tes730

1

BENEMERITA UNIVERSIDAD AUTONOMA DE PUEBLA

FACULTAD DE CIENCIAS DE LA COMPUTACION

SIMULACIÓN DEL CONTROL DE UN ROBOT MOVIL A TRAVÉS DE GSM

TESIS PROFESIONAL

PARA OBTENER EL TITULO DE LICENCIADO EN CIENCIAS DE LA COMPUTACION

PRESENTA

CRISOFORO PAISANO OSORIO

ASESOR:

Dr. RODRIGO MONTÚFAR CHAVEZNAVA

COASESOR:

Dr. MIGUEL ANGEL LEÓN CHÁVEZ

2

��

��

��

��

��

��

� ��

��

� ��

��

��

1

Índice

Introducción…………………………………………………………………………………3 1.-Teléfono celular…………………………………………………………………………..6 1.1.- Surgimiento del teléfono celular………………………………………………….……6 1.2.- Funcionamiento y aplicaciones de un teléfono celular………………………………...7 1.3.- Infraestructura de la red Celular………………………………………………… …..10 1.4.- Tonos telefónicos……………………………………………………………………..11 2.- Sistema global para comunicaciones móviles (GSM)………………………………….13 2.1.- Antecedentes e historia del sistema global para comunicaciones móviles……….…..13 2.2.- Arquitectura de la red GSM………………………………………………………….14 3.- Servicio de Mensajes cortos (SMS)…………………………………………………….18 3.1.- Estructura de SMS…………………………………………………………………...18 3.2.- Funcionamiento de SMS……………………………………………………………...19 3.3.- Servicio de Mensajes Multimedia (MMS)……………………………………………23 4.- Control del robot……………………………………………………………………….24 4.1.- Antecedentes del robot………………………………………………………………..24 4.2.- Características del robot ……………………………………………………………...27 4.3.- Simuladores del robot………………………………………………………………...27 4.3.1.- Simulador Saphira…………………………………………………………………..27 4.3.2.- Simulador Stage Player……………………………………………………………..28 4.3.3.- Simulador Java Mobile Robots (JMR)……………………………………………..28 5.-Simulador Java Mobile Robots (JMR)………………………………………………….30 5.1.- Características del simulador JMR…………………………………………………...30 5.2.- Funcionamiento del simulador JMR………………………………………………….30 6.- Sistema de simulación del teléfono celular……………………………………………..39 6.1.- Planteamiento del sistema SimGSM…………………………………………………39 6.2.- Proceso de Modelado del sistema SimGSM…………………………………….........42 6.2.1.- Modelo de Análisis…………………………………………………………………43 6.2.2.- Modelo de Diseño…………………………………………………………………..50 6.2.3.- Modelo de Implementación………………………………………………………...64 6.2.4.- Modelo de Pruebas y Resultados …………………………………………………..77 7.- Interfaz entre simuladores………………………………………………………………78 7.1.-SimGSM………………………………………………………………………………78 7.2.- Java Mobile Robots (JMR)…………………………………………………………...80 8.- Conclusiones y Observaciones…………………………………………………………83 Bibliografía ………………………………………………………………………………116

2

Apéndice 1: Funcionamiento del Sistema GSM y Arquitectura del Protocolo…………...84 Apéndice 2: Manual de usuario JMR (Java Mobile Robots)………………………………98

3

Introducción El gran avance de la tecnología en el campo de la telefonía celular ha permitido realizar distintas aplicaciones tales como la transmisión de voz, datos, audio y video con algunas limitaciones. Con ayuda del sistema global para comunicaciones móviles, al teléfono móvil se le han agregado cada vez más funciones tales como el servicio de mensajes cortos, entre otros más. Con estos servicios surge la idea de controlar un robot por medio de un teléfono celular con tecnología GSM. Esta idea consiste en que el usuario pueda controlar el robot desde donde se encuentre, estableciendo la comunicación a través del sistema de telefonía celular. La solución a la idea propuesta anterior consiste en lo siguiente: De un simulador de un controlador para un robot móvil, el cual hará las funciones de un teléfono celular con tecnología GSM (SimGSM). Este simulador deberá interactuar con otro sistema existente, el simulador del robot móvil (SimRobot), de modo que la interacción entre ambos sea transparente para su uso posterior con el robot físico, un Pioneer 2. El Pioneer2 es un robot que pertenece a la familia de robots móviles. SimRobot recibe de SimGSM los comandos que a continuación se mencionan:

• Adelante • Gira

Con el comando adelante se especifica la distancia que se desea mover al robot y dicha distancia es medida en milímetros. Con respecto al comando gira se debe indicar el número de grados que se desea que gire el robot. SimRobot lleva a cabo dichos comandos, además puede enviar la información del estado del robot a SimGSM. El SimGSM consta de los siguientes módulos:

1. Teléfono celular con tecnología GSM. 2. MODEM GSM 3. Centro de servicio de mensajes cortos (SMSCYCT).

El módulo 1 asemeja a un teléfono celular, a partir del cual el usuario puede establecer la comunicación con el robot, en este módulo se muestran los datos del SimRobot, ya sea el estado del robot, así como el envió y recepción de mensajes para el control del robot, al igual que el envío de tonos. Con lo anterior podemos ver que contamos con dos maneras de realizar el control del robot: (1) estableciendo comunicación directa y empleando tonos y (2) a través del envío de mensajes. El simulador del robot cuenta con una cámara para obtener las imágenes del mundo en que se encuentra. Para obtener la distancia del robot a los obstáculos se usan los sónares que

4

posee el robot, la velocidad de adquisición del sonar es de 25Hz y el rango de sensibilidad del sónar va desde 10cm a aproximadamente 5m. El módulo 2 simula un MODEM GSM, el cual está conectado con el simulador del robot (SimRobot). El módulo 3 simula el funcionamiento del centro de servicios de mensajes cortos (Short Message Service Center, SMSC) el cual se encarga del envío de este tipo de mensajes, así como también la central telefónica. Los módulos se relacionan como lo muestra la figura 1.

Figura1: Esquema del sistema SimGSM. Como se muestra en la figura 1, si el comando que se va a enviar es por tonos, entonces el teléfono celular se conecta a la red de telefonía GSM y de ahí con el MODEM GSM el cual se conecta a su vez con el simulador del robot. Pero si el comando es enviado como mensaje corto entonces se establece la conexión al centro de Servicios de mensajes cortos y después se conecta con el MODEM GSM. La forma en que son enviados los comandos es decisión del usuario. Algunas de las aplicaciones que se han desarrollado con este tipo de teléfonos celulares, sólo por mencionar tenemos la siguiente: Se trata de un notificador GSM el cual es un equipo para el envío de mensajes cortos (mensajes de texto) a teléfonos móviles GSM. Algunas de las aplicaciones en las que podemos usar este notificador GSM son:

� Con ayuda de un termostato, la alerta del riesgo de heladas � El aviso de la abertura de puertas o ventanas ya sea en nuestra casa o

en el trabajo.

GSM

Central de Servicio de Mensajes Cortos y Central Telefónica (SMSCYCT)

MODEM Robot

Modulo1 Modulo2

Modulo3

5

El resto de la tesis está constituida de la siguiente manera. En el capítulo 1 tratamos los antecedentes del teléfono celular con tecnología GSM. También se explica el funcionamiento de un teléfono móvil y algunas de sus aplicaciones. En el capítulo 2 explicamos como surge la tecnología GSM, sus antecedentes y su historia, así como también vemos sus características y el funcionamiento de dicha tecnología. En el capítulo 3 se presenta el servicio proporcionado por la tecnología GSM que es el servicio de mensajes cortos (SMS short message service). En este capítulo se analiza la estructura de este servicio y su funcionamiento, así como también el servicio de mensajes multimedia. En el capítulo 4 tratamos aspectos relacionados con el simulador de las funciones del robot Pioneer 2, tales como los antecedentes de un robot, así como la historia de cómo surgió, sus características y el funcionamiento del simulador. En el capítulo 5 se dá una breve explicación de cómo funciona el simulador JMR (Java Mobile Robots). En el capítulo 6 se desarrolla la ingeniería de software para el sistema. Se explican los modelos de análisis, diseño, implementación y pruebas realizadas. En el capitulo 7 se describe la interfaz del simulador del robot así como también la interfaz del simulador realizado. En el capítulo 8 se dan las conclusiones del trabajo desarrollado y sus perspectivas.

6

Capitulo 1 Teléfono Celular 1.1.- Surgimiento del Teléfono Celular Las tecnologías inalámbricas han tenido su auge y desarrollo en estos últimos años. Una de las que ha tenido un mayor desarrollo ha sido la telefonía celular. Uno de los aspectos más interesantes del teléfono celular es que se trata solamente de un radio extremadamente sofisticado [1]. A pesar de que la telefonía celular fue concebida estrictamente para la voz, la tecnología celular de hoy es capaz de brindar otro tipo de servicios, como la transmisión de datos, audio y vídeo con algunas limitaciones. La telefonía celular se ha desarrollado a lo largo de diferentes generaciones: La primera generación (1G). La 1G de la telefonía móvil hizo su aparición en 1979 y se caracterizó por ser analógica y estrictamente para voz. La segunda generación (2G) La 2G arribó hasta 1990, y a diferencia de la primera se caracterizo por ser digital. El sistema 2G utiliza protocolos de codificación más sofisticados y se emplea en los sistemas de telefonía celular actuales. La tercera generación (3G) La 3G se caracteriza por contener alta convergencia de voz y datos con acceso inalámbrico a Internet; en otras palabras, es apta para aplicaciones multimedia y altas transmisiones de datos. Los protocolos empleados en los sistemas 3G soportan altas velocidades para la transmisión de información y están enfocados para aplicaciones más allá de la voz como audio (MP3), video en movimiento, videoconferencia y acceso rápido a Internet, sólo por mencionar algunas [2].

7

1.2.- Funcionamiento y Aplicaciones de un Teléfono Celular Una de las cosas más interesantes acerca de los teléfonos celulares es que en realidad son radios, unos radios extremadamente sofisticados, pero radios al fin y al cabo [1]. Una buena forma de entender la sofisticación de un teléfono celular es compararlo con un radio de onda corta (OC) o con radio de doble vía. Un radio OC es un aparato simple. Este permite que dos personas se comuniquen utilizando la misma frecuencia, así que sólo una persona puede hablar a la vez. Un teléfono celular es un dispositivo dual, esto quiere decir que utiliza una frecuencia para hablar, y una segunda para escuchar. Una radio OC tiene 40 canales. Un teléfono celular puede utilizar 1664 canales. Estos teléfonos también operan con "células" y pueden alternarse a medida que el teléfono se desplaza. Las células le dan a los teléfonos un rango increíble. Un radio de doble vía puede transmitir quizás hasta dos millas. Un radio OC, debido a que tiene un poder mucho más alto, puede transmitir hasta cinco millas. Alguien que utiliza un teléfono celular, puede manejar a través de toda la ciudad y mantener la conversación todo el tiempo. Las células son las que dan a los teléfonos celulares un gran rango. El teléfono celular estándar llamado AMPS (Advanced Mobile Phone System, o sistema de telefonía móvil avanzada) fue aprobado y usado por primera vez en Chicago en 1983. El estándar estableció un rango de frecuencias entre los 824 y los 894 Megahertz para teléfonos análogos. Para enfrentar la competencia y mantener los precios bajos, este estándar estableció el concepto de dos portadores en cada mercado, conocidos como portadores A y B. A cada portador se le dá 832 frecuencias de voz, cada una con una amplitud de 30 Kilohertz. Un par de frecuencias (una para enviar y otra para recibir) son usadas para proveer un canal dual por teléfono. Las frecuencias de transmisión y recepción de cada canal de voz están separadas por 45 Megahertz. Cada portador también tiene 21 canales de datos para usar en otras actividades [3]. Hace tiempo, antes de la aparición de los teléfonos celulares, la gente utilizaba radio teléfonos en sus autos. En los sistemas de radio teléfono existía una antena central por ciudad y 25 canales disponibles para esa antena. Esta antena central implicaba que su auto tuviera un transmisor muy potente lo suficiente como para transmitir por 40 o 50 millas. Esto también significaba que no mucha gente podía usar radio teléfonos, simplemente no había los suficientes canales. La gran idea del teléfono celular reside en que una ciudad puede ser dividida en pequeñas "células" que permiten extender la frecuencia por toda una ciudad. La comunicación móvil celular se basa en el concepto de la reutilización de la frecuencia. Es decir, el espectro limitado asignado al servicio se reparte, por ejemplo, el canal N fijo sin traslape, que entonces se asigna en un patrón repetido regular a una rejilla de células hexagonales. El hexágono es sólo una idealización conveniente que se aproxima a la de un círculo pero forma una rejilla sin espacios ni traslapes como es mostrado en la figura 1.1. La elección de N depende de varios aspectos que incluyen el ambiente de la propagación, la distribución del tráfico, y los costos locales. El ambiente de la propagación determina la interferencia recibida de las células vecinas del co-canal que alternadamente determina la

8

distancia de la reutilización, es decir, la distancia permitida entre las células del co-canal (células usando el mismo sistema de canales de frecuencia).

Figura 1.1: Esquema de las células. La determinación del tamaño de la célula se basa generalmente en la distribución y la demanda del tráfico local. Cuanto mayor es la concentración de la demanda del tráfico en el área, el tamaño de la célula tiene que ser más pequeño a fin de beneficiar la frecuencia situando a un número menor de suscriptores roaming y así de esta manera, se limita la probabilidad de bloqueo de la llamada dentro de la célula. Por otra parte, cuanto más pequeño es el tamaño de la célula, más equipo se necesitará en el sistema ya que cada célula requiere del equipo necesario de transceptor y conmutador, éste es conocido como el subsistema de estación base (BSS), a través del cual el usuario móvil accede a la red a través de enlaces de radio. El grado en el cual el espectro de frecuencia asignado es reutilizado sobre el área de servicio celular, determina la eficiencia del espectro en los sistemas celulares. Esto significa cuanto más pequeño es el tamaño de célula, y cuanto más pequeño es el número de células en la geometría de la reutilización, será más alta la eficacia del uso del espectro. Puesto que los sistemas de modulación digital pueden funcionar con una señal más pequeña de interferencia para la misma calidad del servicio, ésta permitirá una distancia más pequeña de la reutilización y proporcionará así una eficacia más alta del espectro. Ésta es una ventaja que el celular digital proporciona sobre los más viejos sistemas celulares análogos de comunicación por radio. Cada célula es típicamente de un tamaño de 10 millas cuadradas [35]. Debido a que los teléfonos celulares y las estaciones base utilizan transmisores de bajo poder, las mismas frecuencias pueden ser reutilizadas en células no adyacentes. Cada célula tiene una estación base que consta de una torre y un pequeño edificio en donde se tiene el equipo de radio. Cada célula utiliza un séptimo de los 416 canales duales de voz. Entonces, cada célula tiene más o menos 59 canales disponibles. En otras palabras, con una célula pueden hablar 59 personas al mismo tiempo.

9

Los teléfonos celulares poseen transmisores de baja potencia dentro de ellos. Muchos teléfonos celulares tienen dos intensidades de señal: 0.6 Watts y 3 Watts (en comparación, la mayoría de los radios de banda civil transmiten a 4 Watts). La estación base también transmite a baja potencia. Los transmisores de baja potencia tienen dos ventajas:

1. El consumo de energía del teléfono, que generalmente funciona con baterías, es relativamente bajo. Esto significa que la baja potencia requiere de baterías pequeñas, y ésto hace posible que existan teléfonos que caben en la mano.

2. Las transmisiones de las estaciones base y de los teléfonos no alcanzan una distancia más allá de la célula. Es por esto que, en cada celda de la figura 2.1 se pueden utilizar las 59 frecuencias. Las mismas frecuencias pueden ser reusadas por toda la zona.

La tecnología celular requiere de un gran número de estaciones base para ciudades de cualquier tamaño. Una típica ciudad grande puede tener cientos de torres emisoras. Pero debido a que hay tanta gente utilizando teléfonos celulares, los costos se mantienen bajos para el usuario. Cada portador en cada ciudad tiene una oficina central llamada MTSO (Mobile Telephone Switching Office). Esta oficina maneja todas las conexiones telefónicas y las estaciones base de la región [4]. Vale mencionar que los sistemas digitales han utilizado comúnmente sectores de células con 120 grados o antenas direccionales más pequeñas a distancias más lejanas, más baja es la efectividad de la reutilización. Esto permite un número más pequeño de células en el patrón de la reutilización y hace una fracción más grande del espectro total de la frecuencia disponible dentro de cada célula. Digamos que si tenemos un teléfono celular, lo encendemos, y alguien nos trata de llamar, la MTSO recibe la llamada, y trata de encontrarnos. En primera instancia, la MTSO nos tratará de encontrar activando el teléfono (utilizando uno de los canales de control, ya que el teléfono se encuentra siempre escuchando) en cada célula de la región hasta que el teléfono responda. Entonces la estación base y el teléfono deciden cuál de los 59 canales en el teléfono celular usarán. Ahora estamos conectados a la estación base y podemos empezar a hablar y escuchar. A medida que nos movamos en la célula, la estación base notará que la fuerza de la señal disminuye. Entre tanto, la estación base de la célula hacia la que nos estamos moviendo (que está escuchando la señal) será capaz de notar que la señal se hace más fuerte. Las dos estaciones base se coordinan a sí mismas a través del MTSO, y en algún punto el teléfono obtiene una señal que le indica que cambie de frecuencia. Este cambio hace que el teléfono mude su señal a otra célula. En los sistemas modernos, los teléfonos esperan una señal de identificación del sistema (IDS) del canal de control cuando se encienden. El teléfono también transmite una propuesta de registro y la red mantiene unos datos acerca de su ubicación en una base de datos (de esta forma es que la MTSO sabe en que célula nos encontramos si quiere timbrar

10

nuestro teléfono). A medida que nos movamos entre células, el teléfono detecta los cambios en la señal, los registra y compara con los de la nueva célula cuando cambia de canal. Si el teléfono no puede hallar canales para escuchar se sabe que está fuera de rango y muestra un mensaje de "sin servicio". La última tendencia son los teléfonos celulares digitales. Utilizan la misma tecnología radial (en diferentes bandas de frecuencia -por ejemplo, los teléfonos PCS utilizan frecuencias entre los 1.85 y 1.99 Gigahertz-) pero comprimen su voz en unos y ceros. Esta compresión permite que entre 3 y 10 llamadas telefónicas ocupen el espacio de una simple voz análoga. Estos aparatos también ofrecen otras características como correo electrónico y agenda. 1.3.- Infraestructura de la Red Celular El concepto de red celular es basado en la superposición de una arquitectura de red tipo estrella sobre la infraestructura de comunicación telefónica fija existente (landline). La red de la telefonía se utiliza para proporcionar no solamente enlaces de comunicación entre un usuario móvil y un usuario fijo, sino también para proporcionar la conectividad entre los usuarios móviles que vagan en células remotamente localizadas o en el dominio de las redes móviles operadas por diversos proveedores de servicio. Las BSS’s, proporcionan la administración de los recursos de radio, y la conmutación entre los canales de radio y las ranuras de TDM (multiplexion por división de tiempo) en sus conexiones con el centro de conmutación móvil (MSC). MSC enlaza grupos de BSS’s vecinos a través de punto a punto landline o microondas E1. El MSC actúa como el centro del nervio del sistema. Este controla el marcado y procesado de la llamada, y coordina el handover1 de la conexión móvil a partir de una estación base a otra mientras que el móvil vaga alrededor. Cada MSC alternadamente está conectado con la red pública local de conmutación telefónica (PSTN/ISDN) para proporcionar la conectividad entre usuarios móviles y los usuarios de teléfonos fijos, además de la conectividad global necesaria entre el MSC’s de la red móvil celular. Esto es pensado para permitir a cualquier usuario móvil comunicarse con cualquier otro usuario móvil o de telefonía fija en el mundo. Así, la conectividad global proporcionada por la infraestructura telefónica landline existente es utilizada para enlazar a los suscriptores de celulares móviles por todo el mundo [35]. Los enlaces directos entre ciertas MSC’s "locales" pueden también proporcionarse para permitir la comunicación entre dos usuarios móviles, evitando a la red de la telefonía cuando hay una circulación de tráfico considerable entre los usuarios móviles que vagan en las áreas bajo la cobertura de estos MSC’s. Así, la trayectoria de comunicación entre dos usuarios móviles que vagan bajo cobertura de dos MSC's locales puede ó no puede cambiar a través de la red pública de telefonía. Esto depende de la conectividad proporcionada entre las dos MSC’s. El MSC puede también conectar con las redes de datos públicas (PDN).

1 Este se da cuando una llamada en progreso puede cruzar la frontera de la celda adyacente. En este, un nuevo canal debe ser asignado a la llamada en la nueva celda para evitar una terminación forzada de la llamada.

11

1.4.- Tonos Telefónicos Tono dual de múltiples frecuencias (DTMF), también conocido como marcación por tonos (Touch Tone) es utilizado para señales telefónicas en la banda de frecuencias de la voz hacia el centro de conmutación de la llamada. Antes del DTMF los sistemas telefónicos utilizaban una serie de clics sobre la línea telefónica para la marcación de los números, este sistema es conocido como marcación por pulsos. Los clics eran realmente los que empezaban ó rompían la conexión en la línea telefónica, equivalía a mover un interruptor de luz a prendido ó apagado. DTMF fue desarrollado en los laboratorios Bell a fin de permitir a la señal de marcado el empleo de números de larga distancia, y la posibilidad de reestablecer enlaces inalámbricos a través de microondas ó de satélites. Los codificadores/decodificadores fueron agregados a las terminales que convertirían el pulso estándar en tonos de DTMF y los pondrían de vuelta a la terminal remota. En el sitio remoto otros codificadores/decodificadores descifrarán los tonos y los cambiarán a una serie de clics. Esto era como si se estuviera conectado directamente a la terminal, las señales trabajarían sobre cualquier clase de conexión. Esta idea de usar la red existente para señales así como para mensajes se conoce como in-band signaling. El sistema Touch Tone también introdujo una disposición de estandarización del teclado. Después de probar no menos de 18 diversas disposiciones, se eligió uno que eventualmente sigue siendo similar a los que hoy se usan, con un 1 en la parte superior izquierda y 0 en el fondo. Los ingenieros también habían previsto que los teléfonos podrían ser utilizados para tener acceso a las computadoras, y examinaron un número de compañías para ver lo que necesitarían para este papel. Esto condujo a la adición de las teclas (#) y el asterisco (*), así como también un grupo de teclas para la selección del menú, A, B, C y D Los militares de los Estados Unidos también utilizaron las letras en su sistema de teléfono Autovon. Aquí las utilizaron antes de marcar un número en el teléfono para darle prioridad a algunas llamadas, cortando las llamadas existentes si era necesario. La idea era permitir que el tráfico importante llegara a su destino. Por ejemplo, presionando C, inmediatamente, antes de marcar haría que el interruptor primero busca cualquier línea libre, y si todas las líneas estuvieran en uso, colgaría cualquier llamada no prioritaria, y después cualquier llamada de prioridad, esto quiere decir que primero buscaría una línea libre en tal caso de no encontrar entonces busca una llamada que no tiene prioridad y si no encontrara alguna, posteriormente buscara una llamada de prioridad inferior a la prioridad marcada y colgaría dicha llamada. Si bien el sistema telefónico Autovon ya no existe, se conservan sus nombres originales que eran (A) “Flash Override”, (B) “Flash”, (C) de inmediato, y (D) la prioridad. Con presionar una de estas teclas se da prioridad a la llamada, eliminando las otras conversaciones sobre la red. “Flash Override” es la prioridad más alta.

12

El teclado numérico de DTMF se presenta en una matriz 4 x 4 con cada fila que representa una frecuencia baja, y cada columna que representa una frecuencia alta. Presionar una sola tecla tal como ' 1 ' enviará un tono senosoidal de dos frecuencias: 697 y 1209 hertz. Los dos tonos son la razón de porque se llama multi-frecuencia. Estos tonos entonces son descifrados por el centro de conmutación para determinar que tecla fue presionada. En la tabla 1 se presenta un esquema de las bajas y altas frecuencias.

Tabla1) Frecuencias Del Teclado numérico de DTMF 1 2 3 A 697 hertz

4 5 6 B 770 hertz

7 8 9 C 852 hertz

* 0 # D 941 hertz

1209 hertz 1336 hertz 1477 hertz 1633 hertz Las frecuencias fueron diseñadas inicialmente con un cociente de 21/19, que es levemente menor que un tono entero, para evitar los armónicos o las frecuencias naturales que podrían ocurrir cuando se envían los dos tonos. Las frecuencias pueden no variar más que +/- 1.5% de su frecuencia nominal, o el centro de la conmutación no hará caso de la señal. Los tonos de alta frecuencia pueden tener el mismo volumen o tener más ruido que los tonos de bajas frecuencias cuando se están enviando a través de la línea. La diferencia de la intensidad entre las frecuencias altas y bajas puede ser tan grande como 3 decibeles (dB) y se refiere como twist [5].

13

Capitulo 2 Sistema Global para Comunicaciones Móviles (GSM) 2.1.- Antecedentes e historia del sistema global para comunicaciones móviles En el inicio de los años 80, después de que el NMT (“Nordic Mobile Telephone”), el sistema de telefonía móvil analógico de cobertura escandinava, tuviera éxito, los sistemas analógicos existentes, tenían limitaciones. Primera, ante la gran demanda de los servicios móviles, la capacidad de las redes analógicas existentes no era suficiente. Segunda, las diversas formas en las que opera este tipo de sistema no hacia posible una compatibilidad entre los usuarios de móviles, por ejemplo: una terminal TACS (servicio de telefonía móvil analógico puesto en funcionamiento en el Reino Unido en 1985) no podía acceder dentro de una red NMT, y viceversa. Además, el diseño de un nuevo sistema de telefonía celular requiere tal cantidad de investigación que ningún país europeo podía afrontarlo de forma individual. Todas estas circunstancias apuntaron hacia el diseño de un nuevo sistema, hecho en común entre varios países. El principal requisito previo para un sistema de radio común es el ancho de banda de radio. Esta condición había sido ya prevista unos pocos años antes, en 1978, cuando se decidió reservar la banda de frecuencia de 900 ± 25 MHz para comunicaciones móviles en Europa. Este problema fue el mayor obstáculo solucionado. Quedaba organizar el trabajo. El mundo de la telecomunicación en Europa siempre había estado regido por la estandarización. La CEPT ("Conférence Européene des Postes et Télécommunications") es una organización para la estandarización presente en más de 20 países europeos. Todos estos factores llevaron a la creación en 1982 de un nuevo cuerpo de estandarización dentro de la CEPT, cuya tarea era especificar un único sistema de radiocomunicaciones para Europa a 900 MHz. El recién nacido "Groupe Spécial Mobile" (GSM) tuvo su primer encuentro en Diciembre de 1982 en Estocolmo, bajo la presidencia de Thomas Haug de la administración sueca. Treinta y una personas de once países estuvieron presentes en este primer encuentro. En 1990, por requerimiento del Reino Unido, se añadió al grupo de estandarización la especificación de una versión de GSM a la banda de frecuencia de 1800 ± 75 MHz. A esta variante se le llamó DCS1800 ("Digital Cellular System 1800"). En los Estados Unidos, la FCC (Federal Communications Comission) decidió abrir partes de las frecuencia de los 1900 Mhz para usos móviles, con la elección del sistema por parte de las operadoras. El PCS1900 fue entonces desarrollado, una variante del GSM para aprovechar la oportunidad recién abierta en el mercado norteamericano (en el que la mayoría de las operadoras utiliza el CDMA). En Noviembre de 1995 el primer servicio PCS1900 fue lanzado en los Estados Unidos Americanos [6]. Actualmente los sistemas GSM900/1800/1900 son utilizados en 135 países, con 345 millones de utilizadores diseminados por 366 redes. El reciente lanzamiento de terminales tribanda (que operan en la frecuencia 900, 1800 y 1900 Mhz) posibilita capacidades de

14

roaming cada vez mayores, ya que los usuarios pueden utilizar las tres frecuencias disponibles en los cinco continentes. El significado actual de las siglas GSM ha cambiado y en la actualidad corresponden a "Global System for Mobile communications" �7�. 2.2.- Arquitectura de la red GSM El Sistema Global para Comunicaciones Móviles (GSM) posee una serie de características que lo diferencian dentro del universo de las comunicaciones móviles. Nacido en los años 80 fruto de una cooperación sin precedentes en Europa, el sistema comparte elementos comunes con otras tecnologías utilizadas en la telefonía móvil, como la transmisión digital de voz y datos y la utilización de células. A continuación se explican las características técnicas fundamentales del sistema, así como sus capacidades. Una red GSM está constituida por los siguientes tres elementos: la terminal, la estación-base (BSS) y el subsistema de red o nodo. Adicionalmente existen centros de operación establecidos por las operadoras, para vigilar el estado de la red. La estación móvil o terminal contiene la tarjeta del Módulo de Identificación de Suscriptor (SIM,”Subscriber Identity Module”), que es utilizada para identificar el usuario dentro de la red. El SIM confiere movilidad personal al usuario de la tarjeta, permitiéndole acceder a los servicios de la red independientemente del teléfono móvil que use o de su localización. El SIM puede ser protegido contra uso indebido a través de un código llamado número de identificación personal (PIN, “personal identity number”) que hay que marcar cada vez que se conecta el móvil con el SIM insertado. Existe además un número que identifica cada terminal individualmente, el International Mobile Susbcriber Identity (IMEI), pero que es independiente del SIM. La estación-base controla la conexión de radio entre el teléfono celular y la red y es también conocida por célula, ya que cubre una determinada área geográfica. Un subsistema de estación base (BSS,” base station subsystem”) está compuesta por dos elementos: la estación transrecibidora de base (BTS,”Base Transceiver Station”) y la estación base de control (BSC,” Base Station Controler”). Cada BSS puede tener una o más BTS. Las BTS albergan el equipo de transmisión / recepción (los TRX o transceivers) y gestionan los protocolos de radio con la terminal móvil. En las áreas urbanas existen más BTS que en zonas rurales y en algunos casos en lugares con características físicas o geográficas particulares (como por ejemplo, en túneles) son colocados retransmisores para garantizar el servicio. Cada estación utiliza técnicas digitales para permitir que varios usuarios se liguen a la red, así como para permitir que hagan y reciban llamadas simultáneamente. Esta gestión se denomina de multiplexado. El BSC administra los recursos de radio de una o más BTS. Entre sus funciones se incluyen el “handoff” (que ocurre cuando el utilizador se mueve de una célula para otra, permitiendo que la conexión se mantenga), el establecimiento de los canales de radio utilizados y los cambios de frecuencias. Finalmente, establece la conexión entre el teléfono celular y la Central Intercambiadora de Servicios Móviles (MSC, “Mobile Service Switching Center”), el corazón del sistema GSM.

15

Figura 2.1. Arquitectura de la red GSM

El MSC, como ya fue referido, es el centro de la red, a través del cual se realiza la conexión entre una llamada realizada desde un teléfono celular hacía las otras redes fijas como las Redes Telefónicas Analógicas Pública (PSTN, “Public Switched Telephone Network”), las redes Digitales de Servicios Integrados (ISDN, “Integrated Services Digital Network”) o las redes móviles. El nodo en el que se encuentra, posee además una serie de equipos destinados a controlar varias funciones, como el cobro del servicio, la seguridad y el envío de mensajes SMS. El�Registro de Localización de Llamada (HLR, “Home Location Register”) contiene toda la información administrativa sobre el cliente del servicio y la localización actual de la terminal. Es a través del HLR que la red verifica si un teléfono celular que se intenta ligar

BTS

BSC

BTS

SIM

MS

TRX

Estación Móvil (Terminal)

HLR

MSC

VLR

SIM SMSC EIR

Estación Base Subsistema de Conmutación y red

PSTN/ISDN

Otros MSC’s

�� !�"�� #��#�� $��%��!�" ��&��& �%�� &��%��'(��'�)�� (��(��%��'�� &�� & �%��&��% �� $�� *+��* ��+ �� #��#�� + ��%�,��+%�� (�� ( �� %%��( �� %��&�(��& �%��)��#�(��(��%� �� &��%��-+��-�� + �� #��#�� + ��%�,��%�-�� .�� #��.�#��%�� .�#��%�� #�� /��/%��)��%�") �� %�$��'��%�#��/0%��&�(��) ��&��#��(��(��%��&��1��( ��

16

posee un contrato de servicio válido. Si la respuesta es afirmativa el MSC envía un mensaje de vuelta a la terminal informándole que está autorizado a utilizar la red. El nombre de la operadora aparece entonces en pantalla, informando que puede efectuar y recibir llamadas. Cuando el MSC recibe una llamada destinada a un móvil, él va al HLR para verificar la localización. Paralelamente, la terminal de vez en cuando envía un mensaje para la red, para informarla del sitio donde se encuentra (este proceso es denominado poleo). El�Registro de Localización del Visitante (VLR, “Visitor Location Register”) es utilizado para controlar el tipo de conexiones que una terminal puede hacer. Por ejemplo, si un usuario posee restricciones en las llamadas internacionales, el VLR impide que estas sean hechas, bloqueándolas y enviando un mensaje de vuelta al teléfono celular informando al usuario. El Registro de Identificación del Equipo (EIR, “Equipment Identity Register”) y la Central de Autenticación (AC, “Authentication Center”) son utilizados para garantizar la seguridad del sistema. El EIR posee una lista de IMEI de terminales que han sido declaradas como robadas o que no son compatibles con la red GSM. Si el teléfono celular está en esa lista negra, el EIR no permite que se conecte a la red. Dentro del AC hay una copia del código de seguridad del SIM. Cuando ocurre la autorización, el AC genera un número aleatorio que es enviado al teléfono celular. Los dos aparatos, de seguida, utilizan ese número, junto al código del SIM y un algoritmo de encriptación denominado A3, para crear otro número que es enviado de nuevo para el AC. Si el número enviado por la terminal es igual al calculado por el AC, el usuario es autorizado a usar la red. La central de mensajes cortos SMSC (Short Message System Center) es responsable de generar los mensajes cortos de texto. Otros equipos utilizados en redes GSM pueden adjuntar el recaudo de llamadas, la conexión a Internet, la caja de mensajes de voz, etc. La explicación sobre las bases de datos definidas por GSM así como también la estructura del canal de Radio, la arquitectura del protocolo se da en el apéndice 1. Características de GSM El sistema GSM posee una serie de funcionalidades, que pueden ser implementadas por los operadores en sus redes. Entre estas características se incluyen: -La posibilidad de usar la terminal y la tarjeta SIM en redes GSM de otros países (roaming). -El servicio de mensajes cortos (SMS) a través del que pueden ser enviadas y recibidos mensajes con hasta 126 caracteres. -El reenvío de llamadas a otro número. -La transmisión y recepción de datos y fax con velocidades de hasta 9.6 Kbps. -La difusión celular – mensajes con hasta 93 caracteres que pueden ser enviados a todos los teléfonos celulares en un área geográfica. Los mensajes son recibidos cuando la terminal no está siendo utilizada y pueden ser recibidos cada dos minutos.

17

-CLIP (Calling Line Identification Presentation) – permite ver en pantalla el número que nos está llamando. Por oposición, el CLIR (Calling Line Identification Restriction) impide que el número llamante sea visto por alguien (anónimo) gracias al CLIP. -La posibilidad de visualización de crédito / costos. -La notificación de llamadas en espera, cuando estamos hablando por teléfono. -La posibilidad de colocar una llamada en espera, mientras se contesta otra. -Las llamadas son encriptadas, lo que impide que sean escuchadas por otros. -La posibilidad de impedir la recepción / transmisión de ciertas llamadas. -Las llamadas de emergencia -La posibilidad de varios usuarios hablar entre sí al mismo tiempo – servicio de conferencia [8].

18

Capitulo 3 Servicios de Mensajes Cortos (SMS)

El papel de las compañías operadoras de telefonía celular ha sido muy importante en esta expansión de las comunicaciones, y han tratado y tratan de amortizar sus inversiones mediante la oferta de diferentes servicios que inciten al usuario a hacer uso de estas comunicaciones.

3.1.- Estructura de SMS

Uno de los servicios ofertados por estas operadoras en los teléfonos celulares de tecnología GSM es el envío y recepción de mensajes cortos, los conocidos SMS.

En el estándar GSM hay especificados dos tipos diferentes de SMS:

• SMS “Point to Point” (SMS/PP). • SMS “Cell Broadcast” (SMS/CB).

El primer tipo permite enviar un mensaje de texto de un teléfono GSM a otro, mientras SMS/CB permite enviar uno o más mensajes contemporáneamente (broadcast) a todos los teléfonos que estén dentro de una determinada zona de cobertura de una o más emisores de señal de radio. El CB puede contener un máximo de 93 caracteres, pero es posible enlazar hasta 15 mensajes para formar un macro-mensaje. A cada mensaje CB se le asigna una categoría que permite clasificar el tipo de información que contiene y el idioma empleado, de modo tal que permita a los teléfonos celulares visualizar selectivamente o de descartar los mensajes CB.

El SMS se denomina protocolo sin conexión, de hecho, cuando se transmite no se produce ninguna conexión entre el terminal que envía y el que recibe, como sucede, por ejemplo, en el caso de las llamadas de voz, datos o fax.

El envío de un SMS/PP desde un teléfono GSM a otro tiene que ser considerado como la concatenación de dos operaciones diferentes: la transmisión del mensaje desde el teléfono celular a una entidad especial de la red, llamada SMSC (Short Message Service Center), y luego desde el SMSC hasta el teléfono celular receptor. La primera operación se denomina SMS-MO (SMS Mobile Originated), mientras que la segunda se conoce como SMS-MT (SMS Mobile terminated):

• SMS-MT permite recibir al usuario mensajes de texto con hasta 160 caracteres en la pantalla del propio teléfono celular GSM

• SMS-MO permite al abonado enviar mensajes de texto con hasta 160 caracteres a otra terminal GSM, a un fax o a una dirección de correo electrónico en Internet [9].

19

Los mensajes SMS son herederos directos de los mensajes de los equipos localizadores de personas, los llamados “buscas”, pero extendiendo su funcionalidad para permitir que desde cualquier dispositivo GSM se pueda realizar un envío a otro equipo sin mediar comunicación vocal con un teleoperador.

El éxito de este servicio, el SMS, parece provenir de la sencillez y facilidad de manejo, por un lado, y de que “hay alguien al otro lado” con quien realizar el acto de la comunicación. Estos dos factores han provocado dicho éxito, aún teniendo en contra el precio del servicio en algunos casos y las limitadas características de esta comunicación.

3.2.- Funcionamiento de SMS

Las posibilidades de comunicación mediante “mensajes cortos GSM” (SMS) son muchas y muy variadas, pero siempre limitadas por las características de estos mensajes, 160 caracteres, muy baja velocidad (en comparación con las líneas telefónicas convencionales), duración limitada (24 ó 48 horas normalmente, sino se entregan antes son cancelados), no es un servicio garantizado (el mensaje suele llegar pero no hay garantía de ello, ni que lleguen en el orden en que se han enviado) y posibilidad de comunicación sólo entre teléfonos celulares GSM entre los que haya “visibilidad” (que los operadores de los dos teléfonos, emisor y receptor, tengan convenio de intercambio de mensajes).

Existen muchas especificaciones de formato de mensaje para los servicios prestados a través de SMS que les dotan de gran potencia y complejidad. Pero es en el uso básico con un sistema de enlace sencillo donde se están obteniendo los mejores resultados, tanto de cantidad de mensajes enviados como de servicios que se están utilizando.

En todo caso, estas posibilidades resultan suficientes aprovechadas de forma adecuada, y una de esas formas es tener uno de los lados de la comunicación gobernado por un servicio automático que se encargue de responder a las peticiones recibidas desde múltiples teléfonos celulares. La automatización de la recepción de los mensajes SMS, su procesado y posterior respuesta es lo que conforma la funcionalidad de una pasarela SMS, ver Fig. 3.1.

20

Figura 3.1: Esquema general de una pasarela SMS

El acceso a la red GSM se puede obtener de diferentes formas. El método más sencillo es utilizando directamente una terminal GSM conectada a la computadora que actúa de pasarela. En realidad este terminal puede ser un teléfono GSM normal con su kit de conexión a PC (cable y software) o un MODEM GSM (igual que los módems convencionales de red telefónica básica –RTB- pero su medio de transmisión es la red GSM, no el par de hilos telefónicos).

La comunicación entre el ordenador y la terminal se suele realizar por un puerto de comunicaciones serie. Casi todos los teléfonos celulares actuales incluyen un MODEM GSM en su interior, de manera que la forma de comunicar ordenador y teléfono/MODEM GSM es la misma que con un MODEM de RTB convencional, es decir, comandos AT. Si el teléfono celular no incluye un MODEM GSM en su interior, es necesario comunicar con el teléfono celular utilizando las especificaciones del protocolo que el fabricante haya utilizado (normalmente se trata de protocolos propietarios, aunque cada vez menos). En GNU/Linux podemos utilizar el proyecto que trata de implementar el paquete de software Nokia Data Suite para la comunicación con estos teléfonos que implementan un protocolo propietario de Nokia.

El otro método más habitual para acceder a la red GSM es contactar directamente con un centro servidor de mensajes (SMSC) del operador de telefonía. Los SMSC de cada fabricante incorporan también protocolos propietarios, por lo que es necesario realizar en cada caso un dialogo diferente con cada tipo de SMSC, además de que el medio de conexión también puede variar de unos a otros (IP, Frame Relay, X.25, RDSI, etc.).

Una vez comprendido el funcionamiento básico de una pasarela de mensajería SMS, nos centraremos en la unión de las redes GSM, en un lado de la pasarela, e IP, en el otro, dada su gran extensión y su uso común en todos los tipos de sistemas informáticos [10].

21

Aplicaciones de una pasarela de mensajería SMS

Los posibles usos que se pueden dar a una pasarela SMS entre las redes GSM e IP son extensas.

Tenemos la siguiente lista como ejemplo de actividades que se realizan en la actualidad con este tipo de pasarelas de mensajería:

• Correo electrónico. La pasarela convierte un mensaje de correo en SMS y un mensaje SMS en mensaje de correo, con las consiguientes generaciones/eliminaciones de cabeceras de mensaje.

• Distribución de mensajes SMS. Al igual que funcionan las listas de correo electrónico, en las que un mensaje es reenviado a lo suscriptores de la lista, en la lista de distribución de mensajes SMS la pasarela permite el mantenimiento (alta/baja/consulta) de suscriptores y envía al resto de suscriptores de la lista los mensajes que no son comandos de actuación sobre la propia pasarela.

• Recepción de alarmas de los sistemas de monitorización de servicios. Aplicaciones como “mon”, “heartbeat”, agentes “snmp”, etc. Generan avisos cuando se alcanzan ciertos eventos. Estos avisos pueden ser encaminados mediante mensaje SMS dependiendo de su importancia, para que ciertas personas sean avisadas inmediatamente.

• Transporte de contenidos Web. El SMS es utilizado como paquete de transporte para hacer llegar desde el teléfono celular al servidor la petición de una página Web y desde el servidor al teléfono Celular el contenido de dicha página una vez “filtrada” para eliminar imágenes, tags html, cabeceras de página, etc.

• Concursos de preguntas y respuestas. Ante una solicitud desde el teléfono celular para comenzar el concurso, la pasarela envía mensajes con preguntas, recibe respuestas y mantiene un contador de resultados para cada participante, de manera que se pueden generar clasificaciones.

• Sistemas de seguimiento de flotas de vehículos. Un teléfono celular unido a un módulo GPS permite enviar información acerca de la posición exacta del portador del teléfono, de manera que para flotas de vehículos se reciben sus notificaciones de posición en la pasarela y ésta actualiza una base de datos consultable por otras aplicaciones que pueden mostrar la situación de cada elemento de la flota.

• Notificación de estado de dispositivos aislados. Dispositivos de control de temperatura y presencia, etc. Que se encuentren aislados y sin comunicación con una red mediante enlace físico pueden hacer uso de los mensajes SMS para recibir ordenes y para notificar de su estado (queda poca bebida, la temperatura ha superado los 45 grados, etc.). Normalmente esta comunicación se realiza sin intervención manual, por lo que realmente se conectan equipos automáticos en ambos lados. Además, de inmediato, a cada persona le surgen nuevas aplicaciones, orientadas a su área de conocimiento:

• Consulta de bases de datos. • Mantenimiento de sistemas. Consultas de estado de servicios, reinicio de los

mismos, reinicio de equipos. • Notificación de informaciones académicas. Notas, convocatorias de examen, etc.

22

• Banca GSM. Servicios financieros y alarmas para el seguimiento de operaciones de valores.

• Cualquier otro tipo de alarmas debido a caídas de tensión, detección de intrusos en “firewalls”, etc.

• Domótica. Control y consulta de dispositivos a distancia. • Avisos de intervención para equipos médicos, mantenimiento, rescate, etc.

Dadas las características de la red GSM que permiten la movilidad a los terminales (teléfonos) en su zona de cobertura, su pueden imaginar aplicaciones que aprovechen la posibilidad de localización de un teléfono, en base a la estación base de la red que en ese momento tiene conexión con él. Sin embargo, esta información no es directamente accesible desde el exterior de la red del operador de telefonía, por lo que, salvo aplicaciones fuertemente integradas con la red del operador, no es posible su utilización.

Podríamos imaginar una aplicación que permitiera emitir mensajes SMS a teléfonos celulares entre las dos y las tres de la tarde en la zona de cobertura de una estación base situada junto a un restaurante que contratara los servicios de publicidad que un operador pudiera ofrecer, para que todos los que por allí cerca pasaran supieran donde está dicho restaurante. Al margen de la aplicación, podrían surgir problemas con la utilización de la posición de las terminales para operaciones no solicitadas por el propietario de la terminal, ya que al fin y al cabo, la situación de cada terminal es información privada del propietario.

De cualquier manera, la pasarela de mensajería sólo trata de servir de intermediario y facilitar la labor de desarrollo de las extensiones móviles para una aplicación dada.

La pasarela de mensajería SMS/IP trata de ser como un servidor Web, realiza sus tareas de cambio de formato y ajuste del mensaje, pero precisa de contenidos que realmente le den una utilidad, aunque en este caso los contenidos son pequeñas o grandes aplicaciones que permiten interactuar al usuario móvil con otro programa.

También tiene un comportamiento similar al de un Agente de Transferencia de Mensajes de correo (MTA) ya que, de alguna forma, ésa también es su tarea: el encolado, conmutado y entrega de mensajes.

Para finalizar con las utilidades de las pasarelas de mensajería SMS/IP, podemos añadir que no hay un estándar para que las aplicaciones se comuniquen con las pasarelas, en general, sino que cada una define su propia interfaz, que es diferente en todos los casos. En este aspecto queda mucho camino por recorrer para, quizás, definir un “wrapper”, una interfaz intermedia, normalizada, que permita la utilización de diferentes pasarelas SMS sin necesidad de realizar cambios en la aplicación2�

23

3.3.- Servicio de Mensajes Multimedia (MMS)

La Mensajería Multimedia (MMS) es un servicio de mensajes para el entorno móvil normalizado por el foro WAP2 “Wireless Application Protocol” y por el Proyecto de colaboración en Tercera Generación (3GPP). Al igual que el tradicional servicio de mensajes cortos (SMS), la mensajería multimedia permite el envío automático e inmediato de mensajes personales. No obstante, a diferencia del SMS, MMS permite a los usuarios de teléfonos celulares mejorar sus mensajes incorporando sonido, imágenes y otros contenidos, transformando su mensaje en un mensaje visual y de audio personalizado.

MMS resulta muy similar al servicio de mensajes cortos (SMS) y, al igual que éste, requiere su propia interfaz. Técnicamente no utiliza WAP, ya que se trata de una aplicación de mensajería y no de navegación.

Pero la tecnología MMS ofrece algo más que la simple ampliación del contenido de los mensajes. Con MMS, no sólo es posible enviar mensajes multimedia de un teléfono a otro, sino también de un teléfono a correo electrónico y viceversa. Esta función aumenta de forma espectacular las posibilidades de la comunicación móvil, tanto para uso privado como profesional [11].

Los principales fabricantes apuestan a que MMS evolucionará rápidamente para convertirse en un auténtico servicio de alto consumo, tanto para el uso personal como profesional.

Es previsible que los usuarios se adapten fácilmente a MMS, ya que este sistema se puede reconocer como una forma avanzada de SMS. De este modo, MMS se convierte en un sólido eslabón para el paso de comunicaciones de 2G a 3G

Compatibilidad

La norma MMS incluye JPEG, GIF, texto, voz AMR y otros formatos como tipos de soportes admitidos, mientras que los formatos no admitidos se administran de forma controlada. Al igual que SMS, MMS constituye una norma industrial abierta y los mensajes MMS se pueden enviar utilizando las redes y protocolos existentes. MMS también es independiente del portador, lo que significa que no se limita exclusivamente a redes GSM o WCDMA3.

2 Una especificación segura que permite a los usuarios accesar información de manera instantánea a través de dispositivos portátiles sin cable como teléfonos celulares o radios de dos vías 3 WCDMA. Wide Band Code Division Multiple Acces, Acceso múltiple por división de código del ancho de banda

24

Capitulo 4

Control del Robot

4.1.- Antecedentes del Robot

La palabra robot se empleó por primera vez en 1920 en una obra de teatro llamada “R.U.R.” o “Los Robots Universales de Rossum” escrita por el dramaturgo checo �aren Capek. La trama era sencilla: el hombre fabrica un robot, luego el robot mata al hombre. Muchas películas han seguido mostrando a los robots como máquinas dañinas y amenazadoras [12].

Ahora veamos lo que es un robot. Los expertos en Robótica afirmarían que es complicado dar una definición. Por lo cual existen varias definiciones de las cuales se presentan algunas:

1. Ingenio mecánico controlado electrónicamente, capaz de moverse y ejecutar de forma automática acciones diversas, siguiendo un programa establecido.

2. Máquina que en apariencia o comportamiento imita a las personas o a sus acciones como, por ejemplo, en el movimiento de sus extremidades.

3. Un robot es una máquina que hace algo automáticamente en respuesta a su entorno.

4. Un robot es un puñado de motores controlados por un programa de computadora.

5. Un robot es una computadora con músculos.

La introducción de los microprocesadores desde los años 70 ha hecho posible que la tecnología de los robots haya sufrido grandes avances, las modernas computadoras han ofrecido un “cerebro” a los músculos de los robots mecánicos. Ha sido esta fusión de electrónica y mecánica la que ha hecho posible al robot moderno. El término mecatrónica se usa para describir la fusión de la electrónica y la mecánica. El año 1980 fue llamado “primer año de la era robótica” porque la producción de robots industriales aumentó ese año un 80 % respecto del año anterior. Con respecto a la historia de cómo surgen los robots tenemos las siguientes generaciones: Primera y Segunda Generación En estas generaciones los cambios en robótica suceden tan rápido que ya se ha pasado de unos robots relativamente primitivos a principios de los años 70, a una segunda generación. La primera generación de robots era reprogramable, de tipo brazo, dispositivos manipuladores que sólo podían memorizar movimientos repetitivos, asistidos por sensores internos que les ayudan a realizar sus movimientos con precisión. La segunda generación de robots entra en escena a finales de los años 70, tienen sensores externos (tacto y visión por lo general) que dan al robot información (realimentación) del mundo exterior. Estos

25

robots pueden hacer elecciones limitadas o tomar decisiones y reaccionar ante el entorno de trabajo, se les conoce como robots adaptativos. Tercera Generación La tercera generación acaba de surgir, está surgiendo en estos años, emplean la inteligencia artificial (IA) y hacen uso de las computadoras más avanzadas de las que se puede disponer en la actualidad. Estás computadoras no sólo trabajan con números, sino que también trabajan con los propios programas, hacen razonamientos lógicos y aprenden. La IA permite a las computadoras resolver problemas inteligentemente e interpretar información compleja procedente de sensores avanzados. Tendencias futuras Durante años los robots han sido considerados útiles sólo si se empleaban como manipuladores industriales. Recientemente han irrumpido varios roles nuevos para los robots. A diferencia de los tradicionales robots fijos de manipulación y fabricación, estos nuevos robots móviles pueden realizar tareas en un gran número de entornos distintos. A estos robots no industriales se les conoce como robots de servicios. Los robots de servicios proporcionan muchas funciones de utilidad, se emplean para el ocio, la educación, fines de bienestar personal y social. Por ejemplo, hay prototipos que recorren los pasillos de los hospitales y cárceles para servir alimentos, otros navegan en oficinas para repartir el correo a los empleados. Los robots de servicios son idealmente adecuados al trabajo en áreas demasiado peligrosas para la vida humana y a explorar lugares anteriormente prohibidos a los seres humanos. Han probado ser valiosos en situaciones de alto riesgo como en la desactivación de bombas y en entornos contaminados radioactiva y químicamente. Este crecimiento revolucionario en el empleo de robots como dispositivos prácticos es un indicador de que los robots desempeñarán un importante papel en el futuro. Los robots del futuro podrán relevar al hombre en múltiples tipos de trabajo físico. Joseph Engelberg, padre de la robótica industrial, está investigando en una especie de robot mayordomo o sirviente doméstico. Se piensa que los robots están en ese momento crítico antes de la explosión del mercado, como lo estuvieron las PC’s en 1975. El campo de la robótica se desbordará cuando los robots sean de dominio público, esta revolución exigirá que la gente de la era de la información no sea “analfabeta robótica”. Existen diferentes tipos de robots entre los cuales tenemos los siguientes: Androides Una visión ampliamente compartida es que todos los robots son “androides”. Los androides son artilugios que se parecen y actúan como seres humanos. Los robots de hoy en día vienen en todas las formas y tamaños, pero a excepción de los robots que aparecen en las ferias y espectáculos, no se parecen a las personas y por tanto no son androides.

26

Actualmente, los androides reales sólo existen en la imaginación y en las películas de ficción. Móviles Los robots móviles están provistos de patas, ruedas u orugas que los capacitan para desplazarse de acuerdo su programación. Elaboran la información que reciben a través de sus propios sistemas de sensores y se emplean en determinado tipo de instalaciones industriales, sobre todo para el transporte de mercancías en cadenas de producción y almacenes. También se utilizan robots de este tipo para la investigación en lugares de difícil acceso o muy distantes, como es el caso de la exploración espacial y las investigaciones o rescates submarinos. Médicos Los robots médicos son, fundamentalmente, prótesis para disminuidos físicos que se adaptan al cuerpo y están dotados de potentes sistemas de mando. Con ellos se logra igualar con precisión los movimientos y funciones de los órganos o extremidades que suplen. Industriales Los robots industriales son artilugios mecánicos y electrónicos destinados a realizar de forma automática determinados procesos de fabricación o manipulación. También reciben el nombre de robots algunos electrodomésticos capaces de realizar varias operaciones distintas de forma simultánea o consecutiva, sin necesidad de intervención humana, como los también llamados «procesadores», que trocean los alimentos y los someten a las oportunas operaciones de cocción hasta elaborar un plato completo a partir de la simple introducción de los productos básicos. Los robots industriales, en la actualidad, son con mucho los más frecuentemente encontrados. Japón y Estados Unidos lideran la fabricación y consumo de robots industriales siendo Japón el número uno. Es curioso ver cómo estos dos países han definido al robot industrial: La Asociación Japonesa de Robótica Industrial (JIRA) dice: Los robots son “dispositivos capaces de moverse de modo flexible análogo al que poseen los organismos vivos, con o sin funciones intelectuales, permitiendo operaciones en respuesta a las órdenes humanas”. El Instituto de Robótica de América (RIA) define: Un robot industrial es “un manipulador multifuncional y reprogramable diseñado para desplazar materiales, componentes, herramientas o dispositivos especializados por medio de movimientos programados variables con el fin de realizar tareas diversas”. Teleoperadores Hay muchos “parientes de los robots” que no encajan exactamente en la definición precisa. Un ejemplo son los teleoperadores. Dependiendo de cómo se defina un robot, los teleoperadores pueden o no clasificarse como robots. Los teleoperadores se controlan remotamente por un operador humano. Cuando pueden ser considerados robots se les llama

27

“telerobots”. Cualquiera que sea su clase, los teleoperadores son generalmente muy sofisticados y extremadamente útiles en entornos peligrosos tales como residuos químicos y desactivación de bombas [13]. 4.2 Características del Robot El simulador del robot utilizado en este proyecto cuenta con las siguientes características:

• 16 sensores • Cámara • Entrada serial

El robot simulado es el Pioneer 2D [14]. 4.3.-Simuladores del robot Como el sistema de simulación de GSM va interactuar con el simulador del robot, en este capítulo se da una breve explicación de las principales características de algunos de los simuladores disponibles y que se analizaron para poder seleccionar el simulador de robot a utilizar, entre ellos tenemos algunos que a continuación mencionamos. 4.3.1.- Simulador SAPHIRA Saphira [36] es una arquitectura para control de robots móviles. Originalmente ésta fue desarrollada para la investigación del robot Flakey en SRI internacional y después estuvo en uso por diez años. Fue desarrollada dentro de una arquitectura que soportaba una gran variedad de investigación y programación de aplicaciones para robots móviles. Saphira y Flakey aparecieron en 1994. El sistema Saphira está dividido en dos partes. Las rutinas de bajo nivel han sido reorganizadas y reimplementadas como un sistema de software separado, Aria. Es diseñado y mantenido por Activmedia Robotics. Este es un sistema de nivel de producción para el control del robot, basado sobre un extenso conjunto de clases de C ++. La estructura de clases Aria hace fácil expandir y desarrollar nuevos programas: añadir nuevos sensores al sistema. El sistema Saphira/Aria puede ser pensado como dos arquitecturas, una construida sobre la otra. La arquitectura del sistema implementada enteramente en Aria es un conjunto integrado de rutinas para comunicación y control con el robot desde el servidor en una computadora. La arquitectura del sistema es diseñada para ser fácil la definición de aplicaciones del robot para la conexión con programas de tipo cliente. Debido a esto, la arquitectura del sistema es una arquitectura abierta a los usuarios que desean escribir su propio sistema de control del robot pero no quieren preocuparse acerca de las complejidades del control de hardware y la comunicación puede ser una ventaja de las propiedades micro-tarea y reflexión de estado de la arquitectura del sistema.

28

Las rutinas del sistema de arriba es una arquitectura del control de robot, que es un diseño para controlar robots móviles que solventan algunos de los problemas envueltos en la navegación. 4.3.2 Simulador Stage Player Player [37] fue originalmente desarrollado por Brian Gerkey y Kasper Stoy, la interfaz del simulador Stage fue originalmente escrita por Richard T. Vaughan y Andrew Howard, el desarrollo de Player es administrado por Brian Gerkey, Andrew Howard, y Richard T.Vaughan. Player es primeramente desarrollado en los laboratorios “Research Robotics” de la universidad de “Southem in California”. Player es software libre, es un servidor multi-hilo de dispositivos del robot, éste da un simple y completo control sobre los sensores físicos y acciones sobre el robot móvil. Cuando Player está ejecutándose sobre el robot, el programa de control cliente se conecta a Player por medio de un socket de TCP, la comunicación se realizará enviando y recibiendo algunos de los comandos de un pequeño conjunto de mensajes simples. Player está diseñado para ser un lenguaje y una plataforma independiente. El programa cliente puede ejecutarse sobre cualquier máquina que tenga conectividad de red para el robot, y el programa cliente puede ser escrito en cualquier lenguaje que pueda abrir y controlar un socket TCP. Las características del cliente están actualmente disponibles en C, C++, TCL, LISP, Java, y Pitón. Player está también diseñado para soportar virtualmente cualquier número de clientes 4.3.3 Simulador Java Mobile Robots (JMR) Con respecto al simulador JMR [38] es de una arquitectura tipo cliente servidor la cual puede soportar varios robots, esto quiere decir que puede simular que está controlando varios robots, estos robots los identifica con un nombre, también puede cargar procesos sobre algún robot que se elija, puede conectarse con el simulador Saphira para poder tener comunicación con un robot real. En el cliente se manejan los dispositivos tales como sonares, cámaras de los robots que se tengan añadidos, así como también puede regular la velocidad y ver la distancia del robot con respecto a los obstáculos, otro aspecto más es que podemos ver el estado del robot ya sea que esté parado, avanzando, que haya chocado con algún obstáculo, etc. También le podemos enviar la distancia que queremos que avance, al igual que los grados que queremos que gire. En el servidor se reciben los comandos que le envía el cliente y los simula, en éste también se pueden cargar mundos que es por donde va a ir navegando el robot, así como también las imágenes que capta la cámara del robot, las cuales son enviadas al cliente y mostradas. En el servidor también se puede seleccionar que robot queremos ver.

29

Esta es una breve explicación del funcionamiento del simulador JMR, un análisis más a fondo se hace en el capítulo 5.

30

Capitulo 5 Simulador Java Mobile Robots (JMR) JMR (Java Mobile Robots) [38] es un entorno Java para simulación de robots, que permite estudiar el comportamiento de uno o varios robots sobre un mundo o entorno definido. 5.1.- Características del simulador JMR El sistema dispone de una aplicación cliente, sobre la que se cargan los robots que se desean probar, y de una aplicación servidor que se encarga de llevar un control de los robots conectados, actualizar su situación en el mundo que se haya especificado, y proporcionar al cliente los datos que se soliciten. Se persigue con este entorno dos objetivos fundamentales: Uno es definir una interfaz de comunicación de Java con la librería Saphira de control de robots. De este modo, se podrá conectar el sistema al simulador de robots de Saphira (Pioneer), y también a los robots reales que se gestionen con dicha librería. Conviene resaltar aquí la modificabilidad y modularidad que permite Java, y que haría posible la adaptación del programa a otras librerías de control de robots. El otro objetivo que se persigue es proporcionar un sistema propio de simulación, fácilmente portable, que permita sencillas modificaciones o actualizaciones del mismo. La estructura de Java permite definir un esqueleto básico sobre el que ir modificando o ampliando características de forma sencilla, añadiendo nuevas clases que extiendan o sobrescriban a las anteriores. De esta forma, además de la comunicación con Saphira, se dispone de un sistema auto-integrado, que permite la prueba de robots y procesos sobre el mismo sin necesidad de ningún programa adicional, mediante un simulador 3D propio. Por todo lo anterior, se ha desarrollado un programa cliente-servidor que permite la gestión de robots, así como algunas librerías auxiliares, algunas de las cuales son utilizadas por dichos programas, y otras facilitan la elaboración de procesos en los robots por parte del usuario. La arquitectura de este simulador es de cliente-servidor la cual se explica enseguida. 5.2.- Funcionamiento del simulador JMR Debido a la arquitectura de este simulador, como se ha mencionado, cuenta con un cliente y un servidor, su funcionamiento a grandes rasgos se explica a continuación. Aplicación cliente El paquete jmr.client contiene la aplicación cliente del sistema. En la parte cliente se tiene un programa para gestionar los distintos robots que queremos conectar. El programa está preparado para soportar varios robots simultáneamente (aunque si se está comunicando con Saphira, sólo se permitirá uno, por las limitaciones de Saphira), y se conseguiría con ello el mismo efecto que lanzando varias aplicaciones cliente, una por cada robot. El cliente dispone de controles para elegir a qué servidor conectarse (actualmente, al simulador Java, al simulador Saphira, o a un robot real a través de Saphira por un puerto

31

serie dado), indicando la dirección donde se encuentra el servidor. Esto permite comunicar mediante RMI (Remote Method Invocation, Invocación de Método Remoto) con un servidor situado en una máquina remota, conociendo su dirección IP y el puerto por el que comunicarse, y también comunicar, si se permite, con un servidor en la máquina local, sin necesidad de indicar dirección IP ni puerto. Además, se permite añadir y quitar robots del cliente, y llevar un control de los datos de cada robot (lecturas de sónares, estado actual, dispositivos, etc.). El servidor. En la parte del servidor, se distingue entre los servidores que se tienen: El simulador 3D JAVA El simulador 3D Java está contenido en el paquete jmr.simulator, y cuenta con un programa que permite monitorizar la situación del mundo que se haya elegido, mediante distintas cámaras que permiten tener una visión global del mundo o particular de cada uno de los robots que haya en él en cada momento. Además, cuenta con métodos para obtener los datos de cada robot en cada instante: detección de colisiones con obstáculos mediante cálculo de intersecciones, toma de lecturas de los sónares, captura de imágenes mediante un dispositivo de tipo cámara, y toma de otros datos de interés, como pueden ser estimaciones de posición mediante otro tipo de dispositivos, filtrado o procesado de imágenes, etc. El servidor SAPHIRA Dentro del servidor Saphira, contenido en el paquete jmr.saphira, se engloban tanto la conexión con el simulador Pioneer como la conexión con un robot real a través de un puerto serie utilizando Saphira. Este tipo de servidor no dispone de ninguna aplicación visual de monitorización, sino simplemente de un programa que se deja ejecutando y permite la comunicación con Saphira. Para la comunicación con Saphira, se emplea JNI (Java Native Interface), una utilidad de Java que permite incorporar al código Java fragmentos de código escritos en otros lenguajes de programación, como C. Así, se definen en una librería un conjunto de funciones escritas en C que interactuarán con Saphira, y desde Java se define el puente para poder llamar a las funciones de dicha librería. Se ha minimizado en la medida de lo posible la parte de tratamiento del robot que hace Saphira, dejando únicamente el reflector de estado, del que tomar los datos del robot, y utilizando algunas funciones para tomar datos y establecer velocidades. Lo que se pretende es dejar que se gestionen todas las estructuras desde Java, y utilizar la API de Saphira para obtener los datos y enviar los comandos básicos de movimiento (velocidad lineal y rotacional) al robot. Las nuevas versiones de Saphira son versiones de pago, aunque se ha desarrollado una librería, llamada ARIA, que es de libre distribución, y permite comunicar con los robots.

32

El programa de configuración. El paquete jmr.conf contiene una pequeña aplicación que permite definir opciones de configuración de distintos módulos de JMR: parámetros de configuración del simulador 3D, del cliente, etc. Debemos ejecutar esta aplicación si queremos modificar estos parámetros antes de ejecutar JMR. Control del robot. Para el control del robot, se tiene definido el paquete jmr.robots, con distintas clases que permitirán almacenar datos y llevar un control del comportamiento (influencia de los procesos en el estado final del robot, procesamiento de imágenes, gestión de dispositivos, etc.) del robot. El robot. El objeto robot propiamente dicho viene dado por una interfaz que define una serie de métodos que debe implementar todo robot, como son el envío de comandos de velocidad, envío de otros comandos algo más complejos como avanzar una distancia o girar un determinado ángulo, toma de datos como el estado, los parámetros, las lecturas de los sonares, etc. También se tienen definidas rutinas estándar para establecer la conexión entre cliente y servidor. Partiendo de esta estructura básica, cada simulador (Java y Saphira) la adaptará a sus propias necesidades, definiendo el código de cada uno de los métodos propuestos en la estructura. Para el caso de Saphira, se definen unas llamadas en código nativo C para poder interactuar con Saphira, y como se ha comentado anteriormente, JNI (Java Native Interface) es la herramienta Java que se ha utilizado para comunicar el código Java con las llamadas a las funciones C. Datos del robot. Se tienen los datos del robot repartidos en tres elementos: estado del robot, parámetros del robot y sónares del robot, si bien estos dos últimos están muy relacionados. Para gestionar el estado del robot se tiene definida una clase que almacena información como la posición y orientación del robot, velocidad lineal y rotacional, estado de la batería, y alguna otra información relevante. Esta información se caracteriza por variar con el tiempo, y presumiblemente podrá ser distinta cada vez que se tomen datos del robot. Por parámetros del robot entendemos datos estáticos que definen las dimensiones, datos internos de trabajo, rangos, etc., del robot, es decir, sus características. Aquí encontramos datos como los factores de conversión que emplea para las unidades de velocidad, lectura de sonares, etc., el rango de velocidades (lineales y rotacionales) entre los que puede moverse, el número de sonares, la disposición de los mismos, etc. Finalmente, se define otra clase para guardar las lecturas de sonares que vaya tomando el robot. Para cada lectura, se tomará información detallada sobre la distancia tomada, coordenadas de la lectura, un contador que servirá para distinguir lecturas ya leídas de las

33

no leídas, etc. Este dato está muy relacionado con los parámetros del robot porque se encuadra dentro de dicha estructura de datos: junto al número de sonares y la disposición de los mismos, se almacenan las lecturas de cada uno (aunque sí sean datos dinámicos). Control sobre los procesos en el robot. Para poder gestionar la influencia de los procesos que se estén ejecutando en el robot, se tiene definido un manejador que se encarga de agrupar los distintos procesos que hay en ejecución sobre un robot, evaluar las prioridades y otros factores a considerar y generar una respuesta que determinará el nuevo estado en que se encuentre el robot (en realidad, determinará qué velocidad lineal y rotacional asignar al robot en función de los resultados ponderados de los procesos). En cuanto a los procesos, se distinguen dos tipos principales de procesos: actividades y conductas. Las primeras fundamentalmente producen comandos directos sobre el robot (se le envían comandos directos de movimiento), aunque también se pueden emplear para combinar procesos, y otras tareas. Las conductas definen sobre unas variables locales qué velocidades se quieren asignar al robot, y luego es el manejador quien se encarga de ponderar los resultados de todas las conductas y producir una respuesta global y única. Se podrán definir conductas y actividades de muy diversos tipos, empleando lógica difusa, razonamiento probabilístico, etc. Se permite que un proceso pueda llamar a otros procesos, y así poder definir procesos más elaborados mediante módulos simples, como por ejemplo, dirigirse hacia un punto evitando obstáculos, que podría estar compuesta por la conducta “dirigirse a un punto” y la conducta “evitar obstáculos”. También se deja la posibilidad de que el usuario implemente su propio manejador de robot, que defina su propia política de control de procesos y de generación de comandos globales para el robot en función de los mismos, sin más que extender de la clase manejador genérica. Visión Se tiene un módulo dedicado a tratar el problema del procesado de imágenes en el robot. Se definen en él estructuras de datos que permitan al servidor enviar al cliente información sobre la imagen que está viendo en cada momento el robot, y se han definido las estructuras de determinados métodos que se emplearán para procesar y obtener imágenes. Además, se ha definido un puente que comunica las imágenes que puedan captarse y procesarse con la herramienta JavaVis desarrollada en el Departamento de Ciencia de la Computación e Inteligencia Artificial de la Universidad de Alicante, de modo que se pueden emplear los diversos filtros y funciones que se han desarrollado para dicha librería, y aplicarlos para procesar imágenes en el servidor y enviarlas al cliente.

34

Dispositivos. Puede ser útil (e incluso necesario) tener la posibilidad de definir dispositivos sobre el robot, elementos que actúen en el servidor, procesando determinados datos, y proporcionando mecanismos para que el cliente pueda adquirir dichos datos procesados. Un ejemplo puede ser la cámara que pueda tener el robot. Conviene disponer de un mecanismo que permita definir la cámara, y poder visualizar así en el cliente las imágenes que capture el robot. Pero no sólo se trata de dispositivos físicos, como puedan ser una cámara, una pinza, o cualquier otro elemento, sino también dispositivos lógicos, como fragmentos de código que preprocesen información en el servidor para ponerla a disposición del cliente cuando lo requiera. Por ejemplo, aplicar un algoritmo para determinar en qué posición puede estar el robot, o un procesado de imágenes que también permita especular sobre dicha posición mediante razonamiento probabilístico. Librerías auxiliares. Se han implementado una serie de librerías que, bien serán utilizadas por las aplicaciones para algunas tareas auxiliares, bien permitirán al usuario definir procesos y programas Java de forma sencilla. A continuación se comentan brevemente. Librería para desarrollo de entornos gráficos: robotGUI La librería jmr.robotGUI se ha desarrollado para facilitar la elaboración de aplicaciones visuales como el propio cliente. Dispone de una serie de controles específicos que puedan resultar interesantes para el control de robots (formados a base de controles Java Swing agrupados), tales como paneles de imágenes, listas de parámetros, etc. Se ha empleado esta misma librería para construir la propia aplicación cliente, de forma que también puede servir de ejemplo de uso para construir otras aplicaciones similares. Librería geométrica: javaGL La librería jmr.javaGL contiene una serie de elementos geométricos que facilitan el tratamiento de objetos del mundo en que se mueve el robot, así como del propio robot. Dispone de objetos tales como líneas, segmentos, círculos, puntos, posiciones, que permiten definir, entre otras cosas, los límites de los muros del mundo, las dimensiones del robot, la posición del mismo, etc. Se emplea sobre todo en la parte del simulador Java para obtener aproximaciones 2D del mundo 3D que se tiene representado, mantener listas de segmentos para obtener intersecciones (y ver con ellas si el robot ha colisionado, o determinar las lecturas de los sonares, etc), definir posiciones, y otras funcionalidades. Librería de lógica difusa: fuzzy La librería jmr.fuzzy contiene un conjunto de clases que permiten emplear lógica difusa en el comportamiento del robot, así como en otras tareas que se quieran realizar. Dispone de elementos para poder definir variables difusas, conjuntos difusos, elaborar reglas difusas

35

que obtengan una serie de consecuentes a partir de unas entradas determinadas para sus antecedentes, etc. Internamente, se ha empleado la librería fuzzyJ del NRC (National Research Council of Canada), que incorpora una serie de clases que contienen parte del código que se busca tener. Se ha adaptado todo de forma que dispone de una librería propia, que se vale de algunas funciones y clases de fuzzyJ para determinadas tareas, permitiendo así poder prescindir de dicha librería en caso de considerarlo oportuno, y de ampliar los contenidos de la misma con nuevas funcionalidades, sin la merma que supondría actuar sobre dicha librería directamente. Con esta librería se pueden definir conductas difusas, basadas en reglas de cuyo cumplimiento dependerá el establecimiento de determinados parámetros como son, sobre todo, la velocidad lineal y rotacional del robot. Librería probabilística: prob La librería jmr.prob se ha definido para mantener, además de una librería para control mediante lógica difusa, una librería que permite el control mediante razonamiento probabilístico. Además, proporciona ayuda a la hora de realizar determinadas tareas, como generación de datos aleatorios siguiendo una determinada distribución de probabilidades, etc. Así, se han definido una serie de distribuciones de probabilidad conocidas y frecuentemente empleadas, como son la distribución normal, la distribución de Poisson, y otras. También se ha dado pie a que el usuario pueda definir sus propias distribuciones de probabilidad, tanto discretas como continuas, dejando simplemente el esqueleto que debe cumplir toda distribución. Además, se tiene implementada una versión genérica del algoritmo CONDENSATION (CONditional DENSity propagATION), un algoritmo que permite realizar estimaciones sobre diversas características (posición del robot, reconocimiento de imágenes, etc), mediante la disposición de un conjunto de muestras en el espacio objeto de estudio, y la evaluación de la probabilidad de cada muestra. Con este algoritmo genérico, se podrán especificar variantes concretas que actúen sobre un tema específico, como por ejemplo localizar un robot en un pasillo, evaluar la posición del robot en función de la imagen que capta, etc. Librería de cargadores de ficheros: loaders La librería jmr.loaders es una librería auxiliar empleada para procesar los distintos tipos de ficheros externos que se utilizan: ficheros de parámetros de robots, de descripciones de mundos, de configuración, etc, y almacenar la información de los mismos en las estructuras de datos pertinentes. Los ficheros de parámetros son los mismos que los que emplea Saphira, añadiendo algunas palabras clave más como comentarios de Saphira, de modo que en el simulador incorporan más datos sobre los parámetros, y en Saphira son ignoradas, pero el fichero puede leerse. Podremos así, por ejemplo, en los mundos del simulador 3D, añadir luces, texturas, etc.

36

Directorios del usuario. Fuera del núcleo de JMR, se tienen otros directorios o paquetes para que el usuario añada funcionalidades:

• El paquete “process”, para añadir procesos que queramos cargar en robots • El paquete “devices”, para añadir dispositivos que queramos cargar en robots • El paquete “vision”, para añadir procesadores de imágenes para las imágenes que

capturen las cámaras de los robots. Estructura general de JMR. El directorio principal de JMR tiene la siguiente estructura:

• Colgando directamente de dicho directorio se encuentran los ficheros de configuración, DLLs y ficheros de copyright y README sobre la aplicación.

• Todo el código fuente del núcleo de JMR se encuentra en el directorio /src/, en la carpeta del paquete principal /jmr/, a partir del cual se tienen los distintos subpaquetes:

o Aplicación cliente: jmr.client o Simulador 3D: jmr.simulator o Servidor Saphira: jmr.saphira o Aplicación de configuración: jmr.conf o Librería de programación de robots: jmr.robots o Librerías auxiliares: jmr.robotGUI, jmr.javaGL, jmr.fuzzy, jmr.prob,

jmr.loaders.

• Además, se tienen algunas clases externas y paquetes que puede modificar el usuario, en los directorios:

o process: para definir procesos que queramos ejecutar sobre los robots o devices: para definir dispositivos que queramos cargar sobre los robots o vision: para definir clases que permitan manipular imágenes tomadas de las

cámaras de los robots. • En el directorio /params/ van los ficheros de parámetros de robots que se quieran

utilizar. • En el directorio /World/ van los distintos mundos que queramos cargar. • El directorio /conf/ contiene algunos ficheros de texto con configuración sobre el

programa. • El directorio /lib/ contiene los ficheros JAR que utiliza JMR como librerías externas • El directorio /images/ contiene algunas imágenes empleadas por las aplicaciones. • El directorio /apps/ es un directorio auxiliar para programas de prueba del usuario. • El directorio /clases/ contiene los ficheros compilados de todos los archivos fuentes

de JMR (subdivididos en paquetes).

37

Funcionamiento general. Para la comunicación de ambas aplicaciones (cliente y servidor), se ha empleado la tecnología RMI (Remote Method Invocation), una tecnología Java que permite ejecutar remotamente comandos de otra máquina, y permitir así la comunicación en sistemas distribuidos. Por una parte, se tiene al servidor que se ha elegido (Java o Saphira), ejecutándose en una máquina. Dicho servidor está escuchando por un puerto determinado, a la espera de solicitudes de conexión de distintos clientes. Por otra parte, se tiene cada uno de los clientes que se quieren lanzar, que pueden estar en la misma máquina que el servidor o en máquinas distintas. En el cliente, se indica la dirección en la que se encuentra el servidor, y los robots que se generen se conectarán con dicha dirección. Podríamos también tener distintos robots conectados a distintos servidores, dentro de un mismo cliente. Se establece así una conexión por cada robot que se añada en la aplicación cliente, que será gestionada de forma independiente. Una vez establecida la conexión, el cliente podrá solicitar datos del robot al servidor ejecutando comandos remotos en el mismo (toma de lecturas de sónares, toma del estado actual, establecimiento de la velocidad del robot, etc). Además, se permite la conexión con un servidor local, sin necesidad de utilizar una dirección IP y puerto, en el caso de que ambos se ejecuten en la misma máquina y no queramos emplear RMI. Ahora veamos la interfaz del simulador JMR. Iniciaremos con la aplicación cliente, ver fig. 5.1

Figura 5.1: interfaz de la aplicación cliente

Zona de control de lista de robots

Zona de parámetros de conexión

Zona de datos del robot

Zona de elementos

añadidos al robot

38

La interfaz de la aplicación cliente es la mostrada en la figura 5.1 la cual contiene lo siguiente:

• Zona de parámetros de conexión • Zona de control de la lista de robots • Zona de datos del robot • Zona de elementos añadidos al robot

La aplicación cliente interactúa con el simulador 3D de java el cual es el encargado de simular el robot y el mundo por donde navega el robot. El cual es el mostrado en la figura 5.2.

Figura 5.2 Cámara de robot y de usuario Para una descripción más a detalle de cada uno de los elementos que componen a cada zona y sobre la cámara del robot puede consultar el apéndice 1 manual de usuario de JMR [38].

39

Capitulo 6 Sistema de Simulación del Control de un robot móvil a través de GSM (SimGSM) Una parte importante en el desarrollo de sistemas es llevar acabo una serie de pasos para poder comprender lo que el usuario quiere que realice el sistema, así como también para que el programador pueda diseñar e implementar el sistema y para que cualquier programador pueda entender su organización. Otro aspecto importante es que el sistema tenga una buena organización para poder evitar errores que puedan conllevar al mal funcionamiento del sistema o a la insatisfacción del usuario. Para llevar acabo la realización de este sistema hicimos uso del lenguaje unificado de modelado (UML) [15] el cual prescribe un conjunto de notaciones y diagramas para modelar sistemas orientados a objetos y describe la semántica esencial de lo que estos diagramas y símbolos significan. UML se puede usar para modelar distintos tipos de sistemas de software, sistemas de hardware y organización del mundo real. 6.1.-Planteamiento del sistema SimGSM. SimGSM consiste en simular un teléfono celular, una central telefónica y de servicio de mensajes cortos, un MODEM GSM y la comunicación entre ellos, cabe mencionar que el sistema simula sólo la comunicación en una célula, ésto implica que sólo hay una central de servicio de mensajes cortos y que el MODEM GSM, y el celular (SimCelular) están dentro de ésta. El funcionamiento del SimGSM es como se muestra en la figura 6.1.

Figura 6.1: Esquema general del sistema SimGSM. La comunicación es de dos maneras por tonos o por mensajes cortos (SMS). Con respecto a la comunicación por tonos ésta se hace de la siguiente manera:

GSM

Central de Servicio de Mensajes Cortos y Central Telefónica (SMSCYCT)

MODEM Robot

40

Desde el simulador del teléfono celular se marca un número telefónico el cual es enviado a la central telefónica para que ésta establezca o rechace la comunicación con el MODEM GSM. Establecida la comunicación con el MODEM GSM del robot, se empieza a introducir el comando, el comando es enviado al MODEM es decir el MODEM reconoce el tono generado de la tecla oprimida, una vez completado el comando, el verificador de comandos (VeriComando) toma el comando y verifica si el comando es válido. El verificador de comandos envía al simulador del robot (SimRobot) los comandos que sean validos. Ya que la comunicación es por tonos entonces VeriComando se comunica con el MODEM GSM para que el MODEM envíe los siguientes mensajes:

1. Conexión aceptada. 2. Conexión rechazada. 3. Comando ejecutado con éxito. 4. Robot colisionó. 5. Robot atascado. 6. Robot moviéndose.

Las cadenas de caracteres establecidas para la definición de los comandos son las siguientes:

1. ** indica que es el inicio o fin del comando. 2. #**cm. indica que el robot debe avanzar los centímetros indicados. 3. #*#grad indica que el robot debe girar los grados indicados.

Por ejemplo si queremos que el robot se mueva 20cm. La cadena del comando sería de la siguiente manera: inicio – avanza20cm - fin ** #**20 ** De modo similar si queremos que el robot gire 90º tendríamos: Inicio – gira90º - fin ** #*#90 ** Así serian los comandos que se emplearían para la comunicación. Con respecto a la comunicación por mensajes cortos se tiene lo siguiente: Desde el simulador del teléfono celular se debe acceder al menú o la tecla que nos sirva para poder escribir un mensaje corto, que para este caso es un comando, así como también introducir el número a quien se le va a enviar dicho mensaje y pulsar enviar. Este mensaje se envía al centro de servicio de mensajes cortos y posteriormente éste lo envía al MODEM GSM, el mensaje que se reciba se pasa al verificador de comandos. En caso de no ser un comando válido el verificador de comandos debe construir un mensaje corto y enviarlo al MODEM GSM para que posteriormente el MODEM GSM envíe el mensaje a la central de servicio de mensajes cortos y posteriormente a SimCelular notificando que el comando es inválido.

41

En el caso de la comunicación por mensajes cortos la forma del comando a enviar será igual a la estructura de un mensaje corto. Cuando el comando enviado se ha verificado y es válido entonces se pasa al robot para la ejecución de dicho comando. El primer paso que se hace es verificar el estado del robot. El cual tiene los siguientes estados:

� Collision: El robot ha colisionado. � Moving: El robot se mueve. � Stopped: El robot esta encendido, con los motores encendidos, pero detenido

sin moverse. � No motors: El robot esta conectado, pero con los motores apagados. � Disconnected: El robot esta desconectado del servidor.

En los estados de “No motors”, “Disconnected” no se puede ejecutar el comando y se informa del error, en el caso de que el estado del robot sea “Collision” solo se puede ejecutar comandos de girar pero no de mover y cuando el estado del robot sea “Stopped” se puede ejecutar cualquier comando. Al ejecutar el comando el simulador del robot señala la ubicación del robot en el mundo como lo muestra la figura 6.2

Figura 6.2: Ubicación del robot en el mundo El robot cuenta con una cámara para ir captando imágenes del mundo por donde esta caminando la cual es presentada en la figura 6.3. Cabe mencionar que la imagen de la cámara del robot es enviada a la aplicación cliente.

42

Figura 6.3: Cámara del robot El simulador 3D nos permite ver las dos cámaras, es decir, la cámara del robot y la cámara de usuario las cuales son presentadas en la figura 6.4

Figura 6.4: Cámara de robot y usuario 6.2.- Proceso de Modelado del sistema SimGSM. A continuación veamos el proceso de modelado del sistema SimGSM el cual tiene las siguientes fases:

• Análisis • Diseño • Implementación • Pruebas

La fase de Análisis comprende los siguientes diagramas de UML

• Diagrama de Casos de uso • Diagrama de clases

Para la fase de Diseño se tienen los siguientes diagramas de UML

• Diagrama de clases (a detalle). • Diagrama de secuencia. • Diagrama de interacción.

43

• Diagrama de estado. • Diagrama de actividades

Para la Implementación se dispone del siguiente diagrama de UML • Diagrama de componentes.

Y por último tenemos las Pruebas, para ello utilizaremos el método de caja negra. 6.2.1.- Modelo de Análisis. Con lo expuesto en el apartado del planteamiento del sistema SimGSM se identificaron dos casos en la que podemos establecer comunicación con el robot, los cuales son:

• Tonos • Mensajes cortos (SMS).

Para el diagrama de casos de uso tenemos los siguientes actores:

• SimCelular. • SimRobot.

Y los siguientes escenarios para el caso de comunicación por tonos: • Marcar. • Enviar tonos de comando. • Colgar.

Con los elementos citados anteriormente se elaboró el diagrama de casos de uso el cual es mostrado en la figura 6.2.1 la cual muestra el modelado para SimGSM cuando se ejecuta la comunicación por tonos.

Figura 6.2.1: Diagrama de casos de uso para el sistema SimGSM (Tonos). Los escenarios del diagrama de la figura 6.2.1 son descritos a continuación. Marcar.

1. SimCelular requiere comunicarse con el robot.

Marcar

Enviar comando

Colgar

SimRobot

SimCelular

44

2. SimCelular espera a que introduzcan un número (de 10 dígitos). Los diez dígitos corresponden al número telefónico sin el 044

3. Establecer la comunicación con el MODEM GSM del robot. Enviar Comando. Como la comunicación es por tonos entonces el comando es enviado carácter por carácter al MODEM GSM del robot, es decir, se genera un tono de la tecla oprimida el cual es el que recibe el MODEM GSM y el proceso es como sigue:

1. Introducción y envío de caracteres del comando (tonos). 2. El MODEM GSM recibe los caracteres del comando (tonos). 3. SimRobot solicita la información del comando al MODEM, hasta que se

complete el comando. 4. SimRobot verifica el comando y si es válido lo ejecuta. 5. SimRobot envía la información sobre el comando y el estado del robot.

Colgar. El usuario presiona la tecla colgar. Rompe la conexión. Para el diagrama de casos de uso en el caso de comunicación por tonos tenemos los siguientes escenarios.

• Introducir mensaje corto. • Enviar.

Ahora veamos el diagrama de casos de uso para el caso de mensajes cortos este diagrama es mostrado en la figura 6.2.2.

Figura 6.2.2: Diagrama de casos de uso para el sistema SimGSM (Mensajes Cortos). Los casos de uso de la figura 6.2.2 son descritos enseguida. Introducir mensaje corto.

1. SimCelular requiere comunicarse con el robot. 2. Introducir el comando y el número de destino.

Introducir mensaje corto

SimRobot

SimCelular Enviar

45

Enviar. 1. Pulsar enviar. 2. El mensaje se envía a la central de mensajes cortos para posteriormente ser enviada

al número destino, que para este caso es el número del MODEM GSM del robot. 3. SimRobot obtiene del MODEM el comando enviado. 4. SimRobot envía al MODEM GSM la información del comando y el estado del

robot en forma de mensaje corto para que el MODEM pueda enviarlo. 5. El mensaje llega a la central de servicio de mensajes cortos y éste lo envía a

SimCelular.

Una vez realizados los diagramas de casos de uso abordaremos los diagramas de clases teniendo en cuenta los requisitos mencionados en el diagrama de casos de uso. En primer lugar tenemos el diagrama de clases para el caso de comunicación por tonos. Las clases que se identificaron fueron las siguientes:

• El simulador del celular (SimCelular). • El simulador del MODEM GSM (SimModemGSM). • Control por celular (ControlCelular). • El simulador de la central de servicios de mensajes cortos y central

telefónica (SimSMSCyCT). La clase SimCelular es la que se encarga de simular alguna de las funciones del celular entre las cuales tenemos las siguientes:

• Marcar • Generar tonos • Colgar • Envío de mensajes cortos • Recibir mensajes cortos

Para lo cual se apoya de una clase llamada “recibir información” que es la encargada de recibir la información que sea enviada al simulador del celular. La clase SimMODEMGSM se encarga de simular la función de recibir comandos ya sea en forma de mensaje corto o de tonos así como también el envío de información del robot hacia el simulador del celular. La clase control por celular (ControlCelular) es la encargada de recibir los comandos enviados para posteriormente verificarlos y su posible ejecución. La clase SimSMSCYCT se encarga de simular a una central telefónica y a una de servicio de mensajes cortos. Que para el caso de comunicación por tonos se utiliza la central telefónica y para el de mensajes cortos la central de servicio de mensajes cortos, la cual tiene una subclase llamada “escuchar” la cual es encargada de la recepción de la información que llegue a ésta. El diagrama de la figura 6.2.3 muestra las clases identificadas.

46

Figura 6.2.3: Clases del sistema SimGSM comunicación por tonos.

La figura 6.2.4 muestra las subclases de SimCelular y SimSMSCyCT respectivamente.

Figura 6.2.4: Subclases de SimCelular y SimSMSCyCT.

Recibir información

Numori: String Numdestino: String

Informacion: String Numinter: String

-Recib información () -Separar información

Escuchar

Numori: String Numdestino: String Información: String Numinter: String -Escuchar () -Separar ()

SimCelular

Numero: String Mensaje: String

NumeroSMSC: String

-Marcar -Introducir comando -Recib información -colgar -Introducir mensaje corto

SimSMSCyCT

Numori: String Numdestino: String Información: String Numinter: String

-Conexión -Romper conexión -Envrob. -Envcel -Enviar Mensaje Corto.

SimModemGSM

Numero de procedencia: String Modo: char

-Conexión robot. -Enviar comando al robot. -Env resp comand. -Liberar conexión -Recibir mensaje

ControlCelular

Estarob: string Comando: string

-Verificar -Ejecutar -Enviar información

47

La clase SimCelular tiene los siguientes atributos: Número: este atributo guarda el número marcado por el usuario. Mensaje: es la información a transmitir. NúmeroSMSC: es el número que tiene la central. Métodos de la clase SimCelular

� Marcar: Este método se encarga de ir obteniendo el número que esta introduciendo el usuario así como también el de solicitar la conexión con la central telefónica.

� Introducir comando: una vez establecida la conexión con la central telefónica y el MODEM del robot, este método es el encargado de identificar el carácter introducido y enviarlo al MODEM GSM.

� Colgar: encargado de finalizar la conexión. � Recib información: es el encargado de recibir la información que llegue a

SimCelular la cual puede ser información acerca de l robot, información sobre la conexión y mensajes cortos.

� Introducir mensaje corto: es el método que permite al usuario introducir el mensaje y es el encargado de comunicarse con el SMSC para el envío de dicho mensaje.

Ahora veamos los atributos y métodos de la subclase de SimCelular (recibir información). Los atributos son los siguientes:

� Numori: Es el número de origen. � Numdestino: Es el número destino � Información: Es la información recibida � Numinter: Es el número intermedio por donde paso o pasara la

información. Los métodos son los siguientes:

� Recib información: es el encargado de recibir la información que llegue al simulador del celular.

� Separarinformacion(String): es el encargado de separar la información para posteriormente mostrarla

A continuación tenemos la clase SimSMSCyCT la cual tiene los siguientes atributos:

� Numori: Es el número de origen. � Numdestino: Es el número destino � Información: Es la información recibida � Numinter: Es el número intermedio por donde pasó o pasará la

información. Métodos de la clase SimSMSCyCT:

48

� Conexión: es el encargado de establecer la conexión con el simulador

del MODEM GSM. � Romper conexión: se encarga de terminar la conexión. � Envrob: Envía la información del Smscyct al MODEM del robot. � Envcel: Envía la información del Smscyct al simulador del celular. � Enviar mensaje corto: Es el que envía el mensaje al destino

especificado.

Enseguida se explican los atributos y métodos de la subclase de SimSMSCyCT:

� Numori: Es el número de origen. � Numdestino: Es el número destino � Información: Es la información recibida � Numinter: Es el número intermedio por donde pasó o pasará la

información. Los métodos son los siguientes

� Escuchar: es el encargado de recibirlas solicitudes. � Separar: es el encargado de separar la información

Posteriormente tenemos la clase SimModemGSM: Los atributos son los siguientes:

� Numori: Es el número de origen. � Numdestino: Es el número destino. � Información: Es la información recibida. � Numinter: Es el número intermedio por donde pasó o pasará la

información. Los métodos son los siguientes:

� Conexión robot: Es el encargado de establecer la conexión con el robot.

� Enviar comando al robot: es el encargado de enviar el comando al robot

� Env resp comand: Este envía la información relacionada con el comando y el robot.

� Liberar conexión: Es el encargado de liberar la conexión. � Recibir mensaje: Es el encargado de recibir los mensajes cortos

Los atributos de la clase ControlCelular son los siguientes:

� Comando: es el comando enviado. � Esta rob: es el estado del robot antes de ejecutar el comando

49

Los métodos de Control Celular

� Verificar: Es el encargado de verificar que el comando enviado es correcto

� Ejecutar: Es el que permite mandar al robot el comando a ejecutar � Enviar información: envía la información sobre el comando y el

estado del robot.

50

6.2.2.- Modelo de Diseño. Ahora veamos las relaciones entre clases, las cuales se muestran en la figura 6.2.5.

Figura 6.2.5 Relaciones entre clases Las relaciones mostradas en la figura 6.2.5 se explican a continuación La clase SimCelular se comunica con la clase SimSMSCyCT para que ésta pueda establecer la comunicación con el MODEM del robot (SimModemGSM) el cual se comunica con el control del robot a través del celular (ControlCelular) la cual es al encargada de verificar el comando así como también el de su ejecución y posteriormente la clase ControlCelular se comunica con el paquete SimRobot para la ejecución del comando y para obtener información del robot. La relación de las dos clases es la misma para los dos casos tonos y mensajes cortos. El paquete SimRobot mostrado en la figura 6.2.5 es el que nos proporciona la simulación del robot.

SimCelular


NumeroSMSC: String

-Marcar -Introducir comando -Recib información -Colgar -introducir mensaje corto

SimSMSCyCT

Numero de procedencia: String

-Conexión -Romper conexión -Envrob. -Envcel -Enviar mensaje corto

SimModemGSM


-Conexión robot. -Enviar comando al robot. -Env resp comand. -Liberar conexión -Recibir mensaje

SimRobot

ControlCelular



51

A continuación tenemos el diagrama de composición que es presentado en la figura 6.2.6:

Figura 6.2.6: Diagrama de Composición y de cardinalidad.

La figura 6.2.6 muestra el diagrama de composición y cardinalidad de las clases SimCelular y SimSMSCyCT. En la cual la clase SimCelular se compone de la subclase Recibir información la cual es el componente que le ayuda a recibir la información que llega a SimCelular y la clase SimSMSCyCT se compone de la subclase escuchar la cual es la que la ayuda a atender las solicitudes. La cual tiene una cardinalidad de uno a uno.

SimCelular


NumeroSMSC: String

-Introducir mensaje corto -Marcar -Introducir comando -Recib información -Colgar

SimSMSCyCT


-Enviar Mensaje Corto. -Conexión -Romper conexión -Envrob. -Envcel

Recibir información

Numori: String Numdestino: String

Informacion: String Numinter: String

-Recib información () -Separar información

Escuchar

Numori: String Numdestino: String Información: String Numinter: String Recib informacion () -Separar ()

1

1

1

1

52

6.2.7: Diagrama de composición y cardinalidad del paquete robot

El diagrama de la figura 6.2.7 presenta el diagrama de composición y de cardinalidad del paquete robot el cual tiene como componentes la clase SimModemGSM que es el simulador del MODEM GSM y la clase ControlCelular y la cardinalidad es de uno a uno. Para lograr el comportamiento del sistema SimGSM veamos la secuencia cronológica entre los objetos para ello nos ayudaremos del diagrama de secuencia. Ahora utilizando la información del diagrama de casos de usos haremos el diagrama de secuencia. Para el caso de la comunicación por tonos el Diagrama de Secuencia es mostrado en las figuras 6.2.8, 6.2.9 ,6.2.10.

SimModemGSM


-Recibir mensaje -Env inf del robot -Conexión robot. -Enviar comando al robot. -Liberar conexión

SimRobot

ControlCelular



1

1

1

1

53

Figura 6.2.8: Diagrama de Secuencia para el caso de uso marcar del caso comunicación por tonos. En la figura 6.2.8 se muestra el proceso de marcar para establecer la conexión, el cual se explica a continuación: El usuario invoca primero el método “Marcar” del objeto Celular, este método permite el ingreso de una serie de dígitos, posteriormente el objeto Celular invoca el método “Conexión” del objeto Smscyct, el cual verifica el número marcado y si el número introducido es del MODEM del robot, entonces genera una respuesta de “éxito” o de “fracaso” e invoca al método “Recib información” del objeto Celular. Si la respuesta es “éxito” entonces se intenta establecer la conexión con el MODEM del robot y éste envía una respuesta de éxito o fracaso de la conexión al objeto Smscyct el cual invoca el método recib información del objeto Celular. Si la respuesta es de éxito entonces queda establecida la conexión con el MODEM GSM del robot.

Figura 6.2.9: Diagrama de secuencia para el caso de uso introducir comando del caso comunicación por tonos. La figura 6.2.9 muestra el proceso de introducir comando el cual es el siguiente: El usuario introduce el comando en el objeto Celular y después el objeto Celular invoca el método “Enrov” del objeto Smscyct para el envío del mensaje. El objeto Smscyct invoca el método “Enviar comando al robot” del objeto MODEM y enseguida el objeto MODEM invoca el

Celular: SimCelular

MODEM: SimModemGSM

Robot: SimRobot

Envrob ()

Introducir comando

Recibir comando ()

Smscyct: SimSMSCyCT

Env inf del robot ()

Recib información ()

Enviar comando al robot ()

Envcel ()

Celular: SimCelular

MODEM: SimModemGSM

Robot: SimRobot

Conexión () Marcar

Smscyct: SimSMSCyCT


Conexión robot ()

Recib información () Recib información ()

54

método “Recibir comando” del objeto Robot. Hasta este punto el comando ha llegado al robot. Aquí es donde se utiliza el componente ControlCelular del paquete robot. En el cual se analiza la validez del comando, si el comando es válido entonces chequea/verifica el estado del robot y si el estado del robot es distinto a “colisión” entonces se podrá ejecutar cualquiera de los dos comandos ‘girar’ o ‘mover’, pero si el estado es colisión entonces solo se puede ejecutar el comando ‘girar’. Ya ejecutado el comando se informa al usuario sobre el resultado de la operación, es decir, sobre la validez del comando o el estado del robot. Para enviar la información del robot, el objeto Robot invoca el método “Env inf del robot” del objeto MODEM y a su vez éste invoca el método “Envcel” del objeto Smscyct para enviar el mensaje. El objeto Smscyct invoca el método “Recib información” del objeto Celular para recibir le información del robot.

Figura 6.2.10: Diagrama de secuencia para el caso de uso colgar del caso comunicación por tonos. La figura 6.2.10 muestra el proceso de colgar en el cual el usuario invoca el método “Colgar” del objeto Celular para terminar la comunicación y el objeto Smscyct invoca el método “liberar conexión” del objeto MODEM para liberar dicha conexión, el objeto MODEM invoca el método “Recib información” para enviar un mensaje de dicha operación así como también el objeto Smscyct invoca el método “Recib información” del objeto celular para recibir la respuesta de la operación. Ahora presentaremos el Diagrama de Secuencia para el caso de la comunicación por mensajes cortos el cual corresponde a la figura 6.2.11.

Celular: SimCelular

MODEM: SimModemGSM

Robot: SimRobot Robot:

Romper conexión () Colgar

Smsyct: SimSMSCyCT

Liberar conexión ()


Éxito o fracaso Recib información ()

Éxito o fracaso

55

Figura 6.2.11: Diagrama de Secuencia para el caso de envió de comandos por mensaje corto. En la figura 6.2.11 el usuario invoca el método “introducir mensaje corto” del objeto Celular, enseguida el objeto Celular invoca el método “Enviar mensaje corto” del objeto Smscyct y consecutivamente el objeto Smscyct invoca el método “Recibir mensaje” del objeto MODEM. En seguida el objeto MODEM invoca el método “Recibir comando” del objeto robot, el objeto robot invoca el método “Env inf de robot” del objeto MODEM, posteriormente el objeto MODEM invoca el método “Enviar Mensaje Corto” del objeto Smscyct y éste invoca el método “Recibir mensaje corto” del objeto Celular. Para poder modelar las interacciones entre objetos en el sistema construiremos el diagrama de colaboración. El diagrama de colaboración para el caso de comunicación por tonos se presenta en la figura 6.2.12.

Figura 6.2.12: Diagrama de colaboración para la comunicación por tonos.

Celular: SimCelular

MODEM: SimModemGSM

Robot: SimRobot

2: Establecer conexión

3: enviar comando al SMSCyCT

5: recibir comando

6: Env resp comand 8: recibir información

Smscyct: SMSCyCT

4: enviar comando al MODEM

7: enviar información al SMSCyCT

1: Marcar

Celular: SimCelular Smscyct: SimSMSCyCT MODEM: SimModemGSM

Enviar Mensaje Corto () Recibir mensaje ()


Recib informacion ()

Robot: SimRobot

Recibir comando ()

Enviar Mensaje Corto ()

Introducir mensaje corto 1

1

56

En el diagrama de la figura 6.2.12 el objeto Celular es el encargado de establecer la conexión con el MODEM del robot, posteriormente podemos enviar el comando. Cabe señalar que el comando se va enviando elemento a elemento, es decir, si queremos enviar el comando **#**1000** primero se envía el * y así sucesivamente hasta terminar de enviar el comando, el método “Recibir comando” es el encargado de recibir los elementos enviados del comando, el método “Env resp comand” se encarga de enviar la información sobre el robot al celular, el método “recibir información” recibe la información enviada por el MODEM A continuación la figura 6.2.13 representa el diagrama de colaboración para la comunicación por mensajes cortos.

Figura 6.2.13: Diagrama de Colaboración para la comunicación por mensajes cortos. En la figura 6.2.13 el proceso de envío de comandos por mensaje corto es el siguiente: Se introduce primero el comando y posteriormente se invoca el método “enviar mensaje corto” el cual requiere del número a quién se le va enviar el comando, este mensaje es enviado al SMSCyCT el cual verifica el número así como también si puede enviar el comando al destino indicado que, para este caso, debe de ser el número del MODEM. Si el número introducido es el del MODEM, entonces lo envía al MODEM, una vez que éste lo recibe lo pasa al robot, el cual lleva a cabo el proceso de verificar el comando y de si puede ejecutarlo. Una vez hecho dicho proceso envía la información al MODEM para que éste la envíe en forma de mensaje corto al SMSCyCT y posteriormente éste la envíe al celular. Ahora continuaremos con los diagramas de estado para los objetos:

• Celular • Smscyct • MODEM • Robot

Celular: SimCelular

MODEM: SimModemGSM

Robot: SimRobot Smscyct: SimSMSCyCT

2: enviar mensaje corto

3: Recibir mensaje

4: recibir comando

5: Env inf del robot

6: enviar mensaje

7: Recibir mensaje

1: Marcar

57

El diagrama de estados para el objeto Celular es mostrado en la figura 6.2.14

Figura 6.2.14: Diagrama de estados para el objeto Celular. La figura 6.2.14 muestra los estados del objeto Celular el cual comienza cuando se invoca el método marcar del objeto celular, posteriormente pasa a esperar respuesta sobre si se estableció la conexión. Si la conexión quedó establecida entonces se procede a la introducción y el envío de comandos o a colgar.

Figura 6.2.15: Diagrama de estados para el objeto Smscyct. La figura 6.2.15 muestra los estados del objeto Smscyct el cual está en espera de una conexión. El ser invocado dicho método identifica hacia donde va ir la información recibida. Cuando la información va a ir del celular al robot se invoca el método Envrob y cuando la información va ir del robot al celular se invoca el método Envcel.

Smscyct

Smscyct Conexión

Envrob

Envcel

Celular

Celular Marcar

Conexión

Introducir comando

Colgar

Recib informacion

Sin conexión

Romper conexión

58

Figura 6.2.16 Diagrama de estados para el objeto MODEM La figura 6.2.16 muestra el diagrama de estados para el objeto MODEM el cual está conectado con el robot. Cuando se invoca el método conexión robot el MODEM está en espera de una instrucción. Para identificar cual método invocar éstos pueden ser el de liberar conexión o el enviar comando al robot o enviar información. El método enviar información es cuando se envía la información del robot hacia el celular.

Figura 6.2.17: Diagrama de estados para el objeto robot. En la figura 6.2.17 se presenta el diagrama de estados para el simulador del robot. Inicialmente espera a que se agregue un robot. El simulador del robot espera recibir un comando, al recibir el comando este verifica el estado del robot y posteriormente lo ejecuta si fuera el caso. La ejecución depende del estado del robot. El diagrama de estados del robot es mostrado en la figura 6.2.18.

Figura 6.2.18: Diagrama de estados del robot

MOVING STOPPED add

Comando (girar, avanzar)

COLLISION

Comando (girar) Resultado del movimiento

Resultado del movimiento

Robot

add

Robot

Recibir comando

Robot

Verificar estado del robot

Robot

Ejecutar

MODEM MODEM

Conexión robot

Enviar comando al robot

Env inf robot

Liberar conexión

59

La figura 6.2.18 muestra los estados del robot. El simulador del robot soporta a varios robots pero para nuestro caso solo se utiliza un robot. Entonces lo primero que tenemos que hacer es agregarlo, una vez agregado el robot su estado inicial es de “STOPPED” enseguida espera por un comando el cual puede ser de avanzar o girar. A la hora del inicio de la ejecución del comando el estado del robot cambia a “MOVING”, el estado resultante de la ejecución del comando puede ser de “COLLISION”, este estado quiere decir que el robot a chocado con algún obstáculo; ó de “STOPPED”, esto quiere decir que el robot esta listo para ejecutar otro comando. Cuando el estado es de “COLLISION” el robot solo puede ejecutar comandos de girar.

Figura 6.2.19 Diagrama de estados para el objeto Celular (Mensajes Cortos). La figura 6.2.19 muestra el diagrama de estados para el objeto celular para el caso de mensajes cortos. Cuando se invoca el método introducir comando el objeto puede estar esperando por recibir algún mensaje sobre la información del comando enviado o puede enviar otro mensaje corto.

Figura 6.2.20: Diagrama de estados para el objeto Smscyct (Mensajes Cortos). En la figura 6.2.20 se muestra el diagrama de estados para el objeto Smscyct el cual al enviar el mensaje corto pasa nuevamente a esperar para poder enviar otro mensaje y así sucesivamente. Solo cerrando el programa se llega al estado final.

Smscyct

Enviar mensaje corto

Enviar mensaje corto

Cerrar programa

Celular Celular

Introducir mensaje corto

Establecer conexión

Celular Recibir mensaje corto

Celular

Enviar mensaje Colgar

Colgar

60

Figura 6.2.21: Diagrama de estados para el objeto MODEM (Mensajes cortos). Lo mostrado en la figura 6.2.21 es el diagrama de estados para el objeto MODEM en el caso de mensajes cortos el cual se describe a continuación. Se comienza cuando se invocan cualquiera de los siguientes métodos: el método recibir mensaje o el método Env inf de robot. El método recibir mensaje es invocado cuando llega el mensaje corto al MODEM y el método Env inf robot es cuando se requiere enviar al celular la información sobre el estado del robot, y volver a esperar una invocación de alguno de éstos métodos.

Figura 6.2.22: diagrama de estados para el objeto Robot (Mensajes Cortos). La figura 6.2.22 muestra el diagrama de estados para el objeto robot. Cuando el método recibir comando es invocado el objeto robot recibe el comando para su posterior verificación y ejecución de dicho comando. El estado del robot es mostrado en la figura 6.2.19. Diagrama de actividades: A continuación se muestra el diagrama de actividades

Robot

Recibir comando

Robot

Veri comando

Robot

Verificar estado del robot

Robot

Ejecutar

MODEM

MODEM

Recibir mensaje

Env inf de robot

Colgar

Colgar

61

Figura 6.2.23 Diagrama de actividades para el caso de uso marcar

Figura 6.2.24: Diagrama de actividades para el caso de uso introducir comando

Introducir comando

Envrob ()

Enviar comando al robot ()

Recib informacion

Envcel

SimCelular SimSMSCyCT

SimModemGSM

Recibir comando

Env inf del robot

Marcar

Conexión ()

Conexión robot () Recib informacion

Recib informacion

Recib informacion


SimModemGSM

62

Figura 6.2.25: Diagrama de actividades para el caso de uso colgar.

Figura 6.2.26: Diagrama de actividades para el caso de uso enviar mensaje corto

Introducir Mensaje Corto ()

Enviar mensaje ()

Recibir mensaje ()


Enviar mensaje ()


SimModemGSM

Recibir comando ()


Colgar

Romper conexión ()

Liberar conexión ()

Recib informacion

Recib informacion

SimCelular SimSMSCyCT SimModemGSM

63

La figura 6.2.23 muestra el diagrama de actividades para el caso de uso marcar el cual comienza con la invocación del método marcar, posteriormente se pasa a establecer la conexión con el robot y el envío de la respuesta de la conexión de la central y a continuación la respuesta de la conexión con el MODEM La figura 6.2.24 presenta el diagrama de actividades para el caso de uso introducir comando el cual se introduce el comando y se envía a la central. Posteriormente este lo envía al MODEM del robot, y éste lo envía al robot y finalmente se envía la información del estado del robot o del comando. La figura 6.2.25 nos muestra el diagrama de actividades para el caso de uso colgar. El usuario invoca el método colgar, el cual pasa esta solicitud a la central para que posteriormente ésta termine la conexión con el MODEM el cual envía la respuesta de la operación a la central y ésta la pasa al celular En la figura 6.2.26 aparece el diagrama de actividades para el caso de uso envío de mensajes cortos el cual comienza con la introducción del mensaje el cual es enviado a la SMSC para su posterior envío al MODEM y éste lo envíe al robot, una vez verificado el comando y posiblemente ejecutado se envía la información del robot y del comando en caso de no ser un comando valido.

64

6.2.3.- Modelo de Implementación. En la implementación ponemos en práctica el diseño, así como también la elección de la interfaz del sistema. El sistema se ejecuta en una sola computadora en la cual se ejecutan las clases ya implementadas del diseño. Para la implementación se utilizó el diagrama de componentes el cual es mostrado en la figura 6.2.27.

Figura 6.2.27: Diagrama de componentes. El componente mostrado en la figura 6.2.27 es el sistema SimGSM. A continuación veamos más a detalle dichos componente. El componente SimGSM se integra de lo siguiente:

• Clase SimCelular. • Clase SimSMSCyCT. • Clase SimModemGSM. • Paquete Simrobot

SimGSM

SimCelular


NumeroSMSC: String

-Introducir mensaje corto -Recibir mensaje corto -Marcar -Introducir comando -Resp conexión -Recib información -colgar

SimSMSCyCT


-Enviar Mensaje Corto. -Conexión -Romper conexión -Envrob. -Envcel

SimMODEMGSM


-Recibir mensaje -Recibir información -Conexión robot. -Enviar comando al robot. -Enviar información. -Liberar conexión

Simrobot

65

La clase SimCelular es la encargada de simular algunas de las funciones del teléfono celular. El paquete SimRobot consta de lo siguiente:

• Simulación del robot. • Clase SimModemGSM. • Clase ControlCelular.

El paquete Simrobot es el simulador JMR (Java Mobile Robot) el cual sólo tenía la función de simular el robot y para lo cual se le agregó la clase SimModemGSM y la clase ControlCelular, para simular que el robot está conectado a un MODEM GSM. El paquete de simulación del robot es el encargado de recibir los comandos que el verificador de comando identifique como válidos. La clase modemGSM es la encargada de simular al MODEM GSM del robot la cual se encarga de la comunicación entre el robot y la central telefónica o la central de servicios de mensajes cortos. La Clase ControlCelular es la encargada de verificar el comando así como también de informar sobre la validez o invalidez del comando, y verificar el estado del robot y de comunicarse con el simulador para la ejecución del comando. El software usado fue el simulador del robot JMR 2.0 (JAVA Mobile Robots) [36]. El software utilizado para la implementación del simulador fue JAVA 1.4.1, la plataforma en la que se ejecuta este simulador es en el sistema operativo “Windows XP Professional” y se ejecuta en una computadora con procesador Pentium III a 500Mhz y memoria de 256MB. A continuación veamos el funcionamiento del sistema. El sistema de simulación del control de un robot móvil a través de GSM (SimGSM) consta de tres módulos los cuales son las siguientes:

• SimCelular. • Smscyct. • Paquete de simulación del robot.

El paquete de simulación del robot consta de lo siguiente: • Simulador del robot JMR • MODEM GSM • Control celular

La interfaz de SimCelular es la mostrada en la figura 6.2.28

66

Comenzaremos con la parte de SimCelular para lo cual nos apoyaremos del siguiente ejemplo. El usuario desea controlar el robot para lo cual deberá seguir lo siguientes pasos:

• Marcar el número del MODEM. • Enviar comando. • Colgar.

Al poner en ejecución el modulo SimCelular tenemos lo siguiente:

� La interfaz de SimCelular la cual es mostrada en la figura 6.2.28 � Ejecución de recib información que es el encargado de recibir toda la

información que llegue al simulador del celular.

Figura 6.2.28 interfaz de SimCelular. Nota: El número del celular es el 2220000002, el de la central telefónica y la central de servicio de mensajes cortos es el 2220000000, y el número del MODEM del robot es el 2220000001. Cuando el usuario ha introducido el número deberá pulsar marcar, al pulsar marcar se procede a formar la siguiente estructura para la solicitud de conexión:

Que para el caso del ejemplo propuesto es el siguiente:

Numero origen Numero destino Numero CT $ $ Mensaje $

67

La cual contiene el número del celular, el número de destino que es el del MODEM, la solicitud de conexión y el número de la central telefónica. La estructura es enviada a la central telefónica, al recibir la central telefónica la solicitud de conexión ésta toma la información la cual tiene la estructura mencionada anteriormente e invoca un método para separarla y la cual queda de la siguiente manera:

� Número origen = 2220000002 � Número destino = 2220000001 � Mensaje = conexión. � Número de central = 2220000000.

Enseguida compara el número de destino con el número del MODEM, si es igual entonces establece la conexión con el MODEM y envía una respuesta de éxito, de no ser así envía una respuesta de fracaso al celular. Posteriormente la respuesta que envía la central telefónica al celular sobre si la conexión fue aceptada o rechazada (éxito o fracaso) tiene la siguiente estructura:

La cual se pasa al método para separar la información, el cual nos da el siguiente resultado.

� Número origen = 2220000000 � Número destino = 2220000002 � Mensaje = éxito � Número de central = 222000000.

Una vez establecido la conexión, el usuario empieza a introducir el comando el cual se va introduciendo carácter a carácter. La figura 6.2.29 muestra que la conexión fue aceptada. Por ejemplo veamos el comando **#**1000** Al enviar el primer carácter, éste se hace conforme a la estructura descrita anteriormente que para el ejemplo es la siguiente:

Esta información es enviada a la central la cual la recibe la separa y la encamina hacia el MODEM.

2220000002 2220000001 2220000000 $ $ $ *

2220000000 2220000002 2220000000 $ $ $ Éxito

2220000002 2220000001 2220000000 $ $ Conexión $

68

Figura 6.2.29: Conexión aceptada con el robot. Al llegar el comando al MODEM éste lo pasa al robot. Como al simulador del MODEM llega la información éste la separa y envía el mensaje al robot y se invoca el método para verificar si el comando es válido. Cabe mencionar que el paso de información es por medio de comandos AT. Como el comando está llegando al robot carácter a carácter entonces se va verificando carácter a carácter hasta que se complete el comando, la figura 6.2.30 muestra la recepción del comando. Si el comando es válido entonces verifica el estado del robot, si el estado del robot es el de colisión entonces identifica de que comando se trata, si es de avanzar o girar, si es de avanzar entonces el comando no se ejecuta pero si es de girar lo ejecuta. Si el estado es de

Conexión aceptada

69

movimiento espera a que termine de moverse y posteriormente ejecuta el comando verificando de nueva cuenta el estado del robot y si el estado es de parado entonces ejecuta el comando enviado, la ejecución del comando se presenta en al figura 6.2.31.

Figura 6.2.30: Recepción de comandos por medio de comunicación por tonos. La ejecución del comando es mostrada en la figura 6.2.31 la cual muestra la lectura de los sónares, el estado del robot, así como también los números telefónicos involucrados en la comunicación, el comando de mover y el comando enviado por el usuario. En la figura 6.2.32 se muestran la cámara de usuario y la cámara del robot, la cámara de usuario es como si fuera una cámara colocada en la parte de arriba para observar el mundo donde el robot va interactuar y la cámara del robot es la que tiene colocada el robot.

**#**1000

70

Figura 6.2.31: Ejecución del comando enviado.

Figura 6.2.32: Cámara del robot y cámara de usuario.

**#**1000** Mover

71

Posteriormente envía la información sobre el comando en caso de ser inválido, en caso contrario envía la información sobre el estado del robot de la siguiente manera:

La cual en información va el estado del robot o la palabra de invalido en caso de que el comando lo fuera. Esta información es pasada al MODEM para que la envíe a la central y posteriormente al celular. Por otra parte el celular está esperando la respuesta de la validez o invalidez del comando o la información sobre el estado del robot. Una vez recibida la respuesta se procede a enviar otro comando o a colgar. Para colgar se envía la información de la siguiente manera:

La cual es enviada a la central telefónica para liberar la conexión A continuación veamos el envío de comandos por medio de mensajes cortos El usuario envía un comando por medio de mensaje corto. El usuario introduce primero el comando como lo muestra la figura 6.2.33 y debe pulsar el botón de SMS, posteriormente se debe introducir el número a quien se le va a enviar el mensaje como lo muestra la figura 6.2.34 y pulsar el botón enviar.

Figura 6.2.33: Envío de comando por medio de mensajes cortos.

2220000002 2220000001 2220000000 $ $ $ Salir

2220000001 2220000002 2220000000 $ $ $ Información

**#**1000**

72

Figura 6.2.34: Introducir número. Al pulsar el botón de enviar se forma la siguiente estructura para ser enviada a la central de servicio de mensajes cortos

Primero tenemos el número que corresponde al número del celular, enseguida tenemos el número corresponde a la central de servicio de mensajes cortos, posteriormente el comando y finalmente el número del destinatario. Al llegar esta información al central se invoca al método que separa la estructura en lo siguiente:

� Número origen = 2220000002 � Número destino = 2220000000 � Mensaje = **#**1000** � Número de destinatario = 2220000001

2220000002 2220000000 2220000001 $ $ **#**1000** $

73

En este caso el número de destino es el de la central porque es donde se envía el mensaje, el número de destinatario es el número del MODEM. La figura 6.2.35 muestra la central telefónica para este caso.

Figura 6.2.35: Mensaje corto en la central telefónica Posteriormente se invoca el método que envía el mensaje al número indicado. El MODEM del robot recibe la información e invoca al método para separar la información y pasar el mensaje al robot. El robot recibe el mensaje (comando) e invoca el método para verificar el comando como el comando es válido para este caso entonces chequea el estado del robot para verificar si lo puede ejecutar, esto quiere decir que para poder ejecutar un comando de mover sólo se puede ejecutar si el robot no está en estado de colisión y un comando de girar se puede ejecutar sin importar el estado en el que se encuentre.

74

6.2.4.- Modelo de Pruebas y Resultados. Prueba 1 El objetivo de esta prueba es de determinar la respuesta del simulador cuando el número marcado es distinto al del MODEM Supongamos que el número marcado es el siguiente 2220000004. El número es enviado a la central telefónica y cuando llega a la central (Smscyct), ésta verifica si el número es valido y si puede establecer la comunicación con dicho número. Para el caso citado anteriormente no se podrá establecer la comunicación ya que este número no es conocido por la central telefónica. La figura 6.2.36 muestra el número marcado en el celular. La figura 6.2.37 muestra el número de quien marco, el número de destino, el mensaje que dice que el número es desconocido y que fue una solicitud de conexión.

Figura 6.2.36: Número marcado

75

Figura 6.2.37: Central telefónica Prueba 2. El usuario envía un mensaje pero el número de destino no es conocido por la central de servicios de mensajes cortos Primero introduciremos el comando y luego el número y posteriormente será enviado a la central de servicios de mensajes cortos de la siguiente manera:

2220000002$2220000000$**#**1000**$2220000001 La cual separa la información y hace las comparaciones de los números para reencaminar el mensaje pero como no lo conoce manda el siguiente mensaje al celular: “El número esta fuera de alcance” El cual es presentado en la figura 6.2.38.

76

Figura 6.2.38: el número esta fuera de alcance

77

Prueba 3 Cuando el comando enviado es incorrecto. El comando es introducido y enviado a la central y posteriormente la central lo envía al robot el cual lo verifica y envía el mensaje de comando incorrecto.

Figura: 6.2.39: El comando es incorrecto La figura 6.2.39 presenta el caso cuando el comando es incorrecto. Esto es para cuando la información es enviada por medio de mensajes cortos y para la comunicación por tonos es similar.

78

Capitulo 7 Interfaz entre simuladores. En este capitulo describiremos la interfaz de los simuladores SimGSM y JMR. Para un buen funcionamiento del sistema se debe ejecutar lo siguiente:

• El simulador del celular. • El simulador de la central de servicios de mensajes cortos y la central telefónica. • El simulador del Robot JMR.

7.1. SimGSM. El simulador de GSM consta de lo siguiente:

1. Un simulador de un teléfono celular: con el cual se emula el marcado de un número para el establecimiento de una llamada por tonos al igual que el envío de mensajes cortos.

2. Un simulador del centro de servicios de mensajes cortos y la central telefónica (SMSCyCT).

Se le asignó un número telefónico a la central de servicios de mensajes el cual es el 2220000000 e igualmente al simulador del teléfono celular el cual es 2220000002, el número asignado al MODEM es el 2220000001. La interfaz del simulador del teléfono celular se presenta en la figura 7.1

Figura 7.1: Interfaz del componente SimCelular.

79

Esta interfaz tiene las teclas de marcar y colgar además de la tecla de envío de mensajes cortos y las teclas que comúnmente tiene un teléfono celular. Para el marcado de un número sólo debemos dar clic en la tecla del número que se desee y una vez terminado la introducción del número procedemos a pulsar la tecla marcar. Por otro lado tenemos el simulador de la central de mensajes cortos y la central telefónica la cual tiene una interfaz como la mostrada en la figura 7.2.

Figura 7.2: Interfaz del componente SMSCyCT. En la figura 7.2 de la interfaz del componente SMSCyCT se muestra los números de los teléfonos entrante, intermedio, saliente y el mensaje en caso que se trate del envío de un mensaje corto. A la hora de pulsar marcar en el simulador del celular, éste se conecta con la central telefónica para verificar el número y posteriormente establecer la llamada. En este caso, como la central telefónica sólo puede establecer la llamada con el MODEM del robot sólo acepta el numero 2220000001. Si se marcara cualquier otro número entonces se escuchará un tono de ocupado y no se podrá establecer la comunicación. Esto es para la comunicación por tonos. Para la comunicación por mensajes cortos la central de mensajes cortos sólo conoce también el número 2220000001 que corresponde al MODEM del robot. En caso que se introduzca otro número de destino, la central telefónica respondería con un mensaje de que el número no existe. Una vez verificado que el número es correcto se establece la comunicación con el MODEM del robot por medio de tonos y podemos empezar a introducir los caracteres del comando.

80

7.2. Java Mobile Robots (JMR). La interfaz del simulador JMR es la mostrada en la figura 7.3:

Figura 7.3: Interfaz del cliente del simulador JMR La figura 7.3 muestra la interfaz del cliente del simulador JMR en la cual podemos añadir más robots así como también quitarlos. Para añadir un robot solo se pulsa en el botón “add” y se nos presenta un cuadro de diálogo como el mostrado en la figura 7.4

Figura 7.4: Cuadro de diálogo.

81

En el cuadro de diálogo mostrado debemos introducir el nombre del robot que deseamos y pulsar aceptar. A continuación se presentará una ventana para elegir el mundo sobre el cual el robot se desenvolverá. La ventana es como la mostrada en la figura 7.5. Posteriormente se carga el mundo elegido en el simulador 3D de java, el cual es mostrado en la figura 8.6.

Figura 7.5: Abrir mundo. La figura 7.5 muestra el cuadro de dialogo abrir y los mundos con los que se cuentan.

Figura 7.6: Simulador 3D de java

82

En la figura 7.6 se muestra el simulador 3D de java el cual es el espacio donde el robot se desenvuelve. En la figura 7.3 de la interfaz se muestran 5 cuadros de texto en los cuales se despliega la información que pasa el MODEM al simulador del robot, estos son:

• No. de origen • No. destino • Comando • Número • VeriComando

No. de origen: Este es el número del celular que esta enviando el comando. No. destino: Este es el número del MODEM. Comando: Es el comando enviado para la ejecución. Número: Es el número intermedio por el cual paso el comando. VeriComando: Es el que verifica si el comando es válido y ahí se muestra el resultado.

83

8. Conclusiones y observaciones. Esta tesis ha presentado el modelado, usando UML, del sistema simulador del control de un robot móvil a través de GSM. El modelado incluye: el modelo de análisis, el modelo de diseño, modelo de implementación y modelo de pruebas. Cada modelo esta formado por diferentes diagramas UML. En el modelo de análisis se tienen los diagramas de casos de uso y diagrama de clases, para el diseño tenemos los diagramas de clase, secuencia, interacción, estado y actividades, y para la implementación se tiene el diagrama de componentes. La implementación se desarrolló usando los paquetes JMR, Java Media Framework, y el lenguaje de programación java. El sistema es una arquitectura cliente servidor. Al simulador JMR que es el encargado de simular el robot, se le agrego la parte del simulador del MODEM GSM ya que no contaba con esta función. El paquete Java Media Framework se utilizó para generar los tonos del simulador del celular. El desempeño del simulador del celular, el simulador de la central telefónica y servicios de mensajes cortos y el simulador del MODEM GSM, bajo operaciones normales es bueno, es decir, en las operaciones de comunicación por medio de mensajes cortos y tonos, debe estar ejecutándose los simuladores citados anteriormente de lo contrario fracasara la comunicación. Con la implementación del simulador se logro el objetivo propuesto en esta tesis. Al sistema de simulación del control de un robot móvil a través de GSM se podría hacer un modelado más a detalle y también mejorar la organización del sistema para así poder contemplar más aspectos que pudieran con llevar a un mejor funcionamiento del mismo, así como también el de la transferencia de imágenes que capta la cámara del robot al celular. Además se puede hacer más eficiente la comunicación por tonos si en lugar de transmitir caracter a caracter se transmite en una trama GSM, como se realiza en la comunicación por mensajes cortos. A futuro la simulación del control de un robot móvil podría ser implementada de manera real, es decir, que desde un teléfono celular con tecnología GSM se pueda controlar a un robot, y poder recibir en el celular las imágenes que capta la cámara del robot.

84

Apéndice 1 Funcionamiento del Sistema GSM y Arquitectura del Protocolo Redes de bases de datos y estandarización GSM define un número de bases de datos de la red que son utilizadas en la ejecución de las funciones del administrador de la movilidad y control de llamadas en una red móvil terrestre pública (PLMN). Estos elementos incluyen los registros de la localización que consisten del registro de localización de llamada (HLR), el registro de la localización del visitante (VLR), el registro de identificación del equipo (EIR), y la central de autentificación (AC). El HLR mantiene y actualiza la localización del suscriptor móvil y/o su información de perfil de servicio. El VLR mantiene la misma información localmente, donde el suscriptor está vagando. El VLR es definido como una función independiente, pero es visto generalmente por los vendedores como parte del MSC. Estos registros son llamados puntos de control de servicio (SCP) en la terminología usada en una red inteligente (IN). El EIR es utilizado para enumerar las identidades del equipo de los suscriptores, que se utilizan para la identificación del equipo desautorizado del suscriptor, y por lo tanto la negación del servicio por la red. La AC proporciona las claves y algoritmos para mantener la seguridad de las identidades del suscriptor, y para la encriptación de la información pasada sobre el interfaz del aire. El MSC se equipa de un módulo de punto de conmutación del servicio (SSP) el cual es utilizado para consultar las bases de datos tales como un registro de la localización para identificar donde encontrar a un suscriptor móvil y cuál es su perfil de servicio, para el encaminamiento, y procesamiento de las llamadas al suscriptor. Las especificaciones de GSM han definido funciones lógicamente separadas e interfaces estándares para cada una de las bases de datos para permitir que cada función sea implementada en una componente de la red separada físicamente. Las interfaces se especifican vía la parte de aplicación del móvil (MAP) que utiliza la parte de aplicación de la capacidad de la transacción (TCAP) de (SS7). Estos son todos los elementos de una IN. GSM se considera una aplicación de IN y proporciona esta consideración de implementación de GSM como experiencia en establecimiento de una red inteligente. Plan de numeración La enumeración consiste en por lo menos un número de ISDN internacional asignado ya sea al suscriptor móvil, si el teléfono celular funciona por tarjeta, o a la estación móvil, o diferente. La estación móvil ISDN (MSIS-DN) se conforma con la recomendación del CCITT E.164, y debe cumplir, en cada país, con el plan de enumeración del ISDN de ese país. El número de MSISDN consiste básicamente de un código de país (CC), un “código de destinación nacional (NDC), que especifica un PLMN dentro de ese país, y un número de suscriptor (SN).

85

El número de MSISDN es utilizado para marcar por un suscriptor que llama del PSTN/ISDN, y utilizado para encaminar la llamada a la entrada MSC de la red GSM. El GSM MSC entonces utiliza el MSISDN para interrogar al HLR apropiado para requerir la información para el encaminamiento y ampliar la llamada al MSC del teléfono celular que visita. La información de reencaminamiento es especificada por el número de roaming de la estación móvil (MSRN) que se obtiene del HLR y se utiliza para dar progreso a la llamada al teléfono celular llamado. El MSRN es un número temporal, asignado por el VLR (asociado al MSC que visita el teléfono celular) y enviado al HLR del teléfono celular referido a la actualización en la localización del teléfono celular o sobre una llamada por base. El MSRN tiene la misma estructura de los números de MSISDN en el área de la localización del visitante donde ésta es asignada Direccionamiento y encaminamiento de la llamada El número de MSISDN se utiliza para el encaminamiento de llamadas dentro de las redes PSTN/ISDN. Los párrafos siguientes proporcionan una discusión sumaria de los panoramas posibles implicados en el encaminamiento de la llamada. Llamadas nacionales desde la red fija Un intercambio local o de tránsito, al recibir una llamada destinada para un móvil, reconoce el NDC, y encamina la llamada a una entrada MSC. La entrada MSC realiza la pregunta de HLR para el MSRN, que entonces utiliza para reencaminar la llamada. Llamadas internacionales desde la red fija Cuando un intercambio local o de tránsito recibe una llamada internacional y reconoce el prefijo internacional, encamina la llamada al ISC más cercano. El ISC reconoce que el NDC indica una PLMN. Si éste puede apoyar la pregunta de HLR (es decir, si éste tiene conectividad de señales (TCAP) al HLR) ésta pregunta al HLR y recibe el número de roaming del suscriptor llamado y encamina la llamada al MSC que visita. Sino, encamina la llamada al ISC de la PLMN del lugar del suscriptor llamado. Llamadas nacionales desde dentro de una PLMN Cuando un intercambio local (MSC) recibe una llamada destinada para un teléfono celular, éste pregunta al HLR del teléfono celular por el número roaming del teléfono celular. En el recibo del MSRN, encamina la llamada al MSC del teléfono celular llamado. Direccionamiento de otros componentes de una PLMN Otros componentes de una PLMN, los cuales pueden ser direccionados para el encaminamiento de varios mensajes de señales, son los MSC’s, y los registros de localización. Si estos elementos se direccionan dentro del mismo PLMN, los códigos de punto (CP) SS7 pueden ser utilizados. Si no, para el encaminamiento del interPLMN, los

86

títulos globales (GT) derivados, por ejemplo, del código del país móvil (MCC) y de los códigos de destinación nacionales (NDC) se utilizan. Estructura del canal de radio en GSM En GSM, los canales de radio se basan en una estructura de TDMA que es implementada en las subbandas de múltiple frecuencia (TDMA/FDMA). Cada estación base se equipa de cierto número de estos canales de frecuencia /tiempo preasignados. La CEPT ha hecho disponible dos bandas de frecuencia para ser utilizados por el sistema GSM. Estas son: 890-915MHz para transmitir del teléfono celular a la estación base y 935-960MHz para transmitir de la estación base al teléfono celular. Estas bandas son divididas en 124 pares de portadores espaciados por 200KHz, comenzando con el par 890.2MHz. Cada sitio de la célula tiene una asignación de cierto número de portadores, extendiéndose de solamente de uno a generalmente no más de 15 canales. La célula alcanza en tamaño de uno a varios kilómetros. El espectro asignado de 200KHz por canal es dividido en segmentos de tiempo usando una asignación fija, siendo el esquema del acceso múltiple de división de tiempo (TDMA). El eje del tiempo se divide en ocho ranuras con longitud de 0.577ms. Las ranuras se numeran de la 0 a la 7 y forman un marco con longitud de 4.615ms. La repetición de una ranura de tiempo en particular en cada marco constituye un canal físico. El esquema de TDMA utiliza un bit total de índice alrededor de 270kb/s (con un cambio mínimo gaussiano afinando la modulación, GMSK) y requiere adaptar técnicas sofisticadas de receptor para hacer frente a los problemas de la transmisión causados por la desaparición multidireccional. El factor de TDMA de 8 conjuntamente con un espaciamiento de portador de 200KHz correspondería al sistema análogo anterior usando solo un canal por portadora con un espaciamiento de portador de 25KHz. El sistema digital GSM permitió la operación en portadores de más baja interferencia de radio (C/I) usando las ganancias por la compresión digital de voz junto con la codificación del canal (corrección de error de gran alcance). El cociente reducido de C/I alternadamente permitió el uso de distancias más cortas para la reutilización del canal para lograr una eficiencia del espectro competitivo a la lograda por los sistemas analógicos. La estructura TDMA es aplicada en ambas direcciones de la estación base al móvil y del teléfono celular a la estación base. La numeración, no obstante, es escalonada por tres ranuras de tiempo, para evitar que la estación móvil transmita y reciba al mismo tiempo. Estas ranuras de tiempo son utilizan para llevar al usuario señales o información de control en ráfagas. Las ráfagas son ligeramente más cortas que las ranuras, son de 546ms, se tienen en cuenta los errores de alineación y sincronización de ráfagas, y el retraso en la dispersión sobre la trayectoria de propagación.

87

El GSM define una variedad de tráfico y los canales de señales/control con diversos índices de bit. Estos canales son asignados a canales lógicos derivados de la estructuración de las ocho ranuras básicas de marcos TDMA. Para este propósito, se han definido dos estructuras de multiframe: una que consiste en 26 marcos de tiempo (dando por resultado un intervalo de repetición de 120ms), y uno que abarca 51 marcos de tiempo (o 236ms). El multiframe 26 se utiliza para definir los canales del tráfico (TCH), y sus canales asociados lentos y rápidos de control (SACCH y FACCH) que llevan la información de control del enlace entre el teléfono celular y las estaciones base. Los TCH se han definido para proporcionar seis diversas formas de servicios, es decir, canales de datos o conversación de máxima velocidad (fullrate) soportando velocidades efectivas de bits de 13kb/s (para conversación), 2.4, 4.8, y 9.6kb/s y canales de velocidad media con velocidad efectiva de bits de 6.5kb/s (para conversación) y 2.4kb/s, y 4.8kb/s para datos (nota que la velocidad total de bit sobre estos canales es más alta debido a la codificación requerida del canal, 22.8kb/s máxima velocidad para conversación) la máxima velocidad de los TCH’s se implementa en 24 marcos del multiframe, con cada TCH ocupando una ranura de tiempo de cada marco. El SACCH es implementado en el marco 12 (numerado a partir de la 0), proporcionando ocho canales SACCH, uno dedicado a cada uno de los ocho canales de TCH. El marco 25 en el multiframe es actualmente ocioso y reservado para implementar los ocho SACCH adicionales requeridos cuando los canales de conversación de media velocidad se convierten en una realidad. El FACCH es obtenido a petición por robo del TCH, y utilizado por cualquier terminal para señalar las características y la transferencia de la trayectoria física, u otros propósitos tales como conexión “handover” de control de mensajes. El robo de una ranura de TCH para señales FACCH se indica a través de una bandera dentro de la ranura de TCH. El marco 51 del multiframe tiene una estructura más compleja y referiremos al lector a la recomendación 05.0 del G/M para las posiciones específicas de varios canales lógicos en el multiframe. La estructura del marco 51, sin embargo, se utiliza para derivar los canales de señales siguientes y de control. SDCCH – el canal de control dedicado es único y se utiliza para la transferencia del control de la llamada que señala a y desde el teléfono celular durante el establecimiento de la llamada. Como los TCH’s, el SDCCH tiene su propio SACCH y se libera una vez que la llamada es establecida. BCCH – el canal del control de la difusión se utiliza del BSS al teléfono celular para emitir información del sistema tal como los parámetros de sincronización, servicios disponibles y el ID de célula. Este canal está continuamente activo, con ráfagas ficticias sustituidas cuando no hay información que transmitir porque la fuerza de las señales es supervisada por los teléfonos celulares para la determinación de desocupado. SCH – el canal de la sincronización lleva la información del BSS para la sincronización del marco.

88

FCCH – el canal del control de la frecuencia lleva la información del BSS para la sincronización del portador. CCCH – los canales comunes de control se utilizan para transferir señales de información entre todos los teléfonos celulares y el BSS en funciones de creación de la llamada y paginación de la llamada callpaging. Hay tres canales comunes de control:

• PCH: el canal de paginación para llamar (paginar) a un teléfono celular del sistema • RACH: el canal de acceso aleatorio usado por los teléfonos celulares que intentan

tener acceso al sistema. Los usuarios móviles utilizan el esquema ranurado de Aloha sobre este canal para solicitar un DCCH del sistema en la iniciación de la llamada.

• AGCH: el canal de la concesión de acceso usado por el sistema para asignar

recursos a un móvil tal como un canal de DCCH. Observe que los AGCH y los PCH nunca son utilizados por un teléfono celular al mismo tiempo, y por lo tanto son implementados sobre el mismo canal lógico. Todos los canales de señales de control, excepto el SDCCH, son implementados en la ranura de tiempo 0 en diversos marcos de TDMA de los 51 multiframes usando una frecuencia portadora dedicada RF asignada en una por célula base. La estructura del multiframe para el SDCCH y su canal asociado lento asociado del control (SACC) se pone en ejecución en uno de los canales físicos (las ranuras de TDM y los portadores del RF) seleccionados por el operador de sistema. Administración de la movilidad Conexiones “handoffs”. Estas conexiones pueden ser hechas entre los canales en la misma célula, entre los canales en diversas células bajo misma cobertura de BSS, o entre las células bajo cobertura de diversos BSS’s, e incluso entre diversos MSC’s. En GSM, el BSS puede autónomamente manejar las conexiones handoffs en la misma célula, o entre las células bajo su propia cobertura. Esto se llama conexiones handoffs internas. El MSC está implicado en el manejo de las conexiones handoffs que necesitan ocurrir entre las células bajo cobertura de dos diversos BSS’s. Estas son llamadas conexiones handoffs externas. Cuando el BSS indica que un handover externo se requiere, la decisión de cuando y si un handover externo debe ocurrir entonces es tomado por el MSC. El MSC utiliza la información de la medida de calidad de la señal divulgada por las estaciones móviles (MS’s) que son preprocesados en el BSS para la determinación del handover externo. El MSC original que maneja una llamada mantendrá siempre el control de la llamada en un handover externo a un MSC diferente e incluso a un MSC subsecuente. Cuando el BSS realiza una conexión handoff interna, ésta informa al MSC la terminación del proceso. La necesidad de una conexión handoff se puede indicar por el usuario móvil, a través de mensajes en el FACH, o por el BSS ya que éste mantiene el rastreo de la calidad de las

89

señales recibidas. El BSS supervisa la calidad de la señal de radio recibida y también transmite tales resultados al MSC quien mantiene una vista más global sobre los canales de radio que pertenecen a su BSS’s. El MSC también puede iniciar la necesidad de una conexión handoff por razones de tráfico en una tentativa de balancear la carga fuera del tráfico en la red. Manejo de información de localización La información de la localización es mantenida y utilizada por la red para localizar al usuario para los propósitos del encaminamiento de la llamada. La red registra la localización del usuario en un registro llamado el HLR del usuario, que se asocia a un MSC situado en el PLMN, al cual suscriben al usuario. Cada BSS guarda la difusión, sobre una base periódica, de las identidades de la célula en “los canales del control de la difusión” de las células bajo su cobertura. Los móviles dentro de cada célula mantienen controlada tal información. Como se detectan cambios en la localización (de la última información registrada por ellos), cada uno de ellos reporta la nueva localización al BSS que encamina esto al VLR del MSC con el cual está conectado. El VLR, alternadamente, envía la información de la localización al HLR del usuario, donde también se registra. Mientras tanto, el HLR ordena al viejo VLR suprimir la vieja localización de visita del teléfono celular de su base de datos, y también envía una copia del perfil del servicio del usuario al VLR nuevo. La actualización de la localización es realizada por la subcapa del protocolo de la administración de la movilidad (MM). Ruteando y señalizando llamadas Una llamada puede ser iniciada por un usuario móvil a otro móvil o un usuario fijo, o al revés, por un usuario fijo a un móvil. Para encaminar una llamada a un usuario móvil, sin embargo, la señal de red necesita primero localizar el móvil. Ilustraremos esto para el caso cuando una llamada es iniciada por un usuario fijo, y después comentaremos respecto al panorama en el cual la llamada es iniciada por un móvil a otro móvil. Cuando la llamada es iniciada por un móvil a un usuario fijo, el procedimiento es un poco directo. En el caso de una llamada iniciada por un usuario fijo, el PSTN puede utilizar el número ISDN de la estación móvil, MSISDN, para encaminar la llamada a la entrada más cercana MSC dentro de PLMN del móvil. El GMSC alternadamente utiliza el MSISDN para interrogar al HLR del móvil para la información de encaminamiento requerida para ampliar la llamada al visitante MSC del móvil en ese entonces. Este visitante MSC (o más específicamente, el VLR dentro del MSC local) es identificado en el HLR del móvil por el MSRN que especifica el MSC visitante El MSRN es un número temporal asignado por el VLR y enviado al HLR en la actualización de la localización, o la iniciación de la llamada. El MSRN debe tener la misma estructura que el número MSISDN al del área donde el VLR es asignado. El VLR entonces inicia el procedimiento de paginación y las páginas MSC son enviadas a la estación móvil con una paginación broadcast a todas las BSS’s del área de localización, así también el área exacta de la estación base del móvil podría no ser conocida.

90

Después de respuesta de paginación, la actual BSS está situada. Se establecen las conexiones RR y MM, al igual que la autentificación del usuario (para acceder a la red), además del cifrado. El VLR entonces envía los parámetros requeridos para establecer la llamada al MSC, y puede también asignar al teléfono celular un TMSI nuevo para la llamada. El MSC envía un mensaje de establecimiento a la estación móvil. La estación móvil, al recibir el mensaje de establecimiento, realiza una comprobación de compatibilidad y retorna un mensaje de llamada confirmada a la red, que puede incluir la capacidad de portador de la estación móvil. El BSS puede en este punto asignar un canal del tráfico, TCH, a la llamada, o puede asignar éste en una plataforma posterior, siendo los últimos al recibir el “mensaje conectar” de la estación móvil. Si la alerta de usuario es llevada fuera del MS, un mensaje de alerta se envía al suscriptor que llama. Cuando, el suscriptor contesta a la llamada, el MS envía un mensaje de conectar, que en el lado de la red inicia la terminación de la asignación del canal de tráfico y el intercambio a través de la conexión. El mensaje de conectar progresa al suscriptor de la llamada. La red también envía un reconocimiento al MS, de entrada en el estado activo. Arquitectura de las capas del protocolo La arquitectura del protocolo del GSM usada para el intercambio de señales de mensajes concierne a la movilidad, los recursos de radio, y las funciones de administración de la conexión. Las capas del protocolo consisten en la capa física, la capa de transmisión de datos, y la capa 3. No se deben confundir las funciones de la capa 3 definidas por GSM con las funciones de la capa 3 del modelo OSI. Los protocolos de la capa 3 del GSM se utilizan para la comunicación de recursos de red, la movilidad, el formato del código y los mensajes relativos a llamadas de administración entre las varias entidades de la red implicadas. Puesto que en el modelo OSI algunas de estas funciones son proporcionadas realmente por las capas más altas, el término “capa de mensaje” podría ser más apropiado para referirse a la capa 3 en GSM. La capa de mensaje (capa 3) del protocolo se compone de tres subcapas llamadas administración de recursos (RR) implementada sobre el enlace entre el MS y el BSS, el administrador de la movilidad (MM), y las subcapas de administración de la conexión (CM) que proporcionan la comunicación entre el MS y el MSC. La capa 3 también pone en práctica la parte del transporte del mensaje (MTP), nivel 3, y la parte de control de la señal de conexión del CCITT SS7 sobre el enlace entre el BSS y el MSC (la interfaz de A) para proporcionar el transporte y las funciones de direccionamiento para señales de mensajes que pertenecen a las varias llamadas encaminadas a través del MSC. Para discutir la funcionalidad proporcionada por la capa 3 en la pila del protocolo GSM, se debe prestar particular atención en no confundir los detalles de la funcionalidad de esta capa con la que es proporcionada comúnmente por la capa 3 del modelo de referencia OSI.

91

En GSM, las subcapas CM y MM, por ejemplo, proporcionan realmente algunas de las funcionalidades que son realizadas por las capas de transporte, de sesión, y presentación de OSI ver Fig. 2.2.

Figura: 2.2 Arquitectura del protocolo GSM Capa Física La capa física en el enlace de radio fue discutido en la sección sobre la estructura del canal de radio. Los canales del tráfico en la telefonía fija se forman de ranuras de TDM puestas sobre enlaces de 2.048Mb/s (troncos E1). Los canales de señales se multiplexan de modo lógico en un agregado de las ranuras de TDM. La capa de enlace en el interfaz del aire La capa de transmisión de datos sobre el enlace de radio (que conecta al MS con el BSS) se basa en un protocolo parecido a LAPD (Link Access Protocol D channel) como el protocolo, etiquetado como LAPDm, que se ha modificado para la operación dentro de la limitación fijada por la trayectoria de radio. En particular, LAPDm no utiliza banderas (y por lo tanto ningún bit de relleno) para la delimitación del marco. En cambio, la delimitación del marco en LAPDm es hecha por la capa física que define los límites del marco de transmisión. LAPDm utiliza un campo “Indicador de la longitud” para distinguir el campo que lleva información de los bits usados para llenar el marco de transmisión. LAPDm utiliza un campo de dirección para llevar el identificador del punto de acceso del servicio, (SAPI), (3 bits en este caso) que LAPD también utiliza para identificar al usuario del servicio proporcionado por el protocolo. Al usar marcos de comando/control, el SAPI identifica el usuario para quien un marco de comando es dirigido, y el usuario que transmite un marco de respuesta. Los 2 bits del discriminador del protocolo de enlace (LPD) son utilizados para especificar una recomendación particular del uso de LAPDm, el C/R es un

CM

MM

RR

LAPDm

TDMA/FDMA

RR

LAPDm

TDMA/FDMA

MTP

BSSAP

SCCP

CM

MM

BSSAP

SCCP

MTP

MSC

A-interface Radio interface

MS BSS

Message Layer (Layer 3)

Layer1

Layer2

Message Layer (Layer 3)

Layer1

Layer2

92

solo bit que especifica si es un marco de comando o de respuesta según lo utilizado en LAPD, y una dirección ampliada (EA) de 1-bit se utiliza para extender el campo de dirección a más de un octeto (el bit EA en el último octeto de la dirección se debe fijar a 1, si no a 0). El bit 8 es reservado para futuros usos. LAPDm utiliza un campo de control como se utiliza en LAPD para llevar una serie de números, y para especificar el tipo de marco. LAPDm utiliza tres tipos de marcos usados para las funciones de supervisión, la transmisión innumerable de la información y las funciones de control (modo sin reconocimiento), y la transmisión de información numerada (modo multiframe reconocido) según lo utilizado en LAPD. LAPDm no utiliza bit verificador de redundancia cíclica para la detección de error. Los mecanismos de corrección y detección de error son, en cambio, proporcionados por una combinación del bloque y de la codificación circunvolucional usados (en conjunción con el bit de interpolación) en la capa física. Capa de enlace en la interfaz A En el enlace terrestre conectando el BSS al MSC (la interfaz A), el nivel 2 de MTP del protocolo SS7 se utiliza para proporcionar las funciones de la capa 2 de OSI del transporte confiable para señales de mensajes, tales como recuperación de errores de la transmisión a través de la detección de error y de la retransmisión. Protocolos y funciones de la capa de mensaje Subcapa de administración de recursos de radio (RR) La subcapa de administración (RR) termina en el BSS y desempeña las funciones de establecimiento de las conexiones físicas sobre el radio con el fin de transmitir la señal de información relacionada con la llamada tal como el establecimiento de señales y canales de tráfico entre un usuario móvil específico y el BSS. Las funciones de administración del RR se ponen en práctica básicamente en el BSS. Subcapa de administración de movilidad (MM) La subcapa MM se termina en el MSC y los mensajes relacionados al MS son retransmitidos de modo transparente en el BSS usando el proceso de DTAP. La subcapa MM proporciona las funciones que se pueden clasificar en tres tipos de procedimientos. Éstos son llamados procedimientos específicos MM, los procedimientos comunes de MM, y los procedimientos MM relacionados a la conexión. Procedimientos relacionados a la conexión MM Estos son los procedimientos usados para establecer, mantener y liberar una conexión MM entre el MS y la red (MSC) sobre la cual una entidad de la subcapa de la administración de la conexión (CM) puede intercambiar la información con este par. Más de una conexión MM puede ser activada al mismo tiempo para servir entidades múltiples CM. Cada entidad CM dentro del MS tendrá su propia conexión MM, y cada conexión es identificada por el discriminador del protocolo, y un identificador de la transacción dentro de las señales de

93

mensajes intercambiados. El identificador de transacción es de clase análoga a la referencia de la llamada usada por ISDN para identificar señales de mensajes de diferentes llamadas sobre el canal D. Así las llamadas en paralelo que pueden ser soportadas por el mismo MS son entonces identificadas por un valor diverso para el parámetro del identificador de la transacción. El establecimiento de una conexión MM requiere que no estén activos procedimientos específicos MM. Las conexiones MM proporcionan servicios a las diversas entidades de la subcapa superior de la administración de la conexión (CM) que consisten en el control de la llamada (CC), los servicios de mensaje cortos (SMS), y los servicios suplementarios de llamada-independiente (SS). Una conexión MM es iniciada por un mensaje de la petición del servicio de CM que identifique la entidad de petición de CM y el tipo de servicio requerido de la conexión de MM. Los servicios proporcionados por las conexiones MM incluyen cosas tales como cifrado (para privacidad de la información del usuario), y autentificación (acceso del usuario a la red y a los servicios solicitados) que sería proporcionada realmente por las capas de presentación, y las aplicaciones de la estructura de OSI. Cada uno de estos servicios implicaría el intercambio de múltiples mensajes entre el MS y la red antes de que se establezca la conexión MM requerida y la entidad de petición dentro de la subcapa del CM se notifica. Procedimientos específicos de la administración de la movilidad Los procedimientos específicos de MM no instalan una conexión MM. Sólo pueden ser iniciados cuando otros procedimientos específicos MM no están funcionando, y no esté establecida la conexión MM. Estos procedimientos consisten en la actualización de la localización y los procedimientos de la fijación de IMSI. Actualización de la localización La actualización de la localización es el procedimiento para mantener la red informada de donde el móvil está vagando. La actualización de la localización es iniciada siempre por la estación móvil ya sea que detecte que está en una nueva área de localización, supervisando periódicamente la información de la localización emitida por la red en el canal de la difusión, y comparándola con la información almacenada previamente en su memoria, o recibiendo una indicación de la red que éste no es conocido en el VLR sobre el intento de establecer una conexión MM. Siempre que la red actualiza la localización del móvil, le envía una “identificación de suscriptor móvil temporal actualizada” (TMSI), en el modo cifrado, que se almacena en el MS y se utiliza para la identificación móvil subsiguiente en la paginación y operaciones de iniciación de llamada. El propósito de usar el TMSI en comparación con IMSI del usuario es mantener la identidad del suscriptor confidencial en el enlace de radio. El TMSI no tiene estructura específica del GSM, y tiene significado solamente dentro del área de la localización asignada. El TMSI tiene que ser combinado con el identificador del área de localización (LAI) para proporcionar una identificación inequívoca fuera del área donde se asigna.

94

Fijar IMSI El procedimiento de fijación de IMSI es el complemento del procedimiento IMSI de desconexión (soltar IMSI), una función de los procedimientos comunes de MM. Ambos procedimientos son las opciones de la red cuya necesidad del uso se indica a través de una bandera en la difusión de la información del sistema en el canal BCCH. Los procedimientos de IMSI desconexión/conexión marcan el MS como desconectado/conectado en el VLR (y opcionalmente en el HLR) sobre energía baja o alta o modulo de información de suscriptor (SIM) quitado o insertado (los IMSI de desconexión deshabilitan la función de actualización de la localización para prevenir el sobrecargo de señales innecesarias en la red). Cualquier llamada entrante, en ese caso, se rechaza o se remite como puede ser especificado por el usuario. El IMSI se utiliza para indicar el IMSI como activo en la red. Se invoca este procedimiento si un IMSI se activa en una MS (energía alta, o inserción de SIM) en el área de la cobertura de la red, o un MS activado entra en el área de la cobertura de la red exterior. El procedimiento de la fijación de IMSI entonces se realiza solamente si el área de la localización almacenada es en ese entonces igual que la que está siendo difundida en el canal BCCH de la porción de la célula. De otro modo, un procedimiento de actualización de la localización normal se invoca sin tener en cuenta si la red soporta procedimientos de IMSI de conexión/desconexión. Procedimientos comunes MM Los procedimientos comunes MM pueden ser iniciados en cualquier momento mientras que un canal de radio dedicado existe entre la red y el MS. No establecen una conexión MM, pero pueden ser iniciados durante un procedimiento específico MM, o mientras una conexión MM tiene lugar. Los procedimientos comunes MM consisten en IMSI de desconexión, reasignación de TMSI, y autentificación/identificación. Separar IMSI (IMSI “detach”) El procedimiento IMSI de desconexión es invocado por la estación móvil para indicar el estado inactivo a la red. No se devuelve ninguna respuesta o reconocimiento al MS por la red al fijar la bandera activa para el IMSI. El procedimiento IMSI de desconexión no es iniciado si al mismo tiempo un procedimiento especifico MM está activo. En este caso, el procedimiento IMSI de desconexión se retrasa, si es posible hasta que el procedimiento especifico MM termine de lo contrario la solicitud IMSI de desconexión es omitida. Si al mismo tiempo de una solicitud de desconexión, una conexión de radio está en existencia entre el MS y la red, la subcapa MM liberará cualquier conexión en curso MM antes de que se envíe el mensaje de indicación MM de desconexión. Reasignación TMSI El propósito de la reasignación de TMSI es proporcionar confidencialidad de la identidad. Es decir, para proteger al usuario contra ser identificado y ser situado por un intruso. Este procedimiento se debe realizar por lo menos en cada cambio del área de cobertura del MSC. La reasignación en cualquier otro caso se deja al operador de red. Si el TMSI

95

proporcionado por una estación móvil es desconocido en la red, por ejemplo, en el caso de una falla de la base de datos, el MS tiene que proporcionar su IMSI a petición de la red. En este caso el procedimiento de identificación tiene que ser realizado antes de que el procedimiento de TMSI pueda ser iniciado. Autentificación El propósito del procedimiento de autentificación es dejar la red verificar la identidad proporcionada por el usuario cuando la solicite, y proporcionar una nueva clave cifrada a la estación móvil. Los casos cuando los procedimientos de autentificación deben ser utilizados se definen en la recomendación 02.09 de GSM. El procedimiento de autentificación es iniciado y controlado siempre por la red. Identificación Este procedimiento es utilizado por la red para solicitar a una estación móvil proporcionar los parámetros de identificación específicos a la red, tal como los identificadores móviles internacionales del suscriptor o del equipo del usuario (IMSI o IMEI). La estación móvil debe estar lista para responder a un mensaje de solicitud de identidad en cualquier momento mientras que la conexión RR existe entre el teléfono celular y la red. Subcapa de la administración de la conexión (CM) La subcapa CM termina en el MSC y contiene las entidades que consisten en el CC incluyendo servicios suplementarios relativos a llamadas, SMS, y la ayuda de servicios suplementarios independientes de la llamada (SS). Una vez que se haya establecido una conexión MM, el CM puede utilizarla para la transmisión informativa. La entidad CC utiliza el protocolo CCITT Q.931, con modificaciones de menor importancia, para la comunicación de los mensajes relacionados con el control de la llamada entre el MS y el MSC. El SMS es un servicio definido por GSM que proporciona comunicación rápida del modo de paquete (“sin conexión”) de mensajes hasta 140 bytes entre el MS y un tercer participante que es el centro de servicio. Estos mensajes se pueden enviar o recibir por la estación móvil mientras que una llamada de voz ó datos está en el estado activo o inactivo. Es aceptable, sin embargo, si se aborta el servicio mientras que una llamada está en un estado transitorio tal como desocupado u ocupado-a-ocioso. El centro de servicio es responsable de la colección, del almacenaje, y de la entrega de mensajes cortos, y está fuera del alcance de GSM. Parte de la aplicación BSS (BSSAP) El BSS, además de proporcionar la conmutación de canal y las funciones aéreas, realiza la administración de los recursos de radio, y las funciones que trabajan entre los protocolos de transmisión de datos usados en la radio y el lado BSS-MSC para transportar señales relacionadas con los mensajes. Estas funciones son proporcionadas por el proceso de

96

administración de aplicación de la BSS (BSSMAP), y el proceso de Aplicación de Transferencia Directa (DTAP). El BSSMAP se utiliza para poner todos los procedimientos en ejecución entre el MSC y el BSS que requieran la interpretación y el procesamiento de la información relacionada para distinguir llamadas, y la administración de los recursos. Básicamente, el BSSMAP es el proceso dentro del BSS que controla los recursos de radio en respuesta a instrucciones del MSC (en ese sentido, el BSSMAP representa la subcapa RR para el MSC). Por ejemplo, el BSSMAP se utiliza en la asignación y la conmutación de los canales de radio en el establecimiento de la llamada y los procesos de desocupado. Los procesos DTAP se utilizan para la transferencia transparente de las señales de mensajes de MM/CM entre el MS y el MSC. Es decir, la función de DTAP es proporcionar la función que trabaja con el nivel del transporte del protocolo para transferir señales de mensajes desde y al MS para y desde el MSC sin ningún análisis del contenido del mensaje. Protocolos de transporte de señales Los protocolos CCITT SS7 MTP y SCCP se utilizan para poner en práctica la transmisión de datos y las funciones de transporte de la capa 3 para llevar el control de la llamada y la administración de la movilidad de señales de mensajes sobre el enlace BSS-MSC. La señal de información de las subcapas MM y CM de la estación móvil se encaminan sobre los canales de señales (tales como el DCCH, el SACCH, el FACCH) al BSS de donde transparentemente se retransmiten a través del proceso DTAP a un SCCP, del tipo CCITT SS7 canal lógico, asignado para esa llamada, sobre el enlace BSS-MSC para la transmisión a la par de la entidad CC en el MSC para el procesamiento. De manera semejante, cualquier información de señal de llamada iniciada por el MSC en la conexión de SCCP se retransmite con el proceso de DTAP en el BSS al canal de señal asignado, usando el protocolo de transmisión de datos LAPDm, para la entrega a la estación móvil. El trabajo entre el protocolo de la capa 2 sobre el lado del radio y el SS7 en el enlace BSS-MSC es proporcionado por una unidad de distribución de datos dentro del campo de información del SCCP. Estos parámetros se conocen como la discriminación, y los parámetros del identificador de la conexión de transmisión de datos (DLCI). El parámetro de la discriminación (dedicado actualmente un octeto) utiliza un solo bit para direccionar un mensaje ya sea al proceso DTAP o al proceso BSSMAP. El parámetro de DLCI (un octeto de tamaño) se compone de dos subparámetros que identifiquen el tipo de canal de radio (tal como el DCCH, el SACCH, el FACCH), y el valor de la “interfaz del punto de acceso de servicio” (SAPI) (en el protocolo LAPDm) usado para el mensaje en el enlace de radio. El SCCP proporciona información para el multiplexado lógico de señales de diversas llamadas sobre el mismo canal físico en el enlace de BSS-MSC. Por cada llamada soportada por un BSS, una conexión lógica de SCCP se establece en el enlace de BSS-MSC. Cualquier información perteneciente a una llamada específica fluye a través de esta conexión asociada de SCCP y es así cómo el intercambio de señales de información perteneciente a diversas llamadas son identificadas en el BSS o el MSC.

97

El modo de servicio sin conexión del SCCP también se apoya para la transferencia de mensajes relacionados OA&M así como los mensajes de BSSMAP que no pertenecen a ninguna llamada específica (nota: los mensajes de BSSMAP que pertenecen a llamadas específicas, tales como mensajes hand-off, se transmiten usando la conexión de SCCP establecida para la llamada). La función de encaminamiento de SCCP utiliza el número del subsistema (SSN) en el octeto de la información de servicio (SIO) dentro del mensaje del nivel 3 de MTP para distinguir mensajes diseccionados a la función de OA&M de los diseccionados ya sea al DTAP o a la parte de aplicación BSSMAP. El alto nivel de capacidad de traducción de dirección del SCCP, conocida como traducción del título global, se puede entonces utilizar para proporcionar capacidades de dirección adicional tales como uso de la enumeración E.164 para direccionar diversas entidades de OA&M. La característica de la traducción del título global del SCCP también proporciona el MSC la capacidad para direccionar señales de mensajes a MSC’s remotos que puedan ser localizados en un diverso PLMN. El íntertrabajo de funciones entre el CM, MM y las entidades de BSSMAP y las entidades correspondientes del SS7 (es decir, el ISDN-UP), MAP, SCCP, y la parte de aplicación de las capacidades de las transacciones (TCAP) son proporcionadas por el MSC. Paginación Los mensajes de paginación para los móviles se envían vía el BSSMAP al BSS como mensaje sin conexión a través del SCCP/MTP. El mensaje de paginación puede incluir el IMSI del móvil a fin de permitir la derivación del número de la población de la paginación. Un solo mensaje de paginación transmitido al BSS puede contener una lista de las células en las cuales la página debe ser difundida. Cuanto más grande es el área de paginación definida, más baja es la frecuencia de las actualizaciones de la localización y por lo tanto el tráfico asociado es elevado en la red. Por otra parte, las áreas grandes de paginación resultan al incrementar el uso de la potencia de transmisión, además de los recursos de radio (canales). Por lo tanto, el tamaño óptimo para el área de paginación (área de localización) es determinado por un equilibrio apropiado entre los costos de paginación y los costos de actualización de la localización. Los mensajes de paginación recibidos del MSC se almacenan en el BS, y los mensajes correspondientes de paginación se transmiten sobre el interfaz de radio en el tiempo apropiado. Cada mensaje de paginación se relaciona con solamente una estación móvil y el BSS tiene que empaquetar el mensaje pertinente de paginación. Una vez que un mensaje de paginación es emitido sobre el canal o canales de radio, si un mensaje de respuesta se recibe del móvil, la conexión de señal relevante se establece hacia el MSC y el mensaje de respuesta de la página se pasa al MSC [35].

98

Apéndice 2 Manual de usuario JMR (Java Mobile Robots). APLICACIÓN CLIENTE Veremos ahora cómo utilizar la aplicación cliente. Haremos un recorrido por los componentes que contiene. PANTALLA PRINCIPAL El programa cliente tiene una apariencia como la siguiente:

Donde podemos distinguir 4 grandes apartados: ZONA DE PARÁMETROS DE CONEXIÓN La zona superior (Connection) tiene una barra con las opciones de conexión: • Dirección del servidor al que conectar (Server Address) • Puerto por el que conectar (Server Port) • Tipo de servidor al que conectar (Server Type), a elegir de la lista:

� Simulador 3D de JMR � Simulador Pioneer de Saphira � Robot real a través de puerto serie 1 (COM1) � Robot real a través de puerto serie 2 (COM2).

99

ZONA DE CONTROL DE LA LISTA DE ROBOTS La segunda zona (Robot List) contiene un panel para controlar los robots activos en cada momento. Se tendrá una lista con los robots que hay en el cliente en cada momento, y botones para añadir o quitar robots de la lista. También se tiene un apartado para elegir el fichero de parámetros que queremos asignar al robot que vayamos a añadir (por defecto se asignan los parámetros del fichero pion1m.p). ZONA DE DATOS DEL ROBOT Bajos las dos zonas anteriores se tiene la zona de datos del robot (Robot Data). En esta zona podremos ver:

• Los parámetros del robot (Parameters): datos estáticos que informan sobre los factores de conversión internos del robot, tamaño, número de sónares, etc.

• Los sonares del robot (Sonars): aquí se informa sobre las lecturas que tiene cada sonar del robot, y se muestra gráficamente el entorno del robot, las lecturas que marca y las velocidades lineal y rotacional que tiene en cada momento.

• El estado del robot (State), donde vemos datos dinámicos acerca del robot: posición actual, velocidades actuales (lineal y rotacional), estado de la batería, etc.

ZONA DE ELEMENTOS AÑADIDOS AL ROBOT En la zona inferior (Robot Add-ons) se tiene información sobre elementos que no forman parte inicialmente del robot, y que se tienen como añadidos. Esta zona se subdivide a la vez en dos: • Los procesos que tenga añadidos el robot (Processes), que a su vez pueden ser:

o Comandos simples: en el cuadro desplegable de esta zona se tiene una serie de comandos simples que podemos enviar al robot:

� Establecer la velocidad lineal (en mm/s) � Establecer la velocidad rotacional (en grados/s) � Indicar al robot que avance una determinada distancia (en mm) � Indicar al robot que gire un ángulo relativo (en grados) � Indicar al robot que gire un ángulo absoluto (en grados) � Sólo hay que escribir en el cuadro de texto el parámetro que necesita

el comando seleccionado (la velocidad, la distancia o el ángulo, según el comando), y pulsar el botón de enviar (Send).

o Procesos complejos: mediante el botón de añadir procesos (Add Process) podremos cargar procesos complejos en el robot. Luego, con el botón de ver procesos (View Processes) podremos ver en todo momento qué procesos tiene cargados el robot.

• Los dispositivos que tenga el robot (Devices). En la parte izquierda de este subpanel se tiene una lista con los dispositivos añadidos al robot que puedan visualizarse, y a la derecha se tiene otro subpanel donde en cada momento se verá el dispositivo que se tenga seleccionado de la lista de la izquierda. ESPECIFICACIÓN DE LAS OPCIONES DE CONEXIÓN Para especificar las distintas opciones de la conexión con el servidor, se tiene el panel de arriba de la aplicación cliente (Connection), donde:

100

• Server Address: será la dirección IP donde se encuentra la máquina servidor a la que conectar.

• Server Port: indica el puerto por el que conectar. • Server Type: indica el tipo de servidor al que nos queremos conectar. Podrá

ser uno de entre: o Java simulator: el simulador 3D de JMR o Saphira Pioneer: conexión al simulador Pioneer de Saphira,

utilizando el servidor de JMR para Saphira. o Saphira COM1: conexión a un robot real a través del puerto

serie 1, utilizando el servidor de JMR para Saphira. o Saphira com2: conexión a un robot real a través del puerto

serie 2, utilizando el servidor de JMR para Saphira.

Tras especificar estos parámetros, cada vez que se añada un nuevo robot, lo hará conectándose con las opciones indicadas en estos controles. CONEXION LOCAL Si no indicamos dirección IP o puerto, la conexión no se hará a una máquina remota (o al localhost) mediante RMI, sino que se creará una conexión directa y local con el servidor seleccionado. Esta opción, nueva en JMR 2, permite conectar de forma más rápida, y sin necesidad de utilizar RMI, con servidores que se encuentren en la misma máquina donde ejecutemos el cliente. Si elegimos la conexión local, al añadir un robot se creará el servidor correspondiente de forma automática (si no lo hemos creado ya antes al añadir un robot previamente), y se establecerá la comunicación con el mismo. CONECTAR / DESCONECTAR ROBOTS Para añadir o quitar robots de la escena, se tiene el segundo panel (Robots List), donde:

• La lista Robots contiene los robots que hay conectados en este momento. En los distintos cuadros de control del robot (parámetros del robot, estado del robot, lecturas de sónares, etc.) aparecerán los datos relativos al robot actualmente seleccionado de la lista.

• El botón de añadir robot (Add) sirve para añadir un nuevo robot. Al pulsarlo, aparecerá un cuadro de diálogo para que indiquemos el nombre del robot:

Si el nombre que se introduzca ya lo tiene otro robot, se auto numerará con el primer número libre. Por ejemplo, si al robot lo llamamos “Robot” y ya existe un robot con el nombre “Robot”, irá asignando nombres “Robot 1”, “Robot 2” ... y así sucesivamente hasta encontrar alguno libre.

101

Al conectar el robot, aparecerán sus datos en los distintos cuadros de controles que hay: parámetros, estado, lecturas de sónares etc.

• El botón de quitar (Remove) elimina al robot actualmente seleccionado, desconectándolo del servidor.

• El cuadro para el fichero de parámetros (Params File) indica el nombre del fichero de parámetros que queremos que tenga el robot que vamos a añadir. Podremos escribirlo directamente en el cuadro de texto, o pulsar el botón con puntos para buscarlo por el disco. Si vamos a conectar con Saphira, debemos asegurarnos de que el fichero de parámetros esté también en el directorio params de Saphira, para que pueda ser cargado.

CONTROL DE LOS DATOS DEL ROBOT En la zona de datos del robot (Robot Data) existen una serie de controles para visualizar y llevar un control de los datos del robot actualmente seleccionado en la lista de robots. PARÁMETROS DEL ROBOT Podremos ver los parámetros que definen al robot con el cuadro de parámetros (Parameters). En este cuadro se definen:

• Angle Conversion Factor es el factor de conversión de unidades de ángulos, interno del robot.

• Linear Velocity Conversion Factor es el factor de conversión de unidades de velocidad lineal, interno del robot.

• Rotational Velocity Conversion Factor es el factor de conversión de unidades de velocidad rotacional, interno del robot.

• Distance Conversion Factor es el factor de conversión de unidades de distancias, interno del robot.

• Range Conversion Factor es el factor de conversión de unidades de rangos (lecturas de sónares), interno del robot.

• Holonomic indica si el robot es holonómico (puede girar sobre sí mismo) o no. • Robot Radius es el radio del robot en mm. • Robot Diagonal es la diagonal del robot, en mm. • Robot Width es la anchura del robot, en mm. • Robot Length es la longitud del robot, en mm. • Robot Height es la altura del robot, en mm. • Maximal Linear Velocity es la máxima velocidad lineal que puede alcanzar, en • mm/s. • Maximal Rotational Velocity es la máxima velocidad rotacional que puede alcanzar,

en grados/s. • Maximal Linear Acceleration es la máxima aceleración lineal que puede adquirir, en

mm/s². • Class indica la clase de robots a la que pertenece. • Subclass indica la subclase dentro de la clase de robots.

102

• Name es el nombre del robot (distinto del que se asigna en la conexión, es un parámetro interno de especificación del robot).

• Number Of Sonars es el número de sónares que tiene. • Front Buffer indica el número de lecturas que se acumulan en los sónares frontales. • Side Buffer indica el número de lecturas que se acumulan en los sónares laterales.

Estos son parámetros estáticos, que definen algunas características del robot. LECTURAS DE LOS SÓNARES Para llevar un control de las lecturas que toma el robot, se tienen los paneles centrales (Sonars), donde se muestran los valores numéricos de dichas lecturas (en mm) y una representación gráfica de las mismas, junto con las velocidades actuales del robot. Se marca la velocidad lineal con una línea vertical, y la rotacional con una horizontal, y las lecturas de sónares en azul. ESTADO DEL ROBOT Podremos ver el estado del robot con el cuadro State, donde:

• Linear Velocity es la velocidad lineal que lleva el robot actualmente, en mm / s. Positiva si va hacia delante, negativa si va hacia atrás.

• Rotational Velocity es la velocidad de giro (rotacional) que lleva en grados / s. Positiva si es giro a la izquierda, negativa si es a la derecha.

• X es la coordenada X del robot, relativa a su posición inicial sobre el mundo, en mm.

• Y es la coordenada Y del robot, relativa a su posición inicial sobre el mundo, en mm.

• Th es la orientación del robot en grados. • State es el estado en que se encuentra el robot, que podrá ser uno de los siguientes:

o DISCONNECTED: el robot está desconectado del servidor. o NO MOTORS: el robot está conectado, pero con los motores apagados. o STOPPED: el robot está conectado, con los motores encendidos, pero

detenido, sin moverse. o MOVING: el robot se mueve o COLLISION: el robot ha colisionado.

• Battery es el estado en que se encuentra la batería (voltaje) Conviene resaltar que la posición X e Y sólo se ve modificada mediante los movimientos propios del robot. Es decir, si el usuario cambia manualmente la posición del robot, las coordenadas X e Y no se verán modificadas con la nueva posición. Representan movimientos automáticos del robot.

CONTROL DE LOS ELEMENTOS AÑADIDOS AL ROBOT En la zona de elementos añadidos (Robot Add-ons) existen controles para gestionar los procesos (Processes) que tiene cada robot, y los dispositivos (Devices).

103

PROCESOS DEL ROBOT Al hablar de procesos en el robot, distinguimos entre comandos simples y procesos complejos. ENVIO DE COMANDOS SIMPLES Para enviar comandos simples al robot, se tiene el cuadro desplegable en Processes, donde podremos elegir los distintos comandos simples que podemos enviar:

• Linear Velocity: velocidad lineal de movimiento. Necesita un parámetro, que es la velocidad, en mm/s.

• Rotational Velocity: velocidad de giro. Necesita un parámetro, que es la velocidad, en grados/s.

• Move: indica que el robot avance una determinada distancia. Necesita un parámetro, que es la distancia a avanzar, en mm.

• Turn to: indica que el robot rote hasta un determinado ángulo absoluto. Necesita un parámetro, que es el ángulo en grados.

• Turn: indica que el robot rote un determinado ángulo relativo. Necesita un parámetro, que es el ángulo en grados.

El cuadro de texto bajo el desplegable se emplea para pasar los parámetros que necesite cada comando simple, y luego pulsando el botón de enviar (Send) se enviará el comando seleccionado, con el parámetro introducido. CARGA DE PROCESOS COMPLEJOS Para cargar procesos en el robot se tiene el botón de cargar proceso (Add Process). Al pulsarlo, aparecerá un cuadro de diálogo para que elijamos el proceso a cargar (un fichero .class ya compilado con el proceso a cargar).

Al elegirlo, se mostrará un cuadro de diálogo para especificar los parámetros del proceso:

104

Al lado de cada parámetro se indica su tipo. Al final hay tres parámetros que tendrá todo proceso:

• Timeout: tiempo (en ms) que damos al proceso para que termine. Si se indica un valor negativo, no habrá límite de tiempo.

• Suspend: indica si el proceso se carga con un estado suspendido inicialmente, o se ejecuta nada más cargarse.

• Process name: nombre que queremos darle al proceso (si queremos darle algún nombre distinto al de la clase).

Tras introducir los parámetros, el proceso se añadirá al robot. VER LOS PROCESOS DEL ROBOT Con el botón de ver procesos (View Processes) se mostrará un panel con los procesos que hay ejecutando actualmente sobre el robot seleccionado:

105

En el panel se muestran todos los procesos que hay actualmente cargados en el robot. Al lado de cada proceso hay un desplegable con los distintos estados en que puede estar el proceso. Podremos cambiar el estado de los procesos que así lo permitan eligiendo el estado correspondiente del desplegable. Podremos elegir entre:

• LOADER: el proceso se ha cargado en el robot. • STOPPED: el proceso ha finalizado anormalmente. • RUNNING: el proceso está en ejecución. • SUSPENDED: el proceso ha sido suspendido mientras se ejecutaba. • DONE: el proceso ha finalizado satisfactoriamente. • QUIT: no es un estado del proceso. Se empleará cuando el usuario quiera quitar el

proceso del robot. Además, al lado de este cuadro se muestran dos líneas, de mayor o menor longitud, indicando la influencia de cada proceso en el movimiento lineal y en el giro. Líneas cortas indican poca influencia (cercana a 0) y líneas largas mucha influencia (cercana a 1). DISPOSITIVOS DEL ROBOT Los dispositivos que tenga añadidos el robot y que tengan un visor asociado, podrán controlarse mediante el panel Devices. En la parte izquierda se tiene una lista con los dispositivos disponibles, inicialmente puestos a OFF (es decir, ninguno se ve). Pulsando sobre cualquiera de ellos, su marca se pone en ON, y en la parte derecha se ve el estado del dispositivo. Volviendo a pulsar sobre él, vuelve a ponerse en OFF y deja de verse. Al pinchar a ON un dispositivo, el resto pasa a OFF (es decir, sólo podremos ver un dispositivo simultáneamente).

106

ACTUALIZACIÓN DE DATOS Los datos que se muestran en la zona de Robot Data y Robot Add-ons para el robot que tengamos actualmente seleccionado en la lista de Robot List se van actualizando automáticamente cada cierto tiempo. En la aplicación de configuración tenemos opciones para poder establecer la frecuencia con la que actualizar estos datos (en ms):

• Frecuencia para actualizar los paneles de Robot Data. • Frecuencia para actualizar los dispositivos de Devices. • Frecuencia para actualizar los procesos cuando hemos pulsado View Processes.

Deberemos ejecutar la aplicación de configuración antes de lanzar el cliente, y modificar estas frecuencias según nuestras necesidades. CONFIGURACIÓN Existen una serie de parámetros configurables, que podemos establecer desde la herramienta de configuración de JMR. Deberemos cargar la aplicación de configuración y seleccionar la pestaña Client Application. Al elegirla, se muestra un cuadro como el siguiente:

donde:

• Data update freq. (ms) es el período de tiempo (en ms) entre dos actualizaciones consecutivas de los paneles de datos del robot actualmente seleccionado.

• Device update freq. (ms) es el período de tiempo (en ms) entre dos actualizaciones

consecutivas de los dispositivos del robot actualmente seleccionado.

• Process update freq. (ms) es el período de tiempo (en ms) entre dos actualizaciones consecutivas de los procesos del robot actualmente seleccionado.

107

Valores pequeños de estas frecuencias proporcionarán actualizaciones constantes, aunque pueden ralentizar el funcionamiento de JMR.

108

SIMULADOR 3D Veremos ahora cómo utilizar el simulador 3D Java. Haremos un recorrido por los componentes que contiene, y veremos cómo utilizar cada uno de ellos. Asumimos que ya se sabe ejecutar la aplicación, pero en cualquier caso, para ver cómo se ejecuta, consultar los apartados previos. PANTALLA PRINCIPAL Tras ejecutar el programa simulador, aparecerá una ventana como la siguiente:

donde podemos distinguir:

• Un canvas (área en negro) donde se podrá ver el mundo y los robots que se tengan cargados.

• Una zona de menús, con los siguientes menús: o File: con las opciones para carga de datos y salir del programa:

� Load parameters: cargará los parámetros de robots � Load world: carga un mundo por donde mover a los robots. � Exit: cierra el servidor

o Cameras: habilita las distintas cámaras que se tengan definidas: � User: cámara de vista global del mundo. � Robot: las distintas cámaras de cada uno de los robots que haya

conectados. � World: las distintas cámaras que se definan en el mundo. � Show secondary viewer: abre / cierra otro visor además del que se tiene,

donde se tendrá la cámara de usuario. o Vision: para realizar distintas tareas de visión.

� Load processor for: indica el procesador que se cargará sobre el robot que se seleccione.

� About: muestra el logo e información sobre el programa.

109

CARGAR DATOS CARGAR PARÁMETROS Para cargar parámetros de un robot, elegimos la opción Load parameters del menú File. Aparecerá un cuadro de diálogo para elegir el fichero de parámetros que se quiere cargar, y una vez elegido, se establecerá dicho fichero de parámetros. De este modo, cuando se conecte algún robot sin especificar qué fichero de parámetros quiere, se le asignará el que se haya establecido con esta opción. CARGAR MUNDOS Para cargar el mundo donde se moverán los robots, elegimos la opción Load World del menú File. Con esto se abrirá un cuadro de diálogo para que elijamos el mundo a cargar. Una vez elegido, se visualizará en el canvas del servidor. Por ejemplo, el mundo simple.wld del directorio world se ve así:

Sobre este mundo se definen una serie de cámaras, que se explican en el apartado de cámaras. Una de las cámaras, la de usuario, permitirá movernos por el mundo y ver distintos puntos de vista, como se verá a en el apartado de cámaras. CÁMARAS DEFINICIÓN DE CÁMARAS El sistema tiene una cámara predefinida, que es la cámara de usuario, que se puede manipular para colocarla en distintos puntos de vista del mundo. Además, tiene las cámaras propias de cada robot (los “ojos” del robot). Para definir una cámara adicional (que se englobarían dentro del grupo World en el menú Camera), se deben definir en el fichero de configuración del mundo (ficheros

110

wld), con la sintaxis: ;camera <nombre> <X> <Y> <Z> <rotX> <rotY> <rotZ> donde:

• nombre es el nombre que le damos a la cámara • X es la coordenada X donde colocamos la cámara • Y es la coordenada Y donde colocamos la cámara • Z es la coordenada Z donde colocamos la cámara • rotX es la rotación con respecto al eje X que le damos a la cámara • rotY es la rotación con respecto al eje Y que le damos a la cámara • rotZ es la rotación con respecto al eje Z que le damos a la cámara

Para más información sobre la configuración de mundos, consultar la documentación del paquete loaders. ESTABLECIMIENTO DE LA CÁMARA ACTUAL Para determinar qué cámara utilizar en cada momento, se tiene el menú Cameras, donde podremos elegir entre:

• User: cámara de vista global del mundo. • Robot: las distintas cámaras de cada uno de los robots que haya conectados. • World: las distintas cámaras que se definan en el mundo.

Podemos añadir un segundo visor en el simulador habilitando la opción Show secondary viewer del menú Cameras. Con esto, aparecerá una zona a la derecha donde se tendrá la cámara de usuario. Así, podremos tener por un lado una cámara cualquiera (lo que ve un robot, otra vista del mundo), y por otro lado la cámara de usuario para llevar un control global. MOVIMIENTOS Podemos mover la cámara de usuario y colocarla en distintas posiciones del mundo, así como mover a los robots y dejarlos en la posición y orientación que queramos. MOVIMIENTO DE LA CÁMARA DE USUARIO Podremos mover esta cámara con las flechas y las teclas Control y Alt, de la siguiente forma:

• Para mover el mundo sobre el plano de proyección, a izquierda, derecha, arriba y abajo, usaremos las flechas sin más.

111

• Para movernos hacia adelante o hacia atrás, usaremos las flechas de arriba y abajo, con la tecla Control pulsada.

• Para rotar el mundo en un sentido u otro, sobre el plano de proyección, usaremos las teclas izquierda y derecha con la tecla Control pulsada.

• Para rotar y mirar hacia arriba abajo, izquierda o derecha de donde estamos, usaremos la flecha correspondiente, con la tecla Alt pulsada.

MOVIMIENTO DE ROBOTS Podemos mover y rotar los robots que estén en cada momento sobre el mundo, bien con la cámara de usuario o con cualquier otra cámara, mediante el ratón:

• Para mover un robot (cambiar su posición (X, Y)), se pulsa el botón derecho del ratón sobre él y luego se arrastra por el mundo. El robot se moverá también cuando arrastremos el botón derecho, y luego sólo hay que soltar el botón cuando el robot esté colocado donde queríamos. El robot se moverá con respecto al sistema de coordenadas original (si se rota el mundo, el robot seguirá moviéndose según el sistema original).

• Para rotar un robot, se pulsa el botón izquierdo sobre él, y se arrastra horizontalmente hacia un lado u otro, dependiendo del giro que queramos dar al robot.

VISOR SECUNDARIO La opción Show secondary viewer del menú Cameras permite ampliar el simulador para mostrar una nueva cámara, que es la de usuario.

De esta forma, en la parte izquierda se tendrá la misma cámara que se tenía seleccionada, y en la derecha la cámara de usuario, que permitirá una visión más global.

112

VISIÓN Podemos procesar las imágenes que capturan los distintos robots cargando un procesador de imágenes en éstos. Para ello, la opción Load processor for del menú Vision permite elegir el robot sobre el que cargar el procesador. Dicho procesador debe ser una clase que implemente jmr.robots.vision.ImageProcessor, y defina el método para procesar las imágenes. Al elegir el robot, aparecerá un cuadro de diálogo para elegir el fichero .class que contiene el procesador que queremos cargar. Mostrará todas las clases contenidas en el directorio ${jmr.home}/vision, por lo que deberemos crear nuestro procesadores de imagen en este directorio.

Una vez elegido, el procesador se dedicará a procesar las imágenes que capture la cámara del robot, y guardar junto a ellas el resultado de procesar la imagen, para enviarlo a los clientes que lo soliciten. Desde el cliente, podremos ver la imagen procesada activando el flag de Image Result en el panel del dispositivo tipo cámara en el cliente. CONFIGURACIÓN Existen una serie de parámetros configurables, que podemos establecer desde la herramienta de configuración de JMR. Deberemos cargar la aplicación de configuración y seleccionar la pestaña 3D simulator. Al elegirla, se muestra un cuadro como el siguiente:

113

donde:

• Threshold for the sonar incidente angle (Angulo umbral del sónar) es el ángulo mínimo en radianes que debe haber entre la dirección del sónar y una superficie para que la lectura producida por la superficie sea detectada por el sónar (si es menor, hay muy poco ángulo, y la señal rebota y se pierde):

• Variance for sonar reading error (Error en las lecturas del sónar) es el error que se comete en las lecturas de los sónares (la varianza). Esto se aplica para dar más realismo a los datos tomados por el robot, variando la lectura tomada con una normal de media 0 y varianza la especificada.

• Error in position estimation (Error en el avance a distancia) es el error que se comete cuando el robot avanza una determinada distancia (la varianza). Al igual que en el caso anterior, sirve para dar más realismo a las acciones del robot, variando la distancia con una normal de media 0 y varianza la especificada.

• Error in orientation estimation (Error en el cambio de orientación) es el error que se comete cuando el robot cambia de orientación (gira). Al igual que en el caso anterior, sirve para dar más realismo a las acciones del robot, variando la orientación con una normal de media 0 y varianza la especificada.

• Variance for velocity errors (Error en la velocidad trasnacional) es el error que se comete al determinar la velocidad lineal del robot. Al igual que en el caso anterior, sirve para dar más realismo a las acciones del robot, variando la velocidad con una normal de media 0 y varianza la especificada.

114

• Variance for rotation errors (Error en la velocidad rotacional) es el error que se comete al determinar la velocidad rotacional del robot. Al igual que en el caso anterior, sirve para dar más realismo a las acciones del robot, variando la velocidad con una normal de media 0 y varianza la especificada.

• Installed devices configuration file indica la localización del fichero de definición de los dispositivos que estamos utilizando en el Simulador 3D.

• IP address es la dirección IP a la que se enlazará el servidor • Port es el puerto donde el servidor permanecerá a la escucha de peticiones de

conexión mediante RMI. El fichero de configuración del simulador se encuentra en el fichero de configuración de JMR en ${jmr.home}/conf/jmr.conf. De ahí se leerán y ahí se escribirán los valores de los parámetros de la configuración. Los parámetros de configuración del Simulador 3D tienen todos el prefijo sim.*. SERVIDOR SAPHIRA Veremos ahora cómo utilizar el servidor Saphira. Asumimos que ya se sabe ejecutar la aplicación, pero en cualquier caso, para ver cómo se ejecuta, consultar los apartados previos. FUNCIONAMIENTO Una vez ejecutado, el programa no tiene ninguna parte visual ni más opciones para el usuario. Simplemente basta con tener preparado el simulador Pioneer o el robot real al que se quiere conectar, y realizar la conexión desde alguna aplicación cliente. Así pues, no se podrán realizar tareas como definir cámaras en el mundo (puesto que sólo se cuenta con la cámara del único robot que podemos conectar). Sí se podrá procesar la imagen que captura la cámara del robot, añadiendo un procesador. No se tiene el menú para hacerlo, como en el caso del simulador 3D, pero también se pueden añadir procesadores desde el código de los procesos, tomando el dispositivo de tipo cámara y añadiendo el procesador. CONFIGURACIÓN Existen una serie de parámetros configurables, que podemos establecer desde la herramienta de configuración de JMR. Deberemos cargar la aplicación de configuración y seleccionar la pestaña Saphira server. Al elegirla, se muestra un cuadro como el siguiente:

115

donde:

• IP address es la dirección IP de la máquina desde la que se lanzará el servidor. • Port es el puerto por que el que se quedará escuchando el servidor. • Params directory es el directorio donde se encuentran los ficheros de parámetros • Default params file es el fichero de parámetros que se establecerá por defecto en

caso de que no se especifique ninguno • Default devices file es el fichero por defecto donde se guardarán los dispositivos

que tendrán los robots que se conecten a un servidor Saphira.

116

Bibliografía.

[1] http://www.Yucatan.com.mx/especiales/celular/historia.asp [2] http://www.Yucatán.com.mx/especiales/celular/3g.asp [3] http://www.geocities.com/Sunsetstrip/Amphitheatre/3064/Celular.html. [4] http://www.Yucatan.com.mx/especiales/celular/comofunciona.asp [5] http://www.wikipedia.org/wiki/DTMF [6] http://www.telefonos-moviles.com/articles/item.asp?ID=25 [7] http://www.todomovil.net/gsm/historia.asp [8] http://www.telefonos-moviles.com/articles/item.asp?ID=30 [9] http://es.gsmbox.com/GSM/SMS/info-descrizione. [10] http://congreso.hispalinux.es/congreso2001/actividades/ponencias/seco/ html/introduccion.html. [11] http://www.nokia.es/telefonos/tecnologias/mms_faq.jsp [12] http://webs.sinectis.com.ar/mcagliani/hrobot.htm. [13] http://usuarios.bitmailer.com/aperobot/robothistoriatecno.htm [14] http://activrobots.com

[15] http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/multiple-

html/c12.html [16] http://hypertextbook.com/physics/waves/beats/index.shtml. [17] http://users.telenet.be/educypedia/electronics/telephone.htm [18] http://www.rvg.dccia.ua.es/jmr/index.html [19] http://www.dage.net/dtmf_tut.html. [20] http://usuarios.bitmailer.com/aperobot/robots.htm

117

[21] http://es.gsmbox.com/wap/come.gsmbox [22] http://www.3gamericas.org/Spanish/Technology_Center/GSM_sp.cfm [23] http://www.3gamericas.org/Spanish/Technology_Center/gsmfacts_sp.cfm. [24] http://www.3gamericas.org/spanish/technology_center/qa/gsmqa_sp.cfm [25] http://www.todomovil.net/gsm/historia.asp [26] http://www.hackhispano.com/oldhh/paginas/gsm/gsm_02.htm [27] http://www.hackhispano.com/oldhh/paginas/gsm.htm. [28] http://www.progres-spain.com/espanyol/avisadorgsm.html. [29] http://www.cept.org [30] http://www.metc.pku.edu.cn/melab/publications/mepaper04.pdf [31] http://www.cat.csiro.au/cmst/automation [32] http://ccc.inaoep.mx/~rodrigo/robotica/Robotica.htm [33] http://www.todomovil.net/gsm/art1.asp [34] http://www.melodiasmoviles.com/documentacion/intro-gsm.php

118

[35] Overview of the GSM System and protocol Architecture Moe Rahnema IEEE Communication Magazine April 1993. [36] Saphira Software Manual

Saphira Versión 8.0a Saphira/Aria integration Kart G. Konolige. SRI International, Menlo Park, California.

[37] Player Version 1.3.1 User Manual Brian P. Gerkey Richard T. Vaughan Andrew Howard December 4, 2002 [38] Java Mobile Robots (JMR). Manual del Programador versión 2.0

Domingo Gallardo López Ignacio Iborra Baeza Miguel Ángel Lozano Ortega. Departamento de Ciencia de la Computación e Inteligencia Artificial Universidad de Alicante Febrero 2003.

[39] Java 1.2 al descubierto Jaime Jaworsky Prentice Hall

[40] El lenguaje de programación java Fco. Javier Ceballos

Ra_Ma [41] Java en pocas palabras David Flanagan Mc Graw Hill [42] Manual Avanzado Java 2 Felipe Lima DIAN

Edición 2000 Editorial Anaya Multimedia

[43] Introducción a Java Presentación de Java y Hot Java

Prentice Hall Jhon December

[44] Manual de Java

Patrick Naughton Osborne Mc Graw Hill.

119

[45] TELEASISNET: Sistema de tele-asistencia basado en un robot asistencial R.Barea, L. M. Bergasa, E. López, M. Escudero, J. A. Hernández e

Y. Willemaers. CD del SAAEI-EPF`04, Toulouse, 15-17 Sep. 2004.

[46] SISTEMA DE TRANSMISION-RECEPCION DESDE UN ROBOT AUTONOMO E INTELIGENTE HACIA ACCIONAMIENTOS A

TRAVÉS DE LA RED ELECTRICA Ignacio Bravo, Fernando Méndez, Esteban Basagoitia, Luis Miguel Bergasa CD del SAAEI-EPF`04 Toulouse, 15-17 Sep. 2004.

[47] Control y Monitorización de Vivienda Inteligente Mediante SMS J. A. Vera, M. Jiménez, y J. Roca CD del SAAEI 2003, 11 y 12 de Sep 2003 [48] A. Ribeiro; R. Gz-Bueno; M. C. García-Alegre; D. Guinea “Environment and Industrial Data Management System of a Net of Sensor Nodes in Industrial Sites” Proc. Geospatial World 2003, New Orleans (USA), 19-21 May 2003 [49] M. C. García-Alegre (;) R. González-Bueno (;) A. Ribeiro (;) D. Guinea “Sistema de información, vigilancia y Control Atmosférico de un polígono Industrial”

6º Congreso Nacional de Medio Ambiente, CDROM. Madrid Noviembre 2002.

tes730

Documents