scieee AI-readable full text Open interactive document viewer

Aplicación Electrónica para UAV: integración de IMU y GPS

Bravo Escudero, Manuel

Abstract

La gran expansión que han sufrido en los últimos años los vehículos aéreos no tripulados ha cambiado las reglas del juego en lo que se conocía hasta el momento del entorno aeronáutico. Tanto a nivel de sistemas y de aplicaciones como a nivel de normativa se han producido modificaciones y la aparición de una serie de nuevos recursos aplicables a estos sistemas. La consecuencia de estos cambios ha sido la creación de nuevas líneas de desarrollo en el ya de por sí complicado y en constante cambio mundo de la aeronáutica. Una de las dificultades que se encuentra alguien externo a las compañías desarrolladoras de estos productos es la falta de información disponible en el dominio público. Los avances punteros en este sector no se detallan en su totalidad debido a la gran competencia que existe entre las empresas. Todo esto es la clave que actúa como motivación de nuestro trabajo, moviéndonos a profundizar más en la aviónica que se aplica en los UAVs. Siendo conscientes de lo rápido que avanzan y han avanzado estos desarrollos en los últimos tiempos, se ha considerado oportuno realizar un breve estudio previo del estado del arte en el que nos encontramos actualmente. Como el resultado que se tiene en el presente es el fruto de todo lo ocurrido en el pasado, comenzaremos comentando el desarrollo de estos sistemas desde su primera aparición. Esto permitirá entender por qué estos sistemas evolucionaron lentamente a lo largo de 100 años y han experimentado un sorprendente impulso que los ha hecho llegar, incluso, hasta el ámbito doméstico. En el presente por tanto contamos con un amplio rango de sistemas a nuestro alcance en los que nos podemos basar para justificar nuestros desarrollos posteriores. Por ello se continuará exponiendo la jerarquía de la vasta variedad de diferentes vehículos no tripulados que se conocen, para obtener una visión más clara de todas las clases que se pueden encontrar en la realidad. Todo ello no sería posible sin los equipos de aviónica que realizan ciertas funciones en los UAVs propias de la tripulación. En este punto podremos afirmar que se comprende el estado actual de estos sistemas y que se entiende la criticidad que la aviónica supone para un UAV, por lo que se procede a analizar sistemas reales que las compañías ofrecen. Para ello se ha realizado un estudio de mercado, desglosando las características de los diferentes sistemas. Realizado este paso, se comprobará que una parte vital de la electrónica aplicada son los sensores de posicionamiento, tanto inerciales como GPS, apareciendo en la inmensa mayoría de los mismos. Ya que no podemos abarcar todo el espectro de sistemas de aviónica, decidimos centrar nuestro estudio en estos instrumentos tan necesarios para la autonomía de dichos vehículos. Y como no es lo mismo quedarse en la teoría que pasar a la práctica, se decidió construir un prototipo que fusionase una unidad de medidas inerciales con un receptor de señales GPS, permitiéndonos conocer su funcionamiento más en profundidad. La plataforma que nos permitirá construir nuestro prototipo, ofreciéndonos la suficiente flexibilidad y potencia como para poder integrar ambos dispositivos será Arduino. En concreto se empleará un Arduino Due, que cuenta con unas características óptimas para nuestro objetivo Como ejemplo de IMU para nuestro estudio se ha seleccionado la placa 10- DOF IMU Breakout - L3GD20H + LSM303 + BMP180 de Adafruit. Este instrumento agrupa tres acelerómetros en los tres ejes, tres giróscopos en los tres ejes, tres magnetómetros en los tres ejes, un sensor de temperatura y un sensor de presión. Para su correcto funcionamiento la compañía ofrece una serie de códigos compatibles con Arduino que permiten extraer los datos de cada sensor por separado y otros que integran dichos datos para obtener información más interesante a la hora del posicionamiento. Finalmente se seleccionará, para la integración posterior, un código que devuelve los ángulos que definen el rumbo del vehículo, y otro que extrae las aceleraciones que captan los acelerómetros. El otro pilar de nuestro proyecto será el receptor de GPS Ultimate GPS Breakout de la compañía Adafruit igualmente. El objetivo de este instrumento será recibir las sentencias NMEA (protocolo de comunicación empleado) que emiten los satélites, y el código que ofrece Adafruit se encarga de depurarlas para conseguir al final datos legibles. Este código será el que posteriormente se integrará con los indicados anteriormente para obtener el prototipo deseado. Finalmente se detallarán los pasos que se han seguido para completar la fusión de ambos dispositivos, obteniendo un equipo que consigue emitir tanto los datos inerciales como el posicionamiento GPS coordinadamente. Con esto se ha conseguido obtener un sistema a partir de dos, ahorrando en espacio, tanto físico como digital. Con todo ello hemos podido incrementar nuestros conocimientos sobre la electrónica que emplean estos dispositivos, ya que son necesarios para comprender correctamente su funcionamiento, al igual que aquellos relacionados con la programación en el lenguaje empleado, como paso necesario para realizar la correcta integración del software, y con todo ello conocer más en profundidad la aviónica que se aplica en los UAVs. Finalmente, se exponen algunas líneas de mejoras futuras que se podrían aplicar como continuación del desarrollo llevado a cabo en el presente Trabajo de Fin de Grado.

Full text

Trabajo Fin de Grado Grado en Ingeniería Aeroespacial Aplicación Electrónica para UAV: integración de IMU y GPS. Autor: Manuel Bravo Escudero Tutor a: Juana María Martínez Heredia Dpto. de Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2015 2 3 Trabajo Fin de Grado Grado en Ingeniería Aeroespacial Aplicación Electrónica para UAV: integración de IMU y GPS Autor: Manuel Bravo Escudero Tutora: Juana María Martínez Heredia Dpto. de Ingeniería Electrónica Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2015 4 5 Trabajo Fin de Grado: Aplicación Electrónica para UAV: integración de IMU y GPS Autor: Manuel Bravo Escudero Tutora: Juana María Martínez Heredia El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros: Presidente: Vocales: Secretario: Acuerdan otorgarle la calificación de: El Secretario del Tribunal Sevilla, 2015 6 7 Resumen La gran expansión que han sufrido en los últimos años los vehículos aéreos no tripulados ha cambiado las reglas del juego en lo que se conocía hasta el momento del entorno aeronáutico. Tanto a nivel de sistemas y de aplicaciones como a nivel de normativa se han producido modificaciones y la aparición de una serie de nuevos recursos aplicables a estos sistemas. La consecuencia de estos cambios ha sido la creación de nuevas líneas de desarrollo en el ya de por sí complicado y en constate cambio mundo de la aeronáutica. Una de las dificultades que se encuentra alguien externo a las compañías desarrolladoras de estos productos es la falta de información disponible en el dominio público. Los avances punteros en este sector no se detallan en su totalidad debido a la gran competencia que existe entre las empresas. Todo esto es la clave que actúa como motivación de nuestro trabajo, moviéndonos a profundizar más en la aviónica que se aplica en los UAVs. Siendo conscientes de lo rápido que avanzan y han avanzado estos desarrollos en los últimos tiempos, se ha considerado oportuno realizar un breve estudio previo del estado del arte en el que nos encontramos actualmente. Como el resultado que se tiene en el presente es el fruto de todo lo ocurrido en el pasado, comenzaremos comentando el desarrollo de estos sistemas desde su primera aparición. Esto permitirá entender por qué estos sistemas evolucionaron lentamente a lo largo de 100 años y han experimentado un sorprendente impulso que los ha hecho llegar, incluso, hasta el ámbito doméstico. En el presente por tanto contamos con un amplio rango de sistemas a nuestro alcance en los que nos podemos basar para justificar nuestros desarrollos posteriores. Por ello se continuará exponiendo la jerarquía de la vasta variedad de diferentes vehículos no tripulados que se conocen, para obtener una visión más clara de todas las clases que se pueden encontrar en la realidad. Todo ello no sería posible sin los equipos de aviónica que realizan ciertas funciones en los UAVs propias de la tripulación. En este punto podremos afirmar que se comprende el estado actual de estos sistemas y que se entiende la criticidad que la aviónica supone para un UAV, por lo que se procede a analizar sistemas reales que las compañías ofrecen. Para ello se ha realizado un estudio de mercado, desglosando las características de los diferentes sistemas. Realizado este paso, se comprobará que una parte vital de la electrónica aplicada son los sensores de posicionamiento, tanto inerciales como GPS, apareciendo en la inmensa mayoría de los mismos. Ya que no podemos abarcar todo el espectro de sistemas de aviónica, decidimos centrar nuestro estudio en estos instrumentos tan necesarios para la autonomía de dichos vehículos. Y 8 como no es lo mismo quedarse en la teoría que pasar a la práctica, se decidió construir un prototipo que fusionase una unidad de medidas inerciales con un receptor de señales GPS, permitiéndonos conocer su funcionamiento más en profundidad. La plataforma que nos permitirá construir nuestro prototipo, ofreciéndonos la suficiente flexibilidad y potencia como para poder integrar ambos dispositivos será Arduino. En concreto se empleará un Arduino Due, que cuenta con unas características óptimas para nuestro objetivo Como ejemplo de IMU para nuestro estudio se ha seleccionado la placa 10- DOF IMU Breakout - L3GD20H + LSM303 + BMP180 de Adafruit. Este instrumento agrupa tres acelerómetros en los tres ejes, tres giróscopos en los tres ejes, tres magnetómetros en los tres ejes, un sensor de temperatura y un sensor de presión. Para su correcto funcionamiento la compañía ofrece una serie de códigos compatibles con Arduino que permiten extraer los datos de cada sensor por separado y otros que integran dichos datos para obtener información más interesante a la hora del posicionamiento. Finalmente se seleccionará, para la integración posterior, un código que devuelve los ángulos que definen el rumbo del vehículo, y otro que extrae las aceleraciones que captan los acelerómetros. El otro pilar de nuestro proyecto será el receptor de GPS Ultimate GPS Breakout de la compañía Adafruit igualmente. El objetivo de este instrumento será recibir las sentencias NMEA (protocolo de comunicación empleado) que emiten los satélites, y el código que ofrece Adafruit se encarga de depurarlas para conseguir al final datos legibles. Este código será el que posteriormente se integrará con los indicados anteriormente para obtener el prototipo deseado. Finalmente se detallarán los pasos que se han seguido para completar la fusión de ambos dispositivos, obteniendo un equipo que consigue emitir tanto los datos inerciales como el posicionamiento GPS coordinadamente. Con esto se ha conseguido obtener un sistema a partir de dos, ahorrando en espacio, tanto físico como digital. Con todo ello hemos podido incrementar nuestros conocimientos sobre la electrónica que emplean estos dispositivos, ya que son necesarios para comprender correctamente su funcionamiento, al igual que aquellos relacionados con la programación en el lenguaje empleado, como paso necesario para realizar la correcta integración del software, y con todo ello conocer más en profundidad la aviónica que se aplica en los UAVs. Finalmente, se exponen algunas líneas de mejoras futuras que se podrían aplicar como continuación del desarrollo llevado a cabo en el presente Trabajo de Fin de Grado. 9 Índice 1 Introducción f ……….……………………………………………………………………..11 2 Sistemas UAV . 2.1 Introducción a los UAVs ......................................................................... 18 2.2 Reseña histórica .................................................................................... 20 2.3 Clasificación de los UAVs ...................................................................... 23 2.4 Aviónica en los UAVs ............................................................................. 26 2.5 Estudio de Mercado. .............................................................................. 29 2.5.1 Robocóptero ganador del International Aerial Robotic Competition (1997). ...................................................................................................... 29 2.5.2 Vehículo de Vigilancia (MIT, 1996). ................................................. 30 2.5.3 Innovative Defense Electronics (RADA) .......................................... 31 2.5.4 Mavins (RADA) ................................................................................ 32 2.5.5 Piccolo (Cloud Cap Technology) ..................................................... 33 2.5.6 Pulse Aerospace ............................................................................. 34 2.5.7 Vector (UAV Navigation) .................................................................. 35 2.5.8 Proton (UAV Navigation) ................................................................. 37 2.5.9 OpenPilot. ........................................................................................ 38 2.5.10 Familia de Autopilotos MP2x28 (MicroPilot) .................................. 39 2.5.11 AirElectronics ................................................................................. 40 2.5.12 Resumen de los datos obtenidos. ................................................. 40 2.6 Conclusiones .......................................................................................... 43 3 Descripción de la Unidad de Medidas Inerciales 3.1 Introducción y Motivación ....................................................................... 44 3.2 Conexión con Arduino Due .................................................................... 46 3.3 Software para el uso de la IMU .............................................................. 47 3.4 Descripción del software relevante ........................................................ 54 3.4.1 pitchrollheading .............................................................................. 54 3.4.2 accelsensor ..................................................................................... 58 16 Sin embargo, el entorno de constante desarrollo que vivimos en la actualidad genera que las compañías mantengan como confidenciales los detalles de sus desarrollos más recientes. Los avances de hace cinco años pueden considerarse desactualizados, lo que ilustra la situación que pretendemos mostrar. Si esto no fuese así, bastaría con estudiar y copiar lo que sí se nos muestra para desarrollar reproducciones de los dispositivos que deseásemos. Esta situación nos deja en una posición de conocimiento poco profundo del tema, teniendo que tomar una parte activa en esta cuestión, debido a lo difícil que resulta encontrar información de esta índole en libros o recursos digitales. Por todo ello se propuso este trabajo, para estudiar la aviónica que hoy en día se aplica en los UAVs. Como es necesario conocer el proceso que se ha seguido hasta alcanzar el punto actual, también se cree conveniente repasar la historia de los UAVs, analizando cuales han sido los momentos fundamentales que impulsaron la creación de mejoras. Tras esto se cree conveniente estudiar sistemas que se encuentren actualmente en el mercado, para tomarlos como referencia para los siguientes pasos de nuestro trabajo. Una vez que consigamos una buena base teórica sobre la actualidad de los UAVs, y debido a que tomar parte en el asunto y pasar a la práctica permite mayor involucración en el tema, nos hemos marcado como objetivo construir un prototipo de dispositivo de aviónica a partir de varios elementos más simples. Como se justificará más adelante, unas de las partes fundamentales en todo sistema de posicionamiento son los sensores. Existen dos categorías de navegación: • Navegación a estima: tratan de hallar la posición de la aeronave conociendo las condiciones iniciales y datos que ofrecen ciertos sensores autónomos, como aquellos que miden propiedades inerciales. • Navegación por posicionamiento: obtienen, mediante la información que reciben de sistemas no embarcados, la posición absoluta en los ejes geográficos. Estas dos categorías son básicas en los vehículos aéreos de hoy en día, por lo que decidimos emplear para nuestro proyecto una unidad de medidas inerciales y un receptor de GPS. Ayudándonos de una placa Arduino, nuestro objetivo final será integrar ambos instrumentos al nivel de la recepción de los datos, coordinando la información de ambos. Finalmente se pretenderá desarrollar la manera en que estos datos pueden ser extraídos de manera realista. A expensas de mejorar la presentación 17 física del prototipo y el procesamiento de datos llevado a cabo, creemos que así resultará un dispositivo perfectamente presentable en el mercado 18 2 Sistemas UAV 2.1 Introducción a los UAVs A pesar de que recientemente los conocidos como UAVs han sufrido su expansión más impactante, esta categoría de vehículos aéreos no tripulados existe desde hace más tiempo del que uno cabe esperar, aunque si es verdad que hasta hace poco el estado de su tecnología estaba muy poco desarrollada. En nuestros tiempos, sin embargo, podemos encontrarnos UAVs destinados únicamente al ocio, e incluso, como juguetes. Esto es reflejo de lo que han avanzado los sistemas, pudiendo abaratar hasta este punto los mencionados dispositivos. Las siglas “UAV” proceden de su denominación en inglés: Unmanned Aerial Vehicles, aunque debido a su reciente “boom” la manera estandarizada en la que podemos referirnos a ellos no ha sido establecida aún. Así, podemos encontrarnos con nombres como UMAs (Unmanned Air Vehicles), RPV (Remote Piloted Vehicles), drones o UCAVs (Uninhabited Combat Air Vehicles). El último de los nombres se corresponde lógicamente con aquellos drones destinados a tener un papel ofensivo en el campo militar. Y es al sector militar de la aeronáutica al que la humanidad debe la mayoría de los avances que en su día fueron punteros y, por tanto, aquellos que lo son ahora mismo y se comienzan a emplear en la aviación civil. Esto es debido a que la normativa militar no es tan estricta como la que se aplica al otro ámbito, de modo que a la hora de implementar un nuevo sistema, la primera deja más margen. Como veremos más adelante, las guerras han sido las primeras impulsoras de todo tipo de tecnología, contribuyendo de esta manera al sector “Airplanes are now built to carry a pilot and a dog in the cockpit. The pilot's job is to feed the dog, and the dog's job is to bite the pilot if he touches anything." Arlen Rens, a Lockheed Martin test pilot. 19 aeroespacial. Y es dentro de este sector donde se enmarcan los UAVs, y por consecuencia, también han sido desarrollados durante estos periodos. No es difícil imaginarse el interés que puede despertar un dispositivo que puede ser guiado automáticamente o de forma remota, hasta la zona del otro bando, y allí desarrollar la misión para la que está destinado, ya sea ofensiva, de vigilancia, etc. De esta manera, un trabajo puede desarrollarse sin poner en peligro la vida de la persona destinada a tripular el vehículo. Sin embargo, durante las dos guerras mundiales, la tecnología no estaba tan desarrollada como lo está hoy en día. Esto nos lleva a pensar que no es casualidad el auge que los vehículos no tripulados están sufriendo. Desde el momento en que se vio que su construcción era completamente factible desde el punto de vista tecnológico, que podían ser dedicados a múltiples aplicaciones y que el precio final era muy asequible, han surgido multitud de empresas que ofrecen pequeños drones destinados al ocio, sin nada más necesario que el dinero para realizar su compra (un dron más grande y pesado estará dedicado a aplicaciones más serias, prácticamente en ningún caso recreativas). Estos a su vez suelen integrar una cámara o algún otro instrumento de funcionalidades diferentes. O simplemente son objetos de aeromodelismo con bajos requerimientos para su control. La ventaja que ofrecen es una forma rápida, sencilla y barata de alcanzar mayores alturas y disfrutar del vuelo estable. En el campo civil también existen drones que realizan misiones, básicamente de supervisión y monitorización. Entre ellas podemos destacar la vigilancia de fronteras ante el tráfico de drogas y la inmigración ilegal, inspección de líneas de potencia eléctrica, supervisión de viaductos de gas o petróleo, monitorización de entornos forestales, fumigación de cultivos y supervisión de tráfico y entornos urbanos. En este caso, los drones ayudan a realizar tareas repetitivas o de largo alcance. De este modo, que la tarea sea repetitiva, facilita su diseño. Y su capacidad para volar permite que cubran grandes distancias de la manera más rápida y eficiente posible. Los únicos impedimentos que deben resolver son los de carácter legislativo y de seguridad. Sin embargo, los mayores avances no se realizan en vehículos destinados a ser vendidos en el mercado civil. Como ya se dijo, esto ocurre en el ámbito militar, ya que las tareas a desarrollar son inesperadas y requieren de gran capacidad de adaptación y decisión. Ya sean sistemas de mejora de la estabilidad, sistemas de guerra electrónica, armamento, etc., existen líneas de investigación en cada uno de ellos para estar a la altura de los últimos avances. Una de las ventajas de su aplicación en este sector, consecuencia de la eliminación del piloto, es la posibilidad de aumentar la cantidad de g’s a las que la aeronave puede estar sometida. El piloto establece una limitación 20 de 9g, por lo que un UAV puede aumentar su maniobrabilidad y su capacidad de escape ante ataques. Además, el vehículo acaba siendo más pequeño y barato, ya que al ser suprimido el habitáculo del piloto, parte de este espacio puede ser ocupado por otros sistemas. A modo de ejemplo, se estima que un UCAV supone una tercera parte del coste total de una nave de combate pilotada, y el coste de operación y mantenimiento resulta del 25% menor. Excepto pequeñas variaciones, todos ellos poseen una arquitectura de su hardware muy similar, ya que aunque no todos están dedicados para lo mismo, todos precisan de unos requisitos mínimos: el vuelo debe ser estable en todo momento, y es complicado que esto se consiga desde la estación de tierra; la comunicación con esta estación debe efectuarse por medio de determinados canales y siguiendo determinados protocolos para que sea correcta; las órdenes que el controlador desea dar deben llegar al dron, ser recibidas adecuadamente y reinterpretadas para traducirse en deflexiones de actuadores o lo que corresponda; debe controlarse en todo momento la batería de la que se dispone para asegurarse de que el dron no pare en pleno vuelo, con los daños que esto desencadenaría. Así podríamos continuar hasta completar el conjunto de funcionalidades básicas que el dron precisaría, y que finalmente se materializaría en un sistema de dispositivos hardware fácilmente identificables en la mayoría de UAVs. Ligado inexorablemente a esta configuración compleja, aparece el conjunto de tecnologías conocidas como aviónica. Dada la experiencia que se tiene en la aplicación de diferentes tipos de sistemas (hidráulico, neumático, etc.), la aplicación de la electrónica ha demostrado ser la única que hace posible el desarrollo de todas las funciones necesarias con el mínimo coste y peso. Sería impensable fabricar un dispositivo que realice todas las funciones que desempeña uno electrónico actual, pero accionado mediante potencia hidráulica, por ejemplo. 2.2 Reseña histórica Para hacernos una idea de lo que son los UAVs en la actualidad y el mérito que supone disponer de un vehículo en el aire, cuyo vuelo y misión sean completamente autónomos, es indispensable conocer la trayectoria que se ha seguido hasta llegar al punto en que nos encontramos actualmente. Para ello se desarrolla la línea temporal siguiente: 21 Globos Austriacos, 22 Agosto 1849 •Uno de los primeros registros que se tienen de algo parecido a un UAV es el ataque por parte de Austria a la ciudad de Venecia con globos cargados de explosivos, no tripulados. Aunque el concepto de UAV no es claro en este ejemplo, tuvo el suficiente impacto para alentar a desarrollar aviones no tripulados cuando esto fue posible. Primera Guerra Mundial •Es durante este periodo que apareció el primer avión de la armada americana sin piloto. Conocido como "flying bomb", pretendía ser un "torpedo aéreo" ola primera versión de los actuales "cruise missiles".Su control se basada en giróscopos. Periodo entre guerras •Durante este periodo se relizaron numerosos avances. Conversión de aviones a UAVs que volaban con pilotos automáticos, aparición de los primeros misiles de crucero, estudio del control mediante ondas de radio... Durante este periodo apareció la denominación de "dron". Segunda Guerra Mundial •Reginald Denny construye la primera factoría que produce drones radiocontrolados para cualquier propósito. Consigue demostrar sus aplicaciones militares y firma un acuerdo con el ejército americano. •La armada estadounidense continúa desarrollando sus drones, haciéndolos cada vez mayores y mejorando sus prestaciones. •La aparición del pulsorreactor facilita la implementación de la propulsión de los UAVs. 22 Como podemos observar, y como se ha dicho con anterioridad, la mayor parte de los desarrollos asociados a los UAVs se debe al impulso tanto económico como táctico que se les dio y se les sigue dando en periodos bélicos. Sus comienzos, sus primeras aplicaciones, sus grandes logros, todos ellos están fuertemente ligados al sector militar. No es casualidad, ya que son innumerables las ventajas que se les pueden encontrar, que ya fueron comentadas anteriormente. Desde el punto de vista tecnológico, al igual que ocurre con el resto del mundo de la aeronáutica, los impulsos de sus diseños están muy limitados por la tecnología del momento. Debido a que son máquinas que involucran una gran cantidad de aspectos de la ciencia, se tuvo que esperar a que todos ellos se encontrasen en el punto adecuado de su desarrollo para conseguir resultados óptimos. Véase por ejemplo los desarrollos que se tuvieron que hacer desde el punto de vista de las comunicaciones remotas para que pudiesen ser controlados de forma idónea. Del mismo modo, tuvieron que ser desarrollados novedosos sistemas propulsivos (entre ellos Guerra Fría •Evolución de los drones de blanco, empleados como señuelos, apareciendo infinidad de modelos debido al avanzado estado de las tecnologías. De hecho, muchos podían alcanzar velocidades supersónicas (Mach 2). • Algunos de ellos fueron modificados para recolectar datos de radioactividad y pruebas nucleares. •El éxito de los drones como blancos los impulsó aser usados como vehículos de reconocimiento.Una de sus más importantes pruebas fue la Guerra de Vietnam. • La URSS comenzó adesarrollar sus propios prototipos, pero mantuvo estos proyectos en secreto. Era Moderna • La guerra entre Siria eIsrael cambió por completo la visión que se tenía de los drones, en la que los israelíes derribaron numerosos aviones sirios con muy pocas pérdidas, empleando drones con alta inteligencia militar. Esto les dio importantes perspectivas. •Los EEUU están muy centrados en desarrollar avanzados drones miitares. •Aparición de drones de larga autonomía y microUAVs. •Uso de nuevas fuentes de energía, como haces de láser o microondas, o energía solar. 23 ha sido destacado el pulsorreactor) cuya relación 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 � fuese la adecuada para ser implementado en dichos vehículos. 2.3 Clasificación de los UAVs Como se puede deducir hasta el momento, entre las grandes ventajas que los UAVs tienen se encuentran la posibilidad de aplicarlos a múltiples propósitos, su gran dinamicidad y su baja limitación por factores humanos (limitaciones del entorno, de gs, de periodos de vuelos grandes, tareas repetitivas, etc.). Por ello es importante hacerse a la idea de los diferentes tipos que existen respecto a diferentes clasificaciones, para poder tener conocimiento de la amplia gama que se conoce en la actualidad. Ello posibilitará comparar las diferentes categorías, ya que para diferentes propósitos, las características no pueden ser las mismas. Además es interesante conocer diferentes clasificaciones, ya que la gran expansión que los UAV han tenido recientemente, trascendiendo del mundo militar a una situación mucho más cercana a la vida cotidiana, ha acabado resultando en una mayor variedad de modelos. Figura 1. Clasificación de los UAVs según el tipo de ala empleada Para empezar, la clasificación más simple que existe, que enmarca los UAVs según el tipo de ala que empleen. Se incluyen todos aquellos que UAVs según el tipo de aeronave Despegue Vertical Ala Rotatoria Helicópteros X-rotors (quad, hexa, octa...) Autosustentados Dirigibles Globos Aerostáticos Despegue No Vertical Ala flexible Parapente Ala Delta Ala fija Aeroplanos 24 realizan una misión sin necesidad de llevar tripulación a bordo, poseyendo una controlabilidad total o parcial. De esta manera, globos meteorológicos, que no son controlables, quedan al margen. Esta clasificación se muestra en la Figura 1. De este modo podemos comprobar que, a pesar de que los tipos más usuales de UAVs son los aeroplanos y los clasificados como ala rotatoria, pueden darse muchos más casos de los que uno podría imaginarse. Llegados a este punto, podría decirse que todo vehículo que alguna vez ha sido pilotado y ha conseguido realizar un vuelo controlado, puede modificarse para convertirse en UAV, cada vez con menos esfuerzo gracias a la experiencia que se tiene en ellos. Hay que comentar que los globos que se incluyen en el apartado de vehículos auto-sustentados sí poseen cierta controlabilidad. Un caso conocido es el denominado vehículo Tandem, sustentado por globos estratosféricos, zona donde se desarrolla su misión, y siendo controlado por hélices específicamente diseñadas para este entorno. Otra manera más detallada e interesante de clasificar los UAVs es según sus capacidades de vuelo, es decir, alcance, autonomía, altitud de vuelo, etc. Debido al deseo reciente de estandarizar y regular las distintas posibilidades que permiten los actuales UAVs, la OTAN ha realizado la clasificación, mostrada en la Tabla 1. Figura 2. Clasificación de Blyenburgh 25 Clase Categoría Aplicación Altitud Radio de Misión Ejemplo Clase I: menos de 150kg SMALL: >20kg Unidad Táctica (sistema de lanzamiento) Hasta 5000 ft 50 km MINI : 2-20kg Sub-unidad táctica (lanzamiento manual) Hasta 3000 ft 25 km MICRO: <2kg Táctico, individual (un solo operador) Hasta 200 ft 5 km Clase II: entre 150kg y 600kg TACTICAL Formación táctica Hasta 10000 ft 200 km Clase III: más de 600kg Strike/ Combat Estratégico/ Nacional Hasta 65000 ft Ilimitado HALE Estratégico/ Nacional Hasta 65000 ft Ilimitado MALE Operacional Hasta 45000 ft Ilimitado Tabla 1. Clasificación de los UAVs según sus capacidades de vuelo Resulta interesante igualmente la Figura 2, (http://apeironuav.org/?p=205), que expresa de forma visual y comparativa dónde se sitúa cada vehículo respecto a las características comentadas. La OTAN se ha basado en dicho 32 • PMC (Payload Management Computer): permite la gestión de múltiples cargas de pago a través de una única plataforma, siendo compatible con el bus MIL-STD-1553. Consumo de 15 W y peso de 1.5 Kg. • PIU (Payload Interface Unit): unidad dirigida por la PMC a través de control digital. Amplía la comunicación con la carga de pago, devolviendo información añadida y su estado. Incluye electrónica redundante que incrementa la seguridad. Consumo de 27 W y peso de 4 Kg. • ECC (Engien Control Computer): proporciona una interfaz completa entre el motor y el FCC, incluyendo sensores, monitorización, control de actuadores y funciones de control discreto del motor. La aplicación de software modular permite la configuración externa de más de 300 parámetros. Consumo de 15 W y peso de 1.15 Kg. • EPMU (Electrical Power Management Unit): RADA ofrece 6 tipos diferentes de estos dispositivos para el control de interruptores, protección y sensores. 2.5.4 Mavins (RADA) Es el segundo producto de la empresa RADA dedicado a UAVs. En este caso se trata de una integración de computador de control de vuelo, autopiloto, sensores, etc. Su alta compacidad se justifica por estar destinado a UAVs mini y micro, además de como sistema de respaldo para vehículos pilotados. Sus sensores incluyen las tecnologías MEMS. Su peso es de 1 kg, y sus dimensiones de 110 x 100 x 10 mm. La apariencia del sistema es la que se muestra en la Figura 6. Figura 6. Dispositivo MAVINS En la Figura 7 se muestra el diagrama de bloques interno, obtenido del sitio web de la compañía. Como se puede ver en él, posee dos módulos iguales 33 que aportan redundancia, aumentando la fiabilidad del sistema. Cada uno de ellos cuenta con una CPU y una memoria como núcleo, de modo que este está comunicado con el resto a través de los buses CAN, RS422A, RS232C y Ethernet rápido. Observamos que también está duplicada la unidad de suministro de potencia y la unidad de medidas inerciales, GPS y un sistema de datos de aire. Finalmente vemos que se comunica con unidades externas como son dos antenas GPS, un sensor de presión estática y otro de presión total. Figura 7. Diagrama de bloques del dispositivo MAVINS. 2.5.5 Piccolo (Cloud Cap Technology) Esta empresa ofrece un autopiloto muy integrado, y además con miras a poder aplicarse a cualquier configuración, pasando de aviónica personalizable a aviónica estandarizada. Está orientado a UAVs pequeños y medianos. Posee un peso de 212g, incluyendo GPS y carcasa. 34 En la Figura 8 se muestra el diagrama de bloques del dispositivo en cuestión. En él se puede ver que posee un microprocesador como núcleo de todo el sistema, y este está conectado al resto de elementos. Por la izquierda observamos que recibe la fuente de energía. En la esquina inferior derecha se sitúa todo el conjunto de sensores, contando con giróscopos, un termopar, acelerómetros, sensor de la velocidad aerodinámica y GPS. En cuanto a las comunicaciones que emplea el sistema, podemos comprobar que en la esquina superior derecha encontramos un bus CAN. Figura 8. Diagrama de bloques del dispositivo Piccolo. 2.5.6 Pulse Aerospace Esta empresa de aviónica ofrece diversos equipos entre los que encontramos una familia de autopilotos, que agrupamos debido a las similitudes que existen entre ellos: 35 • WePilot1000. Sistema de control de vuelo para pequeños helicópteros autónomos. Consiste en un sistema encapsulado que cuenta con receptor GPS, acelerómetros y giróscopos, ambos en tres ejes. Del mismo modo posee barómetros y conexión para un magnetómetro externo. • WePilot1000FW. Sistema basado en el equipo anterior, pero con la aplicación de algoritmos específicos para sistemas de ala fija. • WePilot3000. Sistema de control de vuelo doblemente redundante para vehículos autónomos que cuentan con un MTOW entre 10 y 500 Kg. Cuenta con dos CPUs, dos receptores GPS/Glonass, unidades de medidas inerciales en 5 ejes, dos magnetómetros, así como sensores de presión absoluta y relativa. Las características generales medias se muestran en la Tabla 2 . Dimensiones 165x116x61 mm Masa (con carcasa) 670 g Masa (sin carcasa) 300 g Consumo 450 x 12 V = 5.4 W Tabla 2. Características generales del los autopilotos de la empresa Pulse Aerospace. 2.5.7 Vector (UAV Navigation) Autopiloto ofertado por la empresa UAV Navigation, destinado a UAVs medianos o grandes. Es capaz de controlar tanto UAVs de ala fija como de ala rotatoria, a través de un amplio rango de actuaciones. Cuenta con elementos redundantes para evitar fallos mayores ante errores de los sensores. Las dimensiones del dispositivo se muestran en la imagen Figura 9 36 Figura 9. Dimensiones del dispositivo Vector de la empresa UAV Navigation En cuanto a los sensores con los que trabaja, lleva integrada la placa denominada POLAR AHRS-INS que cuenta con numerosos dispositivos de navegación. Entre ellos, un sistema AHRS (Attitude, Heading & Reference System), una unidad de medidas inerciales, un sistema de navegación inercial, de los que se espera que posean los acelerómetros, giróscopos y magnetómetros necesarios, una unidad de datos de aire (ADS) y GPS. En la Figura 10 se incluye el diagrama de bloques de la tarjeta de sensores. Figura 10. Diagrama de bloques de la placa de sensores POLAR AHRS-INS También sabemos que su peso es de 300 g, y que consume 2.5 W para su correcto funcionamiento. 37 2.5.8 Proton (UAV Navigation) De la misma empresa anterior también encontramos este autopiloto, cuyo objetivo es reducir el coste, el peso y el tamaño, mediante la fabricación en masa y la simplificación de los dispositivos con los que cuenta. Puede ser implementado en dispositivos de ala fija y rotatoria. Mostramos en la Figura 11 las dimensiones en milímetros del autopiloto en cuestión con el encapsulado final. Figura 11. Dimensiones del dispositivo Proton de la empresa UAV Navigation Todo lo necesario para el posicionamiento se proporciona encapsulado en la placa ATOM AHRS-INS, que al igual que el conjunto del autopiloto, está diseñada para reducir peso (menos de 2 g), tamaño y consumo (90 mW). Consta de 3 giróscopos, 3 acelerómetros y 3 magnetómetros, para determinar todas las posiciones asociadas a todos los grados de libertad. Se incluye en la Figura 12 su diagrama de bloques. Figura 12. Diagrama de bloques de la placa ATOM AHRS-INS 38 2.5.9 OpenPilot. OpenPilot está concebida como una plataforma de software libre, enfocada a ser desarrollada de forma comunitaria, o sea, cualquiera puede intervenir en el desarrollo, consiguiendo un dispositivo flexible de aviónica para UAVs pequeños. Inicialmente se proporciona la plataforma OpenPilot, común para cualquier propósito, y después esta es personalizada para uno u otro mediante la implementación de diferentes tarjetas adicionales. Este sistema está constantemente en desarrollo, pero actualmente se dispone de las diferentes estructuras: • Plataforma CopterControl: este dispositivo está pensado como una plataforma de estabilización más que como un autopiloto, de modo que no es el producto con más aplicaciones de la compañía. Para desempeñar su función está provista de una tarjeta de sensores denominada CC3D que consta de 3 giróscopos y 3 acelerómetros, además de poder recibir señales de GPS. • Plataforma Revolution: está actualmente en desarrollo, y su función final será constituir un autopiloto aplicable a cualquier vehículo no tripulado. Debido a las mayores exigencias de su diseño, consta de un dispositivo INS completo, desarrollando todas las funciones asociadas a un autopiloto. La Figura 13 muestra la apariencia de la plataforma OpenPilot, además de sus diferentes componentes: Figura 13. Apariencia de la plataforma OpenPilot y sus componentes. 39 2.5.10 Familia de Autopilotos MP2x28 (MicroPilot) La empresa MicroPilot ofrece una familia de autopilotos de modo que entre todos se cubre gran rango de las aplicaciones de los UAVs pequeños y micro, y también diferentes precios. Todos ellos poseen una serie de características técnicas comunes y alguna que los diferencia de los demás. De este modo respecto a especificaciones de navegación podemos comentar que todos poseen recepción de GPS, giróscopos en los tres ejes, acelerómetros en los tres ejes, aunque no todos constan de magnetómetros, pero siempre existe posibilidad de incluirlo. Todos pesan 24g y el consumo máximo que pueden presentar ronda los 5 W. Los diferentes productos que se ofrecen son: • MP2128-Heli2: destinado para vehículos de ala fija y rotatoria (helicópteros o multi-rótores), posee el mayor rango de características de la familia. • MP2128-g2: solo se puede aplicar a multi-rótores y vehículos de ala fija, aunque cuenta con mejores características para aviones de ala fija. Es compatible con un amplio rango de temperaturas y con diferentes opciones de comunicación. • MP2028-g2: vuela vehículos de ala fija y multi-rótores. Su principal motivación es ofrecer la suficiente flexibilidad para ser aplicado a cualquier aplicación. De este modo cuenta con la mejor relación precio/actuación. • MP1028-g2: igualmente, solo vuela UAVs de ala fija y multi-rótores, y su simple propósito es cubrir las necesidades de nivel más bajo. Por ello está asociado al autopiloto de menor coste, para las ocasiones en que obtener un dispositivo económico es lo primordial. Además se cuenta con unas versiones mejoradas denominadas MP2128-LRC2 y MP2128-Heli-LRC2. Las siglas LRC significan “Long Range Communication”, de modo que la característica mejorada de estos dispositivos son las comunicaciones, permitiendo que estas alcancen mayores distancias y confiriéndoles mayor redundancia al hardware asociado a ellas, resultando un vehículo más flexible. También está disponible el autopiloto MP2128-3X, que consta de triple redundancia (tres autopilotos MP2128-Heli2 integrados y otros dispositivos de respaldo), consiguiendo el elemento de mayor confianza. 40 2.5.11 AirElectronics Esta empresa española ofrece todo tipo de elementos electrónicos de aplicación en UAVs, entre los que encontramos algunos asociados al control del vuelo de dichos vehículos: • U-Pilot: constituye el núcleo de la aviónica de cualquier UAV donde sea implementado, ya que está diseñado como un autopiloto. Permite controlar vehículos de ala rotatoria y fija en todo momento. Posee sensores MEMS de alta sensibilidad, constituyendo la unidad que recoge los datos de posicionamiento, y que se disponen según el siguiente diagrama: Figura 14. Diagrama de bloques del dispositivo U-Pilot Como podemos ver, dispone de acelerómetros, giróscopos, sensores de presión estática para mejorar la actuación en diferentes altitudes y sensores de presión dinámica. • U-Pilot 0EM: es exactamente el mismo dispositivo que el U-Pilot, pero presentado en versión delgada, debido a un encapsulado menos resistente. Presenta los mismos sensores y elementos, pudiendo desempeñar las mismas funciones e instalarse en los mismos UAVs. 2.5.12 Resumen de los datos obtenidos. Debido a la gran cantidad de información recogida mediante el anterior estudio de mercado se hace necesario procesarla y presentarla de forma que sea más cómoda su interpretación. En este caso se ha decidido tabularla quedándonos solamente con los datos más relevantes para el desarrollo que se realizará con posterioridad. Aún así, las empresas 41 no ofrecen los mismos datos para sus productos, de modo que aunque no contamos con la totalidad de todos ellos, contamos con los suficientes de cada categoría para sacar nuestras propias conclusiones. Presentamos en la Tabla 3 la información a la que nos referimos. Para comenzar, cada artículo está definido por su denominación y la empresa u organización a la que se debe su desarrollo. En segundo lugar, hemos indicado las dimensiones que posee cada dispositivo, para hacernos una idea del espacio que ocupan en el vehículo al que van destinado. En relación con esto podemos ver en la tercera columna el peso, cuando se especifica en el sitio web de cada empresa. El tamaño y el peso son dos parámetros muy determinantes para el diseño de la aviónica de un sistema, como se comentó en el apartado “2.4 Aviónica en los UAVs”. Las columnas siguientes hacen referencia a los equipos de posicionamiento y sensores de la aviónica, de modo que son relevantes igualmente, sobre todo para el estudio posterior que se tratará en este trabajo. Así estudiamos el número de giróscopos, acelerómetros, magnetómetros (o sea, elementos típicos de una IMU aunque no siempre constituyan esta unidad), comunicación con GPS y sistema de datos de aire. Finalmente se presenta las comunicaciones existentes entre la unidad de datos inerciales y el resto de elementos de aviónica del sistema. Esto permitirá detectar cuales son los protocolos de comunicaciones más empleados en la práctica, para enfocar nuestros pasos siguientes a una visión más realista. Como conclusiones, podemos destacar, esta vez ya con total certeza, el papel tan vital que juega la unidad de sensores inerciales en la aviónica de estos sistemas. De modo que la mayoría de los sistemas cuentan con 3 giróscopos y 3 acelerómetros. En cuanto a los magnetómetros, si no se cuenta con ellos, al menos existe la posibilidad de conectar uno externo. Además, de igual manera, en prácticamente todos se dispone de compatibilidad con la red GPS o al menos existe la posibilidad de conexión externa. En cuanto a las comunicaciones que se emplean, destacamos el BUS CAN, Ethernet y RS422, apareciendo recurrentemente en estos sistemas. 48 funcionamiento de los sensores de la IMU. Algunos de ellos están enfocados a algunos de los sensores, de modo que solo recogen los datos proporcionados por parte de ellos. Sin embargo, hay un conjunto de códigos que son los que trabajan realmente como integradores de la IMU. Presentamos a continuación los códigos que ofrece la compañía. • Código del sensor de presión y temperatura BMP180, denominado sensorapi: este código extrae la información que obtienen los sensores de presión y temperatura integrados en la IMU. Además, el código aplica un modelo de atmósfera empleando la presión y la temperatura para estimar la altitud (por definición, respecto al nivel del mar). Esta resulta muy necesaria a la hora de calcular la distancia entre el UAV y el suelo. Los datos son mostrados en el Monitor Serial de Arduino, obteniéndose una visualización como la que se muestra en la Figura 17. Figura 17. Resultados mostrados por el Monitor Serial del código sensorapi Se muestra un primer bloque de iniciación y verificación del sensor, donde se observa el rango y la resolución de presiones posibles. Posteriormente se imprime, actualizándose recurrentemente, los valores de presión, temperatura y la estimación de la altitud que se obtienen de los sensores. Las pruebas se han realizado en Sevilla en Verano, de modo que los valores de temperatura y presión son muy razonables. Para obtener una buena estimación de la altitud es necesario actualizar la presión a nivel de mar en la función Adafruit_Sensor.h, incluida en la librería que debemos tener guardada. 49 • Código de los giróscopos L3GD20, denominado sensorapi: en este caso se extraen los valores de velocidades angulares en los tres ejes que recogen los tres giróscopos dispuestos de tal manera. Esos datos son imprescindibles para que el vehículo autónomo conozca la velocidad de giro en cualquier eje, y en caso de integrar estos datos, conocer la inclinación del vehículo en cualquier dirección. Sin embargo, no están implementados estos pasos en este código. Finalmente se presentan los datos en el Monitor Serial como se muestra en la Figura 18. Figura 18. Resultados mostrados por el Monitor Serial del código sensorapi Al inicio se muestra el bloque de iniciación y verificación del sensor, donde se puede comprobar que todo funciona correctamente, y además se muestra el rango de valores para la velocidad angular. Después se muestra dicha velocidad angular en los tres ejes. Para obtener unos datos más ilustrativos se ha realizado esta prueba girando la placa lo más uniformemente posible alrededor del eje Z, por lo que se puede comprobar que los valores de los giros alrededor de los ejes X e Y tienden a ser nulos, y sin embargo, existe velocidad angular alrededor del eje Z • Código del acelerómetro/ magnetómetro LSM303, denominado accelsensor: a pesar de que el sensor LSM303 incluye una serie de acelerómetros y magnetómetros, este código solamente está destinado a leer los valores de las aceleraciones que obtienen los acelerómetros situados en los tres ejes. Al igual que en el resto de casos, estas aceleraciones se podrían integrar para obtener la 50 velocidad que experimenta el vehículo, pero al igual que anteriormente, esto no está implementado en este código. Finalmente las aceleraciones se presentan en el Monitor Serial como se muestra en la Figura 19. Figura 19. Resultados mostrados por el Monitor Serial del código accelsensor Como en los casos anteriores, primeramente se muestra el bloque de iniciación y validación de los sensores. Debajo de este se pueden ver las líneas con los valores, actualizándose en intervalos regulares, de las aceleraciones en los tres ejes, correspondientes a cada uno de los acelerómetros. En este caso se ha situado la placa sobre una superficie nivelada horizontalmente, de modo que podemos comprobar que sobre los ejes X e Y no actúa ninguna aceleración, sin embargo, podemos observar cómo sobre el eje Z se refleja la acción de la fuerza de la gravedad, con unos valores bastante aceptables. • Código del acelerómetro/ magnetómetro LSM303, denominado magsensor: como en el caso anterior solo disponíamos de un código para extraer los valores de las aceleraciones, necesitamos este código para conocer los datos que ofrecen los magnetómetros en los tres ejes. Igualmente, los datos se muestran en el Monitor Serial, como ilustra en la Figura 20. Como en el caso anterior, observamos al inicio un bloque de iniciación y comprobación del sensor, y después los valores del campo medido en micro-Tesla, debido al campo magnético terrestre, actualizándose repetitivamente. 51 • Código de integración de la IMU, denominado tester: en este caso, se presenta el primero de los códigos que no solo obtiene los datos de uno de los sensores, si no que recoge los datos de todos al mismo tiempo. Como su nombre indica, no realiza ninguna operación aparte de actuar como un test de cada uno de los sensores por separado y presentar todos los datos recogidos en conjunto. Por ello, al igual que sucedía en los códigos anteriores, inicialmente en el Monitor Serial se muestra el bloque de inicio y verificación de cada uno de los sensores por separado, idénticos a los presentados hasta ahora. Después se muestra un bloque con todos los datos, que se actualiza a intervalos regulares. El resultado se ejemplifica en la Figura 21. Como se puede comprobar se muestran, por este orden, las aceleraciones, el campo magnético, las velocidades angulares, presión, temperatura y altitud estimada. • Código de integración de la IMU, denominado ahrs: este es el primer código que procesa los datos de todos los sensores para devolver una información más útil desde el punto de vista de la estabilización de nuestro vehículo o la obtención de la actitud de algún dispositivo. Además se proporciona la temperatura y la presión, datos que igualmente son muy importantes para obtener propiedades del movimiento del vehículo, como el número de Mach. En la Figura 22 mostramos el resultado que se ve en el Monitor Serial. Figura 20. Resultados mostrados por el Monitor Serial del código magsensor 52 Figura 21. Resultados mostrados por el Monitor Serial del código tester Figura 22. Resultados mostrados por el Monitor Serial del código ahrs Como se puede observar, en primer lugar se obtienen los valores asociados a lo que se denomina Orientation, y que se corresponden con los ángulos de alabeo, cabeceo y guiñada que experimentaría un vehículo, según el eje X. Se ilustran estos ángulos en la Figura 23. 53 Figura 23. Ángulos de cabeceo (pitch), balance (roll) y guiñada (yaw o heading). De este modo la IMU detecta alabeo nulo cuando el eje Z se alinea con la vertical, devolviendo ángulos positivos y negativos cuando se inclina a uno u otro lado de dicha posición, llegando hasta los 180 grados, momento en el que cambia de signo. Obtenemos cabeceo nulo cuando el eje X se posiciona horizontal, de modo que cuando este eje se sitúa verticalmente se alcanzan 90 grados positivos o negativos, y comienza a decrecer si el dispositivo continua girando, hasta alcanzar de nuevo un ángulo nulo. Y resulta una guiñada nula cuando el eje X se orienta hacia el norte, de modo que los ángulos varían entre 180 y -180 grados. Hay que tener en cuenta que el eje X que se muestra en la Figura 15 no corresponde con el eje X verdadero que considera el dispositivo, teniendo este que apuntar en el sentido opuesto, debido a un problema estético indicado por el fabricante. Finalmente se muestra la altitud estimada a partir de los datos de aire y la temperatura del entorno. • Código de integración de la IMU, denominado pitchrollheading: este es el último de los programas que la compañía Adafruit ofrece para implementarlos junto a la IMU que empleamos. Como hemos dicho, estos códigos integrados combinan los datos de todos los sensores para obtener información relevante. Más en profundidad, este código obtiene la misma información que el código anterior, pero la presenta de manera diferente. Por lo que conociendo la función de uno de los programas, el otro es redundante. Igualmente, se obtienen los ángulos de Alabeo, Cabeceo y Guiñada, en este orden, y además la temperatura y la altitud estimada. El resultado obtenido en el Monitor Serial se muestra en la Figura 24. 54 Figura 24. Resultados mostrados por el Monitor Serial del código pitchrollheading 3.4 Descripción del software relevante Debido a que agrupar la totalidad de los programas de la IMU ofrecería información redundante, es importante seleccionar algunos de ellos para, una vez integrados, que ofrezcan todos los datos necesarios para la correcta navegación de nuestro vehículo. Principalmente esto es debido a que uno de los códigos que consiguen obtener un AHRS de nuestra IMU, tras combinar los datos de todos los sensores instalados, solamente ofrece los ángulos de guiñada, cabeceo y alabeo de la situación actual. Esto es perfecto para la estabilización, pero no involucra la trayectoria seguida en cada punto, por lo que vemos necesario incluir explícitamente los datos de las aceleraciones experimentadas por el vehículo. Para este propósito hemos seleccionado los dos programas siguientes, de los que se presenta el código. Además, se han dividido en bloques para ir comentando la función que realiza cada uno de ellos por separado. 3.4.1 pitchrollheading Anteriormente se comentó la función que realiza este código, pero no se especificó como realiza su función. Para ello exponemos a continuación el código involucrado, tal y como se puede leer en el IDE. La única modificación ha sido la división en bloques comentada en el párrafo anterior. /*----------------------------------------------------------------------------------------------------------- */ /*Bloque 1*/ #include <Wire.h> #include <Adafruit_Sensor.h> 55 #include <Adafruit_LSM303_U.h> #include <Adafruit_BMP085_U.h> #include <Adafruit_10DOF.h> /*----------------------------------------------------------------------------------------------------------- */ /*Bloque 2*/ /* Assign a unique ID to the sensors */ Adafruit_10DOF dof = Adafruit_10DOF(); Adafruit_LSM303_Accel_Unified accel = Adafruit_LSM303_Accel_Unified(30301); Adafruit_LSM303_Mag_Unified mag = Adafruit_LSM303_Mag_Unified(30302); Adafruit_BMP085_Unified bmp = Adafruit_BMP085_Unified(18001); /* Update this with the correct SLP for accurate altitude measurements */ float seaLevelPressure = SENSORS_PRESSURE_SEALEVELHPA; /*----------------------------------------------------------------------------------------------------------- */ /*Bloque 3*/ /*! @brief Initialises all the sensors used by this example */ void initSensors() { if(!accel.begin()) { /* There was a problem detecting the LSM303 ... check your connections */ Serial.println(F("Ooops, no LSM303 detected ... Check your wiring!")); while(1); } if(!mag.begin()) { /* There was a problem detecting the LSM303 ... check your connections */ Serial.println("Ooops, no LSM303 detected ... Check your wiring!"); while(1); } if(!bmp.begin()) { /* There was a problem detecting the BMP180 ... check your connections */ Serial.println("Ooops, no BMP180 detected ... Check your wiring!"); while(1); } } /*----------------------------------------------------------------------------------------------------------- */ /*Bloque 4*/ void setup(void) { 56 Serial.begin(115200); Serial.println(F("Adafruit 10 DOF Pitch/Roll/Heading Example")); Serial.println(""); /* Initialise the sensors */ initSensors(); } /*----------------------------------------------------------------------------------------------------------- */ /*Bloque 5*/ /*! @brief Constantly check the roll/pitch/heading/altitude/temperature */ void loop(void) { sensors_event_t accel_event; sensors_event_t mag_event; sensors_event_t bmp_event; sensors_vec_t orientation; /* Calculate pitch and roll from the raw accelerometer data */ accel.getEvent(&accel_event); if (dof.accelGetOrientation(&accel_event, &orientation)) { /* 'orientation' should have valid .roll and .pitch fields */ Serial.print(F("Roll: ")); Serial.print(orientation.roll); Serial.print(F("; ")); Serial.print(F("Pitch: ")); Serial.print(orientation.pitch); Serial.print(F("; ")); } /* Calculate the heading using the magnetometer */ mag.getEvent(&mag_event); if (dof.magGetOrientation(SENSOR_AXIS_Z, &mag_event, &orientation)) { /* 'orientation' should have valid .heading data now */ Serial.print(F("Heading: ")); Serial.print(orientation.heading); Serial.print(F("; ")); } /* Calculate the altitude using the barometric pressure sensor */ bmp.getEvent(&bmp_event); 57 if (bmp_event.pressure) { /* Get ambient temperature in C */ float temperature; bmp.getTemperature(&temperature); /* Convert atmospheric pressure, SLP and temp to altitude */ Serial.print(F("Alt: ")); Serial.print(bmp.pressureToAltitude(seaLevelPressure, bmp_event.pressure, temperature)); Serial.print(F(" m; ")); /* Display the temperature */ Serial.print(F("Temp: ")); Serial.print(temperature); Serial.print(F(" C")); } Serial.println(F("")); delay(1000); } /*----------------------------------------------------------------------------------------------------------- */ • Bloque 1. En esta sección solamente se llama a las funciones indicadas, igualmente proporcionadas por el fabricante, y necesarias para el correcto funcionamiento de la IMU. • Bloque 2. En este bloque se definen las variables que serán resultado de las funciones definidas en el bloque 1. Como se puede observar, dichas magnitudes serán dof, magnitud asociada a una función necesaria para el funcionamiento del conjunto de la IMU, accel, que recoge el resultado de las aceleraciones leídas por el acelerómetro, mag, que almacenará el valor del campo leído por el magnetómetro, y bmp, para la lectura del barómetro. Finalmente se indica que para mayor precisión de la estimación de la altitud se recoge en la variable seaLevelPressure la presión a nivel del mar. • Bloque 3. En este se define una función auxiliar, que será llamada posteriormente, y cuyo funcionamiento se emplea para detectar errores de conexión en el cableado entre la IMU y la placa Arduino. Simplemente comprueba que todo se encuentre en buen estado, y en caso contrario muestra el siguiente mensaje: "Ooops, no LSM303 detected ... Check your wiring!". Este mensaje se da en el caso de que los acelerómetros-magnetómetros de la placa fallen, pero para el resto de casos, el mensaje es análogo simplemente 64 • La placa pesa unos 8.5 gramos y sus dimensiones son de 25.5 x 35 x 6.5. • Sensibilidad de hasta -165dBm (3.16 ∙10−17 𝑚𝑚𝑚𝑚), actualizaciones a 10 Hz y 66 canales. • Diseño preparado para alimentación con 5 V y 20 mA de corriente. • Registro de datos integrado. • PPS cuando obtiene una señal fix. • Antena interna y conector u.FL para una antena activa externa. • LED de estado integrado. • Arquitectura basada en un chipset denominado MTK3339, que permite rastrear hasta 22 satélites. De este modo se consiguen hasta 10 posiciones por segundo, útil si el dispositivo se mueve a altas velocidades. • Incluye un regulador de tensión permitiendo alimentarlo con 3.3 V. Resulta un consumo de 66mW. • Se incluye un adaptador para pilas de botón, en el caso de que la batería interna que incluye se agote. • La precisión estimada de este dispositivo es de menos de 3 metros, y la precisión en el cálculo de la velocidad es de 0.1 m, ya que los algoritmos incluidos también permiten la obtención de este parámeto, a partir de la tasa de variación de la posición. • Como se describió anteriormente, la salida se realiza en formato NMEA 0183, por defecto a 9600 baud. • Soporta los sistemas DGPS (GPS diferencial, que ofrece mayor precisión de hasta 10 cm, en el mejor de los casos), WAAS (sistema que se complementa con estaciones en tierra que minimizan posibles fuentes de error, desarrollado por Estados Unidos) y EGNOS (similar a los anterior pero Europeo, empleando una serie de satélites geoestacionarios y estaciones en tierra). El diagrama de bloques de la arquitectura interna del receptor resulta como se muestra en la Figura 25, donde se han indicado los principales elementos que influirán nuestro uso. 65 Figura 25. Diagrama de bloques del receptor GPS. Además se muestra la apariencia del dispositivo en la Figura 26, indicando la correspondencia de los elementos del diagrama de bloques y los de la placa física. Figura 26. Apariencia del receptor GPS indicando sus pines principales 66 Como se puede comprobar, todos los pines indicados en el diagrama de bloques son localizables en la placa en sí, disponiendo de los dos pines que enviarán y recibirán información útil, el pin de alimentación y el pin de conexión con tierra. Además, se ha indicado también la existencia del LED de estado, que parpadea con una frecuencia de una vez por segundo cuando el dispositivo está buscando señal de los satélites (tracking), y lo hace cada quince segundos cuando consigue fijar la comunicación con estos. 4.2 Conexión con Arduino Due. Al igual que ocurre con la IMU, este dispositivo es compatible con nuestra placa Arduino Due, sin más que realizar la conexión pertinente y cargar el programa, que al igual que en el caso anterior, proporciona el fabricante. Los pines a conectar se muestran en la Tabla 5. Pin del GPS Pin del Arduino TX RX pin 19 RX TX pin 18 GND GND VIN 3.3 V power supply Tabla 5. Conexiones entre la placa Arduino Due y el receptor GPS. La conexión resulta finalmente como se muestra en la Figura 27. Figura 27. Diagrama de las conexiones entre la placa Arduino Due y el receptor GPS. 67 Un dato importante a destacar es que ninguno de los pines de comunicación interfiere con los pines que emplea la IMU, de modo que a la hora de integrar ambos, el trabajo resultara mucho más simple. Las comunicaciones de ambos con el microprocesador del Arduino no estarán acopladas en cuanto a cableado. 3.3 Software necesario para el funcionamiento del GPS. Una vez que el dispositivo receptor de señales consigue comunicarse correctamente con los satélites y recibe la información codificada en las ondas, se extraen de ellas las sentencias NMEA que se presentaron con anterioridad, y que se detallarán más adelante. El protocolo NMEA indica que las sentencias incluyen toda la información posible en los campos de información, solamente separada por comas, por lo que más tarde se mostrará las sentencias en cuestión y toda la información que estas transportan. Por ellos es necesario un código que depure las sentencias y las transforme en datos más fáciles de leer y manipular. La compañía Adafruit ofrece una librería de códigos descargable, dentro de la cual encontramos el apropiado para el Arduino Due que usamos. Se muestra a continuación el código en cuestión separado por bloques, como se hizo en el caso de la IMU. Posteriormente se comentará la función de cada uno. /*------------------------------------------------------------------------------------------------------*/ /*Bloque 1*/ #include <Adafruit_GPS.h> #define mySerial Serial1 Adafruit_GPS GPS(&mySerial); // Set GPSECHO to 'false' to turn off echoing the GPS data to the Serial console // Set to 'true' if you want to debug and listen to the raw GPS sentences. #define GPSECHO true // this keeps track of whether we're using the interrupt // off by default! boolean usingInterrupt = false; void useInterrupt(boolean); // Func prototype keeps Arduino 0023 happy /*------------------------------------------------------------------------------------------------------*/ /*Bloque 2*/ void setup() { // connect at 115200 so we can read the GPS fast enough and echo without dropping chars 68 // also spit it out Serial.begin(115200); Serial.println("Adafruit GPS library basic test!"); // 9600 NMEA is the default baud rate for Adafruit MTK GPS'ssome use 4800 GPS.begin(9600); mySerial.begin(9600); /*------------------------------------------------------------------------------------------------------*/ /*Bloque 3*/ // uncomment this line to turn on RMC (recommended minimum) and GGA (fix data) including altitude GPS.sendCommand(PMTK_SET_NMEA_OUTPUT_RMCGGA); // uncomment this line to turn on only the "minimum recommended" data //GPS.sendCommand(PMTK_SET_NMEA_OUTPUT_RMCONLY); // For parsing data, we don't suggest using anything but either RMC only or RMC+GGA since // the parser doesn't care about other sentences at this time // Set the update rate GPS.sendCommand(PMTK_SET_NMEA_UPDATE_1HZ); // 1 Hz update rate // For the parsing code to work nicely and have time to sort thru the data, and // print it out we don't suggest using anything higher than 1 Hz // Request updates on antenna status, comment out to keep quiet GPS.sendCommand(PGCMD_ANTENNA); // the nice thing about this code is you can have a timer0 interrupt go off // every 1 millisecond, and read data from the GPS for you. that makes the // loop code a heck of a lot easier! /*------------------------------------------------------------------------------------------------------*/ /*Bloque 4*/ #ifdef __arm__ usingInterrupt = false; //NOTE - we don't want to use interrupts on the Due #else useInterrupt(true); #endif delay(1000); // Ask for firmware version mySerial.println(PMTK_Q_RELEASE); } #ifdef __AVR__ // Interrupt is called once a millisecond, looks for any new GPS data, and stores it SIGNAL(TIMER0_COMPA_vect) { 69 char c = GPS.read(); // if you want to debug, this is a good time to do it! #ifdef UDR0 if (GPSECHO) if (c) UDR0 = c; // writing direct to UDR0 is much much faster than Serial.print // but only one character can be written at a time. #endif } void useInterrupt(boolean v) { if (v) { // Timer0 is already used for millis() - we'll just interrupt somewhere // in the middle and call the "Compare A" function above OCR0A = 0xAF; TIMSK0 |= _BV(OCIE0A); usingInterrupt = true; } else { // do not call the interrupt function COMPA anymore TIMSK0 &= ~_BV(OCIE0A); usingInterrupt = false; } } #endif //#ifdef__AVR__ /*------------------------------------------------------------------------------------------------------*/ /*Bloque 5*/ uint32_t timer = millis(); void loop() // run over and over again { // in case you are not using the interrupt above, you'll // need to 'hand query' the GPS, not suggested :( if (! usingInterrupt) { // read data from the GPS in the 'main loop' char c = GPS.read(); // if you want to debug, this is a good time to do it! if (GPSECHO) if (c) Serial.print(c); } // if a sentence is received, we can check the checksum, parse it... if (GPS.newNMEAreceived()) { // a tricky thing here is if we print the NMEA sentence, or data // we end up not listening and catching other sentences! // so be very wary if using OUTPUT_ALLDATA and trytng to print out data //Serial.println(GPS.lastNMEA()); // this also sets the newNMEAreceived() flag to false 70 if (!GPS.parse(GPS.lastNMEA())) // this also sets the newNMEAreceived() flag to false return; // we can fail to parse a sentence in which case we should just wait for another } // if millis() or timer wraps around, we'll just reset it if (timer > millis()) timer = millis(); // approximately every 2 seconds or so, print out the current stats if (millis() - timer > 2000) { timer = millis(); // reset the timer Serial.print("\nTime: "); Serial.print(GPS.hour, DEC); Serial.print(':'); Serial.print(GPS.minute, DEC); Serial.print(':'); Serial.print(GPS.seconds, DEC); Serial.print('.'); Serial.println(GPS.milliseconds); Serial.print("Date: "); Serial.print(GPS.day, DEC); Serial.print('/'); Serial.print(GPS.month, DEC); Serial.print("/20"); Serial.println(GPS.year, DEC); Serial.print("Fix: "); Serial.print((int)GPS.fix); Serial.print(" quality: "); Serial.println((int)GPS.fixquality); if (GPS.fix) { Serial.print("Location: "); Serial.print(GPS.latitude, 4); Serial.print(GPS.lat); Serial.print(", "); Serial.print(GPS.longitude, 4); Serial.println(GPS.lon); Serial.print("Speed (knots): "); Serial.println(GPS.speed); Serial.print("Angle: "); Serial.println(GPS.angle); Serial.print("Altitude: "); Serial.println(GPS.altitude); Serial.print("Satellites: "); Serial.println((int)GPS.satellites); } } } /*------------------------------------------------------------------------------------------------------*/ Para comenzar es necesario especificar que, a pesar de que el código está destinado a ser implementado exclusivamente con un Arduino Due, la compañía ha decidido hacerlo más flexible, de modo que se incluyen sentencias que analizan si nuestra arquitectura es ARM o AVR, actuando de un modo u otro debido a las diferencias existentes. Analizamos uno a uno los bloques que hemos definido en el código: 71 • Bloque 1. Este bloque realiza las funciones de iniciación del programa. Para comenzar, como es habitual, se incluye una función que debe estar almacenada en la librería, y que igualmente proporciona la compañía, Adafruit_GPS.h. Posteriormente se definen las comunicaciones entre la placa Arduino y el receptor de GPS. También, como se indica en el comentario, se establece la variable GPSECHO como verdadera, implicando que en nuestro caso las sentencias se mostrarán por pantalla. Para aplicaciones que no requieren esto, se deberá definir dicha variable como falsa. Y por último se crea la variable booleana usingInterrupt, como falsa. Esta variable cambiará a verdadera en el caso de que usemos una arquitectura AVR, utilizando una serie de interrupciones para el correcto funcionamiento del dispositivo. • Bloque 2. El bloque dos comienza con el inicio de la función void setup. En ella se da comienzo a la comunicación con el Monitor Serial a 115200 baud y como indicativo de esto se imprime este mensaje por pantalla: "Adafruit GPS library basic test!". Igualmente se inicia la comunicación con la placa GPS a 9600 baud. • Bloque 3. Dentro aún de la función void setup, se establecen una serie de sentencias que como podemos comprobar envían comandos al GPS. Estas son definidas por el fabricante del núcleo del GPS, que no es el mismo que el de la placa final que poseemos. Sus funciones son modificar el modo en que actúa el GPS, los datos que envía, etc. En nuestro caso, no realizaremos ningún cambio en este sentido. • Bloque 4. El bloque 4 es el núcleo fundamental para aquellos que empleen este código con una arquitectura AVR. En nuestro caso no nos afecta, y podríamos eliminar este bloque entero. Como podemos observar se comienza con un bloque condicional, en el que se vuelve a definir la variable usingInterrupt como falsa si usamos una arquitectura ARM, como es nuestro caso, o como verdadera para el caso de emplear una arquitectura AVR. Después se inicia otro en el que se toman determinadas acciones en el caso de emplear un dispositivo AVR. Y finalmente se detalla la función void useInterrupt. No entraremos en más detalles, porque como hemos dicho, no nos afecta. • Bloque 5. Esta función incluye el bucle del código por completo, y su función será la de leer repetitivamente las sentencias NMEA que se reciben de los satélites de GPS. Antes de entrar en el bucle, se define una variable contador timer, y se le da el valor de los milisegundos en el momento de su lectura. Acto seguido entramos en el bucle. En 72 primer lugar se realiza la lectura de los datos que recibe el GPS, y en caso de que tengamos activada la variable GPSECHO se muestran por pantalla las sentencias NMEA recibidas. Acto seguido se tiene un bloque que, mediante el uso de ciertas funciones predefinidas, analiza si se han obtenido nuevos datos, ya que en caso contrario se muestra por pantalla la última sentencia obtenida para evitarnos mostrar campos vacíos o repetitivos. Ahora aparecen un par de líneas que, debido a que la función millis() tiene un límite, resetea la variable timer en caso de que se supere este límite. Tras esto se tienen las sentencias que regulan lo que se muestra por pantalla, de modo que se imprimen los datos relacionados con el estado de la señal cada dos segundos, y, en el caso de que se obtenga un fix, se muestran datos más específicos de posicionamiento, etc., como se mostrará a continuación. Finalmente el resultado que se muestra por pantalla es como se ve en la Figura 28. Figura 28. Resultados del código aplicable al receptor GPS, mostrados por el Monitor Serial Los datos que se muestran son los siguientes: • Hora GMT (Greenwich Mean Time), el que calculan los relojes atómicos a bordo de los satélites, y que utilizan para coordinarse 73 entre ellos y para calcular con exactitud las distancias necesarias en sus cálculos. Y la fecha actual en el meridiano de Greenwich. • Tras estos datos se muestra el tipo de fix que se ha obtenido, de modo que solamente si se muestra un 1 significa que lo tenemos. • Una vez obtenido el fix podemos consultar los datos de localización, que son los que se muestran a continuación. La estructura de las coordenadas resulta ser dos primeros bits para los grados, y el resto para los minutos con decimales. Tras esto, con la variación de nuestra posición, el código estima nuestra velocidad y nuestro rumbo (en el momento de la toma de la imagen el dispositivo no se encontraba en movimiento, pero los pequeños errores que se producen provoca que el programa calcule una pequeña velocidad y el rumbo). Además, cuando se cuenta con conexión a más de 3 satélites, es posible calcular también nuestra altitud sobre el nivel del mar. • Finalmente se muestra el número de satélites de los que recibimos información. Una vez mostrados los datos básicos, de una manera legible y cómoda de interpretar, se muestran las diferentes sentencias NMEA que recibe nuestro dispositivo, contando cada una con una estructura diferente. El conjunto de sentencias que podemos recibir son: • GPGGA: Global Positioning System Fixed Data. Los valores que contiene, en este orden son el ID del mensaje, la hora UTC, la Latitud y Longitud con su indicador Norte/Sur Este/Oeste, el tipo de fix, el número de satélites en uso, la dilución de precisión horizontal, la altitud de la antena sobre el nivel del mar con su unidad, la separación geoidal con su unidad, un campo específico de DGPS (vacío si no se usa), y bits para el fin del mensaje. • GPGSA: GNSS DOP (dilución de la precisión del sistema global de navegación por satélite) and Active Satellites. Los datos que se muestran son, en este orden, el ID del mensaje, modo Manual o Automático de posicionamiento 2D o 3D (se calcula la altura), tipo de Fix (0 cuando no existe, 1 para 2D y 2 para 3D), número de satélites usados, dilución de la precisión en posición, dilución horizontal de la precisión, dilución vertical de la precisión, bits de fin de mensaje. • GPGSV: GNSS Satellites in View. Los valores que contiene, en este orden, son el ID del mensaje, el número de mensajes (de 1 a 3 dependiendo del número de satélites rastreados), número de satélites 80 5 Integración Final 5.1 Introducción. Como ya se ha dicho, una vez presentada la placa que integrará todos los sensores de medidas inerciales, los sensores de datos de aire, y además, el GPS, solo resta realizar la puesta a punto del conjunto para que trabaje como un sistema interrelacionado. Para comenzar necesitamos realizar la toma de datos de los acelerómetros, ya que será necesario conocer las aceleraciones que sufre nuestro vehículo en todo momento, para en un futuro, poder estimar la posición en la que nos encontramos respecto a la inicial. Como ya comentamos, disponemos del código que extrae los datos de las aceleraciones de los acelerómetros de nuestra IMU y los muestra por pantalla. Por otro lado interesa determinar los ángulos de alabeo, cabeceo y guiñada para conocer en todo momento el rumbo en las tres dimensiones que está tomando nuestro UAV. Por esto, también contamos con el código referente al rumbo, que no solo calcula los giros sufridos por nuestro instrumento, sino que transforma dichos movimientos en los ángulos comentados. Este paso que ya está programado nos ahorra el trabajo de realizar el procesamiento de dichos datos. Además, obtener dichos ángulos a partir de los datos extraídos de los sensores nos indica que quizás ya se está aplicando implícitamente un filtro del ruido, por ejemplo un simple filtro de paso bajo o alguno similar al filtro Kalman. En segundo lugar, tendremos que realizar, coordinadamente con el proceso anterior, la toma de sentencias NMEA del receptor de GPS. Ya disponemos del código que realiza esta función de forma independiente, pero ahora habrá que combinar este con el código anterior de manera que se muestre por pantalla el posicionamiento y el resto de datos que calcula el sistema GPS. En este punto, interesa definir el alcance de nuestro trabajo. Aspiramos a que nuestro dispositivo sea capaz de leer conjuntamente los datos de la IMU y los datos del GPS, evitando que las sentencias colapsen a la hora de su computación, acabando por no obtener un resultado satisfactorio. Y además, una vez obtenidas estas, queremos que se muestren por pantalla o que se cuente con la posibilidad de extraer dicha información a través de cualquier otro pin de la placa Arduino. No pretendemos por tanto combinar ambos datos para que la navegación del UAV sea más satisfactoria, como se realiza en los AHRS actuales o cualquier sistema moderno de navegación, ya que no disponemos de los recursos suficientes para ello. Siendo conscientes de que este paso sería fundamental para situar nuestro 81 dispositivo en el mercado, la dejamos como posible línea de desarrollo futuro. 5.2 Integración del hardware Lo primero que debemos realizar a la hora de poner en común la pareja de dispositivos que ya hemos expuesto, es diseñar la estructura física que tendrá, en el sentido de las conexiones necesarias para que su función se realice de manera correcta. En primer lugar, nuestra IMU se comunica con la placa Arduino mediante el protocolo I2C necesitando para ello lo que podríamos denominar como dos líneas de datos. El primero es el SDA, que será a través del cual se transmitan los datos en serie, y el SCL, que actúa como reloj coordinando durante todo el proceso de comunicación. En segundo lugar, el dispositivo GPS se comunica con la placa Arduino a través de los pines RX y TX, de comunicaciones en serie. Por todo ello y afortunadamente, las conexiones entre la placa Arduino y ambos dispositivos no colisionan físicamente. Esto nos permite conectar directamente estos cuatro buses por separado, consiguiendo que las comunicaciones se realicen con normalidad según se programen en el código. Realmente también hay que incluir otras dos líneas que son necesarias para conectar ambos dispositivos. Estas son la toma de alimentación y la toma de tierra. Como en ambos casos es posible realizar la alimentación a 3.3 V se extraerá una toma común para ambos, al igual que sucederá con la tierra. Finalmente, la conexión resulta como se muestra en la Figura 30. 5.3 Integración del Software Una vez que disponemos de los tres códigos, los dos que extraen datos de la IMU y el que interactúa con el GPS, y todas las funciones necesarias incluidas en nuestra librería, podemos proceder a combinar sus sentencias para obtener un código que realice la función deseada. Comentamos punto por punto los pasos seguidos: • Principalmente se ha combinado ordenadamente ambos códigos, es decir, respetando las funciones que se creaban y manteniendo la estructura existente dentro de cada función void setup o void loop. De este modo incluíamos todo lo necesario en el código final. Sin embargo, había que eliminar las redundancias e incongruencias que se producían. 82 • En este punto detectamos que una de las funciones que empleábamos establecía una comunicación con el Monito Serial a un Baud Rate diferente de las otras dos. Por ello se tuvo que definir una sola sentencia de este tipo, finalizando con un Baud Rate de 115200 baudios. • Además, el código está diseñado para que emita ciertos mensajes de iniciación, que expusimos en su momento, para dar comienzo al funcionamiento de cada sensor por separado. Estos han quedado como comentarios y en su lugar se han sustituido por el mensaje “IMU + GPS”. Aún así se han respetado las funciones que detectaban si el funcionamiento de todo el sistema estaba en correcto estado, devolviendo un mensaje de advertencia en caso contrario. • Dentro del código del GPS existían unas líneas que comprobaban si estábamos empleando una arquitectura AVR, y en este caso se realizaban unas determinadas operaciones para actuar con esta arquitectura de un modo diferente. Como este no es nuestro caso, ya que utilizamos el procesador del Arduino Due con arquitectura ARM, estas líneas acaban apareciendo como comentarios para posibles modificaciones. De esta forma ahorramos espacio en la memoria del Arduino, el proceso de carga se realiza más velozmente y la visualización del código es más simple. Figura 30. Diagrama de las conexiones entre la placa Arduino, la IMU y el receptor GPS. 83 • La medida más importante que se ha tenido que tomar se encuentra dentro del bucle de funcionamiento. A causa de que las sentencias pueden colisionar a la hora de ser procesadas, esta parte del código ha sido dividida en el tiempo en dos módulos. Este proceso de scheduling se ha realizado con ayuda de la función millis(). Así durante los dos primeros segundos desde el inicio del código se ejecuta la parte del código que controla el GPS, recibiendo e interpretando las sentencias NMEA. Se ha comprobado que realizar este proceso dos segundos ha sido óptimo, ya que es el margen que se establece de fábrica para emitir los resultados obtenidos, siendo compatible con el intervalo de tiempo destinado a ello. Tras esto se ejecuta el código relativo a la IMU una vez, que es mucho más simple, ya que solo se tiene que extraer los datos de los sensores que se producen en ese instante, y emitirlos por la vía que corresponda. Estos intervalos de tiempo son fácilmente modificables sin más que cambiar directamente los parámetros que los definen. A continuación procedemos a presentar el código dividido en bloques como ya se hizo anteriormente: /*------------------------------------------------------------------------------------------------------------ */ /*Bloque 1*/ /*Incluir funciones propias del GPS*/ #include <Adafruit_GPS.h> #define mySerial Serial1 Adafruit_GPS GPS(&mySerial); #define GPSECHO false boolean usingInterrupt = false; //void useInterrupt(boolean); /*Incluir funciones propias de la IMU*/ #include <Wire.h> #include <Adafruit_Sensor.h> #include <Adafruit_LSM303_U.h> #include <Adafruit_BMP085_U.h> #include <Adafruit_10DOF.h> /*Asignar denominaciones únicas a los sensores */ Adafruit_10DOF dof = Adafruit_10DOF(); Adafruit_LSM303_Accel_Unified accel = Adafruit_LSM303_Accel_Unified(30301); Adafruit_LSM303_Mag_Unified mag = Adafruit_LSM303_Mag_Unified(30302); Adafruit_BMP085_Unified bmp = Adafruit_BMP085_Unified(18001); /* Update this with the correct SLP for accurate altitude measurements */ float seaLevelPressure = SENSORS_PRESSURE_SEALEVELHPA; 84 /* Assign a unique ID to this sensor at the same time Adafruit_LSM303_Accel_Unified accel = Adafruit_LSM303_Accel_Unified(54321);*/ /*------------------------------------------------------------------------------------------------------------ */ /*Bloque 2*/ void initSensors() { if(!accel.begin()) { /* There was a problem detecting the LSM303 ... check your connections */ Serial.println(F("Ooops, no LSM303 detected ... Check your wiring!")); while(1); } if(!mag.begin()) { /* There was a problem detecting the LSM303 ... check your connections */ Serial.println("Ooops, no LSM303 detected ... Check your wiring!"); while(1); } if(!bmp.begin()) { /* There was a problem detecting the BMP180 ... check your connections */ Serial.println("Ooops, no BMP180 detected ... Check your wiring!"); while(1); } } //void displaySensorDetails(void) //{ // sensor_t sensor; // accel.getSensor(&sensor); // Serial.println("------------------------------------"); // Serial.print ("Sensor: "); Serial.println(sensor.name); // Serial.print ("Driver Ver: "); Serial.println(sensor.version); // Serial.print ("Unique ID: "); Serial.println(sensor.sensor_id); // Serial.print ("Max Value: "); Serial.print(sensor.max_value); Serial.println(" m/s^2"); // Serial.print ("Min Value: "); Serial.print(sensor.min_value); Serial.println(" m/s^2"); // Serial.print ("Resolution: "); Serial.print(sensor.resolution); Serial.println(" m/s^2"); // Serial.println("------------------------------------"); // Serial.println(""); // delay(500); //} 85 /*------------------------------------------------------------------------------------------------------------ */ /*Bloque 3*/ void setup() { /*Líneas del GPS*/ Serial.begin(115200); // Serial.println("Adafruit GPS library basic test!"); // 9600 NMEA is the default baud rate for Adafruit MTK GPS'ssome use 4800 GPS.begin(9600); mySerial.begin(9600); // uncomment this line to turn on RMC (recommended minimum) and GGA (fix data) including altitude GPS.sendCommand(PMTK_SET_NMEA_OUTPUT_RMCGGA); // uncomment this line to turn on only the "minimum recommended" data //GPS.sendCommand(PMTK_SET_NMEA_OUTPUT_RMCONLY); // For parsing data, we don't suggest using anything but either RMC only or RMC+GGA since // the parser doesn't care about other sentences at this time // Set the update rate GPS.sendCommand(PMTK_SET_NMEA_UPDATE_1HZ); // 1 Hz update rate // For the parsing code to work nicely and have time to sort thru the data, and // print it out we don't suggest using anything higher than 1 Hz // Request updates on antenna status, comment out to keep quiet GPS.sendCommand(PGCMD_ANTENNA); /*------------------------------------------------------------------------------------------------------------ */ /*Bloque 4*/ /*Líneas de la IMU- PitchRollHeadingTemperature*/ Serial.println(F("IMU + GPS")); Serial.println(""); /* Initialise the sensors */ initSensors(); /*Líneas de la IMU- Aceleraciones*/ //Serial.println("Accelerometer Test"); Serial.println(""); /* Initialise the sensor */ if(!accel.begin()) { /* There was a problem detecting the ADXL345 ... check your connections */ 86 Serial.println("Ooops, no LSM303 detected ... Check your wiring!"); while(1); } // displaySensorDetails(); } /*------------------------------------------------------------------------------------------------------------ */ /*Bloque 5*/ // the nice thing about this code is you can have a timer0 interrupt go off // every 1 millisecond, and read data from the GPS for you. that makes the // loop code a heck of a lot easier! //#ifdef __arm__ // usingInterrupt = false; //NOTE - we don't want to use interrupts on the Due //#else // useInterrupt(true); //#endif // delay(1000); // Ask for firmware version mySerial.println(PMTK_Q_RELEASE); //#ifdef __AVR__ //// Interrupt is called once a millisecond, looks for any new GPS data, and stores it //SIGNAL(TIMER0_COMPA_vect) { // char c = GPS.read(); // // if you want to debug, this is a good time to do it! //#ifdef UDR0 // if (GPSECHO) // if (c) UDR0 = c; // // writing direct to UDR0 is much much faster than Serial.print // // but only one character can be written at a time. //#endif //} // //void useInterrupt(boolean v) { // if (v) { // // Timer0 is already used for millis() - we'll just interrupt somewhere // // in the middle and call the "Compare A" function above // OCR0A = 0xAF; // TIMSK0 |= _BV(OCIE0A); // usingInterrupt = true; // } else { // // do not call the interrupt function COMPA anymore // TIMSK0 &= ~_BV(OCIE0A); 87 // usingInterrupt = false; // } //} //#endif //#ifdef__AVR__ /*------------------------------------------------------------------------------------------------------------ */ /*Bloque 6*/ uint32_t timer = millis(); uint32_t timer2 = millis(); void loop() { // if millis() or timer wraps around, we'll just reset it if (timer > millis()) timer = millis(); if (timer2 > millis()) timer2 = millis(); if (millis()-timer2>1000){ if (millis()-timer2 < 2000){ // /*Líneas del bucle del GPS*/ // in case you are not using the interrupt above, you'll // need to 'hand query' the GPS, not suggested :( if (! usingInterrupt) { // read data from the GPS in the 'main loop' char c = GPS.read(); // if you want to debug, this is a good time to do it! if (GPSECHO) if (c) Serial.print(c); } // if a sentence is received, we can check the checksum, parse it... if (GPS.newNMEAreceived()) { // a tricky thing here is if we print the NMEA sentence, or data // we end up not listening and catching other sentences! // so be very wary if using OUTPUT_ALLDATA and trytng to print out data //Serial.println(GPS.lastNMEA()); // this also sets the newNMEAreceived() flag to false if (!GPS.parse(GPS.lastNMEA())) // this also sets the newNMEAreceived() flag to false return; // we can fail to parse a sentence in which case we should just wait for another } // approximately every 2 seconds or so, print out the current stats if (millis() - timer > 2000) { timer = millis(); // reset the timer 88 Serial.print("\nTime: "); Serial.print(GPS.hour, DEC); Serial.print(':'); Serial.print(GPS.minute, DEC); Serial.print(':'); Serial.print(GPS.seconds, DEC); Serial.print('.'); Serial.println(GPS.milliseconds); Serial.print("Date: "); Serial.print(GPS.day, DEC); Serial.print('/'); Serial.print(GPS.month, DEC); Serial.print("/20"); Serial.println(GPS.year, DEC); Serial.print("Fix: "); Serial.print((int)GPS.fix); Serial.print(" quality: "); Serial.println((int)GPS.fixquality); /*Se eescriben los datos del GPS solo si se consigue un fix*/ if (GPS.fix) { Serial.print("Location: "); Serial.print(GPS.latitude, 4); Serial.print(GPS.lat); Serial.print(", "); Serial.print(GPS.longitude, 4); Serial.println(GPS.lon); Serial.print("Speed (knots): "); Serial.println(GPS.speed); Serial.print("Angle: "); Serial.println(GPS.angle); Serial.print("Altitude: "); Serial.println(GPS.altitude); Serial.print("Satellites: "); Serial.println((int)GPS.satellites); } } } /*------------------------------------------------------------------------------------------------------------ */ /*Bloque 7*/ if (millis()-timer2>2000){ sensors_event_t accel_event; sensors_event_t mag_event; sensors_event_t bmp_event; sensors_vec_t orientation; /* Calculate pitch and roll from the raw accelerometer data */ accel.getEvent(&accel_event); if (dof.accelGetOrientation(&accel_event, &orientation)) { /* 'orientation' should have valid .roll and .pitch fields */ Serial.print(F("Roll: ")); Serial.print(orientation.roll); Serial.print(F("; ")); Serial.print(F("Pitch: ")); 89 Serial.print(orientation.pitch); Serial.print(F("; ")); } /* Calculate the heading using the magnetometer */ mag.getEvent(&mag_event); if (dof.magGetOrientation(SENSOR_AXIS_Z, &mag_event, &orientation)) { /* 'orientation' should have valid .heading data now */ Serial.print(F("Heading: ")); Serial.print(orientation.heading); Serial.print(F("; ")); } /* Calculate the altitude using the barometric pressure sensor */ bmp.getEvent(&bmp_event); if (bmp_event.pressure) { /* Get ambient temperature in C */ float temperature; bmp.getTemperature(&temperature); /* Convert atmospheric pressure, SLP and temp to altitude */ Serial.print(F("Alt: ")); Serial.print(bmp.pressureToAltitude(seaLevelPressure, bmp_event.pressure, temperature)); Serial.print(F(" m; ")); /* Display the temperature */ Serial.print(F("Temp: ")); Serial.print(temperature); Serial.print(F(" C")); } Serial.println(F("")); sensors_event_t event; accel.getEvent(&event); /* Display the results (acceleration is measured in m/s^2) */ Serial.print("X: "); Serial.print(event.acceleration.x); Serial.print(" "); Serial.print("Y: "); Serial.print(event.acceleration.y); Serial.print(" "); Serial.print("Z: "); Serial.print(event.acceleration.z); Serial.print(" ");Serial.println("m/s^2 "); timer2 = millis(); // reset the timer } } /*------------------------------------------------------------------------------------------------------------ */ 96 demostrar que nuestro sistema es capaz de devolver esta información y la del GPS en serie, pero no es suficiente para aplicaciones reales. Este paso no sería trivial, ya que los errores tanto de lectura debido al ruido, como numéricos producidos durante la doble integración a la que hay que someter a estos datos, son una realidad insalvable, y se irían acumulando con el tiempo. Por todo ello nos veríamos obligados a aplicar determinados filtros para minimizar al máximo estas desviaciones. • A pesar de que la compañía que vende los sensores ofrece documentos sobre cada uno donde se especifica su precisión por separado, no conocemos en qué medida ha podido afectar a dichos valores la integración. Para aumentar la fiabilidad de nuestro sistema será de vital importancia realizar un estudio de cuan finas son las mediciones de nuestro instrumento integrado. Para ello, por ejemplo, habrían de diseñarse experimentos que describiesen el método de realizar precisos movimientos y comprobar si los datos leídos se corresponden con la realidad. • Por último, se tendría que dar el siguiente paso en la integración de los dos dispositivos en cuestión. Por ahora se ha obtenido un equipo capaz de obtener las aceleraciones en las tres direcciones (importante a nivel estructural y como paso previo a obtener las velocidades y los desplazamientos), los ángulos que definen el rumbo del vehículo (para conocer en qué dirección y sentido nos movemos), la coordenadas geográficas en que nos encontramos, dos estimaciones de la altitud (necesaria a la hora del despegue y aterrizaje; se contaría con una tercera obtenida a partir de las aceleraciones), entre otros. Sin embargo, estos datos son independientes. En los dispositivos actuales, todos ellos interactúan con el objeto de obtener una navegación más satisfactoria. Por todo ello habría que estudiar la aplicación de un algoritmo que, combinando los datos de medidas inerciales y del GPS, obtenga mejores resultados que los que se pueden obtener por separado. A pesar de la idoneidad que este paso supone, resulta ser el menos factible, debido a que estos algoritmos no son mayoritariamente mostrados por las empresas, por lo que la carencia de información supondría una falta de referencias. En este momento podemos decir que se espera que el punto en el que nuestro proyecto concluye pueda servir como base de siguientes desarrollos, contribuyendo a que más personas puedan formarse en el vasto y joven mundo de la aviónica de los UAV. 97 Referencias 1. Introduction to Avionics Systems, R.P.G. Collinson, Second Edition 2. http://en.wikipedia.org/wiki/History_of_unmanned_aerial_vehicles 3. http://webdiis.unizar.es/~neira/docs/ABarrientos-CEDI2007.pdf...Grupo de Robótico y Cibernética, Universidad Politécnica de Madrid 4. http://www.jpaerospace.com/Tandem/tandem.html 5. http://apeironuav.org/?p=205 6. http://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ve d=0CDMQFjAC&url=http%3A%2F%2Fdspace.mit.edu%2Fbitstream%2 Fhandle%2F1721.1%2F50382%2F40169626- MIT.pdf%3Fsequence%3D2&ei=e3ieVZXaIsHfU4iwu7AL&usg=AFQjCN HbYMqcPU8i9p1zS9duzizspCQrrA&bvm=bv.96952980,d.d24 7. http://www.rada.com/images/brochures/uav_avionics.pdf 8. http://www.rada.com/capabilities/avionics/mavins.html 9. http://www.uadrones.net/systems/research/acrobat/050418.pdf 10. http://pulseaero.com/products/uav-autopilots.php 11. http://www.uavnavigation.com/products/uav-autopilot-vector7 12. http://www.uavnavigation.com/products/uav-autopilot-proton 13. https://www.openpilot.org 14. http://www.micropilot.com/pdf/brochures/brochure-MP2x28.pdf 15. http://www.micropilot.com/pdf/brochures/brochure-MP2128LRC-HELI.pdf 16. www.micropilot.com/pdf/brochures/brochure-MP21283x.pdf 17. http://www.airelectronics.es/products/?PHPSESSID=e5f3d7011u4rt8t6l6 bjn8rio1 18. http://www.adafruit.com/product/1604 19. http://www.adafruit.com/products/746 20. https://learn.adafruit.com/adafruit-ultimate-gps 21. https://upload.wikimedia.org/wikipedia/commons/c/c1/Yaw_Axis_Correct ed.svg 22. https://es.wikipedia.org/wiki/Sistema_de_posicionamiento_global 98 Anexos • Anexo 1. Tutorial: Adafruit 10-DOF IMU Breakout • Anexo 2. Data Sheet: GlobalTop-FGPMMOPA6H Adafruit 10-DOF IMU Breakout Created by Kevin Townsend Last updated on 2014-02-07 03:00:14 PM EST 2 3 3 5 5 6 6 8 8 8 8 9 9 10 11 12 12 12 12 Guide Contents Guide Contents Introduction Related Links Connecting It Up Basic Setup (5V Logic, Arduino Uno, etc.) Advanced Setup 3V3 Setup Software LSM303DLHC, L3GD20, BMP180 Drivers Downloading Libraries from Github Adafruit_10DOF Library Helper Functions bool accelGetOrientation ( sensors_event_t *event, sensors_vec_t *orientation ) bool magGetOrientation ( sensors_axis_t axis, sensors_event_t *event, sensors_vec_t *mag_orientation ) bool magTiltCompensation ( sensors_axis_t axis, sensors_event_t *mag_event, sensors_event_t *accel_event ) Example Sketch Design Files Datasheets Dimensions (Inches) Schematic © Adafruit Industries http://learn.adafruit.com/adafruit-10-dof-imu-breakout-lsm303-l3gd20- bmp180 Page 2 of 13 Introduction Adafruit's 10DOF (10 Degrees of Freedom) breakout board allows you to capture ten (err, eleven!) distinct types of motion or orientation related data. After testing a lot of combinations of sensors, we settled on the following devices that we think offer the best results and the least amount of hassle: LSM303DLHC - a 3-axis accelerometer (up to +/-16g) and a 3-axis magnetometer (up to +/-8.1 gauss) on a single die L3GD20 - a 3-axis gyroscope (up to +/-2000 dps) BMP180 - A barometric pressure sensor (300..1100 hPa) that can be used to calculate altitude, with an additional on-board temperature sensor Related Links The Adafruit 10DOF board and library reuses the existing Adafruit drivers for the LSM303DLHC (accelerometer and magnetometer), the L3GD20 (gyroscope) and the BMP180 (pressure/altitude sensor). For information about these particular drivers, consult the following learning guides: Please note that there is a small cosmetic error on the first revision of these boards Please note that there is a small cosmetic error on the first revision of these boards (shown above). (shown above). The straight X arrow for the accelerometer should be pointing in the The straight X arrow for the accelerometer should be pointing in the opposite direction, towards the right. opposite direction, towards the right. This will be fixed in the net run of these This will be fixed in the net run of these boards. boards. © Adafruit Industries http://learn.adafruit.com/adafruit-10-dof-imu-breakout-lsm303-l3gd20- bmp180 Page 3 of 13 LSM303DLHC Learning Guide (http://adafru.it/cXW) L3GD20 Learning Guide (http://adafru.it/cXX) BMP180 Learning Guide (http://adafru.it/cXY) This breakout is basically just a smooshed together version of all three so anything you can do with those libraries/guides will follow here. © Adafruit Industries http://learn.adafruit.com/adafruit-10-dof-imu-breakout-lsm303-l3gd20- bmp180 Page 4 of 13 Connecting It Up All of the sensors on the Adafruit 10DOF breakout communicate via a two-pin I2C bus, making it relatively easy to setup with a minimum number of cables: Basic Setup (5V Logic, Arduino Uno, etc.) We'll be using an Arduino UNO here, but the code will work on a Mega or Leonardo just fine. Most other Arduino compatibles should have no problems either but we only support official Arduinos for code. Connect the SCL pin on the breakout to the SCL pin on your Arduino. On an UNO & '328 based Arduino, this is also known as A5, on a Mega it is also known as digital 21 and on a Leonardo/Micro, digital 3 Connect the SDA pin on the breakout to the SDA pin on your Arduino. On an UNO & '328 based Arduino, this is also known as A4, on a Mega it is also known as digital 20 and on a Leonardo/Micro, digital 2 Connect the VIN pin on the breakout to 3.3V or 5V on your Uno (5V is preferred but if you have a 3V logic Arduino 3V is best) Connect the GND pin on the breakout to the GND pin on your Uno That's it! With those four wires, you should be able to talk to any of the I2C chips on the board To interface with the sensor, you will need to solder in wire or header into the To interface with the sensor, you will need to solder in wire or header into the breakout row at the bottom. You cannot 'press fit' or 'twist' wires in, they will not breakout row at the bottom. You cannot 'press fit' or 'twist' wires in, they will not make good contact! Soldering is required make good contact! Soldering is required © Adafruit Industries http://learn.adafruit.com/adafruit-10-dof-imu-breakout-lsm303-l3gd20- bmp180 Page 5 of 13 and run any of the example sketches. Advanced Setup While most people probably won't need to use the pins below, we've also broken out a few extra pins for advanced users or for special use cases. If you need to use any of these pins, simply hook them up to a GPIO pin of your choice on the Uno: GINT - The interrupt pin on the L3GD20 gyroscope GRDY - The 'ready' pin on the L3GD20 gyroscope LIN1 - Interrupt pin 1 on the LSM303DLHC LIN2 - Interrupt pin 2 on the LSM303DLHC LRDY- The ready pin on the LSM303DLHC These pins are all outputs from the 10-DOF breakout and are all 3.3V logic, you can use them with 5V or 3V as 3.3V registers 'high' on 5V systems. 3V3 Setup If you are using an MCU or board with 3V3 logic (instead of the 5V logic used by the Arduino Uno), you can still power the 10-DOF with the VIN pin or you can use the 3Vo pin, which will bypass the on-board 3V3 regulator and level shifting: Connect Vin or 3Vo on the breakout to the 3.3V supply on your target MCU Connect GND on the breakout to GND on the target MCU Like other breakouts on Adafruit, the 10 DOF Breakout is fully level shifted, and you Like other breakouts on Adafruit, the 10 DOF Breakout is fully level shifted, and you can safely use it on 3V3 or 5V systems. can safely use it on 3V3 or 5V systems. © Adafruit Industries http://learn.adafruit.com/adafruit-10-dof-imu-breakout-lsm303-l3gd20- bmp180 Page 6 of 13 © Adafruit Industries http://learn.adafruit.com/adafruit-10-dof-imu-breakout-lsm303-l3gd20- bmp180 Page 7 of 13 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. No.16 Nan-ke 9 th Rd, Science-Based Industrial Park, Tainan, 741, Taiwan, R.O.C. Tel: +886-6-5051268 / Fax: +886-6-5053381 / Email: [email protected] / Web: www.gtop-tech.com Data Sheet The FGPMMOPA6 H is a 4 th generation stand - alone GPS module with lightning fast TTFF, ultra high sensitivity (-165dBm), and low power consumption in a small form factor (16*16*4.7mm) GlobalTop Technology Inc. FGPMMOPA6H GPS Standalone Module Data Sheet Revision: V0A 2 2 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # Version History Title : GlobalTop F G PMMOPA6 H Datasheet Subtitle : GPS Module Doc Type : Datasheet Revision Date Author Description V0A 2012-1-31 Delano Preliminary 3 3 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # Table of Contents 1. Functional Description ........................................................................................................... 4 1.1 Overview ....................................................................................................................... 4 1.2 Highlights and Features ................................................................................................ 5 1.3 System Block Diagram................................................................................................... 6 1.4 Multi-tone active interference canceller ...................................................................... 7 1.5 1PPS .............................................................................................................................. 7 1.6 AGPS Support for Fast TTFF (EPO™) ............................................................................. 7 1.7 EASY™ ........................................................................................................................... 7 1.8 AlwaysLocate™ (Advance Power Periodic Mode) ......................................................... 9 1.9 Embedded Logger function .......................................................................................... 9 2.0 Antenna Advisor ........................................................................................................... 9 2. Specifications ....................................................................................................................... 10 2.1 Mechanical Dimension ............................................................................................... 10 2.2 Recommended PCB pad Layout .................................................................................. 11 2.3 Pin Configuration ........................................................................................................ 12 2.4 Pin Assignment ........................................................................................................... 13 2.5 Description of I/O Pin ................................................................................................. 14 2.6 Specification List ......................................................................................................... 16 2.7 Absolute Maximum Ratings ........................................................................................ 17 2.8 Operating Conditions .................................................................................................. 17 2.9 GPS External Antenna Specification (Recommended) ............................................... 17 3. Protocols .............................................................................................................................. 18 3.1 NMEA Output Sentences ............................................................................................ 18 3.2 Antenna Status Protocol (Antenna Advisor) ............................................................... 24 3.3 MTK NMEA Command Protocols ................................................................................ 24 3.4 Firmware Customization Services ............................................................................... 25 4. Reference Design .................................................................................................................. 26 4.1 Reference Design Circuit ............................................................................................. 26 5. Packing and Handling ............................................................................................................ 27 5.1 Moisture Sensitivity .................................................................................................... 27 5.2 Packing ........................................................................................................................ 28 5.3 Storage and Floor Life Guideline ................................................................................. 30 5.4 Drying .......................................................................................................................... 30 5.5 ESD Handling ............................................................................................................... 31 6. Reflow Soldering Temperature Profile ................................................................................... 32 6.1 SMT Reflow Soldering Temperature Profile ................................................................ 32 6.2 Manual Soldering ........................................................................................................ 36 7. Contact Information .............................................................................................................. 37 4 4 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 1. Functional Description 1.1 Overview The FGPMMOPA6H utilizes the MediaTek new generation GPS Chipset MT3339 that achieves the industry’s highest level of sensitivity (-165dBm ) and instant Time-to-First Fix (TTFF) with lowest power consumption for precise GPS signal processing to give the ultra-precise positioning under low receptive, high velocity conditions. The module a revision of POT (Patch On Top) GPS Module with an extra embedded function for external antenna I/O and comes with automatic antenna switching function and short circuit protection, also features a antenna system called “Antenna Advisor” that helps with the detections and notifications of different antenna statuses, including active antenna connection, antenna open circuit and antenna shortage. Up to 12 multi-tone active interference canceller (ISSCC2011 award), customer can have more flexibility in system design. Supports up to 210 PRN channels with 66 search channels and 22 simultaneous tracking channels, Module supports various location and navigation applications, including autonomous GPS,QZSS, SBAS(note) ranging (WAAS, EGNO, GAGAN, MSAS), AGPS. FGPMMOPA6H is excellent low power consumption characteristic (acquisition 82mW, tracking 66mW), power sensitive devices, especially portable applications, need not worry about operating time anymore and user can get more fun. Note: SBAS can only be enabled when update rate is less than or equal to 5Hz. Application:  Handheld Device  Tablet PC/PLB/MID  M2M application  Asset management  Surveillance 5 5 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 1.2 Highlights and Features  Built-in 15X15X2.5mm ceramic patch antenna on the top of module  Ultra-High Sensitivity: -165dBm (w/o patch antenna), up to 45dB C/N of SVs in open sky reception.  High Update Rate: up to 10Hz (note1)  12 multi-tone active interference canceller ( note2) [ISSCC 2011 Award -Section 26.5] (http://isscc.org/doc/2011/isscc2011.advanceprogrambooklet_abstracts.pdf )  High accuracy 1-PPS timing support for Timing Applications (10ns jitter)  AGPS Support for Fast TTFF (EPO ™ Enable 7 days/14 days )  EASY ™ ( note2) : Self-Generated Orbit Prediction for instant positioning fix  AlwaysLocate ™ ( note2) Intelligent Algorithm (Advance Power Periodic Mode) for power saving  Logger function Embedded ( note2)  Automatic antenna switching function  Antenna Advisor function  Gtop Firmware Customization Services  Consumption current(@3.3V): • Acquisition: 25mA Typical • Tracking: 20mA Typical  E911, RoHS, REACH compliant note 1: SBAS can only be enabled when update rate is less than or equal to 5Hz. note2: Some features need special firmware or command programmed by customer, please refer to G-top “GPS command List” 6 6 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 1.3 System Block Diagram 7 7 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 1.4 Multi-tone active interference canceller Because different application (Wi-Fi, GSM/GPRS, 3G/4G, Bluetooth) are integrated into navigation system, the harmonic of RF signal will influence the GPS reception, The multi-tone active interference canceller (abbr: MTAIC) can reject external RF interference which come from other active components on the main board, to improve the capacity of GPS reception without any needed HW change in the design. PA6H can cancel up to 12 independent channels interference continuous wave (CW) 1.5 1PPS A pulse per second (1 PPS) is an electrical signal that very precisely indicates the start of a second. Depending on the source, properly operating PPS signals have typical accuracy ranging 10ns. 1 PPS signals are used for precise timekeeping and time measurement. One increasingly common use is in computer timekeeping, including the NTP protocol. A common use for the PPS signal is to connect it to a PC using a low-latency, low-jitter wire connection and allow a program to synchronize to it: PA6H supply the high accurate 1PPS timing to synchronize to GPS time after 3D-Fix. A power-on output 1pps is also available for customization firmware settings. 1.6 AGPS Support for Fast TTFF (EPO ™) The AGPS (EPO™) supply the predicated Extended Prediction Orbit data to speed TTFF ,users can download the EPO data to GPS engine from the FTP server by internet or wireless network ,the GPS engine will use the EPO data to assist position calculation when the navigation information of satellites are not enough or weak signal zone . About the detail, please link Gtop website . 1.7 EASY™ The EASY™ is embedded assist system for quick positioning, the GPS engine will calculate and predict automatically the single emperies ( Max. up to 3 days )when power on ,and save the predict information into the memory , GPS engine will use these information for positioning if no enough information from satellites, so the function will be helpful for positioning and TTFF improvement under indoor or urban condition. 8 8 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # Figure 1.12-1 EASY System operation Please refer to the Fig 1.12-1, When GPS device great the satellite information from GPS satellites, the GPS engine automatically pre-calculate the predict orbit information for 3 days The GPS device still can quickly do the positioning with EASY ™ function under weak GPS signal. 9 9 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 1.8 AlwaysLocate™ (Advance Power Periodic Mode) Embedded need to be executed full y all the time , the algorithm can be set by different necessary to decide the operation level of GPS function , reduce power consumption , it will suffer positing accuracy to get the target of power saving and extend the usage time of product . (The positioning accuracy of reporting location < 50m (CEP) 1.9 Embedded Logger function The Embedded Logger function don’t need host CPU (MCU ) and external flash to handle the operation , GPS Engine will use internal flash (embedded in GPS chipset ) to log the GPS data (Data format : UTC, Latitude , longitude, Valid ,Checksum ), the max log days can up to 2 days under AlwaysLocate™ condition . Note Note: Data size per log was shrunk from 24 bytes to 15 bytes. 2.0 Antenna Advisor “Antenna Advisor” is a brand new antenna system available exclusively for PA6H. It is designed to detect and notify antenna status using software (through proprietary protocol on Chapter 3.2). Antenna Advisor can detect and notify the following: • Active Antenna Shorted • Using Internal Antenna • Using Active Antenna 1 10 0 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 2. Specifications 2.1 Mechanical Dimension Dimension: (Unit: mm, Tolerance: +/- 0.2mm) 1 17 7 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 2.7 Absolute Maximum Ratings The voltage applied for VCC should not exceed 4.3VDC. Symbol Min. Typ. Max. Unit Power Supply Voltage VCC 3 . 0 3.3 4 . 3 V Backup battery Voltage V BACKUP 2. 0 3.0 4.3 V 2.8 Operating Conditions Condition Min. Typ. Max. Unit Operation supply Ripple Voltage - - - 50 mVpp RX0 TTL H Level VCC=3.0~4.3V 2.0 - VCC V RX0 TTL L Level VCC=3.0~4.3V 0 - 0.8 V TX0 TTL H Level VCC=3.0~4.3V 2.4 - 2.8 V TX0 TTL L Level VCC=3.0~4.3V 0 - 0.4 V Current Consumption @ 3.3V, 1Hz Update Rate Acquisition - 25 - mA Tracking - 20 - mA Backup Power Consumption@ 3V 25°C - 7 - uA 2.9 GPS External Antenna Specification (Recommended) It is important that the antenna gets a clear view of the sky and is positioned on a surface level to the horizon for best results. The following specification has to meet for the use reference design. Characteristic Specification Polarization Right - hand circular polarized Frequency Received 1.57542GHz +/ - 1.023MHz Power Supply 3V to 3.6V DC Current 4 mA ~ 20 mA at 3.3V Total Gain > + 15dBi ( Two - stage LNA ) Output VSWR < 2.5 Impedance 50ohm Noise Figure < 1.5dB 1 18 8 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 3. Protocols 3.1 NMEA Output Sentences Table-1 lists each of the NMEA output sentences specifically developed and defined by MTK for use within MTK products Table - 1: NMEA Output Sentence Option Description GGA Time, position and fix type data. GSA GPS receiver operating mode, active satellites used in the position solution and DOP values. GSV The number of GPS satellites in view satellite ID numbers, elevation, azimuth, and SNR values. RMC Time, date, position, course and speed data. Recommended Minimum Navigation Information. VTG Course and speed information relative to the ground. 1 19 9 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # GGA—Global Positioning System Fixed Data. Time, Position and fix related data Table-2 contains the values for the following example: $GPGGA,064951.000,2307.1256,N,12016.4438,E,1,8,0.95,39.9,M,17.8,M,,*65 Table - 2: GGA Data Format Name Example Units Description Message ID $GPGGA GGA protocol header UTC Time 064951.000 hhmmss.sss Latitude 2307.1256 ddmm.mmmm N/S Indicator N N=north or S=south Longitude 12016.4438 dddmm.mmmm E/W Indicator E E=east or W=west Position Fix Indicator 1 See Table - 3 Satellites Used 8 Range 0 to 14 HDOP 0.95 Horizontal Dilution of Precision MSL Altitude 39.9 meters Antenna Altitude above/below mean-sea-level Units M meters Units of antenna altitude Geoidal Separation 17.8 meters Units M meters Units of geoids separation Age of Diff. Corr. second Null fields when DGPS is not used Checksum *65 <CR> <LF> End of message termination Table - 3: Position Fix Indicator Value Description 0 Fix not available 1 GPS fix 2 Differential GPS fix 2 20 0 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # GSA—GNSS DOP and Active Satellites Table-4 contains the values for the following example: $GPGSA,A,3,29,21,26,15,18,09,06,10,,,,,2.32,0.95,2.11*00 Table - 4: GSA Data Format Name Example Units Description Message ID $GPGSA GSA protocol header Mode 1 A See Table - 5 Mode 2 3 See Table - 6 Satellite Used 29 SV on Channel 1 Satellite Used 21 SV on Channel 2 .... …. …. .... Satellite Used SV on Channel 12 PDOP 2.32 Position Dilution of Precision HDOP 0.95 Horizontal Dilution of Precision VDOP 2.11 Vertical Dilution of Precision Checksum *00 <CR> <LF> End of message termination Table - 5: Mode 1 Value Description M Manual—forced to operate in 2D or 3D mode A 2D Automatic—allowed to automatically switch 2D/3D Table - 6: Mode 2 Value Description 1 Fix not available 2 2D (<4 SVs used) 3 3D ( 4 SVs used)≧ 2 21 1 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # GSV—GNSS Satellites in View Table-7 contains the values for the following example: $GPGSV,3,1,09,29,36,029,42,21,46,314,43,26,44,020,43,15,21,321,39*7D $GPGSV,3,2,09,18,26,314,40,09,57,170,44,06,20,229,37,10,26,084,37*77 $GPGSV,3,3,09,07,,,26*73 Table - 7: GSV Data Format Name Example Units Description Message ID $GPGSV GSV protocol header Number of Messages 3 Range 1 to 3 (Depending on the number of satellites tracked, multiple messages of GSV data may be required.) Message Number1 1 Range 1 to 3 Satellites in View 09 Satellite ID 29 Channel 1 (Range 1 to 32) Elevation 36 degrees Channel 1 (Maximum 90) Azimuth 029 degrees Channel 1 (True, Range 0 to 359) SNR (C/No) 42 dBHz Range 0 to 99, (null when not tracking) .... …. …. .... Satellite ID 15 Channel 4 (Range 1 to 32) Elevation 21 degrees Channel 4 (Maximum 90) Azimuth 321 degrees Channel 4 (True, Range 0 to 359) SNR (C/No) 39 dBHz Range 0 to 99, (null when not tracking) Checksum *7D <CR> <LF> End of message termination 2 22 2 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # RMC—Recommended Minimum Navigation Information Table-8 contains the values for the following example: $GPRMC,064951.000,A,2307.1256,N,12016.4438,E,0.03,165.48,260406,3.05,W,A*2C Table - 8: RMC Data Format Name Example Units Description Message ID $GPRMC RMC protocol header UTC Time 064951.000 hhmmss.sss Status A A=data valid or V=data not valid Latitude 2307.1256 ddmm.mmmm N/S Indicator N N=north or S=south Longitude 12016.4438 dddmm.mmmm E/W Indicator E E=east or W=west Speed over Ground 0.03 knots Course over Ground 165.48 degrees True Date 260406 ddmmyy Magnetic Variation 3.05, W degrees E=east or W=west (Need GlobalTop Customization Service) Mode A A= Autonomous mode D= Differential mode E= Estimated mode Checksum *2C <CR> <LF> End of message termination 2 23 3 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # VTG—Course and speed information relative to the ground Table-9 contains the values for the following example: $GPVTG,165.48,T,,M,0.03,N,0.06,K,A*37 Table - 9: VTG Data Format Name Example Units Description Message ID $GPVTG VTG protocol header Course 165.48 degrees Measured heading Reference T True Course degrees Measured heading Reference M Magnetic (Need GlobalTop Customization Service) Speed 0.03 knots Measured horizontal speed Units N Knots Speed 0.06 km/hr Measured horizontal speed Units K Kilometers per hour Mode A A= Autonomous mode D= Differential mode E= Estimated mode Checksum *06 <CR> <LF> End of message termination 2 24 4 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 3.2 Antenna Status Protocol (Antenna Advisor) The function is for external active antenna only. PGTOP—Status of antenna Table-12 contains the values for the following example: $PGTOP,11,3 *6F Table-12: PGACK Data Format Name Example Units Description Message ID $PGTOP Protocol header Command ID 1 1 Function Type Reference 3 Value of antenna status Example: $PGTOP,11,value*checksum Value: 1=>Active Antenna Shorted 2=>Using Internal Antenna 3=>Using Active Antenna 3.3 MTK NMEA Command Protocols Packet Type: 103 PMTK_CMD_COLD_START Packet Meaning: Cold Start:Don’t use Time, Position, Almanacs and Ephemeris data at re-start. Example: $PMTK103*30<CR><LF> 2 25 5 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 3.4 Firmware Customization Services GlobalTop also offers flexible, value-adding GPS firmware customization services that maximizes the over system efficiencies and power consumptions. Latest functions like Binary Mode, 1-Sentence Output, Geo-fencing and Last Position Retention, please see our website at www.gtop-tech.com under Products / GPS Modules / Software Services for more details. Note: Not all firmware customization services listed below are supported by module. Please contact GlobalTop Sales or Technical Support for more details. 2 26 6 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 4. Reference Design This chapter introduces the reference schematic design for the best performance. Additional tips and cautions on design are well documented on Application Note, which is available upon request. 4.1 Reference Design Circuit Note: 1. Ferrite bead L1 is added for power noise reduction. 2. C1 and C2 bypass should be put near the module. 3. Damping resistors R2,R3,R4 could be modified based on system application for EMI. 4. If you need more support and information on antenna implementation, please directly contact us at [email protected] for further services. 3 33 3 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # Details Suggestions Notes 1 Before proceeding with the reflow - soldering process, the GPS module must be pre-baked. Pre - bake Time: 6 Hours @ 60°±5°C or 4 Hours @ 70°±5°C The maximum tolerated temperature for the tray is 100°C. After the pre-baking process, please make sure the temperature is sufficiently cooled down to 35°C or below in order to prevent any tray deformation. 2 Because PCBA (along with the patch antenna) is highly endothermic during the reflow-soldering process, extra care must be paid to the GPS module's solder joint to see if there are any signs of cold weld(ing) or false welding. The parameters of the reflow temperature must be set accordingly to module’s reflowsoldering temperature profile. Double check to see if the surrounding components around the GPS module are displaying symptoms of cold weld(ing) or false welding. 3 Special attentions are needed for PCBA board during reflow-soldering to see if there are any symptoms of bending or deformation to the PCBA board, possibility due to the weight of the module. If so, this will cause concerns at the latter half of the production process. A loading carrier fixture must be used with PCBA if the reflow soldering process is using rail conveyors for the production. If there is any bending or deformation to the PCBA board, this might causes the PCBA to collide into one another during the unloading process. 4 Before the PCBA is going through the reflow-soldering process, the production operators must check by eyesight to see if there are positional offset to the module, because it will be difficult to readjust after the module has gone through reflow-soldering process. The operators must check by eyesight and readjust the position before reflow-soldering process. If the operat or is planning to readjust the module position, please do not touch the patch antenna while the module is hot in order to prevent rotational offset between the patch antenna and module Note: References to patch antenna is referred to GPS modules with integrated Patch-on-top antennas (PA/Gms Module Series), and may not be applicable to all GPS modules. 3 34 4 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # Details Suggestions Notes 5 Before handling the PCBA, they must be cooled to 35°C or below after they have gone through the reflow-soldering process, in order to prevent positional shift that might occur when the module is still hot. 1. Can use electric fans behind the Reflow machine to cool them down. 2. Cooling the PCBA can prevent the module from shifting due to fluid effect. It is very easy to cause positional offset to the module and its patch antenna when handling the PCBA under high temperature. 6 1. When separating the PCBA panel into individual pieces using the V-Cut process, special attentions are needed to ensure there are sufficient gap between patch antennas so the patch antennas are not in contact with one another. 2. If V-Cut process is not available and the pieces must be separated manually, please make sure the operators are not using excess force which may cause rotational offset to the patch antennas. 1. The blade and the patch antenna must have a distance gap greater than 0.6mm. 2. Do not use patch antenna as the leverage point when separating the panels by hand. 1. Test must be performed first to determine if V-Cut process is going to be used. There must be enough space to ensure the blade and patch antenna do not touch one another. 2. An uneven amount of manual force applied to the separation will likely to cause positional shift in patch antenna and module. 7 When separating pane l into individual pieces during latter half of the production process, special attentions are needed to ensure the patch antennas do not come in contact with one another in order to prevent chipped corners or positional shifts. Use tray to separate individual pieces. It is possible to chip corner and/or cause a shift in position if patch antennas come in contact with each other. Note: References to patch antenna is referred to GPS modules with integrated Patch-on-top antennas (PA/Gms Module Series), and may not be applicable to all GPS modules. 3 35 5 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # Other Cautionary Notes on Reflow-Soldering Process: 1. Module must be pre-baked before going through SMT solder reflow process. 2. The usage of solder paste should follow “first in first out” principle. Opened solder paste needs to be monitored and recorded in a timely fashion (can refer to IPQC for related documentation and examples). 3. Temperature and humidity must be controlled in SMT production line and storage area. Temperature of 23°C, 60±5% RH humidity is recommended. (please refer to IPQC for related documentation and examples) 4. When performing solder paste printing, please notice if the amount of solder paste is in excess or insufficient, as both conditions may lead to defects such as electrical shortage, empty solder and etc. 5. Make sure the vacuum mouthpiece is able to bear the weight of the GPS module to prevent positional shift during the loading process. 6. Before the PCBA is going through the reflow-soldering process, the operators should check by eyesight to see if there are positional offset to the module. 7. The reflow temperature and its profile data must be measured before the SMT process and match the levels and guidelines set by IPQC. 8. If SMT protection line is running a double-sided process for PCBA, please process GPS module during the second pass only to avoid repeated reflow exposures of the GPS module. Please contact GlobalTop beforehand if you must process GPS module during the 1 st pass of double-side process. Figure 6.2: Place GPS module right-side up when running reflow-solder process, do not invert. 3 36 6 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 9. Module must be pre-baked before going through SMT solder reflow process. 10. The usage of solder paste should follow “first in first out” principle. Opened solder paste needs to be monitored and recorded in a timely fashion (can refer to IPQC for related documentation and examples). 11. Temperature and humidity must be controlled in SMT production line and storage area. Temperature of 23°C, 60±5% RH humidity is recommended. (please refer to IPQC for related documentation and examples) 12. When performing solder paste printing, please notice if the amount of solder paste is in excess or insufficient, as both conditions may lead to defects such as electrical shortage, empty solder and etc. 13. The reflow temperature and its profile data must be measured before the SMT process and match the levels and guidelines set by IPQC. 6.2 Manual Soldering Soldering iron: Bit Temperature: Under 380°C Time: Under 3 sec. Notes: 1. Please do not directly touch the soldering pads on the surface of the PCB board, in order to prevent further oxidation 2. The solder paste must be defrosted to room temperature before use so it can return to its optimal working temperature. The time required for this procedure is unique and dependent on the properties of the solder paste used. 3. The steel plate must be properly assessed before and after use, so its measurement stays strictly within the specification set by SOP. 4. Please watch out for the spacing between soldering joint, as excess solder may cause electrical shortage 5. Please exercise with caution and do not use extensive amount of flux due to possible siphon effects on neighboring components, which may lead to electrical shortage. 6. Please do not use the heat gun for long periods of time when removing the shielding or inner components of the GPS module, as it is very likely to cause a shift to the inner components and will leads to electrical shortage. 3 37 7 This document is the exclusive property of GlobalTop Tech Inc. and should not be distributed, reproduced, into any other format without prior permission of GlobalTop Tech Inc. Specifications subject to change without prior notice. Copyright © 2011 GlobalTop Technology Inc. All Rights Reserved. F G PMMOPA6H Dat a Sheet GlobalTop Technology Ver. V0 A Document # 7. Contact Information GlobalTop Technology Inc. Address: No.16 Nan-ke 9rd Road Science-based Industrial Park, Tainan 741, Taiwan Tel: +886-6-5051268 Fax: +886-6-5053381 Website: www.gtop-tech.com Email: [email protected]