INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE ... fileinstituto tecnolÓgico y de estudios...

Evaluación del Desempeño de Calidad deServicio, Internet e Internet 2 en Aplicaciones

de Teleoperación Orientada a Laboratorios de laAutomatización de la Manufactura -Edición Única

Title Evaluación del Desempeño de Calidad de Servicio, Internete Internet 2 en Aplicaciones de Teleoperación Orientada aLaboratorios de la Automatización de la Manufactura -EdiciónÚnica

Issue Date 2010-12-01

Publisher Instituto Tecnológico y de Estudios Superiores de Monterrey

Item Type Tesis de maestría

Downloaded 06/10/2018 23:37:24

Link to Item http://hdl.handle.net/11285/569978

http://hdl.handle.net/11285/569978

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

CAMPUS MONTERREY

PROGRAMA DE GRADUADOS EN MECATRÓNICA Y TECNOLOGÍAS DE

INFORMACIÓN

EVALUACIÓN DEL DESEMPEÑO DE CALIDAD DE SERVICIO, INTERNET E

INTERNET2 EN APLICACIONES DE TELEOPERACIÓN ORIENTADA A

LABOTARORIOS DE LA AUTOMATIZACIÓN DE LA MANUFACTURA.

TESIS PRESENTADA COMO REQUISITO PARCIAL PARA

OBTENER EL GRADO ACADÉMICO DE:

MAESTRO EN CIENCIAS EN AUTOMATIZACIÓN

POR:

JOSÉ ANGEL GARCÍA OROZCO

MONTERREY, N.L. DICIEMBRE 3 DE 2010

INSTITUTO TECNOLÓGICO DE ESTUDIOS SUPERIORES DE MONTERREY

DIVISIÓN DE MECATRÓNICA Y TECNOLOGÍAS INFORMACIÓN

PROGRAMA DE GRA DUADOS EN MECATRÓNICA Y TECNOLOGÍAS DE INFORMACIÓN

Los miembros del comité de tesis recomendamos que la presente tesis del Ing. José Angel García Orozco sea aceptada como requisito parcial para obtener el grado académico de Maestro en Ciencias en

AUTOMATIZACIÓN

Comité de tesis:

Director de las maestrías de electrónica y automatización de MTI

Diciembre 3 de 2010

3

RESUMEN

En esta tesis se condensa el resultado de dieciocho meses de desarrollo de una plataforma

flexible, escalable y reconfigurable que permitirá poder compartir recursos de una celda de

manufactura a través de la red más grande del mundo, Internet, no siendo éste su objetivo

principal sino más bien exponer el resultado de la investigación que se llevó a cabo al probar este

sistema en diversos modos de este medio para conocer su desempeño y poder cuantificar las

diferencias de utilizar Internet, Internet con reservación de ancho de banda (calidad de servicio) o

utilizar Internet2.

Se presentará al lector desde los términos más básicos de los modelos de redes,

protocolos, historia de lo que es Internet e Internet2, investigaciones más recientes de la

teleoperación, el sistema que se desarrolló explicando sus componentes físicos, el medio

que utiliza, las áreas de oportunidad que tiene, la programación que se utilizó, las

herramientas que hicieron posible el análisis del tráfico de los datos, los resultados de las

pruebas realizadas con calidad de servicio, Internet e Internet2 y al final se discuten en

diversas tablas y gráficas los datos obtenidos de estas pruebas sin dejar duda al lector que

es posible hacer aplicaciones complejas para compartir en un medio del dominio público.

4

AGRADECIMIENTOS

Agradezco a los compañeros y amigos integrantes del departamento de mecatrónica y

automatización la oportunidad que se me brindó para poder colaborar en el desarrollo de

esta plataforma que estoy seguro es y será de mucha utilidad hoy en día y en el futuro para

estudiantes con deseos de formar su bases de conocimiento con instrumentos de última

generación pero que no tienen el recurso en su localidad. Agradezco su incondicional apoyo

técnico y humano que significó un impulso para mi trabajo y para mi carrera.

Agradezco a mis asesores todo su apoyo y orientación en el desarrollo de esta

plataforma y en esta investigación, siempre supieron cómo aterrizar mis ideas, evaluar mis

resultados para mejorarlos y darle un curso a este trabajo.

Muchas gracias a todos los que participaron con su tiempo y esfuerzo en cada prueba

que realicé, sé que pudo ser a veces tedioso todo el proceso pero siempre se mostraron

amables y excelentes amigos.

Por último agradezco a mi ahora esposa que todo el tiempo me ha motivado y ayudado a

realizar mis metas y esta no fue la excepción ya que dedicó mucho tiempo a colaborar

conmigo en esta investigación que es parte de ella también.

5

Indice Indice de figuras. ................................................................................................................................. 8

Indice de tablas. ................................................................................................................................ 13

1 Introducción. ............................................................................................................................. 14

1.1 Antecedentes. ................................................................................................................... 14

1.2 Motivación. ....................................................................................................................... 14

1.3 Objetivo. ............................................................................................................................ 15

1.4 Descripción del documento. ............................................................................................. 15

2 Revisión bibliográfica. .............................................................................................................. 17

2.1 Modelos de redes. .............................................................................................................. 17

2.1.1 El modelo Open System Interconnection (OSI). ........................................................ 17

2.1.2 El modelo del DOD (Departamento de defensa). ...................................................... 18

2.1.3 El modelo jerárquico de interred Cisco. .................................................................... 19

2.2 La red Ethernet. ................................................................................................................. 20

2.3 Topologías de Ethernet. ..................................................................................................... 20

2.4 Ancho de banda. ................................................................................................................ 21

2.5 Internet. ............................................................................................................................. 22

2.5.1 Protocolo de Control de Transmisión (TCP). ............................................................ 23

2.5.2 Calidad de servicio (QoS). ........................................................................................ 24

2.6 Internet2. ........................................................................................................................... 25

2.7 Estado del arte. .................................................................................................................. 29

2.7.1 IHM orientada a conexión a internet para sistemas teleoperados. ............................ 30

2.7.2 Medio de acceso remoto. ........................................................................................... 31

2.7.3 Computadora servidor. .............................................................................................. 31

2.7.4 Modo de acceso al controlador de robot. .................................................................. 32

2.7.5 Controlador de robot. ................................................................................................ 33

2.7.6 Robot. ........................................................................................................................ 33

2.7.7 Sensores de retroalimentación. .................................................................................. 34

2.8 Indices de desempeño. ....................................................................................................... 35

3 Metodología. ............................................................................................................................. 38

3.1 Metodología para evaluar el desempeño de una celda didáctica flexible de manufactura

con QoS, en Internet e Internet2 con una aplicación teleoperada tipo stand-alone. ................. 38

6

3.2 Componentes del sistema de teleoperación. ................................................................... 39

3.3 Pruebas de transmisión de datos. ..................................................................................... 41

3.4 Análisis de transmisión de datos. ...................................................................................... 41

4 Implementación. ....................................................................................................................... 43

4.1 Descripción de la Celda Flexible de Manufactura. ............................................................ 43

4.1.1 Interfaces humano máquina del sistema. ................................................................. 44

4.1.2 Medio de acceso remoto y computadora puente. ................................................... 44

4.1.3 Computadora servidor. ............................................................................................. 48

4.1.4 Método de acceso a controlador de robot. .............................................................. 48

4.1.5 Controlador XRC 2001. .............................................................................................. 50

4.1.6 Robot Motoman UP6. ............................................................................................... 50

4.1.7 Retroalimentación sensorial, audio y video. ............................................................. 51

5 Marco experimental .................................................................................................................. 51

5.1 Pruebas con calidad de servicio (QoS). ............................................................................. 51

5.1.1 Prueba a T 2. ............................................................................................................. 52

5.1.2 Prueba a T 38. ............................................................................................................ 56

5.2 Pruebas en Internet ........................................................................................................... 58

5.2.1 Pruebas locales .......................................................................................................... 59

5.2.2 Pruebas LAN. ............................................................................................................. 65

5.2.3 Pruebas en la misma ciudad. .................................................................................... 71

5.2.4 Prueba en otros estados de la república. .................................................................. 78

5.2.5 Prueba en otro país. .................................................................................................. 80

5.2.6 Pruebas en otro continente. ..................................................................................... 83

5.3 Pruebas Internet2.............................................................................................................. 89

5.3.1 Prueba A. ................................................................................................................... 89

5.3.2 Prueba A2. ................................................................................................................. 92

5.4 Tratamiento de datos. ....................................................................................................... 95

5.5 Análisis de porcentaje de pérdidas, retrasos y ancho de banda. ...................................... 97

6 Conclusiones............................................................................................................................ 107

6.1 Conclusiones técnicas. .................................................................................................... 107

6.2 Conclusiones personales. ................................................................................................ 112

6.3 Trabajos futuros. ............................................................................................................ 113

7

7 Referencias Bibliográficas. ..................................................................................................... 116

8

Indice de figuras.

Figura 2.1. Similitudes entre modelos OSI y DOD. .......................................................................... 19

Figura 2.2. Topologías de red comunes. ........................................................................................... 21

Figura 2.3. Segmento TCP. ............................................................................................................... 24

Figura 2.4. GigaPoPs y puntos importantes de la red Abilene (Internet2 Network, 2008). .............. 26

Figura 2.5. Algunas redes que conforman Internet2 (Noticias, 2004). ............................................. 27

Figura 2.6. Mapa de redes avanzadas (CLARA, 2008). .................................................................... 27

Figura 2.7. Topología de red CLARA en Agosto 2008 (CLARA T. d., 2008). ................................ 28

Figura 2.8. Internet 2 en México (Velázquez, Lucet, & Reyes, 2004). ............................................. 28

Figura 2.9. Componentes de sistemas robóticos teleoperados. (adaptado de (Ho & Zhang, 1999),

(Nuño, 2004)) .................................................................................................................................... 29

Figura 3.1. Esquema de metodología para evaluar el desempeño de una aplicación

teleoperada con QoS, Internet e Internet2. ........................................................................................ 39

Figura 3.2. Componentes del sistema de teleoperación de LASM.................................................... 39

Figura 4.1. Subsistemas de la CFM del LASM. ................................................................................ 43

Figura 4.2. IHM’s servidor y cliente. ................................................................................................ 44

Figura 4.3. Sockets para el intercambio de datos con la computadora servidor. ............................... 45

Figura 4.4. Interacción Cliente-Servidor bajo el protocolo TCP. ...................................................... 46

Figura 4.5. Traza de servidor hacia computadora puente. ................................................................. 47

Figura 4.6. Lectura y escritura en computadora puente. ................................................................... 47

Figura 4.7. Red Ethernet soportada por Switch. ................................................................................ 49

Figura 4.8. Interface AUI (izquierda) y Ethernet del transceiver. .................................................... 49

Figura 5.1. Reservación de ancho de banda. ..................................................................................... 52

Figura 5.2. Traza de cliente en San Carlos, Costa Rica. ................................................................... 52

Figura 5.3. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en

servidor. ............................................................................................................................................. 53

Figura 5.4 Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en cliente.

........................................................................................................................................................... 54

Figura 5.5. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en

servidor. ............................................................................................................................................. 54

Figura 5.6. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en cliente.

........................................................................................................................................................... 54

Figura 5.7 Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en servidor.

........................................................................................................................................................... 55

Figura 5.8. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente.

........................................................................................................................................................... 55


servidor 38KB. .................................................................................................................................. 56


cliente a 38 KB. ................................................................................................................................. 56

9

Figura 5.11.Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en

servidor a 38 KB. .............................................................................................................................. 57

Figura 5.12.Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en cliente

a 38 KB. ............................................................................................................................................ 57

Figura 5.13.Tamaño de paquetes (izquierda) y estadísticos principales de RTT para video en

servidor a 38 KB. .............................................................................................................................. 58

Figura 5.14. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente

a 38 KB. ............................................................................................................................................ 58


servidor localmente. .......................................................................................................................... 59

Figura 5.16. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en cliente

localmente. ........................................................................................................................................ 60



Figura 5.18. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos en cliente

localmente. ........................................................................................................................................ 61

Figura 5.19. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en



localmente. ........................................................................................................................................ 62


servidor, 2ª prueba local. ................................................................................................................... 63


cliente, 2ª prueba local. ..................................................................................................................... 63




cliente, 2ª prueba local. ..................................................................................................................... 64



Figura 5.26. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en cliente,

2ª prueba local. .................................................................................................................................. 65


servidor, prueba LAN 1. .................................................................................................................... 66


cliente, prueba LAN 1. ...................................................................................................................... 66





Figura 5.31. Estadísticos principales de tamaño de paquetes (arriba) de RTT para datos en servidor,

prueba LAN 1. ................................................................................................................................... 67

10


prueba LAN 1. ................................................................................................................................... 68









Figura 5.37. Tamaño de paquetes (arriba) y estadísticos principales de RTT para video en servidor,

prueba LAN 2. ................................................................................................................................... 70


prueba LAN 2. ................................................................................................................................... 71

Figura 5.39. Traza de cliente en la misma ciudad a 0.9 Km. ............................................................ 72


servidor, prueba a 0.9 Km. ................................................................................................................ 72


cliente, prueba a 0.9 Km.................................................................................................................... 72


servidor, prueba a 0.9 Km. ................................................................................................................ 73


cliente, prueba a 0.9 Km.................................................................................................................... 73

Figura 5.44. Estadísticos principales de RTT para video en servidor, prueba a 0.9 Km................... 74


prueba a 0.9 Km. ............................................................................................................................... 74

Figura 5.46. Traza de cliente en la misma ciudad a 10.8 Km. .......................................................... 75


servidor, prueba a 10.8 Km. .............................................................................................................. 75

Figura 5.48. Tamaño de paquetes (arriba) y estadísticos principales de RTT para audio en cliente,

prueba a 10.8 Km. ............................................................................................................................. 76




cliente, prueba a 10.8 Km.................................................................................................................. 76




prueba a 10.8 Km. ............................................................................................................................. 77

Figura 5.53. Traza de cliente en Guaymas, Sonora (1081.43 km). ................................................... 78


servidor, cliente en Sonora. ............................................................................................................... 78

11

Figura 5.55. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para audio en

cliente, cliente en Sonora. ................................................................................................................. 79





Figura 5.58. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para video en





servidor, cliente en Chicago. ............................................................................................................. 81

Figura 5.61. Tamaño de paquetes (arriba) y estadísticos principales de RTT para audio en cliente,

cliente en Chicago. ............................................................................................................................ 81


servidor, cliente en Chicago. ............................................................................................................. 82

Figura 5.63. Tamaño de paquetes (arriba) y estadísticos principales de RTT para datos en cliente,






Figura 5.66. Traza de cliente en Paola, Italia. ................................................................................... 84


servidor, cliente en Italia. .................................................................................................................. 84

Figura 5.68. Estadísticos principales de RTT para audio en cliente, cliente en Italia. ...................... 84


servidor, cliente en Italia. .................................................................................................................. 85


cliente, cliente en Italia...................................................................................................................... 85

Figura 5.71. Estadísticos principales de RTT para video en servidor, cliente en Italia..................... 85


Italia................................................................................................................................................... 86

Figura 5.73. Traza de cliente en Madrid, España. ............................................................................. 86


servidor, Cliente en Madrid. .............................................................................................................. 87

Figura 5.75. Estadísticos principales de RTT para audio en cliente, Cliente en Madrid. ................. 87




cliente, Cliente en Madrid. ................................................................................................................ 88

12

Figura 5.78. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para video en



cliente, Cliente en Madrid. ................................................................................................................ 89

Figura 5.80. Traza de cliente en College Station, Texas (Internet2). ................................................ 90


servidor, Internet2 A. ........................................................................................................................ 90


cliente, Internet2 A. ........................................................................................................................... 90




cliente, Internet2 A. ........................................................................................................................... 91




Internet2 A. ....................................................................................................................................... 92


servidor, Internet2 A2. ...................................................................................................................... 92


cliente, Internet2 A2. ......................................................................................................................... 93


servidor, Internet2 A2. ...................................................................................................................... 93


cliente, Internet2 A2. ......................................................................................................................... 93

Figura 5.91. Estadísticos principales de RTT para video en servidor, Internet2 A2. ....................... 94


Internet2 A2. ..................................................................................................................................... 94

Figura 5.93. LSD (p< 0.05) para prueba T 2. ................................................................................... 95

Figura 5.94. LSD (p< 0.05) para prueba G con alta calidad de video. ............................................. 96

Figura 5.95. LSD (p< 0.05) para prueba G con baja calidad de video. ............................................ 96

Figura 6.1. Porcentaje de RTT de servidor a puente en Internet, Local, Internet2 y QoS. ............. 107

Figura 6.2. Comparación de porcentaje de pérdidas en Internet, Internet2 y QoS. ......................... 108

Figura 6.3. Comparación de sonido en paquetes grandes y paquetes pequeños. ............................ 109

Figura 6.4. Distribución de datos en video de sin dividir. ............................................................... 110

Figura 6.5. Distribución de datos en video dividido, 1er y 2º canal. ............................................... 110

Figura 6.6. Distribución de datos en video dividido, 3er y 4º canal. ............................................... 111

Figura 6.7. Distribución de datos en video dividido, 5º y 6º canal.................................................. 111

Figura 6.8. Tiempos de procesamiento y tiempos de tareas realizadas. .......................................... 114

Figura 6.9. Separación de conjuntos por tareas. ............................................................................. 114

13

Indice de tablas.

Tabla 2.1. Capas del modelo OSI (Hill, 2002). ................................................................................. 18

Tabla 2.2 Redes Ethernet de 1 Mbps a 10 Mbps. .............................................................................. 21

Tabla 2.3. Registro de RTT y pérdida de paquetes según la distancia del cliente (Benali, Idasiak, &

Fontaine, 2001), (Oboe & Fiorini, 1997). ......................................................................................... 36

Tabla 2.4 Condensado de artículos referenciados. ............................................................................ 37

Tabla 5.1. Distancia entre cliente servidor y duración de la prueba con QoS. .................................. 97

Tabla 5.2. Distancia entre cliente servidor y duración de la prueba local. ........................................ 97

Tabla 5.3. Distancia entre cliente servidor y duración de la prueba en Internet comercial. .............. 97

Tabla 5.4. Distancia entre cliente servidor y duración de la prueba en Internet2. ............................ 97

Tabla 5.5. Porcentaje de pérdida de paquetes y retardo promedio en prueba con QoS. ................... 98

Tabla 5.6. Porcentaje de pérdida de paquetes y retardo promedio en prueba local........................... 98

Tabla 5.7. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet comercial

parte 1. ............................................................................................................................................... 99

Tabla 5.8. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet comercial

parte 2. ............................................................................................................................................... 99

Tabla 5.9. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet2. .............. 99

Tabla 5.10. Conexiones óptimas. .................................................................................................... 100

Tabla 5.11. Conexiones con bajo desempeño. ................................................................................ 100

Tabla 5.12. Velocidad en conexión servidor puente, puente servidor en prueba con QoS. ............ 101

Tabla 5.13. Velocidad en conexión cliente puente, puente cliente en prueba con QoS. ................. 101

Tabla 5.14. Velocidad en conexión servidor puente, puente servidor en prueba local. .................. 101

Tabla 5.15. Velocidad en conexión cliente puente, puente cliente en prueba local. ....................... 102

Tabla 5.16. Velocidad en conexión servidor puente, puente servidor en prueba en Internet. ......... 102

Tabla 5.17. Velocidad en conexión cliente puente, puente cliente en prueba en Internet. .............. 103

Tabla 5.18. Velocidad en conexión servidor puente, puente servidor en prueba en Internet2. ....... 103

Tabla 5.19. Velocidad en conexión cliente puente, puente cliente en prueba en Internet2. ............ 104

Tabla 5.20. Mejor desempeño de velocidad en conexiones servidor puente, puente servidor. ....... 104

Tabla 5.21. Mejor desempeño de velocidad en conexiones cliente puente, puente cliente............. 104

Tabla 5.22. Peor desempeño de velocidad en conexiones servidor puente, puente servidor. ......... 105

Tabla 5.23. Peor desempeño de velocidad en conexiones cliente puente, puente cliente. .............. 105

Tabla 5.24. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba con QoS. ............. 105

Tabla 5.25. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba local. ................... 106

Tabla 5.26. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba en Internet. .......... 106

Tabla 5.27. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba en Internet2. ........ 106

Tabla 6.1. Porcentaje de pérdida de paquetes y retardo promedio en prueba de video con 1 sólo

canal y con 6 canales. ...................................................................................................................... 112

14

1 Introducción.

1.1 Antecedentes. Actualmente existen avances sustanciales en el desarrollo de redes que ha puesto a Internet tal

cual se conoce como un método obsoleto para compartir recursos en aplicaciones que requieran

interacción en tiempo real. Debido a que la descripción de Internet cabe en la categoría de redes no

determinísticas es muy difícil asegurar una experiencia de teleoperación en tiempo real, si a caso es

posible implementar técnicas y algoritmos de control para hacerlo lo más cercano posible a tiempo

real (Oboe & Fiorini, 1997), ya que actualmente toda información en Internet viene dada con la

misma prioridad en toda la red de una computadora a otra. Las diferentes vertientes que ofrece

aplicar prioridades o a lo que mejor se le conoce como calidad de servicio en la Internet han podido

disminuir la inestabilidad de la red ofreciendo opciones de tener aplicaciones como: impartición de

clases por videoconferencias, multi-videoconferencia, video bajo demanda, acceder a bases de

datos multimedia, entre otras. Lamentablemente estas opciones no se ofrecen gratuitamente como la

Internet misma y en muchos de los casos no son suficientes cuando se pretende manipular

aplicaciones que utilizan un complejo conjunto de herramientas como lo son la teleinmersión,

telemedicina, bibliotecas digitales, laboratorios virtuales, manipulación a distancia y visualización

de modelos 3D. Afortunadamente para resolver este problema de la necesidad de una red con más

capacidades que la que actualmente se conoce hace aproximadamente poco más de diez años se

tomó la iniciativa de desarrollar una red de alta velocidad denominada Internet2, con la finalidad de

proveer a la comunidad científica y universitaria de una red que permitiera formar nuevas

generaciones de investigadores para el desarrollo de aplicaciones científicas y educativas de alta

tecnología (CUDI, 1999). Ahora que se cuenta con estas tres formas comunes de comunicarse en

red, un campo por explorar se encuentra en el desarrollo de una aplicación de demanda de

capacidades importante y evaluarlo para encontrar la diferencia de utilizar una u otra tecnología de

redes.

1.2 Motivación.

Día con día los desarrolladores de software han buscado involucrar a Internet en teleoperación

tanto que ahora en su mayoría las investigaciones sobre robótica no se conciben sin este medio de

comunicación ya que todo mundo puede acceder a él, es tan importante que muchos investigadores

aseguran que en un futuro no muy lejano este medio puede llegar a ocupar la opción número uno

para el desarrollo de aplicaciones de teleoperación. La bondad de este medio puede llegar a ofrecer

15

la oportunidad de poder aplicar cirugía a distancia o la enseñanza de costosas máquinas utilizadas

actualmente en la industria que no todas las instituciones pueden adquirir sin que el Ingeniero o el

estudiante tenga que estar presente físicamente. Para poder crear esas importantes aplicaciones las

instituciones de investigación deben contar con información que respalde la toma de decisiones

cuando se escoge un medio u otro de comunicación ya que existen varias opciones de Internet como

aplicar calidad de servicio o utilizar Internet2. Esta tesis busca exponer las diferencias de utilizar

una opción u otra probadas en una celda flexible didáctica de manufactura y así dar la certeza a

investigaciones futuras de la ventaja que ofrece cada opción.

1.3 Objetivo. El objetivo de esta tesis es investigar las diferencias entre utilizar Internet, Internet con calidad

de servicio (reservación de ancho de banda) e Internet2 en la teleoperación de una celda flexible

didáctica de manufactura utilizando una aplicación tipo stand alone para detectar variables de

control. De esta manera poder asegurar si es necesario un mayor ancho de banda para manipular

aplicaciones de este tipo.

1.4 Descripción del documento. Esta tesis se compone de seis capítulos. Que se describen a continuación.

En el primer capítulo se da una breve explicación del motivo de realización de este proyecto

fundamentando con los antecedentes en el tema, las razones de por qué es necesaria esta

investigación además de fijar un objetivo claro que se pretende cumplir con esta investigación.

En el segundo capítulo se presenta la revisión bibliográfica en donde se enmarca esta

investigación, todo lo que el lector tiene que saber para poder entender algunos conceptos que se

manejan en esta tesis, también se presenta el estado del arte, algunas de las investigaciones que se

tuvieron que revisar para poder comparar otros trabajos con éste.

En el tercero se expone la metodología a seguir para realizar esta tesis. Todo el plan de trabajo

que se fue estructurando para completar el objetivo de esta tesis.

16

En el cuarto se presenta la implementación a detalle de cómo se realizó la programación, el

hardware que se utilizó, y todas las herramientas de software que hicieron posible cumplir con el

objetivo planteado en el capítulo uno.

En el quinto capítulo se encuentra toda la información recaudada del sistema, todas las pruebas

a las que se sometió esta investigación y cómo respondió este sistema ante cada una de ellas.

En el sexto capítulo se concluye con dos tipos de argumentos, técnicos y personales. En el

primero se expresa lo que el sistema arrojó, sus detalles y debilidades así como también sus

fortalezas. En la conclusión personal se exponen las razones que más afectaron al sistema y por qué

se obtuvieron esos resultados. Este capítulo finaliza con una sección de trabajos futuros en los

cuales se recomiendan muchas mejoras que se le deberían hacer al sistema.

17

2 Revisión bibliográfica. En este capítulo se presenta al lector las bases de modelos de redes, la red Ethernet, el protocolo

de conexión TCP y una breve reseña de lo que es Internet e Internet2 ya que esta tesis está orientada

a estos temas. Al final de este capítulo se concluye con una tabla que resume las referencias

actualizadas en el tema de teleoperación de sistemas robóticos a través de Internet con el fin de

dejar en el lector la idea general de las investigaciones más recientes.

2.1 Modelos de redes.

Hace dos décadas y media las redes computacionales se desarrollaban sin ningún enfoque a

futuro y con muchos desórdenes en varios sentidos. El crecimiento acelerado de redes no daba

tiempo para una estructuración bien fundamentada, ya que se estaba viviendo un incremento tanto

en la población de éstas, como en la producción de tecnología para su mejor administración.

Naturalmente los conflictos existentes entre dichas redes pronto se dejaron notar, hasta llegar a una

división total entre ellas, impidiendo que pudieran intercambiar información.

Para enfrentar este problema de incompatibilidad, organizaciones como la Organización

Internacional para la Estandarización (ISO) realizaron investigaciones sobre los modelos de

conexión más populares, con el objetivo de hallar reglas generales para todas las redes. Fue

entonces cuando la ISO desarrolló un modelo de red bajo el nombre de modelo OSI (Open System

Interconnection), el cual permitiría que los proveedores crearan redes compatibles con otras

diferentes (Kurose & Ross, 2008). En las secciones posteriores se detallarán los modelos más

populares que describen las redes existentes.

2.1.1 El modelo Open System Interconnection (OSI). Como se mencionó anteriormente, el modelo OSI se ideó inicialmente con el propósito general

de homogenizar protocolos de diferentes proveedores. Este modelo es una de las mejores

herramientas con que se cuenta para categorizar y describir las interacciones que se llevan a cabo en

redes computacionales.

A la información que se trafica en una red computacional comúnmente se le conoce como trama,

paquete, segmento o mensaje indistintamente, cuyo contenido cuenta con los siguientes

componentes:

18

Dirección de origen: identificación del remitente.

Dirección de destino: identificación de quien recibe el mensaje.

Carga útil: datos que lleva el mensaje. La información en sí.

Verificación: sistema de control de errores que para el caso de OSI se utiliza FCS (Frame

Check Sequence) para corroborar el contenido del paquete.

El modelo OSI se divide en siete capas, cada una de las cuales cumple con una función en

la red dentro del proceso de transportar la información que viaja sobre ella (Hill, 2002). La Tabla

2.1 describe de forma inversa de manera general estas siete capas, para su mejor comprensión.

Tabla 2.1. Capas del modelo OSI (Hill, 2002).

2.1.2 El modelo del DOD (Departamento de defensa).

El Departamento de Defensa (Department of Defense, DOD) de los Estados Unidos es el autor

de este modelo, sin imaginar que posteriormente adquiriría gran popularidad. Comúnmente

llamado modelo de referencia TCP/IP, se ideó como una red que pudiera ser objeto de atentados y

por consiguiente pérdida de hardware, con el principal objetivo de que se no interrumpiera la

comunicación (Tanenbaum, 2003). Básicamente, para poder transferir datos de un proceso a otro,

este modelo se enfoca en cuatro capas relativamente independientes, las cuáles se detallan en a

continuación:

Capa Función

7 Aplicación Traduce lo que la aplicación necesita a lo que los protocolos puedan entender.

6 Presentación Da formato a los paquetes: compresión, encriptado, decodificación y relaciona caracteres.

5 Sesión Responsable de la conexión entre dos aplicaciones.

4 Transporte Según el protocolo manejado, establece la comunicación entre las aplicaciones, se encarga de fragmentación, multiplexado, regular el flujo.

3 Red Responsable de trazar rutas y el direccionamiento lógico.

2 Enlace de datos Responsable de direccionamiento físico y control de NIC (Network Interface Card), añade también la FCS para detectar algunos errores.

1 Física Atiende las características físicas como cableado y conectores además convierte bits y bytes en impulsos eléctricos u ondas según sea el caso.

19

Aplicación: contiene los protocolos que se necesitan para soportar diferentes aplicaciones.

Anfitrión-Anfitrión: se encarga de proveer sistemas que den la confianza de que los datos

llegarán completos y en orden.

Interred: cuando los dispositivos estén conectados a diferentes redes, esta capa provee una

serie de procedimientos para permitir que los datos atraviesen las diferentes redes

interconectadas.

Acceso a redes: le conciernen aspectos de rutas para enlazar los datos. Transmite la

información por el medio físico.

Figura 2.1. Similitudes entre modelos OSI y DOD.

2.1.3 El modelo jerárquico de interred Cisco.

A diferencia de los modelos descritos anteriormente, los cuales explican las comunicaciones en

redes, el modelo jerárquico de interred Cisco se enfoca en capas del diseño de la topología de una

interred. Sus principales objetivos son proporcionar mejoras en el rendimiento y tener una

tolerancia óptima ante fallos. El modelo jerárquico de interred consta de tres capas (Hill, 2002).

Capa núcleo: se centra en la red en dónde la velocidad es lo más importante por el

volumen de tráfico que cruza esta parte. Por esas razones compresión,

enrutamiento, encriptación y otras actividades se realizan antes de esta sección.

Capa de distribución: aquí es donde se lleva a cabo el mayor procesamiento de

paquetes además de la mayoría de las funciones de soporte.

Capa de acceso: está en contacto directo con el usuario dando accesos locales.

20

2.2 La red Ethernet.

Por su sencillez y bajo costo Ethernet se ha convertido en la tecnología más utilizada para la

conexión en redes. Desde sus orígenes (años 70 en Palo Alto California) se colocó como una muy

buena solución en redes por manejar la técnica CSMA/CD (Carrier-Sense Multiple Access with

Collision Detection), cuya característica peculiar es analizar el canal físico antes de transmitir

información, de esta manera si el canal tiene alguna colisión, esta técnica espera un tiempo

aleatoriamente para volver a intentar transmitir. Se permite una longitud máxima de 500 metros al

conectar una tarjeta Ethernet a un transmisor receptor, que recoge la información y la distribuye en

la red. Además permite conectar muchos segmentos de cable a través de repetidores, que toman la

señal que lleva la información y la amplifican para volver a transmitirla con la condición de no

exceder una longitud de 2.5 km y no más de cuatro repetidores entre un transmisor receptor y otro

(Held, 1996).

2.3 Topologías de Ethernet.

Ethernet se desenvuelve utilizando estructuras topológicas de tipo bus o estrella. En la topología

de bus todas las computadoras están conectadas a un cable que transporta la información, ésta viaja

en ambos sentidos y además tiene en sus extremos una resistencia conocida como terminador, con

la principal función de indicar que no existen más computadoras en el extremo y cerrar el bus. Por

su naturaleza esta topología permite que todos los dispositivos de la red puedan ver las señales de

los demás, esto hace que a menudo sucedan problemas de tráfico y colisiones, además que la hace

vulnerable a no tener acceso a más puntos de la red si ésta se rompe. Es la topología más usada en

redes pequeñas.

En cambio la topología estrella permite formar redes en donde las computadoras están

conectadas directamente a un centro y todo el tráfico de información se hace a través de éste. Es la

más popular entre las redes locales e igualmente que la de tipo bus envía los datos a todas las

computadoras y sólo a la que va el mensaje lo recibe. Su ventaja más grande es que si alguna

computadora se desconecta porque se ha roto el cable sólo esa deja de recibir la información y las

demás siguen igual. En contraste con su desventaja más grande si el centro de la red se afecta, toda

la red permanece inactiva (Hill, 2002). En la Figura 2.2 se muestra gráficamente cómo suelen ser

estas topologías.

21

2.4 Ancho de banda.

Con forme ha ido evolucionando esta tecnología, Ethernet ha cambiado sus velocidades en

múltiples maneras que van desde 1 Mbps hasta 1 Gbps aunque actualmente la más común es de 100

Mbps aunado a esto también se ha seccionado en dos métodos para señalización de datos,

broadband (banda ancha), la cual el medio de transmisión se subdivide en frecuencias y así formar

dos o más subcanales y baseband, en donde sólo existe un canal en el medio. En la Tabla 2.2 se

muestran algunas variantes de Ethernet según sus características principales (Tanenbaum, 2003),

(Held, 1996).

Tabla 2.2 Redes Ethernet de 1 Mbps a 10 Mbps.

Características operacionales

Ethernet

10BASE-2

1BASE-5

10BASE-T

10BROAD-36

100BASETX

1000BASET

Mbps 10 10 1 10 10 100 1000

Protocolo de acceso CSMA/CD CSMA/CD CSMA/CD CSMA/CD CSMA/CD CSMA/CD CSMA/CD

Tipo de señalización basebase baseband baseband baseband broadband baseband baseband

Longitud máxima de segmento [m]

500 185 250 100 1800 100 100

Medio 50 Ω

coaxial 50 Ω

coaxial UTP UTP

75 Ω coaxial

UTP UTP

(4pares)

Topología Bus Bus Estrella Estrella Bus Estrella Estrella

Figura 2.2. Topologías de red comunes.

22

2.5 Internet.

Internet no estaba pensada para ser una red mundial que albergara a miles de redes y

conexiones, nació con el nombre de ARPANET como un experimento del gobierno de los Estados

Unidos en 1969, cuando se trataba de solucionar un problema para construir una red robusta que

pudiera resistir ataques militares como bombardeos. ARPANET se construyó bajo el modelo de

datagramas, cuya fortaleza es la simplicidad y habilidad para adaptarse a cambios en la topología de

la red y su principal característica resulta que cada paquete se reenvía a través de la red sin importar

su destino. ARPA (Agencia de Proyectos Avanzados de Investigación del Departamento de Defensa

de los Estados Unidos) posteriormente transformada a DARPA (Agencia de Proyectos Avanzados

de Investigación en Defensa) inicialmente conectaba a investigadores en puntos lejanos

permitiéndoles compartir recursos de espacio en disco duro, bases de datos, computadoras, etc.

Posteriormente otras redes experimentales que utilizaban paquetes de radio y satélite se conectaron

a ARPANET hasta que en 1980 ARPANET tuvo que dividirse en ARPANET y Milnet (red militar

con información no clasificada) que con tecnología que DARPA proporcionó pudo mantenerse la

interconexión. A finales de los setentas se unieron redes cooperativas descentralizadas como UUCP,

una red mundial de UNIX y USENET (red de usuarios) cuyo principal objetivo era dar servicio a la

comunidad universitaria aunque finalmente tuvo objetivos comerciales. En los ochentas redes como

CSNET (Red de Ciencias de Cómputo) y BITNET empezaron a proporcionar redes de alcance

nacional a comunidades académicas y de investigación hasta que Internet se formó de una

amalgama de muchas de redes de cómputo que llegan a millones de personas en todo el mundo.

Internet ha demostrado tal velocidad y efectividad como medio de comunicación, que ha

trascendido su misión original (Ryer, 1994), (Wang, 2001).

A pesar de que la Internet actual es más rápida y ha incrementado su tamaño, su arquitectura

básica no ha cambiado desde su creación. La internet todavía opera como una red de datagramas, lo

que quiere decir que el tiempo de arribo de los paquetes no está garantizado sumado a que algunos

paquetes pueden ser descartados por congestión de la red. Este comportamiento impredecible no se

lleva bien con las nuevas aplicaciones de hoy en día tales como Internet telefónica o conferencias de

video por Internet que no toleran retrasos, desfase de información o pérdida de datos cuando están

operando. Para resolver estos problemas la IETF (internet Engineering Task Force) se ha dado a la

tarea de desarrollar nuevas tecnologías y estándares para proveer seguridad y diferenciar servicios

encapsulados con el término de QoS (Quality of Service) (Wang, 2001) lo cual asegura el recibir

los paquetes de datos bajo condiciones previamente definidas con la desventaja de tener un costo.

23

2.5.1 Protocolo de Control de Transmisión (TCP).

TCP es uno de los principales protocolos que radica en la capa de transporte. En el nivel de

aplicación, facilita administrar los datos que vienen del nivel más bajo del modelo. Entre sus

principales características se encuentran el permitir reordenar los datagramas, permite monitorear el

flujo de los datos para evitar la saturación de la red, permite que los datos se formen en segmentos

de longitud variable y así como también permite conmutarlos en la misma conexión para que

circulen simultáneamente además que con TCP, las aplicaciones pueden comunicarse en forma

segura gracias al sistema de acuse de recibo independientemente de las capas inferiores (León,

2002).

2.5.1.1 Formato de los datos en Control de Transmisión (TCP).

En la Figura 2.3 se representa la forma en que está constituido un segmento TCP. El significado

de los campos se describe a continuación (Douglas, 2000):

Puerto de origen (16 bits): Puerto de la aplicación en curso en la máquina de origen.

Puerto de destino (16 bits): Puerto de la aplicación en curso en la máquina destino.

Número de secuencia (32 bits): Indica la posición del flujo de datos del que envía en el segmento.

Número de acuse de recibo (32 bits): Indica el número de octetos que la fuente espera recibir en el

siguiente.

Margen de datos (4 bits): Esto permite ubicar el inicio de los datos en el paquete.

Reservado (6 bits): Campo actualmente en desuso pero se proporciona para el uso futuro.

Indicadores (6x1 bit): Los indicadores representan información adicional:

URG: Si es 1, procesar en forma urgente.

ACK: Si es 1, el paquete es un acuse de recibo.

PSH (PUSH): Si es 1, el paquete opera de acuerdo con el método PUSH.

RST: Si es 1, se restablece la conexión.

SYN: Indica un pedido para establecer una conexión.

FIN: Si es 1, interrumpe la conexión.

Ventana (16 bits): Campo para saber los bytes que el receptor desea recibir sin acuse.

CheckSum (CRC): Se realiza tomando la suma del campo de datos del encabezado para poder

verificar la integridad del encabezado.

Puntero urgente (16 bits): Indica el número de secuencia donde la información es urgente.

Opciones (tamaño variable): Opciones diversas.

24

Relleno: Espacio restante después de que las opciones se rellenan con cero para una longitud

múltiplo de 32 bits.

Figura 2.3. Segmento TCP.

2.5.2 Calidad de servicio (QoS).

Referirse a calidad de servicio o como popularmente se le conoce por sus siglas en inglés QoS

no es más que la capacidad de algunos proveedores de servicios de red de otorgar ciertos privilegios

a sus clientes los cuales básicamente están dentro de las siguientes cuatro categorías (Alistair &

Packman, 2000):

Ancho de banda: se refiere a garantizar que la red tendrá la capacidad suficiente para

soportar los requerimientos de desempeño (throughput, que se expresa en paquetes por

segundo) de la aplicación utilizada.

Latencia: es el retraso o también llamado delay en inglés que describe lo que tarda un

paquete en enviarse de un nodo a otro. Esta definición se mide en tiempo de ida y vuelta del

paquete (RTT) este tiempo incluye lo que se toma cada nodo por el que pasa el paquete y el

procesamiento de éste en la red.

Jitter: variación del retardo entre llegada de paquetes a su destino y la salida de éstos en

alguna línea donde compiten por estar compartiendo el enlace.

Pérdida de paquetes: tener una baja pérdida de paquetes es muy importante cuando se

manejan aplicaciones de audio y/o video. Afortunadamente cuando se pierden paquetes

algunos protocolos soportan la retransmisión de éstos. Cuando las aplicaciones son de datos

podría favorecer esto, pero en el caso que fueran de video y/o audio resulta inconveniente

ya quela retransmisión lleva mucho tiempo y decae el desempeño de aplicaciones en tiempo

real.

25

Debido a lo complejo que resulta soportar diversos tipos de tráfico, el Internet comercial trata a

éste de manera similar y trata de entregarlo bajo la promesa del mejor esfuerzo, lo que quiere decir

que el tráfico es descartado aleatoriamente y no se hace nada por filtrar alguno de manera

inteligente. Se observa que el Internet comercial tiende a descartar los paquetes de aplicaciones que

tienen mayor demanda de ancho de banda y que colocan paquetes en la red más rápido que aquellas

aplicaciones que no cumplen estas características (Alistair & Packman, 2000).

2.6 Internet2.

Internet2 es un consorcio liderado por 206 universidades junto con la industria y el gobierno

cuyos miembros trabajan en coordinación con las iniciativas estatales y regionales en E. U. y están

coordinados con organizaciones internacionales tales como la IETF. Estos esfuerzos están

orientados hacia áreas como (Carrera, 2003), (Velázquez, Lucet, & Reyes, 2004):

Aplicaciones avanzadas que permitan acceso interactivo a información y recursos

que no serían posibles en la internet comercial.

Nuevas potencialidades de red como QoS, multicasting e IPv6 para proveer un

internet del mañana con un desempeño confiable.

Middleware, software que proporciona seguridad, directorios y otros servicios para

aplicaciones avanzadas. Ya que en la internet actual estas aplicaciones tienen que

proveer esos servicios por sí mismas se han producido incompatibilidades entre

ellas. Por medio de estandarización e interoperabilidad el “middleware” hará

aplicaciones de red más fáciles de usar.

Debido a la creación de nuevas aplicaciones que demandan más ancho de banda, seguridad,

mejor calidad en el arribo de información, necesidades de tiempo real, entre otros requerimientos

fue necesario desarrollar una nueva tecnología de red, a la que por su predecesor se ha llamado

Internet2. Este proyecto inició en octubre de 1998, formando parte de él 34 universidades de E. U.

para compartir aplicaciones que no podían desempeñarse correctamente en la Internet comercial.

Entre las aplicaciones que más destacan se encuentran: laboratorios virtuales, laboratorios remotos,

educación a distancia, bibliotecas digitales, cálculos complejos y en tiempo real, medicina a

distancia y las creaciones artísticas, entre otras (Velázquez, Lucet, & Reyes, 2004).

26

Internet2 es administrada por UCADI (University Corporation for Advanced Internet

Development), consorcio sin fines de lucro dirigido por miembros universitarios que trabajan con

colaboradores para la dirección del desarrollo de esta red (Carrera, 2003).

Abilene es una de las redes de alta velocidad que soportan Internet2. Sus enlaces van desde los

2.4 a los 9.6 Gbps. Estos enlaces se encuentran entre ellos por puntos regionales llamados GigaPoPs

(Puntos de presencia) donde las universidades tienen acceso a este medio. En la Figura 2.4 se

muestran los diferentes GigaPops y otros puntos importantes dentro de la red actualmente.

Figura 2.4. GigaPoPs y puntos importantes de la red Abilene (Internet2 Network, 2008).

Abilene constituye el puente para enlazar otras redes con estas capacidades en otros países

como la red CUDI en México, REUNA en Chile, RETINA en Argentina, RNP en Brasil,

CANARIE en Canadá, RedIRIS en España, DANTE en Europa y CLARA en América Latina. La

Figura 2.5 muestra otras redes y su enlace que conforman Internet2, la Figura 2.6 muestra el

panorama mundial de redes avanzadas (Internet2), la Figura 2.7 muestra la topología de las redes

de América Latina actualmente y en la Figura 2.8 se muestra los enlaces a Internet2 de México.

27

Figura 2.5. Algunas redes que conforman Internet2 (Noticias, 2004).

Figura 2.6. Mapa de redes avanzadas (CLARA, 2008).

28

Figura 2.7. Topología de red CLARA en Agosto 2008 (CLARA T. d., 2008).

Figura 2.8. Internet 2 en México (Velázquez, Lucet, & Reyes, 2004).

29

2.7 Estado del arte.

En esta sección se explicará detalladamente el enfoque que tiene la investigación de sistemas

teleoperados en la actualidad, profundizando en temas como los componentes que conforman un

sistema de este tipo y las variables que resultan clave mediar para describir su desempeño. Fue

importante dirigir esta investigación a estos temas para tomar decisiones en la programación y

arquitectura que se siguió en el LASM y también para tener un punto de comparación con otras

investigaciones.

Mucha de la literatura revisada aseguraba que la correcta funcionalidad de un sistema

teleoperado generalmente contiene en su arquitectura los siguientes componentes presentados en

forma secuencial (Figura 2.9):

Usuario.

Interface humano-máquina (IHM) orientada a conexión a internet.

Medio de acceso remoto.

Computadora servidor.

Método de acceso a controlador de robot.

Controlador de robot.

Robot.

Sensores de retroalimentación.

Figura 2.9. Componentes de sistemas robóticos teleoperados. (adaptado de (Ho & Zhang, 1999),

(Nuño, 2004))

30

2.7.1 IHM orientada a conexión a internet para sistemas teleoperados.

Una descripción para el componente usuario no es indispensable para el entendimiento de los

componentes de teleoperación, nos basta con decir que es la persona a interactuar con el sistema

con ubicación remota a él. Por lo tanto la IHM, como es un componente basado en internet, se

convierte en el cliente dentro de esta cadena, el cual tiene dos maneras de llegar a interactuar con la

computadora servidor, a través de un navegador de red (web browser como: Internet Explorer,

Netscape Navigator, etc.) o a través de lo que común mente en la literatura se conoce como stand-

alone (aplicación independiente) con capacidades de conexión a internet.

Un software web browser se basa en Hyper Text Transport Protocol (HTTP) para desplegar

texto e información gráfica al usuario. La IHM que se apegue a esta manera de presentar la

información por internet se programa en Hyper Text Markup Language (HTML). En cambio una

aplicación stand-alone puede ser programada en cualquier lenguaje de programación con las

características de ser dependiente de la plataforma en que se programó y manejar protocolos de red

para que pueda conectarse a la computadora servidor.

Independientemente de la manera en que se haya construido la IHM, ésta contendrá el conjunto

de botones, uso de imágenes interactivas o representaciones virtuales del robot, espacios para

introducir información alfanumérica, comandos por reconocimiento de voz, etcétera para ejecutar

una acción sobre el robot. Como ejemplos a estas afirmaciones se pueden mencionar: el robot de

cuatro patas SILO4 (Galvez, Estremera, & González de Santos, 2000) utilizado en el laboratorio

de visión y robótica en ENSI Bourges (Benali, Idasiak, & Fontaine, 2001) cuya IHM utiliza una

serie de botones que permite seleccionar qué pierna va a moverse y cuánto desplazamiento tendrá.

También el robot móvil con representación virtual de la Universidad de Essex en Inglaterra (The

Eyebot Project, 1996) cuyo módulo de representación virtual con la ayuda de un sonar crea un

mapa en video de los posibles obstáculos que el robot puede tener y permite al usuario hacer

modificaciones de trayectorias a partir de esas imágenes. Una manera diferente de controlar un

robot es expuesta en (Talyor & Trevelyan, 1995) ya que el usuario tiene que proporcionar un

número para las diferentes coordenadas x, y, z. Por otra parte el proyecto Tele-Garden (Goldberg

& Santarromana, 1997) cuya representación gráfica en dos dimensiones le permite al usuario

seleccionar el área de una imagen en donde el robot se posicionará. Asimismo la investigación

llevada a cabo por el Dr. Manuel Macías en el ramo de teleingeniería en el ITESM campus

Monterrey donde expone el concepto Telelab (Macías, 2008) que cuenta con un brazo robótico de

tres ejes que puede ser operado manualmente como en (Galvez, Estremera, & González de

31

Santos, 2000), en modo semiautomático como en (Goldberg & Santarromana, 1997), o bien en

modo totalmente automático.

2.7.2 Medio de acceso remoto.

Existen muchas formas en las que se puede teleoperar un sistema, por radio frecuencia (Ogai,

Wada, Hirai, Abe, & Sato, 2007), conexiones físicas a larga distancia tipo maestro esclavo

(Clement, Vertut, Fournier, Espiau, & Andre, 1985), por decir algunas. Para el caso en el que el

medio por el cual el usuario envía comandos al robot y recibe la retroalimentación de éste sea a

través de internet si es por una conexión dedicada como las que usan las aplicaciones stand-alone,

en ésta debe extremar seguridad en los datos que se están enviando además de desarrollar un

método de control en el envío. Aunado a esto es necesario establecer diferentes niveles de conexión

para discernir usuarios administradores de usuarios comunes. En (De Pasquale, 1998) se muestra

un ejemplo que usa una aplicación stand-alone cuya conexión es directa para transmitir la

información de control del cliente al servidor y viceversa. Esta información debe ser

“excesivamente validada”, lo cual agrega tiempo de procesamiento preliminar al comando a

ejecutar en este tipo de sistemas. En cambio cuando se usan aplicaciones web toda esta seguridad se

lleva a cabo por el servidor web ajeno a la programación de la aplicación y así se evita el

programador tener que validar las peticiones de conexión. Aunque sistemas como los del Dr.

Manuel Macías (Telelab) (Macías, 2008) permiten tener un grado de seguridad alto al pedir la

identificación de cada usuario en un horario previamente solicitado y además combinar las

bondades de utilizar una conexión web que ya se mencionaron.

2.7.3 Computadora servidor.

La computadora servidor es la que procesa gran parte del código que tiene que ver con las

acciones programadas del robot. Esta computadora está en constante comunicación con el

controlador del robot y por sus características de servidor es muy indispensable que esté todo el

tiempo corriendo la aplicación y en conexión a internet. La conexión con el controlador del robot

provee a la computadora cliente las necesidades de retroalimentación de los sensores que interpreta

el usuario, quien puede enviar y recibir información al servidor ya sea por medio de un servidor

web o una conexión directa a la red como lo hemos estado viendo. Varios ejemplos como en

PumaPaint (De Pasquale, 1998), SILO4 (Galvez, Estremera, & González de Santos, 2000), el

32

proyecto Mercury (Goldberg & Mascha, 1994) o el laboratorio remoto Telelab (Macías, 2008) en

donde se sigue esta metodología de tener un servidor que atiende las peticiones de usuarios.

Es común encontrar en la literatura, en el caso de tener un servidor web, variaciones como

NCSA HTTP Demon (Goldberg & Mascha, 1994) o Microsoft Personal Web Server (Saucy &

Mondada, 1997), pero en sí, la inclinación por algún servidor web se define dependiendo de la

plataforma en la que se ha realizado la aplicación, de sus propósitos de investigación, seguridad

entre otras cosas relacionadas con el desempeño del servidor. Ejemplo de esto es el proyecto “The

Web Interface for Telescience (WITS)” (Paul, Gregory, Tharp, & Kam, 1997), cuyos creadores

se basaron en un servidor web robusto que pudiera manejar arriba de mil peticiones de conexión a

la vez.

2.7.4 Modo de acceso al controlador de robot.

La interface de comunicación entre el servidor y el controlador puede darse de diferentes

maneras. Algunas de estas maneras son más eficientes, rápidas, prácticas o sencillas de usar que

otras. La decisión de escoger una u otra depende de la velocidad de respuesta que la aplicación

requiera, por ejemplo no sería lo mismo la velocidad de respuesta del actuador cuando se controla

temperatura que la que se necesita para controlar un péndulo invertido. Dentro de estos modos

destacan: Wireless Local Area Networks (WLAN), IEEE 802.11 como WiFi e HiperLAN, Ethernet

y sus variantes, RS-232, etc. Algunos desarrollos de esto se pueden ver en proyectos como el

cuadrúpedo SILO4 (Galvez, Estremera, & González de Santos, 2000), el péndulo invertido

(Salzmann, Latchman, Gillet, & Crisalle, 1999) o el proyecto de los tanques acoplados

(Ramakrishnan, y otros, 2001) que utilizan una conexión RS-232, el proyecto de los robots

agentes (Huosheng, Lixiang, Pui, & Zhou) que además de controlar a los robots se manipulan

cámaras ambos controles utilizando como medio de conexión WLAN o el revolucionario sistema

del Dr. Manuel Macías (Macías, 2008) que utiliza una Simatic Station (PLC Siemens) en cuyo

gabinete reside un módulo de comunicaciones que va más allá de una simple interface Ethernet

puesto que incluye un servidor web, un servidor de correo electrónico y funciones FTP (CP 343-1

IT).

33

2.7.5 Controlador de robot.

El controlador del robot es quien tiene los algoritmos de control para llevar al cumplimiento

correcto de tareas que el robot tiene que realizar además que es el encargado de hacer la interface de

comunicación entre el servidor con el actuador en sí. El controlador recibe comandos de control de

alto nivel del servidor y los transforma en instrucciones de bajo nivel para posteriormente

mandarlas al robot, una vez que éste haya terminado la tarea, envía la retroalimentación

correspondiente al controlador y se hace el mismo proceso de manera inversa para que el usuario

interprete el estatus del robot.

Por su naturaleza, no es común encontrar en la literatura la manera en que se implementaron

estos algoritmos, si a caso se encuentra la técnica utilizada como en (Benali, Idasiak, & Fontaine,

2001) que utilizan lógica difusa para que un administrador de modos de control tome decisiones

sobre cuál sería el correcto control para desempeñar una trayectoria, en (Huosheng, Lixiang, Pui,

& Zhou) con programación en C++ se realizaron algunos algoritmos con el propósito de proveer

autonomía y enfrentar el retraso arbitrario que presenta la Internet, en (Salzmann, Latchman,

Gillet, & Crisalle, 1999) donde se programó un cotrolador/optimizador que estima los nuevos

parámetros de los paquetes que hay que enviar basándose en la referencia dada y un ancho de banda

que también estima, todo esto en la plataforma de LabView. También en (Ramakrishnan, y otros,

2001) donde se compara el desempeño de tres controladores programados por técnicas de PID,

espacio de estados y lógica difusa para mantener bajo control el proyecto de los tanques acoplados.

Asimismo el sistema del Dr. Manuel Macías en el ITESM campus Monterrey (Macías, 2008) que

utiliza una unidad de control de procesos (CPU) del tipo CPU 314C-2 DP donde se encuentra toda

la programación en lenguaje escalera para controlar al robot de tres ejes.

2.7.6 Robot.

El robot es el subsistema final dentro de esta cadena de teleoperación, en él se encuentran

todos los servomotores a controlar para lograr una tarea específica y dependiendo de esta tarea estos

robots se categorizan como por ejemplo: robots manipuladores con gripper (especie de mano con

dos dedos), brazos robóticos, móviles, submarinos, humanoides, etc. Las tareas típicas que realizan

los robots suelen ser de: ambiente militar, industrial, para la educación, la medicina,

experimentación, espacial, submarina o de riesgo. Cada robot tiene su propio controlador que como

mencionamos en los párrafos anteriores sirve para hacer la interface entre el servidor y el robot en

sí. En la literatura revisada se encontraron robots como el del concepto Telelab (Macías, 2008)

donde se encuentra un robot de 3 ejes para acomodar piezas en una superficie o el SILO4 (Benali,

34

Idasiak, & Fontaine, 2001) que tiene una orientación para la educación en dónde el estudiante

puede manipular este cuadrúpedo y experimentar la teleoperación. En (Huosheng, Lixiang, Pui, &

Zhou) se coordinan varios robots para realizar tareas complejas que uno sólo no podría llevar a

cabo con propósitos comerciales como “tele-manufactura, tele-capacitación o tele-servicio”. En

(Alencastre-Miranda, Muñoz-Gómez, & Rudomín, 2003) con fines de experimentación se

manipula un robot PUMA del tipo gripper pero en colaboración de varios usuarios a la vez en un

medio virtual.

2.7.7 Sensores de retroalimentación.

Esta parte se refiere a la manera en la que el usuario remoto se percata del estatus del robot.

Aplicaciones avanzadas proveen retroalimentación de video, sonido o del tipo háptica (fuerza de

retroalimentación). Otras aplicaciones no tan avanzadas pero no menos importantes con el

encendido o apagado de algún indicador en la IHM es suficiente para encadenar secuencias que el

robot ejecute. Cuando la aplicación utiliza el video como retroalimentación el número de cámaras

varía dependiendo de las perspectivas necesarias para completar las tareas por ejemplo en

(Tanenbaum, 2003) sólo fue necesario tener una cámara ya que el objetivo del proyecto es que el

usuario tenga una perspectiva panorámica y controle ésta a diferencia de las cámaras que se utilizan

en (Huosheng, Lixiang, Pui, & Zhou) una en cada robot agente y otra que proporciona la vista

general de ambiente. Otro caso es cuando se trata de controlar la transmisión del video como en

(Salzmann, Latchman, Gillet, & Crisalle, 1999) que de dos formas que graba la cámara, cuadro

por cuadro y en modo continuo, se ha escogido la primera por la posibilidad que presenta para que

el usuario pueda definir la compresión del video. También cuando se trata de controlar el zoom o el

panorama de la cámara como en (Ramakrishnan, y otros, 2001) que se utiliza una unidad

motorizada tipo “pan tilt” para que el usuario por medio de comandos que interpreta un controlador

especializado para la cámara pueda cambiar la orientación horizontal y vertical de ésta, método que

también se utiliza en Telelab (Macías, 2008) donde se tienen 2 cámaras de video para tener

diferentes perspectivas, cada una de ellas con control pan, tilt, zoom e iluminación para dar más

libertad al usuario y hacer la experiencia de teleoperación más real. Esto sin contar la interacción

que proporciona la interface humano máquina con sus indicadores en pantalla.

35

2.8 Indices de desempeño.

En la actualidad es necesario definir índices de desempeño para poder hablar del término

“tiempo real” que originalmente fue utilizado para describir procesos de control solamente. Hoy en

día se puede encontrar en la literatura este término describiendo sistemas que no controlan procesos

en sí pero son sumamente dependientes de información proporcionada a tiempo. Una película es un

muy buen ejemplo que depende del tiempo ya que debe tener muy buena sincronización entre los

cuadros expuestos y el sonido de los diálogos y demás. Por estas circunstancias que vinieron

presentándose con el desarrollo de nuevas tecnologías y aplicaciones el término “tiempo real” se ve

obligado a redefinirse en “control en tiempo real” donde como en cualquier sistema de control el

aspecto de una buena retroalimentación es fundamental para el desempeño del control, aunque esta

retroalimentación puede tener varios niveles como por ejemplo el nivel de la aplicación donde la

retroalimentación se puede observar entre las acciones que toma el usuario y los resultados que éste

observa en el sistema (Salzmann, Latchman, Gillet, & Crisalle, 1999).

Una buena experimentación de teleoperación debe satisfacer una serie de requerimientos.

Particularmente el usuario debe sentir como si estuviera frente al sistema ya que en

experimentaciones locales éste puede utilizar su sentido de la vista u oído para percibir los efectos

de las acciones que toma en el sistema de control. Cuando hablamos de teleoperación esta

percepción debe cubrirse proporcionando retroalimentación de este tipo. Obviamente esta

retroalimentación necesita tener un tiempo mínimo razonable para ser presentada, lo cual hace esta

parte la más difícil del sistema teleoperado cuando el medio de transmisión remota es Internet ya

que es inaceptable para un usuario remoto tener retroalimentación de sus acciones 30 segundos

después que las haya tomado.

Investigadores del Instituto Federal Suizo de Tecnología (Salzmann, Latchman, Gillet, &

Crisalle, 1999) han demostrado que la aceptación del usuario hacia una experiencia de

teleoperación es buena cuando la retroalimentación de ésta tiene retardos de 1 a 2 segundos, cuando

estos retardos sobrepasan los cinco segundos el usuario necesita adaptarse al retraso de la

información del sistema y su interacción decrece considerablemente. Cuando este retraso es mayor

a diez segundos el usuario toma acciones de reenviar el comando lo cual pone al sistema en un

estado indeseable.

Este tipo de observaciones han sido tomadas bajo mediciones de RTT (round-trip delay time),

tiempo que tarda un paquete enviado desde un emisor en volver a este mismo emisor habiendo

pasado por el receptor de destino, y también la medición de la pérdida de paquetes que por supuesto

36

está directamente relacionada con la distancia a la que se encuentra el usuario remoto y el tráfico

que presenta la red por la cual pasan los paquetes. A estos dos datos se le llamará índices de

desempeño en este documento (RTT y % de pérdidas). En la siguiente tabla se muestran algunos

registros de sistemas teleoperados a diferentes distancias que como podemos observar aunque no se

tiene el dato de la conexión que se utilizó y el número de paquetes que se enviaron nos podemos dar

una idea de que entre más larga sea la distancia el número de paquetes perdidos aumenta así como

también el retraso promedio (RTT) pero puede darse el caso de una red muy congestionada donde

esto se contradiga, como por ejemplo en el penúltimo dato que se tienen retrasos inaceptables y

pérdidas de datos muy altas.

Tabla 2.3. Registro de RTT y pérdida de paquetes según la distancia del cliente (Benali, Idasiak,

& Fontaine, 2001), (Oboe & Fiorini, 1997).

En la Tabla 2.4 se muestran los diferentes artículos tratados y la forma en que se relacionan

entre sí a manera de resumen. Se puede observar que en su mayoría están enfocados con propósitos

de investigación y estos investigadores se inclinan por experimentar con brazos robóticos. El medio

de teleoperación se basa en TCP/IP y solamente uno se atrevió a experimentar con la combinación

del protocolo UDP, no orientado a conexiones.

Usuario remoto [Km] Retraso promedio [ms] % de pérdidas

0.05 0.998 0.00

30 8.10 0.08

150 17.2 0.80

200 144.43 2.827

1000 420.73 7.357

10000 156.24-326.3 0.37-41.4

37

Tabla 2.4 Condensado de artículos referenciados.

Referencia

Robot tipo Propósito Medio QoS Medición Protocolo

Mó

vil

Brazo

Otro

Edu

cación

Ind

ustria

Investigació

n

Otro

Intern

et

Intern

et2

% P

érdid

a

RTT

TCP

UD

P

(Benali, Idasiak, & Fontaine, 2001)

X X X X X X X X

(The Eyebot Project, 1996) X X X X

(Talyor & Trevelyan, 1995) X X X X

(Goldberg & Santarromana, About the Tele-Garden, 1997)

X X X

(De Pasquale, 1998) X X X X

(Huosheng, Lixiang, Pui, & Zhou) X X X X X X X

(Salzmann, Latchman, Gillet, & Crisalle, 1999)

X X X X X X X

(Ramakrishnan, y otros, 2001) X X X X

(Ko, y otros, 2001) X X X X X X

(Alencastre-Miranda, Muñoz-Gómez, & Rudomín, 2003)

X X X X X X

(Oboe & Fiorini, 1997) X X X X X

(García, 2010) X X X X X X X X X

38

3 Metodología.

En esta sección se expone la metodología que se sigue para evaluar QoS, Internet e Internet2

bajo una aplicación de teleoperación tipo stand-alone.

3.1 Metodología para evaluar el desempeño de una celda didáctica

flexible de manufactura con QoS, en Internet e Internet2 con una

aplicación teleoperada tipo stand-alone.

Este proyecto va enfocado a desarrollar una aplicación robusta, modular, escalable y con la

flexibilidad de adaptar tecnologías de diferente fabricante que permita compartir este recurso a

universidades que no tendrían la posibilidad de adquirirlo. En esta tesis se evalúa el desempeño de

una celda de manufactura teleoperada con QoS (reservación de ancho de banda), Internet e

Internet2.

El esquema de evaluación a seguir en esta investigación empieza con el estudio de los sistemas

recientes de teleoperación (estado del arte), en donde de acuerdo con la bibliografía consultada se

pudo obtener un patrón para categorizar los sistemas teleoperados, posteriormente fue necesario

definir esta metodología que consecuentemente traerá el desarrollo de una interface con capacidades

de conexión directa para ser teleoperada por Internet o Internet2. Inmediatamente después habrá que

someter esta plataforma a las pruebas comunes encontradas en el estado del arte y encontrar por

medio de un análisis debido de los datos de transmisión las ventajas de utilizar esta aplicación y al

final concluir esta investigación. Lo anteriormente escrito se puede interpretar de mejor manera de

acuerdo con la Figura 3.1. Esquema de metodología para evaluar el desempeño de una aplicación

teleoperada con QoS, Internet e Internet2

39

Figura 3.1. Esquema de metodología para evaluar el desempeño de una aplicación

teleoperada con QoS, Internet e Internet2.

3.2 Componentes del sistema de teleoperación. De acuerdo con la investigación recaudada, se ha encontrado que para la correcta funcionalidad

de un sistema teleoperado se debe contar con características bien definidas y expuestas en la sección

2.5.1 las cuales se ven modificadas en esta propuesta y se presenta la solución que resume la Figura

2.9. Esta propuesta de desarrollo se aplicará al Laboratorio de Automatización de Sistemas de

Manufactura (LASM) donde radican estos instrumentos en su mayoría.

Figura 3.2. Componentes del sistema de teleoperación de LASM.

Revisión bibliográfica y estado del arte.

Definición de metodología a utilizar.

Pruebas de teleoperación del sistema.

Análisis de pruebas.

Conclusión de investigación.

40

Esta propuesta expone cumplir con los subsistemas anteriores, para esto:

Se desarrollará una IHM programada en LabVIEW (lenguaje G) ya que es un

revolucionario sistema de programación gráfica para aplicaciones que involucren

adquisición, control, análisis y presentación de datos. Las ventajas de utilizar LabVIEW son

que: reduce el tiempo de desarrollo de las aplicaciones al menos de 4 a 10 veces, por

intuitivo y fácil de aprender ya que toda la programación es por bloques e iconos, es

flexible, permitiendo cambios y actualizaciones tanto del hardware como del software. Con

una sola plataforma se integra la adquisición, análisis y desarrollo de IHM’s. LabVIEW

tiene la posibilidad de incorporar aplicaciones escritas en otros lenguajes de tipo texto

además que es mucho más fácil controlar el procesamiento de la aplicación en la

computadora que lo está ejecutando. Esta interface tendrá que ser una del tipo stand-alone

ya que es necesario que el sonido se reproduzca en la computadora cliente de acuerdo al

hardware con el que cuenta ésta.

Se tendrá un medio de acceso remoto de conexión directa con la posibilidad de conectarse a

Internet e Internet2 el cual sólo se podrá obtener mediante una computadora puente que

tenga posibilidades de funcionar como servidor para que clientes ajenos a la LAN del

campus puedan acceder a la computadora servidor que albergará la aplicación en la celda.

Se contará con una computadora servidor que mantendrá corriendo la aplicación que

contendrá la programación de control en horas adecuadas.

Se hará uso de una LAN que contiene la celda que permitirá tener acceso al controlador del

robot por medio de Ethernet.

Se utilizará el controlador XRC 2001 adjunto al brazo robótico al cual se le enviarán

comandos de control por medio de funciones que Motoman Inc. ha puesto a disposición de

los usuarios que necesiten manipular sus brazos robóticos por medio de computadoras

personales.

Se usará un robot Motoman UP6 (brazo robótico de seis grados de libertad) para analizar

este sistema de teleoperación.

Se colocarán cámaras tipo webcam en puntos estratégicos de la celda de manufactura para

proveer de retroalimentación visual al usuario remoto del sistema además de un micrófono

que le proporcione otro sentido más de retroalimentación al cliente sobre el sistema.

41

3.3 Pruebas de transmisión de datos. Las pruebas a las que se someterá este sistema son:

Movimiento del primer grado de libertad en positivo y negativo a diferentes

velocidades y grados.

Activar y desactivar herramienta.

Cambio de herramienta.

Abrir y cerrar prensa.

Cambio de cámara.

Ejecución de home.

Cambio de cámara.

Cambio de resolución a 100%

α

desactivar sonido

α

Bajar resolución a 10%

α

Activar sonido.

Desactivar video.

α

Desactivar sonido

α

Estas pruebas se harán de diferentes partes del país a través de Internet e Internet2. Esto

proporcionará una variabilidad de bytes confiable para hacer un buen análisis del desempeño del

sistema.

3.4 Análisis de transmisión de datos. Como se ha visto en (Benali, Idasiak, & Fontaine, 2001), (Salzmann, Latchman, Gillet, &

Crisalle, 1999), (Huosheng, Lixiang, Pui, & Zhou), (Alencastre-Miranda, Muñoz-Gómez, &

Rudomín, 2003), (Oboe & Fiorini, 1997) a un sistema de teleoperación comúnmente se le aplican

pruebas en donde se envían comandos que realizarán alguna tarea en específico en el sistema para

analizar pérdidas de datos y RTT, las cuales se convierten en buenos indicadores de desempeño de

estos sistemas. Por lo tanto al realizar las pruebas anteriormente mencionadas se registrarán los

datos enviados y recibidos por las computadoras cliente y servidor para analizar debidamente las

α

42

pérdidas y retardos que ocasiona las múltiples configuraciones que podrá desempeñar esta

aplicación. Estos datos se registrarán con ayuda de una aplicación rastreador que permita guardar el

tráfico de los puertos utilizados. Con este análisis se pretende detectar variables de control que tiene

el sistema, las áreas de oportunidad que se tiene para mejorar el desempeño del sistema entre otros

fenómenos que el comportamiento arbitrario de la red pueda mostrar.

43

4 Implementación. En los párrafos siguientes se hará una descripción de la implementación del sistema que se

manejó para evaluar su desempeño en teleoperación, sus componentes físicos, el medio en el que

opera, las áreas de oportunidad que tiene para mejorar la comunicación, los programas que se

desarrollaron, las herramientas utilizadas para el análisis del tráfico de los datos, de manera

detallada.

4.1 Descripción de la Celda Flexible de Manufactura. En esta faceta del proyecto se ha desarrollado una plataforma de buen rendimiento que permite

manipular, de manera básica, los subsistemas de la Celda Didáctica Flexible de Manufactura

(CFM), los cuales son: fresadora EMCO (A), brazo robótico motoman UP6 (B), mesa de ensamble

(C), banda transportadora (D), almacén automático (E), estación de control (F) y sistema de visión

(G), ubicada en el Laboratorio de Automatización de Sistemas de Manufactura (LASM) en el

ITESM Campus Monterrey. La interface fue comenzada por (Gamboa, 2008) cuyo trabajo se

continuó para optimizar la programación y darle un giro hacia su verdadera finalidad de

teleoperación además de añadir el módulo de control del brazo robótico y audio. De acuerdo con la

propuesta vista en la Figura 3.2 se describirán los subsistemas de esta aplicación que se muestran

en la Figura 4.1.

Figura 4.1. Subsistemas de la CFM del LASM.

44

4.1.1 Interfaces humano máquina del sistema. Para la realización de este proyecto se desarrollaron dos interfaces, una que estuviera

ejecutando todo el algoritmo de control junto a la CFM y otra por la cual el usuario remoto manda

comandos a través de Internet. Estas interfaces tienen módulos de audio y video en su programación

que representan la retroalimentación más importante del sistema. El servidor adquiere el video por

medio de cámaras conectadas a sus puertos usb, descompone esta información en sus componentes

de colores primarios y la envía a la computadora cliente, el número de cámaras que se puede tener

se fija por el número de puertos USB que la computadora servidor tenga, en este momento el

sistema tiene cinco cámaras, una detrás de la máquina CNC para captar la vista general de la celda,

otra a un lado de la mesa de ensamble para dar perspectiva en el plano Z cuando se utiliza el robot,

otra más en la punta de la herramienta del robot para la perspectiva XY, una que capta la visión del

almacén automático y otra más que capta el transporte de pallets por la banda. De manera similar un

micrófono acoplado a la cámara que se encuentra en la punta de la herramienta capta el sonido que

se produce en la CFM y lo envía al cliente. En la programación de la IHM cliente se encuentran los

programas que de manera inversa leen la información que envía el servidor y la reproducen. El

cliente no puede enviar video ni sonido, sólo reproduce lo captado en la CFM. En la Figura 4.2 se

pueden apreciar estas IHM’s y sus funciones.

Figura 4.2. IHM’s servidor y cliente.

4.1.2 Medio de acceso remoto y computadora puente. Como hemos estado mencionando este proyecto evalúa el desempeño de esta interface en

particular en medios como Internet e Internet2. La plataforma se desarrolló como una del tipo stand-

alone que tiene módulos independientes para conectarse a internet por medio de sockets (conjunto

45

de dirección IP, protocolo y número de puerto para intercambiar datos) el protocolo utilizado fue

TCP y los puertos manejados fueron 1001 para transmitir video, 1002 para comandos de control y

1003 para audio. En la el cual sólo se podrá obtener mediante una computadora puente que tenga

posibilidades de funcionar como servidor para que clientes ajenos a la LAN del campus puedan

acceder a la computadora servidor que albergará la aplicación en la celda.

Se contará con una computadora servidor que mantendrá corriendo la aplicación que contendrá

la programación de control en horas adecuadas. En la Figura 4.3 se muestran estos sockets para

tener una idea general de la metodología de comunicación que se utilizó.

Figura 4.3. Sockets para el intercambio de datos con la computadora servidor.

El usuario no tendría acceso a esta programación, él sólo obtiene un archivo ejecutable que le

permite ver la interface solamente, sin saber qué hay detrás de ella. Por lo tanto para él el uso de

puertos e IP (Internet Protocol) es transparente. Con respecto a la comunicación, el proceso de

conexión que sigue la computadora cliente es de cargar la aplicación, después enviar un

requerimiento de conexión, intercambiar datos y cerrar la aplicación, que acaba adecuadamente con

la conexión. Del otro lado el servidor está esperando un requerimiento de conexión, al aceptar pasa

al intercambio de datos y después a cerrar el socket. La Figura 4.4 muestra de mejor manera lo

anterior mencionado.

46

Figura 4.4. Interacción Cliente-Servidor bajo el protocolo TCP.

Durante el desarrollo de este proyecto se presentaron algunos problemas de logística y la

transferencia de los datos hacia el exterior de la LAN del campus sólo fue posible a través de una

computadora ubicada en el cuarto piso del edificio LD (computadora puente). Obviamente esto

genera un problema de retardo en la comunicación de esta aplicación puesto que primero tiene que

resolver el direccionamiento de los datos hacia esta computadora, después resolver el

direccionamiento hacia el servidor externo de la institución y por último enfrentarse a los retrasos

arbitrarios que presenta Internet (WAN) o Internet2. Estos problemas pueden ser solucionados muy

fácilmente con la cooperación del departamento de informática del instituto, si llegara a colocarse

un nodo externo en el LASM.

Es posible notar el impacto de la LAN cuando se trata de comunicar con la computadora

puente haciendo un tracert en la ventana de comandos de Windows. De esta forma se puede saber la

ruta que toman los paquetes antes de llegar a la computadora destino también podemos notar el

tiempo que le lleva entregar los paquetes del servidor a la computadora puente, ver Figura 4.5.

47

Figura 4.5. Traza de servidor hacia computadora puente.

Para tener el mínimo de retardos posible en el puente que se tuvo que realizar, los datos no

son procesados en ninguna otra operación que no sea leerlos de un puerto y escribirlos en otro. Las

acciones que lleva a cabo la computadora puente sólo tienen que ver con escuchar si algún cliente

necesita utilizar la aplicación si es así, ésta manda una petición de conexión al servidor y cuando

éste responde se hace el intercambio de información entre cliente-servidor a través de este puente.

En la Figura 4.6 se muestra la programación que se hizo en la computadora puente.

Figura 4.6. Lectura y escritura en computadora puente.

48

Como se ha dicho hasta ahora este proyecto se evalúa en internet2 por lo tanto debe

mencionarse que el funcionamiento de esta red en comparación con Internet es muy similar, tan

similar que pueden compartir los mismos medios de comunicación como fibras, ruteadores,

etcétera. Como se ha mencionado lo que las distingue es el enfoque que tiene esta nueva red con la

Internet que más que nada es de uso comercial, informativo o de entretenimiento en cambio la

Internet2 tiene fines educativos, de colaboración científica y de investigación. Existe un enlace a

Internet2 por medio de una red central que se encuentra físicamente en las instalaciones de

TELMEX en Monterrey a la cual el ITESM tiene acceso. Al momento de enviar información fuera

del campus el ruteador decide, dependiendo de a dónde va dirigida la información, si traza la ruta

por Internet o Interent2. Por ejemplo si se quiere tener acceso a una página web de alguna de las

instituciones con acceso a Internet2 el ruteador dirige el tráfico por el enlace de TELMEX. Si esta

institución no estuviera afiliada a Internet2 lo haría por un enlace que se tiene a través de Alestra (el

Internet comercial).

4.1.3 Computadora servidor. La computadora que se utilizó, la cual tiene la programación del control del robot y espera la

petición de conexión del cliente utiliza Windows XP Professional 2002, SP 3, con un procesador

Intel Core Duo de 2.33 GHz y 1.95 GB de memoria RAM. Esta computadora tenía ya elaborada

alguna programación que lee las variables de los PLC’s de acuerdo con (Gamboa, 2008). Existen

tres PLC’s de Allen Bradley que concentran la información recopilada de la banda transportadora,

almacén automático y mesa de ensamble, éstos junto con los otros subsistemas de la CFM

conforman una pequeña LAN que veremos en la sección 4.1.4.

Se pretende que esta computadora esté corriendo la aplicación de teleoperación después de que

el LASM fue utilizado por los alumnos de mecatrónica en sus cursos presenciales para que otras

personas de otras universidades puedan acceder a esta aplicación y realizar las prácticas al igual que

un alumno presencial.

4.1.4 Método de acceso a controlador de robot. Como se mencionó en la sección 2.7.4 la interface de comunicación entre el servidor y el

controlador puede darse de diferentes maneras. En el caso de este controlador, permite la

comunicación externa con RS-232 y Ethernet. Puesto que la comunicación en Ethernet resulta más

49

directa y la velocidad es más rápida fue muy conveniente tomar esta vía de comunicación entre el

controlador y el servidor.

Los subsistemas de la CFM comparten información entre sí por medio de una LAN soportada

por un switch, ver Figura 4.7. El controlador tiene una interface del tipo MAU (Medium

Attachment Unit), a la cual se le conecta un transceiver (transmisor-receptor) que hace el

acoplamiento por su conector AUI (Attachment Unit Interface), a Ethernet, ver Figura 4.8. Este

dispositivo tiene características de 10BASE-T, ver Tabla 2.3, que promete no tener más de 5 ns de

jitter y si no se sobrepasa la longitud máxima los retrasos se aseguran por debajo de 1000 ns.

Figura 4.7. Red Ethernet soportada por Switch.

Figura 4.8. Interface AUI (izquierda) y Ethernet del transceiver.

http://en.wikipedia.org/wiki/Medium_Attachment_Unit

http://en.wikipedia.org/wiki/Medium_Attachment_Unit

50

Del lado del servidor se tiene una tarjeta de red INTEL(R) PRO/100 VE Network Connection,

cuyas características interesantes son que maneja Ethernet 10Base-T y Ethernet 100Base-TX, ver

Tabla 2.3, y que tiene una capacidad máxima de transferencia de datos de 100 Mbps lo cual es

suficiente para esta aplicación (Cabletron Systems, 1992).

4.1.5 Controlador XRC 2001. El controlador del robot utilizado fue un XRC 2001, cuya programación se lleva a través de un

teach pendant (IHM para enseñar puntos al robot entre otras actividades que se realizan con el

brazo robótico). Este controlador tiene una memoria de programación que puede manejar 5000

puntos y 3000 instrucciones y su lenguaje de programación que maneja es INFORM II que por su

parecido con Windows hace la programación del robot más amigable. Este controlador tiene la

capacidad de manejar hasta cuatro brazos robóticos y poder sincronizarlos para realizar tareas. En

(O'Neillall, 2002) se puede encontrar más información acerca de este controlador.

Para poder controlar el brazo robótico fue necesario cumplir con las especificaciones básicas

que la sección 1-14 de (Inc., 2002) expone. Motoman Inc. puso a disposición de los usuarios de

controladores YASKAWA una lista de funciones que pueden ser manipuladas en plataformas de

programación como Visual Basic o Visual C ++. Entonces fue así como se desarrolló la aplicación

de teleoperación, mandando comandos a través de funciones programadas en C ++. LabView da la

opción a sus usuarios de realizar desarrollo de software en programación tipo texto por unos

bloques llamados Call Library Funtion Node que llaman archivos .dll.

4.1.6 Robot Motoman UP6. El objetivo final en este sistema de teleoperación es realizar un ensamble de una pieza

utilizando el brazo robótico. Este robot es un UP6 MOTOMAN de seis grados de libertad que

contiene encoders absolutos, los cuales constituyen la planta a controlar por el XRC 2001, quien

logra una exactitud de ± 0.08 mm, tiene un peso de 130 Kg, puede cargar objetos de 6 Kg contando

su herramienta y logra una velocidad máxima de 1.5 m/s, en (URBAN, 1999) se encuentran

especificaciones más técnicas sobre este brazo. El robot utiliza en su mesa de trabajo (mesa de

ensamble) tres herramientas para llevar a cabo esta tarea de ensamble: gripper (pinzas), ventosa y

desarmador, las cuales se activan con energía neumática.

51

4.1.7 Retroalimentación sensorial, audio y video. La retroalimentación se lleva a cabo a través de cámaras de video para web (webcams), es

indispensable que estas cámaras sean de interface USB ya que son procesadas por programación

que el recurso será conectado en ese bus. La imagen es comprimida con el algoritmo de compresión

JPEG, que es el algoritmo más famoso para imágenes que serán enviadas por web ya que permite

modificar el grado de calidad de la imagen fácilmente. No obstante cabe mencionar que el

algoritmo mismo, aun así se haya seleccionado una calidad del 100%, produce pérdidas en la

calidad de la imagen.

Las cámaras que se utilizaron son de la marca Logitech, una Quickcam Chat, for notebooks,

Orbit AF, communicate delux y una express, localizadas como anteriormente se mencionó. Además

de retroalimentación visual se utilizó un micrófono adjunto a la cámara Quickcam for notebooks

para enviar los sonidos producidos en la celda. Este micrófono cuenta con tecnología RightSound

que elimina el eco en la transmisión. Otra retroalimentación visual utilizada es el cambio de estado

de los indicadores y botones en la IHM.

5 Marco experimental En este capítulo se describen las pruebas realizadas con QoS, en Internet e Internet2. Se

detallará cada prueba, la ubicación del cliente, sus pérdidas de paquetes tanto para video, datos y

sonido así como también sus retardos promedio en estas tres conexiones.

5.1 Pruebas con calidad de servicio (QoS). Se realizaron dos pruebas con calidad de servicio (QoS) en San Carlos, Costa Rica. Las

pruebas consistieron en reservar el ancho de banda en 2MB y 38 KB como lo muestra la Figura

5.1. La intención de estas pruebas fue registrar la diferencia que presenta la pérdida de paquetes y el

retardo (RTT) cuando el sistema tiene un ancho de banda muy superior a lo que necesita para operar

(el sistema necesita alrededor de 30 KB para su buen funcionamiento) que fue el caso de la prueba a

2MB y la otra con el suficiente ancho de banda para operar que fue la de 38 KB.

52

Figura 5.1. Reservación de ancho de banda.

5.1.1 Prueba a T 2.

Esta prueba se efectuó el 14 de noviembre de 2008 a las 16:53 horas con un ancho de banda

fijo en 2 MB. Para corroborar la ubicación del cliente se le pidió que en la ventana de comandos de

Windows tecleara el “tracert” que nos permite ver por dónde pasan los paquetes antes de llegar al

destino. En la Figura 5.2 se muestra la traza del cliente en San Carlos, Costa Rica.

Figura 5.2. Traza de cliente en San Carlos, Costa Rica.

53

Como se puede observar en la anterior figura la traza no llega a su destino por el firewall de

Alestra cuya dirección IP es 200.94.151.126, esto nos da la certeza de que los datos fueron

entregados a través de la Internet. Este cliente se encuentra a una distancia aproximada de

2530.21Km, cabe mencionar que la distancia punto a punto no es la que en realidad toman los

paquetes. La duración de esta prueba fue de 16:35 minutos.

El siguiente tratamiento de los datos se llevó a cabo con el apoyo de JUMP 5.0, software

estadístico que permite la manipulación de gran cantidad de datos. A continuación se muestra una

gráfica de Pareto que nos proporciona una mejor interpretación del tamaño de los paquetes que se

enviaron tanto del servidor como del cliente seguida de los estadísticos principales para interpretar

el retraso de video, datos y audio.

Figura 5.3. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio

en servidor.

La Figura 5.3 muestra que los paquetes tuvieron una variabilidad de tamaño entre 4 y 1460

siendo la mayoría de estos los de tamaño 504 bytes ya que alrededor de 3000 paquetes se enviaron

con este tamaño, esto constituye un 70% de los paquetes que se enviaron de audio. En la imagen de

la derecha se puede ver claramente que el valor promedio que tomó el retraso de los paquetes fue de

43.4625 ms en el intercambio de información que se llevó a cabo entre el servidor y el puente.

En la Figura 5.4 se muestra que hubo más variabilidad en los paquetes aunque un 30% de

ellos se mantuvo en 1380 bytes mientras que el valor promedio del retardo fue de 105.5057 ms.

54

Figura 5.4 Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio

en cliente.

En cuanto a los comandos enviados para manipular el robot los cuales están referenciados

como datos tuvieron el siguiente comportamiento como se muestra en la Figura 5.5.

Figura 5.5. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para datos

en servidor.

Se logra apreciar que los datos oscilaban en cinco categorías siendo 4 bytes el 50% del tamaño

de los paquetes enviados. También podemos ver en la imagen de la derecha que hubo un retraso

promedio de 52.4099 ms en toda la conexión de datos. Mientras que en el cliente el 70% de los

paquetes tuvo un tamaño de 1380 bytes y se tuvo un RTT de 44.87 ms como se puede ver en la

Figura 5.6.

Figura 5.6. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para

datos en cliente.

55

Por otra parte en video se tuvo tanta variabilidad en los paquetes que no resultó factible

presentarlos en una gráfica de Pareto aunque más del 75% de los paquetes hayan tenido un tamaño

de 1460 bytes con un retraso promedio de 49.4241 ms como lo muestra la Figura 5.7. Al igual en el

cliente se observó tanta variabilidad en el tamaño de los paquetes que no fue factible presentar los

datos en una gráfica de Pareto aunque el 50% de ellos se encontraba con un tamaño de 1380 bytes

además de tener un RTT promedio de 44.6477 ms como se observa en la Figura 5.8.

Figura 5.7 Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en servidor.


cliente.

56

5.1.2 Prueba a T 38. Esta prueba se llevó a cabo con el mismo cliente en San Carlos, Costa Rica y en la misma

computadora con la diferencia de limitar el ancho de banda dedicado a la aplicación a 38 KB el 14

de noviembre de 2008 a las 17:18 horas y tuvo una duración de 12:10 minutos. Lo cual arrojó los

siguientes resultados en la prueba:

Figura 5.9. Tamaño de paquetes (izquierda) y estadísticos principales de RTT para audio en servidor 38KB.

Los paquetes tienen poca variabilidad en esta prueba además de que el 75% de ellos se

encuentran con un tamaño fijo de 504 bytes. El retardo del servidor al puente en promedio fue de

43.726 ms como lo muestra la Figura 5.9. En cuanto al cliente se observó que hubo más

variabilidad de tamaños de paquetes y el doble de retardo del puente al cliente que en promedio

alcanzó la cifra de 83.5891 ms.


audio en cliente a 38 KB.

57

Mientras que en la conexión de datos se mostró casi una igualdad en cuanto al porcentaje

del tamaño de los paquetes entre 4 y 1395 bytes que ocuparon casi el 100% de los paquetes

enviados entre el servidor y el puente con un RTT promedio de 52.0979 ms como se puede ver en la

Figura 5.11. También en la Figura 5.12 se puede ver el comportamiento que tuvieron los datos

entre el cliente y el puente.

Figura 5.11.Tamaño de paquetes (izquierda) y estadísticos principales de RTT para

datos en servidor a 38 KB.

Figura 5.12.Tamaño de paquetes (izquierda) y estadísticos principales de RTT

para datos en cliente a 38 KB.

Ahora bien el video se comportó como en la Figura 5.13 se muestra muy contrastante a lo que

muestra la Figura 5.14 donde de tanta variabilidad que tuvieron los paquetes se tuvo que obtener

sus estadísticos principales en vez de la gráfica de Pareto.

58

Figura 5.13.Tamaño de paquetes (izquierda) y estadísticos principales de RTT

para video en servidor a 38 KB.


a 38 KB.

5.2 Pruebas en Internet Las siguientes pruebas se aplicaron sin ningún privilegio en la Internet comercial, las

conexiones se realizaron a través de Internet inalámbrico (en su mayoría) y Ethernet en diferentes

partes del país, en otros países y en otros continentes para encontrar en qué medida interviene la

variación de la distancia con algún indicador que se está analizando (RTT y porcentaje de pérdidas

de paquetes). Los resultados que se encontraron son expuestos como en la sección anterior.

59

5.2.1 Pruebas locales Se aplicaron dos pruebas locales para verificar cuál es el desempeño si el servidor no

tuviera que pasar por un puente, las pruebas involucraron cambiar los puertos del cliente para que se

conectara directamente al servidor. Estas pruebas se hicieron sobre Ethernet y a una distancia

aproximada de 20 metros en un nodo en el mismo LASM.

5.2.1.1 Prueba local 1.

Esta prueba se efectuó el 20 de noviembre de 2008 a las 10:24 horas bajo las circunstancias

que se mencionaron en el párrafo anterior y tuvo una duración de 6:06 minutos. Estos fueron los

resultados obtenidos.

En la conexión de audio, servidor puente, se notó que no hubo variabilidad en el tamaño de

los datos, no más allá de 4 rangos, siendo el más grande, con un 75%, el de tamaño 1008 bytes. El

retardo en esta conexión alcanzó un promedio de 66.55 ms como se muestra en la Figura 5.15.

Figura 5.15. Tamaño de paquetes (izquierda) y estadísticos principales de RTT

para audio en servidor localmente.

En cuanto a la conexión de audio pero cliente puente se vieron más paquetes de 52 bytes

con la misma variabilidad y un RTT promedio de 37.7662ms.

60


para audio en cliente localmente.

En la información que se observó en los datos se pudo ver que hubo más variabilidad que

en audio pero los paquetes que predominaron más fueron los pequeños de 4 bytes en la conexión

servidor puente y se tuvo un retraso por el orden del que se tuvo en audio, 58.8233 ms, como se ve

en la Figura 5.17.


datos en servidor localmente.

En la Figura 5.18 se muestran los resultados que se obtuvieron pero en la conexión cliente

puente.

61


en cliente localmente.

En lo que al video se refiere se tuvo tanta variabilidad en el tamaño de los paquetes que fue

necesario exponer los datos en sus estadísticos principales aunque el 90% de los paquetes tuviera un

tamaño de 1490 bytes. Se puede observar que se tuvo un RTT bajo en comparación con los datos y

audio ya que el promedio fue de 5.3155 ms como se muestra en la Figura 5.19.


servidor localmente.

En la conexión cliente puente se notó similitud en la variabilidad de los tamaños de

paquetes también ubicando con un 90% a paquetes de tamaño 1460 bytes y un RTT promedio aun

62

menor, 1.4801 ms, lo cual es muy bajo en comparación con lo que hemos estado viendo en estos

resultados. Ver Figura 5.20.


localmente.

5.2.1.2 Prueba local 2.

Esta prueba se efectuó bajo las mismas circunstancias que la local 1 sólo que a las 16:40

horas del 20 de noviembre de 2008 y tuvo una duración de 9:45 minutos. Los resultados que se

observaron en audio se notan en la Figura 5.21 donde se puede observar muy bien que no existe

mucha variabilidad en los paquetes y en su mayoría están en 1008 bytes con un retraso promedio de

65.1053 ms en la conexión servidor puente. Mientras que en la Figura 5.22 se nota igualmente que

en la prueba anterior, una concentración de paquetes pequeños a 52 bytes y un RTT muy similar

que se fija en un promedio de 38.6215 ms.

63


audio en servidor, 2ª prueba local.


datos en cliente, 2ª prueba local.

Los datos sí se comportaron un poco distintos ya que hubo más variabilidad en cuanto al

tamaño de los paquetes con respecto a la prueba local 1 pero entre el servidor y el cliente en esta

misma prueba, local 2, fueron muy similares en cuanto a variabilidad pero se está notando lo mismo

que se ha notado casi en todos estos registros, el servidor presenta en su mayoría un alto porcentaje

de paquetes pequeños como se muestra en las Figura 5.23 y Figura 5.24.


para datos en servidor, 2ª prueba local.

64


datos en cliente, 2ª prueba local.

La conexión de video se comportó muy similar a la prueba local 1 ya que en los dos casos

servidor puente y puente cliente se tuvieron tamaños de paquetes en 1460 bytes den su mayoría y

RTT por debajo de 10 ms lo cual es un buen indicador de que esta conexión tenía condiciones que

ofrecían al usuario comodidad. Ver Figura 5.25 y Figura 5.26.

Figura 5.25. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video en servidor,

2ª prueba local.

65

Figura 5.26. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para video

en cliente, 2ª prueba local.

5.2.2 Pruebas LAN. Las siguientes pruebas fueron efectuadas dentro del campus a 50 y 20 metros de distancia

con una conexión Ethernet con la intención de comparar qué es lo que sucede cuando las

conexiones de audio, datos y video tienen que pasar por la computadora puente y su destino sea lo

más cerca posible.

5.2.2.1 Prueba LAN 1.

Esta prueba se realizó a 50 metros de distancia, en una oficina en el mismo piso que se

encuentra el LASM, tuvo una duración de 13:20 minutos y se efectuó el 19 de noviembre de 2008 a

las 00:30 horas. El comportamiento de la conexión de audio se comportó como comúnmente se ha

visto, sin tanta variabilidad y con una concentración de los datos en un tamaño de 504 bytes, lo cual

es el 75% de éstos. En cuanto a su RTT promedio se puede observar en la Figura 5.27 que fue de

41.5398 ms. Por otra parte el tamaño de los paquetes en el cliente sí tuvo la variabilidad que en el

servidor no y los paquetes de tamaño 504 no fueron los principales en porcentaje, aunado a esto se

tuvo un RTT de 39.6836 ms. Ver Figura 5.28.

66


en servidor, prueba LAN 1.


audio en cliente, prueba LAN 1.

En la conexión de datos se puede ver una gran diferencia en las gráficas de Pareto ya que los

tamaños no coinciden en lo más mínimo y el RTT promedio del servidor supera por 3 veces al del

cliente. Ver Figura 5.29 y Figura 5.30.


datos en servidor, prueba LAN 1.

67


datos en cliente, prueba LAN 1.

Por otra parte la variabilidad sí se dejó notar en la conexión de video como lo se ha visto hasta

el momento y los tiempos de retardo también son comunes en esta conexión. Ver Figura 5.31 y

Figura 5.32.

Figura 5.31. Estadísticos principales de tamaño de paquetes (arriba) de RTT para

datos en servidor, prueba LAN 1.

68

Figura 5.32. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para

video en cliente, prueba LAN 1.

5.2.2.2 Pruebas LAN 2.

Esta prueba fue aplicada a 20 metros de distancia en un nodo dentro del LASM el 19 de

noviembre de 2008 a las 17:27 horas y tuvo una duración de 8:30 minutos. La intención de esta

prueba es promediar con la prueba anterior a diferentes horas y así tener un argumento más sólido a

lo que se propuso al inicio de las pruebas LAN.

Podemos ver que la conexión de audio tiene la misma variabilidad en paquetes que en la

prueba LAN 1, sólo que esta vez fue la mitad en cantidad, lo cual es muy lógico puesto que una

prueba dura casi el doble de tiempo que la otra, pero lo que representa un dato interesante es que el

RTT se mantuvo alrededor del anterior en la conexión servidor puente, 42.449 ms. Ver Figura 5.33.


para audio en servidor, prueba LAN 2.

69

Al igual que la prueba anterior se conserva la variabilidad en la conexión cliente puente y

también el RTT promedio, ver Figura 5.34.

Figura 5.34. Tamaño de paquetes (izquierda) y estadísticos principales de

RTT para audio en servidor, prueba LAN 2.

Los datos al menos en la conexión servidor puente tiene un comportamiento similar, pero en la

conexión cliente puente varían un poco a la anterior prueba. Ver Figura 5.35 y Figura 5.36.

Figura 5.35. Tamaño de paquetes (izquierda) y estadísticos principales de

RTT para datos en servidor, prueba LAN 2.

70


para datos en cliente, prueba LAN 2.

En la conexión de video no hubo tanta variabilidad con en la prueba anterior en la conexión

servidor puente, pero en la conexión cliente puente sí, aunque en esta última se tuvieron excelentes

beneficios en el promedio de RTT, ver Figura 5.37 y Figura 5.38.

Figura 5.37. Tamaño de paquetes (arriba) y estadísticos principales de RTT para video en

servidor, prueba LAN 2.

71


en cliente, prueba LAN 2.

5.2.3 Pruebas en la misma ciudad. Las siguientes pruebas se aplicaron en la misma ciudad fuera del campus en distintos lugares.

Se aplicaron dos pruebas con duraciones distintas como se describen a continuación.

5.2.3.1 Prueba Ab.

Esta prueba se realizó el 6 de noviembre de 2008 a las 20:43 horas y tuvo una duración de

29:30 minutos. La distancia aproximada de este cliente fue de 900 metros y se aplicó el comando

tracert para corroborar la conexión a Internet comercial como se muestra en la Figura 5.39 donde

se ve claramente la dirección 200.94.151.126 la cual pertenece al firewall de Alestra.

72

Figura 5.39. Traza de cliente en la misma ciudad a 0.9 Km.

El comportamiento del audio en la conexión servidor puente fue variado con un RTT promedio

de 47.8327 ms como se muestra en la Figura 5.40 en cuanto a la conexión puente cliente se tuvo

menos variabilidad y el doble de retardo como se puede observar en la Figura 5.41.


audio en servidor, prueba a 0.9 Km.


audio en cliente, prueba a 0.9 Km.

73

Tocante a la conexión de datos servidor puente se notó muy poca variabilidad y un RTT de

58.8177 lo cual es aceptable a cómo se ha visto hasta ahora como se puede ver en la Figura 5.42.

En la conexión puente cliente la variabilidad aumentó así como también el retardo promedio como

se muestra en la Figura 5.43.


datos en servidor, prueba a 0.9 Km.


datos en cliente, prueba a 0.9 Km.

La conexión de video mostró un 90% de los paquetes concentrados en un sólo tamaño y un

RTT muy similar tanto en la conexión servidor puente como en la puente cliente como se muestra

en las Figura 5.44 y Figura 5.45.

74

Figura 5.44. Estadísticos principales de RTT para video en servidor, prueba a 0.9 Km.


video en cliente, prueba a 0.9 Km.

5.2.3.2 Prueba G.

Esta prueba se efectuó el 9 de noviembre de 2008 a las 21:23 horas, tuvo una duración de 39

minutos y su distancia aproximada fue de 10.8 km que está dentro del área metropolitana de

Monterrey, Nuevo León. Se aplicó el comando tracert para dar veracidad a que la entrega de los

paquetes fuera por Internet comercial y como se ha observado cuando se encuentra la dirección ip

200.94.151.126 el acceso es a través de Alestra como lo muestra la Figura 5.46.

75

Figura 5.46. Traza de cliente en la misma ciudad a 10.8 Km.

Enseguida se muestra de manera más resumida las observaciones que se han hecho hasta ahora

en conexiones de audio, datos y video.


audio en servidor, prueba a 10.8 Km.

76

Figura 5.48. Tamaño de paquetes (arriba) y estadísticos principales de RTT para audio en

cliente, prueba a 10.8 Km.


para datos en servidor, prueba a 10.8 Km.


para datos en cliente, prueba a 10.8 Km.

77


en servidor, prueba a 10.8 Km.


video en cliente, prueba a 10.8 Km.

78

5.2.4 Prueba en otros estados de la república. La siguiente prueba se realizó dentro del país pero al otro lado de éste, atravesando lo más ancho

que es el norte para tener una referencia de una telemanipulación con varios kilómetros de distancia

pero dentro del territorio mexicano.

5.2.4.1 Prueba D.

Esta prueba se efectuó desde Guaymas, Sonora el 4 de noviembre de 2008 a las 18:19 horas, con

una duración de 22:15 minutos y una distancia aproximada de 1081.43 km. El comando tracert

también se efectuó en esta prueba dónde se puede ver claramente la dirección del firewall de

Alestra, ver la Figura 5.53.

Figura 5.53. Traza de cliente en Guaymas, Sonora (1081.43 km).

La prueba mostró el siguiente desempeño en sus tres conexiones, audio, datos y video tanto en el

enlace servidor puente y puente cliente como lo muestran las siguientes figuras.


audio en servidor, cliente en Sonora.

79

Figura 5.55. Estadísticos principales de tamaño de paquetes (arriba) y de RTT para audio en

cliente, cliente en Sonora.


datos en servidor, cliente en Sonora.


datos en cliente, cliente en Sonora.

80


video en servidor, cliente en Sonora.


video en cliente, cliente en Sonora.

5.2.5 Prueba en otro país. La siguiente prueba se aplica en el país vecino, Estados Unidos al otro lado casi en la frontera

con Canadá.

5.2.5.1 Prueba E.

Esta prueba se realizó en S Western Avenue, Chicago, Illinois, Estados Unidos,

aproximadamente 2 138 km de distancia entre cliente y servidor, el 19 de noviembre de 2008 a las

18:44 horas y tuvo una duración de 17:06 minutos. El desempeño de esta prueba está mostrado en

las siguientes figuras.

81


audio en servidor, cliente en Chicago.

Figura 5.61. Tamaño de paquetes (arriba) y estadísticos principales de RTT para audio en

cliente, cliente en Chicago.

82


en servidor, cliente en Chicago.

Figura 5.63. Tamaño de paquetes (arriba) y estadísticos principales de RTT para datos en cliente,

cliente en Chicago.


cliente en Chicago.

83


cliente, cliente en Chicago.

5.2.6 Pruebas en otro continente. Se aplicaron dos pruebas cuando el cliente se encuentra en otro continente, en este caso Europa.

Estas fueron las distancias más largas que se probaron y no por eso se tuvieron resultados diferentes

a las pruebas que se han visto hasta ahora.

5.2.6.1 Prueba Italia.

Esta prueba se llevó a cabo desde la ciudad de Paola, Italia el 23 de noviembre de 2008 a las

14:58 horas, horario de México. Tuvo una duración de 41:48 minutos y la distancia aproximada del

cliente fue de 10236 Km. Se realizó la ejecución del comando tracert para verificar que los paquetes

se entregaron desde Italia por Internet comercial.

84

Figura 5.66. Traza de cliente en Paola, Italia.

Los resultados de desempeño fueron los que se muestran en las siguientes figuras.


audio en servidor, cliente en Italia.

Figura 5.68. Estadísticos principales de RTT para audio en cliente, cliente en Italia.

85


datos en servidor, cliente en Italia.


datos en cliente, cliente en Italia.

Figura 5.71. Estadísticos principales de RTT para video en servidor, cliente en

Italia.

86


video en cliente, Italia.

5.2.6.2 Prueba España.

Esta prueba se efectuó el 25 de noviembre de 2008 a las 15:20 horas, horario de México desde

Madrid, España, aproximadamente 8719 km de distancia. Se cumplió con un tiempo de 17:30

minutos de prueba y también se efectuó el comando tracert como se muestra en la Figura 5.73.

Figura 5.73. Traza de cliente en Madrid, España.

Los resultados de su desempeño se muestran a continuación en las siguientes figuras.

87


audio en servidor, Cliente en Madrid.

Figura 5.75. Estadísticos principales de RTT para audio en cliente, Cliente en

Madrid.


datos en servidor, Cliente en Madrid.

88


datos en cliente, Cliente en Madrid.


video en servidor, Cliente en Madrid.

89


video en cliente, Cliente en Madrid.

5.3 Pruebas Internet2. Se aplicaron dos pruebas en Internet2, ambas pruebas con la Universidad de Texas en College

Station, esto para completar el análisis de este sistema en estas tres modalidades QoS, Internet e

Internet2.

5.3.1 Prueba A. Esta prueba se realizó el 5 de noviembre de 2008 a las 21:00 horas, desde los departamentos de

residencias en College Station, Texas, tomando una distancia aproximada de 671.38 km y se

concluyó con una duración de 23 minutos. La red que comparte la ciudad universitaria con los

dormitorios es la misma que la red que se comparte dentro de las aulas del campus, lo importante de

todos esto es que la conexión se lleva a cabo a través del nodo de Internet2 del campus que para

esto se puede observar la Figura 5.80 muestra la dirección IP 200.23.60.133 la cual es el nodo a

Internet2 del ITESM campus Monterrey, no se completa la traza porque la computadora puente

tiene activado el firewall.

90

Figura 5.80. Traza de cliente en College Station, Texas (Internet2).

Los resultados de esta prueba se pueden notar en las siguientes figuras donde se muestra la

actividad de las tres conexiones tanto en servidor puente como en puente cliente.


audio en servidor, Internet2 A.


audio en cliente, Internet2 A.

91


datos en servidor, Internet2 A.


datos en cliente, Internet2 A.


servidor, Internet2 A.

92


en cliente, Internet2 A.

5.3.2 Prueba A2. Esta prueba se efectuó con el mismo cliente el 20 de noviembre de 2008 a las 18:12 horas, pero

esta vez dentro del campus en la universidad de Texas. La misma distancia aproximada que en la

prueba anterior se involucra en ésta sólo que con una duración de 19:35 minutos. Los resultados

expuestos por esta prueba se muestran a continuación en las siguientes figuras.


en servidor, Internet2 A2.

93


en cliente, Internet2 A2.


en servidor, Internet2 A2.


datos en cliente, Internet2 A2.

94

Figura 5.91. Estadísticos principales de RTT para video en servidor, Internet2 A2.


cliente, Internet2 A2.

95

5.4 Tratamiento de datos. Se hizo un análisis de los datos para encontrar si existe alguna diferencia entre mantener las tres

conexiones activas, sólo una de ellas o dos de ellas a su vez estos datos tuvieron que ser sometido a

pruebas estadísticas para interpretar la información de estos experimentos. La técnica estadística

utilizada en este análisis es conocida como la menor diferencia significativa de Fisher (LSD). Esta

técnica determina si la diferencia que se encuentra entre dos tratamientos es debida al tratamiento

mismo o si simplemente se debe a cuestiones de azar. Se realizaron análisis de varianza (ANOVA)

de las conexiones y se utilizó la prueba LSD (p< 0.05) para la interpretación de medias, es decir que

el 95% de las ocasiones que estos tratamientos se comparen no habrá diferencia estadística

significativa entre ellos. Por cada bloque de datos se asignó una letra que diferenciaba su media de

otro bloque si la letra entre dos tratamientos es la misma significa que no hay diferencia

significativa entre esos bloques de datos.

Se tomaron al azar dos clientes los cuales resultaron el de la prueba T 2 y el de la prueba G. La

dinámica del experimento consistía en tomar tres períodos de tiempo en donde hubiera ya sea audio,

datos y video (tratamiento 1), otros tres donde sólo hubiera datos y video (tratamiento 2), tres más

donde hubiera datos y audio (tratamiento 3) y unos tres más donde sólo existiera la conexión de

datos (tratamiento 4). Y estos fueron los resultados del estadístico.

Figura 5.93. LSD (p< 0.05) para prueba T 2.

Como se muestra en la Figura 5.93 la letra a indica que no hubo diferencia estadísticamente

significativa entre el tratamiento uno y el tratamiento tres siendo que en el uno existía la conexión

de audio activa y en el tres no. Mientras que la letra b expresa que tampoco hay diferencia

estadísticamente significativa entre datos en los cuatro tratamientos y un resultado un poco extraño

es lo que muestra para audio que también fue categorizado por la letra b, lo cual da la certeza que no

existe diferencia estadísticamente significativa tampoco para el sonido a pesar que exista la

conexión de video o no en el sistema, es decir la programación asigna los mismos recursos para

audio que para datos.

96

Por otra parte en el análisis de la prueba G se encontró que se tuvieron dos vertientes, cuando

había video de alta calidad y video de baja calidad. En el caso de video de alta calidad, ver Figura

5.94 se encuentra que al igual que en el experimento anterior no hay diferencia significativa entre

video cuando existe audio o no y también se asignan los mismos recursos a datos y audio ya que el

estadístico los reconoce con la misma letra, b.

Figura 5.94. LSD (p< 0.05) para prueba G con alta calidad de video.

Los mismos resultados se encontraron cuando se analizó la prueba G con video de baja calidad,

el estadístico reconoce dos diferencias significativas la de video y la de audio y datos que al igual

que en las dos anteriores experimentaciones se encontró que la interface asigna los mismos recursos

a audio y datos ya que son muy comparables por sus medias como se muestra en la Figura 5.95.

Figura 5.95. LSD (p< 0.05) para prueba G con baja calidad de video.

97

5.5 Análisis de porcentaje de pérdidas, retrasos y ancho de banda. A lo largo de este capítulo se han mencionado las pruebas que se aplicaron y de dónde se han

aplicado para lo cual a continuación se presentan cuatro tablas donde se resume la duración de cada

prueba y la distancia aproximada que tenía el cliente que la efectuó con el objetivo de poder

comparar más directamente la influencia que tiene la distancia en el retraso y pérdida de

información.

Tabla 5.1. Distancia entre cliente servidor y duración de la prueba con QoS.

T 2 T 38

Distancia [Km] 2530.21 2530.21

Duración [min] 16:35 12:10

Tabla 5.2. Distancia entre cliente servidor y duración de la prueba local.

Local Local 2

Distancia [Km] 0.02 0.02


Tabla 5.3. Distancia entre cliente servidor y duración de la prueba en Internet comercial.

E Ab D G LAN 1 LAN 2 Italia España

Distancia [Km] 2138 0.9 1081.43 10.8 0.05 0.02 10236 8719

Duración [min] 17:06 29:30 22:15 39:00:00 13:20 08:30 41:48 17:30

Tabla 5.4. Distancia entre cliente servidor y duración de la prueba en Internet2.

A A 2

Distancia [Km] 671.38 671.38


98

El análisis de pérdidas de paquetes y retrasos en el intercambio de paquetes se llevó a cabo con

el apoyo de un rastreador de red llamado Wireshark version 1.0.2, la metodología de registro

involucraba instalar el programa en el cliente y también en el servidor, configurar la interface por

donde la computadora podía acceder a Internet y fijar el tiempo de almacenamiento de archivos en

cinco minutos, de esta manera cada cinco minutos se generaba un archivo en el cual se filtraban

sólo los puertos 6001 (datos), 6010 (sonido), 1000 (video) en el caso del servidor y 1001 (video),

1002 (datos), 1003 (sonido) en el caso del cliente. Después estos datos filtrados eran procesados en

una hoja de cálculo para obtener el RTT y por medio de la sumatoria de paquetes de la conversación

que se llevó a cabo entre los puertos TCP se lograba encontrar la pérdida de éstos entre las dos

computadoras. A continuación vemos esta información resumida en las siguientes cuatro tablas.

Tabla 5.5. Porcentaje de pérdida de paquetes y retardo promedio en prueba con QoS.

T 2 T 38

% Pérdida RTT [ms] % Pérdida RTT [ms]

Video 19.42 94.07 20.95 35.32

Datos 20.45 97.28 19.65 92.58

Sonido 17.35 148.97 18.41 127.32

Tabla 5.6. Porcentaje de pérdida de paquetes y retardo promedio en prueba local.

Local Local 2


Video 0.0054 6.80 0.0967 9.73

Datos 0.0064 79.37 0.0256 87.65

Sonido 0 104.32 0.0689 103.73

99

Tabla 5.7. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet comercial parte 1.

E Ab D G

% Pérdida RTT

[ms]

% Pérdida RTT

[ms]

% Pérdida RTT

[ms]

% Pérdida RTT

[ms]

Video 30.3 69.86 15.14 47.62 38.24 143.17 31.26 81.63

Datos 21.73 110.27 16.45 137.60 18.8 247.96 15.62 125.12

Sonido 5.463 165.73 4.96 120.53 3.81 194.49 6.21 133.27

Tabla 5.8. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet comercial parte 2.

LAN 1 LAN 2 Italia España

% Pérdida RTT

[ms]

% Pérdida RTT

[ms]

% Pérdida RTT

[ms]

% Pérdida RTT

[ms]

Video 13.14 7.68 14.34 9.22 17.58 59.22 20.85 335.71

Datos 7.23 88.36 10.65 115.53 17.38 136.81 18.44 338.05

Sonido 17.38 81.22 27.54 80.17 9.35 95.38 7.59 157.00

Tabla 5.9. Porcentaje de pérdida de paquetes y retardo promedio en prueba en Internet2.

A A 2


Video 16.65 48.18 30.51 17.08

Datos 21.21 119.54 26.86 96.46

Sonido 2.48 125.41 20.89 90.39

100

Mostrándose como las conexiones óptimas las cifras con menores pérdidas y menores tiempos

de retraso como se muestra en la siguiente tabla.

Tabla 5.10. Conexiones óptimas.

Video Datos Sonido

% Pérdida 0.0054 0.0064 0

RTT (ms) 6.80 79.37 80.17

Así como también se muestra en la siguiente tabla las peores conexiones las cuales tuvieron RTT

muy altos y pérdidas porcentuales elevadas también.

Tabla 5.11. Conexiones con bajo desempeño.

Video Datos Sonido

% Pérdida 38.24 26.86 27.54

RTT (ms) 335.71 338.05 194.49

En cada prueba se vio reflejado un ancho de banda diferente para cada conexión ya sea de datos,

audio o video, que claro esto influyó en el desempeño de la conexión haciéndola más lenta o fluida

y el cliente lo notaba de forma que se cortara el video o el sonido o que algún comando de

movimiento del robot no se ejecutara cuando se accionó. Con Wireshark se pudo registrar la

velocidad promedio que se tuvo en las tres conexiones. Este velocidad se muestra en las siguientes

tablas como los KB/s que se tuvieron en la transmisión de paquetes del servidor al puente (s-p), del

puente al servidor (p-s), del puente al cliente (p-c) y del cliente al puente (c-p) en los cuatro

experimentos que se realizaron, QoS, Internet, local e Internet2.

101

Tabla 5.12. Velocidad en conexión servidor puente, puente servidor en prueba con QoS.

Video [KB/s] Datos [KB/s] Sonido [KB/s]

T 2 S-P 0.49 12.71 8.50

P-S 15.96 1.39 0.29

T 38 S-P 0.44 12.26 8.48

P-S 19.20 1.35 0.29

Tabla 5.13. Velocidad en conexión cliente puente, puente cliente en prueba con QoS.


T 2 C-P 0.47 9.06 0.41

P-C 14.62 77.09 8.34

T 38 C-P 0.59 1.46 0.41

P-C 19.39 12.41 8.39

Tabla 5.14. Velocidad en conexión servidor puente, puente servidor en prueba local.


Local S-P 6.56 47.35 8.33

P-S 328.98 6.81 0.35

Local 2 S-P 5.41 28.16 8.40

P-S 265.69 6.87 0.35

102

Tabla 5.15. Velocidad en conexión cliente puente, puente cliente en prueba local.


Local C-P 6.56 47.35 8.33

P-C 328.98 6.81 0.35

Local 2 C-P 5.41 28.16 8.40

P-C 265.69 6.87 0.35

Tabla 5.16. Velocidad en conexión servidor puente, puente servidor en prueba en Internet.


E S-P 0.54 12.99 8.16

P-S 26.39 1.90 0.29

Ab S-P 0.50 11.11 6.79

P-S 26.51 1.25 0.24

D S-P 0.20 6.92 6.23

P-S 8.39 1.09 0.23

G S-P 3.94 12.26 8.02

P-S 23.13 1.43 0.29

LAN 1 S-P 15.80 47.46 8.48

P-S 596.90 4.19 0.30

LAN 2 S-P 4.66 28.68 8.44

P-S 302.99 4.14 0.30

Italia S-P 0.57 15.83 8.47

P-S 28.50 2.30 0.31

España S-P 0.10 3.60 6.94

P-S 3.60 0.52 0.27

103

Tabla 5.17. Velocidad en conexión cliente puente, puente cliente en prueba en Internet.


E C-P 0.46 1.42 0.22

P-C 22.16 10.01 6.85

Ab C-P 0.65 1.31 0.21

P-C 24.32 10.78 4.40

D C-P 0.31 1.14 0.21

P-C 8.52 6.71 6.14

G C-P 0.47 1.68 0.37

P-C 18.83 13.79 7.71

LAN 1 C-P 13.88 4.25 0.42

P-C 728.99 47.51 8.53

LAN 2 C-P 6.20 4.15 0.42

P-C 304.55 28.96 8.53

Italia C-P 0.89 2.47 0.48

P-C 28.90 15.95 8.59

España C-P 0.12 0.56 0.29

P-C 3.73 3.56 6.47

Tabla 5.18. Velocidad en conexión servidor puente, puente servidor en prueba en Internet2.


A S-P 0.69 16.79 8.50

P-S 30.48 2.17 0.30

A 2 S-P 2.53 33.03 8.45

P-S 146.80 4.72 0.30

104

Tabla 5.19. Velocidad en conexión cliente puente, puente cliente en prueba en Internet2.


A C-P 0.89 2.64 0.32

P-C 29.57 17.34 8.51

A 2 C-P 4.06 5.09 0.41

P-C 135.73 33.16 8.53

Siendo los mejores anchos de banda los siguientes.

Tabla 5.20. Mejor desempeño de velocidad en conexiones servidor puente, puente servidor.


S-P 15.80 47.46 8.50

P-S 596.90 6.95 0.39

Tabla 5.21. Mejor desempeño de velocidad en conexiones cliente puente, puente cliente.


C-P 13.88 47.35 8.40

P-C 728.99 77.09 8.59

Y las peores conexiones tuvieron un ancho de banda como se muestra en las siguientes tablas.

105

Tabla 5.22. Peor desempeño de velocidad en conexiones servidor puente, puente servidor.


C-P 0.12 0.56 0.21

P-C 3.73 3.56 0.35

Tabla 5.23. Peor desempeño de velocidad en conexiones cliente puente, puente cliente.


S-P 0.10 3.60 6.23

P-S 3.60 0.52 0.23

En la programación del servidor no se le pudo otorgar al cliente el control de activar o

desactivar el audio a diferencia de cómo se hizo con el video. Este detalle hacía que el servidor

empezara varias conexiones de audio en toda la prueba cuando el control de éste estuviera

desactivado lo cual hacía al sistema que enviara nada por el puerto 6010. Entonces lo único que se

registraba al final de la prueba era la información que el protocolo TCP utiliza para mantener la

comunicación, estos paquetes también fueron contabilizados y se comprobó en todos sus casos que

el porcentaje de las pérdidas cuando el paquete es pequeño es menor que cuando va cargado de

información esto es debido a que la Internet descarta los paquetes que más demandan ancho de

banda. Esto se muestra en las siguientes tablas.

Tabla 5.24. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba con QoS.

T 2 T 38

Sonido 0.15 0.63

106

Tabla 5.25. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba local.

Local Local 2

Sonido 0 0

Tabla 5.26. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba en Internet.

E Ab D G LAN 1 LAN 2 Italia España

Sonido 0.21 0.55 0.09 9.2 0.86 0 1.21 1.13

Tabla 5.27. Porcentaje de pérdidas de paquetes pequeños de sonido en prueba en Internet2.

A A 2

Sonido 1.6 0.11

107

6 Conclusiones.

6.1 Conclusiones técnicas.

De acuerdo con las observaciones que permiten hacer estas pruebas se puede asegurar que en el

peor de los casos el retraso se ve afectado hasta un 81% por cuestiones de entrega de paquetes en la

red interna (descontando las aportaciones de LAN 1, LAN2, Local 1 y Local 2 ya que no está

diseñado este sistema para trabajar de esa manera), ver Figura 6.1 además la pérdida de paquetes

que se produce en la LAN del campus pueden llegar hasta un poco más del 28% afectando

conexiones que tienen un buen desempeño en la WAN, ver Figura 6.2.

Figura 6.1. Porcentaje de RTT de servidor a puente en Internet, Local, Internet2 y QoS.

108

Figura 6.2. Comparación de porcentaje de pérdidas en Internet, Internet2 y QoS.

El comportamiento del retraso en la mayoría de los casos estaba relacionado directamente con la

distancia del cliente y la hora en la cual se efectuó la prueba aunque un factor muy importante fue el

ancho de banda promedio que se registró en el puerto que coincide un ancho de banda pequeño con

grandes cantidades de retraso lo cual expone que el RTT puede ser utilizado para describir el

congestionamiento de la red.

En las conexiones de las pruebas siguientes: datos T 2, audio y datos local, audio local 2, audio

LAN 1, audio y datos LAN 2, audio Ab, datos G, audio E, datos Italia, datos España y datos A se

observó una gran cantidad de paquetes con dimensión pequeña emitidos por el servidor cuestión

que indica inactividad del protocolo ya que esos paquetes se van vacíos y sólo se utilizan para

mantener la comunicación. Del lado del puente al cliente se invirtió el caso eran paquetes grandes

los que eran entregados y el índice de paquetes pequeño disminuía drásticamente esto fue favorable

para estas conexiones ya que se mantenía la comunicación con paquetes que en verdad llevaran

información del sistema. Lo anterior indica que la red local del campus trabaja a una alta velocidad

y el sistema también lo cual hace que se estén enviando paquetes vacíos que lo único que hacen es

congestionar la red local ya que el cliente no recibió esta información.

109

Cuando se registraron los paquetes pequeños de audio se notó que las pérdidas de éstos casi

siempre estaban por abajo del porcentaje de paquetes grandes lo cual indica que los paquetes

pequeños tienen un alto índice de seguridad al arribo, ver Figura 6.3. Esto puede ser utilizado a

favor del sistema si se secciona la información en paquetes no muy grandes.

Figura 6.3. Comparación de sonido en paquetes grandes y paquetes pequeños.

Se aplicaron pruebas especiales al video para comprobar esto. Se realizó un programa donde

sólo se mandara video por un canal (a nivel red local) y otro programa donde se mandara el video

dividido en 6 canales.

110

Figura 6.4. Distribución de datos en video de sin dividir.

Figura 6.5. Distribución de datos en video dividido, 1er y 2º canal.

111

Figura 6.6. Distribución de datos en video dividido, 3er y 4º canal.

Figura 6.7. Distribución de datos en video dividido, 5º y 6º canal.

112

Tabla 6.1. Porcentaje de pérdida de paquetes y retardo promedio en prueba de video con 1 sólo canal y con 6

canales.

V1 V6


Video 0.49 0.845 0 123.3

Con esto se demostró que efectivamente si se mandan paquetes pequeños en la red la

probabilidad de que el cliente los reciba es muy alta pero esto indudablemente amplió el tiempo de

retardo.

Al aplicar la prueba estadística LSD se encontró que no existe relación en cuanto a la actividad

promedio paquetes/bytes entre puertos ya que esta razón no disminuía ni aumentaba si se cargaba al

sistema con otra conexión o se desconectaba alguna.

Se encontró que aplicar reservación de ancho de banda como calidad de servicio o utilizar

Internet2 no asegura un buen desempeño del sistema en cuanto a velocidad tampoco en cuanto a

pérdida de información ya que en las gráficas de las Figuras 6.1 y 6.2 se mantuvieron estos datos

muy cercanos a los mayores con respecto a los demás.

6.2 Conclusiones personales. El objetivo de esta tesis se cumplió puesto que se sometió a un sistema tipo stand alone a

diferentes condiciones de Internet. Se encontró que no se necesita contar con un nodo de internet2

para poder manipular esta interface ya que la demanda de ancho de banda está por debajo de 38 KB,

quizá implementar reservación de ancho de banda como calidad de servicio sea suficiente para tener

un buen resultado de teleoperación. Los beneficios de Internet2 no se dejaron notar en medida

tajante en esta investigación ya que el campus accede a esta red a través de un enlace que no va más

allá de 34 Mbps y últimamente se encuentra en demanda por video conferencias con otras

universidades.

Se encontraron dos áreas de oportunidad muy importantes, ya que los paquetes grandes en la

Internet son descartados de llegar a su destino con más probabilidad que los pequeños. Seccionar la

información en diferentes puertos dio resultados óptimos y sencillez en la programación ya que no

fue necesario agrupar la información en un sólo canal y decodificarla en el destino además que

Internet veía a estos paquetes de información como demandas de ancho de banda distintas.

113

Es fundamental resolver el direccionamiento de los paquetes lo más pronto posible a la WAN

desde el servidor de la interface ya que esto disminuye en gran medida el desempeño de ésta que se

ve reflejado en altos retrasos y altas pérdidas de información. Esto se lograría permitiendo que la

computadora servidor pudiera acceder a la WAN además de colocarla en una red lo más próxima a

los nodos externos del campus.

6.3 Trabajos futuros. Tener un bajo procesamiento de información en la computadora servidor es una gran área de

oportunidad que se tendría que lograr para que el sistema sólo se concentre en la comunicación de

audio, datos y video. Para esto se pueden realizar algunas mejoras a este sistema como por ejemplo,

encontrar cámaras que no necesiten procesar la imagen en la programación del servidor si no que

tengan en sí ya un procesador, también este sistema se basa en control lógico, lo cual significa que

da comandos de ejecución de acuerdo a estados por lo tanto no es necesario estar leyendo

constantemente las variables del sistema. El cliente ve al sistema por páginas, es decir, si quiere

manejar el robot se va a la página de robot, si quiere manipular la mesa de ensamble se va al menú

de la página de la mesa de ensamble y así sucesivamente si quiere manejar cualquiera de las

máquinas disponibles, por lo tanto se puede mandar una variable que le indique al servidor cuál es

la acción que quiere tomar el cliente respecto a un subsistema y activar éste cuando el cliente se

cambie de página, de esta manera LabVIEW sólo se concentra en el ciclo que le corresponde a ese

subsistema y los demás permanecen lo más inactivos posible. También el manejo de variables

cuando se trata de variables locales el sistema ocupa más procesamiento que cuando se trata de

property nodes tipo value, cambiar estas variables lo más que se pueda a variables tipo value

significaría un ahorro en procesamiento para la computadora servidor.

Otra actividad más relacionada con el rendimiento del procesamiento tiene que ver con el ciclo

de lectura que se lleva a cabo en cada ciclo while para esto es factible someter cada subsistema de la

celda a experimentos como al que fue sometido el robot en donde se le mandaban un conjunto de

tareas de traslación y rotación de 1mm en diferentes ejes, ya que era el comando más rápido al cual

tenía que responder el robot. Se procuró generar grupos de tareas primero en cada eje y finalmente

mezcladas para buscar alguna diferencia en los tiempos de procesamiento.

Primero se observaron los tiempos de procesamiento ordenados, en conjunto con los tiempos de

cada una de las actividades solicitadas a la celda. Esto arrojó el siguiente análisis en la ¡Error! No se

ncuentra el origen de la referencia.8. Los puntos negros representan los tiempos de procesamiento

114

y los puntos de colores representan los tiempos de actividad de la máquina en las diferentes

opciones.

Figura 6.8. Tiempos de procesamiento y tiempos de tareas realizadas.

En este segundo experimento, se nota que el escalón de tiempos SB (stand by o espera)

observado en el primer experimento se sigue presentando cuando la celda tiene actividad. Esto

expone que los tiempos debajo de estos escalones son cuando la celda esta fuera de operación. Los

tiempos de actividad (puntos de colores) sólo se grafican para observar cómo afectan la aparición de

estos escalones. Si se considera por separado los cuatro grupos de actividades (diferenciados por

cada escalón), se tiene lo siguiente.

Figura 6.9. Separación de conjuntos por tareas.

115

Se observa que la mayoría de los tiempos SB se encuentran alrededor de 250 ms lo cual por

algún método estadístico se pudiera llegar a un rango de límites para someter a ese ciclo while a un

tiempo de lectura óptimo para mantener al procesador lo más libre de tareas posible.

Otra área de oportunidad del sistema que no tiene mucho que ver con el procesamiento del

programa directamente se encuentra en la observación del RTT en las tres conexiones. Al enterarse

de que el RTT está subiendo, como ya se encontró en las pruebas puede deberse a algún

congestionamiento de la red, este número encontrado podría servir para someter el envío de

paquetes a ese número de tal manera que la red y la comunicación del sistema estén sincronizados y

así evitar la pérdida de paquetes de manera dinámica.

Al igual que se notó esta ventaja que se puede obtener de RTT también se notó que hay algunos

puertos más rápidos que otros, la mejora consistiría en encontrar de manera dinámica la mejor

opción para cambiar de puerto una conexión que se está viendo afectada por un bajo ancho de

banda.

Como se observó que los paquetes pequeños son los que menos probabilidad de ser descartados

por la red tienen, sería conveniente cambiar de protocolo a UDP que es un protocolo que se basa en

enviar paquetes no orientado a conexión, es decir no necesita saber si los paquetes llegan bien o

mal, descongestionando la red. Este protocolo maneja cantidades pequeñas de bytes por lo cual

resultaría factible hacer un sistema híbrido entre protocolos TCP y UDP donde los comando que no

son tan pesados pudieran ser enviados por UDP.

El sistema no hace distinción de comandos urgentes con comandos de retroalimentación o no

urgentes, como por ejemplo un botón de encendido de servomotores a un paro de emergencia, es

por eso que otra área de oportunidad se encuentra en priorizar la información y así se seccionaría

aún más los paquetes referentes a datos.

116

7 Referencias Bibliográficas.

[1] Kurose, J., Ross K.W. (2008). Computer networking: a top-down approach. (4a ed.).

Boston: Pearson/Addison Wesley.

[2] Hill, B. (2002). Cisco: manual de referencia. (2ª edición. ed.). (J. García, Trans.) Madrid.:

McGraw-Hill.

[3] Tanenbaum, A. (2003). Redes de computadoras. (3a ed.). (D. Morales, Trans.) México:

Prentice-Hall Hispanoamericana.

[4] Leiner, B., Cole, R., Postel, J., Mills, D. (Marzo de 1985). The DARPA Internet Protocol

Suite. IEEE Communications Magazine .

[5] Held, G. (1996). Ethernet networks : design, implementation, operation, management. (2a

ed.). New York: Wiley.t

[6] Ryer, T. L. (1994). Qué es internet. Wilmington, Delaware, U.S.A.: Addison-Wesley

Iberoamericana.

[7] Wang, Z. (2001). Internet QoS, architectures and mechanisms for Quality of Service.

Londres: Academic Press.

[8] León, G. (2002). Communications Networks Fundamental Concepts and Key Architectures.

Widjaja Indra: McGraw Hill.

[9] Douglas, E. (2000). Internetworking with TCP/IP: Principles, Protocols, and Architectures

(4a ed.). Prentice Hall.

[10] Carrera, J. (2003.). Análisis de la calidad del servicio de video sobre Internet2. [Maestría

en Ciencias en Tecnología Informática], Monterrey N.L., Instituto Tecnológico y de Estudios

Superiores de Monterrey: Campus Monterrey.

[11] Internet2 Network. (2008). Obtenido en Octubre 6, 2008, de "An Advanced Hybrid

Optical and Packet Network" :

http://www.internet2.edu/pubs/networkmap.pdf

117

[12] Galvez, J. A., Estremera, J. y González de Santos, P. (2000). A versatile Quadruped Robot

for Reserch in Force Distribution. 3a International Conference on Climbing and Walking

robots. Madrid, España .

[13] Benali, A., Idasiak, V., Fontaine, J.G. (2001). Remote robot teleoperation via Internet. A

first approach. IEEE International Workshop Robot and Human Interactive Comunitacion ,

306-312.

[14] The Eyebot Project. (1996). Retrieved Nov 2007, from Digital Media Arts:

http://www.dma.nYeyebotJ

[15] Talyor, K. Trevelyan, J. (1995). A Telerobot on The World Wide Web. Retrieved Dic

2007, from National Conference of the Australian Robot Association:

http://telerobot.mech.uwa.edu.au/robot/telerobo.htm

[16] Goldberg, K., Santarromana, J. . (1997). About the Tele-Garden. Retrieved Oct 2008,

from http://telegarden.aec.at/htmlhmtro.html

[17] De Pasquale, J. L. (1998). A Java interface for asserting interactive telerobotic control.

Retrieved Marzo 2008, from EEVRSJ International Conference on Intelligent Robotic Systems

: http://yugo.mme.wilkes.edu/-villanov

[18] Goldberg, K. Mascha, M. (1994). Beyond the Web: Excavating the Real World Via

Mosaic.

[19] Saucy, P., Mondada, F. (1997). KhepOnTheWeb . Retrieved Marz 2008, from An

Example of Remote Access to Mobile Robotics Facilities, IROS :

http://diwww.epfl.ch/lami/robots/K-family/KOTW/VRserver.html

[20] Paul G. Backes, Gregory K. Tharp y Kam S. Tso'. (1997). The Web Interface for

Telescience (WITS). IEEE International Conference on Robotics and Automation, (pp. 411-

417). Albuquerque, New Mexico.

[21] Salzmann, C. ; Latchman, H. A. ; Gillet, D. ; Crisalle, O. D. (1999). Virtual Laboratories

and Real-time Experiments in Engineering Education. International Conference on

Engineering Education, ICEE'99, 1999.

118

[22] V. Ramakrishnan, Y. Zhuang, S. Y. Hu, J. P. Chen, C. C. Ko, B. M. Chen y K. C. Tan.

(2001). Development of a Web-Based Laboratory for Control Experiments on a Coupled Tank

Apparatus. IEEE Transactions on Education , 44 (1), 76-86.

[23] Huosheng Hu, Lixiang Yu, Pui Wo Tsui, Quan Zhou. Internet-based Robotic Systems for

Teleoperation. International Journal of Assembly Automation , 21 (2).

[24] Alencastre-Miranda, M., Muñoz-Gómez, L., Rudomín, I. (2003). Teleoperating Robots in

Multiuser Virtual Environments. 4th Mexican International Conference on Computer Science

(pp. 314- 321). México: IEEE Computer Society .

[25] Oboe, R., Fiorini, P. (1997, Noviembre). A Design and Control Environment for Internet-

Based Telerobotics. International Journal of Robotic Research USA , 1-23.

[26] C. C. Ko, B. M. Chen, S. Y. Hu, V. Ramakrishnan, C. D. Cheng, Y. Zhuang y J. Chen.

(2001). A web-based virtual laboratory on a frequency modulation experiment. IEEE

Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews , 31 (3),

295-303

[27] Velázquez, L., Lucet, G., Reyes, H. (Noviembre de 2004). internet2. (U. N. A. M., Editor,

& Dirección General de Servicios de Cómputo Académico) Visitado el 9 de Octubre de 2008,

de www.enterate.unam.mx:

http://www.enterate.unam.mx/Articulos/2004/noviembre/internet2.htm

[28] Noticias. (2004, Junio). Retrieved Octubre 9, 2008, from www.cudi.edu.mx :

http://www.cudi.edu.mx/noticias/junio_2004/020604_cumbre.html

[29] CLARA, (Ed.). (n.d.). Mapa de Redes. (Gerencia de Relaciones Públicas y

Comunicaciones. CLARA, Producer) Visitada Octubre 9, 2008, sitio www.redclara.net:

http://www.redclara.net/index.php?option=com_wrapper&Itemid=163

[30] Topología de red CLARA Agosto 2008. (2008, Agosto). Retrieved Octubre 9, 2008, from

www.redclara.net: http://www.redclara.net/doc/topology_RedCLARA_Aug2007.pdf

[31] Ho, T. y Zhang, H. (1999). Internet-Based Tele-Manipulation. Canadian Conference on

Electrical and Computer Engineering (pp. 1425-1430). Alberta Canadá: IEEE.

119

[32] Nuño, E. (2004). Teleoperación de Robots: Técnicas, Aplicaciones, Entorno Sensorial y

Teleoperación Inteligente. Universitat Politècnica de Catalunya, Institut d'Organització i

Control de Sistemes Industrials. Barcelona , España: Universitat Politècnica de Catalunya.

[33] G. Clement, J. Vertut, R. Fournier, B. Espiau, G. Andre. (1985). An overview of CAT

control in nuclear services. Robotics and Automation. 2, pp. 713-718. IEEE .

[34] Ogai, H., Wada, K., Hirai, K., Abe, T., y Sato, G. (2007). Wireless radio communication

system for a pipe inspection robot. International Conference on Control, Automation and

Systems 2007 (pp. 2616-2619). Seoul, Korea: ICCAS.

[35] Croll Alistair y Eric Packman, “Managing Bandwidth”, Prentice Hall PTR, USA, 2000.

[36] Accesado en Noviembre 27 de 2008, de www.cudi.edu.mx:

http://www.cudi.edu.mx/preguntas/pregunta_19.htm

[37] Gamboa, J. (2008). Agent-Based Manufacturing System: A generic platform and its

methology for technical migration from FMS to RMS. [Maestría en Ciencias de la

Automatización], Monterrey N.L., Instituto Tecnológico y de Estudios Superiores de

Monterrey: Campus Monterrey.

[38] CABLETRON SYSTEMS. TPT 10BASE-T TWISTED PAIR TRANSCEIVER USER’S

MANUAL.

[39] O'Neillall, A. (2002, Febrero 2). http://www.motoman.com/motomedia/datasheets.

Accesado en Octubre 14, 2008, de www.motoman.com:

http://www.motoman.com/motomedia/datasheets/XRC.pdf

[40] Inc., M. (2002, Junio 1). MotoCom SDK Funtion Manual. Ohio, West Carrollton, Estados

Unidos.

[41] URBAN. (1999, Septiembre 3). Motoman - UP6. Accesado en Octubre 15, 2008, de

www.micromech.co.uk: http://www.micromech.co.uk/dir_products/pdf/motoman/up6-

series_robot.pdf

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE ... fileinstituto tecnolÓgico y de estudios...

Documents

Transcript of INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE ... fileinstituto tecnolÓgico y de estudios...