DISEÑO E IMPLEMENTACION DE UN ROBOT TELE-OPERADO USANDO LA INTERFACE DE COMUNICACIÓN INALAMBRICA ZIGBEE

Transcripción

1 1 DISEÑO E IMPLEMENTACION DE UN ROBOT TELE-OPERADO USANDO LA INTERFACE DE COMUNICACIÓN INALAMBRICA ZIGBEE López Calderón, Tatiana, Arcila Mora, Alejandro, Capacho V., Luis Miguel tlopezc@uniquindio.edu.co, aarcilam@uniquindio.edu.co, lmcapacho@uniquindio.edu.co Universidad del Quindío. Resumen Este artículo presenta el diseño e implementación de un robot tele-operado usando el protocolo de comunicación IEEE (ZigBee). El robot manipulado cuenta con control de dirección, bocina y frenos. La tele-operación se realiza a través de una aplicación de escritorio, la cual envía los comandos que permiten manipular el robot vía USB. Cada sistema esta controlado por un ATmega16, usando para ello la tarjeta ucsboard-mega16 desarrollada en el programa de Ingeniera Electrónica de la Universidad del Quindío. Índice de Términos ATmega16, IEEE , Robot tele-operado, ucsboard-mega16, Universal Serial Bus. I. INTRODUCCIÓN Un robot tele-operado permite ser manejado desde cierta distancia a través de otra maquina, en este caso un computador. El sistema tele-operado implementado consta de cuatro bloques fundamentales como se muestra en la figura 1. Computador Receptor Transmisor Carro Fig. 1. Diagrama de bloques del robot tele-operado La interfaz para el manejo del robot es creada usando el framework wxwidgets[5], el cual posee los botones necesarios para manipular cada uno de los comandos desde el computador. Los comandos de manejo se envían a un microcontrolador, el cual sirve como intermediario para la comunicación inalámbrica del módulo zigbee (MRF24J40MB) haciendo uso de la comunicación serial síncrona SPI, siendo este el transmisor. La recepción cuenta con otro modulo zigbee que funciona como esclavo además de otro microcontrolador que efectúa la tarea correspondiente según el comando recibido. II. ZIGBEE Zigbee es estándar de comunicación de bajo consumo, basado en el estándar IEEE de redes inalámbricas de área personal (WPAN). Su us son en aplicaciones que requieren comunicaciones seguras con baja tasa de envió de datos y maximización de la vida útil de sus baterías. El manejo del módulo zigbee es la parte fundamental de todo el sistema. A continuación se describen las características del módulo usado para la transmisión y recepción. A. Transferencia de datos por SPI El módulo MRF24J40MB es un transreceptor que permite realizar la transmisión y recepción de datos a través del protocolo de comunicación IEEE , más conocido como zigbee. Para acceder a los registros internos del módulo, se cuenta con una interfaz SPI. Pueden existir dos modos de trasmisión, las cuales son de direccionamiento corto y de direccionamiento largo, esto es: 1) Transmisión SPI de direccionamiento cortó: Las transferencias cortas del MRF24J40MB son de 8 bits y se definen así:

2 2 Bit 7: definido en 0 indicando que es una operación de direccionamiento corto. Bits 6-1: registro de dirección de 6 bits. Bit 0: al estar en 1 indicara que es una transferencia de escritura, pero si esta en 0 será una transferencia de lectura. mediante del código de redundancia cíclica (CRC) durante la transmisión verificando los datos recibidos, sin embargo la trama se escribe en el búfer de recepción por lo que puede ser evaluada por el controlador de host si es necesario. 2) Transmisión SPI de direccionamiento largo: Para este tipo de transferencias las tramas son de 12 bits y están dadas por: Bit 11: definido en 1 para indicar que es una operación de direccionamiento largo. Bit 10-1: registro de dirección de 10 bits. Bit 0: Al igual que el direccionamiento corto 1 indicara que es una transferencia de escritura y 0 será una transferencia de lectura. 2) Longitud de la trama: Define el tamaño de la trama excluyendo su tamaño, el del preámbulo y el del FDS, incluye el resto de bytes. El formato de la trama de paquetes [1] enviados por el protocolo IEEE se puede observar en la figura 2. 3) Marco de control: Define el tipo de trama (Beacon, ACK, entre otros), los modos de direccionamiento utilizados si la trama esta codificada y requiere una confirmación. Toda esta información la utiliza el host para determinar la forma de decodificación. 4) Secuencia numérica: Se encarga de comparar las tramas para el proceso de reconocimiento de estas. Por ejemplo una trama ACK no contiene información de direccionamiento, por lo que la singularidad de ese número es el único factor determinante para que la trama llegue a su destino. 5) Dirección de destino y fuente: Estas varían dependiendo del marco de control de la trama, pues la dirección puede que sea corta o larga, en todos los casos donde se especifica una dirección es necesario que la red de área personal (PAN) también sea especificada. 6) Carga útil de datos: Puede variar en longitud, las tramas que exceden los 127 bytes incluyen el marco de control, la dirección de destino y fuente y el código de redundancia cíclica (CRC). Fig. 2. Formato de la trama IEEE Los 7 ámbitos se definen de la siguiente forma: 1) Preámbulo: Este se genera automáticamente haciendo que el host no tenga que ocuparse de ello, funciona como un filtrado por modulo 7) Código de redundancia cíclica (CRC): Este código utiliza la aritmética modular para detectar una mayor cantidad de errores, se usan operaciones en módulo 2 y las sumas y restas se realizan sin acarreo. Además, para facilitar los cálculos se trabaja, aunque sólo teóricamente, con polinomios. Debe ser un método sistemático, es decir, que con un mismo código a transmitir (y un

3 mismo polinomio generador) se genere siempre el mismo código final. III. TIPO DE DISPOSITIVOS Según su papel en la red los zigbee se pueden utilizar de tres formas diferentes: 1) Como coordinador zigbee (ZC): El tipo de dispositivo más completo. Debe existir uno por red y sus funciones son las de encargarse de controlar la red y los caminos q deben seguir los dispositivos para conectarse a ellos. Como router zigbee (ZR): Interconectar dispositivos separados en la topología de la red, además de ofrecer un nivel de aplicación para la ejecución de código de usuario. 2) Como dispositivo final (ZED): Posee la funcionalidad necesaria para comunicarse con su nodo padre (coordinador o router), pero no puede transmitir información destinada a otros dispositivos, de esta forma este tipo de nodo puede estar en modo sleep la mayor parte de tiempo aumentando la vida media de sus baterías. 3) En este caso en especial solo se usan dos de ellas, como coordinador zigbee y como dispositivo final ya que serán solamente una conexión directa zigbee a zigbee. IV. TRANSMISION IEEE PC USB USB Board_Mega16 SPI MRF24J40MB Fig 3. Estructura básica de transmisión 3 entrada/salida como el USB, se debió hacer uso de la librería V-USB [4], la cual logra emular estas características; teniendo en cuenta que el hardware necesario para que se pueda llevar a cabo una conexión exitosa debe contar con unos cuantos diodos y resistencias, con el fin de hacerle saber al host (PC) que será una transferencia USB 1.1, es decir a una velocidad de 1.5 Mbps. La transferencia usada es una transferencia de control, donde los datos son enviados a través del paquete setup del protocolo USB. Dadas las necesidades del sistema, se opto por hacer uso de la tarjeta de desarrollo ucsboard-mega16 la cual se adaptaba a los requerimientos planteados. El diagrama de flujo correspondiente al código implementado en el computador se puede apreciar en la figura 4. Primero se inicializa la librería, luego se busca en todos los dispositivos del computador el microcontrolador conectado a este, el cual tiene un VID con 0x16C0 y un PID 0x05DF, dichos identificaciones gratuitos son proporcionados por la misma librería V-USB para aplicaciones con fines no comerciales. En caso tal de no encontrar ningún periférico asociado a dichos números, la aplicación termina de forma inmediata para evitar fallos y procedimientos que no se harán de forma correcta. Si se logra un reconocimiento satisfactorio, el programa se queda esperando a que se ingresen los comandos relacionados con el manejo del vehículo. En la figura 5 se muestra el diagrama de flujo correspondiente al microcontrolador que se conecta al computador. Primero se inicializan las librerías y luego se deja el microcontrolador en un bucle infinito con el fin de estar verificando la llegada de paquetes del computador. Al momento de llegar un paquete se procede a seguir la transferencia, enviando el dato por el protocolo SPI al modulo ZigBee, y posteriormente vuelve al ya mencionado bucle infinito. En la figura 3 se muestra el subsistema conformado por un computador, el cual sirve como manejador del dispositivo. El manejo del dispositivo desde el computador se realiza usando la librería lib-usb que permite acceder a los puertos USB [3]. Al hacer uso de un microcontrolador como el Atmega16 que no cuenta con un modulo de

4 4 robot. Para recibir un dato correctamente se usa el algoritmo mostrado en la figura 7. Fig 7. Lógica asociada a la recepción de paquetes. Fig 4. Lógica implementada para la transmisión de datos. Inicio Inicialización: V-USB SPI Zigbee Revisión de paquetes enviados por el host (PC) La única diferencia con el transmisor es que se habilita el modo sleep para disminuir el consumo de batería. Como se puede apreciar en la figura 7, al llegar un dato el modulo ZigBee, automáticamente envía una interrupción por flanco de bajada que restablece el funcionamiento normal del microcontrolador y empieza a leer el paquete entrante, para así ejecutar la acción asociada con el comando. VI. Fig 5. Lógica desarrollada para el microcontrolador. V. IEEE MRF24J40MB RECEPCION Control del sistema (vehiculo) Fig 6. Estructura básica de recepción. En el receptor, como se puede apreciar en la figura 6, es la parte más simple del sistema, puesto que se reutiliza el código desarrollado para la transmisión y se ejecuta la acción que es llevada a cabo por el INTERFAZ Y MONTAJE FISICO En la figura 8 se observa la aplicación desarrollada en C++, usando el framework wxwidgets. Esta aplicación fue desarrollada en la interface de desarrollo CodeBlocks, la cual cuenta con los botones necesarios para el manejo de dirección, bocina y luces del robot a tele operar. Todas las herramientas usadas en el diseño son software libre. En la figura 9 se puede observar el modelo del carro que se uso y la luz derecha encendida mediante la información enviada a través del zigbee maestro y recibida por el zigbee esclavo que se observa en la figura 10.

5 Fig 8. Interfaz de manejo. 5 El desarrollo de un sistema tele-operado es muy útil pues este puede ser implementado y mejorado al ya tenerse la comunicación pues dependiendo de las necesidad el robot a manejar puede cambiar, pues así como en este caso es solo de exhibición, mas adelante podría manejar un carro que detecte minas antipersonales o que detecte el calor humano en caso de una emergencia. Compartir y dar a conocer los avances realizados por una persona en algún campo del conocimiento es darle un soporte y unas bases fundamentales al enriquecimiento de información a alguien que posiblemente le ha surgido la misma duda. Por ello el uso del software libre ha sido un pilar en la realización del proyecto, ya que sin este, no se hubiese podido lograr la depuración de un código, ni mucho menos, haber logrado una comunicación USB entre el PC y el microcontrolador. Asimismo con la tarjeta de desarrollo ucsboard-mega16 se logro dar un paso adelante en cuanto a problemas de hardware, ya que al ser esta un derivado de arduino (plataforma de hardware libre), se lograron obtener los mismos resultados, a un costo mucho más bajo. REFERENCIAS Fig 9. Modelo del carro a manejar. [1] Microchip Technology INC. <<MRF24J40 Datasheet>> (en ingles) (pdf) págs. 22. [2] Atmel <<ATmega16>> (en ingles) (pdf) págs.135. [3] [4] [5] Tatiana López Calderón. Fig 10. Modulo zigbee, parte trasera del carro. VII. CONCLUSIONES Nacida el 18 de enero de 1991 (Armenia- Quindío). Bachiller académica del Colegio de la Sagrada Familia Hermanas Terciarias Capuchinas (2007). Actualmente es estudiante de octavo semestre de Ingeniería Electrónica en la Universidad del Quindío. Sus áreas de interés son los sistemas digitales y las telecomunicaciones. Trabaja como investigadora en el grupo de procesamiento digital de señales (GDSPROC) en el diseño de un modulo software de simulación de la CPU AVR de 8 bits.

6 Alejandro Arcila Mora. Nacido el 18 de junio de 1991 (Armenia-Quindío). Bachiller académico con énfasis en mantenimiento de hardware (2007). Actualmente es estudiante de séptimo semestre de Ingeniería Electrónica en la Universidad del Quindío. Sus áreas de interés son los sistemas digitales y todo lo referente con biomédicas. Trabaja como investigador en el grupo de procesamiento digital de señales (GDSPROC) en el diseño de un modulo software de simulación de la CPU AVR de 8 bits. Luis Miguel Capacho Valbuena. Recibió el grado de Ingeniero Electrónico en la Universidad del Quindío en el año Actualmente se desempeña como docente-investigador en la Universidad del Quindío y forma parte del grupo de investigación GDSPROC de la misma institución. Área de trabajo: Sistemas embebidos, procesamiento de señales y programación. 6