Tesis de grado

  • 722 views
Uploaded on

Tesis para obtener el título de Ingeniero Informático en la Facultad de Ciencias Físicas y Matemáticas de la Universidad Nacional de Trujillo.

Tesis para obtener el título de Ingeniero Informático en la Facultad de Ciencias Físicas y Matemáticas de la Universidad Nacional de Trujillo.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
722
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
23
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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
  • 2. DEDICATORIAA ti nuestro Dios que nos diste fuerza, iluminación y empeño a través de unamaravillosa familia.Como expresión de gratitud a nuestros padres y seres queridos por su apoyoconstante.A nuestros asesores y amistades que supieron orientarnos durante la realizacióndel proyecto, por su tiempo y apoyo constante.Con profundo respeto a nuestros GRANDES MAESTROS, por sus enseñanzasimpartidas. Br. Gerardo Víctor Alaín Sánchez Aranda Br. Rolando Palermo Rodríguez Cruz
  • 3. AGRADECIMIENTOSGracias 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. OrlandoAngulo Trujillo, Carlos Alfonso Rivadeneira León, por su participación activa en elproyecto ya que nos permitieron crecer.A nuestros padres y hermanos, por brindarnos todo el respaldo necesario parapoder culminar con éxito este proyecto.A la Escuela de Informática, por el respaldo institucional dado para la realizaciónde 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, EdithTerán Saldaña, Ramón Hernández Gutiérrez, que son buenos amigos y que nosapoyaron en este proceso.Así mismo a aquellas personas que de una u otra manera colaboraron oparticiparon en la realización de esta investigación, hacemos extensivo nuestromás sincero agradecimiento. Br. Gerardo Víctor Alaín Sánchez Aranda Br. Rolando Palermo Rodríguez Cruz
  • 4. PRESENTACIONSeñores Miembros del Jurador Dictaminador:En cumplimiento con las disposiciones vigentes para grados y títulos de laFacultad de Ciencias Físicas y Matemáticas de la Universidad Nacional de Trujillo,sometemos a vuestra consideración la presente tesis titulada: “TELECONTROLDE UN ROBOT MÓVIL PARA TAREAS DE EXPLORACIÓN YRECONOCIMIENTO EN SUPERFICIES TERRESTRES”.El presente trabajo de investigación es el resultado de nuestros mejoresesfuerzos, donde se ponen en práctica los conocimientos adquiridos durantenuestra formación profesional, el cual se complementa con la orientación y apoyode aquellas personas que nos brindaron su ayuda en el desarrollo.Invocamos su comprensión en caso de haber incurrido en cualquier errorinvoluntario en el desarrollo de la presente tesis. Los Autores. Trujillo, Septiembre de 2011
  • 5. ÍNDICE DE CONTENIDOSCAPÍTULO I: INTRODUCCIÓN1.1. Realidad Problemática………………………………………………………. 11.2. Antecedentes…………………………………………………………………. 21.3. Justificación……………………………………………………….………….. 41.4. Planteamiento del Problema……………………………………………….. 41.5. Hipótesis………………………………………………………………………. 41.6. Objetivos……………………………………………………………………… 5 1.6.1. Objetivo General……………………………………………………… 5 1.6.2. Objetivos Específicos………………………………………………… 51.7. Áreas de Aplicación………………………………………………………….. 51.8. Estado Actual………………………………………………………………… 61.9. Organización de la Tesis……………………………………………………. 9CAPÍTULO II: MARCO TEÓRICO2.1. Conceptos fundamentales………………………………………………….. 102.2. Protocolos…………………………………………………………………….. 12 2.2.1. Elementos……………………………………………….…………..... 12 2.2.2. Diseño……………………………………………………………….... 12 2.2.3. Máquinas de estado finito…………………………………………… 142.3. Puertos, Sockets y Modelo Cliente/Servidor……………………………… 162.4. Transmisión de datos en tiempo real……………………………………… 162.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………………………………………………………….... 21CAPÍTULO III: ENLACE DE COMUNICACIÓN1.1. Protocolo 802.11…………………………………………………………….. 221.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
  • 6. ÍNDICE DE CONTENIDOSCAPÍTULO IV: ARQUITECTURA HARDWARE DE TELEOPERACIÓN4.1. Arquitectura principal del sistema de teleoperación……………………… 294.2. El Gamepad como dispositivo de interfaz de teleoperación……………. 31 4.2.1 Interconexión del Gamepad con Java…………………………….. 324.3. Dispositivos de audio y video………………………………………………. 354.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………………………………………………………. 384.5. Módulo de navegación y posicionamiento………………………………… 394.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……………………………… 464.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……………………… 48CAPÍTULO V: SÍNTESIS DEL PROTOCOLO5.1.Descripción del problema…………………………………………………… 505.2.Estructura del protocolo……………………………………………………... 515.3.Nivel de abstracción…………………………………………………………. 525.4.Elementos del protocolo…………………………………………………….. 535.5.Servicio y ambiente………………………………………………………….. 545.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………………………………… 585.7 Implementación del protocolo………………………………………………. 60 5.7.1 HEADER………………………………………………………………. 60 5.7.2 USER DATA………………………………………………………….. 62 5.7.3 TRAILER……………………………………………………………… 655.8 Ejemplos de tramas………………………………………………………….. 65CAPÍTULO VI: ARQUITECTURA DE CONTROL DE RED6.1. Introducción…………………………………………………………………... 666.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…………………………. 746.3 Sincronización de paquetes………………………………………………… 746.4 Implementación experimental de un modelo de control basado en eventos………………………………………………………………………... 77
  • 7. ÍNDICE DE CONTENIDOSCAPÍTULO VII: ANÁLISIS Y DISEÑO DEL SOFTWARE7.1. Especificación de requerimientos…………………………………………… 82 7.1.1 Requerimientos funcionales…………………………………………. 82 7.1.2 Requerimientos no funcionales……………………………………… 837.2 Concepción…………………………………………………………………….. 847.3 Diagrama pictográfico………………………………………………………… 857.4 Casos de uso………………………………………………………………….. 86 7.4.1 Especificación de los casos de uso…………………………………. 867.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……………………………………………… 98CAPÍTULO VIII: RESULTADOS Y CONCLUSIONES8.1. Resultados…………………………………………………………………… 998.2. Conclusiones………………………………………………………………… 1038.3. Recomendaciones………………………………………............................. 103REFERENCIAS BIBLIOGRÁFICAS…………………………………………….. 105ANEXO A: MANUAL DE USUARIO…………………………………………….. 108ANEXO B: IMÁGENES DEL ROBOT DE EXPLORACIÓN…………………... 118ANEXO C: HERRAMIENTAS PARA EL ANÁLISIS DE RED………………… 122
  • 8. LISTA DE FIGURASCAPÍTULO I: INTRODUCCIÓNFigura 1.1 Robots vendidos hasta el 2007………………………………….... 6Figura 1.2 Robots de uso profesional vendidos……………………………… 6Figura 1.3 Ventas de Robots estimadas para el periodo 2008-2011……… 8Figura 1.4 Distribución de los robots en la actualidad según su área de aplicación…………………………………………………………… 8Figura 1.5 Organización de esta tesis………………………………………… 9CAPÍTULO II: MARCO TEÓRICOFigura 2.1 Diagrama de transición de estados………………………….……. 15Figura 2.2 Formato de una cabecera RTP……………………………………. 17Figura 2.3 Cambio de dirección de un robot terrestre……………………….. 18Figura 2.4 Diagrama de Bloques del Robot Móvil…………………………… 19CAPÍTULO III: ENLACE DE COMUNICACIÓNFigura 3.1 Retardo nodal total en el enrutador A……………………………. 24Figura 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………………………………………… 25Figura 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…………………………………………… 26Figura 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……………………………………… 26CAPÍTULO IV: ARQUITECTURA HARDWARE DE TELEOPERACIÓNFigura 4.1 Diagrama general de bloques del sistema de teleoperación desarrollado…………………………………………………………. 31Figura 4.2 El gamepad como dispositivo de interfaz de teleoperación. Izquierda: Disposición de botones y palancas. Derecha: Estructura interna…………………………………………………… 32Figura 4.3 Ventana de controladores de juegos de Windows……………… 33Figura 4.4 Ventana de propiedades y calibración de un dispositivo de juegos en Windows………………………………………………… 34
  • 9. LISTA DE FIGURASFigura 4.5 Resultados de las pruebas de interconexión entre Java y un gamepad…………………………………………………………….. 35Figura 4.6 Cámara web VGA Halion HA-184. Derecha: Sensor CMOS. Izquierda: Lente con filtro de vidrio cristalino……………………. 35Figura 4.7 Cámara IP WIFI con movimiento y visión nocturna. Derecha: Vista posterior. Izquierda: Vista normal………………………….. 36Figura 4.8 Diagrama de bloques de la tarjeta de adquisición de datos…… 37Figura 4.9 Tarjeta de adquisición de datos basada en el Microcontrolador 18F4550……………………………………………………………… 38Figura 4.10 Diagrama de bloques del módulo de navegación y posicionamiento…………………………………………………….. 39Figura 4.11 Receptor GPS Conexant Jupiter. Derecha: Vista superior. Izquierda: Vista inferior…………………………………………….. 39Figura 4.12 Recepción de datos de 4 satélites……………………………….. 40Figura 4.13 Módulo de adquisición de datos de navegación y posición……. 43Figura 4.14 Transistores en configuración de Puente H……………………… 44Figura 4.15 Amplificador de potencia en base a relevadores……………….. 45Figura 4.16 Puente H utilizando el integrado L298N………………………….. 45Figura 4.17 Puente H utilizando el integrado L293B………………………….. 46Figura 4.18 Rueda fija…………………………………………………………… 47Figura 4.19 La locomoción……………………………………………………….. 47Figura 4.20 La locomoción diferencial se caracteriza por la ausencia de ruedas directrices…………………………………………………… 48Figura 4.21 Estructuras mecánicas……………………………………………... 49CAPÍTULO V: SÍNTESIS DEL PROTOCOLOFigura 5.1 Esquema del sistema de comunicaciones……………………….. 51Figura 5.2 Ejemplos de niveles de abstracción………………………………. 53Figura 5.3 Modelo del protocolo desarrollado en base a 4 autómatas……. 55Figura 5.4 Modelo del cliente…………………………………………………... 56Figura 5.5 Diagrama correspondiente al autómata del transmisor………… 57Figura 5.6 Diagrama correspondiente al autómata del receptor…………… 58Figura 5.7 Modelo del canal de comunicación……………………………….. 59Figura 5.8 Principales campos del protocolo…………………………………. 60Figura 5.9 Secciones del campo HEADER del protocolo…………………… 60Figura 5.10 Secciones del campo DATA con respecto al servicio de navegación…………………………………………………………… 64Figura 5.11 Principales campos de la sección TRAILER…………………….. 65Figura 5.12 Trama que indica el reinicio del servicio de video………………. 65Figura 5.13 Trama para la rotación de un actuador del robot móvil…………. 65CAPÍTULO VI: ARQUITECTURA DE CONTROL DE REDFigura 6.1 Esquemas de control tradicional y basado en eventos…………. 67Figura 6.2 Efecto Buffering provocado por los retardos de tiempo en la
  • 10. LISTA DE FIGURAS red…………………………………………………………………….. 68Figura 6.3 Eliminación del efecto Buffering a través de un esquema de control basado en eventos………………………………………… 69Figura 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………………………………………………………………… 70Figura 6.5 Envío de paquetes basado en esquema de control por eventos 73Figura 6.6 Estructura de paquetes…………………………………………….. 73Figura 6.7 Estructura de un paquete con datos de posicionamiento………. 74Figura 6.8 Esquema de sincronización de eventos………………………….. 76Figura 6.9 Resultado del control basado en eventos con δ = 3%................ 78Figura 6.10 Resultado del control basado en eventos con δ = 5%................ 78Figura 6.11 Resultado del control clásico basado en tiempo para la temperatura…………………………………………………………. 79Figura 6.12 Control basado en tiempo en comparación con control basado en eventos con un límite δ = 3%................................................. 79Figura 6.13 Control basado en tiempo en comparación con control basado en eventos con un límite δ = 5%................................................. 80CAPÍTULO VII: ANÁLISIS Y DISEÑO DEL SOFTWAREFigura 7.1 Diagrama pictográfico……………………………………………… 85Figura 7.2 Casos de Uso básicos del sistema………………………………. 86Figura 7.3 Modelo Estático del dominio del problema. TRCU es la unidad de control teleoperado (Teleoperated Robot Control Unit)……. 93Figura 7.4 Diagrama de Estado general del sistema……………………….. 94Figura 7.5 Diagrma de sub-estados del estado Operacional de la Figura 7.4……………………………………………………………………… 95Figura 7.6 Diagrama de Actividades del proceso de exploración…………… 96Figura 7.7 Diagrama de Componentes………………………………………… 97Figura 7.8 Diagrama de Despliegue……………………………………………. 98CAPÍTULO VIII: RESULTADOS Y CONCLUSIONESFigura 8.1 Comparativa de dos métodos de control: Control basado en tiempo y Control basado en eventos……………………………. 100Figura 8.2 Control basado en tiempo……………………………………….. 100Figura 8.3 Control basado en eventos con δ = 3%.................................... 101Figura 8.4 Control basado en eventos con δ = 5%.................................... 101ANEXO A: MANUAL DE USUARIOFigura A.1 Vista superior del gamepad……………………………………… 112Figura A.2 Vista lateral del gamepad………………………………………… 112Figura A.3 Pantalla principal del software de telecontrol………………….. 113Figura A.4 Barra de menús……………………………………………………. 114
  • 11. LISTA DE FIGURASFigura A.5 Menú de herramientas……………………………………………. 115Figura A.6 Menú de servicios…………………………………………………. 115Figura A.7 Barra de herramientas……………………………………………. 116Figura A.8 Pantalla de configuración de parámetros………………………. 116Figura A.9 Botones de acceso rápido………………………………………... 117Figura A.10 Consola…………………………………………………………….. 117Figura A.11 Interfaz de control del robot……………………………………… 118Figura A.12 Pantalla de localización satelital………………………………… 119Figura A.13 Interfaces del software del robot móvil………………………….. 120ANEXO B: IMÁGENES DEL ROBOT DE EXPLORACIÓNFigura B.1 Diagrama esquemático del circuito de control…………………. 121Figura B.2 Pinzas del sistema de manipulación……………………………. 122Figura B.3 Manipulador de 4 grados de libertad……………………………. 122Figura B.4 Hardware de telecontrol del robot de exploración……………... 123Figura B.5 Estación de telecontrol……………………………………………. 123Figura B.6 Robot GERO II…………………………………………………….. 124ANEXO C: HERRAMIENTAS PARA EL ANÁLISIS DE REDFigura C.1 Ejemplo de envío de un paquete ICMP………………………… 125Figura C.2 Inicio del asistente de instalación……………………………….. 128Figura C.3 Componentes disponibles para su instalación…………………. 128Figura C.4 Pantalla para la selección de accesos directos………………... 129Figura C.5 Ventana de selección del directorio de instalación……………. 130Figura C.6 Proceso de instalación iniciado………………………………….. 130Figura C.7 Ventana para la instalación de componentes adicionales……. 131Figura C.8 Finalizando la instalación de Wireshark………………………… 131Figura C.9 Proceso de instalación finalizado………………………………... 132
  • 12. LISTA DE TABLASTabla 2.1 Estados de transición de una máquina de estado finito………….. 14Tabla 2.2 Descripción de los campos de una cabecera RTP……………….. 17Tabla 2.3 Tipos de datos transferidos entre el robot móvil y la estación de control………………………………………………………………….. 21Tabla 3.1 Comparación de los diferentes estándares de la familia 802.11... 23Tabla 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…………..…………………………………………….. 25Tabla 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………………………………………………………………….. 26Tabla 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……………..………………………………………….. 27Tabla 6.1 Limites de las variables más usadas en la exploración de ambientes……………………………………………………………… 72Tabla 7.1 Requerimientos Funcionales del Sistema…………………………. 82
  • 13. PRÓLOGOHan pasado más de 50 años desde que la robótica sentó sus bases y principios ynuestro país no fue ajeno a este acontecimiento. Y ha sido justo esta área de laIngeniería la que ha cambiado la vida de la gente, haciendo de esta más cómoda ysencilla. Sin embargo estos alcances de la tecnología aún no se han visto muyacentuados en nuestro país.Cabe plantear la siguiente interrogante -¿Qué está haciendo la gente encargadade desarrollar la tecnología en Perú?- Muchos países vecinos han iniciadocarreras espaciales con sus primeras sondas exploradoras, que si bien es cierto,están lejos de las potencias mundiales, son investigaciones que servirán de basepara las futuras generaciones.Hemos visto una fuerte filosofía que se está forjando en nuestras universidadesque hacen ver a la robótica como un aspecto netamente lúdico, sin embargo ya estiempo de cambiar esto. Los trabajos orientados a la robótica no alcanzan aún laenvergadura de verdaderos proyectos de investigación y en esta área somosampliamente superados por otros países de América latina.En este presente trabajo queremos aportar algo diferente pues en esta era delconocimiento y la información no podemos ser ajenos a los grandes cambios ydebemos apostar por la tecnología, que a nuestro punto de vista es hoy en día unode los pilares en el desarrollo de una nación.Este trabajo de investigación es una obra multidisciplinaria, pero ha sido orientadoal área de Ciencias de la Computación y la Ingeniería de Redes yTelecomunicaciones dejando otros aspectos para futuras mejoras y nuevaspropuestas.
  • 14. RESUMENEn este trabajo de investigación se describe el proceso de telecontrol de un robotmóvil como medio de exploración. Con el afán de poner énfasis en el sistemaproyectado a manera de prototipo, se implementó una sonda exploradora (a partirde ahora será referenciada como sonda) con los servicios que describimos acontinuació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 actuarante diversas situaciones y ambientes. Utiliza para ello, un protocolo detransferencia de multimedia desarrollado sobre la plataforma Java (RTP) queconjuntamente con el protocolo basado en sockets que aquí se plantea,estructuran un protocolo aún más robusto que al trabajar directamente sobreTCP/IP permiten no depender de ningún servicio en Internet e incrementar lascapacidades 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 afin de hacernos comprender mejor los beneficios y utilidades de este proyecto.
  • 15. ABSTRACTIn this study is described the telecontrols process of a mobile robot as anexploration 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 ofsituations and environments. It uses for this, a transfer protocol of multimedia,developed on the Java platform (RTP) which together with the sockets-basedprotocol which are proposed here, structure even more a robust protocol thatworking directly over TCP / IP allow not rely on any Internet service and increasecapacity 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 tomake us better understand the benefits and profits of this project.
  • 16. CAPÍTULO I INTRODUCCIÓNEn este capítulo se presenta una descripción completa del entorno en el que hasido desarrollado este trabajo de investigación, detallando primero el estado delarte de la robótica de exploración y el telecontrol para luego describir el impactoque ha tenido en la sociedad actual. Por último se comentarán algunos avancesque se han logrado hasta el día de hoy mostrando estadísticas y proyecciones afuturo.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
  • 17. 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
  • 18. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 19. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES1.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
  • 20. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES1.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
  • 21. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES1.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
  • 22. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 23. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 24. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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ón1.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
  • 25. CAPÍTULO II MARCO TEÓRICOEn este capítulo se revisan las bases teóricas, que dan pie a los métodospropuestos en esta tesis, para poder controlar correctamente a una sondamediante un protocolo, a fin que esta realice tareas de reconocimiento yexploración en superficies terrestres. Para esto se revisan algunos conceptosrelacionados 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
  • 26. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 27. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 28. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 29. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 30. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 31. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES2.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
  • 32. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 33. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES2.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
  • 34. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 35. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 36. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 37. CAPÍTULO III ENLACE DE COMUNICACIÓNLos medios de comunicación llevan información entre todos los subsistemas de unsistema de telecontrol. Las comunicaciones entre las unidades de control del roboty los servidores o entre las cámaras y los servidores están implementadas através de conexiones RS-232 o USB. De otro lado, la comunicación entre el ladodel 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, elretardo de tiempo como su principal inconveniente, así como la pérdida depaquetes son descritos ya que ellos son relevantes al momento de diseñarmecanismos 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
  • 38. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 39. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 40. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 41. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES (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. Estadísticas de ping para 192.168.1.1 Paquetes 65 Paquetes 64 Paquetes 1 enviados recibidos perdidos 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. (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
  • 42. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES Estadísticas de ping para 192.168.1.1 Paquetes 47 Paquetes 33 Paquetes 14 enviados recibidos perdidos 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 27
  • 43. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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, elenfoque de control a aplicar debe hacer frente a estos factores perturbadores. Laentrega de los paquetes fuera de orden debe ser manejada y controlada paraasegurar la fiabilidad en la transmisión de datos entre unidades remotas. Tomar elmedio de comunicación en cuenta, como un factor realmente influyente, esimportante para mejorar el rendimiento del protocolo de telecontrol. 28
  • 44. CAPÍTULO IV ARQUITECTURA HARDWARE DE TELEOPERACIÓNComo objetivo general para esta tesis se ha dispuesto realizar el telecontrol de unrobot móvil, el cuál consta de una arquitectura hardware que le permite sertelecontrolado. En este capítulo se describe la arquitectura principal del sistema deteleoperación diseñado, de forma global así como por medio de una descripciónpor bloques que muestra la estructura funcional de cada módulo o circuitoselectró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
  • 45. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 46. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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 desarrollado4.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
  • 47. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 48. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES • 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
  • 49. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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
  • 50. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 20/06/2011 02:19:17 PM net.java.games.input.DefaultControllerEnvironment getControllers INFO: Loading: net.java.games.input.DirectAndRawInputEnvironmentPlugin Encontrado el control Teclado est ndar de 101/102 teclas o estándar Microsoft Natural PS/2 Ke Keyboard que es un Keyboard Encontrado el control Mouse compatible con HID que es un Mouse Encontrado el control Generic USB Joystick que es un Stick Figura 4.5 Resultados de las pruebas de interconexión entre Java y un gamepad entr4.3. DISPOSITIVOS DE AUDIO Y VIDEO 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 de resolución y conexiones USB (Figura d 4.6) además de una cámara IP inalámbrica de similares características y un ) micrófono incorporado para la transmisión de audio. Figura 4.6 Cámara web VGA Halion HA 184. Derecha: Sensor CMOS. Izquierda: Lente HA-184. con filtro de vidrio cristalino. En teleoperación es importante proveer interfaces de usuario amigables con el fin de que la interacción entre el operador y la sonda se lleve a cabo de [17] manera confortable . Por esta razón se han posicionado 4 cámaras de 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 cámaras 35
  • 51. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES hasta en 4 diferentes grados de libertad con el objetivo de proveer al operador de una vista panorámica de 360 grados sin tener el problema que se tendría con cámaras sobre soportes fijos. fijos La cámara de la Figura 4.7, al ser inalámbrica, puede ser colocada sobre un 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: Vista posterior. Izquierda: Vista normal.4.4. TARJETA DE ADQUISICI ADQUISICIÓN DE DATOS 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 sistemas móviles [19]. sistemas El hardware, según se muestra en la Figura 4. , está conformado por una 4.8, unidad de control, unidad de adquisición, dos buses análogos, salidas digitales y una fuente de alimentación. Dicho circuito no es más que un 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
  • 52. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES Salidas Digitales Bus Analógico 1 Unidad de Unidad de Adquisición Control Bus Interno Bus Analógico 2 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. 37
  • 53. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES ECS-10-13-1 Y1 P1 P3 D1 U1 MC7805CT VCC OSC1 1 2 OSC2 RA2 RE0 1 1 1 3 RA3 RE1 12V IN OUT C1 C2 2 2 RE2 GND C0402 C0402 3 1N4007 C4 C5 C RA4 C3 22pF 22pF 4 T491B T491B RA5 C0402 5 RA6 2 100uF/25V 100uF/16v 6 100nF GND GND SOC GND GND GND GND U2 VCC U3 LM35DZ 32 19 AN0 P4 OSC1/CLKI RA0/AN0 1 2 AN0 20 AN1 RB0 +VS VO RA1/AN1 1 21 RA2 RB1 GND RA2/AN2/VREF-/CVREF 2 16 37 22 RA3 RB2 R4A VUSB RA3/AN3/VREF+ 3 23 RA4 RB3 RA4/T0CKI/C1OUT/RCV 4 VCC 7 24 RA5 RB5 3 100 VDD RA5/AN4/SS/HLVDIN/C2OUT 5 8 33 RA6 RB6 VDD OSC2/CLKO/RA6 6 28 RB7 VDD 7 GND 16 29 9 RB0 RC0 1 R1A VDD RB0/AN12/INT0/FLT0/SDI/SDA 8 10 RB1 RC1 RB1/AN10/INT1/SCK/SCL 9 6 11 RB2 RC2 GND 4K7 VSS RB2/AN8/INT2/VMO 10 30 12 RB3 S1 VSS RB3/AN9/CCP2/VPO 31 14 OSC2 RA VSS RB4/AN11/KBI0/CSSPP 1 R2A 16 1 Reset 15 RB5 RB5/KBI1/PGM SW-PB OSC1 13 16 RB6 NC RB6/KBI2/PGC 100 17 RB7 P2 RB7/KBI3/PGD GND RD0 1 AN1 34 RC0 RD1 RC0/T1OSO/T13CKI 2 J1 35 RC1 RD2 RC1/T1OSI/CCP2/UOE 3 5 GND 36 RC2 RD3 SHLD RC2/CCP1/P1A 4 VCC U4 LM35DZ 42 RC4 RD4 RC4/D-/VM 5 1 2 4 GND 43 RC5 RD5 +VS VO GND RC5/D+/VP 6 3 RC4 44 RD6 GND D+ RC6/TX/CK 7 16 2 RC5 1 Reset RD7 R5A D- RC7/RX/DT/SDO 8 1 VBUS 38 RD0 R 3 100 RD0/SPP0 1 440247-1 39 RD1 R3A RD1/SPP1 40 RD2 RD2/SPP2 GND 41 RD3 1 330 RD3/SPP3 RE0 25 2 RD4 RE0/AN5/CK1SPP RD4/SPP4 RE1 26 3 RD5 GND RE1/AN6/CK2SPP RD5/SPP5/P1B RE2 27 4 RD6 RE2/AN7/OESPP RD6/SPP6/P1C 16 18 5 RD7 VCC MCLR/VPP/RE3 RD7/SPP7/P1D C6 PIC18F4550-I/ML C0402 47uF GND 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. 38
  • 54. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES4.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.) MAX232 GPS 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 39
  • 55. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. S2(x2,y2,z2) S1(x1,y1,z1) d2 P0 d3 d1 S3(x3,y3,z3) V1 V0 d4 V3 V2 S4(x4,y4,z4) V4 Figura 4.12 Modelo vectorial del proceso de triangulación 40
  • 56. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES ‖ ‖=‖ ‖=‖ ‖=‖ ‖= = + = + = + = + De donde tenemos: ‖ ‖=‖ ‖ +2 +‖ ‖ … … … … … … … . (1) ‖ ‖=‖ ‖ +2 +‖ ‖ … … … … … … … . (2) ‖ ‖=‖ ‖ +2 +‖ ‖ … … … … … … … . (3) ‖ ‖=‖ ‖ +2 +‖ ‖ … … … … … … … . (4) Efectuando: (1) en (2) ‖ ‖ −‖ ‖ .( − )= … … … … … … … . (5) 2 (2) en (3) ‖ ‖ −‖ ‖ .( − )= … … … … … … … . (6) 2 (3) en (4) ‖ ‖ −‖ ‖ .( − )= … … … … … … … . (7) 2 Sabiendo que: = − ; − ; − = − ; − ; − = − ; − ; − = − ; − ; − 41
  • 57. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES Tenemos: − = − ; − ; − − = − ; − ; − − = − ; − ; − De las ecuaciones (5), (6) y (7) tenemos el siguiente sistema: ‖ ‖ −‖ ‖ ( − )+ ( − )+ ( − )= 2 ‖ ‖ −‖ ‖ ( − )+ ( − )+ ( − )= 2 ‖ ‖ −‖ ‖ ( − )+ ( − )+ ( − )= 2 Con esto finalmente podemos determinar los puntos buscados: ‖ ‖ −‖ ‖ − − 2 ‖ ‖ −‖ ‖ − − 2 ‖ ‖ −‖ ‖ − − = 2 − − − − − − − − − ‖ ‖ −‖ ‖ − 2 − ‖ ‖ −‖ ‖ − 2 − ‖ ‖ −‖ ‖ − 2 − = − − − − − − − − − 42
  • 58. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES ‖ ‖ −‖ ‖ − − 2 ‖ ‖ −‖ ‖ − − 2 ‖ ‖ −‖ ‖ − − = 2 − − − − − − − − − 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. SW1 SW2 SW3 SW4 8 7 6 5 S1 C1+ C2+ SW DIP-4 C1 C2 Cap Pol1 Cap Pol1 1uF 1uF C1- C2- T2OUT 1 2 3 4 U1 C3 Cap Pol1 J1 C1+ 1 2 1uF P2 C1+ VDD 5 GND C1- 3 16 VCC T2IN C1- VCC 1 2 9 SW4 C2+ 4 VCC VCC VCC GND GND C2+ C5 3 4 4 C2- 5 R2OUT GND C2- Cap Semi R8 R9 R10 5 6 8 SW1 GND 100nF 7 8 10 3 R1IN T1IN 11 14 T1OUT T1IN R1OUT T1IN T1OUT 47K 47K 47K 9 10 7 T2IN 10 7 T2OUT GND T2IN T2OUT GND 11 12 11 2 T1OUT PR8 PR9 PR10 GPS13 GPS14 13 14 6 SW2 R1OUT12 13 R1IN GPS15 R1OUT R1IN 15 16 1 SW3 R2OUT 9 8 R2IN DI5 C10 R2OUT R2IN 17 18 P3 P4 P5 19 20 D Connector 9 15 6 PR8 PR9 PR10 GND VEE 3 3 3 R11 GPS GPS15 GPS13 GPS14 J2 C4 2 2 2 100nF MAX232ACPE P6 GND Cap Pol1 1 1 1 10E GND 8 OUT 1uF 1 7 R2IN RESET NMEA ROM VCC R5 GND GND GND 2 6 270 T1IN 5 T2OUT GND ANTENA 4 GND 3 R6 270 T2IN 2 D2 DI5 DI5 1 1N4148 R7 D6 D5 270 D Zener 15-43-6233 1N4002 P7 R12 270 D1 1 P1 U2 LM317BT GND 2 D7 3 2 VCC 2 IN OUT 1N4148 C6 BATERÍA 1 ADJ 1N4007 Cap Pol1 R4 GND ALIMENTACIÓN 100uF/35V D3 R3 1N4002 1K C9 D8 1 C8 GND R1 680 R2 1 220 Cap Semi 1N4148 Cap Pol1 C7 47uF/16V 100nF Cap Pol1 D4 10uF/16V LED R13 1K GND GND GND GND GND VCC Figura 4.13 Módulo de adquisición de datos de navegación y posición 43
  • 59. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES4.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. VCC M GND 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 44
  • 60. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. K1 2 GND GND 2 K2 VCC 1 OUT1 OUT2 1 VCC 3 VCC VCC 3 VCC 4 OUT1 4 VCC D1 D2 Diode 1N4007 5 Diode 1N4007 S1 M B1 Motor 5 S2 SW-SPST Relay Relay SW-SPST OUT2 Q2 TIP31 R1 Q1 NPN R2 TIP31 Res Semi NPN Res Semi 1K 1K GND GND 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. OUT1 C3 OUT2 Cap OUT1 OUT2 1uF VCC D2 D1 D5 D8 Diode 1N4007 Diode 1N4007 C1 Diode 1N4007 Diode 1N4007 VCC GND Cap Pol1 GND VCC 1000uF D4 D3 D6 D7 Diode 1N4007 Diode 1N4007 GND Diode 1N4007 Diode 1N4007 OUT3 OUT3 OUT4 C2 Cap OUT4 1uF OUT1 OUT3 VCC U1 VCC IN1 5 9 IN1 VSS IN2 7 4 C4 IN2 VS 12V M B2 Motor M B1 Motor Cap IN3 IN4 10 12 IN3 2 OUT1 100pF IN4 OUT1 3 OUT2 OUT2 OUT2 OUT4 EN A 6 13 OUT3 GND EN A OUT3 EN B 11 14 OUT4 EN B OUT4 P1 P2 IN1 IN3 1 2 2 ISEN A IN2 IN4 8 15 1 1 GND ISEN B Input1 Input2 L298N GND GND P3 EN A 2 EN B 1 Enable Figura 4.16 Puente H utilizando el integrado L298N 45
  • 61. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. U1 VCC VCC 2 16 IN1 VCC 7 8 IN2 VC C1 10 IN3 Cap 15 3 OUT1 IN4 OUT1 100nF P1 6 OUT2 OUT2 IN1 1 11 OUT3 4 EN1 OUT3 GND IN2 9 14 OUT4 3 EN2 OUT4 IN3 2 IN4 4 OUT1 OUT3 1 GND 5 GND Input 12 GND 13 P2 GND M B1 Motor M B2 Motor EN1 L293B 2 GND EN2 OUT2 OUT4 1 Enable Figura 4.17 Puente H utilizando el integrado L293B4.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. 46
  • 62. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. w r 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 47
  • 63. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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). H Y1 VL L V R VR ω VL VR Y Θ ICR R X X1 L/2 L/2 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. 48
  • 64. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 49
  • 65. CAPÍTULO V SÍNTESIS DEL PROTOCOLOLos protocolos de comunicación juegan un papel importantísimo en los sistemasde telecontrol de robos móviles, dándoles a estos la capacidad de abordaraplicaciones del mundo real. Sin embargo protocolos que carecen de un diseñoformal o que no están bien adaptados a las características y funcionalidades delos enlaces de comunicación actuales, pueden reducir enormemente la efectividadde un sistema robótico. Es aquí donde la ingeniería de protocolos, pocas vecesabordada, propone una serie de etapas que se desarrollarán en este capítulo yque 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. 50
  • 66. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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). Ambiente desconocido Puesto central Sonda de Exploración (Unidad Remota) 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. 51
  • 67. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 52
  • 68. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES Señal Eléctrica Bits Símbolos/caracteres Campos de mensaje Paquetes 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. 53
  • 69. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES • 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. 54
  • 70. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. Cliente Send Ok Error Msg Msg Transmisor Canal Receptor ACK/NAK ACK/NAK Figura 5.3 Modelo del protocolo desarrollado en base a 4 autómatas 55
  • 71. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. Idle Send! NB:=n, W:=0 Waiting end_tx? abort_tx? OK Error 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 56
  • 72. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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 i:=0, n:=0 Idle send? Sending A<NB smsg! wa:=0 ns:=ns+1 Wait_ack end_tx! i==NB ack? i:=i+1 wa<=timeout n=0 wa<timeout ns==sn+1 wa:=0, r:=r+1 wa<=timeout smsg! ns==nr R<MAXR rack? R=MAXR wa==timeout abort_x! Retry 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. 57
  • 73. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES msg? Idle Check_msg nr:=nr+1 ns==nr ns!=nr sack! sack! 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). 58
  • 74. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES d:=0 Sending_ack d<=ttxprop sack? Idle d:=tprop d:=tprop rack! msg! smsg? d==ttx+prop d:=0 d==ttx+prop Sending_msg d<=ttxprop 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. 59
  • 75. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES5.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 60
  • 76. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 61
  • 77. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES • 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. 62
  • 78. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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 Sentido de Giro 1 01 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 Sentido de Giro 0 10 Sentido de Giro 1 01 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 Sentido de Giro 0 10 Sentido de Giro 1 01 63
  • 79. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES • 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. 64
  • 80. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. HEADER DATA TRAILER 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. HEADER DATA TRAILER 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 65
  • 81. CAPÍTULO VI ARQUITECTURA DE CONTROL DE REDControlar un robot móvil sobre un canal susceptible a retardos y errores detransmisión puede ser un gran reto. La fiabilidad y la sincronización son losprincipales factores que determinan el rendimiento de un robot telecontrolado, yaque problemas relacionados con los retardos de tiempo en las comunicacionesinevitablemente degradarán el rendimiento del proceso de telecontrol. Éstosretardos perturban las transmisiones de forma aleatoria por lo que es necesariotomar en cuenta estrategias con el fin de mantener un enlace de comunicaciónfiable.6.1. INTRODUCCIÓN Muchos sistemas de telecontrol no poseen grado alguno de autonomía en [17] el lado remoto 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. 66
  • 82. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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 [22] periódicos o activados por tiempo han sido usados por muchos años , 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. Yd(t) e(t) Y(t) PLANIFICADOR CONTROLADOR ROBOT - a) Control tradicional basado en el tiempo Yd(s) e(s) Y(t) PLANIFICADOR CONTROLADOR ROBOT - ACCIÓN DE REFERENCIA 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 67
  • 83. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. Cm Cm-1 …. C4 C3 C2 OPERADOR ROBOT Tiempo=m HUMANO MÓVIL F1 F2 Cm+n Cm+n-1 …. Cm+2 Cm+1 Cm OPERADOR ROBOT Tiempo=m+n HUMANO MÓVIL F1 F2 F3 …. Fm-1 Fm Figura 6.2 Efecto Buffering provocado por los retardos de tiempo en la red 68
  • 84. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES Cn Cn Evento = n OPERADOR ROBOT HUMANO MÓVIL Fn Fn Cn+1 Cn OPERADOR ROBOT Evento = n+1 HUMANO MÓVIL Fn Fn Cn+1 Cn+1 OPERADOR ROBOT Evento = n+1 HUMANO MÓVIL Fn Fn Cn+1 Cn+1 OPERADOR ROBOT Evento = n+1 HUMANO MÓVIL Fn Fn+1 Cn+1 Cn+1 OPERADOR ROBOT Evento = n+1 HUMANO MÓVIL Fn+1 Fn+1 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. 69
  • 85. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. Muestro según el control basado en eventos Muestro según el control basado en el tiempo Señal Tiempo 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 70
  • 86. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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 [23] antes 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. 71
  • 87. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 72
  • 88. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES Operador Humano Robot Móvil Enviar Paquete 1 Recibir Paquete 1, hacer las operaciones necesarias y responder con ACK-1 Enviar Paquete 2 Figura 6.5 Envío de paquetes basado en esquema de control por eventos TIPO DE SENTIDO SENTIDO NÚMERO DE COMANDO DE GIRO 0 DE GIRO 1 SECUENCIA (a) Estructura de un paquete de comando TIPO DE NÚMERO DE SEGUNDO COMANDO SECUENCIA (b) Estructura de un paquete ACK 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. 73
  • 89. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 6.2.2 ESQUEMA DE CONTROL BASADO EN EL TIEMPO En un esquema basado en tiempo, es la progresión del mismo la que [22] provoca la ejecución de acciones de control . 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]. VELOCIDAD DEL ROBOT HORA UTC LONGITUD LATITUD ALTITUD 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 74
  • 90. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 75
  • 91. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES CLIENTE Sincronización M<N de eventos Restringir No comandos O M=N Esperar hasta Evaluación de que N=M Si los mensajes de confirmación Generación de Permitir comandos comandos Tiempo marcado Tiempo marcado para mensaje para frame de ACK (Segundo m) video (Segundo n) ¿Hay algún paquete perdido? Si Dispositivo de No adquisición de video SERVIDOR 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 76
  • 92. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 77
  • 93. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 60 Temperatura Interna ºC 50 40 30 20 10 0 0 100 200 300 400 500 600 700 Tiempo (segundos) 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 [22] proporciona mejores resultados de control . Sin embargo ocasiona un número más elevado de conmutaciones de la señal como se puede apreciar en la Figura 6.11. 60 50 Temperatura Interna ºC 40 30 20 10 0 0 100 200 300 400 500 600 700 Tiempo (segundos) Figura 6.10 Resultado del control basado en eventos con δ = 5% 78
  • 94. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 60 50 Temperatura Interna ºC 40 30 20 10 0 0 100 200 300 400 500 600 700 Tiempo (segundos) Figura 6.11 Resultado del control clásico basado en tiempo para la temperatura 60 Control clásico 50 Control basado en eventos Temperatura Interna ºC 40 30 20 10 0 0 100 200 300 400 500 600 700 Tiempo (segundos) Figura 6.12 Control basado en tiempo en comparación con control basado en eventos con un límite δ = 3% 79
  • 95. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 60 Control clásico 50 Temperatura Intera ºC Control basado en eventos 40 30 20 10 0 0 100 200 300 400 500 600 700 Tiempo (segundos) 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 80
  • 96. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 81
  • 97. CAPÍTULO VII ANÁLISIS Y DISEÑO DEL SOFTWAREEste capítulo describe el análisis y diseño del software de aplicación. Estaaplicación está compuesta de dos partes, el lado del operador humano y el robotmóvil, que se comunican mediante un enlace de red. El capítulo entregainformación acerca del proceso de desarrollo empleando el Lenguaje Unificado deModelado (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 5 en la que se encuentre el robot móvil. RF2 Transmisión de El sistema debe permitir el envío de Comandos comandos de control de forma remota. 5 RF3 Comunicación con el El sistema debe establecer la Hardware comunicación entre software y 5 hardware. RF4 Control de dispositivos El sistema debe permitir el control de 5 electrónicos, diversos dispositivos que en conjunto electromecánicos y cumplirán con el objetivo del proyecto. eléctricos. RF5 Transmisión de Sonido El sistema debe permitir la transmisión 4 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. Tabla 7.1 Requerimientos Funcionales del Sistema 82
  • 98. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 83
  • 99. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 84
  • 100. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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 Trama RMI/RTP Trama RMI/RTP ROBOT MÓVIL ESTACIÓN DE CONTROL ENRUTADOR 802.11b WIRELESS Nivel de Capa Física y Nivel de Capa de Enlace de Datos Nivel de Capa de Aplicación Comando de Datos del Aplicación Configuración Ambiente de Modo Flujo de Tarjeta de Adquisición Temperaturas Flujo de Video Audio Señal de Inicialización de Datos µC Directivas y Comandos Microcontrolador Dispositivos de adquisición de audio y video Señales de Control Temperatura del de Giro Ambiente Diagrama Pictográfico LM35 Telecontrol de un robot móvil para tareas de reconocimiento y exploración Actuadores Mecánicos en superficies terrestres Sensores de Temperatura Figura 7.1 Diagrama pictográfico 85
  • 101. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES7.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. Apagar Establecer Modo de Iniciar Operación Controlar Torre de Controlar Orientación manipulador Operador Mover Parar Robot Sistema Reiniciar 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 86
  • 102. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 87
  • 103. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. Precondición: El sistema está iniciado. 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. 88
  • 104. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. Precondición: El sistema está iniciado. 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. 89
  • 105. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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: 90
  • 106. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. Precondición: El sistema está iniciado. Secuencia Normal: 1. El operador pulsa el botón correspondiente al sentido de giro del robot. 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. 91
  • 107. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 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. Controlar Manipulador: Actor: Operador Resumen: El operador pone en marcha el sistema manipulación. Precondición: El sistema está iniciado. Secuencia Normal: 1. El operador pulsa el botón correspondiente al sentido de giro de la articulación. 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. 92
  • 108. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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.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. <<External I/O Device>> Local Interface <<External I/O Device>> Handling System 0..* Controls Locates User <<External System>> Move <<Actor>> Controls <<System>> <<External System>> Vehicle Robot TRCU Interacts Teleoperation System 1..* 1..* 0..* Serves images to Guides & supervises Link Joint Sensor <<External System>> Camera Vision System 1..* Actuator Figura 7.3 Modelo Estático del dominio del problema. TRCU es la unidad de control teleoperado (Teleoperated Robot Control Unit) 93
  • 109. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. Ok Estado de error Inicializando Estado de error Error Operacional Solución [prev. operacional] Config Solución [prev. config] Estado de error Config Configurando Apagar Apagar Apagando Figura 7.4 Diagrama de Estado general del sistema 94
  • 110. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES Sin sincronización Parar sistema/alarma Parar manipulación Parado Empezar Manipulando manipulación Alarma crítica/Parar Manipulación Sin sincronización Parar sistema/alarma Parar movimiento [No en manipulación] Estático Parar manipulación En movimiento Empezar movimiento 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. 95
  • 111. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES Inicio del proceso Establecer parámetros por defecto Acrónimos TX: Transmisión de Comandos RX: Recepción de Comandos Iniciar el servicio de TRCU: Unidad de Control Teleoperado video SM: Servicio de Monitorización [Ok] Iniciar el Iniciar TX y servicio de RX de monitorización comandos [Ok] [Ok] Verificar estado de servicios Falla en los servicios Enviar secuencia de comandos Disponibles Recibir secuencia de órdenes del operador Petición de control TRCU Control de SM Ok Reiniciar actuadores Esperando acuse de recibo SM parado Directiva de servicios Reiniciar Parar Respuesta SM Parar servicios Apagar de video y ACK SM Ok comandos Reinicio falló Time out Registrar Evento Fin del proceso Figura 7.6 Diagrama de Actividades del proceso de exploración 96
  • 112. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. :Operador <<library>> <<library>> <<library>> jinput-dx8.dll jinput-raw.dll jinput-wintab.dll <<component>> Panel de control <<component>> <<component>> Generador de Modulo de comandos recepción de datos << TCP/IP>> << UDP>> << LAN>> << TCP/IP>> :Robot <<component>> <<component>> <<component>> Modulo de Modulo de Modulo receptor envío de datos transmisión de comandos multimedia <<library>> <<library>> libSerialPort.dll <<component>> jpicusb.dll Analizador de datos Datos del Ambiente Figura 7.7 Diagrama de Componentes 97
  • 113. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. <<executionEnvironment>> TCP/IP <<executionEnvironment>> PC Windows XP PC Windows 7 TCP/IP RS-232/USB TCP/IP <<executionEnvironment>> <<device>> RED DE Tarjeta de Adquisición de Router AREA Datos Inalámbrico LOCAL SEÑALES ELÉCTRICAS <<device>> Actuadores mecánicos Figura 7.8 Diagrama de Despliegue 98
  • 114. CAPÍTULO VIII RESULTADOS Y CONCLUSIONESEn este capítulo se muestran los resultados obtenidos durante el proceso dedesarrollo de esta tesis, una vez implementados los elementos que forman partedel 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. 99
  • 115. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 40 35 30 Temperaturas 25 20 15 Control basado en el tiempo Control basado en eventos con δ = 3% 10 Control basado en eventos con δ = 5% 5 0 0 500 1000 1500 2000 Tiempo Figura 8.1 Comparativa de dos métodos de control: Control basado en tiempo y Control basado en eventos. 40 35 30 25 Temperatura 20 15 10 5 0 0 500 1000 1500 2000 Tiempo Figura 8.2 Control basado en tiempo 100
  • 116. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 40 35 30 25 Temperatura 20 15 10 5 0 0 500 1000 1500 2000 Tiempo Figura 8.3 Control basado en eventos con δ = 3% 40 35 30 25 Temperatura 20 15 10 5 0 0 500 1000 1500 2000 Tiempo Figura 8.4 Control basado en eventos con δ = 5% 101
  • 117. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 102
  • 118. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES8.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 103
  • 119. TELECONTROL DE UN ROBOT MÓVIL PARA TAREAS DE RECONOCIMIENTO Y EXPLORACIÓN EN SUPERFICIES TERRESTRES 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. 104
  • 120. 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. 105
  • 121. REFERENCIAS BIBLIOGRÁFICAS[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. 106
  • 122. REFERENCIAS BIBLIOGRÁFICAS[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. 107
  • 123. ANEXO A MANUAL DE USUARIOA.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 108
  • 124. ANEXO A – MANUAL DE USUARIO drivers y conectores especiales se deberá seguir sus respectivos manuales de referencia. Control de Tracción del Robot Cámara de vigilancia Adelante Eje Y + Izquierda Derecha Eje Z + Eje Z - Atrás Eje Y - Articulaciones Articulaciones de la base del superiores del brazo robótico brazo robótico Figura A.1 Vista superior del gamepad Pinzas delbrazo robótico Base de la cámara de vigilancia panorámica Figura A.2 Vista lateral del gamepad 109
  • 125. ANEXO A – MANUAL DE USUARIOA.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. 110
  • 126. ANEXO A – MANUAL DE USUARIOEn la parte central izquierda se ubican 4 botones que brindan acceso a lasherramientas de software utilizadas para el telecontrol de la sonda. Estasherramientas serán descritas en las siguientes secciones.En la parte inferior se encuentra un panel conteniendo una tabla quemuestra todo el tráfico de red, categorizando su tipo así como mostrandodatos 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 únicaopción que es Salir, que sirve para terminar la ejecución del programa. Figura A.4 Barra de menúsEl menú de Herramientas de la Figura A.5 contiene todas las opciones deconectividad y control.El menú Parámetros de conectividad permite establecer las direccionesIP y MAC y puertos de audio y video de la estación de telecontrol y del robotmóvil.El menú Consola permite visualizar todas las tareas que se ejecutan ensegundo plano y es usado para determinar el estado de las variables delprograma.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 deexploración. 111
  • 127. ANEXO A – MANUAL DE USUARIO Figura A.5 Menú de herramientasEl Visor de mapas satelital es una herramienta opcional que es usadapara visualizar el mapa correspondiente a la posición actual del robot enfunción de las coordenadas transmitidas por la sonda. El uso de estaherramienta no tiene efecto alguno sobre el proceso de telecontrol y solo es soun agregado del software para darle usabilidad. Figura A.6 Menú de serviciosDentro del menú Servicios se encuentran la opción Iniciar servicios cuyautilidad es la de iniciar el funcionamiento del sistema y todos los sub- subservicios que lo componen, hay que tener en cuenta que para que elsistema trabaje hay que tener iniciado el servicio de transferencia de videoen la sonda de exploración.Detener servicios sirve para interrumpir la ejecución de las tareas y erservicios que han sido iniciados en el programa de telecontrol telecontrol.Una barra de botones de acceso rápido localizada debajo de la barra demenú nos permite realizar las tareas básicas de conectividad de manera conectirápida. El primer botón nos permite, al igual que el menú Parámetros deconectividad, establecer las direcciones y puertos, el segundo botón ,permite iniciar los servicios de telecontrol como lo hace el menú Iniciar 112
  • 128. ANEXO A – MANUAL DE USUARIOservicios, el tercer botón detiene los servicios y el último botón finaliza laejecución del programa. Figura A.7 Barra de herramientasLa pantalla de configuración de parámetros a la que se puede accederdesde el menú Parámetros de conectividad es mostrada en la siguientefigura: Figura A.8 Pantalla de configuración de parámetrosLa barra de botones del panel izquierdo (Ver Figura A.9) también nospermite acceder a los servicios disponibles desde el menú de una maneramás rápida. El primer botón muestra la consola (Ver Figura A.10) donde seejecutan las tareas de segundo plano, el segundo botón muestra la interfazpara el control de la sonda, donde existen botones para cada actuador delrobot (Ver Figura A.11), el tercer botón, como se aprecia en la Figura A.12, 113
  • 129. ANEXO A – MANUAL DE USUARIOsirve para visualizar la interfaz donde se despliegan los mapas del área endonde se encuentra el robot, y el cuarto botón es para mostrar el estado delos servicios. Figura A.9 Botones de acceso rápido Figura A.10 ConsolaLa interfaz de la Figura A.11 muestra los controles de los actuadores delrobot móvil. Este tipo de control es auxiliar al que puede ser realizado por elgamepad y en caso de no disponer de uno, el control mediante este paneles la única forma de enviar comandos hacia la sonda de exploración. 114
  • 130. ANEXO A – MANUAL DE USUARIO Figura A.11 Interfaz de control del robotComo se mencionó al principio de esta tesis, el telecontrol del robot móvilno depende de servicios externos, sin embargo de existir una conexión ainternet se podrá visualizar los mapas de acuerdo con las coordenadas quese obtengan del módulo de navegación, pero la ausencia de la misma noafecta el telecontrol del robot ni tampoco su rendimiento. La Figura A.12muestra la interfaz en donde se despliega el mapa así como la posibilidadde realizar zoom al mismo. 115
  • 131. ANEXO A – MANUAL DE USUARIO Figura A.12 Pantalla de localización satelitalLa barra de botones del panel izquierdo (Ver Figura A.9) también nospermite acceder a los servicios disponibles desde el menú de una maneramás rápida. El primer botón muestra la consola (Ver Figura A.10) donde seejecutan las tareas de segundo plano, el segundo botón muestra la interfazpara el control de la sonda, donde existen botones para cada actuador delrobot (Ver Figura A.11), y el tercer botón, como se aprecia en la FiguraA.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 sondade exploración se muestran en la Figura A.13. En esta pantalla se deberánespecificar las direcciones IP y MAC de la estación de telecontrol así comolos puertos de audio y video (que deberán ser los mismos que se hanespecificado en la estación remota). Luego de esto se deberá hacer clic enel botón Iniciar previa conexión de todos los dispositivos como el sistema dehardware vía USB y el módulo de navegación GPS vía cable serial. 116
  • 132. ANEXO A – MANUAL DE USUARIO Figura A.13 Interfaces del software del robot móvilEl panel con los botones que se aprecian en la figura anterior correspondena un panel de pruebas el cual sirve para verificar el correcto funcionamientode los actuadores del robot móvil. El área de texto en la parte superior sirvepara mostrar las tramas adquiridas por el módulo de navegación GPSmientras que el área en blanco de la parte inferior muestra las tramas entexto plano conforme se va realizando el proceso de telecontrol. 117
  • 133. ANEXO BIMÁGENES DEL ROBOT DE EXPLORACIÓN Figura B.1 Diagrama esquemático del circuito de control 118
  • 134. ANEXO B – IMÁGENES DEL ROBOT DE EXPLORACIÓNFigura B.2 Pinzas del sistema de manipulaciónFigura B.3 Manipulador de 4 grados de libertad 119
  • 135. ANEXO B – IMÁGENES DEL ROBOT DE EXPLORACIÓNFigura B.4 Hardware de telecontrol del robot de exploración Figura B.5 Estación de telecontrol 120
  • 136. ANEXO B – IMÁGENES DEL ROBOT DE EXPLORACIÓNFigura B.6 Robot GERO II 121
  • 137. ANEXO C HERRAMIENTAS PARA EL ANÁLISIS DE LA REDC.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. B R3 R4 R5 El mensaje ICMP se R2 envía al origen A R3 no puede entregar el datagrama a B por una mala configuración de su tabla de enrutamiento R1 A Figura C.1 Ejemplo de envío de un paquete ICMP 122
  • 138. ANEXO C – HERRAMIENTAS PARA EL ANÁLISIS DE RED 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 123
  • 139. ANEXO C – HERRAMIENTAS PARA EL ANÁLISIS DE RED 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 124
  • 140. ANEXO C – HERRAMIENTAS PARA EL ANÁLISIS DE RED 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ón2. 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 125
  • 141. ANEXO C – HERRAMIENTAS PARA EL ANÁLISIS DE RED3. 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 directos4. 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. 126
  • 142. ANEXO C – HERRAMIENTAS PARA EL ANÁLISIS DE RED Figura C.5 Ventana de selección del directorio de instalaciónSe presiona el botón para iniciar el proceso de instalación. Figura C.6 Proceso de instalación iniciado5. 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 127
  • 143. ANEXO C – HERRAMIENTAS PARA EL ANÁLISIS DE REDpara la instalación de WinPcap. Se debe seleccionar hastafinalizar la instalación. Figura C.7 Ventana para la instalación de componentes adicionales Figura C.8 Finalizando la instalación de Wireshark 128
  • 144. ANEXO C – HERRAMIENTAS PARA EL ANÁLISIS DE REDLa siguiente pantalla indica que la instalación ha finalizado exitosamente. Figura C.9 Proceso de instalación finalizado 129