FACULTAD DE CIENCIAS FISICAS, QUIMICAS Y MATEMATICAS CARRERA PROFESIONAL DE INGENIERÍA INFORMATICA Y DE SISTEMAS TEMA: CURSO : Robótica y Procesamiento de Señal DOCENTE : Ing. José Pillco ALUMNOS : - Rivero Túpac Edith Pamela 062854 - Flores Carbajal José Carlos Envío de un fotografía a través de una comunicación de Celular a PC
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
FACULTAD DE CIENCIAS FISICAS, QUIMICAS Y MATEMATICAS
CARRERA PROFESIONAL DE INGENIERÍA INFORMATICA Y DE SISTEMAS
TEMA:
CURSO : Robótica y Procesamiento de Señal
DOCENTE : Ing. José Pillco ALUMNOS :
- Rivero Túpac Edith Pamela 062854
- Flores Carbajal José Carlos 062842
- Álvarez Carbajal Giomar 060564
CUSCO – PERÚ
2012
Envío de un fotografía a través de una comunicación de Celular a PC
BLUETOOTH
Bluetooth es un estándar de factor global que identifica un conjunto de protocolos que facilitan la comunicación inalámbrica entre diferentes tipos de dispositivos electrónicos.
Bluetooth es una tecnología de radio de corto alcance, que permite conectividad inalámbrica entre dispositivos remotos. Se diseñó pensando básicamente en tres objetivos:
• Pequeño tamaño.• Mínimo consumo.• Bajo precio.
Bluetooth opera en la banda libre de radio ISM a 2.4 Ghz. Su máxima velocidad de transmisión de datos es de 1 Mbps. El rango de alcance Bluetooth depende de la potencia empleada en la transmisión. La mayor parte de los dispositivos que usan Bluetooth transmiten con una potencia nominal de salida de 0 dBm, lo que permite un alcance de unos 10 metros en un ambiente libre de obstáculos.
Los paquetes de datos están protegidos por un esquema ARQ (repetición automática de consulta), en el cual los paquetes perdidos son automáticamente retransmitidos.
CLASIFICACIÓN
Estos dispositivos se clasifican en referencia a su potencia de transmisión, siendo totalmente compatibles los dispositivos de una clase con los de las otras.
Bluetooth v.1.1.- En 1994, Ericsson inició un estudio para investigar la viabilidad de una nueva interfaz de bajo costo y consumo para la interconexión vía radio (eliminando así cables) entre dispositivos como teléfonos móviles y otros accesorios.
Bluetooth v.1.2.- A diferencia de la 1.1, provee una solución inalámbrica complementaria para co-existir Bluetooth y Wi-Fi en el espectro de los 2.4 GHz, sin interferencia entre ellos. La versión 1.2 usa la técnica "Adaptive Frequency Hopping (AFH)", que ejecuta una transmisión más eficiente y un cifrado más seguro.
Bluetooth v.2.0.- Creada para ser una especificación separada, principalmente incorpora la técnica "Enhanced Data Rate" (EDR) que le permite mejorar las velocidades de transmisión en hasta 3Mbps a la vez que intenta solucionar algunos errores de la especificación 1.2.
Bluetooth v.2.1.- simplifica los pasos para crear la conexión entre dispositivos, además el consumo de potencia es 5 veces menor.
Bluetooth v3.0.- Aumenta considerablemente la velocidad de transferencia. La idea es que el nuevo Bluetooth trabaje con WiFi, de tal manera que sea posible lograr mayor velocidad en los smartphones.
Pila de Protocolos
Uno de los principales objetivos de la tecnología bluetooth es conseguir que aplicaciones de fabricantes mantengan una comunicación fluida. Para diferentes conseguirlo, receptor y transmisor deben ejecutarse sobre la misma pila de protocolos.
La pila está constituida por dos clases de protocolos. Una primera clase llamada de protocolos específicos que implementa los protocolos propios de Bluetooth. Y una segunda clase formada por el conjunto de protocolos adoptados de otras especificaciones. Esta división en clases en el diseño de la pila de protocolos de Bluetooth permite aprovechar un conjunto muy amplio de ventajas de ambas. Por un lado, al implementar protocolos específicos de Bluetooth permite utilizar los beneficios que aporta la adopción de la tecnología Bluetooth. Por otro lado la utilización de protocolos no específicos ofrece la ventaja de la interacción de esta tecnología con protocolos comerciales ya existentes. Así como la posibilidad de que Bluetooth este abierto a implementaciones libres o nuevos protocolos de aplicación de uso común. La pila de protocolos se puede dividir en cuatro capas lógicas:
Núcleo de Bluetooth: Radio, Banda Base, LMP, L2CAP, SDP Sustitución de cable: RFCOMM Protocolos adoptados: PPP, UDP, TCP, IP, OBEX, WAP, IRMC, WAE Control de telefonía: TCS-binary, AT-Commands Pese a que el núcleo de bluetooth fue desarrollado en su totalidad por la
SIG, algunos protocolos como RFCOMM y TCS-binary han sido desarrollados siguiendo las recomendaciones de otras instituciones de telecomunicaciones.
EL CANAL
Bluetooth utiliza un sistema FH/TDD (salto de frecuencia/división de tiempo duplex), en el que el canal queda dividido en intervalos de 625 μs, llamados slots, donde cada salto de frecuencia es ocupado por un slot.
Dos o más unidades Bluetooth pueden compartir el mismo canal dentro de una piconet (pequeña red que establecen automáticamente los terminales Bluetooth para comunicarse entre si), donde una unidad actúa como maestra, controlando el tráfico de datos en la piconet que se genera entre las demás unidades, donde éstas actúan como esclavas, enviando y recibiendo señales hacia el maestro.
DATAGRAMA BLUETOOTH
La información que se intercambia entre dos unidades Bluetooth se realiza mediante un conjunto de slots que forman un paquete de datos. Cada paquete comienza con un código de acceso de 72 bits, que se deriva de la identidad maestra, seguido de un paquete de datos de cabecera de 54 bits. Éste contiene importante información de control, como tres bits de acceso de dirección, tipo de paquete, bits de control de flujo, bits para la retransmisión automática de la pregunta, y chequeo de errores de campos de cabecera. La dirección del dispositivo es en forma hexadecimal. Finalmente, el paquete que contiene la información, que puede seguir al de la cabecera, tiene una longitud de 0 a 2745 bits.
Datagramas Bluetooth
En cualquier caso, cada paquete que se intercambia en el canal está precedido por el código de acceso. Los receptores de la piconet comparan las señales que reciben con el código de acceso, si éstas no coinciden, el paquete recibido no es considerado como válido en el canal y el resto de su contenido es ignorado.
PICONETS
Como hemos citado anteriormente si un equipo se encuentra dentro del radio de cobertura de otro, éstos pueden establecer conexión entre ellos. Cada dispositivo tiene una dirección única de 48 bits, basada en el estándar IEEE 802.11 para WLAN. En principio sólo son necesarias un par de unidades con las mismas características de hardware para establecer un enlace. Dos o más unidades Bluetooth que comparten un mismo canal forman una piconet.
JAVA
Sun, dispuesto a proporcionar las herramientas necesarias para cubrir las necesidades de todos los usuarios, creó distintas versiones de Java de acuerdo a las necesidades de cada uno. Según esto nos encontramos con que el paquete Java 2 lo podemos dividir en 3 ediciones distintas. J2SE (Java Standard Edition) orientada al desarrollo de aplicaciones
independientes de la plataforma, J2EE (Java Enterprise Edition) orientada al entorno empresarial y J2ME (Java Micro Edition) orientada a dispositivos con capacidades restringidas. Veamos cuáles son las características de cada una de las versiones:
Java 2 Platform, Standard Edition (J2SE):
Esta edición de Java es la que en cierta forma recoge la iniciativa original del lenguaje Java.
Esta versión de Java contiene el conjunto básico de herramientas usadas para desarrollar Java Applets, así como las APIs orientadas a la programación de aplicaciones de usuario final: Interfaz gráfica de usuario, multimedia, redes de comunicación, etc.
Java 2 Platform, Enterprise Edition (J2EE):
Esta versión está orientada al entorno empresarial. El software empresarial tiene unas características propias marcadas: está pensado no para ser ejecutado en un equipo, sino para ejecutarse sobre una red de ordenadores de manera distribuida y remota mediante EJBs (Enterprise Java Beans).
Java 2 Platform, Micro Edition (J2ME):
Esta versión de Java está enfocada a la aplicación de la tecnología Java en dispositivos electrónicos con capacidades computacionales y gráficas muy reducidas, tales como teléfonos móviles, PDAs o electrodomésticos inteligentes. Esta edición tiene unos componentes básicos que la diferencian de las otras versiones, como el uso de una máquina virtual denominada KVM (Kilo Virtual Machine, debido a que requiere sólo unos pocos Kilobytes de memoria para funcionar) en vez del uso de la JVM clásica, inclusión de un pequeño y rápido recolector de basura.
Figura 1.1 Arquitectura de la plataforma Java 2 de Sun
ESTABLECIMIENTO DE LA CONEXIÓN
La conexión con un dispositivo, se hace mediante un mensaje page. Si la dirección es desconocida, antes del mensaje page se necesitara un mensaje inquiry. Antes de que se produzca ninguna conexión, se dice que todos los dispositivos están en modo standby.
Un dispositivo en modo standby se despierta cada 1.28 segundos para escuchar posibles mensajes page/inquiry. Cada vez que un dispositivo se despierta, escucha una de las 32 frecuencias de salto definidas. Un mensaje de tipo page, será enviado en 32 frecuencias diferentes. Primero el mensaje es enviado en las primeras 16 frecuencias (128 veces), y si no se recibe respuesta, el maestro mandará el mensaje page en las 16 frecuencias restantes (128 veces). El tiempo máximo de intento de conexión es de 2.56 segundos.
Estados
En el estado conectado, el dispositivo Bluetooth puede encontrarse en varios modos de operación:
Active mode
En este modo, el dispositivo Bluetooth participa activamente en el canal.
Sniff mode
En este modo, el tiempo de actividad durante el cual el dispositivo esclavo escucha se reduce. Esto significa que el maestro sólo puede iniciar una transmisión en unos slots de tiempo determinados.
Hold mode
En el estado conectado, el enlace con el esclavo puede ponerse en espera. Durante este modo, el esclavo puede hacer otras cosas, como escanear en busca de otros dispositivos, atender otra piconet, etc.
Park mode
En este estado, el esclavo no necesita participar en la piconet, pero aún quiere seguir sincronizado con el canal. Deja de ser miembro de la piconet. Esto es
útil por si hay más de siete dispositivos que necesitan participar ocasionalmente en la piconet.
APIs JAVA PARA BLUETOOTH
Mientras que el hardware Bluetooth había avanzado mucho, hasta hace relativamente poco no había manera de desarrollar aplicaciones java Bluetooth hasta que apareció JSR 82, que estandarizó la forma de desarrollar aplicaciones Bluetooth usando Java. Ésta esconde la complejidad del protocolo Bluetooth detrás de unos APIs que permiten centrarse en el desarrollo en vez de los detalles de bajo nivel del Bluetooth.
Estos APIs para Bluetooth están orientados para dispositivos que cumplan las siguientes características:
Al menos 512K de memoria libre (ROM y RAM) (las aplicaciones necesitan memoria adicional).
Conectividad a la red inalámbrica Bluetooth. Que tengan una implementación del J2ME CLDC.
JSR 82
El objetivo de ésta especificación era definir un API estándar abierto, no propietario que pudiera ser usado en todos los dispositivos que implementen J2ME. Por consiguiente fue diseñado usando los APIs J2ME y el entorno de trabajo CLDC/MIDP.
Los APIs JSR 82 son muy flexibles, ya que permiten trabajar tanto con aplicaciones nativas Bluetooth como con aplicaciones Java Bluetooth.
El API intenta ofrecer las siguientes capacidades:
• Registro de servicios.• Descubrimiento de dispositivos y servicios.• Establecer conexiones RFCOMM, L2CAP y OBEX entre dispositivos.• Usar dichas conexiones para mandar y recibir datos (las comunicaciones
de voz no• están soportadas).• Manejar y controlar las conexiones de comunicación.• Ofrecer seguridad a dichas actividades.
Los APIs Java para Bluetooth definen dos paquetes que dependen del paquete CLDC javax.microedition.io:
javax.bluetooth. javax.obex.
PROGRAMACION DE APLICACIONES PARA BLUETOOTH
La anatomía de una aplicación Bluetooth está dividida en cuatro partes:
• Inicialización de la pila.• Descubrimiento de dispositivos y servicios.• Manejo del dispositivo.• Comunicación.
INICIALIZACION
B CC (Bluetooth Control Center)
El BCC previene que una aplicación pueda perjudicar a otra. El BCC es un conjunto de capacidades que permiten al usuario o al OEM2 resolver peticiones conflictivas de aplicaciones definiendo unos valores específicos para ciertos parámetros de la pila Bluetooth.
El BCC puede ser una aplicación nativa, una aplicación en un API separado, o sencillamente un grupo de parámetros fijados por el proveedor que no pueden ser cambiados por el usuario. Hay que destacar, que el BCC no es una clase o un interfaz definido en esta especificación, pero es una parte importante de su arquitectura de seguridad.
Inicialización de la pila
La pila Bluetooth es la responsable de controlar el dispositivo Bluetooth, por lo que es necesario inicializarla antes de hacer cualquier otra cosa. El proceso de
inicialización consiste en un número de pasos cuyo propósito es dejar el dispositivo listo para la comunicación inalámbrica.
Desafortunadamente, la especificación deja la implementación del BCC a los vendedores, y cada vendedor maneja la inicialización de una manera diferente. En un dispositivo puede haber una aplicación con un interfaz GUI, y en otra puede ser una serie de configuraciones que no pueden ser cambiados por el usuario.
DISCOVERY
Dado que los dispositivos inalámbricos son móviles, necesitan un mecanismo que permita encontrar, conectar, y obtener información sobre las características de dichos dispositivos.
En este apartado, vamos a tratar como el API de Bluetooth permite realizar todas estas tareas.
Descubrir Dispositivos (Device discovery)
Cualquier aplicación puede obtener una lista de dispositivos a los que es capaz de encontrar, usando, o bien startInquiry() (no bloqueante) o retrieveDevices() (bloqueante). startInquiry() requiere que la aplicación tenga especificado un listener, el cual es notificado cuando un nuevo dispositivo es encontrado después de haber lanzado un proceso de búsqueda. Por otra parte, si la aplicación no quiere esperar a descubrir dispositivos (o a ser descubierta por otro dispositivo) para comenzar, puede utilizar retrieveDevices(), que devuelve una lista de dispositivos encontrados en una búsqueda previa o bien unos que ya conozca por defecto.
Descubrir Servicios (Service Discovery)
Este API no da soporte para buscar servicios que estén ubicados en el propio dispositivo.
Para descubrir los servicios disponibles en un dispositivo servidor, el cliente primero debe recuperar un objeto que encapsule funcionalidad SDAP5 (SDP6 + GAP7, se verá más adelante). Este objeto es del tipo DiscoveryAgent, cuyo pseudocódigo viene dado por:
DiscoveryAgent da = LocalDevice.getLocalDevice().getDiscoveryAgent();
Clases del Service Discovery:
class javax.bluetooth.UUID
Esta clase encapsula enteros sin signo que pueden ser de 16, 32 ó 128 bits de longitud. Estos enteros se usan como un identificador universal cuyo valor representa un atributo del servicio.
sólo los atributos de un servicio representados con UUID están representados en la Bluetooth SDP.
class javax.bluetooth.DataElement
Esta clase contiene varios tipos de datos que un atributo de servicio Bluetooth puede usar. Algunos de estos son:
• String
• boolean
• UUID
• Enteros con signo y sin signo, de uno, dos, cuatro o seis bytes de longitud
• Secuencias de cualquiera de los tipos anteriores.
Esta clase además presenta una interfaz que permite construir y recuperar valores de un atributo de servicio.
class javax.bluetooth.DiscoveryAgent
Esta clase provee métodos para descubrir servicios y dispositivos.
interface javax.bluetooth.ServiceRecord
Este interfaz define el Service Record de Bluetooth, que contiene los pares (atributo ID, valor). El atributo ID es un entero sin signo de 16 bits, y valor es de tipo DataElement. Además, este interfaz tiene un método populateRecord() para recuperar los atributos de servicio deseados (pasando como parámetro al método el ID del atributo deseado).
interface javax.bluetooth.DiscoveryListener
Este interfaz permite a una aplicación especificar un listener que responda a un evento del tipo Service Discovery o Device Discovery. Cuando un nuevo servicio es descubierto, se llama al método servicesDiscovered(), y cuando la transacción ha sido completada o cancelada se llama a serviceSearchCompleted().
Registro del Servicio
Las responsabilidades de una aplicación servidora de Bluetooth son:
1. Crear un Service Record que describa el servicio ofrecido por la aplicación.
2. Añadir el Service Record al SDDB del servidor para avisar a los clientes potenciales de este servicio.
3. Registrar las medidas de seguridad Bluetooth asociadas a un servicio.
4. Aceptar conexiones de clientes que requieran el servicio ofrecido por la aplicación.
5. Actualizar el Service Record en el SDDB del servidor si las características del servicio cambian.
6. Quitar o deshabilitar el Service Record en el SDDB del servidor cuando el servicio no está disponible.
A las tareas 1, 2, 5 y 6 se las denominan registro del servicio (Service Registration), que comprenden unas tareas relacionadas con advertir al cliente de los servicios disponibles.
COMUNICACIÓN
Para usar un servicio en un dispositivo Bluetooth remoto, el dispositivo local debe comunicarse usando el mismo protocolo que el servicio remoto. Los APIs permiten usar RFCOMM, L2CAP u OBEX como protocolo de nivel superior El Generic Connection Framework (GFC) del CLDC rovee la conexión base para la implementación de protocolos de comunicación. CLDC provee de los siguientes métodos para abrir una conexión:
Connection Connector.open(String name);
Connection Connector.open(String name, int mode);
Connection Connector.open(String name, int mode, boolean timeouts);
La implementación debe soportar abrir una conexión con una conexión URL servidora o con una conexión URL cliente, con el modo por defecto READ_WRITE.
Perfil del puerto serie (SPP)
El protocolo RFCOMM provee múltiples emulaciones de los puertos serie RS-232 entre dos dispositivos Bluetooth. Las direcciones Bluetooth de los dos puntos terminales definen una sesión RFCOMM. Una sesión puede tener más de una conexión, el número de conexiones dependerá de la implementación. Un dispositivo podrá tener más de una sesión RFCOMM en tanto que esté conectado a más de un dispositivo.
PROTOCOLO DE INTERCAMBIO DE OBJETOS (OBEX)
Este es un protocolo diseñado por el IrDA (Infrared Data Association) para intercambiar objetos entre clientes y servidores, mediante el establecimiento de una sesión OBEX. En vez de incluir esta funcionalidad en el API Bluetooth, se ha optado por extender el API OBEX y dar soporte a Bluetooth. Nosotros vamos a centrarnos únicamente en el soporte Bluetooth.
Un vistazo al API
OBEX, como HTTP, tiene métodos que le permiten pasar información adicional entre el cliente y el servidor mediante el uso de cabeceras.
J2ME (Java 2 Platform, Micro Edition)
Esta versión de Java está enfocada a la aplicación de la tecnología Java en dispositivos electrónicos con capacidades computacionales y gráficas muy reducidas, tales como teléfonos móviles, PDAs o electrodomésticos inteligentes.
Nociones básicas de J2ME
Ya hemos visto qué es Java Micro Edition y la hemos enmarcado dentro de la plataforma Java2. En este apartado vamos a ver cuales son los componentes que forman parte de esta tecnología.
• Por un lado tenemos una serie de máquinas virtuales Java con diferentes requisitos, cada una para diferentes tipos de pequeños dispositivos.
• Configuraciones, que son un conjunto de clases básicas orientadas a conformar el corazón de las implementaciones para dispositivos de características específicas. Existen 2 configuraciones definidas en J2ME:
Connected Limited Device Configuration (CLDC) enfocada a dispositivos con restricciones de procesamiento y memoria, y Connected Device
Configuration (CDC) enfocada a dispositivos con más recursos.
• Perfiles, que son unas bibliotecas Java de clases específicas orientadas a implementar funcionalidades de más alto nivel para familias específicas de dispositivos.
Un entorno de ejecución determinado de J2ME se compone entonces de una selección de:
a) Máquina virtual.
b) Configuración.
c) Perfil.
d) Paquetes Opcionales.
La CDC está basada en J2SE v1.3 e incluye varios paquetes Java de la edición estándar. Las peculiaridades de la CDC están contenidas principalmente en el paquete javax.microedition.io, que incluye soporte para comunicaciones http y basadas en datagramas.
ARQUITECTURA DE LA APLICACIÓN
La aplicación está desarrollada en 2 plataformas java J2SE y J2ME:
J2SE no tiene disponible librerías para la utilización de bluetooth es por eso que se utilizará un driver que implementará la especificación JR82
ESQUEMA DEL PROYECTO
EL proyecto asignado básicamente manda señales del computador a un dispositivo móvil mediante un enlace inalámbrico, que en este caso el bluetooth estas señales son procesadas por el computador y envía mensajes al celular y viceversa, la aplicación hará que interactúen y que el celular pueda enviar la fotografía al computador para su analisis.
A continuación se muestra los patrones con los que se trabajo:
J2ME
J2SE y J2ME
PC
Primer patrón Segundo patrón Tercer patrón
Ahora se ejecuta el Procesador de Imágenes en el Servidor y luego se ejecuta SenClient en el celular .
En seguida se muestra la imagen que se tomo con el celular:
A continuación se muestra el programa en ejecución:
Luego realizamos la conexión del celular con la PC para que muestre la imagen tomada, la cual mostrará de la siguiente manera:
Luego la imagen binarizada se encuentra en la parte inferior del NetBeans y se mostraría de la siguiente manera:
Y por ultimo llega un mensaje al celular indicando que existen dos círculos e indicando los errores que tienen respecto de los patrones:
Nota: Todo el proceso se encuentra en la página: http://www.youtube.com/watch?v=WWj-4WCTN6U
A)El código para el servidor consta en 3 partes:
1.-ProcesadorImagenes:
/*
* To change this template, choose Tools | Templates
* Switches a current displayable in a display. The <code>display</code> instance is taken from <code>getDisplay</code> method. This method is used by all actions in the design for switching displayable.
* @param alert the Alert which is temporarily set to the display; if <code>null</code>, then <code>nextDisplayable</code> is set immediately
* @param nextDisplayable the Displayable to be set
*/
public void switchDisplayable(Alert alert, Displayable nextDisplayable) {
// write pre-switch user code here
Display display = getDisplay();
if (alert == null) {
display.setCurrent(nextDisplayable);
} else {
display.setCurrent(alert, nextDisplayable);
}
// write post-switch user code here
}
//</editor-fold>
//<editor-fold defaultstate="collapsed" desc=" Generated Method: commandAction for Displayables ">
/**
* Called by a system to indicated that a command has been invoked on a particular displayable.
* @param command the Command that was invoked
* @param displayable the Displayable where the command was invoked
*/
public void commandAction(Command command, Displayable displayable) {