escuela politÉcnica nacional - repositorio...
TRANSCRIPT
ESCUELA POLITÉCNICA NACIONAL
FACULTAD DE INGENIERÍA ELÉCTRICA Y
ELECTRÓNICA
DISEÑO, SIMULACIÓN E IMPLEMENTACIÓN DE UN SISTEMA DE
TELEOPERACIÓN PARA UN ROBOT MÓVIL TIPO CARLIKE
PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN
ELECTRÓNICA Y CONTROL
KARLA DANIELA HERNÁNDEZ GANÁN
FREDDY MANUEL PANCHI GUAMANGALLO
DIRECTOR: ING. GEOVANNY DANILO CHÁVEZ GARCÍA, DR.
Quito, noviembre 2017
DECLARACIÓN
Nosotros, Karla Daniela Hernández Ganán, Freddy Manuel Panchi Guamangallo,
declaramos bajo juramento que el trabajo aquí descrito es de nuestra autoría; que
no ha sido previamente presentada para ningún grado o calificación profesional; y,
que hemos consultado las referencias bibliográficas que se incluyen en este
documento.
A través de la presente declaración cedemos nuestros derechos de propiedad
intelectual correspondientes a este trabajo, a la Escuela Politécnica Nacional,
según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por
la normatividad institucional vigente.
_________________________ ____________________________
Karla Daniela Hernández Ganán Freddy Manuel Panchi Guamangallo
CERTIFICACIÓN
Certifico que el presente trabajo fue desarrollado por Karla Daniela Hernández
Ganán y Freddy Manuel Panchi Guamangallo, bajo mi supervisión.
________________________
ING. GEOVANNY DANILO CHÁVEZ GARCÍA, DR.
DIRECTOR DEL PROYECTO
AGRADECIMIENTO
A Dios por su amor infinito.
A mi mamá, por su apoyo y amor incondicional en cada etapa de mi vida y quien
es mi ejemplo de perseverancia.
A mi papá, quien con ternura supo guiarme en cada paso que di, e inculcó en mí el
amor por la vida.
A mis hermanos Pablo y Kelvin, y a mi hermana Ivonne, quienes han sido el pilar
fundamental para avanzar día tras día y lograr ser una mejor persona.
A Freddy, mi amigo y compañero de tesis con quien hemos logrado afrontar y
superar cada obstáculo que se ha presentado en este proyecto.
A todos y cada uno de mis amigos con quienes compartí increíbles momentos, han
sido un gran apoyo en toda la carrera universitaria.
A los profesores de la Escuela Politécnica Nacional, especialmente al Dr. Danilo
Chávez, que fue una guía en todo este proceso y nos ha apoyado para poder
terminarlo eficientemente.
A la Unidad de Mantenimiento Electrónico y a todos los que la conforman, conocí
gente maravillosa e hice grandes amigos.
Karla
AGRADECIMIENTO
A Dios por la vida, por las bendiciones, por acompañarme en cada paso de mi vida
y por permitirme llegar a completar este gran objetivo en mi vida.
A mis padres Olga Guamangallo y Manuel Panchi que con su ejemplo de esfuerzo
y dedicación me han enseñado a ser una persona de bien y a mis hermanos Byron,
Cristian y Danilo que siempre han estado cuando los he necesitado para ayudarme
y apoyarme incondicionalmente.
A mi abuelita Beatriz, tíos, cuñadas, primos y sobrinas que han sabido
encaminarme, apoyarme y alentarme para llevar a cabo todos mis objetivos desde
siempre.
A la Unidad de Mantenimiento Electrónico UME en donde he podido formarme más
profesionalmente y conocí a mis mejores amigos con los cuales he tenido el agrado
de compartir muchos momentos de alegría y apoyo mutuo.
A mi novia, amiga, compañera y confidente Raisa que me ha sabido acompañar y
apoyar en los momentos buenos y malos.
A Karla, amiga y compañera de tesis con la que hemos logrado superar
eficientemente todos los desafíos que implicó llevar a cabo este proyecto de
titulación.
Al Dr. Danilo Chávez que nos ha brindado su consejo de manera oportuna para
librar las dificultades que se presentaban en el proyecto.
Freddy
DEDICATORIA
A mi papá, mi ángel.
Karla
DEDICATORIA
A Dios.
A mis padres Olga Guamangallo y Manuel Panchi ya que con su trabajo me han
permitido terminar mi carrera y también porque ellos han sido la fuente de mi
inspiración para seguir adelante en este largo proceso
A la memoria de mi primo Kevin Nieto y mi abuelo Segundo Guamangallo cuyo
recuerdo siempre estará presente en los corazones de toda la familia.
A mi familia y amigos que creyeron en mí y me ayudaron a ser una mejor persona.
Freddy
i
CONTENIDO
CONTENIDO ........................................................................................................... i
RESUMEN ............................................................................................................ ix
PRESENTACIÓN ................................................................................................... x
. CAPÍTULO 1: MARCO TEÓRICO……………………………………………………..1
1.1. TELEOPERACIÓN DE ROBOTS............................................................. 1
CONCEPTOS GENERALES .............................................................. 1
Teleoperación .................................................................................. 1
Telepresencia .................................................................................. 2
Estabilidad ....................................................................................... 2
Transparencia .................................................................................. 2
EVOLUCIÓN DE LA TELEOPERACIÓN ............................................ 2
ELEMENTOS DE SISTEMAS TELEOPERADOS .............................. 3
Estación Local ................................................................................. 4
Estación Remota ............................................................................. 5
Canal de Comunicación................................................................... 5
RETARDOS EN TELEOPERACIÓN .................................................. 5
Retardo por Protocolo de Comunicación ......................................... 6
Protocolos de Comunicación Confiables .................................. 6
Protocolos de Comunicación No Confiables ............................ 6
Retardo por Velocidad de Transferencia de Datos en la Red .......... 7
El ancho de banda de la red .................................................... 7
La cantidad de usuarios ........................................................... 7
La distancia física ..................................................................... 8
Las características de los dispositivos ..................................... 8
SOFTWARE APLICABLE A INTERFACES ........................................ 8
Software Guide de Matlab ............................................................... 8
Software Visual Studio .................................................................... 9
SISTEMAS DE REALIMENTACIÓN ................................................. 10
Realimentación Háptica ................................................................. 10
Realimentación Visual ................................................................... 12
Realimentación Auditiva ................................................................ 13
ii
1.2. COMUNICACIÓN DE DATOS APLICABLES A TELEOPERACIÓN ...... 14
CANALES DE COMUNICACIÓN ...................................................... 14
Canales Dedicados ....................................................................... 14
Canales No Dedicados .................................................................. 15
PROTOCOLOS APLICABLES EN INTERNET USADOS EN
TELEOPERACIÓN ........................................................................................ 15
Protocolo de Transferencia de Hipertexto HTTP ........................... 15
Protocolo de Transporte en Tiempo Real RTP .............................. 16
Protocolo MQTT (Message Queue Telemetry Transport).............. 17
Protocolo Websockets ................................................................... 17
ARQUITECTURA DEL PROTOCOLO DE COMUNICACIÓN
MQTT………………………………………………………………………………...18
Arquitectura Publicador / Suscriptor .............................................. 18
SERVIDOR DE DATOS O BRÓKER ................................................ 19
1.3. ROBOT MÓVIL ...................................................................................... 19
CLASIFICACIÓN DE LOS ROBOTS MÓVILES ............................... 19
ROBOT MÓVIL TIPO CARLIKE. ...................................................... 21
Tracción ......................................................................................... 22
Direccionamiento Ackerman .......................................................... 22
Modelo Cinemático del Robot ........................................................ 23
Equilibrio mecánico........................................................................ 23
Aplicaciones .................................................................................. 24
1.4. SINGLE BOARD COMPUTER (SBC) .................................................... 24
MODELOS COMERCIALES ............................................................. 25
Raspberry Pi .................................................................................. 25
Beaglebone Black .......................................................................... 25
Udoo .............................................................................................. 26
1.5. PLATAFORMAS DE REALIDAD VIRTUAL ........................................... 26
V-REP .............................................................................................. 26
UNITY 3D ......................................................................................... 28
CAPÍTULO 2: DISEÑO E IMPLEMENTACIÓN DEL HARDWARE DEL ROBOT
MÓVIL TIPO CARLIKE. ....................................................................................... 30
2.1. ARQUITECTURA DEL SISTEMA .......................................................... 30
iii
ESTACIÓN LOCAL ........................................................................... 31
SERVIDOR DE DATOS O BRÓKER ................................................ 31
ESTACIÓN REMOTA ....................................................................... 32
Estación Remota: Carlike Físico .................................................... 32
Estación Remota: Carlike Simulado .............................................. 32
2.2. HARDWARE DE LA ESTACIÓN LOCAL ............................................... 33
CARACTERÍSTICAS DE LA PC U ORDENADOR ........................... 33
JOYSTICK TIPO VOLANTE Y PEDALES ........................................ 34
2.3. HARDWARE DEL SERVIDOR DE DATOS O BRÓKER ....................... 35
2.4. HARDWARE DE LA ESTACIÓN REMOTA: CARLIKE FÍSICO ............. 36
ESTRUCTURA MECÁNICA ............................................................. 36
Ruedas .......................................................................................... 36
Base .............................................................................................. 37
ACOPLES MECÁNICOS PARA MOTORES DEL CARLIKE ............ 38
Acoples Para la Tracción ............................................................... 38
Acoples Para la Dirección .............................................................. 40
SELECCIÓN DE MOTOR DE TRACCIÓN ....................................... 40
SELECCIÓN DE MOTOR DE DIRECCIÓN ...................................... 42
SELECCIÓN DE CÁMARA PARA LA REALIMENTACIÓN VISUAL
DEL CARLIKE FÍSICO ................................................................................... 44
Cámara IP ..................................................................................... 44
SENSORES DEL ROBOT MÓVIL FÍSICO ....................................... 46
Sensor Digital de Distancia SDS01A ............................................. 46
Interruptor Óptico Ranurado H22A1 (Encoder) ............................. 46
SELECCIÓN DE TARJETA EMBEBIDA PARA EL CARLIKE
FÍSICO………………………………………………………………………………. 47
Especificaciones Técnicas ............................................................. 48
Sistema Operativo ......................................................................... 50
Lenguajes de Programación .......................................................... 50
Accesorios ..................................................................................... 50
Aplicaciones .................................................................................. 51
Aplicación en el Proyecto .............................................................. 51
DISEÑO DEL CIRCUITO ELECTRÓNICO DEL SISTEMA .............. 53
iv
Sistema de Alimentación ............................................................... 53
Alimentación para los Actuadores: Micromotor y
Servomotor……………………………………………………………………. 54
Alimentación para cámara IP y sensores ............................... 55
Alimentación para Tarjeta Raspberry Pi 3B. .......................... 55
Circuito de Seguridad para Baterías LiPo .............................. 56
Fuentes Reguladoras de Voltaje: Módulo LM2596 ........................ 60
Driver Para Motor de Tracción - L298n .......................................... 61
Esquema Final del Circuito Electrónico del Sistema ..................... 62
CAPÍTULO 3: DISEÑO E IMPLEMENTACIÓN DEL SOFTWARE PARA EL
SISTEMA DE TELEOPERACIÓN Y EL ROBOT MÓVIL TIPO CARLIKE. ......... 66
3.1. ELEMENTOS DE SOFTWARE DEL CARLIKE FÍSICO. ........................ 66
SELECCIÓN DEL LENGUAJE DE PROGRAMACIÓN. ................... 66
Python 2.7 ..................................................................................... 67
LÓGICA DE MANEJO DE LOS ELEMENTOS DE HARDWARE. .... 68
Driver l298n ................................................................................... 68
Servomotor HS311 ........................................................................ 68
Encoder Óptico .............................................................................. 71
Sensor de presencia Sharp ........................................................... 71
Luces Indicadoras ......................................................................... 72
LÓGICA DE PROGRAMACIÓN DEL CARLIKE FÍSICO .................. 72
CONFIGURACIÓN DE LA CÁMARA IP ........................................... 76
3.2. ELEMENTOS DE SOFTWARE DEL CARLIKE DESARROLLADO EN
ENTORNO VIRTUAL ........................................................................................ 76
DESARROLLO DEL ENTORNO VIRTUAL ...................................... 78
El Terreno ...................................................................................... 78
La Ciudad ...................................................................................... 79
El Carlike Jeep .............................................................................. 80
Luces Direccionales....................................................................... 82
La Cámara ..................................................................................... 83
TeamViewer .................................................................................. 83
PROGRAMAS PARA COMANDAR EL CARLIKE. ........................ 84
Script de la lógica del Carlike ........................................................ 85
v
Script de la cámara ........................................................................ 90
3.3. PROGRAMACIÓN DEL SERVIDOR DE DATOS MQTT ....................... 91
3.4. ELEMENTOS DE SOFTWARE PARA LA ESTACIÓN LOCAL. ............. 93
DESARROLLO DE LA INTERFAZ GRÁFICA................................... 93
DESARROLLO DE LA PROGRAMACIÓN DE LA INTERFAZ ......... 96
. CAPÍTULO 4: PRUEBAS Y RESULTADOS………………………………………..99
4.1. METODOLOGÍA DE IMPLEMENTACIÓN DE LAS PRUEBAS ............. 99
ESCENARIOS DE TELEOPERACIÓN ........................................... 100
Prueba Ideal ................................................................................ 101
Escenario 1. Teleoperación En La Misma Red ............................ 101
Escenario 2. Teleoperación En La Misma Ciudad ....................... 101
Escenario 3. Teleoperación Quito-Latacunga .............................. 102
PRUEBAS AL CANAL DE COMUNICACIÓN DE DATOS .............. 103
Retardo de Ida y Vuelta (Round Trip Time Delay) ....................... 103
Jitter (Fluctuación) ....................................................................... 104
Tasa de Paquetes Perdidos ........................................................ 105
PRUEBAS AL MEDIO DE REALIMENTACIÓN VISUAL ................ 105
PRUEBAS AL OPERADOR ............................................................ 107
Tiempo de Ejecución de la Tarea ................................................ 107
Número de Colisiones ................................................................. 108
Maniobrabilidad ........................................................................... 108
4.2. RECOLECCIÓN DE DATOS ............................................................... 108
DATOS RECOGIDOS DE LA TELEOPERACIÓN PARA EL CARLIKE
FÍSICO…………………………………………………………………………….. 108
Prueba Ideal ................................................................................ 109
Escenario 1. Teleoperación Desde La Misma Red ...................... 109
RTTD en el canal de comunicación de datos ....................... 109
Jitter ..................................................................................... 110
Tasa de paquetes perdidos .................................................. 110
Retardo de la realimentación visual ..................................... 111
Tiempo de ejecución de la tarea .......................................... 111
Número de colisiones ........................................................... 112
Maniobrabilidad. ................................................................... 112
vi
Escenario 2. Teleoperación desde la Misma Ciudad ................... 112
RTTD en el canal de comunicación de datos ....................... 113
Jitter ..................................................................................... 113
Tasa de paquetes perdidos .................................................. 114
Retardo de la realimentación visual ..................................... 114
Tiempo de ejecución de la tarea .......................................... 115
Número de colisiones ........................................................... 116
Maniobrabilidad. ................................................................... 116
Escenario 3. Teleoperación Latacunga - Quito ............................ 116
RTTD en el canal de comunicación de datos ....................... 116
Jitter ..................................................................................... 117
Tasa de paquetes perdidos .................................................. 118
Retardo de la realimentación visual ..................................... 118
Tiempo de ejecución de la tarea .......................................... 119
Número de colisiones ........................................................... 119
Maniobrabilidad. ................................................................... 120
DATOS RECOGIDOS DE LA TELEOPERACIÓN PARA EL CARLIKE
SIMULADO .................................................................................................. 120
Prueba Ideal ................................................................................ 120
Escenario 1. Teleoperación desde la Misma Red ....................... 121
RTTD en el canal de comunicación de datos ....................... 121
Jitter ..................................................................................... 122
Tasa de paquetes perdidos .................................................. 122
Retardo de la realimentación visual ..................................... 123
Tiempo de ejecución de la tarea .......................................... 123
Número de colisiones ........................................................... 124
Maniobrabilidad. ................................................................... 124
Escenario 2. Teleoperación desde la Misma Ciudad ................... 125
RTTD en el canal de comunicación de datos ....................... 125
Jitter ..................................................................................... 126
Tasa de paquetes perdidos .................................................. 126
Retardo de la realimentación visual ..................................... 126
Tiempo de ejecución de la tarea .......................................... 127
vii
Número de colisiones ........................................................... 128
Maniobrabilidad. ................................................................... 129
Escenario 3. Teleoperación Latacunga - Quito ............................ 129
RTTD en el canal de comunicación de datos ....................... 129
Jitter ..................................................................................... 130
Tasa de paquetes perdidos .................................................. 130
Retardo de la realimentación visual ..................................... 131
Tiempo de ejecución de la tarea .......................................... 131
Número de colisiones ........................................................... 132
Maniobrabilidad. ................................................................... 133
4.3. ANÁLISIS DE DATOS .......................................................................... 133
TELEOPERACIÓN PARA EL CARLIKE FÍSICO ............................ 133
RTTD en el Canal de Comunicación de Datos ............................ 133
Jitter ............................................................................................. 134
Tasa de Paquetes Perdidos ........................................................ 134
Retardo de la Realimentación Visual ........................................... 135
Tiempo de Ejecución de la Tarea y Número de Colisiones ......... 135
Maniobrabilidad ........................................................................... 137
TELEOPERACIÓN PARA EL CARLIKE SIMULADO ..................... 140
RTTD en el Canal de Comunicación de Datos ............................ 140
JITTER ........................................................................................ 141
Tasa de Paquetes Perdidos ........................................................ 141
Retardo de la Realimentación Visual ........................................... 141
Tiempo de Ejecución de la Tarea y Número de Colisiones ......... 142
Maniobrabilidad ........................................................................... 144
CAPÍTULO 5: CONCLUSIONES Y RECOMENDACIONES……………………..147
5.1. CONCLUSIONES ................................................................................ 147
5.2. RECOMENDACIONES ........................................................................ 149
REFERENCIAS BIBLIOGRÁFICAS .................................................................. 150
ANEXO A : CONFIGURACIÓN DE LA CÁMARA IP………………………………A-1
ANEXO B: INSTALACIÓN Y CONFIGURACIÓN DEL SERVIDOR DE DATOS
“MOSQUITTO” PARA WINDOWS 7 Y WINDOWS 8 ........................................ B-1
ANEXO C: MANUAL DE USUARIO…………..…………………………………..…C-1
viii
ANEXO D: MODELO DE ENCUESTA……….………………………………….…..D-1
ANEXO E: CIRCUITOS ELECTRÓNICOS DEL CARLIKE FÍSICO……….….…E-1
ix
RESUMEN
Los sistemas de teleoperación han ido ganando mucha importancia y utilidad en
muchos sistemas en los que se hace necesario operar sistemas ubicados en zonas
remotas, inaccesibles o peligrosas. Las aplicaciones de estos sistemas se
extienden en varios campos de la ciencia como la exploración, la medicina, la
industria, etc.
En este proyecto se implementa un sistema de teleoperación que consta de una
estación local, una estación remota y un canal de comunicaciones. La estación local
es un interfaz hombre maquina (HMI) desde la cual, el operador podrá monitorear
la estación remota y también comandarla, para implementar la estación local se
utilizó un GUIDE de Matlab. La estación remota se compone de dos objetos a
comandar que son un robot móvil tipo carlike físicamente implementado, que usa
como procesador central una Raspberry Pi 3B, y un robot tipo carlike implementado
en un entorno virtual desarrollado en Unity 3D. El canal de comunicaciones se
implementó en base al protocolo MQTT el cual es ampliamente usado en el Internet
de las cosas.
Para que el operador pueda conocer el entorno en el que se mueve el robot físico
o simulado, cada robot tiene su propio sistema de realimentación visual. El robot
físico cuenta con una cámara IP y el robot simulado usa Team Viewer. En cada
caso el operador de la estación local utiliza esta realimentación visual para tomar
decisiones sobre el robot.
En este proyecto, el operador comanda la estación remota desde una ubicación
geográficamente alejada, es decir, a distancias físicas considerables y la
comunicación entre la estación local y la estación remota se la realiza mediante el
Internet.
Al final del proyecto de analiza el desempeño del protocolo implementado y el
desempeño del sistema de teleoperación en general en base a comparaciones de
pruebas realizadas desde 3 puntos geográficamente alejados y la forma en la que
influye la distancia física sobre la maniobrabilidad del sistema teleoperado.
x
PRESENTACIÓN
En este proyecto se realiza la descripción total de las partes necesarias para la
implementación del sistema teleoperado, se lo realiza en 5 capítulos y su contenido
se lo menciona a continuación:
En el primer capítulo se revisa la bibliografía necesaria para entender la base
conceptual del marco de la teleoperación y se establecen las posibles herramientas
de hardware y de software a utilizar.
En el segundo capítulo se mencionan las partes de hardware utilizadas en el carlike
físico y en la estación local, se describen las mismas y se justifica su uso en el
proyecto.
En el tercer capítulo se mencionan las partes de software que se implementaron en
la estación local, la estación remota y el canal de comunicaciones, se explican y se
justifican las mismas.
En el cuarto capítulo se presenta la metodología sobre la cual se realizaron las
pruebas, los resultados obtenidos y el análisis de los mismos.
Finalmente, en el quinto capítulo se presentan las conclusiones respectivas sobre
el sistema implementado y las recomendaciones para mejorar y optimizar el
presente proyecto.
1
CAPÍTULO 1
MARCO TEÓRICO
En la actualidad la posibilidad de poder teleoperar sistemas ha tomado mayor
importancia, refiriéndose a teleoperación como el comando de sistemas entre
largas distancias físicas. Los avances en este tema han sido muy amplios desde
sus inicios en los años 40.
Los sistemas teleoperados pueden ser robóticos, eléctricos, mecatrónicos, etc. La
aplicabilidad de la teleoperación en la industria es bastante extensa, pudiendo
dirigirse a líneas como la medicina, la exploración, el sector nuclear entre otros.
Esto indica que la aplicación de esta tecnología seguirá vigente y logrará ser más
avanzada en el futuro.
En el presente capítulo se presentan las bases conceptuales necesarias para poder
entender la temática de la teleoperación, el contexto en el que se desarrolla el
presente trabajo y las herramientas de software y hardware disponibles.
1.1. TELEOPERACIÓN DE ROBOTS
CONCEPTOS GENERALES [1]
A continuación, se muestran algunos de los conceptos básicos sobre la
teleoperación.
Teleoperación
Es una tecnología mediante la cual un operador humano puede comandar un
sistema, en este caso robótico, ubicado en una zona remota, la cual puede estar
ubicada a una distancia física considerable, inaccesible o perjudicial para dicho
operador, desde una zona local usando elementos que le ofrecen maniobrabilidad
sobre el robot y percepción del entorno del robot con la finalidad de realizar tareas
específicas con la misma solvencia como si el operador estuviera comandando al
robot de manera directa.
2
Telepresencia
Hace referencia a los mecanismos que permiten la realimentación, odométrica o
visual, del sistema robótico y de su entorno hacia el operador para que el mismo
sienta como si estuviese directamente en el lugar del robot donde desarrolla la
tarea.
Estabilidad
Es un estado en el cual el sistema teleoperado se mantiene dentro de los límites de
operación definidos como normales a pesar de la presencia de perturbaciones en
el sistema.
Las causas más probables para que se produzcan inestabilidades son la existencia
de ruido eléctrico y los retardos en la comunicación entre el entorno local y el
entorno remoto, siendo el último el problema más grande en los sistemas
teleoperados ya que la información que se comparte entre la zona local y remota
no está actualizada.
Transparencia
Es una virtud del proceso de teleoperación mediante la cual el operador puede
sentir realimentación de fuerza del robot, es decir el operador puede sentir las
fuerzas que se ejercen en el robot durante el tiempo que lo comanda.
EVOLUCIÓN DE LA TELEOPERACIÓN [2]
La teleoperación inicia desde la necesidad del hombre de manipular herramientas
para realizar tareas difíciles o sin correr mucho peligro. Por ejemplo, al utilizar
tenazas se pueden manejar objetos calientes sin quemarse.
El origen de la teleoperación se remonta a los años 40 donde se vio la necesidad
de manejar elementos radioactivos de manera segura para el operador, ya que esta
es peligrosa si se maneja directamente. Las primeras soluciones mecánicas tenían
muchos inconvenientes como la restricción de movimientos que se podían realizar.
3
En 1947 se desarrollan en Estado Unidos investigaciones sobre sistemas de
telemanipulación para realizar tareas remotas en el Argonne National Laboratory.
En 1949 se desarrolla el primer sistema maestro-esclavo de un manipulador
mecánico.
En 1954 se presenta el primer sistema bilateral, que acopla dos bucles de control
uno para el operador y otro en la zona remota del robot, maestro-esclavo accionado
eléctricamente y con servomecanismos.
A partir de 1956 se desarrollan sistemas aplicables a prótesis humanas y para la
rehabilitación de enfermos.
Las aplicaciones a partir de los años 60 se extienden a submarinos que se usaban
para la exploración, búsqueda y rescate de restos.
La carrera por conquistar el espacio por los años 1965 llevo a desarrollar
investigaciones más profundas ante el problema del retardo en las comunicaciones
que creaba problemas de inestabilidad en reflexión de fuerzas.
En 1967 se logra el alunizaje y con ello se da la primera teleoperación hasta el
espacio realizando tareas de colección de piedras lunares.
Durante las décadas posteriores se desarrollaron avances más grandes en los
temas nuclear y submarino, especialmente; y así mismo la teleoperación se ha
extendido a varias otras ramas como la vigilancia, educación, construcción,
medicina, entretenimiento entre otras.
ELEMENTOS DE SISTEMAS TELEOPERADOS
Para poder teleoperar un sistema se necesita tres partes fundamentales, la estación
local, la estación remota y el canal de comunicación. En este punto se describe la
estación local y la estación remota; el canal de comunicación está detallado en la
sección 1.2.
4
El esquema básico para los sistemas teleoperados se muestran en la Figura 1.1
donde se pueden apreciar sus partes más importantes.
Figura 1.1 Diagrama de bloques de un sistema teleoperado [3]
Como se puede observar en la figura anterior, el sistema teleoperado consta de un
dispositivo maestro, ubicado en la estación local, y un dispositivo esclavo, ubicado
en la estación remota. El operador humano, ubicado en la zona local, comanda al
dispositivo maestro, mientras que el dispositivo esclavo, ubicado en el sitio remoto,
donde el operador no tiene acceso, reproduce las acciones del maestro.
En el sitio local donde se localiza el operador también debe existir una interfaz
destinada a mostrar la ejecución de la tarea por parte del esclavo en el sitio remoto.
Esta interfaz debe mostrar en monitores la realimentación visual, de fuerza y de
sensores desde el esclavo para mejorar la telepresencia del operador.
Estación Local
Lugar o entorno desde el cual se comanda y monitorea el robot físico o simulado a
distancia; usando Internet como medio de comunicación. La estación local debe
contar con dispositivos que le permitan al operador generar comandos, y también
con una interfaz de usuario, la cual permitirá la visualización de los datos enviados
hacia el robot y los datos obtenidos desde el robot. Sus elementos son:
· Operador humano: Es la persona, ubicada en el sitio local, que tiene a su
cargo manejar el robot esclavo, ubicado en el sitio remoto, usando la
información proveniente de los sensores del esclavo para tomar decisiones
y generar comandos que serán enviadas al robot esclavo.
5
· Interfaz: son todos aquellos equipos y dispositivos que permiten la
telepresencia al operador como realimentación de video, realimentación de
fuerza, sensores, etc.
Estación Remota
Es un sistema físico o simulado comandado y monitoreado desde la estación de
local usando como medio de comunicación el Internet. La estación remota adquiere
y procesa los datos recibidos de la estación local, con el objetivo de interactuar con
el entorno para desempeñar tareas concretas. Sus elementos son:
· Esclavo: es el dispositivo ubicado en el sitio remoto que ejecuta las acciones
y tareas deseadas por el operador humano
· Sensores: aquellos dispositivos que permiten recoger la información del sitio
local y del remoto para utilizarse al comandar desde la interfaz.
· Realimentación: datos visuales, odométricos, etc. obtenidos en la estación
remota que se refleja en la estación local y que sirven para que el operador
tome decisiones.
· Entorno: Es el lugar físico donde se desarrollarán las tareas del esclavo.
Canal de Comunicación
Son todos aquellos dispositivos que permiten el procesamiento, transmisión y
recepción de información desde el sitio local al sitio remoto y viceversa.
RETARDOS EN TELEOPERACIÓN [3]
En la teleoperación uno de los más grandes obstáculos es el retardo en la
comunicación que se presenta en el envío y recepción de datos entre el dispositivo
maestro y el dispositivo esclavo. Una gran desventaja del retardo en la
comunicación es que causa inestabilidad en el sistema teleoperado. El retardo en
la teleoperación se produce por diferentes causas, principalmente por:
· Retardo por protocolo de comunicación.
· Retardo por velocidad de transferencia de datos en la red.
6
Retardo por Protocolo de Comunicación
De forma general un protocolo cuenta con las siguientes características para su
funcionamiento:
Solicitud: Elemento que el usuario emite para solicitar algún servicio y proporcionar
los parámetros necesarios para especificar el servicio solicitado.
Indicación: Elemento que el proveedor del servicio emite para indicar que ha sido
invocado un procedimiento por el usuario del servicio par en la conexión y para
suministrar los parámetros asociados o que emite para notificar al usuario del
servicio una acción iniciada por el suministrador.
Respuesta: Elemento que el usuario del servicio emite para confirmar o completar
algún procedimiento invocado previamente mediante una indicación a ese usuario.
Confirmación: Elemento que el usuario del servicio emite para confirmar o
completar algún procedimiento iniciado previamente mediante una solicitud por
parte del usuario del servicio.
Los protocolos de comunicación de acuerdo con la velocidad a la que intercambian
datos entre dos usuarios se clasifican en: Protocolos Confiables y Protocolos No
Confiables.
Protocolos de Comunicación Confiables
Son los protocolos que luego de iniciar la transferencia de datos reciben una
confirmación de que el servicio solicitado ha tenido el efecto deseado en el otro
extremo. Como este protocolo necesita confirmación, el tiempo de transferencia de
datos es alto por lo cual se produce un retardo de tiempo.
Protocolos de Comunicación No Confiables
Son los protocolos que sólo invocan los elementos de solicitud e indicación, es
decir, que la entidad que inicia la transferencia de datos no recibe confirmación de
7
que la acción solicitada se haya ejecutado con éxito, por lo tanto, la transferencia
de datos es más rápida.
A continuación, en la Figura 1.2 se puede observar de mejor manera el
funcionamiento de cada protocolo.
Figura 1.2 Diagrama del funcionamiento de protocolos de comunicación confiables y
no confiables [4]
Retardo por Velocidad de Transferencia de Datos en la Red
En este tipo de retardo se tiene dos aspectos importantes:
El ancho de banda de la red
Determina la cantidad de datos que pueden ser transportados en un tiempo
determinado, en consecuencia, la velocidad de los mismos.
La cantidad de usuarios
La cantidad de usuarios que envíen información por una red magnifica el tráfico de
datos que exista en dicha red y, por lo tanto, generará un mayor retardo en la
comunicación.
8
La distancia física
Influye directamente sobre el retardo, a mayor distancia física se tiene un mayor
retardo, debido a que existen más dispositivos dentro del proceso de comunicación.
Las características de los dispositivos
Debido a que la velocidad del procesamiento de un dispositivo puede ser mayor
que otro.
SOFTWARE APLICABLE A INTERFACES
Una interfaz de usuario es el medio en el cual existe interacción hombre-máquina.
A través de la interfaz, el operador comanda y monitorea las diversas variables de
un sistema ubicado en la estación remota.
En la estación local es necesario hacer uso de una interfaz que permita ver las
acciones que se realiza sobre la estación remota, así como los parámetros de
respuesta que tiene esta.
Existen diversos programas sobre los cuales se puede desarrollar una interfaz de
usuario. Cada software posee uno o varios lenguajes de programación, también
diversos elementos que hacen que la interfaz sea visualmente agradable al ojo
humano. A continuación, se detalla las características y el funcionamiento de dos
programas que son ampliamente usados, siendo estos: Guide de Matlab y Visual
Studio.
Software Guide de Matlab [5]
GUIDE MATLAB es un software que se enfoca en el diseño de interfaces gráficas
de usuario, cuyo objetivo es permitir comandar y monitorear sistemas de una
manera sencilla. Se puede usar el lenguaje de programación o el uso de comandos
con el fin de ejercer una actividad determinada sobre el sistema.
En la Figura 1.3 el esquema en blanco de una Graphical User Interface GUI. Los
elementos que dispone GUIDE se basa en un panel principal al cual se le puede
9
agregar: barras de herramientas, botones, menús, controles deslizantes, entre
otros elementos para el diseño de la interfaz del usuario, o incluso la creación de
aplicaciones.
Figura 1.3 Esquema en blanco de una GUI de guide de Matlab [5]
Una vez creada la interfaz gráfica se genera automáticamente el código de la
interfaz en archivo “.m” para poder programar el comportamiento de la misma, es
decir, cada elemento puede realizar una actividad diferente dependiendo de la
lógica de su código.
Software Visual Studio [6]
Visual Studio es un software de entorno de desarrollo integrado que soporta
múltiples lenguajes de programación como: Visual C++, Visual C#, Visual F#,
Python, Visual Basic .NET (orientada a objetos), Java, Ruby, y programación con
entorno visual. Como entorno visual o gráfico proporciona una serie de
herramientas para el diseño de interfaces de usuario y aplicaciones web.
Dependiendo del lenguaje de programación que se escoja, en Visual Studio, se
obtendrá distintas características para la aplicación que se desee crear. En la
Figura 1.4 se observa un ejemplo de una interfaz creada en visual Studio.
10
Figura 1.4 Esquema de interfaz en Visual Studio [6]
Dentro de las herramientas se encuentran: botones, textos estáticos, textos
editables, paneles de control, barras deslizantes y otros. Además, cada elemento
puede ser programado con las funciones que se necesitan para la aplicación.
Para este proyecto se escogió Guide de Matlab para desarrollar la interfaz gráfica,
debido a que proporciona un sencillo manejo de sus elementos gráficos, así como
el lenguaje de programación, la velocidad del procesamiento de la información y
sobre todo por la facilidad de comunicación con el servidor, lo cual, en este caso es
indispensable para poder enviar y recibir datos a grandes distancias, haciendo uso
de Internet.
SISTEMAS DE REALIMENTACIÓN
Los sistemas de realimentación en teleoperación son indispensables ya que
proporcionan información sobre la estación remota y sobre el entorno en el que se
encuentra. Esta información sirve para hacer que el sistema sea más seguro. A
continuación, se expone los diferentes tipos de realimentación que son usados en
teleoperación.
Realimentación Háptica
El término “háptico” es amplio, y se usa para describir información táctil, así como
cinestésica (fuerza). Ambas son necesarias para reproducir la sensación que tiene
una mano humana al contacto con objetos [7]. La realimentación háptica en la
teleoperación proporciona información del robot que se está manipulando en la
estación remota. Generalmente en este tipo de realimentación se usa un joystick
11
como elemento de maniobra para el robot. Pero a diferencia de los joysticks
convencionales, el dispositivo puede devolver fuerzas a los operadores,
permitiendo así la sensación interactiva del proceso de manipulación. [8]
Para implementar una buena retroalimentación háptica, es necesario saber la
cantidad de fuerza que se aplica desde el aparato que está maniobrando sobre el
entorno en el que está funcionando. En general, hay dos maneras de adquirir esa
información. O bien se puede estimar las fuerzas aplicadas mediante la medición
de otros valores, como el ángulo y la corriente en las juntas, o se puede colocar un
sensor de fuerza en un lugar adecuado del maestro-esclavo. [9]
En el sistema teleoperado, el caso ideal sería cuando las fuerzas sentidas por el
operador humano son las mismas que las fuerzas aplicadas al ambiente esclavo.
En tal caso, el operador humano se sentirá como si estuviera manipulando el medio
ambiente directamente, y no sentirá la electrónica en absoluto; es decir, el sistema
es transparente. [9]
Figura 1.5 Figura de un sistema de teleoperación maestro-esclavo con realimentación
háptica [9]
En la Figura 1.5 se presenta como la realimentación háptica funciona. Como se
puede observar la ayuda de una realimentación visual es indispensable.
La realimentación háptica dentro de la teleoperación tiene diferentes aplicaciones,
como el manejo de materiales radioactivos, o en la medicina. La más destacable es
en la medicina, debido a que la exactitud y precisión es de extrema importancia.
Dentro del área de uso médico, hay muchos ambientes diferentes en los que el
12
manipulador robótico estará operando. En este campo ya se han realizado
intervenciones quirúrgicas usando esta tecnología.
Realimentación Visual
Dentro de la teleoperación los sistemas de realimentación visual son de gran
importancia porque sirven para la toma de decisiones sobre el robot móvil. A partir
de la información visual que proporciona el entorno del robot móvil se puede
resolver muchos problemas que limitan aplicaciones como: la exploración en
grandes profundidades, conducción automática, la robótica médica, los robots
aéreos, entre otros. [13]
La realimentación de video logra un mayor nivel de telepresencia, lo cual es muy
significativo para el comando del robot móvil, ubicado en la estación remota. Las
cámaras de diferentes tipos y algunos programas de software son usados para
llevar a cabo estos objetivos. Depende de la calidad visual de la realimentación de
video que sea o no más fácil reconocer el entorno del robot, sin embargo, la alta
calidad visual implica un mayor número de datos de video que transportar a la
estación local de operación, existiendo un mayor retardo en la comunicación [14].
Sin embargo, el retardo en la transmisión de video depende también del ancho de
banda en la comunicación que se asigne para transportar estos datos. Lo más
óptimo es usar un servidor para video, de esta forma el medio es exclusivo para los
datos de video, y así, los retardos disminuyen de forma considerable.
Figura 1.6 Ilustración que muestra como un operador humano maniobra un robot con
el uso de realimentación de video [15]
13
Cabe recalcar, que mientras más sistemas de realimentación existan en un robot
móvil, será más fácil para el operador humano poder comandar el mismo. En el
presente proyecto sólo se hará uso de realimentación de video para comandar el
robot móvil tipo carlike.
Realimentación Auditiva
El sonido puede transmitir un flujo continuo de información sobre el estado de un
sistema a un usuario u operador humano y así mejorar la interacción con el sistema.
Como ejemplo, se puede pensar en la experiencia común de conducir un coche
donde los sonidos continuos del motor, frenos, u otros pueden influir
constantemente en el comportamiento del conductor. Sin embargo, el uso del
sonido como información ha recibido poca atención en cuanto a las
implementaciones técnicas de la realimentación auditiva en las interfaces de
maniobra. La realimentación auditiva en teleoperación es usada para
complementar otro tipo de realimentación, como el caso de la visual, ya que la
realimentación auditiva permite una mejora del rendimiento del sistema incluso bajo
muy buenas condiciones de realimentación visual. [10]
Figura 1.7 Sistema de teleoperación que posee realimentación auditiva [11]
La información auditiva puede ser emparejada con la realimentación visual, por
ejemplo, para dirigir un robot humanoide que es comandado remotamente desde
una interfaz gráfica. Cada vez que el robot hace un paso, el usuario escucha la
14
realimentación auditiva que es síncrona o asincrónica con el movimiento del robot.
El uso reciente de este método encontró que los sonidos de pasos sincronizados
con la realimentación visual reducían el tiempo requerido para realizar la tarea de
caminar. [12]
1.2. COMUNICACIÓN DE DATOS APLICABLES A
TELEOPERACIÓN
Existen varios protocolos de comunicación que se usan para teleoperar un sistema.
Cada protocolo posee sus ventajas y desventajas. Además, es importante tomar en
cuenta las características del canal de comunicación que usa cada protocolo. A
continuación, se detalla primero los tipos de canales de comunicación que existen,
y sus características, posteriormente se presenta los protocolos de Internet que se
usan netamente para teleoperación.
CANALES DE COMUNICACIÓN [4]
En teleoperación el canal de comunicación es el medio por el cual se transporta la
información desde la estación local hacia la estación remota y viceversa, en este
proyecto el Internet. No todos los canales tienen la misma capacidad para transmitir
información. Se debe garantizar la estabilidad del canal de comunicación y en
consecuencia la estabilidad del sistema de teleoperación.
Canales Dedicados
Es un canal de comunicación que se usa específicamente para un propósito. Está
disponible a toda hora para su uso por un usuario designado. No comparte nada
con otros usuarios. La ventaja de estos canales es la velocidad de movilización de
datos y la privacidad que poseen. Este canal se da cuando existe conexión punto
a punto entre dispositivos.
15
Canales No Dedicados
Es un canal de comunicación por el que pasan varios paquetes de información a la
vez y es accesible para varios usuarios, un claro ejemplo es el Internet. Este canal
existe en la conexión multipunto de dispositivos.
No se debe usar un canal dedicado cuando se tiene los siguientes escenarios:
· Los dispositivos están muy alejados. En este caso no estaría justificado, por
ejemplo, utilizar un enlace dedicado entre dos dispositivos que puedan estar
separados por miles de kilómetros.
· Hay un conjunto de dispositivos que necesitan conectarse entre ellos en
instantes de tiempo diferentes. Un ejemplo de esta necesidad es la red de
teléfonos mundial o el conjunto de computadores pertenecientes a una
compañía. Salvo el caso de que el número de dispositivos sea pequeño, no
es práctico utilizar un enlace entre cada dos.
Con la justificación dada se concluye que en teleoperación es conveniente y se
debe usar un Canal de Comunicación No Dedicado, en este caso el Internet.
PROTOCOLOS APLICABLES EN INTERNET USADOS EN
TELEOPERACIÓN
Dentro de Internet existe un sin número de protocolos de comunicación que se usan
para el intercambio de información. Sin embargo, en teleoperación se hace uso de
un número reducido, debido a las características que poseen. A continuación, se
detalla varios protocolos usados en teleoperación.
Protocolo de Transferencia de Hipertexto HTTP [4]
El Protocolo de transferencia de hipertexto (HTTP) es el protocolo que se usa la
World Wide Web (WWW) y puede ser utilizado en cualquier aplicación con
arquitectura cliente/servidor que implique hipertexto. HTTP en realidad no es un
protocolo para la transferencia de hipertexto, sino que es un protocolo para
transferir información con la eficiencia necesaria para realizar saltos de hipertexto.
16
El tipo de datos que pueden ser transmitidos por este protocolo son texto claro,
hipertexto, audio, imágenes o cualquier información accesible por Internet.
El uso más típico del protocolo HTTP es que soporta el intercambio de información
entre buscadores web y servidores web. HTTP utiliza el modelo de comunicación
solicitud/respuesta. Además, es un protocolo ‘sin estado’, debido a que no guarda
información de conexiones anteriores, es decir, cada conexión se trata de forma
independiente, una vez terminada la transferencia de datos la conexión se da por
finalizada.
Una característica importante del protocolo HTTP es que es tolerable a varios
formatos, es decir, cuando un cliente envía solicitud a un servidor, puede incorporar
una lista de formatos preferidos que pueda manejar y el servidor responde con el
formato que sea más apropiado. Por ejemplo, si un navegador no puede manejar
imágenes, el servidor web no transmitirá ninguna imagen en las páginas web. Esta
medida permite que sólo se transmita información netamente necesaria.
Figura 1.8 Operación del protocolo HTTP [4]
En la Figura 1.8 se observa el modo de funcionamiento del protocolo HTTP. El
cliente realiza una solicitud al servidor y este le envía una respuesta. La conexión
existente entre ambos es TCP (Protocolo de Control de Transmisión), siendo TCP
uno de los protocolos fundamentales de Internet.
Protocolo de Transporte en Tiempo Real RTP [4]
Este protocolo, como su nombre lo dice, sirve para transmitir en tiempo real datos
multimedia. Aunque cada aplicación en tiempo real podría incluir sus propios
mecanismos para soportar el transporte en tiempo real, hay una serie de
características que justifican la definición de un protocolo común. Un protocolo
diseñado para este propósito es el protocolo de transporte en tiempo real (RTP).
17
RTP no garantiza en sí la transmisión en tiempo real de los datos multimedia, ya
que eso depende netamente de la red, pero si proporciona los medios necesarios
para administrar los datos a medida que llegan de manera rápida y eficaz. RTP
generalmente funciona sobre el protocolo UDP (Protocolo de Datagrama del
Usuario), pero también puede usar otros protocolos como el SIP (Protocolo de Inicio
de Sesión).
Protocolo MQTT (Message Queue Telemetry Transport) [16]
MQTT es un protocolo de comunicación con arquitectura publicador/suscriptor. Se
caracteriza por ser simple y ligero en el transporte de datos, diseñado para
dispositivos restringidos y redes de bajo ancho de banda, de alta latencia o poco
fiables. Los principios de diseño son minimizar el ancho de banda de la red y los
requerimientos de recursos del dispositivo, a la vez que intenta asegurar la fiabilidad
y cierto grado de seguridad en la entrega. Estos principios también se convierten
en el protocolo ideal de la emergente “máquina a máquina” (M2M) o “Internet de las
cosas”, mundo de dispositivos conectados, y para aplicaciones móviles donde el
ancho de banda y la energía de la batería son muy importantes.
Protocolo Websockets [17]
Es un protocolo de comunicación que proporciona una sesión de comunicación
interactiva entre el navegador de usuario y un servidor, se puede usar en
aplicaciones con arquitectura cliente/servidor. Con este protocolo se puede enviar
mensajes al servidor y recibir respuestas controladas por eventos sin necesidad de
consultar al servidor por una respuesta, debido a que posee un canal de
comunicación bidireccional y full dúplex.
Con las aplicaciones tradicionales de Internet, como la transferencia de archivos, el
correo electrónico y las aplicaciones cliente / servidor, incluyendo la Web, las
métricas de rendimiento de interés son generalmente el rendimiento y el retardo.
También hay una preocupación con la fiabilidad, y se utilizan mecanismos para
asegurarse de que los datos no se pierdan, se dañen o se maltratan durante el
tránsito. Por el contrario, las aplicaciones en tiempo real se preocupan más por los
18
problemas de tiempo. En la mayoría de los casos, existe el requisito de que los
datos sean entregados a una tasa constante igual a la tasa de envío. En otros
casos, se asocia un plazo a cada bloque de datos, de manera que los datos no se
pueden utilizar después de que expire el plazo.
ARQUITECTURA DEL PROTOCOLO DE COMUNICACIÓN MQTT
Para este proyecto se escogió el protocolo de comunicación MQTT, porque posee
la rapidez para la transmisión de datos, y ha tenido gran desarrollo en tarjetas
embebidas. La mayor parte de información de este protocolo se encontró en el
proyecto de titulación [18]. El protocolo MQTT trabaja con arquitectura publicador /
suscriptor, la cual, se explica en el siguiente punto.
Arquitectura Publicador / Suscriptor
En la arquitectura de comunicación, mostrada en la Figura 1.9,
publicador/suscriptor cualquier participante puede tener el papel de publicador o de
suscriptor. El agente publicador produce varios paquetes de datos de información
denominados “tópicos”. El suscriptor es el agente que consume los tópicos.
Figura 1.9 Arquitectura de comunicación publicador / suscriptor
La principal característica de esta arquitectura de comunicación es la forma en que
los tópicos viajan desde el publicador hasta el suscriptor; el suscriptor no está
directamente dirigido al publicador, si no que indirectamente se direcciona
dependiendo del contenido de cada tópico. Es decir, el suscriptor sólo toma los
tópicos a los cuales está suscrito. Además, el suscriptor no anula sus actividades
mientras espera la notificación del tópico.
19
Para evitar que el publicador conozca todas las suscripciones de cada suscriptor,
en el proceso de propagación de información desde el publicador hasta el suscriptor
se coloca un mediador. Este mediador es un “Servidor de Datos”. [19]
El Servidor de Datos es el único medio por el cual el publicador y suscriptor se
comunican. El servidor de datos debe:
· Almacenar todas las suscripciones de cada suscriptor.
· Recibe y almacena los tópicos del publicador, para que los suscriptores
puedan adquirirlos.
SERVIDOR DE DATOS O BRÓKER
El servidor de datos o bróker con el que trabaja el protocolo de comunicación MQTT
es “Eclipse Mosquitto”. Eclipse Mosquitto es un bróker de mensajería de código
abierto (EPL) que implementa las versiones 3.1 y 3.1.1 del protocolo MQTT,
proporciona un método ligero de realizar mensajes usando un modelo de publicador
/ suscriptor. Esto lo hace adecuado para el "Internet de las cosas" de mensajería,
como con sensores de baja potencia o dispositivos móviles como teléfonos,
ordenadores integrados o microcontroladores como el Arduino [20].
1.3. ROBOT MÓVIL
Un robot móvil es una máquina capaz de desplazarse por un entorno físico que
puede ser aéreo, acuático o terrestre de manera autónoma o con cierto nivel de
intervención humana que le guía o da instrucciones.
La diferencia con los robots estáticos como los manipuladores es que estos últimos
se encuentra siempre fijos en la misma ubicación.
CLASIFICACIÓN DE LOS ROBOTS MÓVILES
Existen muchas formas de clasificar los robots, en este caso según el entorno en el
cual trabajan se clasifican en: robots aéreos, robots acuáticos y robots terrestres.
En este proyecto se trabaja con un robot terrestre.
20
Los robots terrestres son el tipo de robots sobre los que más se ha investigado, se
clasifican principalmente por el mecanismo que usan para desplazarse, véase
Figura 1.10.
Clasificación de Robots Terrestres
Robots con Patas Robots con Cintas de Desplazamiento Robots con Ruedas
Triciclo Clásico
Direccionamiento Diferencial
Skid Steer
Síncronas
Ackerman o Carlike
Figura 1.10 Clasificación de los robots terrestres
· Robots con patas: Son robots diseñados para terrenos irregulares y su
diseño se asemeja a la fisiología de animales como los insectos y su
movimiento puede dirigirse casi en cualquier dirección.
· Robots con cintas de desplazamiento o tipo oruga: Son robots que usan una
cinta incorporada en cada lado del robot para el desplazamiento similar a un
tanque de guerra. Son muy útiles para movilizarse en terrenos irregulares
· Robots con ruedas: Son los robots más populares que existen, son fáciles
de construir, mecánicamente hablando, y de maniobrar. No son muy útiles
en terrenos irregulares.
Los robots con ruedas a su vez se clasifican en:
· Triciclo clásico: El modelo de este tipo de robot emplea dos ruedas traseras
que proveen de tracción al robot y una delantera para la dirección del mismo.
· Direccionamiento diferencial: En este modelo se usan dos ruedas acopladas
a un motor independiente y una o dos ruedas para usarlas como soporte.
21
Para girar al robot basta con que una de las ruedas gire más rápido que la
otra.
· Skid steer: Este tipo de robots tiene varias ruedas en cada lado, que trabajan
coordinadamente para darle movimiento al vehículo y darle dirección.
· Síncronas. Es un robot compuesto por tres ruedas cada una acoplada a un
motor, la actuación simultánea de las tres ruedas permite la locomoción del
mismo.
· Ackerman o carlike: Su modelo se parece a los automóviles convencionales
y es el robot que se usará en este proyecto. Su descripción se detalla en el
punto 1.3.2.
ROBOT MÓVIL TIPO CARLIKE.
El robot móvil tipo carlike se ha seleccionado en el presente proyecto como robot a
comandar debido a que es un robot muy común, a su facilidad de implementación
y a las características de estabilidad que presenta.
Este robot es utilizado en vehículos de cuatro ruedas convencionales como se
muestra en la Figura 1.11. De hecho, los vehículos robóticos para exteriores
resultan normalmente la modificación de vehículos convencionales tales como
automóviles o incluso vehículos más pesados. [24]
Figura 1.11 Robot urbano RBCAR [25]
Este robot móvil posee restricciones holonómicas ya que por su diseño solo puede
moverse adelante o hacia atrás y girar su ángulo de direccionamiento. Al poseer
ruedas el carlike puede moverse por terrenos con rugosidad baja.
22
Tracción
El robot dispone de un motor acoplado al eje que une las llantas traseras, el
accionar de este motor le proporciona de movimiento hacia adelante o hacia atrás
al robot.
El motor acoplado al eje deberá cumplir con las necesidades del vehículo como el
torque suficiente para mover al robot y la carga útil que ha de cargar encima, así
mismo con la velocidad necesaria para realizar las tareas especificadas.
Direccionamiento Ackerman
El mecanismo para realizar el direccionamiento se muestra en la Figura 1.12.
Figura 1.12 Sistema Ackerman [24]
En algunos casos, se usan las ruedas traseras para el direccionamiento, pero no
son mecanismos comunes en este tipo de robots.
Las ruedas delanteras son las que proveen de la dirección del robot, por esta misma
razón no deben estar conectadas al mismo eje ya que al curvar los radios de
curvatura de las llantas no son los mismos y se producen deslizamientos que
afectan al desgaste de las llantas y también se dificulta tomar las curvas.
Por la razón anterior las ruedas delanteras no van unidas al mismo eje y giran a
diferentes velocidades según el radio de curvatura y la rueda externa a la curva
girará más rápido que la rueda interna.
23
En el mecanismo presentado en la figura anterior, la rueda interior gira un ángulo
un poco mayor a la rueda exterior para eliminar los deslizamientos laterales. Las
proyecciones de los ejes de las ruedas delanteras se cortan en un punto, denotado
en la Figura 1.12 como P, con el eje de proyección de las ruedas traseras. [24]
Modelo Cinemático del Robot
Las ecuaciones que describen el modelo cinemático simplificado del robot móvil
tipo carlike son las que se muestran a continuación:
!" =#($) tan%($)
&!
! !(1.1)!
'" = #($) cos !($)! (1.2)!
*" = #($) sin !($)! (1.3)!
Donde:
!($), es la orientación del robot respecto del eje x.
%($), es la dirección de las llantas delanteras.
#($), es la velocidad lineal del robot.
'" , es la razón de cambio de posición en el eje x.
*" , es la razón de cambio de posición en el eje y.
Equilibrio mecánico
Dado el diseño del robot con 4 ruedas, este presenta mayor estabilidad respecto a
de modelos como el triciclo de 3 llantas en cuanto a tomar curvas y a terrenos
irregulares.
24
Todo el peso que ha de soportar la estructura debe distribuirse de manera que el
centro de masa coincida con el centro geométrico para lograr mayor estabilidad en
curvas. Este peso normalmente se distribuye uniformemente extendiéndolo por la
parte izquierda y derecha del robot.
Aplicaciones
Dado que su funcionamiento es muy similar a un auto real, las aplicaciones de este
tipo de robots son de las más variadas y abarcan campos domésticos, agro
industriales, industriales, exploración, etc.
Su uso también se enfoca en el reconocimiento y mapeo de zonas no exploradas,
así como para transporte de objeto pesados en hospitales, puertos y almacenes.
1.4. SINGLE BOARD COMPUTER (SBC)
Es una placa base que contiene todos los elementos necesarios para realizar tareas
de computadora como un microprocesador, memoria física, memoria RAM,
periféricos de entrada y salida, etc.
Las SBC presentan altos rendimientos y sus aplicaciones se han extendido en
varias áreas como el entretenimiento, sistemas de navegación, dispositivos
médicos para monitoreo de pacientes, dispositivos industriales de ensayo y
medición, visión industrial, etc. Esto gracias a que muchas de estas tarjetas
embebidas cuentan con puertos USB, Ethernet, Cámara, Audio, pantalla touch, S-
Video, WiFi, Bluethoot, etc.
Estas pequeñas computadoras han empezado su revolución tecnológica poniendo
al alcance de la mano una potencialidad muy alta en el desarrollo e implementación
de las más variadas ideas. Las SBC han servido también en el ámbito educacional
como herramientas de bajo coste para transmitir conceptos informáticos a los más
jóvenes.
25
MODELOS COMERCIALES
Desde la primera SBC, que fue la Raspberry Pi, estas han ganado mucha
aceptación en el mercado de las tarjetas embebidas. A continuación, se presentan
algunas de las SBC más populares y que han ganado su puesto en el mercado.
Raspberry Pi
Fue desarrollado por la fundación Raspberry Pi para promover una forma simple y
barata de enseñar computación en escuelas. Tiene el tamaño de una tarjeta de
crédito y se ha convertido en la base de varios proyectos DIY (do it yourself) para
aplicaciones PC móviles. Incluyen proyectos como transmisión multimedia, paneles
de visualización, dispositivos para sensar ambientes, etc.
La Raspberry Pi 3 se basa en un SoC (system on a chip) Broadcom BCM2835
equipado con un procesador ARM11767JZF-S de 70 MHz, posee una memoria
RAM de 512 MB, dos puertos USB, un puerto ethernet y 40 pines GPIO. El núcleo
de video permite reproducción de video en alta definición, la interface I2C permite
expansiones en el dispositivo y una tarjeta SD se proporciona para el arranque y
almacenamiento de memoria. La tarjeta soporta sistemas operativos de Linux como
Debian Linux y sus derivados Raspbian OS siendo los más populares. [26]
Beaglebone Black
Es una plataforma de bajo costo para la comunidad de desarrolladores y
aficionados. Tiene una memoria RAM de 512 MB, una memoria de almacenamiento
de 4GB, un acelerador de gráficos 3D, 2 microcontroladores PRU de 32 bits y 72
pines GPIO. Tiene compatibilidad con sistemas operativos como debían, Android,
Ubuntu, Cloud 9, etc. [27]
El Beaglebone, es una SBC desarrollada por Texas Instruments. Contiene un
procesador AM335x ARM Cortex-A8, La Beaglebone pretende ofrecer a los
desarrolladores una solución rentable para aplicaciones que necesitan módulos de
expansión. Esta tarjeta necesita una tarjeta SD para arrancar el sistema operativo
y para almacenamiento externo. Incluye HDMI, ethernet, puertos usb 2.0 EterCAT
26
y profibus. Además, presenta respaldo de información, adquisición de datos,
módulos de robótica, etc. [28]
Udoo
Es una familia de las SBC diseñada para ser usada como una mini PC y como una
tarjeta embebida por aficionador y desarrolladores de proyectos DIY.
Este dispositivo, fue diseñado para educadores y desarrolladores. Tiene el poder
de 4 Raspberry Pi y un arduino DUE. Es una de las tarjetas más impresionantes
desarrolladas hasta la fecha. La UDOO lleva un CPU ARM i.MX6 de 1 GHz y
también un CPU ARM Cortex-MR SAM3X8E. Contiene tres aceleradores gráficos
para 2D, OpenVG e incluye 1GB de memoria RAM DDR3. En total posee 54 pines
digitales de entrada y salida, entradas analógicas compatibles con arduino, HDMI
y salida de audio LVDS, módulos WiFi y ethernet, puertos mini USB, dos puertos
USB tipo A, audio analógico, conexión para cámara, alimentación de 5 a 12 voltios
con adaptador a 2ª y micro SD para arrancar el dispositivo. [28]
1.5. PLATAFORMAS DE REALIDAD VIRTUAL
El presente proyecto tiene como alcance también el desarrollo de un modelo
simulado de un carlike, para esto necesitamos una plataforma de realidad virtual
entre las cuales destacamos los programas V-REP y Unity 3D. A continuación, se
detallan las características más importantes de cada uno.
V-REP [29]
Es un programa que se usa en varias ramas como la educación en robótica, y en
la industria para hacer prototipos de robots y simulaciones de automatización. Cada
modelo disponible en la plataforma se programa con scripts, nodos ROS, clientes
API, entre otros que hacen que V-REP sea ideal para control de múltiples robots.
Algunas de las prestaciones más importantes que ofrece esta plataforma de
simulación de robots según la página oficial de V-REP son:
27
· Plataforma cruzada y portátil: el contenido de las escenas y los códigos
puede transportarse fácilmente.
· 7 lenguajes de programación: soporta lenguajes de programación como
Python, Matlab, Octave, Lua, Urbi, ROS, C++.
· API Remota: V-REP presenta la posibilidad de poder controlar la simulación
desde un robot o desde una PC de manera remota, Optimiza la
comunicación para datos pesados y minimiza los retardos.
· Dinámica y física: V-REP presenta 4 motores para la física, Bullet Physics,
ODE, Newton y Vortex Dynamics para cálculos dinámicos y físicos de
interacciones entre objetos.
· Cinemática inversa: V-REP tiene una versión de IK/FK para cálculos de
cinemática inversa.
· Detección de colisiones
· Sensores de proximidad: Realiza un cálculo de la distancia entre objetos de
manera muy exacta.
· Sensores de visión: Realiza procesamiento de imágenes personalizables.
· Bloques de construcción: se pueden enlazar bloques que pueden ser robots,
sensores, objetos usando scripts
· Trayectorias o movimientos: V-REP usa un complemento OMPL.
· Grabación y visualización de datos: puede usarse un gran flujo de datos para
combinarse entre sí y generar gráficos personalizados.
· Interfaces personalizadas de usuario: existen muchos elementos disponibles
para poder realizar HMI.
· Importación y exportación de datos.
· Navegación de modelos: permite fácilmente usar modelos predefinidos
arrastrándolos y soltándolos.
· Versiones gratuitas: existen licencias para productos de prueba para
estudiantes y profesores.
28
UNITY 3D
Es un motor gráfico 3D ampliamente usado en la industria del desarrollo de juegos
por la calidad, velocidad y eficacia de sus flujos de trabajo permitiendo producir
contenido de alta gama.
Unity permite obtener muchas extensiones, muchas de ellas gratuitas y otras a un
costo en la Unity Asset Store para poder ampliar las aplicaciones.
El ambiente visual que se observa en Unity 3D es bastante real, incluyendo
iluminación solar y de fuentes luminosas, espacios con poca luz, etc. El sonido y la
iluminación son excelentes para crear juegos dinámicos.
Los compiladores de juegos son muy rápidos permitiendo pre visualizar el ambiente
diseñado para poder corregir fallos.
Según la página oficial de Unity 3D algunas de las características más importantes
son las que se presentan a continuación: [30]
· Animación: las animaciones pueden tener retargeting, se pueden invocar a
eventos dentro de la animación, se maneja el estado de la máquina
manejando las transiciones sofisticadas.
· Gráficos: iluminación global, sombreado basado en la física, sondas de
reflexión, herramientas UI intuitivas.
· Optimización: Unity 3D cuenta con memorias avanzadas, paquetes activos,
soporte a nivel de detalle y sistema de trabajo en multihilos.
· Audio: mezclado y masterizado en tiempo real, presenta jerarquías de
mezcladores, instantáneas y efectos predefinidos.
· Física 2D y 3D: contiene un modelo de Box2D con efectores, articulaciones
y colliders, además de una librería NVIDIA PhysX 3.3
· Scripting: Unity 3D soporta lenguajes de programación como C# y
JavaScript, tiene una integración nativa con visual Studio y tiene
prestaciones con path finding y mallas de navegación.
29
Para este proyecto se utilizó Unity 3D para el desarrollo del carlike simulado debido
a que es un entorno potente y amigable, la programación del entorno es sencilla,
permite crear ejecutables del proyecto y tiene librerías de C# para crear clientes
MQTT necesarios para la comunicación de datos, lo cual es un requerimiento
indispensable para este proyecto.
30
CAPÍTULO 2
DISEÑO E IMPLEMENTACIÓN DEL HARDWARE DEL
ROBOT MÓVIL TIPO CARLIKE.
En este capítulo se presenta el diseño del hardware, tanto mecánico como
electrónico, del robot móvil tipo carlike, también se detallan los componentes afines
a la estación local, al servidor de datos y a la estación remota.
2.1. ARQUITECTURA DEL SISTEMA
La arquitectura del sistema de teleoperación está constituido por: la estación local,
un servidor de datos, y una estación remota, la cual puede ser el carlike físico o
el carlike simulado. En la Figura 2.1 se especifica cada uno de los elementos que
componen la estación local, el servidor de datos, y la estación remota.
Figura 2.1 Arquitectura general del sistema
31
ESTACIÓN LOCAL
En la estación local se encuentra el operador humano, quien haciendo uso de un
joystick tipo volante conectado a una PC, pueda comandar el robot móvil tipo
carlike. La PC posee una interfaz gráfica que muestra los datos enviados por el
operador y los datos recibidos desde el robot móvil.
Figura 2.2 Estación local de operación ubicada en Latacunga.
En la Figura 2.2 se observa al operador en la estación local, ubicada en Latacunga.
El operador observa la ubicación del robot móvil simulado haciendo uso de
TeamViewer.
SERVIDOR DE DATOS O BRÓKER
El servidor de datos se usa para receptar, almacenar y enviar datos. Este servidor
está montado en una computadora ubicada en el edificio de Química/Eléctrica
Q/E en el aula 708. Como se puede ver en la Figura 2.3, el servidor de datos está
activado listo para usarse.
Figura 2.3 Servidor de datos ubicado en el edificio Q/E, aula 708.
El servidor de datos es el dispositivo intermedio para la comunicación entre la
estación local y la estación remota.
32
ESTACIÓN REMOTA
La estación remota hace referencia al robot móvil tipo carlike físico o simulado.
Estación Remota: Carlike Físico
La estación remota para el caso del robot móvil físico cuenta con una tarjeta
Raspberry Pi 3B que actúa como eje central de este, debido a que ejecuta todos
los comandos recibidos y se encarga de la comunicación; existe también una
cámara IP, la cual se encarga de proporcionar al operador realimentación visual del
entorno en donde se encuentra el robot móvil; se cuenta con sensores y actuadores
que funcionan de acuerdo con las instrucciones recibidas por parte de la tarjeta.
Figura 2.4 Robot móvil carlike físico ubicado en la Escuela Politécnica Nacional.
Por último, se menciona que el robot móvil físico puede ser usado sólo en el séptimo
piso del edificio de Química-Eléctrica Q/E y en el laboratorio de Robótica ubicado
en el EARME, esto es debido a que, para que la cámara funcione debe estar
agregada en una red con acceso a internet, esta red a cuál se encuentra agregada
la cámara IP solo está habilitada en estos dos puntos.
Estación Remota: Carlike Simulado
La estación remota para el caso del robot móvil simulado se desarrolla en un
entorno virtual, por lo que se necesita una PC para ejecutarlo, la realimentación
visual de esta simulación se obtiene a través de TeamViewer. En la Figura 2.5 se
observa el carlike simulado desarrollado en un entorno virtual.
33
Figura 2.5 Robot móvil carlike simulado ubicado en la Escuela Politécnica Nacional.
Cabe mencionar que TeamViewer debe estar instalado tanto en la estación local,
como en la estación remota.
2.2. HARDWARE DE LA ESTACIÓN LOCAL
En la estación de operación se generan todos los comandos que serán enviados
hacia los modelos físico y simulado del carlike. Para generar las mismas el operador
hace uso de un Joystick tipo volante y un par de pedales. A continuación, se detallan
las características más importantes de los mismos.
CARACTERÍSTICAS DE LA PC U ORDENADOR
El ordenador que está ubicado en la estación local debe cumplir con los siguientes
requerimientos para el correcto funcionamiento del sistema:
· Tener instalado sistema operativo Windows 7 en adelante.
· Tener instalado Matlab 2016a.
· Matlab2016a debe contar con el driver para ARDUINO “Acquire inputs and
send outputs on Arduino boards”. Este driver se lo encuentra en la pestaña
Add-Ons en “Get Hardware Support Packages”.
Figura 2.6 Driver de arduino
34
· Tener instalado “TeamViewer”
· Acceso permanente a Internet. Lo recomendable es que la PC se encuentre
conectada a un punto de red, para disminuir los retardos de transferencia de
datos y video.
JOYSTICK TIPO VOLANTE Y PEDALES
El Joystick tipo volante y los pedales son dispositivos que se conectan a la PC u
ordenador para que el operador pueda generar señales de comando, lo cual,
permite una interacción entre el software y el usuario. El Joystick y los pedales son
parte de la estación local y se pueden ver en la Figura 2.7. Estos dispositivos
adquieren señales analógicas y digitales, la cuales son enviadas a la PC por medio
de cables USB.
Figura 2.7 Joystick tipo volante
El Volante posee una palanca que genera dos valores 0 o 1 lógico, cada valor es
una variable, las cuales se usaron para determinar la dirección adelante o atrás del
robot móvil. El ángulo de giro está dado por el valor analógico que envía el mando
de dirección, este valor varía entre -1 y 1.
Internamente los pedales tanto izquierdo como derecho poseen un potenciómetro,
el valor de resistencia de cada potenciómetro varía de acuerdo con que tan
presionado está el pedal. Para poder adquirir las señales de dichos potenciómetros
y enviarlas al PC se debe usar una tarjeta exclusiva para este fin, la misma que
estará localizada dentro de los pedales. En la Tabla 2.1 se muestran los
requerimientos necesarios para escoger la tarjeta.
35
Tabla 2.1 Requerimientos necesarios para tarjeta para los pedales.
Requerimientos Detalle
Entradas Analógicas Necesarias 2
Tamaño 6x6 centímetros [cm]
Compatibilidad con Matlab Drivers para Matlab
Se escogió una tarjeta ARDUINO UNO debido a que cumple con los requerimientos
necesarios. Arduino UNO es un microcontrolador basado en el ATmega328P, ver
Figura 2.8. Las características de esta tarjeta se observan en la Tabla 2.2 [31].
Tabla 2.2 Características de la tarjeta Arduino UNO [31]
Característica Descripción
Alimentación 5 Voltios DC [V]
Entradas / Salidas digitales 14 Pines
Entradas analógicas 6 Pines
Salidas PWM 6 Pines
Figura 2.8 Tarjeta Arduino UNO [31]
Las entradas analógicas A0 y A1 son usadas para tomar la señal de los
potenciómetros colocados en los pedales. Dependiendo de la presión ejercida
sobre cada pedal, se obtiene una señal analógica entre 0 – 5 Voltios [V]. Siendo 0
voltios [V] cuando el pedal no se encuentra y 5 voltios [V] cuando el pedal se
encuentra totalmente presionado.
2.3. HARDWARE DEL SERVIDOR DE DATOS O BRÓKER
El servidor de datos se encuentra en una PC ubicada en la unidad de
mantenimiento electrónico UME. Los requerimientos de esta PC son:
36
· Estar conectada a un punto de red.
· Tener asignada una dirección IP Pública, en este caso es “190.96.111.128”.
· Tener instalado “Eclipse Mosquitto”.
2.4. HARDWARE DE LA ESTACIÓN REMOTA: CARLIKE FÍSICO
El diseño del sistema mecánico del robot móvil se realiza en base al modelo
Ackerman, es decir, se usa el diseño de un carro convencional de cuatro ruedas,
dos delanteras para la dirección y dos traseras para la tracción. El modelo
Ackerman está explicado a detalle en el Capítulo 1. Para este proyecto se
seleccionó un auto de juguete que cumpla con las características del modelo
mencionado, y al cual se acopló los componentes necesarios para su funcionalidad.
ESTRUCTURA MECÁNICA
La estructura de la plataforma móvil consta de una base con cuatro ruedas. Las
ruedas traseras están acopladas a un mismo eje el cual gira gracias a que tiene
encajado un motor, mientras que las delanteras se adaptan a un mecanismo que
se mueve por un servomotor, el cual hace girar las ruedas hacia el lado izquierdo o
derecho, con un ángulo determinado. Las llantas de dirección no se acoplan en un
mismo eje, de tal forma que el movimiento de la una es independiente de la otra.
Ruedas
Desempeñan un papel fundamental en el desplazamiento del robot móvil, debido a
que deben proporcionar un correcto movimiento, es decir, rotar sin resbalar. En el
eje de tracción y de dirección se usó el mismo tipo de ruedas cuyas características
se muestran en la Tabla 2.3 y el modelo de la rueda se observa en la Figura 2.9.
Tabla 2.3 Características de las ruedas del carlike
Característica Descripción
Diámetro 66 milímetros [mm]
Ancho 40 milímetros [mm]
Material Caucho
37
Figura 2.9 Modelo de rueda del Carlike
Base
La base del robot móvil debe ofrecer el espacio necesario para la distribución de
todos los componentes: tarjeta embebida, sistema de alimentación, cámara IP,
sensores y actuadores. Además, soportar la carga que estos elementos conllevan.
En la Tabla 2.4 se encuentran las dimensiones de la base, y en la Figura 2.10 se
presenta la vista inferior y superior con las ruedas ya acopladas.
Tabla 2.4 Características de la base del carlike
Característica Descripción
Longitud (d2): longitud de la base. 170 milímetros [mm]
Ancho máximo (d1): ancho de la base. 80 milímetros [mm]
Material Plástico
Distancia entre ruedas traseras (b) 130 milímetros [mm]
Distancia entre ruedas delanteras (a) 128 milímetros [mm]
a) Vista inferior b) Vista superior
Figura 2.10 Vista inferior y superior de la base del Carlike
En la Figura 2.10 a) se muestran las dimensiones de la base del carlike físico.
38
ACOPLES MECÁNICOS PARA MOTORES DEL CARLIKE
Los acoples mecánicos se seleccionaron tomando en cuenta el torque necesario
de 3 kilogramos por centímetro [kg.cm] para que el carlike pueda desplazarse sin
ningún inconveniente.
Acoples Para la Tracción
El motor de tracción se acopla al eje mediante un juego de engranajes como se
puede apreciar en la Figura 2.11. Este motor es un micromotor de relación 250:1,
como se detalló anteriormente en la sección 2.3.2.1. Por lo tanto, usando la
ecuación (2.1), la relación de transformación en la caja de engranajes del motor es:
+,- =1
250!
(2.1)!
Al ser +,- una relación de transformación propia en la caja de engranajes del
micromotor, sólo se tiene en cuenta la velocidad en el eje del motor, la cual es de
120 revoluciones por minuto (RPM) sin carga.
En la Figura 2.11 se aprecia el acople de los dos engranajes que se usa en la
tracción del robot móvil. El engranaje 1 posee 28 dientes y el engranaje 2 posee 32
dientes.
Figura 2.11 Acople de engranajes en el eje de tracción
Con estos datos y, usando la ecuación (2.9), la relación de transmisión entre el
engranaje 1 y el engranaje 2 es:
39
+,. =28
32//!
(2.2)!
+,. =7
8!
(2.3)!
La velocidad final que existe en las llantas es la velocidad proporcionada por el
engranaje 2 representada por 4., la cual se calcula de la siguiente manera:
+, =4.
4-=6-
6.!
(2.4)!
Donde 4- = 120/+9: es la velocidad angular del primer engranaje (en el eje del
motor).
4.
120=28
32!
(2.5)!
4. =(120)(28)
32!
(2.6)!
4. = 105/+9:! (2.7)!
Por lo tanto, la velocidad en las ruedas traseras es menor a la velocidad del eje del
motor 4. < 4-. Sin embargo, debido a que existen solo dos engranajes, la
velocidad en la salida no disminuye mucho en comparación a la velocidad
proporcionada por el micromotor. A continuación, en la Figura 2.12 se observa la
caja de tracción cerrada, la cual se coloca en la parte trasera del robot móvil.
Figura 2.12 Vista de la caja de tracción
40
Acoples Para la Dirección
En la Figura 2.13 se puede observar el eje de dirección del carlike. Este eje posee
una barra que conecta las dos ruedas, ambas desmontables, esta barra se mueve
de lado a lado para direccionar las llantas según la indicación del servomotor. El
ángulo máximo de giro del eje de las llantas es de 20 grados [°] a cada lado.
Figura 2.13 Acople para el motor de dirección
Además, en la parte central del eje de dirección existe una brecha que sirve para
acoplar el eje del servomotor. El servomotor es desmontable de la brecha, pero a
la vez proporciona un ajuste exacto para que no existan problemas en la dirección.
SELECCIÓN DE MOTOR DE TRACCIÓN [32]
La selección del motor de tracción se realiza dependiendo de la carga, en
kilogramos [kg], que tenga que llevar el robot móvil. Esta carga tiene un valor de 3
kilogramos [kg] y dentro de la cual están considerados: placa del sistema, sistema
de alimentación, tarjeta embebida, sensores, actuadores y la estructura propia del
robot móvil. Considerando estas características se seleccionó un micromotor 250:1
marca pololu, que se muestra en la Figura 2.14.
El micromotor es un sistema de fuerza motriz completo que consta de: un motor
eléctrico y una caja reductora. Esta estructura hace que se produzca un torque alto
a velocidad baja. La caja reductora contiene un sistema de engranajes y está
diseñada para reducir la velocidad al aumentar el torque, debido a que existe una
relación inversamente proporcional entre el torque y la velocidad. Para lograr un
alto torque se debe tomar en cuenta la relación de transmisión que tiene la caja de
engranajes del motor.
41
Figura 2.14 Estructura del micromotor [32]
Relación de Transmisión: La relación de transmisión hace referencia a la relación
que existe entre velocidades angulares de dos engranajes que tienen un punto de
contacto entre sí. Esta relación se puede obtener a partir de la velocidad angular
de cada engranaje; el número de dientes que posee cada engranaje; o con el
diámetro de cada uno.
En la ecuación (2.8) se obtiene la relación de transmisión usando las velocidades
angulares de cada engranaje.
+, =4.
4-!
(2.8)!
Donde +, es la relación de transmisión; 4- es la velocidad angular del primer
engranaje acoplado al micromotor; y 4. es la velocidad angular del segundo
engranaje acoplado al micromotor.
En la ecuación (2.9) se obtiene la relación de transmisión usando el número de
dientes de cada engranaje.
+, =6-
6.!
(2.9)!
Donde +, es la relación de transmisión; 6- es el número de dientes del primer
engranaje acoplado al micromotor; y 6. es el número de dientes del segundo
engranaje acoplado al motor.
El robot móvil físico tiene una masa de 3 kilogramos [kg], por lo que se hizo uso de
un micromotor con relación de transmisión de 250:1. Las características de este
micromotor se presentan en la Tabla 2.5.
42
Tabla 2.5 Características del motor de tracción del carlike [32]
Característica Descripción
Alimentación 6 voltios dc [VDC]
Velocidad 120 revoluciones por minuto [RPM] sin carga
Corriente 120 miliamperios [mA] sin carga
Torque 4.3 kilogramos por centímetro [Kg.cm]
Corriente máxima 1.6 amperios [A]
Caja reductora Sección transversal de 10 x 12 milímetros [mm]
Eje de salida Forma de “D” de 9 milímetros [mm] de largo y 3
milímetros [mm] de diámetro.
SELECCIÓN DE MOTOR DE DIRECCIÓN [33]
Debido a la carga que lleva el robot móvil se necesita un motor que proporcione un
torque alto para que no existan problemas en el giro del eje del motor de dirección.
Además, este giro debe ser rápido. El torque necesario es de 3 kilogramos por
centímetro [kg.cm] En base a estas características se seleccionó un servomotor por
encima de un motor a pasos. A continuación, se exponen las características del
servomotor marca pololu serie HS311 que se muestra en la Figura 2.15.
Figura 2.15 Estructura del servomotor [33]
El servomotor es un motor de corriente continua (DC) sobre el cual se puede
realizar control de posición. El rango de posición varía entre 0 y 180 grados [°]
generalmente. El servomotor está compuesto de: motor DC, caja de engranajes,
sensor de posición: usualmente es un potenciómetro, y un circuito de control.
El servomotor tiene tres cables, dos de los cuales es para la alimentación y el
tercero es para recibir la señal de control. El control de posición del eje del motor
se realiza con una señal PWM (Pulse Width Modulation). Esta señal PWM de pulsos
43
positivos, es de duración proporcional a la posición deseada del servomotor. En la
Figura 2.16 se observa cómo trabaja la PWM sobre el servomotor.
Figura 2.16 Funcionamiento de un servomotor
En la Tabla 2.6 se muestra las especificaciones del servomotor seleccionado.
Tabla 2.6 Características del motor de dirección del carlike [33]
Característica Descripción
Alimentación 4.8 - 6 voltios dc [VDC]
Modulación Análoga
Ángulo de Rotación 180 grados [°]
Ancho de pulso
máximo 2.5 milisegundos [ms]
Torque 4.8 voltios [V]: 3.02 kilogramos por centímetro [kg.cm]
6 voltios [V]: 3.53 kilogramos por centímetro [kg.cm]
Velocidad 4.8 voltios [V]: 60 grados [°] en 0.19 segundos [seg]
6 voltios [V]: 60 grados [°] en 0.15 segundos [seg]
Corriente 4.8 voltios [V]: 160 miliamperios [mA] sin carga
6 voltios [V]: 180 miliamperios [mA] sin carga
Dimensiones
Longitud: 39.9 milímetros [mm]
Profundidad: 19.8 milímetros [mm]
Altura: 36.3 milímetros [mm]
44
SELECCIÓN DE CÁMARA PARA LA REALIMENTACIÓN VISUAL DEL
CARLIKE FÍSICO
Para la realimentación visual del sistema se montó una cámara sobre el robot móvil,
para de esta forma ver por donde circula el mismo. Se consideró las cámaras que
podrían proporcionar una buena visualización del entorno del robot móvil. Dentro
de estas cámaras se encuentran: cámara web, cámara para la tarjeta Raspberry Pi
3B, y cámara IP. En la Tabla 2.7 se realiza la comparación de cámaras
consideradas para el proyecto.
Tabla 2.7 Comparación de cámaras.
CARACTERÍSTICA CÁMARAS
Cámara Web Cámara Raspberry Pi Cámara IP
Resolución (pixeles) 640x480 2592x1944 640x480
Ángulo de vista 180° 180° 360°
Conexión USB a
Ordenador
USB a Tarjeta
Raspberry Pi Inalámbrica
Comunicación para
envío de imagen Internet USB Tarjeta a PC Internet
Costo $70 $40 $70
El uso de una cámara web se descartó debido a que es necesario que esté
conectada a una computadora o a cualquier dispositivo que le permita acceder a
Internet. La cámara para la Raspberry Pi 3B se descartó debido a que el uso de la
tarjeta para envío de video hace que el procesamiento de los demás datos tengo
un retardo mayor. Además, la tarjeta debe estar conectada a la PC para visualizar
el video enviado por la cámara.
Se escogió una cámara IP debido a la facilidad para acceder a la misma, a
continuación, se detalla sus características.
Cámara IP
La cámara IP que se uso es la que se muestra en la Figura 2.17, su función es la
de transmitir imagen y video directamente por medio de Internet sin la necesidad
45
de usar un ordenador. Para poder acceder a la cámara IP desde cualquier
computador en cualquier lugar, se le debe asignar una dirección IP pública. La IP
pública se solicitó a la Dirección de Gestión de la Información y Procesos-DGIP.
Para asignar la IP se debe acceder a la configuración de la cámara.
Figura 2.17 Cámara IP Sricam modelo AP001 [37]
La cámara IP adquirida es una Sricam, cuyas especificaciones técnicas se
muestran en la Tabla 2.8.
Tabla 2.8 Especificaciones de la cámara IP Sricam [37]
Especificación Descripción
Compresión de Video VGA (640x480), QVGA (320x240)
Video Grabación de video de forma remota
Velocidad de fotogramas de imagen 25fps (50Hz), 30fps (60Hz)
Lente 3.6 milímetros [mm]
Visión nocturna Distancia has 10 metros [m]
Ángulo de rotación Pan: 355°, Tilt:90°
Protocolo de red HTTP, FTP, TCP/IP, UDP, SMTP, DHCP
Estándar inalámbrico IEEE 802.11 b/g/n
Seguridad inalámbrica Encriptación WEP, WPA, WPA2
Modo de IP Dirección IP dinámica, dirección IP estática
Visitantes en línea Apoyo 4 visitantes al mismo tiempo
Acceso Acceso multinivel
Modo de Acceso Interfaz de usuario
Fuente de Alimentación 5 Voltios DC [V], 2 Amperios [A]
Ethernet Un solo conector 10/100 Mbps, RJ-45
46
SENSORES DEL ROBOT MÓVIL FÍSICO
Sensor Digital de Distancia SDS01A
Se usó el sensor digital de distancia SDS01A para evitar que el robot móvil choque
frontalmente con objetos. El sensor sirve como seguridad en caso de que el
operador pierda el comando sobre el carlike o a su vez cuando los datos lleguen
demasiado tarde al vehículo como para evitar un choque frontal.
Este sensor detecta objetos que ser encuentra a una distancia de entre 2 y 10
centímetros [cm]. Posee un rápido tiempo de respuesta, es pequeño y consume
niveles bajos de corriente. [35]
Figura 2.18 Sensor digital de distancia SDS01A [35]
En la Figura 2.18 se observa el diseño exterior del sensor digital de distancia
SDS01A.
Interruptor Óptico Ranurado H22A1 (Encoder)
Se usó un interruptor óptico ranurado para usarlo con un disco ranurado y de esta
forma simular un encoder, como se puede observar en la Figura 2.19.
Figura 2.19 Encoder acoplado en la rueda de tracción del carlike
47
El sensor H22A1 es un sensor de arseniuro de galio que emite luz acoplado a una
foto darlington de silicio en una carcasa de plástico. El sistema de embalaje está
diseñado para optimizar la resolución mecánica, la eficiencia del acoplamiento, el
rechazo de la luz ambiental, el coste y la fiabilidad. El hueco en la carcasa
proporciona un medio para interrumpir la señal con un material opaco, cambiando
la salida de un estado "ON" a un estado "OFF". El sensor se muestra en la Figura
2.20.
Figura 2.20 Sensor óptico ranurado H22A1 [36]
SELECCIÓN DE TARJETA EMBEBIDA PARA EL CARLIKE FÍSICO
Para la selección de la tarjeta embebida se analizó las características necesarias
para que el sistema funcione correctamente. En el Capítulo 1 se detalló las
características de las siguientes tarjetas: Raspberry Pi 3B, Beaglebone Black,
UDOO. A continuación, en la Tabla 2.9 se realiza la comparación de dichas tarjetas
para seleccionar la que se acople a las necesidades del proyecto.
48
Tabla 2.9 Comparación de tarjetas de desarrollo comerciales
CARACTERÍSTICA SINGLE BOARD COMPUTER
Raspberry Pi 3B Beaglebone Black UDOO
CPU ARM v8 de 64 bits AM335x ARM Cortex-A9
Frecuencia 1.2GHz 1GHz 1GHz
RAM 1 GB DDR3 512MB DDR3 1GB
Sistema Operativo Raspbian Debian Debian, Ubuntu, etc. UDOObuntu 2,
Android
Módulo WiFi SI NO SI
Puerto HDMI SI SI SI
Puertos USB 4 2 3
Micro SD SI NO SI
Costo $35 $115 $135
De acuerdo con las especificaciones técnicas presentadas, las tarjetas Raspberry
Pi 3B y UDOO son la mejor opción ya que poseen módulo WiFi, el cual es necesario
para tener acceso a Internet sin el uso de cable ethernet, y también cuentan con
gran capacidad de memoria RAM que es indispensable para el procesamiento de
datos. Sin embargo, la tarjeta Raspberry Pi 3B es de costo más accesible y cuenta
con los recursos necesarios. Por lo tanto, en este proyecto se hace uso de una
tarjeta Raspberry Pi 3B.
Especificaciones Técnicas [26]
La Raspberry Pi 3B presenta las siguientes características técnicas:
· CPU ARM v8 de 64 bits a 1.2GHz
· Wireless LAN 802.11
· Bluetooth de bajo consumo
· Memoria RAM de 1GB
· 4 puertos USB
· 40 Gpio pins
· Puerto Full HDMI
· Puerto Ethernet
49
· Jack de audio combinado de 3.5mm y video compuesto.
· Interfaz de cámara CSI
· Interfaz de monitor DSI
· Espacio para micro SD
· Núcleo de gráficos 3D, núcleo gráfico.
Las partes de la Raspberry Pi 3B se muestran en la Figura 2.21 y mientras que la
distribución de pines GPIO se muestran en la Figura 2.22.
Figura 2.21 Distribución de elementos en la Raspberry Pi 3B [26]
Figura 2.22 Pines GPIO Raspberry Pi 3B [26]
50
Sistema Operativo [34]
El sistema operativo recomendado para el uso normal en una Raspberry Pi es
Raspbian. Raspbian es un sistema operativo libre basado en Debian, optimizado
para el hardware de la Raspberry Pi. Raspbian viene con 35000 paquetes de
software pre compilado para una fácil instalación en la Raspberry Pi.
Raspbian es un proyecto comunitario de desarrollo activo, con el énfasis de mejorar
la estabilidad y rendimiento de los paquetes Debian.
Para instalar el sistema operativo en el dispositivo micro SD se necesita otra
computadora con lector de tarjetas SD para instalar la imagen del sistema. La
imagen del sistema operativo puede descargarse directamente de la página oficial
de la fundación Raspberry donde existen varias opciones disponibles.
Lenguajes de Programación [26]
Los lenguajes de programación disponibles en la Raspberry Pi 3B son los
siguientes:
· Mathematica: Es una plataforma computacional potente usada en ciencias,
matemáticas, computación e ingeniería que ha sido incluido en Raspbian.
· Python 2 y 3: es un lenguaje de programación poderoso para propósitos
generales de fácil uso. Es un lenguaje muy simple que utiliza palabras claves
para desarrollar programas, su compilador para la Raspberry Pi 3B es IDLE.
Este es el lenguaje utilizado para el presente proyecto.
· Scratch: es un lenguaje de programación visual basado en la temática de
arrastrar y soltar. Permite crear juegos y animaciones, es un lenguaje
pensado para gente que recién empieza en el ámbito de la programación.
· Sonic Pi: Es un lenguaje libre dedicado para editar música.
Accesorios [34]
Algunos accesorios diseñados específicamente para la Raspberry Pi son:
51
· Módulo de cámara: es un producto oficial de la Fundación Raspberry Pi. El
modelo original de 5 mega pixeles fue desarrollado en 2013 y el modelo de
8 mega pixeles fue desarrollado en 2016
· Display LCD: Es un accesorio que se conecta mediante un conector DSI, se
permite el uso simultaneo del HDMI y del display LCD en algunas ocasiones,
pero se requiere soporte de software.
Aplicaciones
Las principales aplicaciones se enfocan al Internet de las cosas y proyectos DIY en
temas de adquisición de datos, visión artificial, montaje de servidores, etc. Para
usos en exploración, monitorización, control, etc.
Aplicación en el Proyecto
A continuación, se resalta las características necesarias de las que se harán uso:
· Wireless LAN 802.11: Proporciona a la tarjeta acceso a Internet de forma
inalámbrica, esto logra que el robot móvil pueda tener comunicación con el
servidor de datos, tanto para recibir como enviar información.
· Memoria RAM de 1GB: Garantiza alta velocidad en el procesamiento de
datos, los cuales son enviados desde la estación local. De esta forma reduce
los retardos.
· 40 Gpio-pins: Las GPIO de la tarjeta poseen salidas PWM necesarias para
el comando de los motores de tracción y dirección.
· Espacio para micro SD: Cuenta con memoria suficiente para instalar el
sistema operativo de la tarjeta y para almacenar el código de programación
del robot móvil.
En la Tabla 2.10 se detalla los pines utilizados en la tarjeta y cuál es la funcionalidad
que cumplen.
52
Tabla 2.10 Pines de la tarjeta usados
Pines
Funcionalidad Pines
BOARD
GPIO
Tarjeta
Pin11 GPIO17 Se conecta al pin IN1 del driver del motor de tracción para que
gire en sentido horario.
Pin13 GPIO27 Se conecta al pin IN2 del driver del motor de tracción para que
gire en sentido antihorario.
Pin15 GPIO22 Se conecta al pin SEÑAL PWM del driver del motor de tracción
para enviar la señal PWM y manejar la velocidad del mismo
Pin12 GPIO18 Se establece como puerto de entrada, para recibir la señal del
sensor de distancia colocado en la parte frontal del robot móvil.
Pin16 GPIO23
Se establece como puerto de entrada, para recibir los pulsos
del encoder colocado en llanta de tracción y así conocer la
velocidad del carlike.
Pin18 GPIO24
Se conecta al pin de control del servomotor para determinar el
ángulo de giro del mismo, y comandar la dirección del robot
móvil.
Pin22 GPIO25 Se usa como indicador para saber si existe comunicación
entre la estación local y remota.
Pin40 GPIO21 Se usa como reset para borrar el valor de las variables
odométricas.
Pin1 -------- Es el pin de conexión a Vcc para alimentar la tarjeta.
Pin6 -------- Es el pin de conexión a GND.
En la Figura 2.23 se especifica a qué elemento se conecta a cada pin de la tarjeta.
53
Figura 2.23 Pines de la tarjeta usados
DISEÑO DEL CIRCUITO ELECTRÓNICO DEL SISTEMA
Para el diseño del circuito electrónico del sistema se tomó en cuenta la energía
necesaria para abastecer al robot móvil y que éste funcione correctamente. El
sistema de alimentación se basa en el consumo de voltaje y corriente de los
siguientes elementos: micromotor, servomotor, cámara IP, tarjeta Raspberry Pi 3B,
y sensores.
Sistema de Alimentación
En la Tabla 2.11 se detalla el consumo de voltaje y corriente de los elementos que
componen el robot móvil.
Tabla 2.11 Consumo de voltaje y corriente de elementos del robot móvil
Elemento Voltaje [V] Corriente [A]
Micromotor 250:1 5 – 12 1
Servomotor 5 – 6 0.2
Cámara IP 5 0.6
Tarjeta Raspberry Pi 3B 5 0.7
Sensores 5 0.2
54
De acuerdo con los niveles de voltaje y corriente obtenidos se escogió las baterías
que puedan abastecer al carlike durante un tiempo de 25 minutos, lo cual es
suficiente para el funcionamiento continuo del robot móvil.
El consumo de corriente la tarjeta Raspberry Pi 3B es alto, por lo tanto, se usó una
sola batería para la tarjeta. Esta batería es propia de la marca Raspberry. Además,
se cuenta con dos baterías LiPo adicionales, es decir, finalmente se hace uso de
tres baterías.
Alimentación para los Actuadores: Micromotor y Servomotor
Esta etapa de alimentación suministra energía al micromotor y al servomotor. El
consumo de corriente de estos elementos no supera 1 Amperio [A], y el voltaje más
alto es de 12 Voltios [V], que corresponde al micromotor 250:1. Por lo tanto, se
selecciona una batería Rhino de 1250 [mAh] y 11.1 [V] (3 celdas).
Las baterías Rhino como la que se muestra en la Figura 2.24 proporcionan una
excelente relación potencia / peso. Equipado con lengüetas de cobre y la mayoría
de los paquetes que tienen electrodos opuestos. Las baterías Rhino están
diseñadas para un alto rendimiento y baja resistencia interna. Las características
más importantes de la batería se encuentran en la Tabla 2.12.
Figura 2.24 Batería LiPo RHINO [38]
Tabla 2.12 Especificaciones de la batería RHINO [38]
Especificación Descripción
Capacidad 1250 [mAh]
Descarga constante 20C
Configuración 3 celdas; 11.1 [V]
Dimensiones 90x35x18 [mm]
Peso 116 [g]
55
Alimentación para cámara IP y sensores
Esta etapa de alimentación suministra energía la cámara IP, y sensores. La cámara
IP, como los sensores necesitan una alimentación de 5 voltios [V]. Se escogió una
batería Turnigy nano-tech de 1500 [mAh] y 7.4 [V] (2 celdas).
La batería Turnigy como la de la Figura 2.25 abastece energía a las partes
eléctricas del sistema como son el sensor de presencia, el encoder, la cámara IP y
el circuito de monitoreo de las baterías. Las especificaciones de esta batería se
muestran en la Tabla 2.13.
Figura 2.25 Batería LiPo NanoTech [39]
Tabla 2.13 Especificaciones de la batería Turnigy [39]
Especificación Descripción
Capacidad 1500 [mAh]
Descarga constante 20C
Configuración 2 celdas; 7.4 [V]
Dimensiones 87x34x13 [mm]
Peso 75 [g]
Alimentación para Tarjeta Raspberry Pi 3B.
Para la alimentación de la tarjeta del robot móvil, se escogió la batería RPi
PowerPack V1.2 que se muestra en la Figura 2.26. Esta batería tiene un tiempo de
operación mucho más prolongado que una batería LiPo, esto la hace ideal para la
tarjeta ya que el alto consumo de corriente de la misma hace que una batería LiPo
se descargue al cabo de pocos minutos. A continuación, se presentan las
características de la batería.
56
Características
· Un módulo de potencia diseñado para la tarjeta Raspberry Pi 3B, que permite
el uso de tarjeta de forma móvil hasta 9 horas.
· Capacidad de la batería: 3800 mAh (máximo)
· Corriente de salida: 1.8 Amperios [A]
· Voltaje de salida (sin carga): 5.1 V ± 0.1V.
· Dos salidas USB para suministrar carga.
Figura 2.26 Batería RPi PowerPack V1.2 [40]
Circuito de Seguridad para Baterías LiPo
Como medida de seguridad se tomó en cuenta que las baterías LiPo no deben
descargarse por debajo del 80 por ciento [%] de su voltaje nominal, porque al
suceder esto las baterías se dañan completamente y ya no es posible cargarlas de
nuevo. Por esta razón para evitar el daño permanente de las baterías LiPo se
implementa un circuito el cual indique en que momento las baterías están por
debajo del nivel de voltaje permitido.
El circuito que se implementó es un comparador de voltaje. Este circuito posee un
led verde y un led rojo, los cuales indican que la batería se encuentra en el rango
de voltaje permitido o a un nivel por debajo de este. Se enciende el led verde
mientras las baterías tengan el voltaje suficiente. Y se enciende el led rojo para
indicar que el voltaje de la batería es demasiado bajo y necesita ser cargada
inmediatamente.
57
Cálculo del valor que representa el 80% del nivel de voltaje de una celda:
;>?@AB/B@/-CCD = 3E7/[;] F 100/[D]! (2.10)!
;>?@AB/B@/GCD =(80[D])(3E7[;])
100[D]!
(2.11)!
;>?@AB/B@/GCD = 2EHI/[;] J 3[;]! (2.12)!
El voltaje mínimo de la celda para que no exista daño en las baterías es:
;>?@AB/B@/GCD = 3/[;]! (2.13)!
Cálculos para realizar el circuito divisor de voltaje de la fuente alimentación:
Se tiene una fuente de 5 voltios [;], por lo tanto, para obtener los 3 voltios [;] y
realizar la comparación de voltaje se hizo un divisor de voltaje.
;>?@AB/B@/GCD =+.
+- K +.E ;LM?N,?!
(2.14)!
3[;] =+.
+- K +.(5[;])!
(2.15)!
+- K +. =5[;]
3[;]E +.!
(2.16)!
OP/+- = 10/[QR] /S /+. = 15/[QR]! (2.17)!
+- = 10/[QR] F 2[;]! (2.18)!
+. = 15/[QR] F 3[;]! (2.19)!
TUVW&X Y /ZX/UZ\/X6$^6_XZ/+- = 10/[QR] /S /+. = 15/[QR]! (2.20)!
58
Cálculos para realizar el circuito comparador de voltaje de la Batería Rhino: LiPo
de 3 celdas, voltaje de 3.7 voltios [;] por celda
Esta batería posee un voltaje total de 11.1 voltios [;]. Para tomar el voltaje de una
sola celda se realizó un divisor de voltaje.
;>?@AB =+.
+- K +.E ;̀ >?@ABb!
(2.21)!
3E7[;] =+.
+- K +.(11E1[;])!
(2.22)!
+- K +. =11E1[;]
3E7[;]E +.!
(2.23)!
+- K +. = 3+.! (2.24)!
OP/+- = 15/[QR] /S /+. = 7E5/[QR]! (2.25)!
+- = 15/[QR] F 7Ed[;]! (2.26)!
+. = 7E5/[QR] F 3E7[;]! (2.27)!
TUVW&X Y /ZX/UZ\/X6$^6_XZ/+- = 15/[QR] /S /+. = 7E5/[QR]! (2.28)!
A continuación, en la Figura 2.27 se presenta el esquema del circuito con sus
elementos y valores.
59
Figura 2.27 Circuito de seguridad para batería Rhino 3 celdas.
Cálculos para realizar el circuito comparador de voltaje de la Batería Turnigy: LiPo
de 2 celdas, voltaje de 3.7 voltios [;] por celda
Esta batería posee un voltaje total de 7.4 voltios [;]. Para tomar el voltaje de una
sola celda se realizó un divisor de voltaje.
;>?@AB =+.
+- K +.E ;̀ >?@ABb!
(2.29)!
3E7[;] =+.
+- K +.(7Ed[;])!
(2.30)!
+- K +. =7Ed[;]
3E7[;]E +.!
(2.31)!
+- K +. = 2+.! (2.32)!
Alimentación Batería
R1015k
R117.5k
R1210k
R1315k
AK
D1LED-GREEN
R14
220R
3
21
41
1
U2:A
LM324
5
67
41
1
U2:B
LM324
R15
220R
AK
D2LED-RED
CIRCUITO DE SEGURIDAD PARA BATERÍA DE POTENCIA
Vcc
5V
led1
led2
Vcc
5V
60
OP/+- = 10/[QR] /S /+. = 10/[QR]! (2.33)!
+- = 10/[QR] F 3E7[;]! (2.34)!
+. = 10/[QR] F 3E7[;]! (2.35)!
TUVW&X Y /ZX/UZ\/X6$^6_XZ/+- = 15/[QR] /S /+. = 7E5/[QR]! (2.36)!
En la Figura 2.28 se presenta el esquema del circuito con sus elementos y valores.
Figura 2.28 Circuito de seguridad para batería Turnigy 2 celdas.
Fuentes Reguladoras de Voltaje: Módulo LM2596
El módulo LM2596 mostrado en la Figura 2.29 es un circuito que permite mantener
un voltaje regulado entre un rango de 1.5 V a 35 V, El voltaje de alimentación de
este módulo debe ser mayor al voltaje de salida que se quiera obtener. Este módulo
está basado en el regulador DC-DC LM2596 tipo Buck. Es una fuente de
Alimentación Batería
R1010k
R1110k
R1210k
R1315k
AK
D1LED-GREEN
R14
220R
3
21
41
1
U2:A
LM324
5
67
41
1
U2:B
LM324
R15
220R
AK
D2LED-RED
CIRCUITO DE SEGURIDAD PARA BATERÍA DE CONTROLV
cc 5
V
led1
led2
Vcc
5V
61
alimentación conmutada lo que aumenta su eficiencia en comparación a los típicos
reguladores lineales.
Se usó este módulo debido a que se necesita un voltaje de alimentación fijo para
alimentar todos los partes electrónicos. Se usan dos módulos, cada uno conectado
a la batería LiPo correspondiente.
Figura 2.29 Módulo LM2596 convertidor de voltaje DC-DC [41]
Características
· Módulo basado en el regulador LM2596.
· Voltaje de alimentación: 4.5 – 40 Voltios DC [V]
· Voltaje de salida: 1.5 – 35 Voltios DC [V]
· Corriente máxima de salida: 3 Amperios [A]
· Dimensiones: 43x20x14 Milímetros [mm]
· Frecuencia de switching: 150 Kilo Hertz [KHz]
Driver Para Motor de Tracción - L298n
El motor de tracción que se usó en el robot móvil es un micromotor. Este motor
tiene un alto par de torque, lo cual, provoca un consumo de corriente considerable
en ciertos momentos. Tomando en cuenta estas consideraciones, se usó el driver
L298n mostrado en la Figura 2.30, el cual, haciendo uso de una señal PWM, sirve
para manejar la velocidad y sentido de giro del motor, y ayuda a amplificar el voltaje
y corriente que llega al micromotor. La descripción de este driver se detalla a
continuación.
62
Figura 2.30 Driver L298n para motor de tracción [42]
Características
· El driver L298n es un circuito tipo puente completo dual diseñado para
niveles lógicos TTL.
· Consta de dos entradas, las cuales habilitan o deshabilitan el motor.
· Consta de dos pines, dependiendo de cuál se escoja se determina el sentido
de giro del motor.
Esquema Final del Circuito Electrónico del Sistema
En la Figura 2.31 se muestra el esquema del circuito electrónico interno que fue
desarrollado.
Figura 2.31 Esquema del circuito electrónico
63
En la Figura 2.32 y Figura 2.33 se muestra el robot móvil, tanto la parte interna
como externa.
Figura 2.32 Vista exterior del robot móvil
Figura 2.33 Vista interior del robot móvil
En la Figura 2.34, Figura 2.35, Figura 2.36, Figura 2.37, y Figura 2.38 se muestran
las conexiones internas del circuito electrónico.
64
Figura 2.34 Vista interior derecha de conexión de pines
Figura 2.35 Vista interior izquierda de conexión de pines
Figura 2.36 Vista interior superior de conexión de pines
65
Figura 2.37 Vista trasera de conexión de pines
Figura 2.38 Vista conexión de leds indicadores
66
CAPÍTULO 3
DISEÑO E IMPLEMENTACIÓN DEL SOFTWARE PARA
EL SISTEMA DE TELEOPERACIÓN Y EL ROBOT MÓVIL
TIPO CARLIKE.
El sistema en general requiere de varias partes de software necesarias para el
desarrollo de todo el proyecto que se explican en los siguientes apartados. Cada
apartado tiene sus propios elementos a manejar, sistemas de recolección de
información y de procesamiento de los mismos. Dado que la estación local
comparte información con los modelos de carlike físicos y simulado, la estructura
del presente capítulo se ha desarrollado de manera que se detalle el
funcionamiento de los modelos de carlike físico y simulado en entorno virtual, luego
del servidor o bróker MQTT y por último de la estación local.
3.1. ELEMENTOS DE SOFTWARE DEL CARLIKE FÍSICO.
En el desarrollo del proyecto, en la parte del carlike físico se consideran partes de
software necesarios para poder manejar el hardware que fue descrito en el capítulo
2, así mismo para gestionar la comunicación entre el cliente de la Raspberry Pi 3B
y el cliente MQTT de la estación de operación.
SELECCIÓN DEL LENGUAJE DE PROGRAMACIÓN.
El sistema operativo Raspbian utilizado en el proyecto ofrece lenguajes de
programación como Java, Python, Scratch y Mathematica como se explicó en el
apartado 2.4.2.6 del presente proyecto.
Considerando las necesidades y requerimientos de este proyecto y considerando
las prestaciones y potencialidad de cada uno de los lenguajes de programación
mencionados anteriormente, se ha elegido el lenguaje Python 2.7 para llevar a cabo
la programación de este proyecto.
67
Python 2.7
Python es un lenguaje de programación interpretado de alto nivel, sencillo de utilizar
y potente en cuanto a funcionalidades ya que provee una gran gama de librerías y
utilidades que permiten desarrollar aplicaciones de manera sencilla. Algunas de las
librerías utilizadas en este proyecto son las siguientes:
· Time: Permite obtener y trabajar con la información de tiempo del Sistema.
· paho.mqtt.client: Permite crear y conectar un nuevo cliente MQTT capaz de
suscribirse a tópicos y recibir información que comparten otros clientes.
· paho.mqtt.publish: permite que el cliente de Python pueda publicar datos en
tópicos para compartir información con otros clientes.
· JSON: Es un formato de intercambio de información que permite crear
diccionarios que incluyan varios datos, en el presente proyecto se usa para
enviar varios datos en un mismo tópico.
· RPi.GPIO: en general permite trabajar con las entradas físicas de la
Raspberry Pi 3B y poder usarlas como entradas o salidas digitales.
· Math: Permite realizar operaciones matemáticas, en el proyecto se usa para
medir las variables de odometría.
Una de las características más importantes que presenta Python es que se puede
programar en hilos, lo cual significa que se pueden compilar varios procesos a la
vez y no esperar a que termine un proceso para seguir con el siguiente.
Figura 3.1 Programación en pasos y en hilos
68
En la Figura 3.1 se muestra la diferencia entre la forma de compilación en pasos
consecutivos realizada normalmente y la forma de compilación en hilos donde
varios procesos se ejecutan a la vez. En este proyecto se utilizó la programación
en hilos para completar diferentes operaciones a la vez debido a que se deben
gestionar varios procesos importantes al mismo tiempo.
LÓGICA DE MANEJO DE LOS ELEMENTOS DE HARDWARE.
Los elementos de hardware que se deben manejar en el modelo físico del carlike
son los siguientes:
Driver l298n
Para manejar el motor con caja reductora 250:1 se usó un driver L298N, necesita
3 señales que son las que se muestran en la Tabla 3.1
Tabla 3.1 Tabla de funciones del driver L298n [42]
Enable
(Señal PWM)
In1
In2
Función
H L H Giro a la derecha
H H L Giro a la izquierda
H L L Detención rápida
H H H Detención rápida
L X X Detención libre
En la Tabla 3.1 se pueden apreciar las funciones que realiza el driver según las
entradas que tiene. En la lógica dentro del programa se definirán 3 salidas en las
GPIO de la Raspberry Pi 3B para comandar este driver según la lógica de la tabla
anterior, dos de estas salidas se usarán para fijar en las entradas 1 y 2 el sentido
del giro, mientras que en la entrada Enable se usara una señal PWM de 1Khz con
ancho de pulso variable para poder manejar la velocidad del motor.
Servomotor HS311
Para comandar el servomotor se necesita una señal PWM de 50Hz (20ms) con el
ancho de pulso variable. Para fijar el eje del servomotor en 0 grados se debe enviar
69
pulsos de 1ms que corresponde a un ancho de pulso de 5%, para fijar el eje del
motor en 180 grados, se debe enviar pulsos de 2 ms que corresponde a un ancho
de pulso de 10% como se muestra en la Figura 3.2.
Figura 3.2 Relación entre ancho de pulso de PWM y ángulo del eje del servomotor
Para obtener la ecuación de la recta de la gráfica de la Figura 3.2 se usa la ecuación
(3.1).
* = V' K e! (3.1)!
Reemplazando los nombres de los ejes tenemos:
\6_f^/gX/WU&Z^ = [(V)(\6hU&^/gX&/XjX/gX&/ZXk#^V^$^k)] K e! (3.2)!
Gráficamente se puede observar que el valor de b que corresponde al corte de la
recta con el eje perpendicular es de 5. La pendiente se puede calcular como en la
ecuación (3.3).
V =*. l *-
'. l '-!
(3.3)!
Al reemplazar los valores de los puntos se obtiene:
V =10 l 5
180 l 0=
5
180= 0E02777!
(3.4)!
0
2
4
6
8
10
12
0 50 100 150 200Án
cho
de
pu
lso
del
PW
M(%
)
Ángulo del eje del servomotor (°)
70
Para calcular el ancho del pulso necesario para comandar el servomotor y girar las
llantas delanteras según se desee, se tiene la ecuación (3.5).
\6_f^/gX/WU&Z^ = [(\6hU&^/gX&/XjX/gX&/ZXk#^V^$^k)(0E02777)] K 5! (3.5)!
De acuerdo con los acoples físicos realizados, el eje que une las llantas delanteras
puede girar las mismas entre -20 grados (tope a la izquierda) y 20 grados (tope a
la derecha). Cuando el eje del servomotor se ubica en 50 grados, el eje que une las
llantas delanteras mantiene las mismas hacia el frente, cuando el eje del
servomotor se ubica en 21 grados, el eje que une las llantas delanteras gira las
llantas a 20 grados a la derecha y cuando el eje del servomotor se ubica a 79
grados, el eje de las llantas delanteras las gira a 20 grados a la izquierda como se
muestra en la Figura 3.3.
Figura 3.3 Relación entre el ángulo del eje del servomotor y el ángulo de giro de las
llantas delanteras
Para obtener la ecuación de la relación lineal entre el ángulo del eje del servomotor
y el ángulo de las llantas delanteras del carlike se usa la ecuación (3.1) y para
reemplazando los nombres de los ejes se tiene:
anmupo/qrq/vqp/sqwxoyotow/ = [(V)(viwqccion/vq/pas/ppantas/vqpantqwas)] K z (3.6)!
El valor de b que corresponde al corte de la recta con el eje vertical es 50 y la
pendiente de la recta se calcula usando la ecuación (3.3) y reemplazando los
valores se obtiene:
0
10
20
30
40
50
60
70
80
90
-25 -20 -15 -10 -5 0 5 10 15 20 25Án
gulo
del
eje
del
ser
vom
oto
r (°
)
Ángulo de las llantas delanteras del carlike (°)
71
V =21 l 7H
20 l (l20)=l50
d0= l1Ed5!
(3.7)!
La relación lineal que rige este movimiento viene dada por la ecuación (3.8).
anmupo/qrq/vqp/sqwxoyotow/ = [(l1Ed5)(viwqccion/vq/pas/ppantas/vqpantqwas)]
K50
(3.8)!
Con las ecuaciones (3.5) y (3.8) el programa puede recibir el dato del ángulo de
giro de las llantas delanteras deseado y comandar el servomotor para poder realizar
la acción deseada.
Encoder Óptico
El encoder óptico utilizado provee un tren de pulsos según el movimiento giratorio
de las llantas traseras. La resolución del encoder es de 10 pulsos por vuelta.
El encoder se utiliza para poder calcular la velocidad lineal que mantiene el carlike
de la siguiente manera: el enconder y su respectivo acondicionamiento proveen de
un tren de pulsos que se leen en una entrada física GPIO de la Raspberry Pi 3B
configurada como interrupción externa con flanco de subida. Dentro de la
interrupción externa se cuenta el número de pulsos n en un determinado periodo
de tiempo T. La lógica de conversión de datos es la que se muestra en la ecuación
(3.9) considerando el diámetro D de la rueda que se muestra en la Tabla 2.3.
#X&^_Pg\g[V{Z] =6/[WU&Z^Z]
|/[ZXhU6g^Z]/1/[#UX&$\]
10/[WU&Z^Z]//(WP)}[_V]
1[#UX&$\]/1[V]
100/[_V]
(3.9)!
Con la ecuación (3.9) el programa puede calcular la velocidad lineal del carlike.
Sensor de presencia Sharp
Este sensor de presencia provee de una señal lógica cuando existe un obstáculo
entre 2 y 10 cm. En el programa principal se lee el estado digital de esta señal para
poder conocer si existen obstáculos y evita que el carlike choque contra el mismo.
Si los comandos le indican que debe seguir hacía el frente, el carlike se detendrá
72
al detectar un obstáculo adelante y solo permitirá que se mueva si los comandos le
indican que debe ir hacia atrás.
Luces Indicadoras
Se usa un led amarillo para que el usuario que tiene contacto con el carlike pueda
conocer si este tiene comunicación con la estación local. Está ubicado en la parte
superior del carlike y se enciende cuando existe comunicación con la estación y se
apaga cuando no hay comunicación. Además, se usan dos leds verdes y dos leds
rojos, los cuales indican el nivel de voltaje de las baterías LiPo, están ubicados junto
al led amarillo.
LÓGICA DE PROGRAMACIÓN DEL CARLIKE FÍSICO
A continuación, se muestra la lógica de programación que se ha desarrollado en
Python 2.7 a manera de un diagrama de flujo general en la Figura 3.4. El programa
empieza con la inicialización y luego pasa al lazo infinito, los eventos o
interrupciones pueden ejecutarse en cualquier momento para luego volver al lazo
principal.
Inicialización de programa
INICIO
FIN
Interrupción externa. ENCODER
Lazo principalInterrupción.
Mensaje MQTT recibido
Figura 3.4 Diagrama de flujo general de la lógica de programación del carlike físico
73
Para la parte de inicialización y configuraciones iniciales se siguen los siguientes
pasos como se muestra en la Figura 3.5.
Inicialización del programa
Importar librerías de tiempo, MQTT, JSON, GPIO y MATH
Configuración de la GPIO
Inicialización de la PWM de motor DC en 0, motor detenidoInicializa la PWM del servomotor para girar 0 grados las llantas delanteras
Inicializa la interrupción externa del encoder
Definicion de variables odometricas y variables de control y se las inicializa con valor de 0
Se define el diccionario JSON para almacenar las varables odometricas de velocidad y posicion en x e y
Se crea el cliente MQTTSe conecta el cliente MQTT al BROKER
Inicia el contador de tiempo 1 y 2
Figura 3.5 Inicialización del programa
A continuación, en la Figura 3.6, se muestra el lazo principal donde se llevan a cabo
tareas de monitorización, cálculos de odometría y ejecución de comandos.
74
Lazo principal
Detener el carlike
¿Existe un obstáculo al frente y el sentido del movimiento es hacia el frente?
Calcular la velocidad del carlike de acuerdo a la información del encoder.
Reset del contador de la interrupción del encoder
Calcula la posición del carlike usando el modelo cinemático del mismo
Crea un objeto JSON donde se añaden las variables odométricos de posición y velocidad
Publica el objeto JSON para q sea considerado en la estación local
Reinicia el contador de tiempo 1
¿El contador de tiempo 2 es mayor a 2 s?
Estado de desconexión con la estación local
Apaga el led indicador de que existe comunicación con la estación local
Detener el carlike
¿El contador de tiempo 1 es mayor a 0.5 s?
sino
no si
si no
Figura 3.6 Lazo principal del funcionamiento del sistema
75
El evento en el que se realiza el contador de pulsos del encoder es el que se
muestra en la Figura 3.7.
Interrupción externa. ENCODER
Aumentar el valor del contador
Lazo principal
Figura 3.7 Evento para contar pulsos del encoder
El evento en el que se recibe un mensaje MQTT y se actualizan los valores de los
comandos es el que se muestra en la Figura 3.8.
Interrupción.Mensaje MQTT recibido
Reset del contador de tiempo 2
Encender la luz indicadora de que existe comunicación
Guardar el mensaje MQTT, discriminar, limitar y actualizar las variables
Aplica las acciones de control en los actuadores del carlike
Lazo principal
Figura 3.8 Evento de la recepción de un mensaje MQTT
76
CONFIGURACIÓN DE LA CÁMARA IP
La cámara IP es un elemento se suma importancia que permite la realimentación
visual del entorno del robot hacia la estación local, ya que gracias a ello el operador
podrá tomar decisiones para comandar el carlike.
El retardo en la comunicación juega un papel muy importante en este caso, ya que
el retardo puede hacer que la telepresencia del operador no sea adecuada y las
decisiones sean erróneas. Por ejemplo, si los retardos son muy altos el operador
podría no darse cuenta de que el carlike esté a punto de colisionar.
La configuración de la cámara IP se muestra en el ANEXO A.
3.2. ELEMENTOS DE SOFTWARE DEL CARLIKE
DESARROLLADO EN ENTORNO VIRTUAL
Para la ejecución de este proyecto se usó Unity 3D para desarrollar el modelo
simulado del carlike. Unity es un motor gráfico utilizado para crear video juegos,
aplicaciones y animaciones para plataformas de Windows, Android, iOS, XBOX,
etc.
Unity ofrece un editor visual muy completo que provee de herramientas para el
desarrollo de las aplicaciones. El entorno virtual se desarrolla en el editor, mientras
que los comandos se ejecutan desde scripts, estos scripts pueden ser
implementados en tres lenguajes: JavaScript, C# o Boo.
En este proyecto se usó una versión estudiantil de Unity, que es menos completa
que la versión profesional, pero tiene las herramientas necesarias para llevar a cabo
el mismo.
Las partes del entorno virtual que se creó son el carlike, el terreno, luces
direccionales, una cámara, y una ciudad virtual como se muestra en la Figura 3.9.
La programación de los objetos que componen el entorno virtual se la realizó en
scripts en lenguaje C# en el compilador mono Developer propio de Unity.
77
Figura 3.9 Carlike simulado en el entorno virtual
Unity provee de varias herramientas que facilitan el trabajar en el entorno para que
se comporte de una manera muy realista. La herramienta que hace posible esto es
la tecnología Nvidia Physx que posee Unity la cual incluye consideraciones de
aceleración, masa, gravedad, fuerzas externas, inercia, torques, etc. Esta
herramienta incluye motores de física incluidos que realizan todos los cálculos
físicos para la simulación. Por lo cual al crear cada objeto se le debe asignar las
características adecuadas de tamaños y masa, por ejemplo.
Figura 3.10 Módulo de diseño del robot móvil.
78
En la Figura 3.10 se muestra las herramientas del módulo de física que provee
Unity, para este proyecto solo se usaron los componentes de RigidBody y los
Colliders.
· Rigidbody. Esta herramienta permite que los GameObjects sean afectados
por la física, es decir que puede aplicárseles fuerzas y torques para crear
movimientos realistas. Además, permite que el objeto sea influenciado por
la gravedad o por fuerzas agregadas vía script. Esta herramienta permite
configurar la masa del objeto, el detector de colisiones, la gravedad, etc.
· Colliders. Son componentes que se incluyen en los GameObjects y lo
delimitan para que el programa reconozca colisiones con otros colliders. Los
colliders son invisibles y no es necesario que tenga la misma forma que el
objeto, sino que sea lo más aproximado posible. Unity incorpora cuatro
geometrías básicas que son el box collider (caja), sphere collider (esfera),
capsule collider (cápsula), mesh collider y Wheel collider. En este proyecto
se usó el box collider para recubrir el carlike y Wheel colliders en las ruedas
del automóvil.
DESARROLLO DEL ENTORNO VIRTUAL
Como se mencionó anteriormente, el entorno virtual desarrollado se compone de
varios objetos como el carlike, el terreno, luces direccionales, la cámara, y una
ciudad. A continuación, se explican el desarrollo y configuración de estos objetos.
El Terreno
El terreno es la base sobre la que se sostiene todas las estructuras que se monten
en el entorno virtual como se muestra en la Figura 3.11. El terreno puede ser
añadido en la barra de menú en la pestaña GameObject, submenú 3D Object y en
la opción Terrain. En este caso el terreno tiene como dimensiones 1000 m de ancho
y 2000 m de largo.
79
Figura 3.11 Terreno Unity 3D
La Ciudad
La ciudad es el medio por el cual el operador debe conducir el carlike con el objetivo
de llegar a un punto específico sin chocar. El modelo de la ciudad fue obtenido de
manera gratuita en el asset store de Unity 3D como se muestra en la Figura 3.12.
Figura 3.12 Asset store - modelos de ciudades gratuitas
Al elegir una ciudad se la selecciona, luego el Asset Store pedirá que el usuario
ingrese su cuenta y el modelo se descargará automáticamente. Luego de eso el
modelo se importa a la escena y se la puede utilizar. El modelo de la ciudad elegida
se muestra en la Figura 3.13.
80
Figura 3.13 Modelo de la ciudad utilizada.
El Carlike Jeep
El carlike es el robot que se maneja desde la estación local, desde la cual se puede
direccionar las llantas delanteras, acelerar o frenar las llantas traseras e ir hacia
delante o hacia atrás. El carlike simulado en el entorno virtual se muestra en la
Figura 3.14.
Figura 3.14 Modelo de Carlike en el entorno virtual.
El carlike se comporta como un auto normal y el objetivo es manejarlo en la ciudad
y llegar a un punto específico. El peso asignado al carlike es de 600 kg, tiene
activado el método de detección de colisiones continuo para evitar que el mismo
choque con cualquier obstáculo utilizando el “Cube Collider” de la Figura 3.15.
81
Figura 3.15 Cube collider en el Carlike.
En la Figura 3.16 se muestran algunas configuraciones del carlike.
Figura 3.16 Configuración del rigidbody del Carlike
Para poder comandar cada par de llantas se le incluyen un Wheel colliders a cada
llanta como se muestra en la Figura 3.17. Estos Wheel collider tienen propiedades
que se pueden manejar como el “motor torque” para generar tracción desde las
llantas traseras, “motor break” para frenar las llantas y “steerAngle” para girar las
llantas según las indicaciones del volante hacia la izquierda o hacia la derecha.
Estas propiedades se modifican desde el script donde se ejecutan los comandos
en el carlike.
82
Figura 3.17 Wheel colliders en las llantas del carlike.
Algunas de las características de los Wheel colliders son el radio de 0.33m, tienen
masa de 20Kg y sus propiedades son modificadas desde el script de C#
“Movimiento”.
Luces Direccionales
Las luces direccionales mostradas en la Figura 3.18 proveen de iluminación natural
al entorno simulado para poder iluminar toda la escena y sus componentes. En este
caso se usaron 4 luces direccionales para iluminar la escena completamente y
poder tener buena visualización dentro de la misma.
Figura 3.18 Luces direccionales para iluminar el entorno.
83
La Cámara
La cámara mostrada en la Figura 3.19 es una de las partes más importantes ya que
provee la posibilidad de mirar el entorno del carlike y saber por dónde está
movilizándose. La cámara está programada para seguir al carlike en todo momento
y proveer de realimentación visual al operador para que pueda tomar las decisiones
más convenientes. La cámara actúa bajo la influencia de un script programado en
C# llamado “cámara”.
Figura 3.19 Cámara montada en el Carlike.
TeamViewer
En la arquitectura de comunicación entre la estación local, donde se generan los
comandos, y la aplicación de Unity 3D, la comunicación de datos entre ambos
clientes se la realiza usando el protocolo MQTT específicamente. Este protocolo es
utilizado ya que envía mensajes cortos y es muy liviano, pero no fue diseñado para
datos grandes y pesados como imágenes, es por lo que se hace presente la
necesidad de utilizar otra aplicación para poder realizar la realimentación visual
desde el entorno simulado en Unity 3D y la estación local. Para esto se ha decidido
usar una licencia gratuita de TeamViewer.
TeamViewer es una aplicación multiplataforma que soporta conexiones entre
dispositivos Windows, macOS, Linux, Chrome, Android, etc. No necesita
configuraciones y funciona detrás de cualquier firewall. Usa eficientemente el ancho
de banda de la red, transmite con una velocidad de hasta 60fps lo cual permite una
experiencia optimizada. La interfaz de usuario es muy amigable y fácil de usar. En
84
el ámbito de la seguridad emplea codificaciones punto a punto, contraseñas
aleatorias, etc que lo hacen muy seguro. Y provee de licencias gratuitas para
usuarios no comerciales. [43]
Todas las características anteriores hacen que TeamViewer sea la mejor opción
para llevar acabo la realimentación visual del entorno simulado en Unity 3D y su
interfaz de usuario se muestra en la Figura 3.20.
Figura 3.20 Interfaz de usuario TeamViewer.
PROGRAMAS PARA COMANDAR EL CARLIKE.
En los anteriores apartados se mencionaron todas las partes que componen el
carlike y del entorno virtual. En este apartado se menciona la lógica que se utilizó
para manejar cada objeto según se necesite y de acuerdo con los comandos
enviados desde la estación local.
Para controlar las propiedades de cada objeto del entorno simulado se usan los
scripts. En este caso se ha elegido el lenguaje C# que provee Unity 3D. La
estructura del programa empieza definiendo todas las variables y configuraciones
en la función Start () que se ejecuta una sola vez en el programa. La función Update
() se ejecuta una vez cada cuadro de imagen y las instrucciones que se programen
se realizaran en forma cíclica. También existe la función FixedUpdate () que se
ejecuta en cada periodo de actualización del módulo de física, lo cual hace que se
ejecute varias veces en cada cuadro de imagen, por lo cual es mejor programar los
85
comportamientos físicos en esta función. El diagrama de flujo general se muestra
en la Figura 3.21.
Función Start
INICIO
FIN
Función Update Función Fixed Update Función Guide Evento de mensaje MQTT
Figura 3.21 Diagrama de flujo general de la lógica de programación del carlike
simulado en Unity 3D
Para la lógica de todo el sistema se usan dos scripts, uno de ellos gestiona la
comunicación y maneja el carlike, mientras que el otro gestiona las acciones de la
cámara.
Script de la lógica del Carlike
Como se mencionó anteriormente los objetos que se deben manejar del modelo del
carlike son los que se relacionan con las Wheel colliders de las llantas delanteras y
traseras, además de las variables que se reciben desde la estación local y las
variables odométricos que se calculan en transcurso de la simulación, estas se
muestran en la Figura 3.22.
Para empezar el programa se cargan todas las librerías necesarias para poder
llevar a cabo las tareas requeridas como son: Trabajar sobre el Internet usando
MQTT, crear el cliente MQTT y poder suscribirse a información de otros clientes, y
publicar información para que sea leído por otros clientes, además se carga la
librería JSON para manejar un formato de texto para poder intercambiar datos.
86
Figura 3.22 Variables públicas del jeep.
Después el programa reconoce los objetos del carlike que han de ser manejados y
guarda los mismos en variables públicas.
En la función Start () que se muestra en la Figura 3.23 se crea un nuevo cliente
MQTT para la aplicación y se lo conecta al bróker o servidor central que tiene la IP
publica suministrada por la EPN, luego se suscribe al cliente a los tópicos en los
que la estación local envía los comandos.
Función Start
Carga librerías de MQTT, JSON y TIME
Cargar variables públicas de objetos del carlike desde el entorno virtual
Crear un nuevo cliente MQTTConectarse al Bróker en la dirección IP publica
Suscribir el cliente MQTT a los Tópicos en los que la estación local publica la aceleración, desaceleración, la direccion de las ruedas delanteras, el sentido del movimiento y el estado de la conexión
Figura 3.23 Inicialización del programa en la función start
87
Función Update
Inicia el Timer 1 y el Timer 2
Calcula la velocidad del carlike
Timer 1 >= 1s
Actualizar los valores de posición en x e y del carlike
Crea un objeto JSON con los datos odométricos de posición y velocidad del carlike
Publica el objeto JSON para que se considerado en la estación local
Reinicia el Timer 1
Timer 2 >= 2s
Estado de conexión = desconectado
no si
no si
Figura 3.24 Función update.
En la función Update que se muestra en la Figura 3.24 se inician dos timers, los
cuales llevaran la información de tiempo transcurrido, el primero se usará para
sincronizar el envío de los datos odométricos de posición y velocidad del carlike
hacia la estación local para que sean considerados en la misma. El segundo timer
88
lleva la información del tiempo transcurrido desde la última vez que se actualizó un
dato por un evento de comunicación MQTT. Hay que notar que este timer se reinicia
en el evento de un nuevo mensaje MQTT. Cuando este timer2 llega a un valor
mayor a 2 segundos se reconoce que no existe comunicación entre la estación local
y el carlike simulado y el sistema entra en modo de desconexión.
Por otro lado, se calcula la velocidad en km/h del carlike constantemente de
acuerdo con la rotación de las llantas del carlike ya que Unity permite obtener la
información de la velocidad rotacional de las mismas.
En la función FixedUpdate que se muestra en la Figura 3.25 se verifica el estado
de la comunicación con la estación de operación al inicio, si existe comunicación
entonces se ejecutan los comandos enviadas desde la estación de operación, esto
se realiza modificando las propiedades de las Wheel collider que fueron añadidas
en las cuatro ruedas del carlike. Para acelerar el carlike, se modifica la propiedad
“motor torque” de las Wheel collider de las llantas traseras, para frenar el carlike se
modifica la propiedad “motorbreak” de las Wheel collider de las llantas traseras,
para girar las llantas delanteras se modifica la propiedad “steerAngle” de los Wheel
collider de las mismas.
Por otro lado, si se verifica que no existe comunicación, el sistema entra en el modo
sleep, donde se enceran las variables y se hace detener el carlike como medida de
seguridad.
Función Fixed Update
Estado de conexión==desconectado
Aplica las variables de aceleración o desaceleración, dirección y sentido en los objetos del carlike
Detener el carlike
no si
Figura 3.25 Función FixedUpdate.
89
Cuando el bróker envía la notificación de que existe una nueva publicación en algún
tópico. El cliente MQTT de Unity entra en una interrupción o evento como se
muestra en la Figura 3.26 en el que se guarda el mensaje recibido y se lo discrimina
de acuerdo con el tópico de la publicación para poder actualizar los comandos que
corresponda.
Al final se reinicia el timer2 que se maneja en la función Update que era el
responsable de llevar la cuenta del tiempo que transcurre desde el último dato
recibido para reconocer si existe comunicación o no con la estación local.
Evento. Mensaje MQTT recibido
Guarda el mensaje recibido
Discrimina el mensaje recibido de acuerdo al Tópico y actaliza las varablescomo la aceleracion, desaceleracion,
direccion y sentido
Reinicia el Timer 2
Función Update
Figura 3.26 Evento de mensaje MQTT recibido.
Para poder visualizar el estado de la conexión con la estación local, se incluye una
caja en la pantalla del simulador para que el operador pueda conocer el estado de
la conexión y además para que el usuario pueda reiniciar la simulación como se
muestra en la Figura 3.27.
90
Función Guide
Mostrar el estado de la conexión con la estación local
¿Se presiono el botón de reinicio?
Reiniciar el simulador
si no
Figura 3.27 Función guide de Unity.
Script de la cámara
La cámara fue programada para seguir a un solo objetivo, en este caso es el carlike
para poder visualizar por donde se está movilizando. El diagrama de bloques de la
programación de la misma se muestra en la Figura 3.28.
Inicio
Guarda el objeto Carlike en una variable publica desde el entorno virtual
Calcula la distancia entre la cámara y el carlike
Ajusta la posición de la cámara según la distancia que mantiene con el carlike
Ajusta la rotación de la cámara según la rotación del carlike
Fin
Figura 3.28 Programa de la cámara de Unity 3D.
91
3.3. PROGRAMACIÓN DEL SERVIDOR DE DATOS MQTT
Uno de los puntos más importantes en este proyecto fue implementar un canal de
comunicaciones para poder compartir información usando el Internet como medio
de comunicación entre la estación local y los modelos de los robots físico y
simulado; para llevar a cabo esta tarea se decidió utilizar el protocolo MQTT.
Figura 3.29 Arquitectura de comunicación MQTT
La arquitectura de comunicación que utiliza el protocolo MQTT es la que se muestra
en la Figura 3.29.
En este caso los clientes conectados al bróker son capaces de crear tópicos en el
mismo. Cada cliente puede suscribirse tópicos para recibir los mensajes que otro
cliente publique en dichos tópicos.
El servidor de datos está programado en una PC ubicada en la Escuela Politécnica
Nacional y que se encuentra conectada a la red interna de la misma, la cual le
provee de acceso a Internet y así mismo le provee una dirección IP publica para
que las aplicaciones puedan conectarse al mismo desde una WAN (Internet).
Este servidor de código fuente es muy ligero y no requiere de un gran ancho de
banda para poder interconectar clientes ya que trabaja con mensajes cortos y
ligeros.
La taba de tópicos que gestiona el bróker para el uso de los tres clientes como son
la estación local y los modelos de carlike físico y simulado en entorno virtual se
muestra en la Tabla 3.2.
92
Tabla 3.2 Tabla de tópicos gestionados en el bróker MQTT.
Tópico
Estación
Local
Carlike
Físico
Carlike
Simulado
Descripción
Pu
bli
caci
ón
Su
scri
pci
ón
Pu
bli
caci
ón
Su
scri
pci
ón
Pu
bli
caci
ón
Su
scri
pci
ón
real_aceleracion X X Aceleración que debe
aplicarse al robot físico.
real_sentido X X
Sentido del movimiento
hacia adelante o atrás del
robot físico.
real_direccion X X Dirección de las llantas
delanteras del robot físico.
real_odometria X X Grupo de datos
odométricos del robot físico.
sim_aceleracion X X
Aceleración que debe
aplicarse al robot del
simulado.
sim_desaceleracion X X
Desaceleración que debe
aplicarse al robot del
simulado.
sim_direccion X X
Dirección de las llantas
delanteras del robot
simulado
sim_sentido X X
Sentido del movimiento
hacia adelante o atrás del
robot físico.
sim_estado X X Estado de conexión entre la
estación y el robot
sim_odometria X X
Grupo de datos
odométricos del robot
simulado.
93
3.4. ELEMENTOS DE SOFTWARE PARA LA ESTACIÓN LOCAL
DESARROLLO DE LA INTERFAZ GRÁFICA
Para la interfaz gráfica se seleccionó Guide de Matlab como plataforma. Este
software cuenta con todos los elementos necesarios para desarrollar una interfaz
que abarque todas las funcionalidades que debe cumplir la estación local del
sistema y que sea visualmente agradable para el usuario y de fácil manejo.
Inicialmente se tiene una ventana que da la opción de escoger el entorno en el que
el usuario desee trabajar, es decir, entorno real si va a manejar el carlike físico o
entorno virtual si se desea manejar el carlike simulado. En la Figura 3.30 se observa
la pantalla de inicio.
Figura 3.30 Pantalla de inicio del sistema.
Luego de seleccionar el entorno de trabajo, independientemente de cuál sea,
aparecerá una ventana que solicitará al operador un usuario y contraseña como se
ve en la Figura 3.31. Después de ingresar los datos solicitados se da clic en aceptar
94
y se procede a la siguiente ventana que es la que opera como estación local del
sistema.
Figura 3.31 Ventana de ingreso de usuario y contraseña.
Si selecciona “Entorno Real” para manejar el robot móvil físico, aparecerá la
ventana de la Figura 3.32.
Figura 3.32 Interfaz de la estación local del sistema para el carlike físico.
95
La ventana de Estación Local cuenta con un panel de comando, un panel de
monitoreo, un indicador de conexión y un botón de salida.
El panel de comando cuenta con dos botones, uno de marcha que da inicio al
encendido del sistema, y un botón de paro que apaga el sistema. Al encenderse el
sistema se establece conexión entre la estación local y el robot móvil, esto permite
enviar los datos de ángulo, sentido y aceleración, y recibir datos de posición y
velocidad.
El ángulo de dirección varía en un rango de -20 a 20 grados [°], siendo de -20 a 0
grados [°] cuando el robot gira hacia la izquierda y de 0 a 20 grados [°] cuando el
robot gira hacia la derecha. El sentido del carlike indica si se mueve hacia adelante
o si se mueve hacia atrás. El acelerador varía de 0 a 100 por ciento [%], siendo 0
cuando el pedal está sin presionar y 100 cuando el pedal está presionado a fondo.
El panel de monitoreo muestra los datos de posición y velocidad del carlike, a partir
de estos datos se puede graficar la trayectoria que ha seguido el robot en un
determinado tiempo. Además, cuenta con un cronómetro, el cual mide el tiempo
que le ha tomado al operador terminar un circuito establecido.
El indicador de comunicación muestra si existe conexión entre la estación local y el
robot móvil, es decir, si no se recibe ningún mensaje desde el carlike en un
determinado tiempo se concluye que se ha perdido la conexión. Cuando existe
conexión el indicador es de color ‘verde’ y aparece ‘ONline’, cuando no existe
conexión el indicador es de color ‘rojo’ y aparece ‘OFFline’.
Finalmente, hay un botón de ‘SALIR’ que al dar clic cierra la ventana y envía al
operador a la pantalla de inicio del sistema. Cabe recalcar que antes de salir de la
ventana se debe apagar el sistema para cortar comunicación con el robot móvil.
Si se selecciona “Entorno Virtual” para trabajar, aparecerá la ventana de la Figura
3.33.
96
Figura 3.33 Interfaz de la estación local del sistema para el carlike simulado.
Esta ventana cuenta con los mismos componentes de la ventana de estación local
del entorno real, sin embargo, en el panel de comando hay un parámetro más que
es el ‘desacelerador’, el cual varía en un rango de 0 a 100 [%], ya que en el entorno
virtual si es viable enviar una señal para frenar más rápido el carlike.
DESARROLLO DE LA PROGRAMACIÓN DE LA INTERFAZ
La lógica de programación para que la interfaz gráfica cumpla con las funciones de
estación local para el carlike físico y el carlike simulado se presenta en el diagrama
de flujo de la Figura 3.34.
97
INICIO
Inicia comunicación con joystickSe define el diccionario JSON para recibir datos desde la estación remota
Se direcciona al cliente a la IP pública del servidorSe establece comunicación entre el cliente y el servidor
Se realiza las suscripciones a los tópicosSe crea cliente para recibir mensajeSe crea cliente para enviar mensaje
Definición de variables de posiciónInicialización de cronómetro
Botón de inicio
Si
Botón de paro
Mostrar datos de posición y velocidadToma de datos del joystick
Publicación de tópicos en el servidorVerificar estado de la comunicación entre el cliente y el servidor
No
Si
No
Figura 3.34 Funcionamiento de la interfaz de la estación local.
En la Figura 3.35 se presenta la lógica de programación de la función
‘MqttMsgPublishMRecibido’, la cual decodifica el mensaje recibido desde el robot
móvil.
98
Si
¿El tópico recibido corresponde al tópico
suscrito?
INICIO
Tomar datos de posición y velocidad
No
Definición de VariablesConversión de mensajes recibidos a String
Se toma el tópico del mensaje recibido
FIN
Figura 3.35 Función de mensaje recibido.
99
CAPÍTULO 4
PRUEBAS Y RESULTADOS
En el presente capítulo se detalla las pruebas de funcionamiento realizadas al
sistema de teleoperación para el robot móvil tipo carlike. Las pruebas se realizaron
en tres escenarios diferentes tanto para el carlike físico como para el carlike
simulado.
Para los tres escenarios siguientes la estación remota (robot móvil tipo carlike)
estará ubicada en la Escuela Politécnica Nacional. En el primer escenario la
estación local se encuentra en la misma red de la EPN. En el segundo escenario la
estación local está en Quito en un punto a 2 kilómetros de la EPN. Finalmente, en
el tercer escenario la estación local se encuentra en la ciudad de Latacunga, que
está a 96.6 kilómetros de la EPN.
Para cada escenario se describe las consideraciones tomadas en cuenta al
momento de realizar las pruebas de funcionamiento del sistema, como el
desempeño tanto del sistema total como el del operador.
4.1. METODOLOGÍA DE IMPLEMENTACIÓN DE LAS PRUEBAS
A continuación, se detalla la forma y las consideraciones necesarias que se
tomaron para realizar las pruebas del sistema de teleoperación implementado.
Estas pruebas permiten conocer las condiciones y características del canal de
comunicación, la realimentación visual y también el desempeño del operador ante
las mismas.
Las pruebas que se realizan al canal de comunicaciones permiten conocer
indicadores como el retardo de ida y vuelta (RTTD), la variación del retardo
(JITTER) y la tasa de paquetes perdidos. Estos datos son necesarios para que el
operador pueda considerarlos al momento de manejar los carlike implementados.
100
En base a las consideraciones anteriores el operador sentirá una mayor o menor
dificultad para teleoperar lo cual se verá reflejado en los resultados del número de
colisiones registradas, el tiempo que tarda en recorrer la trayectoria y el confort que
siente al teleoperar.
Cabe recalcar que en cada caso se procuró que la Estación Local y Remota cuente
en lo posible con conexiones rápidas a Internet.
ESCENARIOS DE TELEOPERACIÓN
En este apartado se muestran los 3 puntos geográficos desde los cuales se realizó
las pruebas de teleoperación.
Para probar el sistema teleoperado de este proyecto se decidió usar tres puntos
geográficamente distantes como escenarios para poder evaluar el desempeño del
sistema teleoperado y conocer la manera en la que la distancia física afecta el
rendimiento del mismo. Además, se realizaron pruebas de operación directa al
sistema para tomar sus resultados como punto de comparación con los resultados
obtenidos en los tres escenarios de teleoperación.
El tráfico en las redes tiene una relación directa al horario en el que se realizan las
pruebas ya que en el horario laboral habrá más tráfico que en los horarios no
laborables. Para la realización de estas pruebas se consideró el horario laboral, ya
que se puede conocer el desempeño del sistema ante un tráfico de red alto.
En el caso específico de este proyecto, la cámara IP del modelo físico de carlike
implementado debe estar conectado a una red interna de la Escuela Politécnica
Nacional, ya que la misma le provee de una dirección IP pública para poder acceder
a ella desde el Internet. Por el motivo anterior los modelos físico y simulado de
carlike (Estación remota) deben ubicarse dentro de la Escuela Politécnica Nacional
en este caso en el laboratorio de Unmanned Aerial Vehicles (UAV’s) ubicado en el
edificio EARME del centro de educación continua CEC de la EPN, mientras que la
estación de operación (Estación Local) se ubica en puntos geográficos diferentes
para poder realizar las pruebas de teleoperación.
101
Prueba Ideal
La prueba ideal se realiza cuando el operador se encuentra directamente en la
misma locación de la estación remota, en este caso no influirá el retardo del video
ya que el operador podrá observar directamente el comportamiento del robot físico
o simulado.
Esta prueba sirve como entrenamiento para el operador, además que sus
resultados sirven como referencia para comparar los resultados que arrojan las
demás pruebas de teleoperación en los tres escenarios planteados.
Escenario 1. Teleoperación En La Misma Red
Para la primera prueba se eligió como lugar para la Estación local el laboratorio de
Informática ubicado en el sexto piso del edificio de Química y Eléctrica de la EPN.
Este lugar fue elegido ya que dispone de varios puntos de red directos para poder
tener una mejor conexión de Internet.
En esta prueba la estación local y la estación remota se encuentran relativamente
cerca, por ello es considerada como ideal y servirá para hacer contraste con las
demás pruebas en puntos geográficamente diferentes.
Escenario 2. Teleoperación En La Misma Ciudad
Para la segunda prueba se eligió un punto ubicado en la misma ciudad a 1.5 km en
línea recta.
En este caso se podrá comprobar el funcionamiento de los protocolos en un
ambiente real de tráfico y se podrá verificar el retardo debido a los diferentes
procesamientos de las redes sobre el servicio de Internet.
102
Figura 4.1 Punto geográfico de teleoperación para el escenario 2.
Escenario 3. Teleoperación Quito-Latacunga
Para la tercera prueba se eligió un punto ubicado en la ciudad de Latacunga a 75
km en línea recta.
En este se podrá verificar en mayor medida los efectos de las redes del Internet
que se reflejan como retardos en la comunicación entre los clientes MQTT.
Figura 4.2 Punto geográfico de teleoperación escenario 3.
103
PRUEBAS AL CANAL DE COMUNICACIÓN DE DATOS
A continuación, se muestran las pruebas realizadas al canal de comunicaciones
para poder conocer el desempeño del protocolo de comunicaciones ante las
condiciones de la red.
Retardo de Ida y Vuelta (Round Trip Time Delay)
El retardo de ida y vuelta es el tiempo que tarda un mensaje en ir desde la Estación
local al bróker MQTT, desde el bróker MQTT hasta el carlike, desde el carlike de
vuelta hacia el bróker y desde el bróker de vuelta hacia la Estación local.
+||} = $~b,��>B@�����?� K $����?��~b,�?��,B K $~b,�?��,B�����?�
K $����?��~b,��>B@
(4.1)!
Este parámetro es muy importante debido a que presenta características reales del
comportamiento del canal de comunicaciones en la red e influirá directamente en
la maniobrabilidad del sistema teleoperado entorpeciendo en mayor o menor
medida el comando por parte del operador.
Para obtener este parámetro se usó un timer en la estación local, el timer empieza
a contar el tiempo cuando la estación local envía un mensaje hacia la estación
remota, el tiempo sigue contando mientras el mensaje viaja hasta la estación
remota y esta responde con otro mensaje hacia la estación local. El timer se detiene
cuando la estación local recibe el mensaje de respuesta de la estación remota.
Para implementar el temporizador en Matlab se usaron los comandos “tic” y “toc”.
El comando “tic” se usa para iniciar el timer y el comando “toc” se usa para conocer
el valor del timer cuando el mensaje de respuesta es recibido. La metodología que
se usó para obtener el RTTD se muestra en la Figura 4.3.
104
INICIO
Conectar el cliente MQTT
Enviar un mensaje MQTT a la estación remota
Inicia el timer
Evento de recepción de mensaje MQTT
Finaliza el timer
Guarda el dato de RTTD
Calcula el RTTD promedio
Calcula el jitter
INICIO
Conectar el cliente MQTT
Evento de recepción de mensaje MQTT
Procesa el mensaje
Envía un mensaje MQTT de respuesta a la estación local
Estación Local Estación Remota
Figura 4.3 Metodología de toma de datos de RTTD.
Jitter (Fluctuación)
Este indicador permite conocer, como su nombre lo indica, que tanto varía el retardo
respecto a su valor medio.
Este parámetro se calcula cada vez que se registra un nuevo valor de RTTD y se
calcula como el valor absoluto del último valor de RTTD registrado menos el valor
medio de RTTD de todos los datos registrados.
jP$$Xk[P] = �kX$\kg^[P] l VXgP\(kX$\kg^[0� P])� (4.2)!
105
Los valores de Jitter se calculan cada vez que se mide un valor de retardo, y al igual
que los datos de retardo se guardan en una matriz para poder analizarlos
posteriormente.
Tasa de Paquetes Perdidos
En este caso el cálculo de los paquetes perdidos se realiza al terminar las pruebas,
es decir al final de tomar datos de RTTD, se cuentan los paquetes enviados y
recibidos, se los compara y se determina cuántos de estos datos enviados no han
sido recibidos en la estación remota.
DW\�UX$XZ/WXkgPg^Z =
:X6Z\jXZ/X6#P\g^Z~b,B>�óN/@�>B@ l:X6Z\jXZ/kX_PePg^Z~b,B>�óN/�?��,B
:X6Z\jXZ/X6#P\g^Z~b,B>�óN/@�>B@
(4.3)!
PRUEBAS AL MEDIO DE REALIMENTACIÓN VISUAL
En este proyecto la realimentación visual cobra una importancia muy alta debido a
que es el único medio de telepresencia para el teleoperador y solo en base a este
medio el operador podrá tomar decisiones para completar la tarea propuesta.
Una de las características más relevantes de la realimentación visual es el retardo
que demuestra en viajar desde el punto de origen en la estación remota hasta el
punto de llegada en la estación local.
Para poder cuantificar el retardo de la realimentación visual se ha establecido la
siguiente metodología para la implementación de la prueba. En la estación local y
en la estación remota se tienen cronómetros, ambos cronómetros empiezan ante
la orden de inicio del usuario ubicado en la estación local. Cuando el usuario da la
orden de inicio para el cronómetro, un mensaje de inicio es enviado vía protocolo
MQTT hacia el cronómetro de la estación remota, de esta manera se sincronizan
ambos cronómetros en la estación local y en la estación remota con una diferencia
en el orden de las decenas de ms debido al protocolo MQTT que es mucho menor
al retardo mismo del video.
106
INICIO
ESTACIÓN LOCAL
Conectar el cliente mqtt
¿Se pulso el botón de inicio?
Se inicia el contador de tiempo
¿Se pulso el botón de fin?
Enviar mensaje mqtt de inicio
Enviar mensaje mqtt de fin
Se para el contador de tiempo
sino
Mostrar el contador de tiempo
sino
ESTACIÓN REMOTA
INICIO
Conectar el cliente mqtt
Evento de recepcion de mensaje mqtt de
inicio
Se inicia el contador de tiempo
Mostrar el contador de tiempo
Evento de recepción de mensaje mqtt de fin
Se para el contador de tiempo
FIN
Figura 4.4 Diagrama de flujo de sincronización de cronómetros.
Cuando los cronómetros están sincronizados, se realimenta visualmente el
cronometro de la estación remota hacia la estación local usando el mecanismo
correspondiente: Cámara IP en el caso del robot físico y Team Viewer en el caso
del robot simulado. Teniendo el cronómetro sincronizado de la estación remota
reflejado en la estación local, se puede contrastar el valor que muestran los dos
cronómetros y la diferencia entre ellos se puede reconocer como el retardo
existente para la realimentación visual.
Se grabó en video ambos cronómetros, el de la estación local y el de la estación
remota reflejado en la estación local, para poder registrar el retardo y analizar la
información posteriormente.
107
PRUEBAS AL OPERADOR
A continuación, se muestran las pruebas que fueron realizadas para conocer el
desempeño del operador al teleoperar en los distintos escenarios mostrados.
El carlike físico se lo manejó en una pista con la forma de la Figura 4.5.
Figura 4.5 Pista del carlike físico
El recorrido para el carlike simulado es el que se muestra en la Figura 4.6.
Figura 4.6 Recorrido del carlike simulado.
Tiempo de Ejecución de la Tarea
El tiempo de ejecución de la tarea es el tiempo que el operador tarda en recorrer
todo el circuito. Este tiempo será variable dependiendo de las características del
108
circuito, de la experiencia que tenga el operador sobre un entorno determinado, y
del retardo en la transmisión de video.
Número de Colisiones
Tomando en cuenta que el circuito usado para las pruebas de funcionamiento es
una superficie lisa y consta de cinco curvas, el número de colisiones dependen de
la habilidad del operador para comandar el robot móvil y del retardo de video que
exista.
Maniobrabilidad
La maniobrabilidad del sistema se determina dependiendo de la facilidad de
maniobra que existe sobre el sistema. El uso del joystick, la visualización de la
interfaz gráfica y la realimentación visual, en conjunto, proporcionan un buen
manejo y confort del sistema.
La maniobrabilidad del sistema se verá opacada debido a la distancia física, esto
se refleja en los resultados de las encuestas realizadas al operador para calificar
su apreciación sobre el sistema en los distintos escenarios.
4.2. RECOLECCIÓN DE DATOS
En este apartado se muestran los datos que se recogieron a partir de la realización
de las pruebas de teleoperación en los distintos escenarios propuestos.
DATOS RECOGIDOS DE LA TELEOPERACIÓN PARA EL CARLIKE
FÍSICO
En el apartado anterior se mostró la metodología de la realización de las pruebas y
los datos de importancia que se deben recoger. A continuación, se muestran los
datos experimentales recogidos de las diferentes pruebas de teleoperación para el
carlike físico en los diferentes escenarios.
109
Prueba Ideal
En la prueba ideal debido a que el operador comanda directamente el carlike se
obvian los datos del comportamiento de la red y de la cámara IP. Sólo se consideran
los datos del tiempo de ejecución de la tarea y del número de colisiones para poder
comparar luego con los resultados de las pruebas en los demás escenarios.
Tabla 4.1 Datos obtenidos en la prueba ideal
ROBOT REAL
PRUEBA IDEAL No. Prueba Tiempo de ejecución de la tarea[s] No. de Colisiones
1 26 0 2 31 0 3 32 0 4 25 0 5 28 0
PROMEDIO 28 0
Escenario 1. Teleoperación Desde La Misma Red
A continuación, se muestran los resultados de las pruebas en este escenario.
RTTD en el canal de comunicación de datos
En la prueba de retardo de ida y vuelta (RTTD) se obtuvieron los resultados que se
muestran en la Figura 4.7.
Figura 4.7 RTTD de datos en teleoperación en la misma red.
0
100
200
300
400
500
600
700
800
900
1000
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Ret
ard
o d
e Id
a y
Vu
elta
(m
s)
Número de Muestra
RTTD(ms) Promedio(145.2 ms)
110
Los datos estadísticos se muestran en la Tabla 4.2. Como se aprecia 145.2
milisegundos es el valor promedio de llegada de datos desde la estación local a la
estación remota.
Tabla 4.2 Datos estadísticos de pruebas del RTTD
RTTD Tiempo [ms]
Valor Promedio 145.2
Desviación Estándar 106.75
Valor Máximo 493.7
Valor Mínimo 30.81
Jitter
La varianza del RTTD o Jitter se muestra en la Figura 4.8, donde se puede observar
que el valor promedio es 98.65 ms.
Figura 4.8 Jitter del RTTD de datos en teleoperación en la misma red.
Tasa de paquetes perdidos
En esta prueba se enviaron 150 datos desde la estación local y en la estación
remota se recibieron los mismos 150 datos. Experimentalmente se registró que
todos los datos que fueron enviados desde la estación local a la estación remota
fueron recibidos exitosamente, registrándose así una tasa de paquetes perdidos de
0%.
0
50
100
150
200
250
300
350
400
450
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Jitt
er(m
s)
Número de Muestra
JITTER(ms) Promedio(95.68 ms)
111
Retardo de la realimentación visual
Para el caso de la realimentación visual provista por la cámara IP se recogieron los
150 datos que se muestran en la Figura 4.9.
Figura 4.9 Retardo de video en la teleoperación en la misma red
De la Figura 4.9 se tienen los siguientes datos estadísticos en la Tabla 4.3.
Tabla 4.3 Datos estadísticos del retardo visual
Retardo de Video Tiempo [ms]
Valor Promedio 799.28
Desviación Estándar 221.1
Valor Máximo 2818
Valor Mínimo 586.8
En comparación al retardo de datos, el retardo de video es considerable. Esto
afecta al maniobrar el robot móvil ya que la actualización de la imagen de video
debería ser rápida y constante.
Tiempo de ejecución de la tarea
Para el tiempo de ejecución de la tarea se realizó cinco intentos para que el
operador complete el circuito.
0
0.5
1
1.5
2
2.5
3
1 7
13
19
25
31
37
43
49
55
61
67
73
79
85
91
97
10
3
10
9
11
5
12
1
12
7
13
3
13
9
14
5
15
1Ret
ard
o d
e V
ideo
(s)
Número de Muestra
Retardo de video en la misma red Retardo promedio: 799.28ms
112
Figura 4.10 Tiempos de ejecución de la tarea en la misma red.
Los datos estadísticos de la Figura 4.10 se muestran en la Tabla 4.4.
Tabla 4.4 Datos estadísticos del tiempo de ejecución de la tarea
Tiempo más alto de ejecución de la tarea 57 [s]
Tiempo más bajo de ejecución de la tarea 52 [s]
El tiempo de ejecución de la tarea a partir del segundo intento disminuye, esto es
debido a que el operador va adquiriendo experiencia y conoce mejor el entorno en
el que se encuentra el robot móvil.
Número de colisiones
En las pruebas en este escenario no se registraron colisiones.
Maniobrabilidad.
Conforme aumenta la experiencia del operador, aumenta la maniobrabilidad que
tiene sobre el robot móvil.
Escenario 2. Teleoperación desde la Misma Ciudad
A continuación, se muestran los resultados de las pruebas de teleoperación en la
misma ciudad.
49
50
51
52
53
54
55
56
57
58
1 2 3 4 5
Tiem
po
de
ejec
uci
ón
de
la t
area
(s)
Número de Prueba
113
RTTD en el canal de comunicación de datos
En la prueba de retardo de ida y vuelta (RTTD) se obtuvieron los resultados que se
muestran en la Figura 4.11.
Figura 4.11 RTTD de datos en teleoperación en la misma ciudad.
Los datos estadísticos son los que se muestran en la Tabla 4.5.
Tabla 4.5 Datos estadísticos del RTTD en el escenario 2
RTTD Tiempo [ms]
Valor Promedio 207.93
Desviación Estándar 41.28
Valor Máximo 940.28
Valor Mínimo 141.28
En este escenario el valor promedio aumenta en comparación al escenario anterior.
Esto se debe a que la distancia física entre la estación local y remota también ha
aumentado.
Jitter
La varianza del RTTD o Jitter se muestra en la Figura 4.12, donde el valor promedio
alcanza un valor de 56.27 ms.
0
100
200
300
400
500
600
700
800
900
10001 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Ret
ard
o d
e Id
a y
Vu
elta
(m
s)
Número de Muestra
RTTD (ms) Promedio: 207.93ms
114
Figura 4.12 Jitter del RTTD de datos en teleoperación en la misma ciudad
En este escenario el valor del Jitter disminuye en comparación al anterior, esto
ayuda a una mejor maniobrabilidad sobre el robot móvil.
Tasa de paquetes perdidos
Se enviaron 150 datos desde la estación local, a la estación remota. Se registró
que todos los datos que fueron recibidos exitosamente, registrándose así una la
tasa de paquetes perdidos de 0%.
Retardo de la realimentación visual
Para la realimentación visual provista por la cámara IP se recogieron los 150 datos
que se muestran en la Figura 4.13.
Figura 4.13 Retardo de video en la teleoperación en la misma ciudad
0
100
200
300
400
500
600
700
800
900
1 7
13
19
25
31
37
43
49
55
61
67
73
79
85
91
97
10
3
10
9
11
5
12
1
12
7
13
3
13
9
14
5
Jitt
er (
ms)
Número de Muestra
JITTER(ms) Promedio(56.27ms)
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1 7
13
19
25
31
37
43
49
55
61
67
73
79
85
91
97
10
3
10
9
11
5
12
1
12
7
13
3
13
9
14
5
15
1
Ret
ard
o d
e V
ideo
(s)
Número de Muestra
Retardo de video en la misma ciudad Retardo promedio: 817,24ms
115
De la Figura 4.13 se tienen los siguientes datos estadísticos en la Tabla 4.6.
Tabla 4.6 Datos estadísticos del retardo visual en el escenario 2.
Retardo de Video Tiempo [ms]
Valor Promedio 817.24
Desviación Estándar 108.09
Valor Máximo 1409.6
Valor Mínimo 303.7
El retardo de video aumenta muy poco en comparación al valor del escenario
anterior, pero siguen siendo valores considerables que afectan la maniobrabilidad
del robot móvil.
Tiempo de ejecución de la tarea
En la Figura 4.14 se observa el tiempo que le tomó al operador completar el circuito
en cada intento.
Figura 4.14 Tiempos de ejecución de la tarea en la misma ciudad
Los datos estadísticos son los que se muestran en la Tabla 4.7.
Tabla 4.7 Datos estadísticos de tiempo de ejecución de la tarea en el escenario 2
Tiempo más alto de ejecución de la tarea 160 [s]
Tiempo más bajo de ejecución de la tarea 122 [s]
0
20
40
60
80
100
120
140
160
180
1 2 3 4 5
Tiem
po
de
ejec
uci
ón
de
la t
area
(s)
Número de prueba
116
El tiempo de ejecución de la tarea aumenta de manera considerable en
comparación al escenario anterior. Esto se debe a que el operador tiene mayor
dificultad de reconocer el entorno por el retardo en la realimentación visual.
Número de colisiones
En cada intento se contó cuantas colisiones sufre el robot móvil.
Figura 4.15 Número de colisiones en la misma ciudad
Maniobrabilidad.
Tomando en cuenta que en este escenario si existen colisiones, debido a que por
cada intento se registra una colisión. Además, el tiempo de ejecución de la tarea
aumenta a casi el triple del valor del primer escenario, se concluye que el operador
tiene mayor dificultad para maniobrar el robot móvil.
Escenario 3. Teleoperación Latacunga - Quito
A continuación, se muestran los resultados de las pruebas de teleoperación en una
ciudad diferente, en este caso desde Latacunga.
RTTD en el canal de comunicación de datos
En la prueba de retardo de ida y vuelta (RTTD) se obtuvieron los resultados que se
muestran en la Figura 4.16.
0
1
2
3
0 1 2 3 4 5 6
Nú
mer
o d
e co
lisio
nes
Número de prueba
117
Figura 4.16 RTTD de datos en teleoperación Latacunga-Quito
Los datos estadísticos son los que se muestran en la Tabla 4.8. El valor promedio
del RTTD ha aumentado en comparación a los dos escenarios anteriores. Esto es
debido a que la estación local y remota se encuentra a una distancia física mucho
mayor que en los dos casos anteriores.
Tabla 4.8 Datos estadísticos del RTTD en el escenario 3
RTTD Tiempo [ms]
Valor Promedio 298.52
Desviación Estándar 124.98
Valor Máximo 1466
Valor Mínimo 124.98
Jitter
La varianza del RTTD o Jitter se muestra en la Figura 4.17, donde el valor promedio
alcanza los 134.25 ms.
0
200
400
600
800
1000
1200
1400
1600
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Ret
ard
o d
e Id
a y
Vu
elta
(s)
Número de Muestra
RTTD (ms) Promedio: 298.52ms
118
Figura 4.17 Jitter del RTTD de datos en teleoperación Latacunga-Quito
Tasa de paquetes perdidos
Experimentalmente se registró que todos los datos que fueron enviados desde la
estación local a la estación remota fueron recibidos exitosamente, registrándose así
una la tasa de paquetes perdidos de 0%.
Retardo de la realimentación visual
Para el caso de la realimentación visual provista por la cámara IP se recogieron los
150 datos que se muestran en la Figura 4.18.
Figura 4.18 Retardo de video en la teleoperación Latacunga Quito.
De la Figura 4.18 se tienen los siguientes datos estadísticos en la Tabla 4.9. En
este caso el valor promedio del retardo de video aumenta considerablemente, esto
afecta directamente en la maniobrabilidad del robot móvil, ya que el operador
observa el entorno del robot móvil 1.678 segundos después.
0
200400
600800
10001200
1400
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Jitt
er (
ms)
Número de Muestra
JITTER(ms) Promedio: 134.25ms
00.5
11.5
22.5
3
1 7
13
19
25
31
37
43
49
55
61
67
73
79
85
91
97
10
3
10
9
11
5
12
1
12
7
13
3
13
9
14
5
15
1Ret
ard
o d
e V
ideo
(s)
Número de Muestra
Retardo de video en otra ciudad Retardo promedio: 1,678 s
119
Tabla 4.9 Datos representativos del retardo visual escenario 3.
Retardo de Video Tiempo [ms]
Valor Promedio 1678
Desviación Estándar 286.66
Valor Máximo 2808
Valor Mínimo 1297.5
Tiempo de ejecución de la tarea
Se observa el tiempo que tomó cada intento ejecutar la tarea en este escenario.
Como se puede apreciar el Figura 4.19 el tiempo de ejecución de la tarea es mucho
más alto que en los dos escenarios anteriores, esto se produce porque la imagen
de la realimentación visual no se actualiza rápidamente y el operador debe esperar
a tener una imagen actualizada.
Figura 4.19 Tiempos de ejecución de la tarea Latacunga-Quito.
Los datos estadísticos son los que se muestran en la Tabla 4.10.
Tabla 4.10 Datos estadísticos de tiempo de ejecución en el escenario 3.
Tiempo más alto de ejecución de la tarea 155 [s]
Tiempo más bajo de ejecución de la tarea 101 [s]
Número de colisiones
En cada número de prueba se considera cuantas colisiones sufre el robot móvil.
0
20
40
60
80
100
120
140
160
180
1 2 3 4 5
Tiem
po
de
ejec
uci
ón
de
la t
area
(s)
Número de prueba
120
Figura 4.20 Número de colisiones en cada prueba Latacunga-Quito.
Maniobrabilidad.
En este escenario el número de colisiones disminuyó en comparación al anterior,
pero el tiempo promedio de ejecución de la tarea aumentó por lo que la
maniobrabilidad en el anterior escenario y en este sería similar.
DATOS RECOGIDOS DE LA TELEOPERACIÓN PARA EL CARLIKE
SIMULADO
A continuación, se muestran los datos experimentales recogidos de las diferentes
pruebas de teleoperación del carlike simulado en los diferentes escenarios.
Prueba Ideal
En la prueba ideal debido a que el operador comanda directamente el carlike
simulado solo se consideran los datos del tiempo de ejecución de la tarea y del
número de colisiones para comparar con los resultados de las pruebas en los
demás escenarios, y se obvian los datos del comportamiento de la red y del uso de
TeamViewer como realimentación visual. En el carlike simulado el circuito que
debe completar es de mayor distancia que en el carlike físico, por lo cual los tiempos
de ejecución de la tarea serán mayores.
0
1
2
3
0 1 2 3 4 5 6
Nú
mer
o d
e co
lisio
nes
Número de prueba
121
Tabla 4.11 Datos obtenidos en la prueba ideal
ROBOT SIMULADO
PRUEBA IDEAL
No. Prueba Tiempo de ejecución de la tarea [s] No. de Colisiones
1 177 0
2 160 0
3 157 0
4 151 0
5 167 0
PROMEDIO 162 0
Escenario 1. Teleoperación desde la Misma Red
A continuación, se muestran los resultados de las pruebas de teleoperación en la
misma red, la cual, servirá para contrastar con las demás pruebas.
RTTD en el canal de comunicación de datos
En la prueba de retardo de ida y vuelta se obtuvieron los resultados que se
muestran en la Figura 4.21.
Figura 4.21 RTTD de datos en teleoperación en la misma red
Los datos estadísticos son los que se muestran en la Tabla 4.12.
0
50
100
150
200
250
300
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Ret
ard
o d
e Id
a y
Vu
elta
(m
s)
Número de Muestra
RTTD(ms) Promedio(48.45 ms)
122
Tabla 4.12 Datos estadísticos del RTTD en el escenario 1.
RTTD Tiempo [ms]
Valor Promedio 48.45
Desviación Estándar 24.73
Valor Máximo 247.85
Valor Mínimo 13.16
El valor promedio del RTTD es 48.45 ms. Cabe mencionar que, al encontrarse en
la misma red, el retardo será mínimo, por lo tanto, en este escenario se considera
el RTTD como bajo.
Jitter
La varianza del RTTD o Jitter se muestra en la Figura 4.22, donde se puede
observar que el valor promedio alcanza los 12 ms. En este escenario el Jitter es
bajo, lo cual favorece al manejo del robot móvil.
Figura 4.22 Jitter del RTTD de datos en teleoperación en la misma red
Tasa de paquetes perdidos
En esta prueba se enviaron 150 datos desde la estación local, se registró que todos
estos datos que fueron enviados a la estación remota fueron recibidos
exitosamente, registrándose así una la tasa de paquetes perdidos de 0%.
0
50
100
150
200
250
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Jitt
er (
ms)
Número de Muestra
JITTER en la misma red Promedio(12ms)
123
Retardo de la realimentación visual
En la realimentación visual provista por TeamViewer se recogieron los 150 datos
que se muestran en la Figura 4.23.
Figura 4.23 Retardo de video en la teleoperación en la misma red.
De la Figura 4.23 se tienen los siguientes datos estadísticos.
Tabla 4.13 Datos estadísticos de retardo visual escenario 1.
Retardo de Video Tiempo [ms]
Valor Promedio 682.9
Desviación Estándar 349.97
Valor Máximo 1801.6
Valor Mínimo 219.7
El retardo de video es bastante alto en comparación al RTTD. Como se puede
apreciar este retardo es más de medio segundo, esto afecta en la maniobrabilidad
del robot móvil debido a que el operador no ve en tiempo real el entorno del robot.
Tiempo de ejecución de la tarea
En cada intento se tomó el tiempo que el operador tarda en completar el circuito.
0.00.2
0.40.60.81.01.21.41.61.8
2.0
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
15
1
Ret
ard
o d
e V
ideo
(s)
Número de Muestra
Retardo de video en la misma red Retardo promedio
124
Figura 4.24 Tiempos de ejecución de la tarea en la misma red.
Los datos se muestran en la Tabla 4.14. Como se observa, el tiempo que tarda
Tabla 4.14 Datos estadísticos del tiempo de ejecución de tarea escenario 1.
Tiempo más alto de ejecución de la tarea 313 [s]
Tiempo más bajo de ejecución de la tarea 258 [s]
El tiempo de ejecución de la tarea para este escenario se duplica en comparación
a prueba ideal realizada. Debido a que la realimentación visual tiene un retardo
considerable el operador tiene más dificultades para maniobrar el sistema.
Número de colisiones
En este escenario no se produjo ninguna colisión. A pesar del alto retardo en la
realimentación visual, la experiencia del operador ayuda a que no existan
colisiones.
Maniobrabilidad.
Tomando en cuenta que el número de colisiones es cero y que el tiempo de
ejecución de la tarea es alto se concluye que para este escenario la maniobrabilidad
es ‘buena’.
0
50
100
150
200
250
300
350
1 2 3 4 5
Tiem
po
de
ejec
uci
ón
de
la t
area
(s)
Número de prueba
125
Escenario 2. Teleoperación desde la Misma Ciudad
A continuación, se muestran los resultados de las pruebas de teleoperación en la
misma ciudad. El operador comandó el robot móvil desde un punto ubicado fuera
de la EPN pero dentro de la ciudad de Quito.
RTTD en el canal de comunicación de datos
En la prueba de retardo de ida y vuelta se obtuvieron los resultados que se
muestran en la Figura 4.25.
Figura 4.25 RTTD de datos en teleoperación en la misma ciudad.
Los datos estadísticos son los que se muestran en la Tabla 4.15.
Tabla 4.15 Datos estadísticos del RTTD en el escenario 2.
RTTD Tiempo [ms]
Valor Promedio 72.73
Desviación Estándar 146.46
Valor Máximo 1588
Valor Mínimo 57
El valor promedio del RTTD aumenta en comparación al escenario anterior, pero
sigue siendo un valor pequeño, lo cual, no representa problemas para el envío de
datos. También se puede apreciar que existen picos en los cuales el RTTD alcanza
su máximo o su mínimo valor.
0
200
400
600
800
1000
1200
1400
1600
1800
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Ret
ard
o d
e Id
a y
Vu
elta
(m
s)
Número de Muestra
RTTD(ms) Promedio(72.73 ms)
126
Jitter
La varianza del RTTD o Jitter se muestra en la Figura 4.26, donde se puede
observar que el valor promedio alcanza los 47.37 ms.
Figura 4.26 Jitter del RTTD de datos en teleoperación en la misma red.
El Jitter aumenta cuatro veces su valor con respecto al escenario anterior, pero
sigue siendo de bajo valor, así que no afecta al envío y recepción de datos.
Tasa de paquetes perdidos
En esta prueba se enviaron 150 datos desde la estación local y en la estación
remota se recibieron los mismos 150 datos.
Experimentalmente se registró que todos los datos que fueron enviados desde la
estación local a la estación remota fueron recibidos exitosamente, registrándose así
una la tasa de paquetes perdidos de 0%.
Retardo de la realimentación visual
En la realimentación visual proporcionada por TeamViewer se recogieron los 150
datos que se muestran en la Figura 4.27. Se puede observar que se presenta un
pico de alto valor, pero en general el retardo se mantiene constante.
0
200
400
600
800
1000
1200
1400
1600
18001 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Jitt
er (
ms)
Número de Muestra
JITTER en la misma ciudad Promedio(47.37 ms)
127
Figura 4.27 Retardo de video en la teleoperación en la misma ciudad.
De la Figura 4.27 se tienen los siguientes datos estadísticos.
Tabla 4.16 Datos estadísticos del retardo de video escenario 2
Retardo de Video Tiempo [ms]
Valor Promedio 970.8
Desviación Estándar 0.3595
Valor Máximo 3801
Valor Mínimo 490
El retardo de video aumenta con respecto al escenario anterior, casi alcanza el valor
de un segundo. Esto es debido a que la estación local y remota se encuentra a
mayor distancia, provocando así que el retardo incremente. Este retardo afecta más
al sistema que el RTTD.
Tiempo de ejecución de la tarea
Para el tiempo de ejecución de la tarea se realizó cinco intentos para que el
operador complete el circuito. Este tiempo depende más del valor de retardo de
video que del RTTD ya que el operador necesita conocer el entorno del robot móvil
para poder tener buena maniobrabilidad sobre este, y así finalizar el circuito.
00.5
11.5
22.5
33.5
4
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
15
1
Ret
ard
o d
e V
ideo
(s)
Número de Muestras
Retardo de video en la misma ciudad Retardo promedio
128
Figura 4.28 Tiempos de ejecución de la tarea en la misma ciudad.
Los datos estadísticos son los que se muestran en la Tabla 4.17
Tabla 4.17 Datos estadísticos de tiempo de ejecución de la tarea escenario 2.
Tiempo más alto de ejecución de la tarea 476 [s]
Tiempo más bajo de ejecución de la tarea 425 [s]
Se observa que el tiempo de ejecución de la tarea ha incrementado en comparación
al escenario anterior. Esto es debido a que el operador debe manejar el móvil a
baja velocidad.
Número de colisiones
Se observa que en los cinco intentos sólo se presentó una colisión.
Figura 4.29 Número de colisiones en cada prueba en la misma ciudad.
390
400
410
420
430
440
450
460
470
480
1 2 3 4 5
Tiem
po
de
ejec
uci
ón
de
la t
area
(s)
Número de prueba
0
1
2
3
0 1 2 3 4 5 6
Nú
mer
o d
e co
lisio
nes
Número de prueba
129
Maniobrabilidad.
Si bien el tiempo de ejecución aumentó, el número de colisiones es casi nulo. Esto
es debido a que el operador maneja a baja velocidad para evitar colisiones, bajo
estas condiciones se puede determinar el robot móvil es maniobrable.
Escenario 3. Teleoperación Latacunga - Quito
A continuación, se muestran los resultados de las pruebas de teleoperación en una
ciudad diferente, en este caso desde Latacunga.
RTTD en el canal de comunicación de datos
En la prueba de retardo de ida y vuelta se obtuvieron los resultados que se
muestran en la Figura 4.30.
Figura 4.30 RTTD de datos en teleoperación Latacunga-Quito.
Los datos estadísticos son los que se muestran en la Tabla 4.18. En este escenario
el RTTD promedio aumenta de forma considerable con respecto al anterior
escenario.
0
100
200
300
400
500
600
700
800
900
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Ret
ard
o Id
a y
Vu
elta
(m
s)
Número de muestras
RTTD(ms) Promedio(226.27 ms)
130
Tabla 4.18 Datos estadísticos de RTTD escenario 3.
RTTD Tiempo [ms]
Valor Promedio 226.27
Desviación Estándar 126.43
Valor Máximo 836.41
Valor Mínimo 110.91
El valor promedio del RTTD a pesar de ser más alto que en los anteriores
escenarios, sigue teniendo un bajo valor.
Jitter
La varianza del RTTD o Jitter se muestra en la Figura 4.31, donde se puede
observar que el promedio alcanza un valor de 97.1 ms.
Figura 4.31 Jitter del RTTD de datos en teleoperación Latacunga-Quito.
El valor del Jitter aumenta, con respecto a los escenarios anteriores.
Tasa de paquetes perdidos
Experimentalmente se registró que todos los datos que fueron enviados desde la
estación local a la estación remota fueron recibidos exitosamente, registrándose así
una la tasa de paquetes perdidos de 0%.
0100
200300
400500
600700
800
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Jitt
er (
ms)
Número de Muestra
JITTER en una ciudad diferente Promedio(97.1ms)
131
Retardo de la realimentación visual
Con la ayuda del TeamViewer se recogieron los 150 datos que se muestran en la
Figura 4.32.
Figura 4.32 Retardo de video en la teleoperación Latacunga Quito.
De la Figura 4.32 se tienen los siguientes datos estadísticos.
Tabla 4.19 Datos representativos de retardo de video escenario 3.
Retardo de Video Tiempo [ms]
Valor Promedio 1210.8
Desviación Estándar 380.53
Valor Máximo 2835.6
Valor Mínimo 320.3
En este caso el valor promedio del retardo de video rodea el un segundo. Este valor
afecta al sistema, debido a que el operador no goza de una buena telepresencia
para manejar el robot móvil,
Tiempo de ejecución de la tarea
El tiempo de ejecución de la tarea rodea los siete minutos. Se debe tomar en cuenta
que en este escenario la estación local se encuentra a una distancia física
considerable, por lo cual, el operador tiene mayor dificultad para manejar el robot
móvil.
0
0.5
1
1.5
2
2.5
3
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
15
1Ret
ard
o d
e V
ideo
(s)
Número de Muestras
Retardo de video en otra ciudad Retardo promedio
132
Figura 4.33 Tiempos de ejecución de la tarea Latacunga-Quito.
Los datos estadísticos son los que se muestran en la Tabla 4.20.
Tabla 4.20 Datos estadísticos de tiempo de ejecución de la tarea escenario 3.
Tiempo más alto de ejecución de la tarea 489 [s]
Tiempo más bajo de ejecución de la tarea 421 [s]
Número de colisiones
En este escenario aumenta el número de colisiones, debido a que el operador no
tiene una buena realimentación visual.
Figura 4.34 Número de colisiones en cada prueba Latacunga-Quito.
380
400
420
440
460
480
500
520
1 2 3 4 5
Tiem
po
de
ejec
uci
ón
de
la t
area
(s)
Número de prueba
0
1
2
3
4
0 1 2 3 4 5 6
Nú
mer
o d
eco
lisio
nes
Número de prueba
133
Maniobrabilidad.
El tiempo de ejecución de la tarea aumentó con respecto al escenario anterior, pero
el número de colisiones es mínimo, por lo cual, la maniobrabilidad del sistema en
este escenario es ‘buena’.
4.3. ANÁLISIS DE DATOS
En el apartado anterior se mostraron los datos recogidos experimentalmente de la
teleoperación de los modelos físico y simulado de carlike, en este apartado se
muestra un análisis comparativo de los resultados obtenidos para poder distinguir
los efectos provocados por la distancia física, el rendimiento del canal de
comunicaciones y la teleoperabilidad del sistema en general.
TELEOPERACIÓN PARA EL CARLIKE FÍSICO
A continuación, se analizan los datos recogidos de la teleoperación del modelo
físico de carlike.
RTTD en el Canal de Comunicación de Datos
En la Figura 4.35 se muestran los valores de RTTD obtenidos experimentalmente
en los 3 escenarios propuestos.
Figura 4.35 Comparación de los valores de RTTD en los tres escenarios propuestos.
0
200
400
600
800
1000
1200
1400
1600
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6Ret
ard
o d
e Id
a y
Vu
elta
(m
s)
Número de Muestra
RTTD EN LA MISMA RED RTTD EN LA MISMA CIUDAD RTTD EN UNA CIUDAD DIFERENTE
134
Tabla 4.21 Comparación de RTTD en los 3 escenarios.
RTTD Valor Promedio [ms]
EN LA MISMA RED 145.42
EN LA MISMA CIUDAD 207.93
EN UNA CIUDAD DIFERENTE 298.52
En la Figura 4.35 y en la Tabla 4.21, se puede apreciar que el retardo en la
transmisión de datos por el protocolo MQTT, se ve afectado directamente por la
distancia física entre la estación local y la estación remota y el valor promedio del
mismo aumenta.
Jitter
Figura 4.36 Jitter en los tres escenarios
En la Figura 4.36 se puede observar que la variación del retardo o Jitter también
aumenta su valor según la distancia física que existe entre la estación local y remota
Tasa de Paquetes Perdidos
En todos los casos se registró que no existieron paquetes de datos perdidos, lo cual
es un indicador muy bueno para la teleoperación.
0
200
400
600
800
1000
1200
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Jitt
er (
ms)
Número de Muestra
JITTER en la misma red JITTER en la misma ciudad JITTER EN UNA CIUDAD DIFERENTE
135
Retardo de la Realimentación Visual
Figura 4.37 Retardo de video de los 3 escenarios.
Tabla 4.22 Comparación de retardo de video en los 3 escenarios.
Retardo de Video Valor Promedio [ms]
EN LA MISMA RED 799.28
EN LA MISMA CIUDAD 810.66
EN UNA CIUDAD DIFERENTE 1678.31
En la Figura 4.37 y Tabla 4.22 se puede apreciar la diferencia entre el retardo
existente en cada escenario de teleoperación propuesto. Cabe recalcar que el
retardo en la transmisión de video es uno de los factores más importantes y que
influye en mayor medida en la maniobrabilidad del robot, un retardo muy alto o
pausas en la transmisión de video puede ocasionar que el operador entorpezca sus
decisiones al momento de manejar. También se puede apreciar que el retardo en
la transmisión de video aumenta conforme aumenta la distancia física.
Tiempo de Ejecución de la Tarea y Número de Colisiones
A continuación, se analiza el tiempo en promedio que tarda el operador en
completar el recorrido en cada escenario desde los cuales se realizaron las
pruebas.
0.0
0.5
1.0
1.5
2.0
2.5
3.0
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
15
1Ret
ard
o d
e vi
deo
(s)
Número de Muestra
Retardo de video en la misma red Retardo de video en la misma ciudad
Retardo de video en otra ciudad
136
Figura 4.38 Tiempo de ejecución de la tarea en cada escenario.
Tabla 4.23 Comparación de tiempo de ejecución de tarea en los 3 escenarios
Escenario PRUEBA
IDEAL ESCENARIO 1 ESCENARIO 2 ESCENARIO 3
Valor Promedio [s] 28 55 147 121
Como se puede apreciar en la Figura 4.38 y en la Tabla 4.23, existe un incremento
en el tiempo que le toma al operador completar el circuito. En la prueba ideal el
tiempo promedio que tarda el operador en completar el circuito es de 28 segundos,
en el escenario 1 el tiempo aumenta a casi el doble, para el escenario 3 el tiempo
casi se multiplica por 5 y para el escenario 3 el tiempo se multiplica por 4.
A continuación, se muestran los resultados del número de colisiones en promedio
que se contabilizaron en el desarrollo de las pruebas en cada escenario propuesto.
Figura 4.39 Número de colisiones en cada escenario.
0
20
40
60
80
100
120
140
160
PRUEBA IDEAL ESCENARIO 1 ESCENARIO 2 ESCENARIO 3
Tiem
po
de
ejec
uci
ón
de
la t
area
(s)
Escenario
0.0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
PRUEBA IDEAL ESCENARIO 1 ESCENARIO 2 ESCENARIO 3
Val
or
pro
med
io d
e co
lisio
nes
Escenario
137
Tabla 4.24 Comparación del número de colisiones de cada escenario.
Escenario PRUEBA
IDEAL ESCENARIO 1 ESCENARIO 2 ESCENARIO 3
Valor Promedio 0 0 0.8 0.6
En la Figura 4.39 y en la Tabla 4.24 se puede apreciar un incremento en el número
de colisiones registradas en los 5 intentos en cada escenario.
Una consideración inicial para analizar estos resultados es la cronología en la que
se realizaron las pruebas, primero se realizó la prueba ideal, luego la prueba desde
el escenario 2, luego el escenario 3, y al final el escenario 1, esto debido a
disponibilidad de tiempo del operador.
De acuerdo con lo anterior, se puede mencionar que el nivel de experticia del
operador en la prueba del escenario 3 fue mayor que en la prueba del escenario 2,
por lo cual, al estar más acostumbrado a la realimentación visual de la cámara, los
pedales y el comportamiento del robot, logró obtener mejores resultados a pesar
de una mayor influencia de la distancia física sobre el sistema.
El número de colisiones depende en mayor medida a las condiciones de la
realimentación visual, cuando existen pausas en la transmisión de video el operador
puede perder el control del robot y esto se traduce en colisiones.
Maniobrabilidad
Para poder analizar este parámetro se realizó una encuesta a cinco personas, que
actuarán de operadores, la cual incluye preguntas cuyas respuestas reflejan las
características del rendimiento del sistema teleoperado en los diferentes escenarios
propuestos. La encuesta propuesta sólo es para el primer escenario: en la misma
red, esto es debido a la disponibilidad de los operadores.
A continuación, se muestran los resultados de esta encuesta:
Pregunta 1. ¿Cómo califica la calidad del sistema de realimentación visual?
138
Pregunta 2. ¿Cómo califica la interacción del usuario con la interfaz haciendo uso
del joystick y los pedales?
Pregunta 3. ¿Cómo califica el funcionamiento del modelo de carlike?
Pregunta 4. ¿Cuál es el nivel de dificultad al teleoperar debido los retardos en la
comunicación?
Pregunta 5. ¿Qué tan amigable y completa es la interfaz de la estación local?
4
3 3
0
1
2
3
4
5
Escenario 1 Escenario 2 Escenario 3
0
1
2
3
4
5
Escenario 1 Escenario 2 Escenario 3
0
1
2
3
4
5
Escenario 1 Escenario 2 Escenario 3
0
1
2
3
Escenario 1 Escenario 2 Escenario 3
4. Excelente
3. Bueno
2. Regular
1.Malo
4. Excelente
3. Bueno
2. Regular
1.Malo
4. Excelente
3. Bueno
2. Regular
1.Malo
3. Alto
2. Medio
1. Bajo
139
Pregunta 6. ¿Qué tan maniobrable es el sistema en general?
Pregunta 7. ¿Cómo califica la reacción del robot móvil desde que se lo comanda
hasta que el mismo presente movimiento?
Pregunta 8. ¿Qué aspectos se podrían mejorar en el sistema teleoperado?
En cada caso las mejoras que proponen los operadores se relacionan al sistema
de realimentación visual, debido a que por las condiciones de la red la fluidez en la
imagen no es tan alta, y así mismo el retardo de la cámara influye en la
maniobrabilidad.
A modo de análisis de los resultados obtenidos en las encuestas, se puede apreciar
que el sistema es maniobrable, pero que en cada escenario su rendimiento se ve
opacado por las limitaciones mismas de las redes de Internet.
0
1
2
3
4
Escenario 1 Escenario 2 Escenario 3
0
1
2
3
4
Escenario 1 Escenario 2 Escenario 3
0
1
2
3
4
Escenario 1 Escenario 2 Escenario 3
3. Alto
2. Medio
1. Bajo
3. Alto
2. Medio
1. Bajo
3. Alto
2. Medio
1. Bajo
140
TELEOPERACIÓN PARA EL CARLIKE SIMULADO
A continuación, se analizan los datos recogidos de la teleoperación del modelo
simulado de carlike.
RTTD en el Canal de Comunicación de Datos
En la Figura 4.40 se muestran los valores de RTTD obtenidos experimentalmente
en los 3 escenarios propuestos.
Figura 4.40 Valores de RTTD en los tres escenarios propuestos.
Tabla 4.25 Comparación de valores de RTTD en los tres escenarios.
RTTD Valor Promedio [ms]
EN LA MISMA RED 48.45
EN LA MISMA CIUDAD 72.73
EN UNA CIUDAD DIFERENTE 226.27
En la Figura 4.40 y en Tabla 4.25, se puede apreciar que el retardo en la transmisión
de datos, este valor se ve afectado directamente por la distancia física entre la
estación local y la estación remota.
0
200
400
600
800
1000
1200
1400
1600
1800
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Ret
ard
o d
e Id
a y
Vu
elta
(m
s)
Número de Muestra
RTTD EN LA MISMA RED RTTD EN LA MISMA CIUDAD RTTD EN UNA CIUDAD DIFERENTE
141
JITTER
Figura 4.41 Valores de Jitter en los 3 escenarios.
En la Figura 4.41 se puede observar que la variación del Jitter en este caso, el
retardo mayor es la prueba realizada en una ciudad diferente. Esto debido a la
distancia a la que se encuentran las estaciones.
Tasa de Paquetes Perdidos
En todos los casos se registró que no existieron paquetes de datos perdidos, esto
favorece a la teleoperación del robot móvil ya que muestra que la comunicación es
eficiente.
Retardo de la Realimentación Visual
Figura 4.42 Valores de retardo de video en los tres escenarios.
0
500
1000
1500
2000
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
Jitt
er (
ms)
Número de Muestra
JITTER en la misma red JITTER en la misma ciudad JITTER en una ciudad diferente
0.0
1.0
2.0
3.0
4.0
1 6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
10
1
10
6
11
1
11
6
12
1
12
6
13
1
13
6
14
1
14
6
15
1
Ret
ard
o d
e V
ideo
(s)
Número de Muestra
Retardo de video en la misma redRetardo de video en la misma ciudadRetardo de video en otra ciudad
142
En este caso, el retardo de video más considerable se dio en la prueba realizada
en otra ciudad. Nuevamente la distancia que existe entre ambas estaciones es
fundamental en el aumento del retardo.
Tabla 4.26 Comparación de valores de retardo de video de los 3 escenarios.
Retardo de Video Valor Promedio [ms]
EN LA MISMA RED 680
EN LA MISMA CIUDAD 964.1
EN UNA CIUDAD DIFERENTE 1210.88
En la Figura 4.42 y Tabla 4.26 se puede apreciar la diferencia entre el retardo
existente en cada escenario de teleoperación propuesto.
Tiempo de Ejecución de la Tarea y Número de Colisiones
En la Figura 4.43 se presenta el tiempo promedio que el operador tarde en ejecutar
el circuito completo en cada escenario. Se puede observar que mientras aumenta
la distancia de estación a estación el tiempo aumenta. También se debe tomar en
consideración la experiencia que posea el operador al manejar el robot móvil en un
entorno definido.
Figura 4.43 Tiempo de ejecución de la tarea en los 3 escenarios.
0
50
100
150
200
250
300
350
400
450
500
PRUEBA IDEAL ESCENARIO 1 ESCENARIO 2 ESCENARIO 3
Tiem
po
de
ejec
uci
ón
de
la t
area
(s)
Escenario
143
Tabla 4.27 Valores promedios de tiempo de ejecución de la tarea en los 3 escenarios.
Escenari0 PRUEBA
IDEAL ESCENARIO 1 ESCENARIO 2 ESCENARIO 3
Valor Promedio [s] 162 275 446 464
Como se puede apreciar en la Tabla 4.27, en la prueba ideal el tiempo promedio
que tarda el operador en completar el circuito es de 162 segundos, en el escenario
1 el tiempo aumenta a casi el doble, para el escenario 2 el tiempo casi se multiplica
por 3 y para el escenario 3 el tiempo es casi el mismo que en el escenario 2. A
continuación, se muestran los resultados del número de colisiones en promedio que
se contabilizaron en el desarrollo de las pruebas en cada escenario.
Figura 4.44 Número de colisiones en cada escenario.
Tabla 4.28 Valores promedios del número de colisiones en cada escenario.
Escenario PRUEBA
IDEAL ESCENARIO 1 ESCENARIO 2 ESCENARIO 3
Valor Promedio 0 0 0.2 1.2
En la Figura 4.44 y Tabla 4.28 se puede apreciar un incremento en el número de
colisiones registradas en los 5 intentos en cada escenario.
Una consideración inicial para analizar estos resultados es la cronología en la que
se realizaron las pruebas, primero se realizó la prueba ideal, luego la prueba desde
el escenario 2, luego el escenario 3, y al final el escenario 1, esto debido a
disponibilidad de tiempo del operador.
0
0.2
0.4
0.6
0.8
1
1.2
1.4
PRUEBA IDEAL ESCENARIO 1 ESCENARIO 2 ESCENARIO 3Val
or
pro
med
io d
e co
lisio
nes
Escenario
144
A medida que el operador conoce mejor el entorno en el cual circula el robot móvil,
le será más fácil manejarlo y adaptarse a la variación en el retardo de video.
El número de colisiones se ve directamente afectado por la experiencia del
operador en determinado circuito y por el retardo de video que exista, esto debido
a la velocidad de red con la que se trabaje en ambas estaciones.
Maniobrabilidad
Para poder analizar este parámetro se realizó una encuesta a cinco personas que
tendrán el papel de operador, esta encuesta es la misma realizada en el robot móvil
físico. También se la realizó en un solo escenario: la misma red, debido a la
disponibilidad de los operadores.
A continuación, se muestran los resultados de esta encuesta:
Pregunta 1. ¿Cómo califica la calidad del sistema de realimentación visual?
Pregunta 2. ¿Cómo califica la interacción del usuario con la interfaz haciendo uso
del joystick y los pedales?
Pregunta 3. ¿Cómo califica el funcionamiento del modelo de carlike?
0
1
2
3
4
5
Escenario 1 Escenario 2 Escenario 3
0
1
2
3
4
5
Escenario 1 Escenario 2 Escenario 3
4. Excelente
3. Bueno
2. Regular
1.Malo
4. Excelente
3. Bueno
2. Regular
1.Malo
145
Pregunta 4. ¿Cuál es el nivel de dificultad a la teleoperar debido los retardos en la
comunicación?
Pregunta 5. ¿Qué tan amigable y completa es la interfaz de la estación local?
Pregunta 6. ¿Qué tan maniobrable es el sistema en general?
Pregunta 7. ¿Cómo califica la reacción del robot móvil desde que se lo comanda
hasta que el mismo presente movimiento?
0
1
2
3
4
5
Escenario 1 Escenario 2 Escenario 3
0
1
2
3
Escenario 1 Escenario 2 Escenario 3
0
1
2
3
4
Escenario 1 Escenario 2 Escenario 3
0
1
2
3
4
Escenario 1 Escenario 2 Escenario 3
4. Excelente
3. Bueno
2. Regular
1.Malo
3. Alto
2. Medio
1. Bajo
3. Alto
2. Medio
1. Bajo
3. Alto
2. Medio
1. Bajo
146
Pregunta 8. ¿Qué aspectos se podrían mejorar en el sistema teleoperado?
Para todos los escenarios presentados los operadores hacen referencia a la mejora
del sistema de realimentación visual, debido a que esta es la mayor limitante para
poder maniobrar el robot móvil.
En forma general se determina que el sistema maniobrable. Los operadores al
ganar experiencia pueden comandar de mejor manera el robot móvil en el entorno
en que se movilice.
0
1
2
3
4
Escenario 1 Escenario 2 Escenario 3
3. Alto
2. Medio
1. Bajo
147
CAPÍTULO 5
CONCLUSIONES Y RECOMENDACIONES
5.1. CONCLUSIONES
· Existen diversos protocolos de comunicación que son aplicables en la
teleoperación de robots móviles. De estos protocolos unos son más rápidos
que otros en la transferencia de datos dependiendo de la arquitectura de
comunicación con la que trabajen.
· El protocolo MQTT demostró ser de alta velocidad en la transferencia de
datos, ya que al poseer arquitectura de comunicación publicador –
suscriptor, el cliente sólo toma los datos que necesite (suscripciones) y no
todos los datos que se encuentran publicados. Por estas razones este
protocolo fue el implementado para teleoperar el robot móvil tipo carlike.
· El funcionamiento del protocolo de comunicaciones MQTT ha demostrado,
experimentalmente, que es bastante eficiente en redes de Internet,
comprobando que es posible un envío constante de datos entre la estación
local y la estación remota sin pérdidas de paquetes de datos.
· El servidor de datos seleccionado es MOSQUITTO. Este servidor es
específico para el protocolo de comunicación escogido MQTT. Es muy
eficiente en su función como dispositivo intermedio para establecer
comunicación entre la estación local y la estación remota.
· Es más eficiente usar la tarjeta embebida en el carlike físico sólo para la
transferencia de datos para los sensores y actuadores. Y para la
realimentación visual del sistema usar una cámara IP, esto significa que los
datos de video son enviados por un canal de comunicación independiente al
canal que se usa para enviar las señales a los sensores y actuadores del
robot, de esta forma la transmisión de video no aumenta el retardo en la
transferencia de datos.
· El carlike simulado se desarrolló en la plataforma virtual UNITY 3D. El diseño
visual del robot móvil se realizó con piezas predeterminadas dadas por la
plataforma, pero el funcionamiento de cada parte del robot se realiza a través
148
de la programación. Además, el protocolo de comunicación también se
encuentra incluido. La realimentación visual para este caso se lo realizó
usando TeamViewer, siendo esta opción la más viable para envío de video
de un ordenador a otro.
· El sistema teleoperado que se diseñó en el presente proyecto tiene un buen
rendimiento, se ha demostrado su maniobrabilidad experimentalmente en
varios escenarios geográficamente distantes aun en horarios en los que los
tráficos en las redes del Internet son altos. Lo cual supone que el rendimiento
del sistema será más alto en condiciones mejores de tráfico en las redes del
Internet.
· El sistema teleoperado del presente proyecto es maniobrable, pero sus
cualidades se ven opacadas por las limitaciones mismas del canal de
comunicaciones que no es dedicado como es el Internet y también la
influencia de las distancias físicas y los horarios de trabajo.
· La eficiencia de un sistema teleoperado también depende la complejidad de
las tareas que se requieren, en el caso del presente proyecto la complejidad
de las tareas que se requieren es media ya que los recorridos de los modelos
físicos y simulados de carlike tienen curvas y caminos no tan angostos con
lo cual se registró un buen rendimiento del sistema.
· Experimentalmente se ha podido comprobar que la experiencia del operador
al manejar los modelos de carlike físico y simulado influye bastante en los
resultados que se obtuvieron, probando así que, al tener más experiencia, el
operador logra cada vez obtener mejores resultados ante las mismas
circunstancias.
· El rendimiento del sistema teleoperado se ve afectado en mayor medida por
los retardos producidos en los sistemas de realimentación visual que por los
retardos en la comunicación de datos debido a que la realimentación visual
es la más importante para el operador al momento de tomar decisiones
cuando maneja el carlike. Además, los retardos de realimentación visual son
mucho mayores a los retardos de comunicación de datos.
· El incremento en el tiempo de retardo de la comunicación de datos por MQTT
de acuerdo con la distancia física es grande, pero aun así no significa un
149
retardo muy alto comparado con el retardo de video cuyo aumento según la
distancia física si representa un mayor problema en la maniobrabilidad del
sistema.
5.2. RECOMENDACIONES
· En futuros proyectos se recomienda probar el protocolo Websockets en vez
del protocolo MQTT, esto es debido a que se ha demostrado
experimentalmente en la tesis [18] que es más rápido en la transferencia de
datos.
· En la teleoperación se debe contar con una alta velocidad de red de
comunicación, esto específicamente para la realimentación visual porque la
transferencia de datos de video es bastante pesada. También se puede
aumentar el ancho de banda de la red con la que se trabaje. Otra opción es
tener un servidor exclusivo para el envío y recepción de video.
· Una de las características más importantes para tarjetas embebidas que se
usen en la teleoperación de robots móviles es que posea un módulo para
conexión inalámbrica. De esta manera la tarjeta no necesita estar conectada
siempre a un ordenador para acceder a Internet. Esto se considera solo en
caso de que se necesite que el robot móvil se movilice de un punto a otro.
· Al momento de teleoperar el carlike físico se recomienda estar pendiente de
las luces indicadoras. Estas avisan en que momento las baterías tienen un
voltaje insuficiente para que el robot siga funcionando. Si se deja descargar
las baterías completamente se dañarán permanentemente.
· A pesar de las protecciones que posee carlike físico se recomienda no forzar
el motor de tracción, es decir, cuando exista una colisión o cuando el terreno
tenga una pendiente muy alta o sea muy rugoso.
150
REFERENCIAS BIBLIOGRÁFICAS
[1] O. Padilla Montiel, “Manipulador teleoperado inalámbricamente”, Universidad de las Américas de Puebla, Puebla, México, 2008.
[2] J. M. Bogado Torres, “Control bilateral de robots teleoperados por convergencia de estados”, Ph.D, E.T.S.I. Industriales (UPM), Universidad Politécnica de Madrid, Madrid, España, 2007.
[3] E. Slawiñski, V. Mut, L. Salinas, y S. García, “Teleoperation of a mobile robot with time-varying delay and force feedback”, Robotica, vol. 30, núm. 01, pp. 67–77, ene. 2012.
[4] W. Stallings, Comunicaciones y Redes de Computadores, D. Fayerman, Pearson Educación, S.A., Madrid, 2008.
[5] “GUI de MATLAB - MATLAB & Simulink”, Es.mathworks.com,2017. [En línea]. Disponible en: https://es.mathworks.com/discovery/matlab-gui.html. [Consultado: 18-may-2017].
[6] “Tecnologías y lenguajes de Visual Studio”, Msdn.microsoft.com,2017. [En línea]. Disponible en: https://msdn.microsoft.com/es-es/library/bb514232 (v=vs.100). [Consultado: 18-may-2017].
[7] A.M. Okamura, “Methods for haptic feedback in teleoperated robot-assisted surgery”, Industrial Robot: An International Journal, vol.31, pp. 499 - 508, 2004 [En línea]. Disponible en: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC 1317565/. [Consultado: 24-jul-2017].
[8] Z. Ni, C. Pacoret, R. Benosman, S. Réginer, Haptic Feedback Teleoperation of Optical Tweezers, Wiley-ISTE, 2014.
[9] J. E. Fjellin, “Design of a bilateral master-slave system with haptic feedback for ultrasound examinations”, Msc., Dept. Informatics, Oslo Univ., Oslo, Norway, 2013.
[10] M. Rath, “Continuous Auditory Feedback in a Control Task”, Deutsche Telekom Lab., Berlin Univ. of Technology, Berlin, Germany, 2006.
[11] R. Chellali, H. Pham, “Frequency modulation based vibrotactile feedback vs visual feedback in a multimodal interface for 3D pointing tasks in teleoperation”, Presented at: Robotics and Biomimetics (ROBIO), 2011 IEEE International Conference.
[12] E. Tidoni, P. Gergondet, G. Fusco, S. Aglioti, “Literature Review: The Role of Audio-Visual Feedback in a Thought-Based Control of a Humanoid Robot: A BCI Study in Healthy and Spinal Cord Injured People”, IEEE Transactions on Neural Systems and Rehabilitation Engineering, unpublished. [En línea].
151
Disponible en: https://www.researchgate.net/publication/305823274_The_Role_of_Audio-Visual_Feedback_in_a_Thought-Based_Control_of_a_Humanoid_Robot_A_BCI_Study_in_Healthy_and_Spinal_Cord_Injured_People. [Consultado: 24-jul-2017].
[13] C. Glover, B. Russell, A. White, M. Miller, A. Stoytchev, “Evaluating the effects of Haptic and Visual Feedback on the Teleoperation of Remote Robots”, unpublished. [En línea]. Disponible en: http://www.vrac.iastate.edu/wp-content/uploads/2014/11/Robot_paper.pdf. [Consultado: 24-jul-2017].
[14] E. Nuño, L. Basañez, “Teleoperación: técnicas, aplicaciones, entorno sensorial y teleoperación inteligente”, Dept. Control de Sistemas Industriales, Universidad Politécnica de Cataluña, 2004, unpublished. [En línea]. Disponible en: https://www.researchgate.net/publication/33421071. [Consultado: 24-jul-2017].
[15] M. Condoluci, T. Mahmoodi, E. Steinbach, y M. Dohler, “Soft Resource Reservation for Low-Delayed Teleoperation Over Mobile Networks”, IEEE Access, vol. 5, pp. 10445–10455, 2017.
[16] “MQTT”, Mqtt.org, 2016. [En línea]. Disponible en: http://mqtt.org/. [Consultado: 15-nov-2016].
[17] “About HTML5 WebSocket - Powered by Kaazing”, Websocket.org, 2016. [En línea]. Disponible en: http://websocket.org/aboutwebsocket.html. [Consultado: 15-nov-2016].
[18] L. F. Burbano Vallejo, “Estudio e implementación en Matlab de un entorno de comunicación basado en protocolos del Internet de las Cosas para clientes de Teleoperación en Robótica”, trabajo de fin de grado, Escuela Politécnica Nacional, jul. 2017.
[19] S. Tarkoma, Publish / Subscribe Systems: Design and Principles. John Wiley & Sons, United Kingdom, 2012.
[20] “An Open Source MQTT v3.1 Broker”, Mosquitto.org, 2017. [En línea]. Disponible en: https://mosquitto.org/. [Consultado:22-nov-2016].
[21] A. Barrientos, J. del Cerro, P. Gutiérrez, “Vehículos aéreos no tripulados para uso civil”, Grupo de Robótica y Cibernética, Universidad Politécnica de Madrid, Madrid, España. [En línea]. Disponible en: http://webdiis.unizar.es/~neira/docs/ABarrientos-CEDI2007.pdf. [Consultado: 18-may-2017].
[22] “Clasificacion de robots | Wiki de Robótica”, Wiki.robotica.webs.upv.es, 2017. [En línea]. Disponible en: http://wiki.robotica.webs.upv.es/wiki-de-robotica/introduccion/clasificacion-de-robots/. [Consultado en: 25-nov-2016].
152
[23] H. Moreno, R. Saltarén, L. Puglisi, I. Carrera, “Robótica Submarina: Conceptos, Elementos, Modelado y Control", Revista Iberoamericana de Automática e Informática Industrial RIAI, vol 11, pp. 3-19, 2014. [En línea]. Disponible en: http://www.sciencedirect.com/science/article/pii/S1697791213000885. [Consultado: 18-may-2017].
[24] A. Ollero Baturone, Robótica: manipuladores y robots móviles. Marcombo, 2005.
[25] “RBCAR | Robotnik”, Robotnik, 2017. [En línea]. Disponible en: http://www.robotnik.es/robots-moviles/rbcar/. [Consultado: 18-may-2017].
[26] “Raspberry Pi 3 Model B”, Raspberry Pi, 2016. [En línea]. Disponible en: https://www.raspberrypi.org/products/raspberry-pi-3-model-b/. [Consultado: 22- nov- 2016].
[27] “BeagleBoard.org - black”. Beagleboard.org, 2016. [En línea]. Disponible en: https://beagleboard.org/black. [Consultado: 18-may-2017].
[28] C. Atwell, “The biggest-little revolution: 10 single-board computers for under $100”, EDN, 2017. [En línea]. Disponible en: http://www.edn.com/design/diy/4419990/The-biggest-little-revolution--10-single-board-computers-for-under--100. [Consultado: 18-may-2017].
[29] “Coppelia Robotics V-REP: Create. Compose. Simulate. Any Robot: Features”, Coppeliarobotics.com, 2017. [En línea]. Disponible en: http://www.coppeliarobotics.com/features.html. [Consultado: 18-may-2017].
[30] “Coppelia Robotics V-REP: Create. Compose. Simulate. Any Robot: Features”, Coppeliarobotics.com, 2017. [En línea]. Disponible en: http://www.coppeliarobotics.com/features.html. [Consultado: 18-may-2017].
[31] “Arduino UNO”, Arduino Project Hub, 2017 [En línea]. Disponible en: https://create.arduino.cc/projecthub/Aritro/security-access-using-rfid-reader-f7c746. [Consultado: 18-may-2017].
[32] “Pololu - 250:1 Micro Metal Gearmotor HP 6V”, pololu.com, 2017. [En línea]. Disponible en: https://www.pololu.com/product/995. [Consultado: 18-may-2017].
[33] “Pololu - RC Servos”, pololu.com, 2017. [En línea]. Disponible en: https://www.pololu.com/category/23/rc-servos. [Consultado: 18-may-2017].
[34] “Raspbian - Raspberry Pi Documentation”, Raspberry.pi, 2017. [En línea]. Disponible en: https://www.raspberrypi.org/documentation/raspbian/. [Consultado: 18-may-2017].
153
[35] “Pololu Carrier with Sharp GP2Y0D810Z0F Digital Distance Sensor 10cm”, Pololu.com, 2017. [En línea]. Disponible en: https://www.pololu.com/product/1134/resources. [Consultado: 18-may-2017].
[36] “231a-ak proposal - CSclasswiki”, Cs.smith.edu, 2017. [En línea]. Disponible en: http://cs.smith.edu/classwiki/index.php/231a-ak_proposal. [Consultado: 18-may-2017].
[37] “Cámara IP del P2P cubierta Sricam inalámbrica WiFi CMOS Pan / Tilt con Negro de detección de movimiento”, es.tmart.com, 2017. [En línea]. Disponible en: http://es.tmart.com/Sricam-Wireless-Wifi-CMOS-Pan-Tilt-Indoor-P2P-IP-Camera-with-Motion-Detection-Black_p247649.html. [Consultado: 18-may-2017].
[38] “Rhino 1250mAh 3S1P 20C Lipoly Pack”, hobbyking.com, 2017. [En línea]. Disponible en: https://hobbyking.com/en_us/rhino-1250mah-3s1p-20c-lipoly-pack.html?___store=en_us. [Consultado: 18-may-2017].
[39] “Turnigy nano-tech 1500mAh 2S1P 20~40C Lipo Receiver Pack”, Hobbyking. [En línea]. Disponible en: https://hobbyking.com/en_us/turnigy-nano-tech-1500mah-2s1p-20-40c-lipo-receiver-pack.html. [Consultado: 18-may-2017].
[40] “RPI Lithium Battery Expansion Board SKU:435230”, raspberrypiwiki.com, 2017. [En línea]. Disponible en: http://www.raspberrypiwiki.com/index.php/RPI_Lithium_Battery_Expansion_Board_SKU:435230. [Consultado: 18-may-2017].
[41] “Módulo LM2596 Convertidor de Voltaje DC-DC Buck 1.25V-35V”, Electronilab, 2017. [En línea]. Disponible en: https://electronilab.co/tienda/modulo-lm2596-convertidor-de-voltaje-dc-dc-buck-1-25v-35v/. [Consultado: 18-may-2017].
[42] “Módulo L298N Puente H doble para Arduino controlo motores paso a paso”, Createc 3D Shop, 2017. [En línea]. Disponible en: http://createc3d.com/shop/es/modulos-y-sensores/345-comprar-modulo-l298n-puente-h-para-arduino-controlo-motores-paso-a-paso-precio-oferta.html. [Consultado: 18-may-2017].
[43] “Lista de características de TeamViewer”, teamviewer.com, 2017. [En línea]. Disponible en: https://www.teamviewer.com/es/features/. [Consultado: 18-may-2017].
A-1
ANEXO A
CONFIGURACIÓN DE LA CÁMARA IP
A.1. PROCESO DE CONFIGURACIÓN DE LA CÁMARA IP
En este anexo se muestra la forma en la que debe ser configurada la cámara IP
que se usó en este proyecto. El modelo de la cámara IP se muestra en la Figura
A.1.
Figura A.1 Cámara
El primer paso es conectar la cámara IP y una PC en un router para ponerlos en
red. También existe la posibilidad de conectar directamente la cámara IP al PC con
un cable ethernet.
La cámara IP viene por defecto con la dirección IP 192.168.1.88:80 y para poder
acceder a ella la PC debe configurarse con una dirección IP en la misma red. Para
ello accedemos al Panel de control y se da click en la pestaña de “Redes e Internet”
>> Redes y Recursos compartidos >> Cambiar la configuración del adaptador >>
Ethernet
Se da doble click y entramos, nos aparece la ventana de propiedades de ethernet
como se ve en la Figura A.2 y se busca el protocolo IPV4.
A-2
Figura A.2 Propiedades de ethernet
Se entra y se configura como se muestra en la Figura A.3.
Figura A.3 Propiedades protocolo IPv4
Al pulsar en aceptar ya se tiene la PC y la cámara en red y se puede acceder a la
cámara desde cualquier buscador digitando la IP de la cámara por defecto en la
barra de búsqueda.
Al entrar aparece una pantalla como la que se muestra en la Figura A.4 en la que
se pide autenticación, por defecto el nombre de usuario es “admin” mientras que la
contraseña tiene sus campos vacíos.
A-3
Figura A.4 Autentificación de la cámara.
Al entrar aparece la ventana que se muestra en la Figura A.5 donde se debe
seleccionar una de las opciones para ingresar.
Figura A.5 Ventana de inicio de la interfaz de la cámara IP
En este caso se seleccionó “Firefox, Chrome o Safari” y la cámara accede la interfaz
que se muestra en la Figura A.6.
Figura A.6 Interfaz de la cámara IP.
A-4
Para entrar en las configuraciones de la cámara se da click en el botón de la
izquierda en la parte de abajo. Al entrar en las configuraciones se muestra una
ventana como la que se muestra en la Figura A.7.
Figura A.7 Ventana de configuraciones de la cámara IP
Para que la cámara IP obtenga una IP de router automáticamente se debe habilitar
el DHCP en la pestaña de “Basic Network Settings” como se muestra en la Figura
A.8.
Figura A.8 Configuraciones de red de la cámara IP
Para configurar la comunicación vía WiFi damos click en la pestaña de “Wireless
LAN Settings” donde se debe buscar la red WiFi, introducir el tipo de autenticación
y la contraseña como se muestra en la Figura A.9.
A-5
Figura A.9 Configuraciones de red WiFi LAN
Luego de configurar la red LAN, se da click en submit y la cámara se reiniciará. Una
vez reiniciada la cámara los cambios quedaran guardados.
Para que la cámara siempre tenga la misma dirección IP cada vez, las redes
internas de la Escuela Politécnica Nacional le asignan una dirección IP según la
dirección MAC que posee.
Para poder acceder a la cámara desde el Internet se debe hacer un proceso de
nateo en las redes de la Escuela Politécnica Nacional. En este caso cuando se trata
de acceder a la IP pública 190.96.111.129:81 que es propiedad de la EPN, las redes
internas redirigen hacia la IP interna de la EPN que fue asignada a la cámara.
El proceso de nateo lo realizan las personas encargadas de las redes internas de
la EPN en la DGIP.
B-1
ANEXO B
INSTALACIÓN Y CONFIGURACIÓN DEL SERVIDOR DE
DATOS “MOSQUITTO” PARA WINDOWS 7 Y WINDOWS 8
La instalación del Servidor de Datos “Eclipse Mosquitto” se la debe realizar en una
PC conectada a un punto de red. Está PC debe tener asignada una dirección IP
Pública, en este caso es “190.96.111.128”.
B.1. INSTALACIÓN
Descargar Mosquitto de la página web “mosquitto.org/download/”. En la Figura B.1
se presenta los enlaces de descarga del servidor para el Windows. Escoger la
segunda opción.
Figura B.1 Enlaces de descarga del servidor de datos Mosquitto para Windows.
Descargar el ejecutable en la pestaña “download” como se ve en la Figura B.2.
Figura B.2 Enlaces de descarga del servidor de datos Mosquitto para Windows.
B-2
Ejecutar el archivo descargado. Aparecerá la siguiente ventana. Se debe descargar
los dos archivos que se solicitan.
Figura B.3 Archivos adicionales que deben descargarse.
Antes de continuar con la instalación de ‘mosquitto’ se procede a descargar
‘OpenSSL’ del enlace: “slproweb.com/products/Win32OpenSSL.html”. Escoger la
versión v1.0.2L Light. Ejecutar e instalar el archivo descargar. Tomar en cuenta la
dirección en la cual se instaló.
Figura B.4 Archivo OpenSSL.
Descargar ‘pthreads’ del enlace: “ftp://sources.redhat.com/pub/pthreads-win32/dll-
latest/dll/x86/”. Seleccionar “pthreadvc2.dll”. Descargar y guardar el archivo
Figura B.5 Archivo pthreads.
B-3
Luego de realizar los dos pasos anteriores se retoma la instalación de ‘mosquitto’.
Seleccionar la opción ‘Service’ y dar clic en ‘Next’.
Figura B.6 Instalación Mosquitto
Escoger la carpeta en donde se instalará ‘Mosquitto’. De preferencia escoger
‘C:\ProgramFiles\mosquitto’. Luego de seleccionar la carpeta se da clic en ‘Install’.
Figura B.7 Instalación Mosquitto
Una vez finalizada la instalación en la carpeta en la que Mosquitto fue instalado se
debe copiar los siguientes archivos.
Archivos: libeay32.dll ssleay32.dll, estos archivos se encuentran en la carpeta en
la cual OpenSSL fue instalado.
Archivo: pthreadVC2.dll, este archive se descargó en la opción ‘pthreads’.
B-4
En la Figura B.8 se observa cómo queda finalmente la carpeta en la que se instaló
Mosquitto.
Figura B.8 Carpeta de instalación de Mosquitto.
Finalmente, se debe reinstalar ‘Mosquitto’ en la misma carpeta. Para comprobar
que la instalación se ha realizado correctamente, se debe acceder al ‘cmd’ y escribir
el comando netstat -an, aparecerá la siguiente ventana.
Figura B.9 Puerto ‘1883’ abierto para el servidor.
Se el puerto ‘1883’ se ha habilitado y está en escucha.
C-1
ANEXO C
MANUAL DE USUARIO
C.1. INTRODUCCIÓN
En el presente manual de usuario se detalla los pasos a seguir para poner en
funcionamiento el “Sistema de Teleoperación para el Robot Móvil tipo Carlike”. Este
manual explica los requisitos previos con los que debe contar el sistema, el
procedimiento para ponerlo en marcha y los errores que se pueden presentar, así
como las soluciones a los mismos.
El sistema de teleoperación consta de tres partes fundamentales que son: Estación
Local, Servidor de Datos y Estación Remota. Cabe recalcar que la Estación Remota
puede representar el robot móvil físico o el robot móvil simulado.
La estación local es una PC u ordenador, en donde se encuentra la interfaz del
usuario, mediante la cual el operador puede comandar el robot móvil. El servidor
de datos está ubicado en una PC, este servidor almacena la información recibida
desde la estación local y desde la estación remota.
La estación remota para el caso del robot móvil físico cuenta con una tarjeta
Raspberry Pi 3B que actúa como eje central de este ya que ejecuta todos los
comandos recibidos y se encarga de la comunicación; existe también una cámara
IP, la cual se encarga de proporcionar al operador realimentación visual del entorno
en donde se encuentra el móvil; hay sensores y actuadores que funcionan de
acuerdo con las instrucciones recibidas por parte de la tarjeta. La estación remota
para el caso del robot móvil simulado se desarrolla en un entorno virtual, por lo que
se necesita una PC para ejecutarlo, la realimentación visual de esta simulación se
obtiene a través de TeamViewer. Cabe mencionar que TeamViewer debe estar
instalado tanto en la estación local, como en la estación remota.
C-2
Por último, se menciona que el robot móvil físico puede ser usado sólo en el séptimo
piso del edificio de Química Eléctrica Q/E y en el EARME, esto es debido a que la
red a cuál se encuentra agregada la cámara IP solo está habilitada en estos puntos.
C.2. INSTALACIÓN
C.2.1. REQUISITOS PREVIOS DE SOFTWARE
Antes de poner en marcha el sistema se debe tener en cuenta varios requerimientos
que necesitan tanto la estación local como la estación remota del sistema, para que
funcione de manera correcta, a continuación, se explica cuáles son estos.
C.2.1.1. Estación Local:
1. Sistema Operativo de la PC: Windows 7 en adelante.
2. Instalar Matlab 2016a.
Figura C.1 Logo Matlab R2016a
2.1. En Matlab, instalar el driver para ARDUINO “Acquire inputs and send outputs
on Arduino boards”. Este driver se lo encuentra en la pestaña Add-Ons al
dar click en “Get Hardware Support Packages”.
Figura C.2 Software necesario en la Estación Local.
Al abrirse la ventana “Support Package Installer” se debe buscar “Arduino” en la
sección izquierda de la ventana y seleccionarlo. En la sección derecha
aparecerá todos los drivers que se puede instalar. Solo se debe seleccionar el
C-3
driver mencionado “Acquire inputs and send outputs on Arduino boards” e
instalarlo.
Figura C.3 Dirección de la carpeta “Tesis Teleoperación”.
3. Instalar driver de ARDUINO para habilitar el puerto de comunicación con la PC.
Se puede descargar este driver desde la página oficial de Arduino accediendo
al siguiente link: www.arduino.cc/en/Main/Software.
Figura C.4 Software ARDUINO
4. Instalar TeamViewer
Se puede descargar TeamViewer desde la página oficial en el siguiente link:
www.teamviewer.com/es/download/windows/
Figura C.5 Logo TeamViewer.
5. Acceso permanente a Internet. Recomendación: conectar la PC a un punto de
red.
C-4
C.2.1.2. Estación Remota:
C.2.1.2.1. Estación Remota Física
El elemento fundamental del robot móvil es la tarjeta Raspberry Pi 3B. Esta tarjeta
debe ejecutar los programas contenidos para comandar el robot móvil, así como
para establecer comunicación con el servidor de datos.
1. Sistema Operativo de la Tarjeta Raspberry Pi 3B
Se requiere de una micro SD para que se inserte en la tarjeta Raspberry. En la
micro SD debe estar instalado el sistema operativo RASPBIAN JESSIE WITH
DESKTOP. Este sistema operativo puede ser descargado de la página oficial en el
link: “www.raspberrypi.org/downloads/raspbian/”. Además, se usa
Win32DiskImager para instalar el sistema operativo en la micro SD. En la Figura
C.6 se muestra los pasos a seguir.
Figura C.6 Descarga del Sistema Operativo en la Raspberry Pi.
2. Librerías de la tarjeta Raspberry Pi 3B
El lenguaje de programación usado en la tarjeta es Python 2.7. Para llevar a cabo
el proyecto se debe usar las siguientes librerías:
import time
· Time: Permite obtener y trabajar con la información de tiempo del Sistema.
import paho.mqtt.client as mqtt
C-5
· paho.mqtt.client: Permite crear y conectar un nuevo cliente MQTT capaz de
suscribirse a tópicos y recibir información que comparten otros clientes.
import paho.mqtt.publish as publish
· paho.mqtt.publish: permite que el cliente de Python pueda publicar datos en
tópicos para compartir información con otros clientes.
import json
· JSON: Es un formato de intercambio de información que permite crear
diccionarios que incluyan varios datos, en el presente proyecto se usa para
enviar varios datos en un mismo tópico.
import RPi.GPIO as GPIO
· RPi.GPIO: en general permite trabajar con las entradas físicas de la
Raspberry Pi 3B y poder usarlas como entradas o salidas digitales.
import math
· Math: Permite realizar operaciones matemáticas, en el proyecto se usa para
medir las variables de odometría.
C.2.1.2.2. Estación Remota Simulada
1. Sistema Operativo de la PC
2. En el caso de la simulación la PC u ordenador debe contar con tarjeta de video
para que soporte el entorno virtual del robot móvil.
3. Instalar TeamViewer.
C.3. EJECUCIÓN
C.3.1. Configuración de la Estación Local
1. Copiar la carpeta “Tesis Teleoperación” a la PC u ordenador.
C-6
2. Abrir Matlab 2016a.
3. Copiar la dirección en donde se encuentra la carpeta “Tesis Teleoperación” en
la barra de direccionamiento de Matlab.
Figura C.7 Dirección de la carpeta “Tesis Teleoperación”
4. Verificar que aparezcan los siguientes archivos
Figura C.8 Archivos de la carpeta “Tesis Teleoperación”
5. Conectar el Joystick a la PC.
6. Ir a “Administrador de Dispositivos” y verificar que tanto el volante como los
pedales estén conectados.
C-7
Figura C.9 Puertos USB conectados en la PC.
7. Identificar en qué puerto USB serial se encuentra conectado los pedales.
8. El número de puerto se lo debe colocar tanto en el archivo “EstaciónLocal.m”
como en el “EstaciónLocalSim.m” en la sección que se observa a continuación:
Figura C.10 Número de puerto de comunicación del Arduino.
9. Colocar la dirección del archivo a ensamblar “MqttClientEPN.dll”, ubicado en la
carpeta TESISTeleopMQTT\MqttClientEPN\MqttClientEPN\bin\Debug, en la
línea de código de ambos archivos “EstaciónLocal.m” y “EstaciónLocalSim.m”
como se ve a continuación:
Figura C.11 Dirección del archivo “MqttClientEPN.dll”
C-8
10. Verificar la dirección de la IP pública del Servidor de Datos, la es
‘190.96.111.128’, en la línea de código de ambos archivos “EstaciónLocal.m” y
“EstaciónLocalSim.m”, como se observa a continuación:
Figura C.12 Dirección IP del Servidor de Datos
C.3.2. Activación del Servidor de Datos
1. Dar clic en inicio.
2. Escribir “cmd” y dar clic sobre el ícono.
Figura C.13 Acceder a CMD
3. En la pantalla que aparece se debe escribir lo siguiente:
3.1. Escribir “cd..” y dar enter.
3.2. Escribir nuevamente “cd..” y dar enter.
3.3. Escribir “cd Program Files” y dar enter
3.4. Escribir “cd mosquitto” y dar enter
3.5. Finalmente se escribe “mosquitto -v” y dar enter.
Si el servidor se ha activado correctamente aparecerá lo siguiente en la
pantalla.
C-9
Figura C.14 Comandos en cmd.
3.6. Si el servidor no se ha activado de forma correcta aparecerá la siguiente
pantalla.
Figura C.15 Comandos en cmd
Para corregir este inconveniente revise la “Sección de Errores” el ERROR N°1.
NOTA: La PC que se usa como servidor de datos se encuentra ubicada en la
“Unidad de Mantenimiento Electrónico (UME)” en el aula 708 Q/E.
C-10
C.3.3. Configuración de la Estación Remota
C.3.3.1. Estación Remota Real
1. Verificar que las tres baterías del robot móvil estén cargadas.
1.1. Quitar la tapa que se encuentra en la parte inferior del robot móvil. Allí se
encuentran los terminales de dos de las tres baterías. Verificar su estado.
Figura C.16 Vista inferior del Carlike.
1.2. Los terminales más anchos corresponden a la batería de 3 celdas, 11.1
voltios [V] a 1.25 amperios [A], los terminales más delgados son de la
batería de 2 celdas, 7.4 voltios [V] a 1.5 amperios [A].
1.3. La tercera batería se encuentra debajo de la tarjeta Raspberry Pi 3B. Para
cargar esta batería se la debe desconectar de la tarjeta.
2. Desmontar la carcasa del carlike.
3. Revisar que todas las conexiones se encuentren como en la Figura C17, Figura
C18, Figura C19, Figura C20, Figura C21.
C-11
Figura C.17 Vista interior derecha de conexión de pines
Figura C.18 Vista interior izquierda de conexión de pines
Figura C.19 Vista interior superior de conexión de pines
C-12
Figura C.20 Vista trasera de conexión de pines
Figura C.21 Vista conexión de leds indicadores
4. Colocar la carcasa.
5. Activar los dos interruptores que posee el robot móvil en la parte inferior. Si al
activarlos se enciende uno de los dos leds rojos o ambos, significa que las
baterías se encuentran descargadas, por lo tanto, el robot móvil no funcionará.
En la sección “Procedimiento” se detalla como cargar las baterías.
6. Desmontar la carcasa del carlike.
7. Conectar la tarjeta Raspberry Pi 3B, mediante cable Ethernet, a una PC.
8. Dar clic a inicio y escribir “Escritorio Remoto”
Figura C.22 Acceso a Escritorio Remoto.
C-13
9. Escribir la dirección IP de la tarjeta “192.168.10.5” y dar clic en conectar.
Figura C.23 Ingreso de dirección IP.
10. Si no tiene acceso a la tarjeta, revise la “Sección de Errores” el EEROR N°2.
11. Aparecerá la siguiente pantalla en la cual se debe ingresar los datos de usuario
y contraseña.
Figura C.24 Acceso a Raspberry Pi 3B.
Usuario: pi
Contraseña: raspberry
12. Ingresar a Python 2. Como se ve a continuación.
Figura C.25 Python 2.
13. Abrir el archivo “p2carlike”.
C-14
Figura C.26 Archivo p2carlike.
14. Dar clic en “Run Module” para correr el programa.
Figura C.27 Run Module
15. Quitar el cable Ethernet de la tarjeta.
16. Colocar la carcasa del robot móvil y conectar el cable de la cámara IP y el de
las luces led indicadoras.
C.3.3.2. Estación Remota Simulada
1. Copiar la carpeta “Carlike simulado” a la PC que será usada como estación
remota.
2. Dar clic en el archivo ejecutable del carlike simulado llamado “Tesis_Carlike”.
Aparecerá la siguiente pantalla.
C-15
Figura C.28 Vista inferior del Carlike.
3. Escoger la resolución deseada. Tomar en cuenta que a mayor resolución
aumenta el retardo de envío de video. Se recomiendo escoger una resolución
baja. Aparecerá la siguiente pantalla.
Figura C.29 Interfaz de INICIO.
4. Al aparecer la pantalla se da clic sobre EMPEZAR para dar inicio a la
simulación. Cuando se establezca comunicación entre la estación local y
remota la palabra ‘ONline’ se visualizará en la pantalla.
C-16
Figura C.30 Entorno Vistual.
C.4. PROCEDIMIENTO
Luego de haber realizado todos los pasos anteriores se procede a poner en
funcionamiento el sistema, como se especifica a continuación:
1. Encender los dos interruptores que contiene el robot móvil. Verificar que las
luces indicadoras encendidas sean las verdes. La luz amarilla se encenderá
cuando se establezca comunicación entre la estación local y remota.
2. Para tener la Realimentación Visual del carlike físico, se accede a cualquier
navegador y se escribe “190.96.111.129:81” en la barra de direcciones.
Usuario: admin
Dentro de esta aplicación se puede controlar el movimiento de la cámara.
3. Para obtener realimentación visual del carlike simulado se debe activar
TeamViewer en la PC de la estación local y en la PC de la estación remota.
4. En matlab se pone a correr el archivo “Presentacion.m”. Aparecerá la siguiente
pantalla.
C-17
Figura C.31 Interfaz de INICIO.
5. Dar clic en ACCEDER.
Figura C.32 Interfaz de INICIO.
6. Escoger el entorno que se desea. Entorno real para manejar el robot móvil físico
o entorno virtual para manejar el robot móvil simulado.
7. Al dar clic en “acceder” se solicitará al operador que ingrese un usuario y una
contraseña.
C-18
Figura C.33 Acceso de usuario.
Usuario: matlab
Contraseña: 123
8. En la pantalla que se muestra, dar clic en START para dar inicio al
funcionamiento del sistema.
Figura C.34 Interfaz de “Estación Local”
C-19
Una vez iniciado el funcionamiento se observa en la esquina superior derecha el
estado de conexión.
Si el indicador está en verde, significa que existe comunicación entre la estación
local y la estación remota, por lo tanto, los datos pueden ser enviados. Si el
indicador está en rojo, significa que se ha perdido la conexión y los datos no serán
enviados.
9. Una vez que el robot móvil termine de recorrer el circuito es NECESARIO dar
clic en STOP, y aparecerá una imagen con la trayectoria recorrida.
10. Dar clic en SALIR para regresar a la pantalla de inicio y nuevamente tener la
opción de que entorno escoger.
11. Antes de apagar el carlike físico se debe acceder a la tarjeta y parar el programa
que está corriendo. De forma rápida se escribe “Ctrl+C” y el programa se detiene
automáticamente.
12. Cerrar los programas y apagar la tarjeta desde la PC.
13. Apagar los dos interruptores que posee el robot móvil.
14. Cerrar la aplicación del robot móvil simulado.
C.5. SECCIÓN DE ERRORES
ERROR 1: No se ha activado de forma correcta el servidor.
1. En inicio escribir “Administrador de Tareas”
Figura C.35 Administrador de Tareas.
1.1. Seleccionar la pestaña de procesos.
1.2. Dar click en “Mostrar procesos de todos los usuarios”
C-20
1.3. Buscar y seleccionar “mosquito”
1.4. Dar click en “Finalizar proceso”
Figura C.36 Administrador de tareas.
1.5. Compruebe si el error se ha solucionado escribiendo sólo la línea: mosquitto
-v
Figura C.37 Activación del servidor.
ERROR N°2: No se puede acceder a la tarjeta Raspberry Pi 3B
1. Verificar que la PC que se use para acceder a la tarjeta este en red con la misma.
Recomendación: usar la siguiente configuración en la PC.
C-21
Figura C.38 Dirección IP en la PC.
ERROR N°3: No encuentra el servidor de datos o Broker.
Figura C.39 Error: No se encuentra el Broker.
En la PC donde se encuentra el servidor de datos realizar lo siguiente.
1. Verificar que la PC esté conectada al punto de red
2. Verificar que todos los firewalls de la PC estén desactivados.
Figura C.40 Firewall de la PC.
2.1. Acceder a los Firewals de la PC.
2.2. En la pestaña ‘Acción’ dar click en propiedades
C-22
Figura C.41 Firewall de la PC.
2.3. En la pestaña ‘Perfil de dominio’ en la sección ‘Estado de Firewall’
seleccionar la opción “Inactivo” y dar click en aplicar como se muestra a
continuación:
Figura C.42 Estado del Firewall
2.4. Se debe seguir el mismo procedimiento en las pestañas “Perfil Privado” y
“Perfil Público”
2.5. Al finalizar dar click en aceptar.
3. Verificar que la PC contenga la configuración correcta de la IP interna.
C-23
4.1. Acceder a Panel de Control/ Redes e Internet/ Centro de Redes y Recursos
Compartidos/ Cambiar Configuración del Adaptador.
4.2. Click derecho en Conexión de área local y acceder a propiedades
4.3. En propiedades seleccionar Protocolo de Internet versión 4 (TCP/IPv4) y dar
click en propiedades.
Figura C.43 Protocolo de Internet versión 4.
4.4. El protocolo de Internet versión 4 (TCP/IPv4) debe estar configurado como
se ve a continuación:
Figura C.44 Propiedades del protocolo de Internet versión 4.
D-1
ANEXO D
MODELO DE ENCUESTA
1. ¿Cómo califica la calidad del sistema de realimentación visual?
Excelente bueno regular malo
2. ¿Cómo califica la interacción del usuario con la interfaz haciendo uso del joystick?
Excelente bueno regular malo
3. ¿Cómo califica el funcionamiento del modelo de carlike?
Excelente bueno regular malo
4. ¿Cuál es el nivel de dificultad al teleoperar debido los retardos en la comunicación?
Alto medio bajo
5. ¿Qué tan amigable y completa es la interfaz de la estación local?
Alto medio bajo
6. ¿Qué tan maniobrable es el sistema en general?
Alto medio bajo
7. ¿Cómo califica la reacción del robot móvil desde que se lo comanda hasta que el mismo presente movimiento?
Alto medio bajo5
8. ¿Qué aspectos se podrían mejorar en el sistema tele operado?
E-1
ANEXO E
CIRCUITOS ELECTRÓNICOS DEL CARLIKE FÍSICO
Figura E.1 Diagrama desarrollado en ISIS parte1.
1 2 3
EN
CO
DE
R
CO
NN
-SIL
3
12
U1
:A
74
14
1
EN
C. R
AS
P
10k
1 2
RA
SP
3.3
V
CO
NN
-SIL
4
1
VIN
+1
LM
324
1
VIN
-1
74
14
1
VO
UT
+1
10k
1
VO
UT
-1
10k
1 2
FU
EN
TE
CA
MA
RA
L2
93D
1
VIN
+2
10k
1
VIN
-2
CO
NN
-SIL
2
1
VO
UT
+2
TB
LO
CK
-I4
1
VO
UT
-2
CO
NN
-SIL
1
1 2 3
SE
RV
OM
OT
OR
CO
NN
-SIL
2
1
CO
NT
RO
L S
ER
VO
TB
LO
CK
-I2
1 2 3
DR
IVE
R M
OT
OR
DC
L2
93D
1 2
LU
CE
S R
AS
P
CO
NN
-SIL
2
R2
11
0R
R1
120
k
vcc
6V
AK
D5
LE
D-G
RE
EN
AK
D6
LE
D-G
RE
EN
lipo
b
lipo
a
1 2 3 4
SH
AR
P
CO
NN
-SIL
4
1 2 3 4
SH
AR
P1
CO
NN
-SIL
4
1 2 3 4 5 6
LE
DS
LIP
O
CO
NN
-SIL
6
led1
led2
led3
led4
neg
led
act
led
act
1 2 3
SW
ITC
H3A
CO
NN
-SIL
3
1 2 3
SW
ITC
H3
CO
NN
-SIL
3
1 2
MO
TO
RA
CO
NN
-SIL
2
1 2
MO
TO
R
CO
NN
-SIL
2
R3
11
0R
E-2
Fig
ura
E.2
Dia
gram
a d
esarr
olla
do e
n IS
IS p
arte
2.
lipo
a
R10
10k R11
10k
R12
10k R13
15k
A K
D1
LE
D-G
RE
EN
R14
22
0R
3 21
4 11
U2
:A
LM
324
5 67
4 11
U2
:B
LM
324
R15
22
0R
A K
D2
LE
D-R
ED
R16
15k R17
7.5
k
A K
D3
LE
D-G
RE
EN
R20
22
0R
12 1314
4 11
U2
:D
LM
324
10
98
4 11
U2
:C
LM
324
R21
22
0R
A K
D4
LE
D-R
ED
lipo
b
1 2 3
AL
IME
NT
AC
ION
1
CO
NN
-SIL
3
1 2 3 4
AL
IME
NT
AC
ION
2
CO
NN
-SIL
4
vcca
a
1 2
SW
ITC
H1
CO
NN
-SIL
2
1 2
SW
ITC
H2
CO
NN
-SIL
2
lipo
a
lipo
b
led1 le
d2
led3
led4
neg
E-3
Figura E.3 Diagrama desarrollado en ARES.
Figura E.4 Vista en 3D del circuito.