Supervisión remota de parámetros medioambientales capturados
Anuncio
PROYECTO FIN DE CARRERA Título Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Autor/es Eduardo Garbayo Herce Director/es Montserrat Gil Martínez y Javier Rico Azagra Facultad Escuela Técnica Superior de Ingeniería Industrial Titulación Proyecto Fin de Carrera Departamento Ingeniería Eléctrica Curso Académico 2013-2014 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado, proyecto fin de carrera de Eduardo Garbayo Herce, dirigido por Montserrat Gil Martínez y Javier Rico Azagra (publicado por la Universidad de La Rioja), se difunde bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. Permisos que vayan más allá de lo cubierto por esta licencia pueden solicitarse a los titulares del copyright. © © El autor Universidad de La Rioja, Servicio de Publicaciones, 2014 publicaciones.unirioja.es E-mail: [email protected] Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado PROYECTO FIN DE CARRERA: “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR VEHÍCULO AÉREO NO TRIPULADO” Peticionario: DEPARTAMENTO DE INGENIERÍA ELECTRICA Informantes: Eduardo Garbayo Herce Alumno de Ingeniería Industrial Universidad de La Rioja Lugar y Fecha: Logroño, 12 de Julio de 2014 1 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 2 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado NORMA USADA Este proyecto se basa principalmente en software. Se ha asesorado para ello cuál sería le norma que más se acercaría para la creación de los documentos finales. Se ha consultado y corroborado en el BOE. Según BOE: https://www.boe.es/diario_boe/txt.php?id=BOE-A-2007-20618 Ilustración 1 Norma usada Como resultado de esta investigación previa la norma a usar en este PFC que lleva por título “Supervisión remota de parámetros medioambientales capturados por UAV“ será la: UNE 157801: 2007 Criterios generales para la elaboración de proyectos de sistemas de información (por ejemplo, proyectos de aplicaciones informáticas) . Esta norma, que tiene su origen en la norma UNE 157001, puede servir de pauta para que los proyectos de Sistemas de Información que se realicen por o para las entidades, tanto organismos públicos como empresas privadas. Tratándose de un PFC, y no un proyecto real comercial ni concursal, el autor de este documento usará algún término y apartado personal referente al trabajo realizado, no incluido en esta norma pero que en su disposición permite y ofrece un documento abierto y no restrictivo. Será interpretación personal la inclusión de dicha documentación esperando acertar en su posicionamiento para que la lectura de esta memoria será lo más clara posible. Partiendo que el software es el elemento clave de este proyecto cabe destacar que existen dos elementos extra, añadidos que completan este PFC y que por sus condicionantes necesitarán una documentación añadida. Serán los circuitos 3 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado electrónicos creados, placas y controladores, y un elemento externo como un Quatricópetero o Multirotor. De este último apenas existe documentación ni normativa en Español, puesto que durante este 2014 están apareciendo las directrices y anteproyectos de funcionamiento, control, y gestión de estos aparatos que acaban de irrumpir con fuerza en nuestro entorno. De ello se parte: 1.- Software. Sobre el 80 % del trabajo realizado. (software para el Hardware Arduino, GPS, 3DR, Xbee + Software para el Ordenador, Processing, web) 2.- Dispositivos electrónicos. Tarjetas, sensores, cableados: 15 % del trabajo total. 3.- Cuatricóptero o Multirotor. 5% del final. Ilustración 2 Gráfico en % de dependencia documental. Como se ve, el apartado más complejo serán las aplicaciones informáticas diseñadas. Ya sean las que harán trabajar a las placas Arduino, las instaladas en el ordenador local, o las usadas en internet en servidores. Se les adjudica un 80% de la valoración total para la decisión de la norma a usar, que como se ha comentado es la UNE 157801: 2007. Pero si solo se usara esta norma quedarían muchos flecos y capítulos por cumplir, tanto para el tema de placas y dispositivos electrónicos como para las condiciones de vuelo de un Multirotor. 4 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Como indica la norma, (UNE 71044 - ISO/IEC 12207: 1995 y UNE 710451 ISO/IEC 141431: 1998) se lee textualmente: “En esta norma no se pretende desarrollar ni condicionar los proyectos a ninguna metodología ni a ningún ciclo de vida que pueda emplearse en la elaboración de los mismos. Tampoco establecerá los procesos que necesiten realizarse, ni el estado del arte para el uso de estas tecnologías que, en caso de considerarse necesaria su inclusión, se hará mediante la referencia a otras normas de carácter técnico que contemplen esto aspectos”. Se permite el uso de la documentación extra que se necesite no siendo restrictiva en ningún momento ni condicionante. Para ello a este proyecto, y para cumplimentar los apartados descritos que quedan fuera de este ámbito de aplicación este documento final se ampliarán con apartados, capítulos y documentos correspondientes a las siguientes normas: UNE 50135: 1996. Documentación. Presentación de informes científicos y técnicos y UNE 157000: 2002 y UNE 157001: 2002 Criterios generales para la elaboración de proyectos. Como siempre las decisiones tomadas se interpretarán como lo que son “subjetivas” y siempre susceptivas de ser exégesis desde otros puntos de vista de Ingenieros de diversas titulaciones. Aquí queda explicada la exposición final de este alumno en cuanto a la calidad y estructura documental. Asumiendo las decisiones tomadas no basadas simplemente en capricho personal sino en justificaciones argumentadas asentadas, en parte de la normativa actual. Por ello se verán documentos como: Planos, Pliego de Condiciones, etc. 1 Que por defecto no forman parte de la UNE 157801: 2007 , pero que el autor considera, ya no solo importantes si no imprescindibles para la interpretación y desarrollo físico de este proyecto. 1 http://www.aenor.es/aenor/normas/buscadornormas/ 5 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Por otro lado el creador de este trabajo, Ingeniero de titulación, pero informático de profesión y autónomo en trabajos de internet durante la última década presentará una memoria más descriptiva que si se tratase de un proyecto comercial o concursal, intentando llegar a un público más amplio no familiarizado con términos muy específicos de software. Incluyendo un exceso de gráficos, diagramas, tablas o enlaces descriptivos en un número elevado. Interprétese por ello que la idea final es la de evitar una pérdida en su lectura y no una carencia informativa o técnica contradiciendo el dicho romano “Excusatio non petita, accusatio manifesta”. Aunque por otro lado esto es solo una corroboración del punto 6.1 de la norma UNE 157801: 2007 que indica “La Memoria debe ser claramente comprensible, no sólo por profesionales especialistas sino por terceros, y en particular por el receptor del producto. Debe redactarse con este espíritu, de forma que la información más detallada y técnica debe ir en los otros documentos básicos y en los anexos.” ORDEN DOCUMENTAL Según la norma UNE 157801: 2007 en su apartado 4.2 el proyecto debe constar de los siguientes documentos básicos: Índice general Memoria Anexos Especificaciones del Sistema Presupuesto Estudios con Entidad Propia Dichos documentos se deben presentar en el orden indicado. Se añadirán como se ha explicado un nuevo capítulo para los Planos, y un Pliego de Condiciones, principalmente técnico, relativo a las condiciones de instalación y gestión del software. 6 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado NUMERACIÓN Y SUBDIVISION DOCUMENTAL Los documentos se numerarán de acuerdo con lo indicado en la Norma UNE 50-132. La división en capítulos surge también de un análisis y consulta personal del autor a dicha norma. Así como la no inclusión de algunos de ellos. 7 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado AGRADECIMIENTOS A mis directores de Proyecto: Montserrat Gil Martínez, y Javier Rico Azagra por haberme acogido en su grupo de trabajo como uno más. A mis compañeros de despacho: Silvano Nájera y Luis García por esa idea genial cuando las puertas se cierran y por aguantar las historias del abuelo. A las empresas Riojawebs.com Diseño y Programación web, a Zainder.com Soluciones Tecnológicas por haberme dado vacaciones de 6 meses.. A la empresa PhoscodeSL por sus cuadricópteros e información. A la Informática especialista en Sistemas, Sofía Soro y a los clientes que me han prestado placas de Arduino, sensores, material extra, etc. A los clientes que he abandonado estos meses: ¡no os vayáis¡. A Ramón Rico y Paloma Maisterra por dejarme interrumpirles en sus tareas para probar mis cachivaches. Al hacker Tijuinem por incentivarme a crear proyectos Open Source. A vosotros, mis indómitos seres cercanos que habéis repetido la palabra “termina” cada seis meses durante los últimos 10 años… A las comunidades, foros y a los creadores de Hardware y Open Source por hacer libre no solo el código si no la información en si misma que crea un mundo mejor, más abierto y de más fácil acceso para todos. Atte. Garba. Julio 2014. [email protected] +34 629486109. @egarbayo Logroño, a 07 de Julio de 2014 8 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado PROYECTO FIN DE CARRERA: “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” DOCUMENTO Nº1: MEMORIA DESCRIPTIVA Peticionario: DEPARTAMENTO DE INGENIERÍA ELECTRICA Informantes: Eduardo Garbayo Herce Alumno de Ingeniería Industrial Universidad de La Rioja Lugar y Fecha: Logroño, 12 de Julio de 2014 1 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 2 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1. MEMORIA ............................................................................................... 16 1.1 OBJETO .................................................................................................................................... 17 1.1.1 PALABRAS CLAVE .................................................................................................................. 17 1.1.2 KEYWORDS ........................................................................................................................... 17 1.1.3 APARTADOS DE LA MEMORIA .............................................................................................. 18 1.2 ANTECEDENTES ........................................................................................................................ 21 1.2.1 ANTECEDENTES DEL AUTOR ................................................................................................. 21 1.2.2 ANTECEDENTES DEL PROYECTO ........................................................................................... 24 1.3 1.2.2.1 QUÉ ES ARDUINO Y SUS ALTERNATIVAS: ........................................................................ 24 1.2.2.2 VEHÍCULO AÉREO NO TRIPULADO UAV. DRONE............................................................. 25 OBJETIVOS DEL PROYECTO ....................................................................................................... 28 1.3.1 OBJETIVOS CUMPLIDOS ........................................................................................................ 29 1.3.2 EXTRAS AÑADIDOS ............................................................................................................... 31 1.3.3 CONOCIMIENTOS PREVISO NECESARIOS .............................................................................. 32 1.3.4 CONOCIMIENTOS A ADQUIRIR ............................................................................................. 32 1.4 CONCLUSIONES Y VÍAS DE CONTINUACIÓN .............................................................................. 34 1.4.1 APLICACIONES ...................................................................................................................... 34 1.5 TIMELINE ................................................................................................................................. 38 1.6 ARDUINO ................................................................................................................................. 40 1.6.1 SELECCIÓN DE LA TARJETA USADA ....................................................................................... 40 1.6.2 ALTERNATIVA CON EL MODULO ETHERNET ........................................................................ 41 1.6.3 POWER OVER ETHERNET, POE ............................................................................................. 42 1.6.4 SALIDA VIA ROUTER A RED ................................................................................................... 42 1.6.5 MODO SERVIDOR EN LOCAL – LOCALHOST .......................................................................... 42 1.6.6 MODO SERVIDOR EN INTERNET ........................................................................................... 44 1.6.7 SENSORES INSTALADOS. ....................................................................................................... 46 1.6.7.1 1.7 OTROS SENSORES............................................................................................................ 47 NUEVO PARADIGMA ................................................................................................................ 48 3 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.7.1 RECOGIDA DE DATOS EN PUERTO SERIE .............................................................................. 49 1.7.2 MODULOS INALAMBRICOS ................................................................................................... 54 1.7.3 SISTEMA 3DR ........................................................................................................................ 54 1.7.4 SISTEMA XBEE - ZIGBEE ........................................................................................................ 56 1.7.5 POSICIONAMIENTO GLOBAL GPS ......................................................................................... 58 1.7.6 EMISIÓN Y RECEPCIÓN DE DATOS ........................................................................................ 60 1.7.7 EMISIÓN DESDE ARDUINO.................................................................................................... 62 1.8 PROCESSING – RECEPCIÓN DE DATOS - .................................................................................... 63 1.8.1 USO DEL PUERTO SERIE COM ............................................................................................... 65 1.8.2 CONSOLAS DE CONTROL EN PROCESSING ............................................................................ 67 1.8.3 CONSOLA BÁSICA.................................................................................................................. 67 1.8.4 CONSOLA COMPLETA DE CONTROL PARA MUESTRESO REALTIME ...................................... 68 1.8.5 CONSOLA COMPLETA DE CONTROL PARA POSICIONAMIENTO GPS .................................... 73 1.8.6 ALTERNATIVAS A ARDUINO-PROCESSING (JAVA,PHP) ......................................................... 80 1.9 PANEL DE ADMIN WEB ............................................................................................................ 82 1.9.1 CAMARA WIFI MONTADA EN DRONE ................................................................................... 83 1.9.2 LIVE STREAMING................................................................................................................... 88 1.9.3 ANGULARES DE GRABACIÓN ................................................................................................ 89 1.9.4 EFECTO FLAN – GELATINA O ROLLING SHUTTER .................................................................. 89 1.9.5 RECEPCIÓN DE VIDEO LIVE STREAMING ............................................................................... 89 1.10 CAPACIDAD DE TRABAJAR EN TIEMPO REAL........................................................................ 92 1.10.1 EN MODO CONSOLA LOCAL.................................................................................................. 92 1.10.2 EN MODO ONLINE. ............................................................................................................... 92 1.11 FLUJO DE DATOS Y OPEN DATA ........................................................................................... 95 1.11.1 OPEN DATA ........................................................................................................................... 96 1.11.2 TIEMPO REAL DE LAS APLICACIONES .................................................................................. 101 1.11.3 FUNCIONAMIENTO MODELO 1 TIEMPO REAL .................................................................... 103 1.11.4 FUNCIONAMIENTO MODELO 2 Y 3 TIEMPO REAL .............................................................. 104 1.11.5 ALTERNATIVA PARA EL MODELO 2 Y 3 ............................................................................... 105 1.12 BOOTSTRAP DE TWITTER .................................................................................................. 107 1.12.1 VISUALIZACIÓN EN INTERNET DE LOS DATOS .................................................................... 110 1.12.2 COMO RESULTADO UN SISTEMA MULTIPLATAFORMA ...................................................... 112 4 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.12.3 FORMATOS GRAFICOS DE LOS DATOS ................................................................................ 113 1.13 VERSIONES DEL SOFTWARE ............................................................................................... 116 1.14 REQUISITOS DE EXPOSICIÓN-PRESENTACIÓN .................................................................... 118 1.15 ORDEN DE PRIORIDAD DOCUMENTAL ............................................................................... 120 1.15.1 1.16 COMPATIBILIDAD Y RELACION ENTRE DICHOS DOCUMENTOS .......................................... 120 BIBLIOGRAFÍA ................................................................................................................... 120 1.16.1 REFERENCIAS BIBLIOGRÁFICAS DE ESTUDIOS CON ENTIDAD PROPIA. ............................... 121 1.17 DEFINICIONES Y ABREVIATURAS........................................................................................ 122 1.18 NORMAS Y REFERENCIAS .................................................................................................. 128 1.18.1 1.19 NORMAS PARA CONSULTA ................................................................................................. 128 INDICE DE ILUSTRACIONES ................................................................................................ 137 2. PLANOS ................................................................................................... 3 2.1 INTRODUCCIÓN ......................................................................................................................... 3 SONDA DE TEMPERATURA NTC ........................................................................................................... 4 SENSOR LDR ........................................................................................................................................ 4 SENSOR LM35 ..................................................................................................................................... 4 POTENCIOMETRO................................................................................................................................ 4 SISTEMA INALAMBRICO XBEE ............................................................................................................. 4 GPS GTPA 013 ..................................................................................................................................... 4 GPS GTPA 013 + LM 35 ....................................................................................................................... 4 LDR + LM35 + XBEE + GPS + ARDUINO ETHERNET ................................................................................ 4 POTENCIOMETRO + GPS + XBEE + ARDUINO....................................................................................... 4 5 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3. ESPECIFICACIONES DEL SISTEMA ...................................................... 3 3.1 CONFIGURACIONES BÁSICAS ..................................................................................................... 3 3.2 CONFIGURACIÓN PUESTA EN MARCHA DEL DRONE ................................................................... 3 3.2.1 3.3 SOFTWARE DE CONFIGURACION ............................................................................................ 7 ARDUINO ................................................................................................................................... 8 3.3.1 PUESTA EN MARCHA .............................................................................................................. 8 3.3.2 PUERTO SERIE ......................................................................................................................... 8 3.3.3 IDE DE ARDUINO ..................................................................................................................... 9 3.3.4 INSTALACIÓN EN WINDOWS XP-7-8-8.1................................................................................. 9 3.3.5 INSTALACIÓN EN LINUX - UBUNTU ....................................................................................... 10 3.3.6 DRIVERS DE ARDUINO. ......................................................................................................... 11 3.3.7 PUERTOS SERIE. .................................................................................................................... 11 3.3.8 PROBLEMAS DE INSTALACIÓN. IDE, DRIVERS, ETC ............................................................... 12 3.3.9 NO DETECTA DRIVERS........................................................................................................... 12 3.3.10 PUERTO OCUPADO ............................................................................................................... 13 3.3.11 MUY LENTO EL IDE BAJO WINDOWS 7 ................................................................................. 14 3.3.12 ARRCANCA LA IDE DE ARDUINO ........................................................................................... 14 3.3.13 USO DE LA SHIELD ETHERNET ............................................................................................... 15 3.3.14 LIBRERÍAS PARA ARDUINO.................................................................................................... 15 3.3.15 CONFIGURANDO LA RED EN MODO LOCALHOST E INTERNET DIRECTO .............................. 16 3.3.15.1 3.4 CONFIGURACIÓN DEL ROUTER ..................................................................................... 21 CONVERTIR EL ORDENADOR EN UN SERVIDOR ........................................................................ 23 3.4.1 CREACIÓN DE UN WAMP ...................................................................................................... 24 3.4.2 CREACIÓN DE UN LAMP ....................................................................................................... 24 3.4.3 COMPROBACIÓN .................................................................................................................. 25 3.4.4 COMUNICACIÓN BÁSICA- COMPROBACIONES ..................................................................... 26 3.4.5 CODIGO BASICO PARA ENVIAR DATOS VIA ETHERNET CON GET A UNA SQL ....................... 26 3.5 ENVÍO DE DATOS DESDE ARDUINO A PROCESSING VIA SERIAL ................................................ 27 3.5.1 3.6 DESDE PHP ............................................................................................................................ 29 INSTALACIÓN DE SENSORES ..................................................................................................... 31 3.6.1 ENTRADAS. SALIDAS PVM. .................................................................................................... 31 6 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6.2 POTENCIOMETRO ................................................................................................................. 33 3.6.2.1 3.6.3 CODIGO BÁSICO EN ARDUINO PARA UN POTENCIOMETRO ........................................... 34 SONDA NTC DE TEMPERATURA ............................................................................................ 35 3.6.3.1 CODIGO ARDUINO PARA NTC – STEINHARHART............................................................. 38 3.6.3.2 CODIGO ARDUINO PARA NTC – MÉTODO 2 - .................................................................. 39 3.6.4 INSTALACIÓN DE UNA LDR ................................................................................................... 41 3.6.4.1 ACONDICIONAMIENTO DE SEÑAL ................................................................................... 42 3.6.5 SENSOR LM35 ....................................................................................................................... 45 3.6.6 CONFIGURACIÓN DEL GPS .................................................................................................... 49 3.6.6.1 CONFIGURACIÓN HARDWARE ........................................................................................ 49 3.6.6.2 CODIGO ARDUINO PARA LECTURA DEL GPS ................................................................... 50 3.6.7 3.7 OTROS SENSORES ................................................................................................................. 54 IDE PARA PROCESSING ............................................................................................................. 55 3.7.1 LIBRERIAS PARA PROCESSSING ............................................................................................. 55 3.7.2 CONDICIONES DE EJECUCIÓN DE PROCESSING .................................................................... 56 3.7.3 PROBLEMAS DE EJECUCIÓN DE PROCESSING ....................................................................... 57 3.7.4 LIBRERIAS PARA PROCESSING............................................................................................... 61 3.7.5 CONDICIONES DEL SISTEMA GRÁFICO .................................................................................. 62 3.8 CONFIGURACION DE XBEE ....................................................................................................... 65 3.8.1 CONFUSIÓN ZIGBEE, Y PROTOCOLO 802.15.4 EN MÓDULOS XBEE...................................... 67 3.8.2 CARACTERÍSTICAS ................................................................................................................. 67 3.8.3 CONFIGURACIÓN DE LOS JUMPERS ...................................................................................... 68 3.8.4 SOFTWARE ............................................................................................................................ 68 3.8.5 HARDWARE........................................................................................................................... 70 3.9 CONFIGURACIÓN DE 3DR ......................................................................................................... 72 3.9.1 SOFTWARE ............................................................................................................................ 72 3.9.1.1 AJUSTES. .......................................................................................................................... 73 3.9.1.2 CONDICIONES TÉCNICAS PARA QUE FUNCIONE PROCESSING........................................ 75 3.9.2 PLANOS ................................................................................................................................. 76 3.9.3 HARDWARE........................................................................................................................... 76 3.10 GPS PARA ARDUINO ............................................................................................................ 77 3.10.1 LIBRERIAS PARA GPS ............................................................................................................. 77 7 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.10.2 INSTALACIÓN DE LIBRERÍAS PARA ARDUINO........................................................................ 79 3.10.3 PROTOCOLO NMEA .............................................................................................................. 80 3.10.4 CONVERSIÓN PERSONALIZADA DE DATOS DMM , DDD ....................................................... 82 3.11 LIVE STREAMING VIA WIFI ................................................................................................... 83 3.11.1 WLAN, LA RED INALAMBRICA ............................................................................................... 85 3.11.2 802,11G ................................................................................................................................ 86 3.11.3 802.11A................................................................................................................................. 86 3.11.4 802.11N ................................................................................................................................ 87 3.11.5 COMPATIBILIDAD DE LOS DOSPOSITIVOS WLAN N .............................................................. 88 3.12 VUELO DEL DRONE .............................................................................................................. 89 3.12.1 CONCICIONES MÍNIMAS DEL DRONE ................................................................................... 89 3.12.2 COMPAS, GPS, IMUS ............................................................................................................. 90 3.12.3 ¿POR QUÉ CALIBRAR LA BRÚJULA? ...................................................................................... 90 3.12.4 ¿CUÁNDO HACERLO?............................................................................................................ 90 3.12.5 AVISOS .................................................................................................................................. 90 3.12.6 PROCDIMIENTO DE CALIBRACIÓN ........................................................................................ 91 3.12.7 SOFTWARE DE CONFIGURACION DE EMISORA Y DRONE ..................................................... 92 4. ANEXOS ................................................................................................... 2 4.1 ARDUINO ................................................................................................................................... 2 4.1.1 ARDUINO MEGA 2 – ARDUPILOT ............................................................................................ 2 4.1.2 IDE DE ARDUINO ..................................................................................................................... 4 4.1.3 ARDUINO LENTO..................................................................................................................... 4 4.2 SENSORES EXTRA ....................................................................................................................... 7 4.2.1 DHT 11 - HUMEDAD................................................................................................................ 7 4.2.2 SERIE MQ X ............................................................................................................................. 8 4.2.3 MQ2. ....................................................................................................................................... 9 4.2.4 MQ3. ..................................................................................................................................... 10 4.2.5 MQ4. ..................................................................................................................................... 10 4.2.6 MQ-5..................................................................................................................................... 10 4.2.7 MQ-6..................................................................................................................................... 11 4.2.8 MQ-7..................................................................................................................................... 11 8 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.2.9 MQ-8..................................................................................................................................... 12 4.2.10 MQ-9..................................................................................................................................... 12 4.2.11 MQ131 .................................................................................................................................. 12 4.2.12 MQ135 .................................................................................................................................. 12 4.2.13 MQ136 .................................................................................................................................. 13 4.2.14 MQ137 .................................................................................................................................. 13 4.2.15 MQ138 .................................................................................................................................. 13 4.2.16 MQ214 .................................................................................................................................. 13 4.2.17 MQ216 .................................................................................................................................. 13 4.2.18 MQ303A ............................................................................................................................... 13 4.2.19 MQ306A ............................................................................................................................... 14 4.2.20 MQ307A ............................................................................................................................... 14 4.2.21 MQ309A ............................................................................................................................... 14 4.2.22 MG811 .................................................................................................................................. 14 4.2.23 AQ-104 .................................................................................................................................. 14 4.2.24 AQ-2 ...................................................................................................................................... 14 4.2.25 AQ-3 ...................................................................................................................................... 15 4.2.26 AQ-7 ...................................................................................................................................... 15 4.3 OTROS FORMATOS .................................................................................................................. 15 4.4 COMUNICACIÓN PUERTO SERIE ............................................................................................... 15 4.4.1 PUERTOS SERIE MODERNOS................................................................................................. 16 4.4.2 USB ESTÁNDAR ..................................................................................................................... 16 4.4.2.1 4.5 PATILLAJE ........................................................................................................................ 18 MODULOS INALAMBRICOS ...................................................................................................... 18 4.5.1 COMUNICACIÓN XBEE .......................................................................................................... 20 4.5.2 XBEE 1MW – SERIE 1 ............................................................................................................ 21 4.5.3 XBEE 2MW – SERIE 2 ............................................................................................................ 21 4.5.4 ARQUITECTURA BÁSICA DE UNA RED XBEE. ......................................................................... 22 4.5.5 MODOS RECIBIR/TRANSMITIR. ............................................................................................. 24 4.5.6 MÁS FUNCIONES .................................................................................................................. 25 4.5.7 MÓDULOS PRO ..................................................................................................................... 30 4.5.8 DIGI EN ESPAÑA, LOGROÑO, LA RIOJA. ................................................................................ 30 4.5.9 LIBRERIA SERIAL. COMUNICACIONES PUERTO SERIE ........................................................... 31 9 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.5.10 4.6 CREACIÓN DE UN TIMELINE ................................................................................................. 32 GPS .......................................................................................................................................... 35 4.6.1 GPS GTPA 013 – BASADO EN MTK3339 - .............................................................................. 35 4.6.2 DETALLES TÉCNICOS ............................................................................................................. 37 4.6.3 DESCARGAS DE HOJAS TECNICAS DRIVERS Y SOFTWARE .................................................... 38 4.6.4 PROTOCOLO NMEA .............................................................................................................. 38 4.6.5 RECEPCIÓN E INTERCAMBIO DE DATOS DEL GPS ................................................................. 39 UTM COORDINADAS....................................................................................................................... 39 COORDENADAS GEOGRÁFICAS (LATITUD, LONGITUD) ................................................................. 40 4.7 ANEJOS NO IMPRESOS PRESENTADOS EN FORMATO DIGITAL ENLAZADO ............................... 40 4.7.1 CUADRO NACIONAL DE ATRIBUCIÓN DE FRECUENCIAS (CNAF) ........................................... 40 4.7.2 SOLUCIONES WIFI DE LARGO ALCANCE ................................................................................ 41 4.7.3 CONFIGURACIÓN CON VERSIÓN CLÁSICA ............................................................................ 41 4.7.4 CONFIGURACIÓN CON VERSIÓN ACTUALIZADA 2014 .......................................................... 44 4.8 IMPORTAR UNA LIBRERÍA PARA FRITZING ............................................................................... 48 4.9 LISTADO DE CODIGOS .............................................................................................................. 49 4.9.1 FUNCIONES BÁSICAS DE ARDUINO ....................................................................................... 49 4.9.1.1 LOCALIZAR LA IP DE MI ARDUINO – DHCP - .................................................................... 49 4.9.1.2 COMUNICACIÓN ARDUINO CON SERVIDORES LOCALES Y REMOTOS............................. 50 4.9.2 4.9.1.2.1 ALGUNOS RESULTADOS DE DIFERENTES CONEXIONES........................................... 51 4.9.1.2.2 LECTURAS BÁSICAS Y CONVERSIONES EN ARDUINO ETHERNET ............................. 52 FUNCIONES BÁSICAS DE PROCESSING .................................................................................. 58 4.9.2.1 CONSOLA 1...................................................................................................................... 58 4.9.2.1.1 VARIABLES DE CONFIGURACIÓN ............................................................................. 58 4.9.2.1.2 PARTE DE LA FUNCIÓN MAIN .................................................................................. 59 4.9.2.1.3 FUNCIONES PARA DIBUJAR FONDOS Y REJILLAS ..................................................... 59 4.9.2.2 CONSOLA PRINCIPAL ....................................................................................................... 64 4.9.2.2.1 DECLARACIÓN DE VARIABLES Y CONFIGURACIONES .............................................. 64 4.9.2.2.2 ALGUNAS FUNCIONES DEL SISTEMA ....................................................................... 65 4.9.2.2.3 OTRAS FUNCIONES COMPARITDAS ENTRE APLICACIONES ..................................... 73 4.9.2.3 CONSOLA GPS ................................................................................................................. 76 4.9.2.3.1 CONFIGURACION PRINCIPAL DE LA CONSOLA GPS ................................................. 76 10 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.9.2.3.2 CONFIGURACIÓN 2 DE LA CONSOLA GPS – SETUP – ............................................... 77 4.9.2.3.3 FUNCION PARA EL CAMBIO DE PROVEEDOR DE MAPAS ........................................ 78 4.9.2.3.4 PARTE DEL BUCLE DE LA FUNCIÓN MAIN ............................................................... 78 4.9.2.3.5 FUNCIONES LLAMADAS EN CONSOLA GPS.............................................................. 80 4.9.3 FUNCIONES BÁSICAS DE LA APLICACIÓN WEB ..................................................................... 85 4.9.3.1 BOOSTRAP DE TWITTER MODIFICADO............................................................................ 85 4.9.3.2 DESARROLLOS EN PHP – MYSQL - HTML......................................................................... 85 4.9.3.2.1 HACER UN GET EXTERNO PARA INSERCCIÓN ......................................................... 85 4.9.3.2.2 BORRAR UN DATO EN UNA BASE DE DATOS ........................................................... 86 4.9.3.2.3 BORRAR TODA UNA BASE DE DATOS ...................................................................... 87 4.9.3.2.4 CREAR UNA BASE DE DATOS DE PRUEBA ................................................................ 87 4.9.3.2.5 INSERTAR UN DATO EN HTML POR GET .................................................................. 88 4.9.3.2.6 BORRAR UN DATO MEDIANTE FORMULARIO ......................................................... 88 4.9.3.2.7 SACA POR PANTALLA EL VALOR DE LA TEMPERATURA ........................................... 89 4.9.3.2.8 MOSTRAR LA BASE DE DATOS ................................................................................. 89 4.10 PENDIENTE .......................................................................................................................... 91 4.11 OPEN SOURCE Y CREATIVE COMMONS................................................................................ 93 4.11.1 OPEN HARDWARE ................................................................................................................ 93 5. PLIEGO DE CONDICIONES .................................................................... 3 5.1 PLIEGO DE CONDICIONES GENERAL ........................................................................................... 4 5.1.1 PLIEGO DE CONDICIONES LEGALES ........................................................................................ 4 5.1.2 CONDICIONES GENERALES ..................................................................................................... 4 5.1.3 CONDICIONES PARTICULARES. ............................................................................................... 8 5.1.4 SEGURIDAD Y CONFIDENCIALIDAD ..................................................................................... 10 5.2 NORMAS LEYES Y REGLAMENTOS ............................................................................................ 11 5.3 PROPIEDAD INTELECTUAL DEL SOFTWARE. .............................................................................. 12 5.3.1 5.4 COMPETENCIAS REFERIDAS A LA PROGRAMACIÓN ............................................................. 12 PLIEGO DE CONDICIONES PARA EL TRATAMIENTO ESTANDARIZADO DE LOS DATOS ............... 18 5.4.1 SEMÁNTICA Y LINKED DATA ................................................................................................. 18 5.4.2 REUTILIZACIÓN DE INFORMACIÓN ....................................................................................... 19 11 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.4.3 JUSTIFICACIÓN Y ENFOQUE ................................................................................................ 19 5.4.4 ALCANCE Y OBJETIVOS ...................................................................................................... 20 5.4.5 CLASIFICACIÓN Y SEGUIMIENTO DE LOS SERVICIOS ELECTRÓNICOS .............................. 20 5.4.6 DATOS ENLAZADOS ............................................................................................................. 21 5.4.7 FACILIDAD AL USUARIO Y MULTICANALIDAD .................................................................. 22 5.4.8 REQUISITOS TÉCNICOS....................................................................................................... 22 5.4.9 PLATAFORMA CLIENTE ........................................................................................................ 23 5.4.10 LISTADO DE NAVEGADORES EN DIFERENTES VERSIONES Y SU COMPATIBILIDAD ............... 24 5.4.11 PERFILES Y PERSONAS ....................................................................................................... 27 5.4.12 CONSULTOR SEMÁNTICO .................................................................................................... 27 5.4.13 ANALISTA FUNCIONAL ......................................................................................................... 27 5.4.14 PROGRAMADOR ................................................................................................................... 27 5.4.15 EXPERTO EN A RQUITECTURA DE LA INFORMACIÓN ....................................................... 27 5.4.16 CONDICIONES DEL SERVICIO.............................................................................................. 28 5.4.17 REPOSITORIO DOCUMENTAL .............................................................................................. 28 5.4.18 PROPIEDAD INTELECTUAL, SEGURIDAD YCONFIDENCIALIDAD. ....................................... 28 5.5 PLIEGO DE CONDICIONES ADMINISTRATIVAS .......................................................................... 30 5.5.1 DOCUMENTACIÓN DEL PROYECTO....................................................................................... 30 5.5.2 CONDICIONES DE SEGURIDAD .............................................................................................. 31 5.5.3 SEGURIDAD Y PREVENCIÓN .................................................................................................. 32 5.5.4 NORMATIVA Y REGLAMENTACIÓN ....................................................................................... 33 5.5.5 ÁMBITO DE ACTUACIÓN ....................................................................................................... 35 5.6 PLIEGO DE CONDICIONES TÉCNICAS ......................................................................................... 36 5.6.1 VERIFICACIONES PREVIAS ..................................................................................................... 36 5.6.2 CONDICIONES GENERALES DE LOS MATERIALES .................................................................. 37 5.6.3 COMPONENTES ELECTRÓNICOS ......................................................................................... 37 5.6.4 SENSORES ............................................................................................................................. 37 5.6.5 MATERIAL DE LOS CABLES .................................................................................................... 39 5.6.6 CARACTERÍSTICAS DE LOS SERVICIOS CIVIL .......................................................................... 39 5.6.7 ENSAMBLADO E INTERCONEXIONADO DE LOS DISTINTOS ELEMENTOS.............................. 39 5.6.8 TEST DE VALIDACIÓN DE DATOS........................................................................................... 39 5.6.8.1 VARIABLES. 5.6.9 VALIDACIÓN DE LA COHERENCIA INTERNA DE LOS DATOS. RELACIONES ENTRE 41 PUESTA EN MARCHA Y MANTENIMIENTO ........................................................................... 41 12 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.6.10 PRECAUCIONES DE USO........................................................................................................ 42 5.6.11 PLIEGO DE CONDICIONES ECONÓMICAS .............................................................................. 42 5.6.11.1 DERECHOS Y DEBERES DEL CONTRATISTA .................................................................... 42 5.6.11.2 DERECHOS ..................................................................................................................... 43 5.6.11.3 DEBERES ........................................................................................................................ 44 5.6.12 DERECHOS Y DEBERES DEL CONTRATANTE .......................................................................... 44 5.6.13 DERECHOS ............................................................................................................................ 44 5.6.14 DEBERES ............................................................................................................................... 44 5.6.15 FORMALIZACIÓN DEL CONTRATO ........................................................................................ 45 5.6.16 EXTINCIÓN DEL CONTRATO .................................................................................................. 45 5.6.17 PLAZOS DE EJECUCIÓN ......................................................................................................... 46 5.6.18 FORMA DE PAGO .................................................................................................................. 46 5.6.19 FIANZA .................................................................................................................................. 47 5.6.20 GARANTÍAS Y PLAZOS DE GARANTÍA .................................................................................... 48 5.7 CALIDAD .................................................................................................................................. 49 5.7.1 5.8 NORMAS DE CALIDAD........................................................................................................... 50 CONCEPTOS COMPRENDIDOS .................................................................................................. 51 5.8.1 CONCEPTOS NO COMPRENDIDOS ........................................................................................ 53 5.8.2 INTERPRETACIÓN DEL PROYECTO ........................................................................................ 54 5.8.3 COORDINACIÓN DEL PROYECTO........................................................................................... 54 5.8.4 MODIFICACIONES AL PROYECTO .......................................................................................... 55 5.8.5 REGLAMENTACIÓN DE OBLIGADO CUMPLIMIENTO ............................................................ 55 5.8.6 DOCUMENTACIÓN GRÁFICA ................................................................................................. 56 5.8.7 DOCUMENTACIÓN FINAL DE OBRA ...................................................................................... 56 5.9 PLIEGO DE CONDICIONES PARA ESTANDARES DEL SOFTWARE ................................................. 58 5.9.1 PLAN DE ASEGURAMIENTO DE LA CALIDAD IEEE STD 730-2002 .......................................... 58 5.9.1.1 LA CALIDAD EN INGENIERÍA DEL SOFTWARE .................................................................. 58 5.9.1.2 DEFINICIÓN DE LA CALIDAD DEL SOFTWARE .................................................................. 59 5.9.1.3 EL MODELO SPICE ........................................................................................................... 60 5.9.1.4 DESCRIPCIÓN DE LOS REQUISITOS DEL SOFTWARE (SRD) .............................................. 61 5.9.1.5 DOCUMENTACIÓN DEL USUARIO ................................................................................... 61 5.9.1.6 PLAN DE GESTIÓN DE CONFIGURACIÓN DEL SOFTWARE (SCMP)................................... 62 5.9.1.7 VERSIONES DEL SOFTWARE ............................................................................................ 62 13 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.1.8 BIBLIOTECA DE SOFTWARE ............................................................................................. 62 5.9.1.9 CONTROL DE LA CONFIGURACIÓN DEL SOFTWARE ........................................................ 62 5.9.2 ESPECIFICACIÓN DE LOS REQUISITOS SOFTWARE IEEE 830 – 1998 ..................................... 63 5.9.2.1 CABE DESTACAR: ............................................................................................................. 63 5.9.2.2 REFERENCIAS .................................................................................................................. 64 5.9.2.3 ELABORACIÓN DE LOS PERFILES DE USUARIO ................................................................ 65 5.9.2.4 FIABILIDAD ...................................................................................................................... 65 5.9.2.5 USABILIDAD..................................................................................................................... 65 5.9.2.6 SEGURIDAD ..................................................................................................................... 66 5.9.2.7 MANTENIMIENTO ........................................................................................................... 66 5.9.2.8 PORTABILIDAD ................................................................................................................ 66 5.9.3 DESCRIPCIONES DEL DISEÑO DE SOFTWARE IEEE STD 1016 – 2009 .................................... 66 5.9.3.1 ÁMBITO DE APLICACIÓN ................................................................................................. 67 5.9.3.2 PROPÓSITO ..................................................................................................................... 67 5.9.4 FUNDAMENTOS DE LAS PRUEBAS. ADAPTADO DEL ESTÁNDAR IEEE 729 ............................ 67 5.9.4.1 INTRODUCCIÓN ............................................................................................................... 67 5.9.4.2 PRUEBAS DE ACEPTACIÓN .............................................................................................. 69 5.9.4.3 ERRORES VS FALLOS ........................................................................................................ 69 5.9.4.4 CRITERIOS PARA DAR POR FINALIZADAS LAS PRUEBAS .................................................. 69 5.9.4.5 REALIZAR PRUEBAS PARA LA IDENTIFICACIÓN DE DEFECTOS......................................... 69 5.9.4.5.1 PRUEBAS VS DEPURACIÓN ..................................................................................... 70 5.9.4.5.2 PRUEBAS Y CERTIFICACIÓN .................................................................................... 70 5.9.4.6 CONCLUSIONES ............................................................................................................... 71 5.9.4.7 PRUEBAS DE SISTEMA ..................................................................................................... 71 5.9.4.8 PRUEBAS DE INSTALACIÓN ............................................................................................. 72 5.9.4.9 PRUEBAS ALFA Y BETA .................................................................................................... 73 5.9.4.10 PRUEBAS DE RENDIMIENTO.......................................................................................... 74 5.9.4.11 PRUEBAS DE CONFIGURACIÓN ..................................................................................... 75 5.9.4.12 PRUEBAS DE FACILIDAD DE USO ................................................................................... 75 5.9.4.13 ANÁLISIS DE LOS VALORES LÍMITE ................................................................................ 75 5.9.4.14 PRUEBAS ORIENTADAS A LA CONFIABILIDAD DEL SOFTWARE ..................................... 76 5.9.4.15 BASADAS EN COMPONENTES ....................................................................................... 76 5.9.4.16 PRUEBAS PARA INTERNET ............................................................................................. 77 5.9.4.17 LAS ESTRATEGIAS DE EVALUACIÓN............................................................................... 77 5.9.4.18 PRUEBAS PARA GUI ....................................................................................................... 78 14 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.4.19 5.9.5 GUÍAS PARA LAS PRUEBAS ............................................................................................ 79 ESTÁNDARES ......................................................................................................................... 81 5.10 ERRORES EN EL PROYECTO .................................................................................................. 83 5.11 LIQUIDACIÓN ...................................................................................................................... 83 5.12 DISPOSICIÓN FINAL ............................................................................................................. 83 6. PRESUPUESTO ....................................................................................... 2 6.1 INTRODUCCIÓN ......................................................................................................................... 2 6.2 ESTADO DE MEDICIONES............................................................................................................ 4 6.3 LISTA DE PRECIOS....................................................................................................................... 6 6.4 LISTA DE MATERIAL.................................................................................................................... 9 6.4.1 PLACAS, ARDUINOS Y COMPONENTES ................................................................................. 10 6.4.2 LICENCIAS EN EL SOFTWARE ................................................................................................ 11 6.4.3 LISTADO DE MATERIAL RELATIVO AL VUELO ........................................................................ 13 6.5 RESUMEN DEL PRESUPUESTO. ................................................................................................. 14 6.6 PRECIO PARA VENTA COMO PACK ........................................................................................... 15 6.7 PRECIO PARA ALQUILER ........................................................................................................... 15 6.8 PRESENTACIÓN A CONCURSOS PUBLICOS. RÉGIMEN CONCURSAL ........................................... 16 7. ESTUDIOS CON ENTIDAD PROPIA........................................................ 3 7.1 MARCO NORMATIVO BÁSICO SOBRE SEGURIDAD Y SALUD ....................................................... 4 7.2 PROYECTOS SOMETIDOS A EVALUACIÓN DE IMPACTO AMBIENTAL .......................................... 6 15 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1. MEMORIA En ella se describirá el objeto de las obras, servicios, y trabajos relativos a este proyecto con Drones, placas microcontroladoras y recogerá los antecedentes y situación previa de las mismas, las necesidades a satisfacer y la justificación de la solución adoptada, descripción de las diferentes unidades de la obra, detallándose los factores de todo orden a tener en cuenta. Asimismo se incluirá el resumen de presupuestos, el plazo de ejecución previsto, la clasificación del contratista de los servicios, índice de los documentos que componen el proyecto, manifestación expresa y justificada de que el proyecto comprende una obra completa o fraccionada según el caso, declaración del cumplimiento de la Ley de Contratos y consideraciones finales. Un esquema aproximado del documento podría ser el que se relaciona a continuación: Antecedentes, Estudios Previos, Estudios Técnicos. Se presenta esta memoria, junto con sus Pliegos de Condiciones, Anejos, Presupuestos y Planos, siguiendo el modelo UNE 157801: 2007 singularizando para un típico de Proyecto Fin de Carrera (PFC) correspondiente al plan clásico de Ingeniería Industrial. Se consultó en cambiar el formato para adaptarlo al modelo actual de “Grado”, pero se recomendó usar el sistema clásico pero actualizado a la norma usada. Como resultado se obtiene una memoria que describe “qué se ha hecho” un pliego de condiciones y unas especificaciones que abarcan “cómo se ha hecho”, “y como se debería hacer, usar”, y unos anejos que incluyen “qué se ha utilizado para”. Aparte de mediciones extras, presupuestos, y planos. Como se ratifica en UNE 157801: 2007 Criterios generales para la elaboración de proyectos de sistemas de información (por ejemplo, proyectos de aplicaciones informáticas). 16 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.1 OBJETO Se diseñará un sistema de bajo coste para la medición de parámetros medioambientales cualesquiera que sean necesarios en dicho contexto mediante un vehículo aéreo no tripulado, Drone, UAD. Se transmitirán dichos datos en tiempo real a una estación remota basada en un ordenador personal (portátil) mediante un sistema inalámbrico. Se almacenará su información tanto en servidores localhost como en internet. Se podrá consultar desde cualquier dispositivo. Ordenador, móvil, tableta, etc. pues se intentará que todo el desarrollo web final sea abierto y “responsive” sin cerrar el acceso a ninguna plataforma. Todo el tratamiento intermedio de la información será un Open Data estándar, que proporcionará un flujo de datos visible en cualquier entorno y accesible desde cualquier dispositivo compatible. 1.1.1 PALABRAS CLAVE Arduino, Vehículo aéreo no tripulado, Processing, Multirotor, Cuadricóptero, Java, PHP, MySQL, JSON, software Tiempo real, parámetro ambiental, diseño responsable, html5, lienzo, código abierto, datos abiertos, entorno de desarrollo, Drone. 1.1.2 KEYWORDS Arduino, unmanned aerial vehicle, Processing, Quadricopter, Java, PHP, MySQL, JSON, Real Time software, environment parameter, responsive web design, html5, canvas, open source, open data, framework, IDE. 17 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.1.3 APARTADOS DE LA MEMORIA Para el desarrollo de esta memoria descriptiva se ha seguido el mismo proceso y “planning” que el progreso material de este proyecto. Se ha optado por una exposición secuencial de cómo se han ido ejecutando las partes de que se compone el proyecto, a modo didáctico. 1.Toma en contacto con la placa microcontroladora Arduino. Instalación de sensores analógicos, conocer sus lecturas, interpretarlas en modo de consola. Convertir las señales de entrada y salida para tener unos valores reales, coherentes. 2.Conocidos estos valores, y al tener la posibilidad de usar una tarjeta Ethernet, se han hecho pruebas de enviar dichos valores directamente a internet. Interpretar las respuestas de la red en modo consola. Crear scripts online basados en PHP y que el Arduino los ejecute para insertar datos en diferentes bases de datos.. 3.Una vez que esto era funcional se pasa a enviar datos por el puerto serie USB mediante cable a otro ordenador. Posteriormente, interpretación de dichos datos con otro lenguaje de programación diferente. En este caso Processing. 4.Cuando las lecturas mediante cable funcionan OK, se quita el cableado y se usan módulos 3DR, y XBee. Se configuran y comprueban resultados. También se hacen comparativas. Como se explicará más adelante, no fue fácil el desconectar el cable … 5.Una vez que la placa Arduino hace lecturas de potenciómetros, LDR, LM35, y otro tipo de sensores y los transmite de forma inalámbrica ya se puede subir a un Drone y tomar valores móviles. 6.Una cámara wifi permitirá seguir las trayectorias y recorridos del Drone. 7.Un GPS instalado en la placa Arduino geoposicionará los datos capturados en un mapa en tiempo real. 18 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 8.Las lecturas ya están configuradas en un ordenador con una consola gráfica que muestra en tiempo real los datos recogidos. 9.Una vez que existe la consola en tiempo real, se comienza a preparar una aplicación en modo local. Para ello convertimos el ordenador en un servidor. 10. Se clonará la información que esté en el modo local con un servidor de internet. 11. La transmisión de datos será Open Data. Es decir, se usarán datos estructurados y estandarizados para que todo el mundo pueda acceder a ellos y poder usarlos en sus aplicaciones. Json. 12. Se creará una aplicación web online que sea compatible y accesible para que se pueda consultar con cualquier dispositivo electrónico. 13. Se intentará que el tiempo entre captura de datos y muestra online sea lo más rápido posible. 14. La muestra de datos será en formato gráfico estandarizado, y con acceso a los mismos de forma sencilla. 19 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Sirva el siguiente diagrama explicativo del proceso: 20 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.2 ANTECEDENTES 1.2.1 ANTECEDENTES DEL AUTOR Presenta el Proyecto que lleva por título oficial y registrado como tal: “Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado” el alumno “Eduardo Garbayo Herce”, con DNI de operador intracomunitario ES16577967G. El autor del presente documento, del software que lo acompaña y del proyecto que representa: asume los principios éticos, morales, y religiosos de la Universidad de La Rioja, y los propios de la Comunidad Riojana; por lo tanto se garantiza que toda la documentación presentada, usada, y finalizada no suponen ningún tipo de daño, lesión, discriminación o amenaza para ninguna persona, ni supone la diseminación de ninguna ideología. El alumno es Ingeniero Técnico en Electrónica Industrial por La Universidad de La Rioja terminando sus estudios en el año 2000. Cursando posteriormente las asignaturas del segundo ciclo de Ingeniería hasta el curso 2004 donde sin presentar el Proyecto Fin de Carrera comienza su carrera laboral como programador profesional. Pionero de internet desde 1996, crea diferentes proyectos relacionados con el diseño web, comercio online, y programación custom (soluciones propietarias) para empresas y código libre Open Source bajo licencias GPL-GNU2. Asimismo aplicando sus estudios de Ingeniería y hardware para la unificación de proyectos de Innovación y Desarrollo. En los últimos años incluyendo el hobby del aeromodelismo en un nuevo proyecto de captación de tomas aéreas mediante cuadricópteros de tamaño medio. Modelos puramente comerciales algunos y otros retocados transformados en su integridad. 2 La Licencia Pública General de GNU 21 y Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Uniendo estos conocimientos previos se ha desarrollado el software y el hardware de este proyecto de Fin de Carrera para la obtención del título de Ingeniería Industrial. En el mundo del Open Source el autor ha creado documentación, software y ha trabajado en proyectos internacionales cooperando dentro de sus limitaciones profesionales. Desde 2003. Es autor de documentación de proyectos Open Soruce nacionales con más de 95k lecturas. Menciones en medios y prensa nacionales y gran repercusión en redes sociales. En el mercado privado el autor es pionero en el uso de sistemas de gestión de contenidos CMS3 desde finales de s.XX. Es autor de código libre y webs para ONG´s gratuitas premiadas en concursos a nivel regional y nacional. Incluidos los extintos premios Fundarco. Gestiona más de 100 dominios en internet en diferentes idiomas de proyectos tan diversos como institucionales. Algunos con más de 2 millones de vistas. Es autor de juegos Open Source bajo C++, Allegro, premiados económicamente en concursos y mencionados en prensa especializada y Universitarias como Universia. Pero todo este bagaje profesional no sirve de nada cuando uno se enfrenta a nuevos proyectos que requieren la vuelta al mundo autodidacta. Enfrentarse con ilusión y ética hacker4 (compromiso, pasión, ilusión) a un nuevo desafío; que es como se deben enfrentar en la vida los nuevos cometidos. Y en este caso lo era. Volver al mundo universitario casi una década después para compaginar trabajo profesional remunerado con un proyecto universitario que requería un tiempo y esfuerzo considerable, más aún cuando se quiere hacer bien: funcional, y operativo; 3 Content Management System 4 Gente entusiasta, apasionada, relacioanda o no con el mundo informático. 22 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado y es que ya se sabe que cuando uno afronta software + hardware + drivers + librerías + versiones; lo más normal es que los problemas surjan en todos los eslabones de la cadena (como así ha sido). Pero mejor realizar el esfuerzo en ello que no desarrollar un proyecto teórico de papel “que todo aguanta”. Y más aún cuando se trata de un proyecto que puede llegar a tener varias aplicaciones reales. …Y todo ello se ha podido llevar a cabo porque el autor ha priorizado este proyecto a su trabajo de autónomo durante 6 meses. Y por la ayuda e información prestada en puntos clave de profesionales muy específicos de más talento que él en dicho cometido. Aun así, el autor de este proyecto aunque agradecido por ello, se considera autor del 95% del resultado. Sirva de recuerdo; mi agradecimiento a todos ellos: 23 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.2.2 ANTECEDENTES DEL PROYECTO En los últimos años ha irrumpido en el mercado la plataforma de hardware libre Arduino. Basada en una placa con un microcontrolador y un entorno de desarrollo, diseñada para facilitar el uso de la electrónica en proyectos multidisciplinares. Es un sistema de trabajo relativamente nuevo ya que proyecto Arduino recibió una mención honorífica en la categoría de Comunidades Digital en el Prix Ars Electrónica de 2006. 1.2.2.1 QUÉ ES ARDUINO Y SUS ALTERNATIVAS: Arduino es un microcontrolador programable. De bajo coste y de licencias de uso gratuitas. Su popularidad ha hecho que salgan clones: Ktuluino, $9 Arduino, Moteino, Chibiduino, Prototino, Paperduino, Kameduino, BoArduino, Vinciduino, Sushiduino dentro , etc. También existen proyectos similares ya de microcontroladores como dispositivos superiores. BASIC Stamp microcontrolador con un intérprete de BASIC. PIC . Microcontroladores tipo RISC5 Raspberry Pi es un micro ordenador que corre con Linux. BananaPI. Clon chino de Rasberry. Otras: BeagleBone, Nanode y Waspmote Udoo, proyecto de 2013, que une ambos mundos. De controladores y microordenadores. *El autor está pendiente (11 Julio 2014) de recibir por parte de Microsoft un Intel Galileo que la compañía está regalando a los desarrolladores para realizar pruebas y proyectos. Para ello, se comunicó a Microsoft que se estaban realizando este tipo de trabajos con dichos microcontroladores como este PFC. 5 Reduced Instruction Set Computer, 24 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Las ventajas de usar Arduino frente a otras, además de su bajo coste que ronda los 50 euros, es por la filosofía ética del proyecto. Basado en Hardware Abierto, y Software Abierto, la comunidad ha creado alrededor de esta placa cientos de aplicaciones funcionales, y un sistema de documentación inmenso que facilita la creación de nuevos proyectos. Y como siempre, mentes activas, abiertas y muy generosas en foros. De la misma forma existen diferentes modelos de placas Arduino y placas shields que incrementan sus funciones hasta unos límites insospechados. Wifi, Ethernet, GSM etc. Paso 1: Se montará la Placa Arduino programada con sus respectivos sensores en un Vehículo Aéreo no Tripulado UAV. Drone. 1.2.2.2 VEHÍCULO AÉREO NO TRIPULADO UAV. DRONE. Para los aficionados al aeromodelismo no es nuevo el uso de helicópteros de gasolina o aviones eléctricos para vuelos de entretenimiento. Si bien es cierto que su uso no ha sido muy popular como ha sido el aplicado a vehículos terrestres. Se debe ello a su complejidad y precio. Volar mediante emisora de 7- 9 canales no es sencillo y requiere de un periodo de aprendizaje que incluye el uso de software de adaptación como simuladores. Y es que “aporrizar” un helicóptero de varios miles de euros no es algo que se pueda permitir un usuario hacer en muchas ocasiones. Es un hobby caro y hasta hace pocos años no estaba al alcance de todos los bolsillos. Algunos además (entre los que se incluye el autor) han añadido cámaras de grabación digitales para realizar tomas aéreas. Material que luego es usado en el trabajo para promocionar en internet: fincas de bodegas, mostrar grandes superficies terrestres para venta, tomas de solares y su avance en la construcción para empresas, etc. Contenido que complemente en la web y redes la imagen de marca de una empresa. Hasta ahora un proceso muy caro y que solo grandes empresas podían permitirse. Enfoque personal : Los que estamos en el negocio de videos comerciales publicitarios y también deportivos vimos hace apenas 4-5 años como empresas extremas asociadas a la marca RedBull usaban los primeros octocópteros para 25 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado realizar grabaciones en alta montaña. El llevar este equipo era mucho más barato y accesible que llevar helicópteros tripulados. Estos octocópteros eléctricos con cámara digital apenas costaban unos pocos miles de euros. Precio que ha bajado a la mitad hoy en día. Aún así era un desembolso, e inversión bastante alto. Lo que hizo que todo aquel que tuviera conocimiento de soldadura, paciencia, y muchas ganas de tirar de manual, empezara comprando kits de montaje de empresas que vendían las piezas para empezar a montarte tu propio DRONE. Principalmente cuadricópteros o hexacópteros. Varias marcas vieron el potencial que tenía esta venta y hace apenas 3 años salen al mercado Kits completos de cuadricópteros por menos de 1000 euros. Equipos que se complementaban y que eran compatibles con las emisores de radio frecuencia que ya todos usuarios disponían y manejaban. Dentro de estas empresas las más “avispadas” fueron Walkera y la americana DJI. Esta última está siendo la que está copando el mercado ya sea con sus kits de desarrollo completos o con su modelo estrella: los Phantom. 1, 2, Vision, etc. Ilustración 3 Kit de montaje de un 450 26 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Estos equipos ya bajan su precio de los 900 euros y montados, funcionales y con su emisora TX., Disponen de sistemas de GPS, estabilización y orientación perfecta y son relativamente fáciles de actualizar con el software propio de la marca. Además hace dos años el primer Phantom1, que salió al mercado tuvo el acierto de montar un adaptador para cámaras deportivas GoPro que es el modelo más usado del mundo en deportes extremos. Lo que le supuso tener una legión de seguidores por toda la red, foros, comunidades, y haber generado con ello un estándar en la grabación semi-profesional aérea. A nivel personal, tanto en cámaras deportivas, de las que soy usuario desde 2007, como de cuadricópteros, que ya he pasado por varios modelos, incluidos todos los Phantom y otros montajes de DJI, lo que se consigue ahora mismo es algo impensable hace apenas 5 años. Todo esto, por otro lado, está generando un problema muy serio de regulación. Son aparatos complejos y ofrecen muchas posibilidades y como tal, se les puede dar mal uso. Estamos en un Boom de Drones y en los próximos años veremos una regulación muy dura para vuelos de estos equipos. Para la presentación de este proyecto se usará un Phantom II de 2013, que será el encargado de cargar la placa Arduino. Más adelante se explicará por qué la decisión de usar este equipo. Se mostrarán otros modelos de cuadricópteros en la presentación como un 450-DJI, y alguno más grande capaces de cargar más de 500 gramos de peso durante 12 minutos. 27 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.3 OBJETIVOS DEL PROYECTO En la documentación presentada en Marzo 2014 se crearon estos objetivos para el desarrollo del proyecto. 1.Configuración básica del sistema UAV (Unmanned Aerial Vehicle- vehículo aéreo no tripulado) para ejecutar cualquier misión de vuelo. Se empleará o un sistema desarrollado comercialmente o se desarrollará un sistema propio. 2.Estudio y selección de parámetros medioambientales a medir y determinación de la aplicación final de la misión de vuelo. Dotación de los sensores específicos para su captura desde el UAV. 3.Montaje de cámara para ayuda en el video guiado del UAV o la toma de imágenes de interés par a la aplicación. 4.Selección del sistema microprocesador capaz de realizar las tareas propias de la misión de vuelo. 5.Selección del sistema de transmisión de datos. Desarrollo de aplicaciones software para: 6.Captura y trasmisión de datos desde el UAV a la estación terrestre (sistema PC). 7.Tratamiento de datos recibidos en modo local. 8.Gestión de la información resultante en servidor LAMP (Linux -sistema operativo-, Apache – servidor web-, MySQL -gestor de bases de datos-, PHP -lenguaje de programación-) 9.Visualización de datos bajo formatos gráficos en página web RWD (Responsive Web Design). 28 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.3.1 OBJETIVOS CUMPLIDOS Se explica a continuación como TODOS, el 100% de lo estimado se ha cumplido en fechas y resultados. Se responde a cada punto anterior con su numeración correspondiente: 1. Configuración básica del sistema UAV (Unmanned Aerial Vehiclevehículo aéreo no tripulado) para ejecutar cualquier misión de vuelo. Se empleará o un sistema desarrollado comercialmente o se desarrollará un sistema propio. Se ha usado un Drone comercial, aunque también existen otros modelos montados; la seguridad y estabilidad del sistema comercial era imprescindible.. 2. Estudio y selección de parámetros medioambientales a medir y determinación de la aplicación final de la misión de vuelo. Dotación de los sensores específicos para su captura desde el UAV. Se han usado dos sensores de temperatura, una sonda NTC y un LM35. Un sensor de Luz LDR, y un potenciómetro para simular señales analógicas. 3. Montaje de cámara para ayuda en el video guiado del UAV o la toma de imágenes de interés par a la aplicación. Se han usado diferentes cámaras de video. Unas para drones grandes y otras menores IP para los Drones más pequeños. Para la presentación del proyecto se hará con una versión comercial de GOPRO vía WIFI. Pero usando software propio para su visualización. 4. Selección del sistema microprocesador capaz de realizar las tareas propias de la misión de vuelo. Se han utilizado diferentes placas Arduino: Uno, Ethernet, Arupilot 29 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5. Selección del sistema de transmisión de datos. Se ha trabajado con cable usb, cable de red y sistemas Inalámbricos para cuando el sistema esté en vuelo. 3DR, Xbee. Desarrollo de aplicaciones software para: 6. Captura y trasmisión de datos desde el UAV a la estación terrestre (sistema PC). Arduino captura bajo su software programado y customizado. 3DR, Xbee transmite.. 7. Tratamiento de datos recibidos en modo local. En modo local, para trabajo en tiempo real de recepción de datos se trabajará bajo Processing. 8. Gestión de la información resultante en servidor LAMP (Linux -sistema operativo-, Apache – servidor web-, MySQL -gestor de bases de datos-, PHP lenguaje de programación-) Toda la información será enviada y transmitida bajo “JSON” . Se enviará a un modo local, localhost, y se duplicará en internet.. 9. Visualización de datos bajo formatos gráficos en página web RWD (Responsive Web Design). Se ha creado en Html5, Javascript, Jquery, css3, Less, PHP, MySQL, un sistema de visualización compatible para web y dispositivos móviles. 30 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.3.2 EXTRAS AÑADIDOS Una vez cumplido todos los objetivos básicos del Proyecto se han creado nuevas aplicaciones que completan, consuman y rematan un proyecto completo y complejo para hacerlo viable en el uso profesional. 1.Toda la programación de Arduino está enfocada y optimizada para poder añadir nuevos sensores para mediciones con mucha facilidad. Tocando muy poco código y usando funciones específicas ya programadas para ello. 2.El envío de los datos se ha optimizado de tal forma que en la setup programada se puede configurar para trabajar con sistemas mucho más complejos. Buffers, interrupciones, codificación, librerías extras. 3.Uso del módulo Ethernet POE para salida directa a internet. Tanto en localhost vía router como MySQL directo. 4.Asimismo la recepción bajo Processing está optimizada y configurada para poder modificar y ampliar el proyecto hasta nuevos horizontes… 5.Dada la relación laboral del alumno con una empresa distribuidora de cuadricópteros se pueden hacer montajes para equipos mucho más potentes, pesados y de mayor autonomía. Se muestran ejemplos. 6.Igualmente, por relaciones comerciales se han podido crear varias aplicaciones prácticas que se adjuntan y presentan como demos. 7.Tratamiento de datos de GPS, para posicionamiento de información en tiempo real. Unfolding, bajo Java, Eclipse, y Processing. 8.Tratamiento del video capturado para análisis y toma de decisiones en tiempo real dependiente de medidas de sensores. 9.Sistema online totalmente actualizable, configurable y compatible con dispositivos móviles de diferentes tamaños y versiones. 31 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.3.3 CONOCIMIENTOS PREVISO NECESARIOS Previo a la realización de un Proyecto Fin de Carrera o un trabajo adjudicado en el mercado laboral, el Ingeniero tiene unos conocimientos previos adquiridos en las asignaturas cursadas en la carrera y con la propia experiencia laboral, que podrá aplicar para llevar a cabo tal cometido; y otras materias en los que aunque no exista conocimiento y se parta de “cero”, se tiene capacidad suficiente para el aprendizaje autodidacta. Ejemplo de conocimientos previos necesarios: Html básico y html5. Javascript. Diferentes lenguajes de Programación y uso de compiladores. C++, Php, Java. Javascript, J2ME. Configuración de servidores en modo local ( localhost ) LAMP6 WAMP Servidores VPS para internet. LAMP. Configuración y vuelo de Cuadricópteros. Live Streaming de video. Video y Foto Aereos. 1.3.4 CONOCIMIENTOS A ADQUIRIR Ingeniero viene de Ingenio, y siempre habrá que estar atento a los cambios del entorno y la mimetización con éste y sus nuevas tecnologías. En una carrera como ingeniería donde el mercado es tan amplio los conocimientos se adquieren según se vayan necesitando la aplicación de nuevas ciencias: De estos campos se partía de cero: 6 Arduino Hardware Linux Apache MySQL PhP 32 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Arduino IDE + GPS + Protocolo NMEA 3DR . Sistemas inalámbricos Xbee – Protocolo inalámbrico Transmisión de video inalámbrica. IP. Wifi. Entorno Processing. “json” como intercambio de datos hard – soft. Bootstrap y SVG en RWD – Responsive Web Design Nunca se había trabajado con la placa microcontroladora Arduino, pero sí se conocía la programación de otros sistemas microprogramables. El software de Arduino es muy similar al C++. El envío de datos de forma inalámbrica también era un campo nuevo en los sistemas Xbee, pero se conocía parte de trabajo bajo Bluetooth y wifi. Asimismo el IDE de Processing, está basado en Java y su uso es una mezcla entre éste y el C++. Siendo todos estos sistemas Open Source ha permitido que sus comunidades online sean muy amplías, y lo que no se ha encontrado en los manuales y bibliografías se ha consultado en los foros de internet de cada aplicación requerida. Aún así, ha habido consultas que como se indica en el Anejo correspondiente no han quedado resueltas. Como por ejemplo hacer un Live Streaming de video bajo el Software Processing. Ya que existen librerías de video, pero no para ese cometido. De esta forma se ha resuelto este problema usando código embebido7 en html5. Y también usando software OS 8 VLC bajo Linux, distribución Ubuntu. 7 Insertar código funcional en otra aplicación eficaz por si misma. 8 De ahora en adelante al referirnos al Open Source 33 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.4 CONCLUSIONES Y VÍAS DE CONTINUACIÓN Uno de los puntos más importantes de este proyecto se basa en la tecnología Arduino. El poder usar este tipo de hardware de forma gratuita en cuanto a licencias se refiere y de bajo coste en su material básico y ampliaciones de la comunidad, abre ya de por sí, un abanico de posibilidades para la creación de proyectos de bajo coste, ya no solo a nivel educativo si no comerciales. Las nuevas placas con wifi, los nuevos Arduino Yun, las actualizadas placas para Ardupilot, y en concreto las módulos con GSM, o Xbee incorporado van a dar la posibilidad de que en los próximos meses se vean, una cantidad ingente de proyectos basados en estas placas, tanto a nivel de ingeniería , como usuarios DIY , “hágalo usted mismo”. Por otro lado la tecnología de vuelo basada en Drones de pequeño tamaño ha irrumpido fuerte en el mercado. Ha abierto un sector meramente profesional a cualquier usuario amateur que se dedique a la grabación aérea, de video y fotografía. Y este mercado es tan amplio que ha crecido exponencialmente porque como ya hemos visto las aplicaciones son inmensas. Esperemos por otro lado que haya una regulación consecuente a nivel europeo, como parece que se impone por lógica. En Julio 2014, ya aparecen noticias en medios de comunicación que Drones mayores de 25 kilos deberán tener un certificado de aeronavegabilidad. Normativa que será ampliada a equipos menores de 5 kilos, dejando el mundo del juguete a los que no lleguen a 1 kilo de peso. Este proyecto nace por iniciativa del alumno de usar este tipo de elementos, del que ya conocía su funcionamiento básico, y compatibilizarlo con Arduino para crear aplicaciones que de momento parecen originales y no muy explotadas. Por tanto, como se ve en el apartado siguiente, se intentará estar en el mercado y poder satisfacer esta posible demanda que existirá en los próximos años: 1.4.1 APLICACIONES Este proyecto nace con la aspiración e ilusión de poder llevarse a cabo en el mundo real. El bajo coste de este PFC principalmente por el uso de licencias libres 34 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado hace bastante viable crear desarrollos con este tipo de componentes. Por otro lado, las posibles aplicaciones de uso con un Drone, serían menores, pero también se nos ocurren unas cuantas. A nivel personal, creo que la tarjeta de Aduino Ethernet o con la shield de red para cualquier otro Arduino abre un mercado profesional muy amplio. Actualmente todo el mundo quiere tener en internet y en su dispositivo móvil los datos que está generando su empresa, fábrica, instalación agrícola, o domótica. Ya sea una bodega que quiere consultar las temperaturas de sus barricas, humedades, un sistema de cámaras frigoríficas, etc a un pequeño agricultor que quiera también conocer de primera mano todos los datos que el entono de su plantación le quiera dar. Hablamos ahí de mediciones estáticas de datos. Pero también la aplicación presentada en este proyecto que permite hacer estos sondeos en altura, y en lugares de accesos complejos, abre otro conjunto de oportunidades muy interesante. Todo ello, cuando la actual legislación de 2014 para estos aparatos se estabilice. El encargado de un Retén de bomberos contactó conmigo hace unas semanas indicando si sería capaz nuestro sistema de hacer ciertas mediciones del terreno en condiciones adversas y suministrar esa información en tiempo real a los ordenadores; Indicando alturas, velocidades, y una lista de parámetros a medida que él nos suministraría. Yo le dije que entonces no podría hacerlo, pero sí en seis meses. Comentó, que para ellos sería muy interesante tener esa aplicación funcionando porque con esos datos y sus tablas de control, podrían por ejemplo calcular en tiempo real unas vías de acceso y escape en incendios en campo abierto. Ahora mismo el sistema sería casi capaz de hacer esas mediciones, a falta de conseguir más autonomía en vuelo y poder cargar más peso: cámaras infrarrojas, etc. Pero en este futuro cercano ya se está viendo cómo se están usando Drones para: Arquitectura Construcción y Edificación 35 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Certificaciones Vigilancia ferrocarril. Grafitis, mediante el uso de de riego, sistemas programados Publicidad y Promociones Control de Tráfico. Gestión de Incendios. Fincas, bodegas. Videos promocionales Inmobiliarias y Promotoras Agricultura – Venta o Control Cuidado de terrenos agrícolas Necesidades visitas, fertilizantes, insecticidas etc. Arqueología Deportes y Eventos Termografía de edificios. Posibilidad de hacerlo y verlo en tiempo real vía web o teléfono móvil. Campos de Golf Paisajismo Jardinería Análisis de Riesgos Cámaras Infrarrojas. Cartografía industrial Seguimiento Forestal Energía Solar Documentales 36 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Videoclips-Spots-televisión-Cine Comunicaciones Corporativas Bienes Raíces Minería Obras Públicas Vigilancia, Seguridad Medio Ambiente … y esto es solo el principio. Desde estas aplicaciones comerciales, a poder llevar nuestro Drone a un volcán y medir la emisión de gases en medio de éste, solo hay unas horas de configuraciones…. y eso ya es una aplicación "custom” . Esta lista de aplicaciones basadas en “Arduino + Drones” han sido seleccionadas de la web de internet Zainder9, Empresa de Tecnología, de la cual el autor de este PFC es socio fundador. Y es a través de ella, desde donde se está intentando llevar al mundo laboral proyectos similares a éste; de bajo coste para pequeñas y medianas empresas. El desarrollo de este PFC ha posibilitado trabajar con nuevos dispositivos y entrar en contacto de nuevo con el mundo universitario, conociendo de primera mano, los nuevos trabajos que se están llevando a cabo en los diferentes departamentos de la Universidad de La Rioja. 9 www.zainder.com 37 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.5 TIMELINE Se adjunta un timeline del proyecto, así como de conocimientos previos y futuras aplicaciones o versiones. Este timeline se puede consultar online. Basado en un sistema JS 10 ofrece la posibilidad de usar su código embebido en cualquier sistema html. Ilustración 4 Time Line 10 JavaScript y Jquery. Posibilidad de trabajo con json también. 38 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 39 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Haciendo click en la imagen se puede ver un timeline online de la evolución del proyecto así como de los conocimientos previos y adquiridos. 1.6 ARDUINO La decisión por tanto de usar Arduino como placa de captura de datos queda reflejada por estos puntos y este orden: 1. Placa Open Source. Tanto Hardware como Software. 2. Libre de Licencias. Tanto para uso educativo como profesional. 3. Amplia documentación y comunidad activa online. 4. Coste. Alrededor de 50 euros. 5. Facilidad de adquisición de diferentes modelos y nuevos módulos para ampliación de capacidades. Aparte de estas funcionalidades se procederá a explicar que: peso, tamaño, compatibilidades y facilidad de conexión con oros dispositivos es el porqué se ha seleccionado un modelo u otro. Es importante recalcar que el peso de los materiales en este proyecto será muy importante. El tiempo de vuelo de un equipo en vacío puede llegar a ser de 1520 minutos, dependiendo de las condiciones atmosféricas, uso o no de ayudas en vuelo como GPS, etc. Una vez cargado el Drone con 200 gramos de peso, el tiempo de vuelo cae a la mitad. El consumo de baterías se duplica. Asimismo el tamaño reduce, pero en menor medida el uso de baterías, pero si decrementa las capacidades de maniobrabilidad. El uso del GPS da la estabilidad del sistema pero su consumo reduce en varios minutos su estancia en vuelo. 1.6.1 SELECCIÓN DE LA TARJETA USADA Cada placa de Arduino tiene pequeñas diferencias con otros modelos. Estado y direcciones de puertos, módulos de comunicación etc. En el software del ordenador además de configurar el puerto de comunicaciones habrá que hacer lo 40 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado mismo con la tarjeta usada. Para ello, el sistema cuando se han instalado los drivers ha creado también una lista de tarjetas soportadas, basadas en los diferentes chips de control de la placa. En este proyecto se han usado principalmente 3 Arduinos: Arduino Ethernet, Arduino Uno, y Arduino Mega 2 especial Ardupilot. Existen otras configuraciones avanzadas en la setup del IDE de Arduino que también requieren unos minutos en la optimización del Software, pero ya no son imprescindibles para su funcionamiento básico. Compilación etc. 1.6.2 ALTERNATIVA CON EL MODULO ETHERNET Al estar trabajando en un proyecto en el que los datos van a tener que llegar a internet en algún momento era imprescindible hacer las primeras pruebas de conexión directamente desde la tarjeta Arduino. Dada la expansión y popularidad de estas tarjetas, existen en el mercado diferentes formas de conectarse a internet desde la placa. Para las antiguas, existe la ampliación con la Ethernet Shield de Arduino, y también opciones como el Arduino Yun que permite hacer conexiones wifi y la básica Arduino Ethernet. Se ha desechado la opción de trabajar mediante el sistema wifi en la transmisión de datos inalámbricos ya que su distancia y estabilidad será menor que los módulos Xbee empleados. Por lo tanto, para hacer las pruebas se ha seleccionado la placa Arduino Ethernet, ya que aunque en el proyecto actual no se va a usar cable, esto permite dos opciones de trabajo para futuras aplicaciones: Poder ser usado mediante cable de Ethernet y su módulo PoE, o subirlo a un equipo en movimiento y enviar los datos en formato inalámbrico. Asimismo el peso al desconectar el usb-serial FDTI es menor. También deja libre el puerto de comunicaciones TX RX para su posterior uso inalámbrico. 41 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 5 Directo a Internet 1.6.3 POWER OVER ETHERNET, POE La alimentación a través de Ethernet es una tecnología que incorpora alimentación eléctrica a una infraestructura LAN estándar. Permite que la alimentación eléctrica se suministre al dispositivo de red. Elimina la necesidad de utilizar tomas de corriente y permite una aplicación más sencilla de los sistemas de alimentación ininterrumpida (SAI) para garantizar un funcionamiento las 24 horas del día. Se regula en la norma IEEE 802.3af y está diseñado de manera que no haga disminuir el rendimiento de comunicación de los datos. 1.6.4 SALIDA VIA ROUTER A RED Una vez conectado el Arduino al Router mediante al cable de red, se tendrá acceso vía IP a cualquier ordenador de internet y también a nuestro ordenador local puesto que se configurará como servidor de datos. El acceso no será como una conexión web, si no, que en modo consola se podrán hacer peticiones básicas que el servidor permita en acceso remoto. Estará muy limitado y habrá que ser muy claro y preciso con lo que se intenta conseguir. 1.6.5 MODO SERVIDOR EN LOCAL – LOCALHOST Nunca se sabrá si dónde se va a trabajar se tendrá una conexión a internet estable. Ya sea wifi, cable, gsm, satélite, etc .. Para no tener dependencia de ésta condición se llevará un ordenador PC estándar configurado como servidor remoto- 42 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado local de datos. En la actualidad esta conversión de un PC a un sistema “localhost” es muy sencilla y para ello se usará un software que instala y configura automáticamente las 3 aplicaciones básicas: Apache para conversión. Para poder ejecutar código y guardar y visualizar directamente se instalará php, MysQL. Ilustración 6 Localhost básico Realizado en Windows se llamará a este sistema: WAMP. Windows + Apache + MySQL + PhP. Bajo Linux LAMP: Linux + Apache + MySQL + PhP Comprobación: Para saber si la instalación ha sido correcta servirá con teclear “localhost” o “127.0.0.1” en la barra del navegador. En el documento Especificaciones del Sistema se entra más en profundidad en esta setup de la red. En este proyecto se han usado ambos sistemas operativos, pero para que la compatibilidad con otros usuarios sea completa, se seguirá como sistemas locales WAMP. Y como servidor de internet LAMP. Pero el funcionamiento a nivel de código es exactamente el mismo. No habría que tocar nada de código ni en php en modo local y ni en Arduino a la hora de enviar los datos. Dentro de un sistema WAMP se ha tomado la decisión de trabajar con EasyPHP. Un software completo que instala y actualiza todas las aplicaciones necesarias. Viniendo por defecto preconfigurado para sistemas Windows y que 43 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado incluye una versión portable de su software. Lo que ha permitido y permite trasladar toda la información de un ordenador a otro copiando simplemente su carpeta de datos. Además de ser de los pocos que están en Español. 1.6.6 MODO SERVIDOR EN INTERNET A nivel amateur en internet se alquilan servidores compartidos “shared” a la hora de contratar los servicios de un hosting para alojar una web personal. Estos servidores están muy limitados en cuanto a uso y ejecución de código extra y se limitan a prestar y compartir espacio y bases de datos. Pero si se va a tener que usar aplicaciones muy customizadas este tipo de servidores suelen dar problemas. El siguiente paso es el uso de servidores VPS 11 o privados totalmente y últimamente servidores tipo cloud. Esto implica que el usuario será el responsable de configurar dichos servidores para su uso personal. Para este proyecto se ha desechado desde el principio el uso de servidores “shared” porque daban problemas a las peticiones externas de http y php. Así como a la inserción de datos desde un sistema externo de su red. Lógico, si fuera sencillo hacerlo se podría entrar en un servidor con unas pocas instrucciones de php, html desde una placa de Arduino en el otro lado del mundo y causar varios problemas en la web. El sistema cloud no ha sido necesario puesto que la información que se necesita almacenar serán unos pocos miles de datos y con las capacidades básicas de un VPS estándar sobrará. Hasta 500.000mil en una sola base de datos sin problema. Se desestima un crecimiento a escala que precisara de dicho cloud. Se usará por tanto un VPS externo en el que se instalará una base de datos MySQL y se le dará permiso de lectura y ejecución de código php. Importante permitir en dicho servidor la ejecución de código desde dispositivos externos. 11 Por ello la virtual private server 44 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado selección de un VPS que permite mediante su plesk 12 o similares dichas configuraciones. Las lecturas de los datos de los sensores que vengan desde la placa de Arduino mediante el uso de la tarjeta Ethernet se guardan en modo local en una base de datos y también será una información clonada en internet. 12 Parallels Plesk Panel – Control de VPS - 45 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.6.7 SENSORES INSTALADOS. Este proyecto lleva por título “Supervisión remota de parámetros medioambientales capturados por UAV “. Se trata de un proyecto abierto y ampliable que dentro de la palabra “parámetros” puede abarcar todo aquello que pueda ser susceptible de ser medible y que sea necesario para la toma de alguna decisión según su resultado. Ya sea en una plataforma fija como móvil los parámetros a medir pueden ser muy variados. Para la elaboración de este proyecto y su documentación se han tomado muestras con sensores tan básicos como temperatura y luz. Así como algunos emuladores. Sonda NTC para medición de temperatura. Sensor LM35 para medición de temperatura redundante. Sensor LDR para la medición de la cantidad de Luz. Potenciómetro estándar. Para la simulación de Señales Analógicas en entrada. La medición de cada sensor necesita una adaptación física a la tarjeta Arduino. Un circuito mínimo que vendrá especificado por las necesidades del fabricante así como adaptación de dichos datos mediante software para su lectura e interpretación. Se ha intentado ser muy cuidadoso en la programación de dicho software de lectura y captura de datos, para que el proyecto pueda ser ampliado con otro tipo de sensores y que el trabajo extra que hubiera que añadir sea mínimo; fácilmente interpretable para programadores terceros que tuvieran que modificar dicho código. Funciones extras muy completas y configuradas previamente para poder ser usadas con facilidad. Comentarios línea por línea para que la lectura del código sea casi “novelada”. Pensando en terceros y también en el mismo creador del código para poder retocarlo, ampliarlo y mejorarlo en el futuro. Se tiene experiencia en este tipo de trabajos de creación de software común ya que previamente se ha trabajado en comunidades abiertas de creadores de código y el 46 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado especificar claramente que hace cada función, cómo, y que tipo de dato devuelve es transcental. 1.6.7.1 OTROS SENSORES Dadas las posibilidades de aplicación de tiene este proyecto la placa podrá ser cargada con el sensor que desee el usuario según el parámetro a medir. Deberán ser sensores compatibles con la placa Arduino y como se ha explicado necesitarán seguramente de un circuito mínimo de adaptación de señal. Pero dada la forma estructurada y envío de datos al ordenador central simplemente habrá que cambiar ciertas variables en el código a cargar en el programa. El sistema de comunicaciones se ha programado mediante interrupciones y buffers de control para que sea un estándar en la transmisión de datos por puerto serie. Podría ser interesante la lectura de Gases como metano CH4, monóxido de carbono C0 , dióxido de carbono, calidad del aire , humos, amoniaco NH3, humedad relativa Butano, LPG, Alcoholes, Etanoles, Gas Natural, Hidrógeno, Ozono, Benceno, Acetona, Formaldehídos, etc El sensor específico para todos estos parámetros se encuentra adjunto en el Anejo de este proyecto. También su código de Arduino por defecto para toda la serie, y su circuito de adaptación si fuera necesario. El código para su lectura se ha programado de forma estándar y podrá ser leído sin retocar apenas código. Dado el formato de programación el software en modo local se puede configurar para hacer mediciones continuas, en modo temporal y local, así como para generar avisos cuando los parámetros salgan de unos varemos establecidos que se pueden configurar. También se podrán graficar, posicionar en mapas y trabajar con ellos posteriormente para generación de históricos y cualquier formato que sea preciso; ya que los datos se quedarán guardados tanto en ficheros estandarizados como en bases de datos online. Con fecha, hora. Y si fuera pedido por el cliente con posicionamiento global de captación. 47 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Posteriormente, avanzado el proyecto se añadirá un lector GPS para el geoposicionamiento global de los datos recibidos en tiempo real en diferentes tipos de mapas, urbanos, físicos, topográficos. Etc. Esto será lo que en este proyecto se conoce como la Tercera aplicación o tercera fase del proyecto. 1.7 NUEVO PARADIGMA Durante esta primera parte del proyecto la información de los sensores ha sido enviada directamente mediante cable Ethernet. Los datos llegan al ordenador local, que hace como servidor mediante la ejecución de sentencias y código desde la placa Arduino. Código que ejecuta software, scripts propios en los ordenadores preparados para ello. Habrá casos en que usar este sistema sea suficiente, que la placa y los sensores estén en instalados en un sitio estático, inmóvil para la medición de los parámetros deseados. Si existiera conexión a internet los datos suben directamente a la web a la vez que se clonan en un ordenador local. Pero este proyecto nace con la novedad de que estos datos puedan ser capturados mediante un transporte móvil. Ya sea un vehículo terrestre, marítimo o aéreo. Las ventajas del uso de un vehículo aéreo no tripulado son increíbles ya que permitirán accesos a lugares remotos, de imposible acceso humano, y sin riesgo para la salud del operario del sistema sea la medición que se desee hacer de cualquier tipo o condición. El problema que surge mediante la captura de datos de un vehículo móvil, es que los datos ya no se pueden enviar mediante la ejecución directa de sentencias en la placa Arduino para un código instalado en los ordenadores. La información ahora debe ser de forma inalámbrica. Por lo tanto también el sistema de recogida será totalmente diferente al que se hacía por el cable Ethernet. Para compaginar ambos sistemas se ha trabajado con una estandarización de conservación y tratamiento de la información. Para que, sea como sea la recepción, las bases de datos sean compatibles. Y no solo las bases de datos, si no 48 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado los ficheros, y ya no solo compatibles entre ellos si no estandarizados a nivel global y de formato abierto. Los sistemas básicos de transmisión de datos de forma inalámbrica que se permite hacer con la placa Arduino son BlueTooth, Wifi. Algunos ya incorporados en placas específicas como Arduino YUN. Otros, previa instalación de “shields” extras totalmente compatible y configurables con cualquier Arduino. Pero estos módulos a nivel profesional no cumplen con unos requisitos y características básicas necesarias de consumo, estabilidad y distancia de recepción. Se necesitan para este proyecto módulos que superen los 100 metros de longitud con una estabilidad contrastada y de muy bajo consumo, sin importar en exceso la velocidad de transmisión. El Drone más pequeño de uso profesional con el que se trabaja en este proyecto tiene un alcance de 300 metros en campo abierto. Límite fácilmente ampliable pero no posible debido a las limitaciones legales. Para la transmisión de datos en este proyecto “Demo” se han usado los módulos 3DR, y los Xbee estándar. Los módulos XBee de MaxStream permiten enlaces seriales de señales TTL en distancias de 30 metros en interiores, 100 metros en exteriores con línea de vista y hasta 1.5 Km con los módulos Pro. Siendo su consumo menor que los otros sistemas como se muestra en el documento Especificaciones del Sistema. Los datos serán recogidos de Arduino y se emitirán al puerto serie COM del ordenador de trabajo 1.7.1 RECOGIDA DE DATOS EN PUERTO SERIE Como se mencionado en el punto anterior, una vez desconectado el cable de Ethernet, todo el sistema de recepción de datos se ha tenido que modificar. Desarrollo que ya sería un trabajo complejo y extenso por sí mismo, se amplía ahora en el proceso de recepción de datos por el puerto serie del ordenador. 49 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado A nivel profesional de software son varios los estándares que se tienen para recoger datos del puerto serie. Se muestran a continuación una serie de lenguajes de programación conocidos que disponen de librerías específicas para trabajar con el puerto serie. 1.PHP : PHP es un lenguaje de programación de uso general de código del lado del servidor originalmente diseñado para el desarrollo web de contenido dinámico. 2.C#: Un lenguaje de programación orientado a objetos desarrollado por Microsoft como parte de su plataforma .NET 3.Python: .Es un lenguaje interpretado, usa tipado13 dinámico y es multiplataforma. 4.JAVA: Es un lenguaje de programación de propósito general, concurrente, orientado a objetos y basado en clases que fue diseñado específicamente para tener tan pocas dependencias de implementación como fuera posible. 5.C++: Es un lenguaje de programación diseñado a mediados de los años 1980 basado en C. Para la selección de un lenguaje con la que enfrentarse a una nueva tarea que se desconocía por completo el programador debe preguntarse qué es lo que necesita hacer exactamente y en qué estado de progreso se encuentran tanto el IDE, o framework de desarrollo como las librerías que deberá usar. Necesidades futuras y expansión o el Scaffolding14 del proyecto. Visualizar el futuro no será fácil, y quizá haya que retroceder y volver a empezar si la decisión tomada no es la adecuada. Es importante anteponer estos puntos a las preferencias y políticas propias del programador. Será mucho más útil comenzar un nuevo aprendizaje de 13 14 Una misma variable puede tomar valores de distinto tipo en distintos momento Construcción de aplicaciones más potentes basadas en plantillas y datos previos. Andamiaje. 50 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado software si es que está preparado para tales funciones o desarrollos que mantenerse inamovible en un uno de ellos por preferencias, conocimientos y-o capacidades personales. De esta forma aunque se sea especialista en C++, es sabido que las facilidades para trabajar con bases de datos están más implementadas en php. Y por el contrario, si se necesitan aplicaciones standalone y compatibles en múltiples entornos de desarrollo, siempre será mejor usar Java, o Python. Por lo tanto, no se debe comenzar el estudio de la decisión a tomar con prejuicios sobre qué sistema usar. En este apartado, se comenzó con el desarrollo de esta recogida de datos en PHP. Muy parecido al formato que al trabajar con la ejecución de código desde Arduino. Sistemas GET, POST, librería específica, etc bases de datos de MySQL, accesos directos a éstas, etc. En unas pocas horas de desarrollo de código se vio que la decisión tomada no era correcta. Se iba a necesitar el uso de muchas librerías, y el código se complicaba según se avanzaba en el proyecto. Scaffolding tiende a infinito. Por otro lado, de esta forma la ejecución de programas resultantes iba a ser totalmente dependiente de trabajar online, o mediante servidores en modo local. Lo que por un lado, ya se tenía solucionado, pero cara al usuario final iba a convertirse en muy complejo. Aunque en ese momento se desconocía que se iba a necesitar por otro lado un sistema de gestión de interrupciones enrevesado. Vuelta a empezar y búsqueda de otra vía de desarrollo. En este punto, estaba el socorrido C++, del que se sabe que “lo hace todo”, sea por la cantidad de librerías a usar, como su sistema de trabajo a bajo nivel. Ya se había desarrollado en C++ código similar, y se conocía que se podría desarrollar lo que se necesitaba para el proyecto. Pero también era notable la complejidad del resultado final. En esta misma línea de trabajo estaba JAVA. Pero antes de tomar esta decisión, y consultando en foros de internet, y a profesionales y colegas del gremio, apareció la palabra Processing. Término que se recordaba en anterioridad por ser un lenguaje basado en wiring15 y el padre del IDE de Arduino. No obstante más conocido por su 15 Wiring es un entorn de tabajo de open source para microcontroladores.. 51 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado enfoque para la enseñanza y producción de proyectos multimedia e interactivos de diseño digital que para la integración con hardware. Como nota informativa cabe destacar que cuando uno arranca el entorno de desarrollo de Arduino, se puede leer abajo en letra pequeña “Based on Processing by Casey Reas and Ben Fry”. Esta pista debía haber sido suficiente para arrancar esta segunda parte del proyecto directamente en Processing, puesto que si el IDE de Arduino está basado en este sistema implicará que el rango de compatibilidades y de comunicaciones estará bastante desarrollado. No fue así en el primer intento, pero si en el siguiente. Como reza el proverbio popular “Rectificar es de sabios”, y aunque el autor de dicho proyecto y el que subscribe y firma este documento no se considera en posesión de dicha habilidad, no se tiene por necio. Comienza lo que será la parte más importante de este proyecto. La recogida de estos datos con Processing colocados en el puerto serie por los sistemas inalámbricos de las lecturas de la placa Arduino. En conocimiento de Processing se partía de cero, pero gracias a la documentación básica encontrada por internet, y a la amplia comunidad Open Source de este entorno, fue relativamente asequible comenzar su aprendizaje y dedicar algunos días de estudio en la familiarización de dicho lenguaje. Una mezcla entre JAVA y C++. El código de Processing al estar basado en Java, puede heredar todas sus funcionalidades, convirtiéndose en una herramienta poderosa a la hora de encarar proyectos complejos. Al igual que Arduino posee una serie de ejemplos funcionales que ayudan la labor del programador; pero como siempre en estos casos, cuando las necesidades crecen, todo se complica enormemente. Posteriormente se iba a necesitar una serie de funciones que se desconocía si desarrollarlo con Processing iba a ser engorroso o no. Algunas aplicaciones se pudieron realizar, como el tratamiento gráfico de datos en tiempo real, guardar dicha información en ficheros de texto, estructuras complejas como “json”, etc. Pero otras se complicaron enormemente y se desechó su utilización como: hacer un 52 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado live streaming de video dentro del entorno de desarrollo de dicho framework; o comunicación directa con bases de datos externas MySQL. Posteriormente se ha sabido que dichas funciones no están implementadas todavía en ninguna librería. Así como otras aplicaciones que se fueron descubriendo con el tiempo y que se había comenzado ya su implementación usando Java bajo Eclipse16. Al final se pudieron desarrollar bajo Processing. Es un ejemplo de este caso, el uso del posicionamiento de datos provenientes de un GPS instalado en Arduino. Se tienen los datos esperando en el puerto serie del ordenador, ya fuera mediante cableado USB o por sistema inalámbrico. Ya se puede hacer su tratamiento mediante el software Processing.. 16 Entorno de programación abierto que soporta multitud de formatos. 53 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.7.2 MODULOS INALAMBRICOS Antes de trabajar con módulos inalámbricos como es lógico habrá que probar todos los sistemas con un cable estándar. Cualquier USB servirá para la prueba. Trabajar con módulos inalámbricos tiene dependencia de muchos factores para su estabilidad. En especial, distancia al punto de recogida de datos, condiciones atmosféricas y elementos físicos que se interpondrán en dicha distancia. En campo abierto, alejado de ciudades y campos magnéticos bajo cielo azul raso, serán las condiciones perfectas. En entornos cerrados los problemas son relativos a interferencias magnéticas y a las distancias al punto de emisión. Amén de cargas de baterías, movimientos imprevisibles, etc. La estandarización en las comunicaciones los puertos COM nacidos del estándar RS-232, ha dado como resultado una comunicación trasparente entre periféricos externos y el ordenador central. Sea cual sea el sistema operativo usado. Linux, Mac, Windows. La transmisión serial transparente en modo AT (también existe el API) hace que si se consigue hacer funcionar para un sistema estandarizado su portabilidad es total a otro formato. Por lo tanto si se consigue lectura correcta por cable USB, será inmediatamente compatible con cualquier otro sistema seleccionado. En este proyecto se han usado dos dispositivos hardwares distintos para las comunicaciones inalámbricas. De la compañía DIGI, los módulos XBee. Y de 3DRobotics Inc, los módulos 3DR. Ambos sistemas han sido probados y su compatibilidad es total con la tarjeta de Arduino. 1.7.3 SISTEMA 3DR La condición de usar este sistema de comunicaciones en este proyecto ha venido definida por diferentes factores. El primero y más importante fue la disponibilidad. El acceso a estos módulos fue inmediato, y su sencillez y precio los hacían indispensables para hacer pruebas en un proyecto que debería ser real y de bajo coste como éste para que pueda ser implementado. 54 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Por otro lado, era importante conocer el resultado de estabilidad y características de estos módulos para tenerlos como opción de implementación para la versión más reducida de este trabajo. Se podría decir por tanto que la comunicación 3DR sería la opción barata, económica, de medición inalámbrica para este proyecto. Habrá que tener en cuenta por tanto cuando se instalen unos sistemas u otros las características necesarias o-y distancias para instalar unos módulos u terceros. El rendimiento de los lectores 3DR es ligeramente inferior a los Xbee. Por ello se relegarán para aplicaciones menores y-o como se ha comentado a versiones menores en la configuración del harware. Para poder hacer la afirmación de si unos módulos son más estables que otros, el alumno y autor de este documento y PFC ha realizado las pruebas de forma personal, con la ayuda de sus compañeros de Laboratorio recorriendo pasillos por edificios cerrados como callejuelas y parques en zonas abiertas. Y esta afirmación es totalmente personal e intransferible puesto que va en contra de lo que se puede leer en foros internacionales de usuarios de cuadricópteros y otros equipos de vuelo: “Para uso de módulos de datos inalámbricos para telemetría y comandos en vuelo APM 2 17 es compatible con dos tipos comunes de módulos inalámbricos de datos, la Radio 3DR (y compatibles) y Xbee. Recomendamos la Radio 3DR, que está optimizado para APM y dará un mayor alcance y rendimiento de pérdida de paquetes (además de que es la mitad del precio de Xbees), pero si usted ya tiene Xbees que trabajen bien, también” Disponer de diferentes módulos para la realización de este PFC ha sido muy útil, ya no sólo para conocer su funcionamiento si no, para poder tener en tiempo real funcionando dos aplicaciones diferentes y mostrar las bondades del trabajo realizado, así como resultados físicos y de futura implementación en la práctica profesional. 17 ArduPilotMega 2.0 - DIY Drones 55 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado La configuración de 3DR tanto a nivel de Hardware como en su lectura de datos será prácticamente similar a los módulos Xbee. Simplemente habrá que configurar los dispositivos en sus setups correspondiente con el hardware que sus propias compañías suministran, y en algunos casos, proyectos abiertos que la comunidad ha creado y cede. 1.7.4 SISTEMA XBEE - ZIGBEE ZigBee es un protocolo de comunicaciones inalámbricas basado en el estándar 802.15.4, está pensado para comunicaciones a baja velocidad entre dos o varios dispositivos, y se pueden formar redes con miles de dispositivos comunicándose entre sí, por lo que es ideal para muchas aplicaciones. ZigBee es desarrollado por la ZigBee Alliance, formada por cientos de compañías que quieren solventar la necesidad de un estándar para comunicaciones a baja velocidad, con un bajo coste de implementación y donde los dispositivos que forman parte de una red pueden requerir un bajo consumo, llegando a estar funcionando durante años con un par de pilas. Los módulos Xbee proveen 2 formas amigables de comunicación. La Transmisión serial transparente en modo AT (también modo API antes nombrado) que provee muchas ventajas. El tratamiento de los datos estará estandarizado. 56 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 7 Tecnologías inalámbricas La selección de esta tecnología se debe principalmente a las características mencionadas como: distancias, coste, consumos. También a su implementación en las placas Arduinos, en algunos casos bajo “shields” externas, y en los nuevos Arduinos incluso ya implementado dentro de la propia placa. Como se indica en el punto anterior los módulos Xbee serán los empleados Vs. los módulos 3DR cuando se requiera una mayor estabilidad del sistema. Se presentarán y ofertarán como la gama alta del producto terminado. 57 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.7.5 POSICIONAMIENTO GLOBAL GPS Como tercera aplicación y usando parte del código desarrollado en Processing en la sección anterior se ha desarrollado otro software standalone 18 para el posicionamiento global de los datos leídos por los sensores instalados en la placa Arduino. Será una ampliación no prevista en los objetivos iniciales del proyecto puesto que complicaba el proyecto enormemente. Y así ha sido. Pero dado el buen resultado del trabajo realizado en la recepción de datos por los sistemas inalámbricos comenzaron las pruebas con diferentes lectores de GPS Se presenta también la realización de este apartado bajo Eclipse. Entorno de desarrollo basado en java. Las librerías usadas tanto en Processing como en Elcipse para el posicionamiento global tienen fuentes similares y aunque el tratamiento de datos no es el mismo, para cualquier profesional de JAVA será muy sencillo adaptarlo. Por otro lado, se ha comprobado que la estabilidad y compatibilidad bajo Java y Eclipse es mayor que bajo Processing donde da problemas con el OpenGL en versiones que no estén muy actualizadas y configuradas de forma específica. Los datos leídos por los GPS se transmiten igualmente por el puerto serie estándar, como la lectura de los otros sensores, pero habrá diferencias en código y codificaciones para usar el protocolo NMEA19. Los datos recibidos en las variables del GPS usado en este proyecto serán bajo el formato Grados y minutos decimales – DMM- y el posterior tratamiento en Processing será en Grados decimales DDD. Se ve: Grados, minutos y segundos (DMS): ddd°mm'ss.ss" Grados y minutos decimales (DMM): ddd°mm.mmm' 18 Software que se ejecuta sin dependencias de otros programas. 19 Noatinal Marine Electronics Association 58 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Grados decimales (DDD): ddd.ddddd° Habrá que convertir dentro del software de Arduino estos datos para ser enviados por el puerto serie. Igualmente habrá que hacer otra descomposición de datos para enviar estos Floats en 4 bytes por el serial com. Para facilitar este trabajo y poder hacerlo las veces que sea necesario se creará una función para la conversión DMM DDD que se llamará cada vez que se captura un dato en el GPS. Resumen: 1. Recepción de datos de Satélite a Arduino. Protocolo NMEA 2. Conversión en Arduino DMM DDD a grados decimales. 3. Descomposición de datos floats. 59 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.7.6 EMISIÓN Y RECEPCIÓN DE DATOS No era un problema complicado “a priori”, pero sí que se ha enmarañado. La comunicación entre dos dispositivos tan distintos siempre tiene unas complejidades básicas; que se incrementan cuando las necesidades del proyecto van “in crescendo”. Y más aún cuando se usan distintos tipos de software, bajo distintos IDE´s de desarrollo y con un tratamiento de datos completamente diferente entre ellos. A veces, en los estándares básicos del software comercial existen librerías que facilitan este proceso. Pero al final, siempre habrá que tocar mucho código para que “emisión y recepción” de datos sea correcta en tiempo y forma. Sincronización, cheksums específicos y customizados etc. Como se ha explicado una vez cambiado el paradigma de enviar datos directos a Internet, a enviar los datos por el puerto serie mediante el cable, se cambió el concepto de trabajo. Tanto Arduino, como Processing, tienen funciones específicas para trabajar con el puerto serie. Pero en ambos casos son unas funciones muy básicas para dicha actividad. No permiten el control total del puerto serie, por ello se pensó volver en este punto a usar C++ o replantear el tratamiento de éstos. Al final, se desarrollaron funciones avanzadas de comunicaciones que funcionan en modo interrupción en ambos sentidos. Teniendo siempre en escucha a ambos puertos, tanto salida como entrada y ejecutándose solo cuando existe una información que tratar. Ya sea enviar, o recibir. Fue el problema más grave en este proyecto cuando se pasó de emitir datos de Arduino a Processing del cable USB a un sistema inalámbrico. Bajo un cable de conexión menor de 4 metros de distancia las comunicaciones no daban ningún tipo de problema. No había pérdida de información ni transmutación o intercambio de datos. Si se enviaba una serie de Bytes, en un orden establecido, eso era lo que se obtenía en el otro punto de comunicaciones. Y así debía seguir siendo, puesto que luego toda esa cadena de Bytes, descompuestos en sus respectivos BITS debían ser compuestas en su destino. Pero el problema principal surge al introducir 60 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado datos que se tienen que descomponer en más de un Byte y luego hacer su recomposición. Ya sean datos con signo, enteros, floats, etc. Las funciones que procedían a envíos ASCII están menos optimizadas que lo que se necesitaba para este proyecto. Hubo una serie de pruebas (bastantes) descartadas en el formato de envío de datos. Sirva como ejemplo de lo que funciona bajo cable en condiciones estables y no en formato inalámbrico en condiciones adversa: 1. Crear funciones de envío de datos cada “cierto” tiempo preconfigurado y compararlo en destino … porque si se produce una pérdida momentánea de información por un golpe de viento, una interferencia electromagnética, un objeto se interpone ..etc Los datos llegan intercambiados, el tiempo se pierde. 2. Generar marcas en las tramas y comprobar su salida y llegada…. porque si lo que no llega o lo que se transmuta es la trama, la marca indica que ha habido llegada de datos… 3. … y así una serie de pruebas más como contar datos de salida, esperar tiempo según distancias, comprobar datos anteriores para comparativas que no sean muy desviadas, especie de control estadístico, etc . Esto es similar a generar un checksum 20 propio de comunicaciones, chequeo que tiene como propósito principal detectar cambios accidentales en una secuencia de datos para proteger la integridad de estos. Estos checksums daban sus resultados. Indicaban que el sistema estaba trabajando incorrectamente, pero esto no soluciona el problema. Se podría despreciar los datos perdidos puesto que el dato próximo avalará al dato siguiente, pero el problema de intercalamiento de datos era inasumible. Se tenía debía diseñar un sistema de trabajo que en tiempo real uniera estos dos formatos tan diferente para el tratamiento de datos. 20 suma de verificación, también llamada suma de chequeo 61 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.7.7 EMISIÓN DESDE ARDUINO El software de Aduino parte con unos amplios ejemplos y unas librerías espléndidas con código preconfigurado y una comunidad muy amplia de desarrollo. Las funciones básicas no solucionaron el problema pero sí, a raíz de ellas se pudo generar un sistema de trabajo que al final ha resultado ser “inexpugnable” en su formato de transmisión de datos. El proceso consiste en generar un buffer FIFO de datos en formato BYTE. Tantos datos y tan grande de componentes como se quieran transmitir. Deberá ser un buffer enorme, puesto que por ejemplo un float se enviará como 4 BYTES dentro de ese Buffer. De esta forma cada dato recibido por el GPS una vez convertido DMM a DDD se descompondrá en bytes que se guardan en un orden determinado. Cada lectura de cada sensor también será convertido y guardado en este buffer de BYTES. De igual modo e usara otro byte para indicar signos del sistema, etc. Todo bajo una configuración personalizada y que hay que conocer. Quedará explicada en el documento de Especificaciones del sistema y se verá claramente en el código adjunto. Arduino como es sabido es un software que funciona como loops infinitos. Una vez configurada la setup, entra en un bucle de ejecución constante. Esta característica pude ser positiva para algunas aplicaciones, pero no para otras. Puesto que una vez que se ejecuta la setup, ya NO vuelve a ejecutarse si no es por alguna ejecución en concreto que se le envíe. Este bucle infinito es como el conocido en C++ “do { … } while (condición)” y conociendo esta característica que será similar en Processing, se pueden programar funciones para sacar al sistema de esa ejecución lineal–secuencial de código. Esto será de suma importancia porque es en esencia lo que se debe hacer para la captura de datos. Una vez que ese buffer se ha completado, se calcula su tamaño y se envía en una sola trama. De esta forma puede que se pierda un buffer completo de datos si el sistema inalámbrico entra en inestabilidad pero no habrá intercalamiento ni transmutación de información. 62 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Será imprescindible conocer e indicar al software de destino la velocidad de información de envío. Como se ha indicado en este proyecto 9600baudios. Y también será imprescindible indicar “manualmente” en la setup del software del destino el tamaño del buffer de salida. Aunque en Arduino, como se ha indicado esto no es necesario ya que el tamaño se calcula cuando se ejecuta la función de envío. Aunque por seguridad el Buffer se inicializa con unos parámetros y un tamaño determinado. Cambiando el tamaño con una serie de variables y una simple línea de código se podrían enviar tantos datos como requiera una futura aplicación. 1.8 PROCESSING – RECEPCIÓN DE DATOS Como se ha indicado, a pesar de que dichos entornos de desarrollo tienen sus propias funciones de comunicaciones usando librerías programadas Open Source por la comunidad, una vez que se necesitan ser usadas en un formato custom hay que generar y crear nuevas funciones a raíz de éstas para utilizarlas en el programa en cuestión y bajo las necesidades específicas. Mediante el cable USB la comunicación ha sido sencilla, los datos enviados se recibían perfectamente, pero al implementar los sistemas inalámbricos, ya fuera 3DR o Xbee ha habido que replantear la situación. Se quiere reflejar, y que quede patente, que en las setups de los softwares de comunicaciones inalámbricas (3DRadio, Xtcu) los datos recibidos no tienen nada que ver en orden y concierto con los resultados que luego llegan al puerto serie. En los programas de configuración que suelen disponer de sus propias consolas de observación, se obtiene una lectura y luego en el puerto serie del ordenador se obtiene otra; dependiendo de distancias, interferencias etc. Por lo tanto el crear un 63 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado protocolo estable, era absolutamente imprescindible para la consecución de este PFC. Se hace hincapié en este apartado, pero es que de no ser así, todo el proyecto a partir de este punto no tendría validez. Todos los datos llegarían desordenados, en diferentes momentos y no se podría hacer nada con ellos. Otrosí, una vez conseguido un protocolo de comunicaciones estable también abre nuevos horizontes para la creación de nuevas aplicaciones, dado la cantidad de hardware que se podría instalar en Arduino y las capacidades de procesales del framework usado en la recepción. En principio; en la redacción básica de los objetivos, no se pretendía hacer lecturas de un sistema GPS, pero visto que una vez que las transmisión del protocolo NMEA es correcta, el envío de datos, aunque complejo se ha podido llevar a cabo incrementando las posibilidades y las opciones de este PFC. Era por tanto un “cuello de botella”, una rotura de la cadena por el “eslabón más débil”. Y era prioritario solucionarlo cuanto antes. Una vez enviados los datos de un buffer completo desde Arduino a Processing habrá que recibirlo bajo los condicionantes de transmisión. Como se ha indicado en otras ocasiones: Comunicaciones a 9600 baudios. Puerto serie COM-X. Variable en cada compilación. Para cada Ordenador. Para cada Sistema Operativo. Para cada versión de Arduino ( Uno, Ethernet, etc) y también variable si se usa 3DR o XBee. ( se ha creado una función también para que el sistema busque automáticamente el puerto serie cada vez que se va a usar) – Suele ser del COM 4 al COM 9 por lo general. Tamaño del Buffer de envío. Tipo del Buffer. En este caso un FIFO. 64 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado La función en Processing funciona como una Interrupción clásica. Descartado una lectura constante de datos y posterior composición, o una trama con marcas de inicio y final, ni el mejor sistema de checksum posible, ni envío de strings, ASCII, etc hicieron viable una lectura inalámbrica. (Todos ellos muy viables en modo cable). Sólo trabajando con interrupciones del ciclo secuencial lineal del loop de Arduino hacen posible una transmisión correcta de un buffer FIFO de datos floats. 1.8.1 USO DEL PUERTO SERIE COM Hasta el momento se ha ejecutado todo el software en formato secuencial. Es decir, ejecutando línea a línea de principio a fin. Haciendo saltos a funciones cuando estas eran requeridas, y vuelta al mismo sitio con los resultados. Ya fueran funciones “void” o con devolución de datos. Pero cuando se requiere una programación más amplia se dependerá en ocasiones de eventos externos que ocurren fuera de nuestro código y que precisan de una atención especial debidamente programada. Esto es un evento, una interrupción, o un evento de interrupción. Existen muchos tipos de interrupciones como pueda ser un usuario pulsando una tecla, o haciendo click en el ratón. Y en este caso que se explica para el tema de lectura de datos en el puerto serie, el sistema está a la escucha de todos estos puertos configurados y cuando se produce una llamada, el software da prioridad a estos eventos. Son peticiones ineludibles que requieren ejecución inmediata. Las hay con más o menos prioridad, pero no es tema de explicación esta memoria. Usando librerías Open Source y programación propia se ha implementado la interrupción de lectura de datos desde el puerto serie. Al ser un proceso de interrupción, no se produce demora en el código, excepto el salto de dirección, y el resultado es el correcto, ya que el checksum usado en este formato es el propio de 65 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado un puerto serie estándar, y no habrá que esperar fines de tramas del buffer indicado ni tiempos de espera de datos dependientes del programa de envío. Podría funcionar tan rápido como el tiempo que lleguen los datos del sistema Arduino. 66 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.8.2 CONSOLAS DE CONTROL EN PROCESSING Dentro de IDE de Processing se programarán diferentes tipos de consolas gráficas de trabajo para el usuario. Unas con más aplicaciones que otras, que serán más avanzadas, e incluso Consolas específicas para cada entorno de trabajo. 1.8.3 CONSOLA BÁSICA Este software está destinado a ser usado en diferentes ordenadores y diferentes plataformas. Por ello se programarán diferentes formatos para compatibilizar y hacer funcional el sistema para el usuario final. La que se muestra a continuación en concreto fue creada para trabajar con los condicionantes mínimos de tarjetas gráficas, dispositivos móviles, etc. Podría cargarse como sustitutiva si no funcionaran algunas configuraciones, pero no se ha usado ni se carga por defecto. Ilustración 8 Consola mínima Su funcionamiento es muy sencillo y toda la configuración es tocando código. No tiene capacidad de cambiar datos en tiempo real. Los sensores recogen los sensores y según los datos preestablecidos se cambiarán las imágenes en tiempo real con los datos leídos y mostrados por pantalla. Con la interrupción del ratón, con el botón derecho se pueden ver otros parámetros 67 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 9 Datos Ayuda Digamos que es muy básica, y sin funcionalidad real. Pero siempre se podría recurrir a ella si el ordenador fuera antiguo, o no tuviera las capacidades necesarias implementadas para trabajar con las consolas siguientes. Para acostumbrados a trabajar en Windows, se podría decir, que es como cuando arranca el sistema operativo con las condiciones mínimas o en prueba de fallos para chequeos del sistema. 1.8.4 CONSOLA COMPLETA DE CONTROL PARA MUESTRESO REALTIME Esta consola completa, será el sistema de control de todo el sistema, y aquí todo será configurable para customizarlo y personalizarlo a gusto del usuario. 68 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 10 Consola principal de recepción de datos El usuario ajustará con estos parámetros los valores críticos tanto de temperatura como de luz, de lo que esté midiendo en cada momento. Las imágenes se podrán cambiar con facilidad para que la consola sirva para hacer diferentes muestreos. Los ajustes básicos serán 3 parámetros, de temperaturas de riesgo y una tercera de valor crítico de la cuál no se podrá pasar. Este valor puede activar lo que el contratista del proyecto desee. En este caso solo cambia la imagen y las muestras cambian de color, pero se puede integrar que haga una llamada, que envíe un email, un mensaje de texto o que se active un mensaje en la cuenta de twitter. Las APIS externas probadas bajo Processing funcionan correctamente, y una vez que estamos en la red, se puede hacer todo lo que es posible de hacer online y eso implica que se puede hacer de “todo”. 69 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Arriba a la izquierda se ajustan los parámetros críticos de las lecturas mediante los slides y el ratón. También mediante el teclado en algunos casos. Ilustración 11 Ejemplo de lectura y configración de dos datos. En el apartado central, los faders o knobs ajustan tamaños de rejillas de muestreo, la magnitud de los datos posicionados en pantalla, colores, fondos , etc. Ilustración 12 Potenciometros de setup. Ilustración 13 Parte central consola 70 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado En la parte central de la consola se ha instalado un scroll de texto con ayuda para configurar los parámetros. Indicando las teclas funcionales y su significado. Cargará el texto que se le indique para cada consola. En las rejillas inferiores se visualizan los parámetros deseados. En esta demo, “Temperatura”, y “luz” Como se ha indicado, el tamaño se puede configurar, y también las rejillas de visualización. Si se observa en la parte izquierda, se ve que el valor de temperatura ha tomado el valor rojo a mitad de la tabla. Esto indica que se ha superado un valor crítico y se deberán tomar medidas al respecto. Ilustración 14 Rejillas de muestro En la parte superior derecha se ha instalado un cuadro informativo que indica los parámetros básicos de control. Velocidad de transmisión, puerto serie funcional, etc. Ilustración 15 Cuadro informativo. 71 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Cabe reseñar que toda la consola se ha programado bajo código a mano. Todo se ha realizado con variables, por lo que se puede cambiar en tiempo real todos los parámetros de la misma. Desde las más insignificantes como el tamaño de las fotos, a eliminar por ejemplo la consola de datos, pausarla o ponerla a grabar datos en ficheros. Todo se reajusta automáticamente. Todo el sistema trabaja por funciones muy bien explicadas, comentadas y con tanta cantidad de condicionales “if” que hacen un sistema casi listo para poder presentarse a una versión Beta comercial en unas horas de configuración. *Datos simplemente curiosos para los aficionados a la programación. “Al final, algunos solo quieren ver un resultado por pantalla, que haga lo que se ha especificado que tiene que hacer, pero para otros programar bien es un arte” J.F.T. Ejemplo de una consola customizada en tiempo real. En este caso, el operario final ha cambiado tamaños de muestra de la recogida de datos, ha anulado la pantalla de configuraciones y ha expandido el scroll del cuadro de texto informativo para conocer que más podría hacer en la pantalla. Se trata de una pantalla informativa y de ayuda. 72 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 16 Consola personalizada. 1.8.5 CONSOLA COMPLETA DE CONTROL PARA POSICIONAMIENTO GPS Se creará una nueva consola para el tratamiento de los datos del GPS y su geoposicionamiento. En esta el sistema cargará mapas en tiempo real ( necesaria conexión a internet) y en el punto concreto colocará la medida del sensor instalado en la placa Arduino. Esta consola es mucho más restrictiva que la anterior. Hará uso de unas librerías muy potentes que requieren tarjetas gráficas especiales con capacidad de funcionamiento en modo GPU21 especial y con librerías OpenGL22 de versiones superiores. Asimismo como se explica detalladamente en el documento de “Especificaciones del Sistema” de este proyecto, aun con estas características no se 21 Unidad de procesamiento gráfico 22 Open Graphics Library 73 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado garantiza su funcionamiento. Dependerá de una configuración muy profesional por un experto informático. Cuando las librerías y todo el hardware esté instalado, esta aplicación desarrollada también en Processing y duplicada bajo Eclipse en parte, podrá posicionar en tiempo real en diferentes mapas topográficos, físicos, vectoriales, urbanos etc los datos de lectura de la placa Arduino con su correspondiente GPS instalado. La navegación entre los diferentes mapas se ha programado con interrupciones de teclado y uso del ratón. Por lo tanto queda una navegación minimalista, limpia, clara ya que no hay botones que entorpezcan la observación. Con este tipo de apps se permite crear de forma rápida mapas interactivos en aplicaciones táctiles como dispositivos móviles o expositores. Se podrán realizar desde interacciones básicas en nuestro mapa, como pueden ser el zoom o panorámicas, a otras más complejas como gestos multitáctiles si en vez de exportar bajo ejecutable de Windows se hiciera una exportación para Android que por defecto permite Processing (si se ha instalado previamente la SDK 23). Esta librería facilita la conexión con varios proveedores de mapas como OpenStreetMaps, Bing o aquellos generados con TileMill, creando una visualización mediante tiles. A este mapa de teselas24 se le pueden añadir cualquier tipo de elementos gráficos definidos por el usuario y geoposicionarlos. En este caso se trabajará con OpenSTT para mapeos urbanos y se hará una prueba con el proveedor de Microsoft para usar mapas topográficos y físicos. 23 kit de desarrollo de software 24 La tesela es una pequeña pieza de piedra coloreada que se utiliza para confeccionar un mosaico. 74 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 17 Mapa en real time - Geovisualización Urbano En este primer mapa que es el que carga por defecto la consola, se puede llegar a un nivel de zoom en el que la interactividad con edificios ya es bastante válida. Tras las primeras capturas de los datos por el puerto serie provenientes de Arduino el sistema comienza a posicionar los datos. Se ve ya un punto de temperatura posicionado en la zona de la Universidad de La Rioja, que lógicamente era dónde se estaba en ese momento. Estas capturas también se guardarán en unos gigantescos buffers y se clonarán a ficheros de texto plano y si fuera necesario a ficheros estructurados para posterior tratamiento. Por ejemplo, bajo “json25” se distribuyen los datos 25 JavaScript Object Notation, es un formato ligero para el intercambio de datos. 75 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado geolocalizados de todos los sensores de terremotos que funcionan en la actualidad a nivel global en los océanos y mares de nuestro planeta. Se creará dentro de esta aplicación otro tipo de mapeo interactivo para poder posicionar además del punto geolocalizado el dato de muestra leído por Arduino. Temperatura, luz, etc. Depende del sensor que se utilice en este momento. Asimismo para facilitar la navegación, en esta segunda pantalla se dispone de un segundo mapa en forma de zoom como se ve en la figura abajo a la derecha. Ilustración 18 Posicionamiento más lectura de datos. Urbano + dato Como se explica a continuación habrá opciones en la consola para cambiar a otro tipo de visualizaciones. 76 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Este segundo modelo de navegación por satélite en tiempo real necesitará además de las librerías anteriormente instaladas la incorporación de las API de otro proveedor de mapas. Esa carga la hace el sistema internamente pero se programará bajo líneas de código. En este caso, bajo teclado se ha programado un cambio de proveedor de mapas a una librería abierta de Microsoft, la usada en el buscador y directorio Bing. Se comprueba con el cambio de mapas que el posicionamiento y sincronización entre ambos mapas es casi exacto. Trabajar con 4 decimales desde la conversión que se hace en Arduino da una resolución muy buena, se usen unos mapas u otros. Se recuerda que existe la posibilidad de cargar otro tipo de proveedores de mapas, carreteras, urbanos para ciudades, lumínicos, etc. Pero su implantación es bastante compleja. Más aún si queremos posicionar puntos exactos en ellos. Sin posicionamiento el cargar o importar otro tipo de proveedores no es tan complejo. 77 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 19 Desde otro proveedor de mapas. Físicos y Topográficos. 78 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 20 Proveedor Microsoft. Mapa Físico urbano. Se ve una captura de datos por los sensores y geoposicionados. 79 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.8.6 ALTERNATIVAS A ARDUINO-PROCESSING (JAVA,PHP) El trabajo principal de este PFC consiste en la instalación de sensores en Arduino. Su programación bajo su IDE y transmitirlos a otro software distinto. Processing. Pero lógicamente existían otras alternativas, que como se verán se han descartado por diferentes motivos. Algunos casos ya se han explicado en capítulos anteriores, pero no se había hablado de un paquete comercial existente en el mercado que facilitaría mucho este trabajo realizado. Una de las alternativas a este cometido , hubiera sido desarrollar todo mediante “Matlab + Simulink + APM2 Simulink Blockset”. Es decir, trabajando usando todo bajo librerías en Matlab. Tanto para emisión como recepción de datos. Pero este formato de trabajo estaría muy restringido: desde el uso de Ardupilot2 como Arduino compatible a todo el sistema de tratamiento y recepción de la información. Hubiera sido un sistema muy cerrado y la dependencia del sistema sería completa. La mayoría de las condiciones del cliente serían imposibles implementar, y todo el uso estaría limitado a las actualizaciones propias de la marca. El scaffolding del proyecto por otro lado sería limitado puesto que se depende por completo de terceros. Las ventajas hubieran sido en cuanto a fiabilidad del software y al uso de sus entornos de desarrollo y gráficos. No hubiera habido que crear ninguno de ellos. Para algunos apartados hubiera sido más sencillo este formato, pero “siguiendo el camino que ya han usado otros, se llega al mismo sitio”, y en este proyecto se quería crear un proyecto novedoso y único (dentro de lo que internet se entiende como original). Por otro lado, solo la licencia de uso de Matlab 26 ya tiene un coste mayor que todo este proyecto completo. Uniendo “software + hardware + instalación + desarrollo + licencias”. Asimismo no se podría liberar bajo open source completo los resultados puesto que se parten de sistemas propietarios. 26 https://www.mathworks.es/store/link/products/standard/new?s_iid=htb_buy_gtwy_cta1 80 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado En una actualización a 12 Julio 2014, hay que considerar que no todo se podría haber realizado en Matlab. Las librerías usadas y los proveedores de mapas no tienen las APIS implementadas en su totalidad para este software profesional 81 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.9 PANEL DE ADMIN WEB Estos puntos que siguen a continuación serán los apartados que menos tengan que ver con un proyecto de Ingeniería Industrial y que se acercan más a Ingenieros Informáticos. Pero en este siglo XXI , si no estás en la red, no existes. Todo lo hagas tiene que tener su versión online, su “alter ego” informativo y funcional en el mundo virtual. Casi cualquier proyecto que se lleve a cabo hoy en día y que vaya a tener un tratamiento de datos, una serie cruzada de información, que vaya a usar históricos, flujo de datos, etc necesitará de usar bases de datos, y si estas son online la ventajas incrementan y amplían los horizontes del proyecto y generan nuevas metas para otros valientes. Es por la labor desempeñada por el autor de este PFC durante la última década. Aunque ingeniero de titulación, informático de profesión. Al comienzo de este proyecto 6 meses atrás, se pensó que el panel de administración web podría trabajar en tiempo real mostrando datos de lectura de los sensores y exponerlos gráficamente. Durante el desarrollo de las aplicaciones se han visto los problemas que esto puede generar y de la dificultad de implantarlo. Para un tratamiento en modo real online habría que haber elegido un placa Arduino con tarjeta GSM/GPRS contratada con telefonía de datos. Sólo esta opción hubiera dado la posibilidad de visualizar online, en internet, la captura de las lecturas de los sensores y su mantenimiento en diversas bases de datos. Por otro lado, este sistema hubiera sido más fácil de implantar y de coste similar. La tarjeta shield de GSM27 para Arduino apenas cuesta 90 euros, y una tarifa de datos, en el año en curso ronda los 15 euros. La solución aportada en este proyecto en la que los datos pasan por los módulos inalámbricos Xbee, etc está en un coste similar. Pero principalmente no era la preferencia el trabajar en modo online para el tratamiento de datos, puesto que lo primordial era que se pudieran tomar medidas y 27 http://arduino.cc/en/Main/ArduinoGSMShield 82 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado decisiones según se producía una lectura o aviso en tiempo real en modo “insitu”. Es decir, el operario con el ordenador local, recibiendo datos, mientras sobrevuela cierta zona, poder actuar inmediatamente sin tener dependencias de conexiones a internet o problemas similares. Ser autónomo e independiente en ese momento. Ser responsable único de una decisión a tomar. Posteriormente se valorará si esa decisión fue correcta o no, cuando se analicen esos datos guardados en ficheros y en bases de datos online. Se usará más el tema online como histórico de datos, consulta, etc. También para poder compartirlo en formato Open Data estandarizados con otros usuarios del sistema que necesiten de esos datos para su investigación o trabajos. De las tres aplicaciones que se han desarrollado en este proyecto se ven cuáles son las que pueden llegar a trabajar en Real Time en la web, en formato online…. porque en modo consola en el ordenador local TODAS funcionan en tiempo real. Enviar datos en tiempo real a la red solo pude ser posible en la condición de funcionamiento en la que el Arduino esté conectado directamente a un Router. 1.9.1 CAMARA WIFI MONTADA EN DRONE ¿Por qué usar una cámara en un UAD? La respuesta aunque sencilla y obvia es clara: Para saber dónde se encuentra nuestro vehículo en cada momento. Es trivial, pero cuando se ha trabajado con Drones se sabe que esto no es siempre tan sencillo. El Drone es un equipo pequeño y simétrico de apenas 50 cm de envergadura – fuselaje. Aunque suele llevar luces y diferentes marcas para conocer su posición, esto es solo factible reconocerlo cuando se encentra a menos de 40- 50 metros del punto de control donde se encuentra el operario de vuelo. Las marcas se pierden en la distancia y tanto el sol como las diferentes montañas y sus 83 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado perspectivas equivocarán la visión que se piense que lleva la trayectoria de movimiento. Los multirotores, para facilitar su maniobrabilidad se pueden mover horizontalmente en las cuatro direcciones. Y también pueden girar sobre sí mismos. Por lo que adelante, atrás, derecha, izquierda en los mandos de control del transmisor tienen poco sentido. Por lo general, cuando se sale a volar estos equipos, si se van a llevar a largas distancias, 100, 200, 300 metros en campo abierto lo cual de por si es ya una temeridad por el riesgo de pérdida que conlleva, el uso de prismáticos o dispositivos de visualización y búsqueda son indispensables. El uso de “gemelos” permitirá seguir la trayectoria del Drone, pero dependiendo de distancias o zonas complejas de vuelo, este medio no siempre será el más acertado. La instalación de una pequeña cámara en el UAD nos dará la posición exacta para saber “hacía donde está mirando”. Habrá que tener mucha paciencia y pericia para controlar un Drone a largas distancias y ser muy meticuloso con los mandos. Giros suaves bajo un control exhaustivo. Realmente se convierte en un proceso muy arriesgado. Dependiendo de las velocidad de transmisión de estas cámaras y de su tasa de envío las habrá que incluso permitan al usuario hacer un FPV: First Person View de la navegación y sentirse realmente navegando dentro del Drone. Pero conseguir un tiempo real de navegación no es fácil ni barato. Actualmente ya existen versiones en el mercado Drones con cámara de video incorporada. Las gamas bajas de multirotores emiten su señal de video y de control vía Bluetooth. Algunos modelos también wifi. Uno de los problemas de esta emisión de video aparte de su baja calidad es que no se tiene acceso al video emitido. El mismo problema que todos los sistemas cerrados explicados en el párrafo anterior. Otros modelos ya más potentes viendo las oportunidades de negocio de la grabación aérea de video y fotografía están incorporando a sus equipos cámaras de video de alta resolución en formato wifi a sus propias aplicaciones para dispositivos 84 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado móviles. Y cuando se habla de productos recientes, cabe indicar que el primer Drone comercial de gama media alta, lanzado al mercado con estas funciones ha sido a mediados-finales del año 2013 por la compañía DJI : el Phantom 2 Vision. Ilustración 21 Phanton 2 Vision. 2013 Este producto ya permitiría opciones de video más avanzadas y un tratamiento básico de la imagen así como manipulaciones. Pero el problema viene a ser similar si se usa este tipo de equipos. Se estaría trabajando con entornos cerrados y siempre dependientes de actualizaciones propietarias del fabricante. Así como usar siempre su gama de servicios y extras, incluyendo los dispositivos finales a los que va encaminado. Había que analizar el mercado y conocer otros equipos de transmisión de imagen. Con la preferencia de que el acceso control a ese flujo de video pudiera ser capturado desde el dispositivo que se quisiera. Ya fuera un ordenador, un teléfono o tableta, o enviarlo directamente a internet si se precisara. Pero que no fuera ni restrictivo ni un sistema cerrado. Que se permitiera trabajar con esa información y tomar decisiones propias y personalizadas para cada cliente y sus futuras configuraciones. Para ello habrá que recurrir a salir de los equipos suministrados por las propias marcas de fabricantes de Drones y buscar soluciones personalizadas. 85 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado El mercado actual de cámaras ligeras de video se ha transformado desde la producción en masa de la tecnología CCD 28 que aunque datan de los años 70, no fue hasta 2009 cuando se le concedió el premio nobel de física a los inventores del laboratorio Bell. Las cámaras actuales de HD permiten ser subidas a multirotores pequeños cosa que hace 10 años solo se podía hacer en helicópteros profesionales. Existen cámaras en el mercado que apenas pesan unos gramos y de valores accesibles al gran público. Pero aparte de estas características de peso y precio, para este proyecto se necesitaba una cámara que fuera capaz de transmitir ese video de forma inalámbrica a una velocidad relativamente potente que permitiera una visualización “casi” en tiempo real. Se va dar por bueno un desfase de “5 segundos” como tiempo real. Las opciones más importantes. Cámara IP. Desde 1.2Ghz a 2.4Ghz Cámara wifi estándar. Emisión en 2.4Ghz. Cámara en Alta frecuencia. Emisión inalámbrica en la banda de 5.8GHz. Cualquiera de estas soluciones adoptadas podrían ser válidas. Todas aportan según sus especificaciones un valor extra al proyecto. En España la emisión entre 900 Mhz y 1.3 Ghz está prohibida ( radiobaliza )… pero … se puede emitir legalmente en 1.2 Ghz, 2.4 Ghz, 5,8 Ghz, 10 Ghz y 24 Ghz, no obstante se necesita una licencia de radioaficionado y una autorización especial individual para transmitir en las mismas (menos en 24 Ghz que no es necesario). 28 Charge coupled device en español «dispositivo de carga acoplada 86 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado En 2.4 Ghz hay un segmento "libre", para uso industrial, científico y médico (ISM) que permite una Potencia radiada isotrópica29 efectiva de 10 dBm (10 mW) Mediante la cámara IP se podría emitir directamente la señal wifi al Router y de ahí salir directamente a internet, ya sea a una aplicación propia, usar APIS de servicios como youtube y otros. También se podría tratar el video en modo local. La elección final de una cámara para la versión Demo de este proyecto se ve prefijada por la disponibilidad de una cámara wifi estándar, que aunque bien satisface algunas condiciones como peso (80 gramos), precio, podría presentar problemas de interferencias con los módulos inalámbricos instalados (habrá que revisar los canales de emisión dentro de esa frecuencia), porque transmitan de forma codificada estarán en la misma banda de frecuencia. Se usará una GoPro Hero3 que viene diseñada para trabajar con cuadricópteros y con una visión de gran angular a 170º que permitirá una visión amplia de las zonas a analizar. La frecuencia del Wi-Fi integrado de las cámaras HERO3+ Black Edition y Silver Edition es de 2,4 GHz, b/g. Se aconseja no obstante que para proyectos mayores que requieran características más complejas se usen dispositivos inalámbricos que trabajen en el rango de 5.8Ghz a 1000mw. Estas cámaras permiten seleccionar entre diferentes canales (sobre 7) de frecuencia una vez hacen un barrido de investigación en la zona. La cámara seleccionada en este caso emite video en formato wifi abierto no codificado y permite su uso mediante software externo. Asimismo la cámara se ha hecho popular en el mercado deportivo de cámaras subjetivas de acción y son funcionales las aplicaciones para dispositivos móviles para tratar el video. Existen además aplicaciones propias de la marca para los principales modelos de telefonía móvil, aunque en este trabajo no se usarán dichas aplicaciones si no que se 29 Potencia Isotrópica Radiada Equivalente (PIRE) 87 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado desarrollarán y aplicarán códigos propios en html5 para integrarlos en el panel de control de la web, ya sea en modo local, como a través de internet. 1.9.2 LIVE STREAMING El término streaming se aplica habitualmente a la difusión de audio o vídeo. Requiere una conexión por lo menos de igual ancho de banda que la tasa de transmisión del servicio. El streaming de vídeo se popularizó a fines de la década de 2000, cuando el ancho de banda se hizo lo suficientemente barato para gran parte de la población. Live streaming será por tanto la emisión de ese audio-video en tiempo real a dispositivo cercano que hará de servidor y captura de datos. Dados los algoritmos actuales de conversión y también el hardware aplicado de corrección de movimiento no hará falta trabajar con video completo si no que se podrá usar la conversión más estándar que es actualmente el mp4. De esta forma seleccionando diferentes parámetros de conversión se podrá buscar la calidad óptima de recepción, visualización, tiempo, buffer, etc. A veces será necesario tener capturas de video o imagen estática de calidad, y en otras ocasiones bastará con calidades bajas de video que proporcionen un flujo más rápido y fluido de datos. La emisión de video en tiempo real se usará particularmente para el posicionamiento del multirotor cuando éste se encuentre en largas distancias. Saber hacia dónde está mirando y poder traerlo de vuelta. Para este cometido se puede configurar el flujo de video en baja calidad. Pero también se le puede dar otro cometido al video streaming. En ocasiones quizá tenga que salir en un vuelo de investigación en una zona que presente visibilidad baja desde el suelo, y solo en altura se pueda tener una imagen clara de la perspectiva a analizar. Por ejemplo tras un incendio en una nave industrial que se quisiera medir la concentración de humos y ver cómo han quedado zonas de acceso para una posterior incursión de bomberos con material pesado. En este caso, tener unas imágenes de calidad será importante, y no lo será tanto el tiempo que cueste su llegada al servidor local. 5 – 10 segundos es un tiempo aceptable para este cometido. Este video puede ser tratado “insitu”, no se ha programado para este PFC 88 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado pero perfectamente se pueden aplicar plugins y librerías para incrementar luz, color, etc. Ahora mismo, estos parámetros se pueden ajustar desde el control wifi propio de la cámara usada. Pero para otro tipo de cámaras de gamas más bajas, posiblemente no dispongan de estas características. Como se ha indicado en este caso la calidad de la cámara es de uso profesional. Soporta grabación hasta 4k. Pero como uso recomendable se plante el HD estándar. 1.9.3 ANGULARES DE GRABACIÓN Se tendrá la posibilidad de grabar en diferentes módulos y ángulos, pudiendo usar un gran angular de 170 grados para ver más amplio el campo de visión, pero teniendo en cuenta que esta visión es una deformación. El parámetro más indicado de grabación será a 127 grados. Ilustración 22 Modos de grabación WIDE 170 grados - MEDIUM 127 grados - NARROW. 90 grados 1.9.4 EFECTO FLAN – GELATINA O ROLLING SHUTTER Cuando se hacen las primeras tomas de grabación de video en altura, llegan unos problemas inesperados ya que los equipos todavía no están preparados específicamente para ello. Uno de los efectos más problemáticos es el conocido como efecto “Gelatina”. La imagen capturada se ve como “temblorosa” como un flan cuando se mueve el plato que lo sustenta. En el Documento Especificaciones técnicas del sistema se explica cómo mejorar esta problema. *No es propio de este PFC la captura de video. 1.9.5 RECEPCIÓN DE VIDEO LIVE STREAMING Sea cual sea el formato de recepción y el material usado: IP, wifi o en la frecuencia 5.8Ghz habrá que integrar la recepción de video en un sistema amigable para el usuario. Par ello la preferencia, será integrar en la aplicación una pantalla para la visualización FPV de las maniobras del cuatricóptero. 89 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Se ha intentado crear el live streaming de video en la aplicación desarrollada en Processing, pero ha sido imposible. Existen librerías de video basadas en JAVA y que se integran en el framework y también APIs externas. Pero aunque también tienen aplicaciones para abrir un buffer de datos y trabajar y editar video, no ha sido posible hacerlo con video streamming en wifi. Se ha consultado directamente a desarrolladores de Processing y de estas librerías de video y no se han obtenido soluciones funcionales. Por lo tanto había que buscar una alternativa para la recepción del video de la cámara del cuadricóptero. Se ha creado una aplicación personal para la recepción e integración del video en la web. Ya que come se ha comentado, no se ha podido hacer en la consola de Processing. Se hicieron pruebas trabajando en formato canvas 30, pero se complicaba mucho el desarrollo. Al final se ha usado código html5 embebido en web. Este código se puede cargar desde el panel de administración de la aplicación online y usarlo dentro de una plantilla y también se puede usar en ventana externa. Si se tuvieran dos ordenadores, esta solución sería la más clara, para poder tener en uno de ellos, la consola de recepción de datos y en otro el streaming de video para la navegación en FPV. La decisión final de hacerlo también en html5 ha sido para que el resultado sea compatible en cualquier plataforma móvil. Se han hecho pruebas incluso para integrar esta aplicación web en una APK31 exportable y los resultados han sido positivos, pero como resultado exportable solo sería posible comprobarlo bajo dispositivos Android. Como reserva, por si hubiera problemas en la recepción de video se usarán y configurarán otros sistemas 30 Se usará un software externo para la configuración de la cámara. Canvas, lienzo. Elemento HTML5 que permite generación de gráficos dinámicamente por scripting 31 Application PacKage 90 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Se instalará una aplicación modificada web OS de Github 32 para tal cometido. Se tendrá preparada la aplicación propia y comercial de la cámara bajo Windows phone. Se configurará el programa VLC para la recepción del buffer de red abierto. Este último punto es al que se le ha dado más preferencia para usar por si fallan otros sistemas. El autor ha comprobado esta configuración bajo Linux y bajo Windows, e incluso ya escribió un post33 para la comunidad Unix en Septiembre 2013. Pero como se comenta estos procedimientos son usando software externo. Para la realización de este PFC se intentará reprogramar esta recepción de streaming con código propio. 32 Alojar proyectos utilizando el sistema de control de versiones Git. 33 http://eduardogarbayo.com/streaming-con-gopro-hero3-via-wifi-en-linux-ubuntu/ 91 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.10 CAPACIDAD DE TRABAJAR EN TIEMPO REAL A continuación un resumen de en qué condiciones se podrá trabajar en tiempo real online. Es decir, ver en internet en cualquier parte del mundo la captura de la placa Arduino. 1.10.1 EN MODO CONSOLA LOCAL. 1.- Arduino conectado por cable de red PoE o no, a un Router y enviando datos a internet y a un server local. SI REAL TIME 2.- Arduino emitiendo datos vía inalámbrico 3DR a la consola, al server local, y al server de internet. SI REAL TIME 3.- Arduino emitiendo datos y posicionando datos en del GPS en mapa vía inalámbrico Xbee a la consola, al server local, y al server de internet. SI REAL TIME 1.10.2 EN MODO ONLINE. 1.- Arduino conectado por cable de red PoE o no, a un Router y enviando datos a internet y a un server local. SI REAL TIME 2.- Arduino emitiendo datos vía inalámbrico 3DR a la consola, al server local, y al server de internet. NO REAL TIME 3.- Arduino emitiendo datos y posicionando datos en del GPS en mapa vía inalámbrico Xbee a la consola, al server local, y al server de internet. NO REAL TIME 92 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado El panel de administración web estará clonado en modo local, en un ordenador PC personal, donde el usuario tendrá instalado las aplicaciones básicas para sus funcionalidades necesarias. No importa si se trata de un sistema LAMP o WAMP. Es decir, usar Linux o Windows. Tanto Apache, php, mysql y su correspondiente PhPmyAdmin funcionan correctamente en ambos sistemas cuando se trata de aplicaciones menores. Esta aplicación localhost estará clonada en un servidor remoto de internet. En este caso, se ha contratado un VPS en Canadá para tales cometidos. No existe ninguna preferencia al server local usado, ni al server remoto. La preferencia para usar el server remoto en este caso es una mera cuestión económica. Aparte de que se lleva trabajando con esta empresa más de un lustro y aunque no sea la más estable del mercado de hosting, si es una de las más valoradas en cuanto a servicio técnico profesional. Por otro lado, la justificación de tener la información clonada en un server remoto es para poder acceder vía online sin ningún tipo de problemas. Conociendo la dirección web o IP se podrá acceder desde cualquier dispositivo móvil pues la web es 99% RPW 34. Responsive web Design que significa que se ha programado pensando en usuarios finales de todo tipo y haciendo su compatibilidad casi total. Aparecerán incompatibilidades para teléfonos basados en dispositivos Symbian, algún problema también en los gráficos en tiempo real en las Blackberry y en Androids con versiones menores a la 2.4. Ya que a veces los gráficos mostrados usará el formato SVG. Aparte de un jquery, html5, canvas… etc. 34 Responsive Web Design. Compatible con todos los sistemas de visualización. 93 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 23 Panel de admin web RWD Acceso al panel de admin online desde un dispositivo móvil: Ilustración 24 Admin web acceso móvil Haciendo una foto en el Bidi el sistema lleva al usuario al panel de administración online con su dispositivo celular. 94 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.11 FLUJO DE DATOS Y OPEN DATA Un flujo de datos es un buffer de información que va de un origen a un destino pasando por cualesquiera que sean los lugares intermedios, en infinitos contextos en un formato que pueda ser interpretado en todos sus puntos de acceso y su usuario final. Al hablar de flujo de datos no se habla de Diagramas de flujo si no de las primigenias líneas que usen esos diagramas. Los datos en sí mismos y su viaje. El apartado “medio” por donde fluyen ya ha sido explicado en puntos anteriores. En este caso sea hablado de sistemas bajo cable usb, inalámbricos. Y el nivel de software no importa si se trata de buffers de enteros, floats, o strings. No afecta lo que existe en entre origen y destino, en medio del “medio”. Solo importa el resultado final. La transmisión definitiva, en base, no importaría si se tratara de analógica o digital. Tipo de Datos Flujo de Datos F l u j o d e d a t o Diagrama: Flujo de Datos, Tipo sde datos. Por un lado están los datos en sí mismos, luego está el medio por donde fluyen, y su formato de transporte. 95 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado No se hará más hincapié en este apartado de lo ya explicado en capítulos pasados de cómo se han implementado las funciones e interrupciones del sistema que hace el sistema funcional. Interesará más en este punto del proyecto saber cómo trabajar con esos datos que el sistema ha ido enviando de un lugar a otro. Como guardarlos para que sean interpretados por softwares y aplicaciones tan dispares como sea posible. 1.11.1 OPEN DATA El concepto datos abiertos (open data, en inglés) es una filosofía y práctica que persigue que determinados tipos de información datos estén disponibles de forma libre para todo el mundo, sin restricciones de derechos de autor, de patentes o de otros mecanismos de control. Tiene una ética similar a otros movimientos y comunidades abiertos, como el software libre, el código abierto y el open access. Si se habla de licencias para este tipo de información se ve que la línea temporal está muy cerquita : el Archivo Nacional del Reino Unido liberó una licencia gubernamental en el año 2010. Esto no quiere decir que antes no se usaran estos formatos, si no que el rápido crecimiento de la red, hace que continuamente aparezcan nuevas licencias para subsanar, corregir y ampliar vacíos que antes existían o que simplemente no estaban estandarizados. Una estrella - Disponible en Internet (cualquier formato. Por ejemplo: PDF), Dos estrellas - Disponible en Internet de manera estructurada (XLS). Tres estrellas - Estructurados y en formato no propietario (CVS en vez del Excel). Cuatro estrellas - Siguiendo todas las reglas anteriores, pero dentro de los estándares establecidos por el W3C (RDF e SPARQL): 96 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Cinco estrellas - Todas las reglas ya mencionadas, y además: vincular sus datos a los de otras personas, de manera a proveer un contexto. Y dentro de los cuatro y cinco estrellas los formatos o más utilizados en los últimos años han sido el csv, xml, y el formato que está imponiéndose últimamente: “json”. Y al decir últimamente hablamos de 2 años atrás. Tampoco se sabe la evolución que tendrá la red, pero sí está claro que el crear datos abiertos, estructurados, y bajo cierta normativa es absolutamente imprescindible para poder trabajar con otros usuarios que reutilicen, usen, amplíen, etc. Y preferiblemente bajo licencias y códigos relacionados con el Open Source. En este proyecto se trabajará principalmente con dos tipos de datos. Se usarán ficheros de texto plano abiertos no estructurados para servir como copias de seguridad, y ficheros “json”. Aunque también se tendrá opción de trabajar con exportaciones de datos desde phpMyadmin de bases mySQL que permiten todo tipo de exportaciones, sql, xml, csv, etc. Y todo esto viene a ser corroborado en este proyecto; como el uso de datos abiertos, estandarizados hace que la captura de un sistema totalmente independiente (Arduino), envíe datos a otros elementos y aplicaciones(Processing), para ser posteriormente compartidos en un mundo online(vía website), para volver a ser interpretados por otros sistemas totalmente independientes y volver a ser mostrados a usuarios finales(en un movil) que usan otras aplicaciones personalizadas que tan poco tienen nada que ver con el comienzo de la cadena. Se explica a continuación este trabalenguas de datos que vienen y van. 97 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Diagrama: Cualquier intérprete, compilador, puede leer datos estructurados y trabajar con ellos. No solo es importante que los datos sean abiertos y públicos. Que su estructura esté definida por estándares establecidos por el W3C (RDF e SPARQL) será una garantía para el trabajo con estos datos y su reutilización. Fácilmente interpretables por máquinas y personas. El Gobierno de La Rioja, comunidad donde se presenta este PFC lanzó 35 en el año 2012 su propio portal de datos abiertos donde el organismo abre la información pública para que los diferentes agentes involucrados en el sector Open Data puedan acceder a ella y reutilizarla. Tres son los tipos de datos que se pueden encontrar en www.larioja.org/datoabierto: directorios, estadísticas y datos geográficos, en formatos XLS, XML, CSV o “JSON”. En este año, “json” todavía no estaba tan estandarizado como ahora mismo, en 2014, donde parece que se está imponiendo, principalmente para aplicaciones web con APIS externas de hombre máquina. Sumada a esta iniciativa open data, cabe destacar la sección especial de la entidad IDE Rioja (Infraestructura de Datos Espaciales de La Rioja) que, desde el pasado mes de febrero, publica todos los datos geográficos de su portal en abierto bajo la licencia Creative Commons Reconocimiento 4.0 Internacional. De esta manera, es posible reutilizar la información para fines comerciales y no comerciales con la única condición de reconocer la autoría de los datos. El autor de este PFC recuerda con claridad aquellos años ya que su empresa ganó un concurso para la comunidad riojana para gestionar durante cerca de 3 años varios apartados de la web institucional larioja.org. Se rememora por tanto como llegaban las nuevas directrices para tratar dicha información en las web institucionales. El apartado web que se gestionaba en aquella época no tenía acceso directo a datos o configuraciones, ya que se realizaba una gestión de actualización y gestión de contenidos de un software J2EE. 35 http://datos.gob.es/content/rioja-apuesta-apertura-de-datos-publicos 98 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Desde estos años de trabajo para el mundo institucional se ha tomado conciencia de la importancia de trabajar con datos abiertos licenciados también como tales y estandarizados para su reutilización. Datos estructurados. Diagrama : Los datos estructurados más comunes Estos datos pueden ser interpretados por cualquier lenguaje de programación moderno. Todos estos sistemas disponen de librerías y-o funciones que abren estos ficheros y los compilan dentro de sus formatos. Los cargan en arrays. buffers, variables, etc. Así, cualquier programador puede acceder, y tratar esos ficheros dentro del lenguaje que entienda. Por ejemplo en este caso, cualquier programador podrá usar el fichero “json” que creen los programas de este documento de datos de temperatura posicionados en un mapa, para crear sus propios diagramas o estudios. Sus propios históricos, tablas, análisis etc. Y no solo usarlos, y reutilizarlos, si no ampliarlos y mejorar lo establecido. Esta filosofía de compartir y mejorar es la base del Open Source y algunas de sus licencias como GPL-GNU, Creative Commons. En este PFC todos los datos se ha tomado la decisión de ser convertidos y manipulados bajo el formato “json”. También existirán versiones en texto plano, y en bases de datos finales MySQL. Pero para la transmisión de un formato a otro, “json”, y su modelo estructurado es el más compatible de todos. También es el más actualizado, y el que está adoptando la gran mayoría de programadores de php, 99 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado html5, y todos los usuarios de librerías jquery. Se garantiza por tanto que el uso de “json”, en contraposición con csv, xls, rss, etc generará una estructura que será compatible con el 99% de los usuarios que quisieran trabajar en el futuro con estos datos. Ilustración 25 El viaje de la información. Por otro lado, uno de los puntos más importantes que se ha encontrado en el trabajo con open data basado en “json” para este proyecto es la compatibilidad entre Processing, php, y html5 + javascript. 100 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.11.2 TIEMPO REAL DE LAS APLICACIONES Como se ha hecho hincapié en capítulos anteriores de esta memoria, se han desarrollado 3 aplicaciones principales para tener un concepto global de las posibilidades que este proyecto presenta. Trabajar en tiempo real, es decir, visualizar al mismo tiempo unos datos que el sistema está capturando es imprescindible que así suceda por el operario que está insitu haciendo el muestreo. Visualiza el valor que desea, en el punto que precise enviando el multirotor y haciendo el muestreo. No solo visualiza el valor, si no, que el sistema le indicará si ese valor capturado está dentro de los baremos establecidos. Ya sea una temperatura, uno humedad relativa o un detector de humos, etc. Este tiempo real es absolutamente inmediato. Se habla en este caso de menos de 1 segundo. Se podría hacer por tanto unas capturas y unas mediciones de varias veces por segundo para crear mapas muy precisos incluso con gradientes, alturas, etc. La velocidad de esta captura y posterior emisión estaría limitada por la velocidad de transmisión del sistema inalámbrico elegido en este caso. Como siempre, la cadena se rompe por el eslabón más débil. Este apartado ha sido totalmente solucionado en este proyecto. La tres aplicaciones presentadas nos permitirán este modo de trabajo “insitu” en tiempo real. Pero… como se ha replicado, en este mundo tan online en el que estamos, el trabajar con los datos en la red, es ineludible. Para ello se han buscado todas las opciones posibles para llevar y poder implementar estas propiedades. El modelo 1, que envía datos desde Arduino a un router directamente y de ahí el dato sube directamente a una base de datos a través de la ejecución un programa en un servidor remoto en php, ya lo hace por defecto. Coloca este dato en el servidor para ser interpretado posteriormente de ser convertido en un fichero json y leído en javascript. 101 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado El modelo 2 y 3 funcionarían de diferente forma. El dato llega por el puerto serie desde Arduino a un ordenador. Éste, mediante Processing interpreta el dato. Lo muestra en tiempo real y lo guarda en un fichero “json” en un ordenador local. Este ordenador local está programado en modo servidor con Apache y con una serie de scripts basados en “php” tratan ese fichero leyendo su información y enviándola a la base datos local, y clonando la información en una base de datos en un servidor de internet. Existirá otra opción en la que el sistema se salte el paso de guardar los datos en modo local y usará el servidor programado para coger el fichero de datos y subirlo a internet. Será mediante la ejecución dentro de Processing de instrucciones directas que conectan con la base de datos en el servidor, ejecutando un código php que captura el dato y lo guarda en la base datos. Diagrama: Captura datos y llegada a Processing en formato inalámbrico. A continuación un resumen de los modelos de funcionamiento. 102 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.11.3 FUNCIONAMIENTO MODELO 1 TIEMPO REAL 1. Se instalan en la placa Arduino unos sensores. 2. Se programa la placa bajo el IDE de Arduino y su software correspondiente es compilado a la rom del micro. 3. Arduino captura los datos con sus respectivos sensores. 4. Por cable de red los envía a un Router conectado a un ordenador y a internet. 5. El router directamente sin pasar por el ordenador (o también) envía datos a un servidor. 6. En el servidor de internet (y local) habrá unos ficheros programados en php que entienden la petición hecha desde Arduino. GET, POST, etc. 7. El script del servidor guarda los datos que llegan en una base de datos previamente programada y configurada en MySQL. La dificultad de implantación de esta aplicación se considera media-alta. Ilustración 26 Arduino directo 103 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.11.4 FUNCIONAMIENTO MODELO 2 Y 3 TIEMPO REAL 1. Se instalan en la placa Arduino unos sensores. 2. Se programa la placa bajo el IDE de Arduino y su software correspondiente. 3. Arduino captura los datos con sus respectivos sensores. 4. Mediante sistema inalámbrico envía los datos a un ordenador local. 5. En tiempo real el ordenador bajo Processing muestra los datos al usuario. 6. En tiempo real, Processing guarda todos los datos en ficheros de texto plano sin formato y en ficheros estructurados en formato json. 7. Se programa un servidor en el mismo ordenador para soportar php, mysql. 8. Este servidor, mediante un script que se ejecutará manualmente o podría ser programado bajo cron36, o refrescado cada cierto tiempo abrirá el fichero json y enviará los datos al servidor en modo local a su mySQL y hará una clonación de los datos a un servidor de internet. 104 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado La dificultad de implantación de esta aplicación se considera muy alta, experto. Crear dos ficheros json, uno en modo local para guardar lo datos, y otro en el servidor para mostrarlos gráficamente será muy complejo de sincronizar. Tanto que con ello, se debe explicar que los que se considera tiempo real, queda descartado por completo. Requeriría de una sincronización entre servidores mediante instrucciones cron, que vigilarán hora de los mismos, que comprobaran que los ficheros están ya abiertos y no se siguen escribiendo datos…etc y un sinfín de inconvenientes surgidos que como se reitera, el tiempo real para la visualización de estos dos modelos se ha descartado. Mínimo unos 5 minutos de desfase entre captura y visualización en la red online. Es un tiempo estimado y perfectamente podría duplicarse. No se ha medido. La dificultad de implantación de esta aplicación se considera alta y muy alta para el tratamiento y posicionamiento bajo GPS. 1.11.5 ALTERNATIVA PARA EL MODELO 2 Y 3 Se intentará saltar el paso de crear ficheros json desde processing, o por lo menos, aunque estos ficheros si serán creados, no usarlos para el tratamiento real de la señal. Se podrán usar para el tratamiento de históricos, compartirlos bajo open data estructurado etc. Como alternativa se creará una aplicación dentro de Processing que contactará directamente con los scripts en php en los servidores mediante la función GET o POST muy similar a la usada desde Arduino cuando se conectaba directamente al Router. Esta aplicación en php podría estar en modo local, o en modo servidor, sería exactamente la misma, y su función sería capturar el dato y guardarlo en la base de datos mysql. Tanto en modo local como en modo servidor 36 En el sistema operativo Unix, cron es un administrador de procesos en segundo plano (demonio) 105 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado de internet. De esta forma el tiempo real se reduciría de esos largos minutos a unos pocos segundos, y dependiendo de la red, sería casi inmediato. Otro problema surgiría si en ese momento de captura alguien estuviera visualizando los datos. Posiblemente este usuario estaría viendo el fichero json recién exportado por el servidor remoto y no estaría viendo los nuevos datos, pues no habría habido petición de exportación y ejecución de dicho scritp. Para ello , este usuario debería ejecutar o refrescar de nuevo la dirección web, pulsar F5, y si hubiera problemas quizá limpiar la cache de su navegador ( solo en algunos casos 10%). Diagrama: Proceso desde el Multirotor a Interet via Processing y Router La dificultad de implantación de esta aplicación se considera alta. 106 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.12 BOOTSTRAP DE TWITTER Para el panel de administración de la web que se basará en html5 y CSS3 se ha optado por no comenzar desde cero para la creación de una plantilla. Existen plantillas de html5 en la red con las que se podrían haber empezado sin tener que usar otro código nuevo que aprender y usar. Twitter Bootstrap es un framework o conjunto de herramientas de software libre para diseño de sitios y aplicaciones web. Contiene plantillas de diseño con tipografía, formularios, botones, cuadros, menús de navegación y otros elementos de diseño basado en HTML y CSS, así como, extensiones de JavaScript opcionales adicionales. Es el proyecto más popular en GitHub y es usado por la NASA y la MSNBC junto a demás organizaciones. Bootstrap tiene un soporte relativamente incompleto para HTML5 y CSS3, pero es compatible con la mayoría de los navegadores web. La información básica de compatibilidad de sitios web o aplicaciones está disponible para todos los dispositivos y navegadores. Existe un concepto de compatibilidad parcial que hace disponible la información básica de un sitio web para todos los dispositivos y navegadores. Por ejemplo, las propiedades introducidas en CSS3 para las esquinas redondeadas, gradientes y sombras son usadas por Bootstrap a pesar de la falta de soporte de navegadores antiguos. Esto extiende la funcionalidad de la herramienta, pero no es requerida para su uso. Desde la versión 2.0 (en este PFC se usará la 3) también soporta diseños sensibles RWD. Esto significa que el diseño gráfico de la página se ajusta dinámicamente, tomando en cuenta las características del dispositivo usado (Computadoras, tabletas, teléfonos móviles). Esta ha sido la principal decisión para usar como plantilla un panel de administración basado en Bootstrap, que el resultado de todo lo que se haga online será compatible con todos los dispositivos. De esta forma, no se ve necesario el crear una APP de instalación específica para cada dispositivo: Android, ios, 107 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Windows Phone, BalckBerry ,etc. El mero acceso a la web detecta el aparato conectado y ajusta la plantilla para el móvil o tableta en cuestión. Aún así, al haber creado todo basado en Bootstrap se genera un código tan limpio que puede ser importado desde Eclipse + Phone Gap, y crear APPS compatibles con sus respectivos SDK. Asimismo se podría usar la última aplicación abierta de Adobe para crear apps compatibles. Su popular PhoneGap Build. Pero se reitera, que como el acceso vía web es compatible con la opción adoptada, crear apps instalables no será necesario. Por otro lado, las apps se crean cuando se el uso que se le dará a la misma sería offline; y en este trabajo, siempre se estará tirando de datos en internet para estar actualizados y usando continuamente la red. Desestimado. 108 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 27 Panel de admin online En el panel de Admin se verán datos de lecturas, control de las bases de datos, video wifi, etc. 109 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.12.1 VISUALIZACIÓN EN INTERNET DE LOS DATOS Ya están todos los datos guardados en el servidor local y en el servidor de internet. Se explica ahora como se mostrarán dichos datos para que sean interpretados por el usuario final de la aplicación web. 1. Los datos ya están guardados en una base de datos en un servidor bajo MySQL. 2. Se programa un script que se sube al servidor que captura los datos que deseen ser visualizados. La programación se hará bajo PHP. 3. Se crea una aplicación en HTML5. 4. Se programa una aplicación en php para generar ficheros json a raíz de los ficheros de la MySQL. 5. La aplicación web en css3, html5, javascript, jquery, Ajax, carga los datos del fichero json en un array interno. 6. Los datos son mostrados usando librerías externas jquery , svg, … Las librerías externas usadas en este PFC para estas aplicaciones son librerías de uso gratuito, libre de licencias y open source, lo que permite usar su código y modificarlo. Se usarán las más estandarizada para ello: jqplot, flot, highcharts, etc. Todas ellas serán descargadas de Github, webs oficiales o sitios similares de código abierto que garanticen una seguridad contrastada y que se está trabajando con las últimas versiones. Es importante trabajar de esta forma para no comprometer la seguridad de nuestro servidor. Habrá que configurar muchos parámetros de directorios para dar permisos chmod de escritura y acceso externo y evitar dichos peligros requerirá de un esfuerzo y configuración extra, más aún cuando la información no va a llegar de forma codificada ni bajo ningún estándar de seguridad o https. 110 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Diagrama: Desde el servidor se muestran los datos. La web en html5 tendrá algún apartado programado también bajo LESS que generará CSS3 dinámicas. Pero estas CSS no se generarán en tiempo real. Seria ralentizar el sistema y la complejidad de la aplicación se dispararía. Se recuerda que LESS es un lenguaje de estilo dinámico que apenas lleva en el mercado desde 2010. Su uso se está estandarizando en la programación web desde 2012. En este PFC las compilaciones de LESS a CSS3, serán previas y los ficheros subirán ya compilados para ser usados. Pero conservar originales de LESS dará muchas posibilidades de configuración futuras para aplicación web. La dificultad de implantación de esta aplicación se considera muy alta. 111 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.12.2 COMO RESULTADO UN SISTEMA MULTIPLATAFORMA Se ha comprobado que el sistema es compatible para 1. Acceso desde cualquier PC sobremesa o portátil. Netbook, Ultrabook, etc. 2. En 125 versiones de diferentes navegadores navegadores: Safari, iOS Android Browser, Google Chrome, Amazon Silk, BlackBerry Browser, Nokia Browser, Internet Explorer, Opera Mobile, Opera mini, Firefox – Se adjunta en anejo correspondiente las pruebas realizadas. 3. Tabletas ios, Android. 4. Telefonía móvil : a. Android, desde la versión 2.4 b. BlackBerry c. Windows Phone d. Symbian, al 99% ( no funcionan gráficos SVG) e. iPhone, iPad, Phones & Tablet, Android 4.0+, Kindle Fire, Phones, Tablet, MeeGo-N9, Symbian, Windows Phone 7.5, Windows 8, Android & Symbian, Java ,iOS, Android, Android, MeeGo, HP Phone …y en resumen, con cualquier dispositivo compatible37 con html5 37 http://mobilehtml5.org/ 112 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.12.3 FORMATOS GRAFICOS DE LOS DATOS En los últimos años se ha producido una enorme proliferación de datos en bruto que deben de ser procesados y preparados de una forma comprensible y visualmente atractiva para el usuario final. La mayoría de estas representaciones se integran en servicios web, y de muchas de ellas se espera que sean interactivas. Esto supone que el lenguaje de programación utilizado en muchas ocasiones sea JavaScript y que los datos a tomar en muchos ocasiones, en formatos JSON. Para este proyecto se ha programado principalmente estos formatos de trabajo, para comprobar compatibilidades finales con dispositivos móviles: canvas, javascript, jquery, svg. Las más conocidas serían: MorrisJS, jqPlot, JsPlumb, JsCharts, Flot, Fusioncharts Highcharts Jqplot es una librería escrita en JQuery y Javascript que utiliza el elemento Canvas para representar del lado del cliente gráficos dinámicos por medio de programación Highcharts es otra iblioteca de gráficos escritos en JavaScript puro que ofrece una forma fácil de añadir gráficos interactivos a su sitio web o aplicación web, basada en JQuery por lo que permite generar todo tipo de Charts. Funciona en todos los navegadores modernos, incluyendo el iPhone / iPad e Internet Explorer. Se basa únicamente en tecnologías de navegación nativas que no requieren plugins secundarios del lado del cliente como Flash o Java. Generan datos en SVG. 113 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 28 Formato SVG Flot es una biblioteca JavaScript con un aspecto simple y atractivo que presenta características interactivas. La navegabilidad es posible tanto en Internet Explorer, Chrome o Firefox como en navegadores móviles en plataformas como iOS y Android. Por último, la inserción de datos se efectúa con formato JSON. Flot que tiene soporte para extensiones y se puede usar como un plugin de jQuery. Dentro del panel de administración se crearán diferentes formatos para la visualización gráfica de los datos. Tiempo real, históricos ..etc. La principal ventaja que deviene de la utilización del formato SVG es su perfecta visualización en cualquier dispositivo, sea una computadora de escritorio convencional o el más avanzado gadget con alta resoluciones (tipo retina). En el diagrama siguiente se resume como el servidor basado en Apache, ejecuta el código script php, coge los datos de la MySQL y los convierte a JSON, que mediante html5 y JS son cargados en el código en diferentes arrays para hacer llamadas a las funciones gráficas y mostrarlos. 114 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Se ve como en cada dispositivo el aspecto varía cambia. Se verán diferentes estructuras puesto que el código se interpreta de forma diferente. Diagrama: Visualización de la aplicación en diferentes dispositivos. 115 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.13 VERSIONES DEL SOFTWARE El desarrollo de este software y su hardware dependiente se presenta en este trabajo y en su posterior exposición y defensa pública como proyecto Universitario en versión Alfa. Y aunque todo su desarrollo se ha realizado como proyecto real, el resultado no lo es. Se trata de un paquete de Hard+Soft que se ha quedado en versión Alfa demostrativa, indicando sus bondades, características y posibilidades de crecimiento, aplicación, etc. Es un producto inestable y no terminado puesto que en parte es una revisión de futuras posibilidades del entorno. Sirvan estos ejemplos de muestra: Los datos capturados son meros parámetros de temperatura y luz en un campo abierto. Cuya aplicación futura es “cuasi” nula, pero da la posibilidad de cambiar los sensores e instalar por ejemplo un detector de humos o gases tóxicos que sirvan como aviso, etc El tiempo real en la red no está automatizado en su integridad. Sí que en modo consola se verán todo el proceso en RealTime, pero no así en internet ya que depende de la configuración insitu de una serie de parámetros complejos y de unos ajustes que habría que retocar para una aplicación concreta. Todas las configuraciones básicas están grabadas en sus correspondientes setups, pero las avanzadas no lo están. Estás son dependientes de cada instalación, de cada ordenador, y de cada dispositivo. Por ello, solo el desarrollador del software o en su defecto un usuario avanzado podría hacer una prueba de funcionamiento y ajustes en tiempo real. Por ejemplo, habrá que cambiar puertos de comunicaciones cada vez que se conecten o desconecten dispositivos, y esto implica el tener que volver a compilar y crear, ino, jar, js, “json”, mysql, php o standalone de cada aplicación …etc 116 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Por estos condicionantes y características este software se presenta como una versión α. Una primera revisión del programa; lo que a nivel de software se podría llamar a un producto inestable y se está a la espera de que se eliminen los errores ó a la puesta en práctica completa de toda su funcionalidad, pero satisface la mayoría de los requisitos. Este proyecto puede pasar a una versión BETA β, Y a una Beta 1.0 en cuestión de unas horas. Simplemente al conocer unas necesidades concretas básicas de un cliente final. El proceso de desarrollo de una 1.0 a sus posteriores 1.X será de unos pocos días. Asimismo también podría llegar a ser una Beta 2. Funcional, comercial y vendible en una semana, satisfaciendo casi cualquier necesidad de un cliente final. Se entenderá por Versión BETA β la que representa la primera versión completa del programa. Los desarrolladores las lanzan a un grupo de probadores, a veces al público en general, para que lo prueben e informen de cualquier error que encuentren y propongan características que quisieran encontrar en la versión final. De la misma forma, ya sin un tiempo establecido y bajo las peticiones específicas todo el este software “puede” pasar a ser una Versión RC, candidata a definitiva bajo unas revisiones insitu y bajo el software ya instalado y funcional en un sistema único. Comprende un producto final preparado para lanzarse como versión definitiva a menos que aparezcan errores que lo impidan. Por otro lado llegar a ser una Versión RTM ó de disponibilidad general en este caso sería casi imposible ya que se habla de software custom, propietario y dependiente de hardware y de configuraciones muy privativas y específicas. Se considera una RTM una versión final del programa. Normalmente es casi idéntica a la versión RC, con sólo correcciones de último momento. Esta versión es considerada muy estable, relativamente libre de errores y con una calidad adecuada para una distribución amplia y para ser ya utilizada por los usuarios finales. 117 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.14 REQUISITOS DE EXPOSICIÓN-PRESENTACIÓN Se desconoce si en el lugar elegido para demostraciones o presentaciones se cumplirán las necesidades básicas que este proyecto necesita como pueden ser: red wifi potente, campo abierto y tiempo necesario para estabilización de los datos capturados por el GPS, lugar de interferencias electromagnéticas que imposibiliten tanto el vuelo del Drone como la emisión de datos de los sistemas inalámbricos instalados. Tomas de corriente necesarias para ordenadores y carga de datos, software, etc. Zona libre de vuelo de vehículos comerciales como avionetas de pruebas o antiincendios. Zona preparada para vuelo de Drones de peso medio sin riesgo para el entorno y-o visitantes. Tiempo necesario para la preparación de vuelo de un Drone: IMU, Compas, estabilizaciones verticales, horizontales; requieren unos minutos de configuración sí o sí, antes de comenzar cada vuelo de prueba. Datos concretos: 1. Para recepción de datos del GPS a Arduino se requiere un mínimo de 3 satélites. Si no, resultado 0. Medidas correctas estables a partir de 7 satélites. 2. Para el vuelo del Drone la recepción mínima será un posicionamiento de 6 satélites. 3. La distancia máxima del vuelo del Drone con carga será de 200 metros. 4. El tiempo de vuelo seguro máximo será de 12 minutos en vacío, 9 minutos con carga. Cámara + placa. 5. La distancia máxima para recepción de video wifi correcta en live streaming será 50 metros. 6. La distancia máxima para recepción de datos inalámbricos en el módulo 3DR será 60 metros. 118 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 7. La distancia máxima para la recepción de datos inalámbricos para el módulo Xbee será de 75 metros. 8. La distancia de riesgo inasumible para el Drone será de 300 metros horizontales. 9. La altura máxima de vuelo aconsejado será de 50 metros. Aunque se tenga la capacidad de triplicar esta distancia. Pero el riesgo es inaceptable. 119 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.15 ORDEN DE PRIORIDAD DOCUMENTAL Este será el orden de prioridad documental. 1. Especificaciones del Sistema 2. Pliego de Condiciones 3. Planos 4. Memoria Descriptiva. 1.15.1 COMPATIBILIDAD Y RELACION ENTRE DICHOS DOCUMENTOS En caso de incompatibilidad o contradicción entre los Planos y Pliego, prevalecerá lo escrito en este último documento. Entre pliego y Especificaciones, prevalecerá lo escrito en este último. En cualquier caso lo mencionado en el Pliego de Condiciones y omitido en los planos o viceversa, habrá de ser considerado como si estuviese expuesto en ambos documentos, siempre que la unidad del Proyecto este definida en uno u otro documento y figure en el Presupuesto. 1.16 BIBLIOGRAFÍA La mayor la información consultada para este proyecto se ha basado en documentación online. Ejemplos de las webs de los fabricantes y librerías de los mismos. Sirvan de referencia y ayuda, algunas de las más visitadas. http://www.Arduino.cc/es/ https://php.net/manual/es/ https://www.processing.org/ http://unfoldingmaps.org/ http://www.w3schools.com/ http://www.larioja.org/ http://es.wikipedia.org/ http://www.phpmyadmin.net/ http://www.aeromodelismovirtual.com/ http://www.dji.com/ http://www.aeromodelismofacil.com/ http://www.multicopters.es/ http://www.aenor.es http://www.sojamo.de/ 120 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.16.1 REFERENCIAS BIBLIOGRÁFICAS DE ESTUDIOS CON ENTIDAD PROPIA. [1]. Martínez De Pisón Ascacíbar, F. J. y otros. “La oficina técnica y los proyectos industriales. Volumen II”. Ed. S. P. UR. 2002. [2]. Morilla Abad, Ignacio. “Guía metodológica y práctica para la realización de Proyectos. Tomo II. Ed. SP Colegio Oficial de Caminos, Canales y Puertos de Madrid. 2001 121 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.17 DEFINICIONES Y ABREVIATURAS LISTADO DE ACRÓNIMOS Y TECNICISMOS USADOS APM : ArduPilot Mega 2.0 - DIY Drones ArduPilot . Placa basada en Arduino Mega específica para vuelos. IEEE. Institute of Electrical and Electronics Engineers. Es una de las mayore asociaciones en el campo de la ciencia y la tecnología. Uno de los trabajos más conocidos que desarrollan es la estandarización. WI-FI. Marca de la Wi-Fi Alliance Mecanismo de conexión de dispositivos electrónicos de forma inalámbrica. Sigue la norma IEEE 802.11. (anteriormente la WECA: Wireless Ethernet Compatibility Alliance), SRS - ERS El estándar IEEE 830-1998 para el SRS(en inglés) o ERS (Especificación de requerimientos de software) es un conjunto de recomendaciones para la especificación de los requerimiento o requisitos de software el cuál tiene como producto final la documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir con la totalidad de exigencias estipuladas. La especificación de requisitos de software (ERS) es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el software. Las características de una buena ERS son definidas por el estándar IEEE 830-1998 TTL: Es la sigla en inglés de transistor-transistor logic, es decir, «lógica transistor a transistor». Es una familia lógica o lo que es lo mismo, una tecnología de construcción de circuitos electrónicos digitales. ZigBee Es el nombre de la especificación de un conjunto de protocolos de alto nivel de comunicación inalámbrica para su utilización con radiodifusión digital de bajo consumo, basada en el estándar IEEE 802.15.4 Lós módulos XBee utilizan el protocolo conocido como ZigBee. Este protocolo se creó 122 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado pensando en implementar redes de sensores. El objetivo es crear redes tipo mesh que tengan las propiedades de auto-recuperación y bajo consumo de energía. LDR viene de la expresión inglesa Light Dependent Resistor. Sensor de Luz Frameworks: En el desarrollo de software, es infraestructura digital, conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, que puede servir de base para la organización y desarrollo de software. Iincluye soporte de programas, bibliotecas, y un lenguaje interpretado Scaffolding: La palabra Scaffold significa Andamio, pero en programación el scaffolding es un método para contruir aplicaciones basadas en bases de datos, esta técnica está soportada por varios frameworks. Standalone: Software de ejecución totalmente independiente. Wiring: Framework de programación open source para microcontroladores. Processing: es un lenguaje de programación y entorno de desarrollo integrado de código abierto basado en Java. UART : Universal Asynchronous Reciever/Transmitter RS-232 : Recomended Standard-232 – Puerto serie clásico. NMEA 0183 (o NMEA de forma abreviada) es una especificación combinada eléctrica y de datos entre aparatos electrónicos marinos y, también, más generalmente, receptores GPS. El protocolo NMEA 0183 es un medio a través del cual los instrumentos marítimos y también la mayoría de los receptores GPS pueden comunicarse los unos con los otros. Ha sido definido, y está controlado, por la organización estadounidense National Marine Electronics Association. APM2 Simulink blockset - librerías para usar con ArduPilot Mega 2.0 hardware. 123 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado RoHS de las siglas en inglés ( Restriction of Hazardous Substances) se refiere a la directiva 2002/95/CE de Restricción de ciertas Sustancias Peligrosas en aparatos eléctricos y electrónicos, fue adoptada en febrero de 2003 por la Unión Europea. Checksum suma de verificación, también llamada suma de chequeo que tiene como propósito principal detectar cambios accidentales en una secuencia de datos para proteger la integridad de estos. Fritzing es un programa de automatización de diseño electrónico libre que busca ayudar a diseñadores y artistas para que puedan pasar de prototipos (usando, por ejemplo, placas de pruebas) a productos finales. Fritzing fue creado bajo los principios de Processing y Arduino. IMU. Una unidad de medición inercial o IMU (del inglés inertial measurement unit), es un dispositivo electrónico que mide e informa acerca de la velocidad, orientación y fuerzas gravitacionales de un aparato, usando una combinación de acelerómetros y giróscopos. Las unidades de medición inercial son normalmente usadas para maniobrar aviones, incluyendo vehículos aéreos no tripulados. Beidou es un proyecto desarrollado por la República Popular de China para obtener un sistema de navegación por satélite. "Beidou" es el nombre chino para la constelación de la Osa Mayor. ESC Electronic Speed Controller. También llamado "variador". Controlador de motores. Cámara IP (en inglés "IP cameras") es una cámara que emite las imágenes directamente a la red (Intranet o internet) sin necesidad de un ordenador. Cable, wifi, infrarojos., etc CCD. Charge coupled device en español «dispositivo de carga acoplada» es un circuito integrado que contiene un número determinado de condensadores enlazados o acoplados. 124 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado MPEG-4 es un formato AAC de compresión de datos de audio desarrollado por el Instituto Fraunhofer conjuntamente con algunas empresas privadas como AT&T, Nokia, Sony y Dolby. OpenGL (Open Graphics Library) es una especificación estándar que define una API multilenguaje y multiplataforma para escribir aplicaciones que produzcan gráficos 2D y 3D. ARF: Almost ready to fly PNP: Plug & Play RTF: Ready to fly BNF: 'Bind-and-fly' Suspensión Cardán del francés cardan, por alusión a Girolamo Cardano, 1501-1576, médico y de suspensión consistente escritor en dos italiano) aros es un concéntricos mecanismo cuyos ejes forman ángulo recto, lo cual permite mantener la orientación de un eje de rotación en el espacio aunque su soporte se mueva. Para ello se usan los Gimbals. Gimbal estabilizador de imagen, siempre mantiene el horizonte y la vertical en la cámara. APK: Application PacKage File es un paquete para el sistema operativo Android. Es una variante del formato JAR de Java y se usa para distribuir e instalar componentes empaquetados para la plataforma Android para smartphones y tablets GSM/GPRS General Packet Radio Service (GPRS) o servicio general de paquetes vía radio creado en la década de los 80 es una extensión del Sistema Global para Comunicaciones Móviles (Global System for Mobile Communications o GSM) para la transmisión de datos mediante conmutación de paquetes 125 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado OEM: Las licencias OEM son licencias de software que son adquiridas en la compra de un PC con software legalmente preinstalado. Si alguna vez ha adquirido un PC Nuevo con Microsoft Windows® o Microsoft Office ya instalado, ha adquirido licencias de software OEM. Las licencias OEM solo pueden ser utilizadas e instaladas en el PC con el que fueron preinstaladas. RDF: El Marco de Descripción de Recursos (del inglés Resource Description Framework, RDF) es una familia de especificaciones de la World Wide Web Consortium (W3C) originalmente diseñado como un modelo de datos parametadatos. Mashups : Mashup (aplicación web híbrida) En desarrollo web, una mashup es una aplicación que usa y combina contenido de más de una fuente, para crear un nuevo servicio simple, visualizado en una única interfaz gráfica. Por ejemplo, usted puede combinar las direcciones y fotografías de las ramas de su biblioteca con un mapa de Google para crear un mashup de mapa. GNU La Licencia Pública General de GNU o más conocida por su nombre en inglés GNU General Public License (o simplemente sus siglas del inglés GNU GPL) es la licencia más ampliamente usada1 en el mundo del software y garantiza a los usuarios finales (personas, organizaciones, compañías) la libertad de usar, estudiar, compartir (copiar) y modificar el software. Hacker Gente apasionada en el desarrollo. Entusiastas. GPU Unidad de procesamiento gráfico o GPU (acrónimo del inglés graphics processing unit) es un coprocesador dedicado al procesamiento de gráficos u operaciones de coma flotante SDK Un kit de desarrollo de software o SDK (siglas en inglés de software development kit) es generalmente un conjunto de herramientas de desarrollo de software que le permite al programador crear aplicaciones para un sistema concreto, por ejemplo ciertos paquetes de software, frameworks, plataformas de hardware, 126 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado JSON acrónimo de JavaScript Object Notation, es un formato ligero para el intercambio de datos. PIRE En sistemas de Radiocomunicación, la Potencia Isotrópica Radiada Equivalente (PIRE) es la cantidad de potencia que emitiría una antena isotrópica teórica (es decir, aquella que distribuye la potencia exactamente igual en todas direcciones) para producir la densidad de potencia observada en la dirección de máxima ganancia de una antena. Canvas (lienzo en inglés) es un elemento HTML incorporado en HTML5 que permite la generación de gráficos dinámicamente por medio del scripting. Github es una forja para alojar proyectos utilizando el sistema de control de versiones Git. Utiliza el framework Ruby on Rails por GitHub, Inc CRON En el sistema operativo Unix, cron es un administrador regular de procesos en segundo plano (demonio) 127 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.18 NORMAS Y REFERENCIAS 1.18.1 NORMAS PARA CONSULTA UNE 66904-6:2000 – Gestión de la calidad.- Directrices para la Gestión de proyectos (ISO 10006:1997) UNE 71044 – Tecnología de la Información – Proceso del ciclo de vida del software (ISO/IEC 12207: 1995) UNE 71045-1 – Tecnología de la Información – Medida del Software - Medida del tamaño funcional - Parte 1: Definición de conceptos (ISO/IEC 14143-1: 1998) UNE 71048-5 - Tecnología de la información – Evaluación del producto software – Parte 5: Procesos para evaluadores (ISO/IEC 14598-5) UNE 157001 – Criterios generales para la elaboración de proyectos UNE 17799 IN - Tecnología de la Información - Código de buenas prácticas de la Gestión de la Seguridad de la Información (ISO/IEC 17799) UNE 50113-11/02/03 UN 50132:1994 UNE 90003:2004 Ingeniería del software: Guía para la aplicación de la norma ISO 9001:2000 al software de ordenadores ISO/IEC 2382-1:1993 – Information Technology – Vocabulary – Part 1: Fundamentals term ISO 2382-2:1976- Data processing -- Vocabulary -- Part 2: Arithmetic and logic operations ISO 2382-3:1987- Information processing systems Vocabulary -- Part 3: Equipment technology 128 -- Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ISO/IEC 2382-4:1999- Information technology -- Vocabulary -- Part 4: Organization of data ISO/IEC 2382-5:1999- Information technology -Vocabulary -- Part 5: Representation of data ISO 2382-6:1987- Information processing systems -- Vocabulary -- Part 6: Preparation and handling of data ISO/IEC 2382-7:2000- Information technology -- Vocabulary -- Part 7: Computer programming ISO/IEC 2382-8:1998- Information technology -- Vocabulary -- Part 8: Securit ISO/IEC 2382-9:1995- Information technology -- Vocabulary -- Part 9: Data communication ISO 2382-10:1979- Data processing -- Vocabulary -- Part 10: Operating techniques and facilities ISO 2382-12:1988- Information processing systems -- Vocabulary -- Part 12: Peripheral equipment ISO 2382-19:1989- Information processing systems -- Vocabulary -- Part 19: Analog computing ISO 2382-21:1985- Data processing -- Vocabulary -- Part 21: Interfaces between process computer systems and technical processes ISO 2382-22:1986- Information processing systems -- Vocabulary -- Part 22: Calculators ISO/IEC 2382-13:1996- Information technology -- Vocabulary -- Part 13: Computer graphics ISO/IEC 2382-14:1997- Information technology -- Vocabulary -- Part 14: Reliability, maintainability and availability ISO/IEC 2382-15:1999- Information technology -- Vocabulary -- Part 15: Programming languages ISO/IEC 2382-16:1996- Information technology -- Vocabulary -- Part 16: Information theory ISO/IEC 2382-17:1999- Information technology Vocabulary -- Part 17: Databases 129 -- Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ISO/IEC 2382-18:1999- Information technology -- Vocabulary -- Part 18: Distributed data processing ISO/IEC 2382-20:1990- Information technology -- Vocabulary -- Part 20: System development ISO/IEC 2382-23:1994- Information technology -- Vocabulary -- Part 23: Text processing ISO/IEC 2382-24:1995- Information technology -- Vocabulary -- Part 24: Computer- integrated manufacturing ISO/IEC 2382-25:1992- Information technology -- Vocabulary -- Part 25: Local area networks ISO/IEC 2382-27:1994- Information technology -- Vocabulary -- Part 27: Office automation ISO/IEC 2382-28:1995- Information technology intelligence -- Basic concepts and expert systems - ISO/IEC Vocabulary 2382-29:1999- recognition and synthesis ISO/IEC 2382-31:1997- learning -- Information -- Part 28: Artificial technology intelligence -- Speech Vocabulary Information Vocabulary Part -- -- Part 29: Artificial technology intelligence -- Machine 31: Artificial ISO/IEC 2382-32:1999- Information technology -- Vocabulary -- Part 32: Electronic Mail ISO/IEC 2382-34:1999- Information technology -- Vocabulary -- Part 34: Artificial intelligence -- Neural networks ISO 3535:1977- Forms design sheet and layout chart ISO 5806:1984- Information processing -- Specification of single-hit decision tables 130 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ISO 5807:1985- Information processing -- Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts ISO/IEC 6592:2000- Information technology -- Guidelines for the documentation of computer-based application systems ISO 6593:1985- Information processing -- Program flow for processing sequential files in terms of record groups ISO/IEC 8211:1994- Information technology -- Specification for a data descriptive file for information interchange ISO/IEC 8631:1989- Information technology -- Program constructs and conventions for their representation ISO 8790:1987- Information processing systems -- Computer system configuration diagram symbols and conventions ISO/IEC 9126-1:2001- Software engineering -- Product quality -- Part 1: Quality model ISO 9127:1988- Information processing systems -- User documentation and cover information for consumer software packages ISO/IEC 10027:1990- Information technology -- Information Resource technology -- Information Resource Dictionary System (IRDS) framework ISO/IEC 10728:1993- Information Dictionary System (IRDS) Services Interface ISO/IEC 10746-1:1998- Information Distributed ISO/IEC Open technology -- Open Distributed -- Reference Model: Foundations 10746-3:1996- Information Distributed -- -- Reference model: Overview 10746-2:1996- Information Processing ISO/IEC Processing technology Processing technology -- Open -- Reference Model: Architecture 131 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ISO/IEC 10746-4:1998- Information Distributed Processing -- technology Reference -Model: Open Architectural semantics ISO/IEC 11411:1995- Information technology -- Representation for human communication of state transition of software ISO/IEC 12119:1994- Information technology -- Software packages -- Quality requirements and testing ISO/IEC 13235-1:1998- Information technology -- Open Distributed Processing -- Trading function: Specification ISO/IEC 13235-3:1998- Information technology -- Open Distributed Processing -- Trading Function -- Part 3: Provision of Trading Function using OSI Directory service ISO/IEC 13244:1998- Information technology -- Open Distributed Management Architecture ISO/IEC 13244:1998/Amd 1:1999- Support using Common Object Request Broker Architecture (CORBA) ISO/IEC 13800:1996- Information technology -- Procedure for the registration of identifiers and attributes for volume and file structure ISO/IEC 14102:1995- Information technology -- Guideline for the evaluation and selection of CASE tools ISO/IEC 14598-1:1999- Information technology -- Software product evaluation -- Part 1: General overview ISO/IEC 14598-2:2000- Software engineering -- Product evaluation -- Part 2: Planning and management ISO/IEC 14598-3:2000- Software engineering -- Product evaluation -- Part 3: Process for developers 132 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ISO/IEC 14598-4:1999- Software engineering -- Product evaluation -- Part 4: Process for acquirers ISO/IEC 14598-5:1998- Information technology -- Software product evaluation -- Part 5: Process for evaluators ISO/IEC -- 14598-6:2001- Software engineering -- Product evaluation Part 6: Documentation of evaluation modules ISO/IEC 14750:1999- Information technology -- Open Distributed Processing -Interface Definition Language ISO/IEC 14752:2000- Information technology -- Open Distributed Processing -Protocol support for computational interactions ISO/IEC 14753:1999- Information technology -- Open Distributed Processing -Interface references and binding ISO/IEC 14756:1999- Information technology -- Measurement and rating of performance of computer-based software systems ISO/IEC 14764:1999- Information technology -- Software maintenance ISO/IEC 14769:2001- Information technology -- Open Distributed Processing -- Type Repository Function ISO/IEC 14771:1999- Information technology -- Open Distributed Processing -Naming framework ISO/IEC 14834:1996- Information technology -- Distributed Transaction Processing -- The XA Specification ISO/IEC 14863:1996- Information technology -- System-Independent Data Format (SIDF) ISO/IEC 15026:1998- Information technology -- System and software integrity levels ISO/IEC 15288:2002- System Engineering – System life Cycle Processes 133 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ISO/IEC 15437:2001- Information technology -- Enhancements to LOTOS (E-LOTOS) ISO/IEC 15910:1999- Information technology -- Software user documentation process ISO/IEC TR 9294:1990- Information technology -- Guidelines for the management of software documentation ISO/IEC TR 12182:1998- Information technology -- Categorization of software ISO/IEC TR 12382:1992- Permuted index of the vocabulary of information technology ISO/IEC TR 14471:1999- Information technology -- Software engineering -Guidelines for the adoption of CASE tools ISO/IEC TR 14759:1999- Software engineering -- Mock up and prototype -- A categorization of software mock up and prototype models and their use ISO/IEC TR 15271:1998- Information technology -- Guide for ISO/IEC 12207 (Software Life Cycle Processes) ISO/IEC TR 15504-1:1998- Information technology -- Software process assessment -- Part 1: Concepts and introductory guide ISO/IEC TR 15504-2:1998- Information technology -- Software process assessment -- Part 2: A reference model for processes and process capability ISO/IEC TR 15504-3:1998- Information technology -- Software process assessment -- Part 3: Performing an assessment ISO/IEC TR 15504-4:1998- Information technology -- Software process assessment -- Part 4: Guide to performing assessments ISO/IEC TR 15504-5:1999- Information technology -- Software Process Assessment -- Part 5: An assessment model and indicator guidance ISO/IEC TR 15504-6:1998- Information technology -- Software process assessment -- Part 6: Guide to competency of assessors 134 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ISO/IEC TR 15504-7:1998- Information technology -- Software process assessment -- Part 7: Guide for use in process improvement ISO/IEC TR 15504-8:1998- Information technology -- Software process assessment -- Part 8: Guide for use in determining supplier process capability ISO/IEC TR 15504-9:1998- Information technology -- Software process assessment -- Part 9: Vocabulary ISO/IEC TR 15846:1998- Information technology -- Software life cycle processes -- Configuration Management ISO7IEC 15939 Software engineering -- Software measurement process ISO/IEC TR 16326:1999- Software engineering -- Guide for the application of ISO/IEC 12207 to project management ISO/IEC CD TR 19759 Software Engineering -- Body of Knowledge (SWEBOK) ISO/IEC 19.761 Software engineering- COSMIC-FFP. A functional size measurement method. ISO/IEC 20926 Unadjusted Software engineering functional size -- measurement IFPUG method 4.1 -- Counting practices manual ISO/IEC 20.968 Software engineering - FPA Functional Sizing Method ISO/IEC 24.570 Software engineering - Definition and counting guidelines for the application of Function Point Analysis. ISO/IEC 90003 Software and system engineering -- Guidelines for the application of ISO 9001:2000 to computer software SA-CMM:1996 (SEI) The Software Acquisition Capability Maturity Model SE-CMM 1995 (SEI) A Systems Engineering Capability Maturity Model SW-CMM 1993 (SEI) Capability Maturity Model for Software IEEE 729 135 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado IEEE 610.12 EIS 731-1 (EIA) MIL-STD 499B Eurométodo Métrica versión 3 (MAP) PMBOK - A Guide to the Project Management Body of Knowledge version 3 traducida al español (PMI) 136 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.19 INDICE DE ILUSTRACIONES Ilustración 1 Norma usada ................................................................................ 3 Ilustración 2 Gráfico en % de dependencia documental. ................................. 4 Ilustración 3 Kit de montaje de un 450 ........................................................... 26 Ilustración 4 Time Line ................................................................................... 38 Ilustración 5 Directo a Internet ........................................................................ 42 Ilustración 6 Localhost básico ........................................................................ 43 Ilustración 7 Tecnologías inalámbricas........................................................... 57 Ilustración 8 Consola mínima ......................................................................... 67 Ilustración 9 Datos Ayuda ............................................................................... 68 Ilustración 10 Consola principal de recepción de datos ................................. 69 Ilustración 11 Ejemplo de lectura y configración de dos datos. ...................... 70 Ilustración 12 Potenciometros de setup. ........................................................ 70 Ilustración 13 Parte central consola ............................................................... 70 Ilustración 14 Rejillas de muestro ................................................................... 71 Ilustración 15 Cuadro informativo. .................................................................. 71 Ilustración 16 Consola personalizada. ............................................................ 73 Ilustración 17 Mapa en real time - Geovisualización Urbano ........................ 75 Ilustración 18 Posicionamiento más lectura de datos. Urbano + dato ............ 76 Ilustración 19 Desde otro proveedor de mapas. Físicos y Topográficos. ....... 78 Ilustración 20 Proveedor Microsoft. Mapa Físico urbano. .............................. 79 Ilustración 21 Phanton 2 Vision. 2013 ............................................................ 85 Ilustración 22 Modos de grabación ................................................................. 89 137 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 23 Panel de admin web RWD ....................................................... 94 Ilustración 24 Admin web acceso móvil .......................................................... 94 Ilustración 25 El viaje de la información. ...................................................... 100 Ilustración 26 Arduino directo ....................................................................... 103 Ilustración 27 Panel de admin online ............................................................ 109 Ilustración 28 Formato SVG ........................................................................ 114 Ilustración 29 Fritzing ....................................................................................... 3 Ilustración 30 Octocopter.................................................................................. 4 Ilustración 31 Hexacopter ................................................................................. 4 Ilustración 32 Cuatricopter ................................................................................ 4 Ilustración 33 Naza setup ................................................................................. 7 Ilustración 34 Pila 9v ........................................................................................ 8 Ilustración 35 Arduino en modo portable ........................................................ 10 Ilustración 36 Software Center ....................................................................... 11 Ilustración 37 Puertos serie usados por Arduino ............................................ 11 Ilustración 38 FTDI para serie ........................................................................ 13 Ilustración 39 FTDI sofware drivers ................................................................ 13 Ilustración 40 Puerto Seleccionado ................................................................ 14 Ilustración 41 Tarjeta Seleccionada ............................................................... 14 Ilustración 42 Librería Ethernet en C++ .......................................................... 16 Ilustración 43 ipconfig ..................................................................................... 17 Ilustración 44 Resultados de IpConfig ............................................................ 17 Ilustración 45 MAC personal Subred .............................................................. 19 Ilustración 46 Puerto Serie a 9600 ................................................................. 21 138 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 47 Accediendo al Router ............................................................... 23 Ilustración 48 Configurando puertos ............................................................... 23 Ilustración 49 Versiones recomendadas ........................................................ 24 Ilustración 50 EasyPHP .................................................................................. 24 Ilustración 51 Paquetes completos para otros sistemas ................................ 25 Ilustración 52 Lectura correcta de un fichero en modo local. Localhost. ........ 26 Ilustración 53 Dato desde formulario en php .................................................. 27 Ilustración 54 Arduino Mega 1-2 ..................................................................... 28 Ilustración 55 USB para Arduino Uno ............................................................. 28 Ilustración 56 USB miniUSB ........................................................................... 29 Ilustración 57 Potenciometro. ......................................................................... 33 Ilustración 58 Potenciometro. ......................................................................... 33 Ilustración 59 Sonda NTC de temperatura ..................................................... 35 Ilustración 60 Acondicionador de señal para NTC 10k................................... 36 Ilustración 61 Curva caracteristica NTC ......................................................... 36 Ilustración 62 Ecuación de las NTC ............................................................... 36 Ilustración 63 Salida de un divisor de tensión ................................................ 37 Ilustración 64 Ecuación de la temperatura ..................................................... 37 Ilustración 65 Parámetro Rinf ......................................................................... 37 Ilustración 66 Ecuación STH .......................................................................... 38 Ilustración 67 Coeficientes ABC ..................................................................... 38 Ilustración 68 LDR en Arduino Ethernet ......................................................... 41 Ilustración 69 Circuito para LDR ..................................................................... 42 Ilustración 70 LDR en Arduino Ethernet ......................................................... 44 139 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 71 LM 35 en Arduino Uno ............................................................. 45 Ilustración 72 LM35 ........................................................................................ 47 Ilustración 73 GPS a Arduino UNO ................................................................ 49 Ilustración 74 Processing Básico .................................................................... 56 Ilustración 75 Fallo 1 de Pocessing ................................................................ 58 Ilustración 76 Solucion 2 ................................................................................ 58 Ilustración 77 Solucion 2. parte B. .................................................................. 59 Ilustración 78 Solucion 2. Parte C. ................................................................ 59 Ilustración 79 Mis Documentos. ..................................................................... 60 Ilustración 80 Librearías modo A. ................................................................... 61 Ilustración 81 Contribuida ............................................................................... 62 Ilustración 82 Librerías Processing método 2. ................................................ 62 Ilustración 83 Comprobación Open GL .......................................................... 63 Ilustración 84 Arduino y Xbee ......................................................................... 66 Ilustración 85 versión 2014 ............................................................................. 69 Ilustración 86 Versión clásica ......................................................................... 70 Ilustración 87 Xbee Hard ................................................................................ 70 Ilustración 88 Xbee Asignación ...................................................................... 71 Ilustración 89 Configuración 3DR ................................................................... 74 Ilustración 90 Configuración 3DR ................................................................... 75 Ilustración 91 3DR sobre el APM2 ................................................................. 76 Ilustración 92 GTPA 013 ................................................................................ 77 Ilustración 93 GPS en exteriores Logroño. ..................................................... 78 Ilustración 94 GPS en interiores ..................................................................... 78 140 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 95 Librerias Para Arduino ............................................................. 79 Ilustración 96 Librerias Arduino ...................................................................... 80 Ilustración 97 Coordenadas UR ..................................................................... 82 Ilustración 98 Calibración Compass ............................................................... 92 Ilustración 99 Calibración Compass. .............................................................. 92 Ilustración 100 Internet Shield .......................................................................... 2 Ilustración 101 Arduino Ethernet ...................................................................... 2 Ilustración 102 Ardupilot ................................................................................... 3 Ilustración 103 Panel de Control ...................................................................... 4 Ilustración 104 Administrador de dispositivos................................................... 5 Ilustración 105 Administrador de dispositivos desinstalamos ........................... 5 Ilustración 106 Sensor humedad DHT 11 ........................................................ 7 Ilustración 107 Arduino - Sensor humedad DHT11 ......................................... 7 Ilustración 108 Adaptador Arduino de los MQX................................................ 8 Ilustración 109 Serie MQX ................................................................................ 9 Ilustración 110 Arduino Serie MQX .................................................................. 9 Ilustración 111 Serial ...................................................................................... 16 Ilustración 112 USB logo ................................................................................ 16 Ilustración 113 Patillaje................................................................................... 18 Ilustración 114 Zona Fresnel .......................................................................... 19 Ilustración 115 Módulos alámbricos vs. Inalámbricos. ................................... 19 Ilustración 116 Serie 1 .................................................................................... 21 Ilustración 117 Serie 2 .................................................................................... 21 Ilustración 118 Xbee ....................................................................................... 22 141 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 119 Redes Xbee ........................................................................... 23 Ilustración 120 Trama Xbee ........................................................................... 26 Ilustración 121 Comparativa wifi Zig Blue ....................................................... 28 Ilustración 122 Usos ZigBee ........................................................................... 29 Ilustración 123 Comparativa con la serie PRO ............................................... 30 Ilustración 124 Digi Logo ................................................................................ 31 Ilustración 125 Timeline.................................................................................. 32 Ilustración 126 Cuenta de google timeline ..................................................... 33 Ilustración 127 Publicación web ..................................................................... 34 Ilustración 128 Resultado del código .............................................................. 34 Ilustración 129 GPS 3DR ............................................................................... 35 Ilustración 130 GPS GTPA 010 ...................................................................... 35 Ilustración 131 GTPA 013 de Adafruit ............................................................ 36 Ilustración 132 Radiofrecuencias. .................................................................. 40 Ilustración 133 XCTU clásico ......................................................................... 42 Ilustración 134 Versión clásica XCTU ............................................................ 43 Ilustración 135 XCTU clásico ......................................................................... 44 Ilustración 136 XCTU versión 2014 ................................................................ 45 Ilustración 137 XCTU versión 2014 ................................................................ 45 Ilustración 138 XCTU versión 2014 ................................................................ 46 Ilustración 139 XCTU versión 2014 ................................................................ 46 Ilustración 140 XCTU versión 2014 ................................................................ 47 Ilustración 141 XCTU versión 2014 ................................................................ 47 Ilustración 142 XCTU versión 2014 ................................................................ 47 142 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 143 Open Source .......................................................................... 94 Ilustración 144 Logo Arduino .......................................................................... 94 Ilustración 145 Frizting ................................................................................... 94 Ilustración 146 Processing ............................................................................. 94 Ilustración 147 Java ........................................................................................ 94 Ilustración 148 Javascript ............................................................................... 94 Ilustración 149 Html5 Y CSS3 ........................................................................ 95 Ilustración 150 PHP ........................................................................................ 95 Ilustración 151 Aptana Std ............................................................................. 95 Ilustración 152 MySQL ................................................................................... 95 Ilustración 153 SO Linux ................................................................................ 95 Ilustración 154 Distro Ubuntu ......................................................................... 95 Ilustración 155 LESS CSS .............................................................................. 95 Ilustración 156 Eclipse Logo ........................................................................... 95 Ilustración 157 PhP MyAdmin ........................................................................ 95 Ilustración 158 Boostrap d Twitter .................................................................. 95 Ilustración 159 Jquery .................................................................................... 95 Ilustración 160 Json........................................................................................ 95 lustración 161 Open Office ............................................................................. 95 Ilustración 162 Wamp ..................................................................................... 95 Ilustración 163 Gimp....................................................................................... 95 Ilustración 164 Phone GAP ............................................................................ 95 Ilustración 165 Apache ................................................................................... 95 Ilustración 166 EasyPhp ................................................................................. 95 143 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 167 Compatibilidad Navegadores ................................................. 24 Ilustración 168 Compatibilidad Navegadores ................................................. 25 Ilustración 169 Compatibilidad Navegadores ................................................. 25 Ilustración 170 Compatibilidad Navegadores ................................................. 26 Ilustración 171 división de los temas para el KA de las Pruebas de Software68 144 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” FIN DE DOCUMENTO: MEMORIA Eduardo Garbayo Herce Logroño, a 16 de Julio de 2014 145 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 146 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado PROYECTO FIN DE CARRERA: “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” DOCUMENTO Nº2: PLANOS Peticionario: DEPARTAMENTO DE INGENIERÍA ELECTRICA Informantes: Eduardo Garbayo Herce Alumno de Ingeniería Industrial Universidad de La Rioja Lugar y Fecha: Logroño, 12 de Julio de 2014 1 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 2 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 2. PLANOS 2.1 INTRODUCCIÓN Todos los planos y circuitos de este PFC se han generado con el software Open Source Fritzing. Además de los planos exportados en papel, todos los archivos fuente se encuentran en formato digital; lo que da posibilidad de editarlos o hacer nuevas exportaciones. Generar circuitos nuevos, completos, o partes. Así como cambiar formatos para crear ya placas finales. Generar lista de despieces de componentes, e incluso hacer las compras directas del material online. Fritzing fue creado bajo los principios de Processing y Arduino; lo que lo hace el componente perfecto para el pack de este proyecto. Se ha respetado la licencia del software y por ello la marca de agua no ha sido borrada de los circuitos intencionadamente. Ilustración 29 Fritzing 3 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado INDICE DE PLANOS ARDUINO CHECK 2.1.1 LISTA DE ENSAMBLAJE, 2.1.2 LISTA DE COMPRA SONDA DE TEMPERATURA NTC 2.2.1 LISTA DE ENSAMBLAJE 2.2.2 LISTA DE COMPRA SENSOR LDR 2.3.1 LISTA DE ENSAMBLAJE 2.3.2 LISTA DE COMPRA SENSOR LM35 2.4.1 LISTA DE ENSAMBLAJE 2.4.2 LISTA DE COMPRA POTENCIOMETRO 2.5.1 LISTA DE ENSAMBLAJE 2.5.2 LISTA DE COMPRA SISTEMA INALAMBRICO XBEE 2.6.1 LISTA DE ENSAMBLAJE 2.6.2 LISTA DE COMPRA GPS GTPA 013 2.7.1 LISTA DE ENSAMBLAJE 2.7.2 LISTA DE COMPRA GPS GTPA 013 + LM 35 2.8.1 LISTA DE ENSAMBLAJE 2.8.2 LISTA DE COMPRA LDR + LM35 + XBEE + GPS + ARDUINO ETHERNET 2.9.1 LISTA DE ENSAMBLAJE 2.9.2 LISTA DE COMPRA POTENCIOMETRO + GPS + XBEE + ARDUINO 2.10.1 LISTA DE ENSAMBLAJE 2.10.2 LISTA DE COMPRA 4 2.2 ARDUINO CHECK Circuito de comprobación del sistema 2.2.1 LISTA DE ENSAMBLAJE Label Part Type Properties LED2 Red LED - 5mm paquete 5 mm [THT]; leg yes; Color Red (633nm) Parte1 Arduino Board Ethernet Tipo Arduino Ethernet Board VCC1 Battery block 9V Voltaje 9V 2.2.2 LISTA DE COMPRA Amount Part Type Properties 1 Red LED - 5mm paquete 5 mm [THT]; leg yes; Color Red (633nm) 1 Arduino Board Ethernet Tipo Arduino Ethernet Board 1 Battery block 9V Voltaje 9V FECHA NOMBRE Y APELLIDOS 20/05/2014 Eduardo Garbayo Herce COMPROBADO 03/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: Chequeo del Sistema. Baterías, Puerto, Sensor, entradas y salidas. Setup. PLANO Nº 1 2.3 SONDA DE TEMPERATURA NTC 2.3.1 LISTA DE ENSAMBLAJE Label Part Type Properties Parte1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3) R1 10k Ω Resistor R2 Temperature paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio entre pines 400 mil Sensor (Thermistor) resistance at 25° 10kΩ; paquete THT; thermistor type NTC; Tipo thermistor 2.3.2 LISTA DE COMPRA Amount Part Type Properties 1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3) 1 10k Ω Resistor 1 Temperature (Thermistor) paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio entre pines 400 mil Sensor resistance at 25° 10kΩ; paquete THT; thermistor type NTC; Tipo thermistor FECHA NOMBRE Y APELLIDOS 20/05/2014 Eduardo Garbayo Herce COMPROBADO 03/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: Sonda de Temperatura NTC. PLANO Nº 2 2.4 SENSOR LDR 2.4.1 LISTA DE ENSAMBLAJE Label Parte1 Part Type Arduino Properties Board Ethernet R1 Photocell (LDR) R2 10k Ω Resistor VCC1 Battery block 9V Tipo Arduino Ethernet Board paquete THT; resistance@ dark 300 kOhms@ 10 seconds; resistance@ luminance 16 kOhms@ 10 lux paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio entre pines 400 mil Voltaje 9V 2.4.2 LISTA DE COMPRA Amount 1 Part Type Arduino Properties Board Ethernet 1 Photocell (LDR) 1 10k Ω Resistor 1 Battery block 9V Tipo Arduino Ethernet Board paquete THT; resistance@ dark 300 kOhms@ 10 seconds; resistance@ luminance 16 kOhms@ 10 lux paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio entre pines 400 mil Voltaje 9V FECHA NOMBRE Y APELLIDOS 24/05/2014 Eduardo Garbayo Herce COMPROBADO 03/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: Sensor LDR en Arduino Uno PLANO Nº 3 2.5 SENSOR LM35 2.5.1 LISTA DE ENSAMBLAJE Label Part Type Properties Parte1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3) T1 LM35 Temperature Sensor paquete TO92 [THT]; Tipo LM35 VCC1 Battery block 9V Voltaje 9V 2.5.2 LISTA DE COMPRA Amount Part Type Properties 1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3) 1 LM35 Temperature Sensor paquete TO92 [THT]; Tipo LM35 1 Battery block 9V Voltaje 9V FECHA NOMBRE Y APELLIDOS 20/05/2014 Eduardo Garbayo Herce COMPROBADO 03/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: Sensor LM35 de temperatura en Arduino Uno. PLANO Nº 4 2.6 POTENCIOMETRO 2.6.1 LISTA DE ENSAMBLAJE Label Part Type Properties Parte1 Arduino Board Ethernet Tipo Arduino Ethernet Board U1 POT paquete pot_alpha_rv16af-20; variant -rv16af-20 VCC1 Battery block 9V Voltaje 9V 2.6.2 LISTA DE COMPRA Amount Part Type Properties 1 Arduino Board Ethernet Tipo Arduino Ethernet Board 1 POT paquete pot_alpha_rv16af-20; variant -rv16af-20 1 Battery block 9V Voltaje 9V FECHA NOMBRE Y A PELLIDOS 24/05/2014 Eduardo Garbayo Herce COMPROBADO 03/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: Potenciometro en Arduino Ethernet PLANO Nº 5 2.7 SISTEMA INALAMBRICO XBEE 2.7.1 LISTA DE ENSAMBLAJE Label Part Type Properties Parte1 Arduino Board Ethernet Tipo Arduino Ethernet Board U1 XBEE-1 paquete xbee-1_lock; variant xbee-1_lock VCC1 Battery block 9V Voltaje 9V 2.7.2 LISTA DE COMPRA Amount Part Type Properties 1 Arduino Board Ethernet Tipo Arduino Ethernet Board 1 XBEE-1 paquete xbee-1_lock; variant xbee-1_lock 1 Battery block 9V Voltaje 9V FECHA NOMBRE Y A PELLIDOS 24/05/2014 Eduardo Garbayo Herce COMPROBADO 05/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: Xbee en Arduino Ethernet PLANO Nº 6 2.8 GPS GTPA 013 2.8.1 LISTA DE ENSAMBLAJE Label Part Type Properties GPS1 Adafruit Ultimate GPS Breakout Parte1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3) VCC1 Battery block 9V Voltaje 9V 2.8.2 LISTA DE COMPRA Amount Part Type Properties 1 Adafruit Ultimate GPS Breakout 1 Arduino Uno (Rev3 Tipo Arduino UNO (Rev3) 1 Battery block 9V Voltaje 9V FECHA NOMBRE Y A PELLIDOS 24/05/2014 Eduardo Garbayo Herce COMPROBADO 05/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: GTPA 013. Instalación GPS PLANO Nº 7 2.9 GPS GTPA 013 + LM 35 2.9.1 LISTA DE ENSAMBLAJE Label Part Type Properties GPS1 Adafruit Ultimate GPS Breakout Parte1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3) T1 LM35 Temperature Sensor paquete TO92 [THT]; Tipo LM35 VCC1 Battery block 9V Voltaje 9V 2.9.2 LISTA DE COMPRA Amount Part Type Properties 1 Adafruit Ultimate GPS Breakout 1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3) 1 LM35 Temperature Sensor paquete TO92 [THT]; Tipo LM35 1 Battery block 9V Voltaje 9V FECHA NOMBRE Y A PELLIDOS 24/05/2014 Eduardo Garbayo Herce COMPROBADO 05/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: GTPA 013 + LM 35 PLANO Nº 8 FECHA NOMBRE Y A PELLIDOS 24/05/2014 Eduardo Garbayo Herce COMPROBADO 05/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: GTPA 013. + LM 35 PLANO Nº 8.1 2.10 LDR + LM35 + XBEE + GPS + ARDUINO ETHERNET 2.10.1 LISTA DE ENSAMBLAJE Label GPS1 Part Type Adafruit Properties Ultimate Breakout Parte1 Arduino Uno (Rev3) R3 10k Ω Resistor R4 Photocell (LDR) T1 GPS LM35 Temperature Sensor Tipo Arduino UNO (Rev3) paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio entre pines 400 mil paquete THT; resistance@ dark 300 kOhms@ 10 seconds; resistance@ luminance 16 kOhms@ 10 lux paquete TO92 [THT]; Tipo LM35 U2 XBEE-1 paquete xbee-1_lock; variant xbee-1_lock VCC1 Battery block 9V Voltaje 9V 2.10.2 LISTA DE COMPRA Amount 1 Part Type Properties Adafruit Ultimate GPS Breakout 1 Arduino Uno (Rev3) 1 10k Ω Resistor 1 Photocell (LDR) 1 LM35 Sensor Temperature Tipo Arduino UNO (Rev3) paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio entre pines 400 mil paquete THT; resistance@ dark 300 resistance@ luminance 16 kOhms@ 10 lux paquete TO92 [THT]; Tipo LM35 kOhms@ 10 seconds; Amount Part Type Properties 1 XBEE-1 paquete xbee-1_lock; variant xbee-1_lock 1 Battery block 9V Voltaje 9V FECHA NOMBRE Y APELLIDOS 20/05/2014 Eduardo Garbayo Herce COMPROBADO 03/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: GPS + LDR + LM35 + XBee PLANO Nº 9 FECHA NOMBRE Y APELLIDOS 20/05/2014 Eduardo Garbayo Herce COMPROBADO 03/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: GPS + LDR + LM35 + XBee PLANO Nº 9.1 2.11 POTENCIOMETRO + GPS + XBEE + ARDUINO 2.11.1 LISTA DE ENSAMBLAJE Label Part Type Properties GPS1 Adafruit Ultimate GPS Breakout Parte1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3) U2 XBEE-1 paquete xbee-1_lock; variant xbee-1_lock U3 POT paquete pot_alpha_rv16af-20; variant -rv16af-20 VCC1 Battery block 9V Voltaje 9V 2.11.2 LISTA DE COMPRA Amount Part Type Properties 1 Adafruit Ultimate GPS Breakout 1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3) 1 XBEE-1 paquete xbee-1_lock; variant xbee-1_lock 1 POT paquete pot_alpha_rv16af-20; variant -rv16af-20 1 Battery block 9V Voltaje 9V FECHA NOMBRE Y APELLIDOS 20/05/2014 Eduardo Garbayo Herce COMPROBADO 05/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: GPS + XBee + Potenciometro PLANO Nº 10 FECHA NOMBRE Y APELLIDOS 20/05/2014 Eduardo Garbayo Herce COMPROBADO 05/07/2014 Eduardo Garbayo Herce DIBUJADO GRUPO ESCALA UR - PFC - Supervisión remota de parámetros medioambientales capturados por UAV PFC – ARD – UAD - 0001 DENOMINACIÓN DEL PLANO: GPS + XBee + Potenciometro PLANO Nº 10.1 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” FIN DE DOCUMENTO: PLANOS Eduardo Garbayo Herce Logroño, a 16 de Julio de 2014 2 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado PROYECTO FIN DE CARRERA: “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” DOCUMENTO Nº3: ESPECIFICACIONES DEL SISTEMA Peticionario: DEPARTAMENTO DE INGENIERÍA ELECTRICA Informantes: Eduardo Garbayo Herce Alumno de Ingeniería Industrial Universidad de La Rioja Lugar y Fecha: Logroño, 12 de Julio de 2014 1 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 2 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3. ESPECIFICACIONES DEL SISTEMA 3.1 CONFIGURACIONES BÁSICAS La configuración, setup del entorno de Processing será muy sencilla, ya que el programa viene preconfigurado para realizar las funciones de ejemplo sin tener que hacer dependencias o instalaciones de SDKs complejas. Se explicarán en este documento las librerías extras que se necesitarán para compilar este código, así como instalarlas. Se adjuntarán también una lista de errores comunes, FAQ; y como solucionarlos. Por defecto habrá que cargar y compilar el programa cada vez que se requiera su ejecución si es que se ha cambiado de ordenador o configuraciones extra en el hardware del sistema. Como se explica al final del documento, se está trabajando con una versión Alfa de desarrollo. Para la exportación de código sí que se requerirá una configuración extra, ya se trate para destinos como Android, JavaScript, Windows 32bits, 64bits, etc. 3.2 CONFIGURACIÓN PUESTA EN MARCHA DEL DRONE La denominación «vehículo aéreo no tripulado», de siglas «VANT», proviene del inglés «Unmanned Aerial Vehicle», de siglas «UAV». Es también muy usada la denominación «sistema aéreo no tripulado», de «Unmanned Aerial System» y de siglas UAS. Más extendido es el término inglés «drone» (literalmente zángano), que puede asimilarse como palabra española con el singular «dron». En este proyecto el Drone en sí mismo solo será el vehículo, el medio usado para montar las placas Arduino y proceder a su captura de datos. Perfectamente para algunos casos se podrían usar vehículos terrestres de buena tracción para la recogida de datos, pero como objetivo final, se ha pensado en usar un Drone para poder acceder a lugares más remotos e inaccesibles para un vehículo terrestre. Como pudieran ser mediciones de polinización a una altura de 3 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado terminada en campo abierto, o hacer un muestreo de picos de humos en un incendio… etc. Ilustración 30 Octocopter Ilustración 31 Hexacopter Ilustración 32 Cuatricopter Es por tanto el Drone el vehículo a usar y aunque no forma parte de este proyecto su configuración, setup, o modificaciones internas, sí que será importante tener experiencia en el manejo de estos aparatos. Dentro de las gamas de cuatricópetros que oferta el mercado actual habrá que saber discernir claramente entre lo que es considerado un juguete y lo que 4 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado empieza a ser aeromodelismo amateur, y posterior uso de aeromodelismo avanzado para uso comercial. Es decir, uso de Drones para tomas fotográficas, video aéreo, mediciones, vigilancia, etc. En este punto es donde se encuentra este proyecto y el uso que se va a dar a los Drones. Existen en el mercado a nivel de “juguetes” o “aficionado” un boom de pequeños drones en venta por el que los amantes al aeromodelismo van pasando hasta llegar a equipos más profesionalizados: Suelen ser equipos de corcho o poliestireno expandido que controla vía BlueTooth o Wifi con nuestros dispositivos móviles (teléfonos, tabletas, etc ) . Tiene un alcance máximo de 50 metros y están preparados para volar en interiores y sin nada de viento. No pueden cargar absolutamente nada de peso. Este mercado se ha extendido en los últimos años, pero también el siguiente escalón donde ya se encuentran cuadricópteros pequeños que ya pueden volar en exteriores cuando las condiciones atmosféricas sean positivas. Como se indica, todavía estas configuraciones son equipos enfocados a juegos y son aptos para casi todos los públicos. Las aspas van cubiertas, suelen ser de plástico blanco y no son relativamente peligrosos. Pero cuando ya se quiere usar algo de carga, por poca que sea, hasta 250 gramos, y volar en exteriores los equipos a usar ya se disparan en precio, dificultad de vuelo y configuraciones. Dentro de esta gama es en la que se encuentra este proyecto. Se necesita cargar un Drone con una cámara que nos ayudará en el vuelo para posicionamiento, y la placa Arduino con sus respectivos sensores. Incluída una pila de 9v, y una protoboard. Lo que ronde los 200 gramos. En este rango de equipos de vuelo, el autor de este PFC tiene experiencia en el montaje personalizado, customizado y configuración de cuadricópteros de tamaño medio-alto. Como se ha indicado el principio de esta memoria, principalmente en el uso de Kits abiertos de montaje. Se compran elementos compatibles con diferentes configuraciones, IMUS, GPS, etc Se consideran abiertos en el hecho que se pueden combinar marcas y modelos, pero no se tiene acceso a sus datos internos para 5 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado lectura de datos. El acceso y configuración de estos equipos sería otro proyecto en sí mismo. Usando similar equipo del usado para este trabajo, como el Ardupilot Mega 2 como elemento de control. Un Arduino con sensores incorporados que permite el acceso a los datos y configuraciones a bajo nivel. Para este proyecto como se indica el uso del UAD será el elemento soporte para las tarjetas Arduino, GPS, cámaras, etc. Dentro de esta gama de vehículos comerciales de uso cerrado se optará por mostrar el trabajo en dos equipos de alta gama. Uno construido a mano, y que permite ciertas configuraciones, así como de una alta capacidad de carga, puesto que está basado en un kit muy potente de vuelo. Se podría enfocar el uso de este Drone a las tareas más complejas o que requieran más tiempo en vuelo con estabilidad contrastada con pesos cercanos a los 500 gramos de carga. Por otro lado se mostrará un Drone comercial preconfigurado y estabilizado de serie para labores menores. Aún así estamos hablando de alturas aproximadas a 300 metros y distancia horizontal superior en campo abierto bajo condiciones atmosféricas benévolas. Aunque estos drones vengan de serie con unas estabilizaciones básicas habrá que proceder a hacer una calibración instu cada vez que el Drone vaya a alzar el vuelo. Este ajuste requiere de unos minutos ineludibles que no deben ser obviados puesto que se pondrá el riesgo el equipo en vuelo y principalmente todos los usuarios cercanos a éste. Un equipo sin un buen ajuste se puede desconfigurar en vuelo aunque las condiciones atmosféricas y ambientales sean positivas. Otros datos como el posicionamiento de salida o “home” quedan registrados para hacer aterrizajes de emergencia y traer al Drone a un punto fijo prefijado en caso de pérdida visual o cualquier otro tipo de problema mecánico. La configuración o setup básica del Drone se tiene que hacer cada vez que se ponga en marcha el equipo. Sólo serán necesario actualizaciones o configuraciones bajo software externo en casos concretos. 6 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.2.1 SOFTWARE DE CONFIGURACION Ambos equipos, ya sean los montados manualmente a base de Kits, como el equipo cerrado de la serie Phantom usan software específico de setup de los componentes internos. Aunque no se dispone de acceso a los datos internos o secuencias de control, desde el software, el usuario avanzado podrá calibrar parámetros como GPS, IMU, emisora TX etc. Estas configuraciones habrá que hacerlas cada vez que el equipo sufra un “aporrizaje” o aterrizaje forzoso. Así como si hay cambio de motores u otro tipo de componentes. Cualquier movimiento extraño en vuelo, desconfiguración, trayectorias erróneas, no home automático, o posicionamientos incorrectos será buen momento para realizar una setup del equipo. Se recomendará también el Pliego una serie de condiciones básicas y revisiones cada determinadas horas de vuelo. Ilustración 33 Naza setup 7 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.3 ARDUINO Se dividen las condiciones y de uso de Arduino en su versión Hardware y Software. 3.3.1 PUESTA EN MARCHA Para arrancar la placa Arduino bastará conectarla a la alimentación necesaria. Se puede usar una pila de 9V si se desea que el sistema sea autónomo y libre de cables. Si se trabaja en modo local, se alimentará con un transformador con un máximo de 12v y un mínimo de 7v. Si el software ha sido cargado el Arduino ya está listo para funcionar, si no ha sido así, se debe enviar el programada desde el IDE del ordenador al Arduino por el puerto usb. Éste hace de alimentación propia y no será necesario tener fuentes de energía alternativas. Existen como se ha indicado Arduinos que soportan también alimentación PoE38. Ilustración 34 Pila 9v 3.3.2 PUERTO SERIE La comunicación entre la placa Arduino y el IDE en el ordenador será por el puerto USB. Este puerto se asigna cada vez que se usa el Arduino y se conecta al ordenador. Dependerá de cada sistema operativo usado: Linux, o Windows. E incluso dentro de cada sistema, será diferente también de cada versión. Incluso puede cambiar en cada arranque del ordenador. Por ello, habrá que consultar siempre el Panel del Control de los sistemas Operativos para comprobar el puerto 38 Alimentación a través de Ethernet Power over Ethernet. 8 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado serie usado y asignarlo al IDE del Arduino para que así pueda comunicar. Se explica como hacer este tipo de pruebas, así como todos los problemas que puedan surgir al usuario al realizar este intercambio de información. 3.3.3 IDE DE ARDUINO Desde la página oficial de Arduino39 se descarga de forma GRTUITA el Entorno de Desarrollo Integrado, llamado también IDE (en inglés de integrated development environment). Esto será el software que será capaz de comunicar nuestros drivers con la tarjeta. El IDE de este sistema es muy completo y viene con una serie de ejemplos que hará que trabajar con él sea gratamente satisfactorio. El sistema está basado en C++ y su programación es muy similar en cuanto al uso de bucles, funciones y variables. El sistema incluirá una serie de comandos especiales para el uso específico de puertos y características de la tarjeta. Dado la cantidad de ejemplos y tutoriales online la curva de aprendizaje será relativamente sencilla para todos aquellos que tengan estructura su forma de programación de alto nivel. 3.3.4 INSTALACIÓN EN WINDOWS XP-7-8-8.1 El paquete descargado tiene dos opciones de instalación. Una versión portable y una setup. Se han probado ambas versiones y no existen grandes diferencias de estabilidad. Si bien es cierto, que las versiones portables dan problemas en Windows cuando se hace limpieza de ordenadores en los registros o archivos temporales. Cachés etc Este software ha sido probado por el autor en Windows xp sp3, Windows 7, Windows 8.1 Funcionando de forma similar en todas las particiones. 39 http://arduino.cc/ 9 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 35 Arduino en modo portable 3.3.5 INSTALACIÓN EN LINUX - UBUNTU Para distribuciones estándar de Linux se haría: cd $HOME wget http://Arduino.googlecode.com/files/Arduino-1.0.5-linux64.tgz tar xzvf Arduino-1.0.5-linux64.tgz rm -R Arduino-1.0.5-linux64.tgz Probando el puerto USB dmesg | grep ttyACM Ahora habría que darle permisos suficientes al puerto ttyACM0 sudo chmod 666 /dev/ttyACM0 cd $HOME/Arduino-1.0.5 Y a continuación lo ejecutamos! ./Arduino En este caso se ha instalado a través de una distribución Linux Ubuntu 13, y se ha usado el sistema de descarga oficial de la distro. Ubuntu Software Center. Siendo tan sencillo como teclear “Arduino” e instalar. 10 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 36 Software Center 3.3.6 DRIVERS DE ARDUINO. Si los DRIVERS que si no se instalan automáticamente al conectar el Arduino por primera vez habrá que acudir a las páginas de los respectivos fabricantes e instalarlos a mano. 3.3.7 PUERTOS SERIE. Se comprueba que la instalación ha sido correcta. Aquí se conocerá que puerto serie ha sido el adjudicado para Arduino. Se ve en este caso que es el COM8. No siempre será así, y cada vez que se cambie cualquier configuración habrá que consultarlo. Este dato es imprescindible para la setup del IDE. Ilustración 37 Puertos serie usados por Arduino 11 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.3.8 PROBLEMAS DE INSTALACIÓN. IDE, DRIVERS, ETC Siempre que se trabaja con HardWare-Software-Librerías-Drivers surgen problemas. Más aun cuando se trata de Open Source, donde los fabricantes de los dispositivos son de diferentes compañías. Son entornos abiertos y siempre habrá que tener cuidado con las versiones que se usan de los entornos de desarrollo. Drivers, Librerías usadas. Leer las características de cada versión y trabajar siempre con versiones estables. Aun así, los quebraderos de cabeza serán continuos en todo proyecto que aúne hard+soft. 3.3.9 NO DETECTA DRIVERS Como se ha indicado Windows - Linux se conectan a internet por primera vez cuando se conecta una tarjeta Arduino para la instalación automática de drivers. En la mayoría de los casos la instalación es instantánea, pero cuando esto no sucede: Si no se instalan automáticamente: hacerlo desde el Panel de Control de Windows y añadirlos manualmente. Los Drivers están en la carpeta de instalación de Arduino/Drivers. Basta con indicar esta ruta y el sistema los buscará e instalará. A veces como se indica esto no es suficiente, así ha sido el caso de la placa Arduino Ethernet. El resto de placas probadas, Ardupilot, Mini, Uno, no han dado problemas. Pero como se indica la placa Ethernet lleva un software especial para la comunicación del puerto serie y ha habido que acudir en algunas ocasiones a la web original del fabricante FTDI.40 Esta placa lleva un sistema externo para la carga de programas vía usb, que luego se desconecta para dejar la placa Arduino cargada y funcionando, reduciendo peso. 40 http://www.ftdichip.com/Drivers/VCP.htm 12 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 38 FTDI para serie Se descarga el software y nos da un aviso de todo ok : Ilustración 39 FTDI sofware drivers 3.3.10 PUERTO OCUPADO Los puertos COM de Windows se asignan según se conectan dispositivos al ordenador: ratón, impresora, teléfono, etc. Suele coger el puerto 8 en winXP, a veces el 5 en Windows 7; depende partición. En ocasiones dice que el puerto está ocupado y no compila. Se soluciona quitando Arduino instalando otro dispositivo de usb; sacándolo, reiniciando el sistema, y colocando Arduino en otro puerto usb. A veces el problema es del propio cable USB. – Tamaño, longitud, calidad del cable - Cambiar de cable e intentarlo de nuevo. 13 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Principalmente este ha sido el problema más común tanto en Windows, como en Linux. 3.3.11 MUY LENTO EL IDE BAJO WINDOWS 7 En ocasiones el entorno IDE se ralentiza en Windows 7. Le cuesta entrar al menú y el ratón va como a golpes. Le cuesta abrir cualquier pestaña. Acudir a Anejo correspondiente porque la solución es larga y compleja. 3.3.12 ARRCANCA LA IDE DE ARDUINO En el software Arduino se coloca el puerto que nos haya dicho el Panel de Control Ilustración 40 Puerto Seleccionado y la versión de la tarjeta . Ethernet en este caso Ilustración 41 Tarjeta Seleccionada 14 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado También usarán ambas versiones de Aruino Mega. 1, 2, ardupilot. 3.3.13 USO DE LA SHIELD ETHERNET Ethernet permite a la placa Arduino de conectarse a Internet. Puede funcionar tanto como servidor capaz de aceptar conexiones entrantes, como cliente permitiendo realizar conexiones de salida. La configuración viene determinada por una librería específica de Arduino 3.3.14 LIBRERÍAS PARA ARDUINO Será la primera de las varias librerías que habrá que instalar para incrementar las capacidades de nuestro Arduino. En este caso, instala en esta librería varias opciones para el trabajo en red, y salir a internet. Así como diferentes propuestas para escribir o leer datos. Las librerías para Arduino son gratuitas y de uso Open Source. Están escritas en C++ e incluso se permite el hacer modificaciones en ellas. Los códigos fuentes están disponibles. En las versiones más actualizadas del IDE de Arduino la librería “serie” ya viene instalada por defecto. Más adelante se usarán otras librerías que habrá que instalar y se explica cómo hacerlo, pero se entiende que si se usa el IDE de Arduino se hará con esta versión indicada o en su defecto con una superior. 15 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 42 Librería Ethernet en C++ 3.3.15 CONFIGURANDO LA RED EN MODO LOCALHOST E INTERNET DIRECTO Lo primero será conocer las IP´s del ordenador que hará como servidor de información. Permitiendo conectar a Arduino a un ordenador en modo local o en un servidor de internet vía Router. Se Abre una ventana de ejecución a través de Inicio. Ejecutar o pulsando las teclas “Windows” + <R> simultáneamente. En la línea que se ha abierto, teclee “cmd” y pulse la tecla <Intro> Se abrirá una ventana con fondo negro como esta. 16 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 43 ipconfig Se teclea lo siguiente en la pantalla “ipconfig” y pulsa la tecla <Intro> Ilustración 44 Resultados de IpConfig Se pueden re-utilizar los datos siguientes: La dirección IP (IP Address): Se suman 10 al número final [*], en este caso: 192.168.1.34 (34+10) = 44 192.168.1.44 o 92.168.1.34 17 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado La máscara de red (Network mask) : 255.255.255.0 La dirección del router (default gateway) : 192.168.1.1 (*) Normalmente los routers asignan las direcciones automáticamente, al sumar 10 se intenta no re-utilizar ninguna de las que su router haya asignado a los equipos de casa (portátiles, puestos fijos, etc). Si no tiene más de 10 equipos en casa; esto debería funcionar. Se muestra a continuación ya los datos, tal y como se usarán en código bajo Arduino. Variables en formato Byte. Este código ya es funcional e interpretable por el IDE. byte mac[] = { 0x00, 0xAA, 0x00, 0xAA, 0x00, 0xAA }; // Una dirección MAC . Cualquiera es válida si no existe ya dentro de su red, byte ip[] = { 192, 168, 1, 34 }; //La dirección IP asignar a la placa Arduino Ethernet byte gateway[] = { 192, 168, 1, 1 }; // La dirección de su router en la red byte subnet[] = { 255, 255, 255, 0 }; // La máscara de red En las redes de computadoras, la dirección MAC (siglas en inglés de media access control; en español "control de acceso al medio") es un identificador de 48 bits (6 bloques hexadecimales) que corresponde de forma única a una tarjeta o dispositivo de red. Se conoce también como dirección física, y es única para cada dispositivo. Está determinada y configurada por el IEEE. Las direcciones MAC son únicas a nivel mundial, puesto que son escritas directamente, en forma binaria, en el hardware en su momento de fabricación. Debido a esto, las direcciones MAC son a veces llamadas burned-in addresses, en inglés. 18 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Si necesitara mi propia imac. Tecleo en windows CMD. luego ipconfig/all (if config bajo Linux). Ilustración 45 MAC personal Subred La dirección física real: 6C- F0-49-73-97-8B (ordenador de sobremesa casa) byte mac[] = { 0x6C, 0xF0, 0x49, 0x73, 0x97, 0x8B }; //no me hará falta. La MAC de mi Arduino Ethernet- (Mayo 2014) : 90-A2-DA-0D-69-DB viene escrita debajo de la tarjeta. byte mac_Arduino[] = { 0x90, 0xA2, 0xDA, 0x0D, 0x69, 0xDB }; En resumen; lo que se ha conseguido aquí es identificar las direcciones dinámicas y físicas de los dispositivos que se van a usar en la red. Las MAC físicas de ordenadores y placa Arduino. Las IP de routers, y ordenadores locales en red. Las IP de servidores en internet ya se conocen e incluso se podrá usar nombre reales www.google.es y la propia librería devuelve la IP dando como resultado conexiones estables. El software Arduino con su librería Ethernet a través de DHCP (siglas en inglés de Dynamic Host Configuration Protocol, en español «protocolo de configuración dinámica de host») que es un protocolo de red que permite a los clientes de una red IP obtener sus parámetros de configuración automáticamente, localiza Arduino y le asigna una IP fuera de la red para no tener problemas. Este código básico y funcional se encuentra en el Anejo correspondiente. Se 19 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado recomienda usar este código para asignar la dirección IP al Arduino y así se ha hecho en este proyecto. Una vez conocidas y configuradas las direcciones de servidores ya sea en modo local o directamente internet, Arduino puede usar instrucciones de código similar al usado en http para hacer peticiones. Y también instrucciones de PHP como GET y POST. client.println("HTTP/1.1 200 OK"); client.println("<body><html>"); client.println("Content-Type: text/html"); client.println("<meta http-equiv='Refresh' content='0;url=xxx'>"); client.println("</body></html>"); client.println("Host: www.google.com"); client.println("GET http://zainder.com/arduino/arduino.txt"); client.println("GET http://zainder.com/arduino/arduino-get.php?temperatura="); client.println( variable ) Diferentes colores para mostrar diferentes tipos de peticiones. Este código pertenece a un programa mayor que se cargará en Arduino y que se adjunta tanto en formato digital como en el Anejo correspondiente. Estas instrucciones son imprescindibles comprender para tener comunicación ya sea con el ordenador en localhost, o cualquier otro ordenador en red. Si se desconoce el lenguaje de programación PHP no se puede usar este sistema de comunicaciones, que es imprescindible su uso. Aparte de tener el Arduino programado para realizar peticiones GET, POST, y otras http, es imprescindible que esos ficheros .php existan. Arduino por sí mismo no hace nada si no ejecutar dicho código. Previamente se habrán creado, probado, e instalado esos scripts. La ejecución de este código es el puerto serie de Arduino. Requerirá una configuración mínima. 20 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado void setup() { Serial.begin(9600); Serial1.begin(38400); Serial2.begin(19200); Serial3.begin(4800); Serial.println("Hola ordenador"); Serial1.println("Hola Serial 1"); Serial2.println("Hola Serial 2"); Serial3.println("Hola Serial 3"); } Ilustración 46 Puerto Serie a 9600 3.3.15.1 CONFIGURACIÓN DEL ROUTER Con el ordenador conectado al router y el Arduino conectado al router en otro puerto se comprueba cual es la ip del Arduino. Tiene su propio script para ello → 192.168.1.33 – resultado. Luego con ipconfig se la IP de ordenador. 21 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ipv4.192.168.1.34 Se comprueba que está el puerto 80 abierto para usarlo de servidor. Se deben modificar parámetros en el router. Acceder al router por http://192.168.1.1 Seleccionar la opción del menú de la izquierda: 'NAT -> Reenvio de Puertos. Se muestra 'Configuración de Servidores Virtuales'. Pulsar en “Añadir”. Marcar la casilla “Seleccionar un Servicio” y buscar en el desplegable si la aplicación ya está predefinida, si no aparece, marcar “Servidor personalizado“ y escribir el nombre de la aplicación en el espacio en blanco. En 'Dirección IP del Servidor', introducir la IP asignada a la red. Se puede obtener, si se desconoce, mediante el comando ipconfig desde la consola de DOS de Windows (Inicio -> Ejecutar -> cmd) o ifconfig desde terminal GNU/Linux. Se obtiene en la línea 'Dirección IP', y sería algo así como 192.168.1.x Seleccionar en el desplegable el tipo de puerto a abrir (TCP o UDP). En 'Puerto Externo inicial' introducir el puerto a abrir y en 'Puerto Externo Final' el mismo (si se desea abrir un rango consecutivo de puertos, en ese caso el inicial sería el más bajo y el final el más alto). Este mismo paso para todos los puertos deseados. Pulsar en Salvar. 22 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 47 Accediendo al Router Ilustración 48 Configurando puertos 3.4 CONVERTIR EL ORDENADOR EN UN SERVIDOR Para poder trabajar con bases de datos, y código en ejecución se debe tener el sistema configurado para tal efecto. Se podrá convertir cualquier PC con unas características mínimas de disco duro, ram, y cpu en un servidor local. Cualquier ordenador menor de 10 años, basado en un sistema Pentium servirá para tal efecto puesto que las condiciones de estos sistemas no son muy restrictivas. Siempre será recomendable el uso de ordenadores potentes, ya que el mismo ordenador además de trabajar en modo servidor, también estará ejecutando otro tipo de programas como Processing, y también compaginará el uso de red wifi para hacer live streaming etc, 23 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Las versiones necesarias para funcionar también serán las mínimas y aunque se recomienda siempre trabajar con versiones actualizadas que serán las recomendadas como: Ilustración 49 Versiones recomendadas Se puede instalar cada aplicación por separado o usar un software que instale simultáneamente todo lo que se necesita para convertir un PC estándar en un servidor. 3.4.1 CREACIÓN DE UN WAMP Se podrán usar softwares como wamp, easyPhP, xampp, phptriad,, etc si lo que se requiere es instalar todo en una sola aplicación. En el ordenador principal de trabajo se ha usado el software EasyPHP. Ilustración 50 EasyPHP 3.4.2 CREACIÓN DE UN LAMP Por defecto en los servidores remotos se trabajará con LAMP. Más concretamente bajo CentOS41. Uno de los sistemas más estables del mercado. 41 Community ENTerprise Operating System – Basado en Red Hat 24 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado En modo local si se es usuario de Linux, o de Mac se recomienda trabajar con Xampp, que instala el paquete completo: MySQL, PHP y Perl. Ilustración 51 Paquetes completos para otros sistemas 3.4.3 COMPROBACIÓN Para estar seguros que la instalación es correcta, pues acontece que cuando se instalan estos sistemas nunca sucede nada; ya que corren en segundo plano. Será importante saber que todo ha ido correctamente cada vez que queramos que el ordenador trabaje en modo servidor. Accediendo o tecleando “localhost” o “127.0.0.1” en cualquier navegador el sistema nos devuelve los archivos que se tengan en la carpeta de trabajo. Que será diferente dependiendo del sistema instalado. Algunos la instalan en el directorio raíz, bajo el nombre “www” y en el caso que se está trabajando para este proyecto se encontrará en la carpeta propia del programa en el directorio “scripts”. Que devuelva una información y no solo visual al acceder a esta carpeta significa que se está bajo un trabajo dinámico. Se crea un fichero básico para comprobación de qué se están haciendo bien todos los pasos. Es un fichero de texto que copiamos en nuestro ordenador cuando éste, trabaje como localhost. Es decir, que tenga instalado: Apache. 25 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 52 Lectura correcta de un fichero en modo local. Localhost. Este es el fichero que se usará continuamente para hacer las pruebas con Arduino. Antes de escribir o ejecutar código php, o peticiones http, se comprobará mediante este archivo que todo va desarrollándose correctamente. Este mismo archivo de texto plano se clonará en diferentes servidores de internet. 3.4.4 COMUNICACIÓN BÁSICA- COMPROBACIONES Siempre, antes de ejecutar un código completo, se comenzará con pruebas básicas de control. Ficheros demo que bajo resultado positivo permitan avanzar a la ejecución de mayores líneas de código; y es que las configuraciones pueden jugar una mala pasada y pensar que el error está en otro apartado. 3.4.5 CODIGO BASICO PARA ENVIAR DATOS VIA ETHERNET CON GET A UNA SQL El php que coge datos desde formulario es : mysql_query("INSERT INTO $tabla_BD ($campo1 ,$campo2, $campo3) VALUES ('$_GET[temperatura_desde_formulario]' , now() , curtime() ) " , $conecta ); Código que está dentro del archivo llamado Arduino-get.php en la carpeta: http://localhost/scripts/envio%20datos%20a%20sql%20por%20formulario/ La variable que recibe desde el formulario se llama temperatura_desde_formulario y el submit se llama ingresar_dato. 26 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado <form action="arduino-get.php" method="get"> <table border="0" width="331"> <tbody> <tr> <td width="137">temperatura a ingresar</td> <td width="184"><input name="temperatura_desde_formulario" type="text"></td> </tr> <tr> <td>Ingresa este Dato</td> <td><input name="ingresar_dato" type="submit"></td> Ilustración 53 Dato desde formulario en php El resultado de esta petición vía GET o POST nos da la siguiente línea de código que es la que se debe que trasladar al Arduino para que su ejecución: http://localhost/scripts/envio%20datos%20a%20sql%20por%20formulario/Ard uino-get.php?temperatura_desde_formulario=5544&ingresar_dato=Submit 3.5 ENVÍO DE DATOS DESDE ARDUINO A PROCESSING VIA SERIAL Se utiliza para la comunicación entre la placa Arduino y un ordenador u otros dispositivos. Todas las placas Arduino tienen al menos un puerto serie (también conocido como UART o USART): Serial. Se comunica a través de los pines digitales 0 (RX) y 1 (TX), así como con el ordenador mediante USB. Por lo tanto, si utiliza estas funciones, no puede usar los pines 0 y 1 como entrada o salida digital. 27 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Algunas placas usadas como Arduino Mega; Ardupilot tiene tres puertos adicionales de serie: Serial1,2,3 (desde el 14 al 19 RX y TX) Para utilizar estos pines para comunicarse con el ordenador personal, necesitará un adaptador USB adicional a serie, ya que no están conectados al adaptador USB-Serie de la placa Arduino Mega. Para comunicarse con un dispositivo serie externo TTL, conecte el pin TX al pin RX del dispositivo, el RX al pin TX del dispositivo, y el GND de tu Arduino Mega a masa del dispositivo. (No conecte estos pines directamente a un puerto serie RS232, que operan a +/- 12V) Conexión bajo normativa RoHS. - RoHS Directive 2011/65/EU Para la conexión de Arduino Mega2 se usarán USB CA y DKU Ilustración 54 Arduino Mega 1-2 Para el Arduino Uno , también usado en parte en este proyecto se usará un USB 2.0 tipo A-B ( AM BM ) Ilustración 55 USB para Arduino Uno La conexión Arduino Ethernet usa un cable estándar USB – miniUSB 28 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 56 USB miniUSB Durante todo este trabajo toda la comunicación serial estará establecida a 9600 baudios. Entre Arduino y Processing. Entre GPS y Arduino La red inalámbrica 3DR. La red inalámbrica Xbee. Todos bajo 9600. Configurados y guardados todos los datos en sus setups correspondientes. Uso del Puerto Según la documentación, Serial.print (valor, BYTE) convierte el valor en el carácter ASCII que le corresponde, y envía ese dato. Por lo tanto, es válido solamente para los valores que están en el rango de 0 a 255. Serial.write, por otra parte, transmite el patrón de bits de valor. Por lo tanto, se envía cualquier valor de un byte como es. Interrupciones Subrutinas Checksums 3.5.1 DESDE PHP File: php_serial.class.php Role: Class source Content type: text/plain Description: The class itself 29 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Class: PHP Serial Communicate with a serial port <?php include "php_serial.class.php"; // Let's start the class $serial = new phpSerial; // First we must specify the device. This works on both linux and windows (if // your linux serial device is /dev/ttyS0 for COM1, etc) $serial->deviceSet("/dev/ttyUSB0"); // Then we need to open it $serial->deviceOpen(); $read = $serial->readPort(); // If you want to change the configuration, the device must be closed $serial->deviceClose(); // We can change the baud rate $serial->confBaudRate(9600); echo $read; ?> 30 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6 INSTALACIÓN DE SENSORES Como sensores de prueba se instalarán unos sensores básicos, que aun siendo muy sencillos de añadir a Arduino, requerirán unos circuitos mínimos de adaptación de señal, y un código de conversión en Arduino hasta obtener valores que se den por válidos. Sensor de Temperatura NTC y LM35. Sensor LDR, potenciómetros; y posteriormente no son sensores pero los GPS que se emplearán requerirán una configuración determinada que se acompaña en este documento de Especificaciones. 3.6.1 ENTRADAS. SALIDAS PVM. Al trabajar con sensores externos a Arduino que habrá que instalar se deberá estudiar a conciencia cómo funciona el sistema, que lecturas soporta, o escribe, ¿dónde? ..etc. Gracias a la comunidad online, no se dilatará mucho aquí la explicación ni la documentación. Se hará un simple repaso de las condiciones básicas de funcionamiento de las entradas y salidas que se necesitan para dicha instalación. El funcionamiento de las entradas y salidas digitales será trivial. Las entradas analógicas darán valores de rango 1024. Desde 0 a 1023 Y habrá que tener en cuenta que Arduino no dispone de salidas analógicas como tal, pero tiene unas salidas digitales marcadas con un símbolo especial indicando una senoidal “~” o con las siglas PWM que permiten configurar su valor entre 0-255. Con ello ya se puede emular una salida analógica. 31 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado La Modulación por Ancho de Pulso (PWM42 = Pulse Width Modulation) es una tecnica para simular una salida analógica con una salida digital. El control digital se usa para crear una onda cuadrada, una señal que conmuta constantemente entre encendido y apagado. Este patron de encendido-apagado puede simular voltajes entre 0 (siempre apagado) y 5 voltios (siempre encendido) simplemente variando la proporción de tiempo entre encendido y apagado. A la duración del tiempo de encendido (ON) se le llama Ancho de Pulso (pulse width). Se aconseja chequear con el siguiente código que las entradas y salidas que se usarán para aplicaciones más complejas están en orden. Es el “hello world” de este apartado.. // incrementar la luz de un led de 0 a 255. es decir, convertir salida digital en analogica. int led = 6; // solo puedo EMULAR algunos puertos como señales analogicas de salida. la 3, la 6, lo marca cada placa con la señal senoidal int brillo =0; // the setup void setup() { // initialize the digital pin as an output. pinMode(led, OUTPUT); } // the loop routine void loop() { //a brillar se ha dicho. for ( brillo =1; brillo <= 255; brillo ++ ) { analogWrite ( led , brillo ); // enciendo el led desde 0 a 255. delay(10); // wait } //al reves. se va apagando for ( brillo =255; brillo > 1; brillo -- ) { analogWrite ( led , brillo ); // enciendo el led desde 0 a 255. delay(10); // wait } } 42 http://arduino.cc/es/Tutorial/SecretsOfArduinoPWM 32 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6.2 POTENCIOMETRO Se instalará un potenciómetro como simulador de señales analógicas. A nivel de hardware de Arduino se en la imagen que solo necesita 3 conexiones: Ilustración 57 Potenciometro. Ilustración 58 Potenciometro. 33 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6.2.1 CODIGO BÁSICO EN ARDUINO PARA UN POTENCIOMETRO //variables int leo_potenciometro; int senal_entrada = 0; // funcion de setup del sistema. void setup() { Serial.begin(9600); // abre el puerto serie a 9600 bps: pinMode(9, OUTPUT) ; } // el loop es para siempre. void loop() { leo_potenciometro = analogRead(senal_entrada); Serial.print("He recibido: "); Serial.println(leo_potenciometro); // para sacarla analogica int convertir_senal = map (leo_potenciometro, 0 1023, 255); constrain (convertir_senal, 0, 255); analogWrite (9, convertir_senal); delay (1000); } 34 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6.3 SONDA NTC DE TEMPERATURA Se usará como sensor2 (también se dispone de una LM35) de temperatura un termistor con pendiente negativa, conocido comunmente como NTC. Esta resistencia varía su valor dependiendo de la temperatura a la que se encuentra. Se tratará pues de buscar una relación entre la resistencia actual de la NTC y la temperatura del medio que la rodea. La instalación en Arduino (UNO) en este caso no es complicada. Simplemente se acondiciona mediante una resistencia. Éste se colocará dependiendo del valor de la sonda. En este caso de 10k para la sonda NTC seleccionada, pero para otros modelos se puede cambiar la resistencia, pero habrá que recalcular los coeficientes que se pueden calcular por diferentes métodos. Ilustración 59 Sonda NTC de temperatura 35 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 60 Acondicionador de señal para NTC 10k Conceptos teóricos Para obtener el valor de la temperatura. Atendiendo a las ecuaciones que describen el comportamiento de las NTC existen diferentes métodos, con la ecuación de las NTC que se describe a continuación es como se han obtenido mejores resultados. Ilustración 61 Curva caracteristica NTC Ilustración 62 Ecuación de las NTC 36 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 63 Salida de un divisor de tensión Ecuación de Steinhart-Hart43 Se calcularán los coeficientes necesarios para los valores que hayamos incluido en la cabecera, como las temperaturas y resistencias medidas para la calibración así como el valor de la resistencia auxiliar utilizada en el divisor de tensión entre otros Ilustración 64 Ecuación de la temperatura Ilustración 65 Parámetro Rinf Para la creación del software en Arduino se ha probado a realizar las medidas con la ecuación de SteinhartHart para la realización del programa de medición, pero los datos no han sido satisfactorios. Aún así se adjunta la función puesto que puede ser de utilidad si se usa otro modelo de NTC o una PTC. Los problemas suelen surgir al tratamiento de datos matemáticos tan grandes en Arduino. Las funciones logarítmicas están implementadas pero trabajar en la consola requiere de mucha atención. 43 http://en.wikipedia.org/wiki/Thermistor#Steinhart.E2.80.93Hart_equation 37 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 66 Ecuación STH Los coeficientes ABC de la ecuación vienen determinados por las hojas del fabricante. En este caso para una sonda : 103AT-1144 Ilustración 67 Coeficientes ABC Para un valor de 10 kohm los valores de las constantes son : A = 0.001125308852122 B = 0.000234711863267 C = 0.000000085663516 3.6.3.1 CODIGO ARDUINO PARA NTC – STEINHARHART //funciones extra para operaciones matemáticas #include <math.h> //---------------------------------------------------------------------//variables int leo_valor_temperatura; int senal_entrada = 0; double temp_celsius_de_funcion; //---------------------------------------------------------------------//Steinhart - Hart Equation 1/T = A+B(LnR)+C(LnR) al cubo //variables de la funcion Steinhart–Hart equation para 10kohm double SteinhartHart ( int Resistencia_lectura_temometro) { double Temp; 44 http://www.rapidonline.com/pdf/61-0500e.pdf 38 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado int R = Resistencia_lectura_temometro ; float A = 0.001129148; float B = 0.000234125; float C = 0.0000000876741; //con estos obtengo peores resultados. en concreto. la mitad. //float A = 0.0014762284; //float B = 0.00018817994; //float C = 0.00000038493403; Temp = log(10000*((1024/R-1))); // for pull-up configuration Temp = 1 / (A + (B + (C * Temp * Temp ))* Temp ); Temp = Temp - 273.15; // Convert Kelvin to Celcius //Temp = (Temp * 9.0)/ 5.0 + 32.0; // Convert Celcius to Fahrenheit return Temp;}//--------------------------------------------------------------------void setup() { Serial.begin(9600);} //---------------------------------------------------------------------void loop() { leo_valor_temperatura = analogRead(senal_entrada); Serial.print("He recibido: "); Serial.println(leo_valor_temperatura); temp_celsius_de_funcion = SteinhartHart ( leo_valor_temperatura ); Serial.print("Aplico SteinhartHart: "); Serial.println(temp_celsius_de_funcion); delay(1000);} 3.6.3.2 CODIGO ARDUINO PARA NTC – MÉTODO 2 #include <stdio.h> #include <math.h> int senal_entrada_NTC = 0; // Which pin will be the input of the Voltage-Divider int leo_valor_sonda_NTC ; float TempCelsius_NTC; //funcion que me caclula los grados C pasandole el valor de la resistencia //mejores resultados que la ecuacion de SteinhartHart float funcion_valor_sondaNTC ( int resistencia_NTC) { float Vin=5; // [V] Supply voltage in the Voltage-Divider float Raux=10000; // [ohm] Secondary resistor in the Voltage-Divider float R0=10000; // [ohm] NTC nominal value at 25ºC float T0=293.15; // [K] (25ºC) float Vout=0.0; // [V] Voltage given by the Voltage-Divider float Rout=0.0; // [ohm] Current NTC resistance float T1=273; // [K] Temperature at first testing point float T2=373; // [K] Temperature at second testing point float RT1=19750; // [ohms] Resistance at 273K (0ºC) float RT2=2150; // [ohms] Resistance at 373K (100ºC) float beta=0.0; // [K] Beta parameter float Rinf=0.0; // [ohm] Rinf parameter float TempK=0.0; // [K] Temperature output in Kelvin 39 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado float TempC=0.0; // [ºC] Temperature output in Celsius beta=(log(RT1/RT2))/((1/T1)-(1/T2)); Rinf=R0*exp(-beta/T0); //para compensar que tengo de entrada entre 0 y 1023 datos = 1024. en el puerto analogico. //y que la resistencia no mide de forma lineal la temperatura. es para hacer la equivalencia. Vout=Vin*((resistencia_NTC)/1024.0); Rout=(Raux*Vout/(Vin-Vout)); //Temperature calculation TempK=(beta/log(Rout/Rinf)); TempC=TempK-272.15; //paso Kelvin a Celsius return TempC; //devuelvo un valor. ojo, variable interna de la funcion. no puedo sacarla } //---------------------------------------------------------void setup() { Serial.begin(9600); //Configuracion del puerto serie pinMode(senal_entrada_NTC, INPUT); //Configuracion de los pines de entrada } //---------------------------------------------------------void loop() { leo_valor_sonda_NTC = analogRead(senal_entrada_NTC); //leo la resistencia que marca la sonda en la señal de entrada determinada Serial.print("He recibido: "); Serial.println(leo_valor_sonda_NTC); //por puerto, el valor de la resistencia . es una NTC. negativa TempCelsius_NTC = funcion_valor_sondaNTC ( leo_valor_sonda_NTC ); //llamo a la funcion con el valor de la resistencia de la NTC. me da grados C. Serial.print("Y eso son Grados C: "); Serial.println(TempCelsius_NTC); delay(1000);} 40 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6.4 INSTALACIÓN DE UNA LDR LDR or Light Dependant Resistor, Photoresistor - Fotoresistencia. Resistencia que varía con la luz. Una fotorresistencia es un componente electrónico cuya resistencia disminuye con el aumento de intensidad de luz incidente. Puede también ser llamado fotorresistor, fotoconductor, célula fotoeléctrica o resistor dependiente de la luz, cuyas siglas (LDR) se originan de su nombre en inglés light-dependent resistor. Para medirla, mido lo que cae el voltaje en ella. Mediante un divisor de tensión y otra resistencia. Data sheet de la que se usa en este proyecto vt 900 Ilustración 68 LDR en Arduino Ethernet //prueba simple del funcionamiento de una fotoresistencia 41 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado //Conectar la fotoresistencia por una pata al pin 0 y por la otra a +5V. //Conectar una resistencia de 10K entre el pin 0 y GND // PhotoR 10K // +5 o---/\/\/--.--/\/\/---o GND // | // Pin 0 o-------' //variables int leo_LDR, convierto; int senal_entrada = 0; // funcion de setup del sistema. void setup() { Serial.begin(9600); // abre el puerto serie a 9600 bps: } // el loop es para siempre. void loop() { leo_LDR = analogRead(senal_entrada); Serial.print("He recibido: "); Serial.println(leo_LDR); convierto = map ( leo_LDR, 0, 1023, 0 , 255); // para transformar a salida analogica. o byte Serial.println(convierto); delay (1000); } 3.6.4.1 ACONDICIONAMIENTO DE SEÑAL Ilustración 69 Circuito para LDR 42 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Como esta LDR en concreto es de 10 k. (Su rango de variación es de 40 Ohm a 10KOhm.) Se instala también una resistencia de 10k . Si el divisor de tensión es lo más fácil posible para el código de Arduino a máxima luz que son 5volts. Me da un valor en Arduino de 1023. A mitad luz que son 2.5 volts daría 512. Y a 0 volts. nada de luz. seria 0 la medición. Así ya es más fácil para mapear esta salida por ejemplo a una señal de salida PWM. Que saca valores entre 0 y 255.; que es el mismo valor que se puede conseguir con un byte cuando escribo en el puerto serie. mapear esos 0, 1023 valores de entrada . a 0 255. valor = map (valor, min, max, 0, 255); Se aconseja usar la función “constrain” para evitar salir del rango de medida. Pruebas reales. Con buena luz. Pero sin sacarlo al sol, el valor medido es 965 y debería ser 1023- ok. Con oscuridad casi total* el valor medido es 2 , 1 a veces 0. y debía ser 0. ok 43 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 70 LDR en Arduino Ethernet 44 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6.5 SENSOR LM35 Sensor de temperatura LM35. No necesita acondicionador de Señal. La conexión es directa. Este sensor tiene una salida análoga proporcional a la temperatura que registra (pin del centro), de acuerdo a la imagen a derecha los pines son +Vs, Vout, GND (como referencia en la fotografía y en el diagrama utilizaremos los colores rojo para +5V, azul para la salida y negro para GND (Ground o Tierra). Para conectar el sensor al Arduino el pin +Vs (rojo) debe conectarse al pin 5V en la sección “POWER” de la placa. El pin Vout (verde) al pin A0 en la sección “ANALOG IN” y el pin GND (negro) en el PIN GND de la sección “POWER”. En el siguiente diagrama pueden ver como se realiza la conexión entre el Arduino y el sensor LM35 ¡ Ilustración 71 LM 35 en Arduino Uno 45 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Mediante una función en Arduino //variables const int senal_entrada_LM35 = 0; float temperatura_del_LM35; //funcion para leer temperatura de un LM35. damos señal de entrada y devuelve temperatura float funcion_temp_de_LM35 (int senal_entrada_para_leer ) { float miliVolts ; float temp_LM35 ; int lectura_entrada_LM35; lectura_entrada_LM35 = analogRead(senal_entrada_para_leer); //convierto la entrada analogica 0-1023 a lectura de sonda LM35 //habria que multiplicar por 5000mV para hacer la conversion. pero.. //se ha visto que la tension real es mas pequeña. y por eso se producen desajustes. miliVolts = ((lectura_entrada_LM35 * 4638L ) / 1023L ) ; temp_LM35 = ( miliVolts / 10L) ; return temp_LM35 ; } // fin de funcion que lee temperatura de un LM35 // funcion de setup del sistema. void setup() { Serial.begin(9600); // abre el puerto serie a 9600 bps: } // el loop es para siempre. void loop() { temperatura_del_LM35 = funcion_temp_de_LM35 (senal_entrada_LM35); Serial.print("Salida LM35 en grados: "); Serial.println(temperatura_del_LM35); delay (1000); } /* notese la letra “L” que se usa en valores en Arduino. 10L- no es un error. Es para especificar el tipo de dato cuando se trabaja con funciones matemáticas. */ 46 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 72 LM35 MIRANDOLO DE FRENTE: POR EL LADO PLANO. pata-1- IZQUIERDA a 5volts. pata-3 - DERECHA a tierra. pata central a entrada analógica. El sensor da 10 milivoltios cada grado centigrado. 270 mV son 27ºC según tablas Recordar que la señal analógica -analogRead- de Arduino da valores de0 ->1023 de 0 a 1023 de 0 a 5volts. 5000 mV Conversión Con los datos que tenemos sería: 5000mV - 1023 270 mV - X = 55 en la entrada serian esos aproximados 27 grados. 47 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado y el caso general : 5000 miliVolts ----- 1023 x milivolts ------------- dato de entrada Los X mV = dato de entrada * 5000 / 1023 y de aquí la temperatura es un valor directo, porque 270mV son 27º. Divido el resultado por 10 . Temperatura = X mV / 10; Esto se lleva a Arduino 48 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6.6 CONFIGURACIÓN DEL GPS 3.6.6.1 CONFIGURACIÓN HARDWARE Del TX del GPS al Rx de la placa Arduino (solo necesito recibir) pero si no se conecta también el receptor no funcionará GND de GPS al GND placa Arduino 3.2 volts. del gps al Arduino Si da problemas overdue , Desconectarlo y conectarlo después. Problema por interrupción de TX o RX en diferentes placas. Peor en Arduino Ethernet. Se aconseja usar las señales digitales. Así se ha programado el script como se ve en el código y asi se ha dibujado en planos. GPS TX (transmitir) a pin Digital 3. GPS RX (recibir) a pin Digital 2. Ilustración 73 GPS a Arduino UNO 49 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6.6.2 CODIGO ARDUINO PARA LECTURA DEL GPS #include <Adafruit_GPS.h> #include <SoftwareSerial.h> // y para mis operaciones matematicas en flotante. flooooat !! #include <Math.h> byte buffer[] = {0, 1, 2, 3, 4, 5, 6, 7}; //doy unos valores cualesquiera. luego los actualizaré. int signo_Latitud =0, signo_Longitud=0; float mi_latitud_DMM , mi_longitud_DMM; float mi_latitud_DDD , mi_longitud_DDD; // Grados y minutos decimales (DMM): 41 24.2028, 2 10.4418 // Grados decimales (DDD): 41.40338, 2.17403 // muy importante. pines digitales a vigilar // Connect the GPS TX (transmit) pin to Digital 3 // Connect the GPS RX (receive) pin to Digital 2 SoftwareSerial mySerial(3, 2); Adafruit_GPS GPS(&mySerial); #define GPSECHO false boolean usingInterrupt = false; void useInterrupt(boolean); void setup() { Serial.begin(9600); GPS.begin(9600); _OUTPUT_RMCGGA); GPS.sendCommand(PMTK_SET_NMEA_UPDATE_1HZ); // 1 Hz update rate GPS.sendCommand(PGCMD_ANTENNA); useInterrupt(true); delay(1000); } SIGNAL(TIMER0_COMPA_vect) { char c = GPS.read(); #ifdef UDR0 if (GPSECHO) if (c) UDR0 = c; #endif } void useInterrupt(boolean v) { if (v) { OCR0A = 0xAF; TIMSK0 |= _BV(OCIE0A); usingInterrupt = true; } else { TIMSK0 &= ~_BV(OCIE0A); usingInterrupt = false; } } uint32_t timer = millis(); void loop() // run over and over again { // need to 'hand query' the GPS, not suggested :( 50 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado if (! usingInterrupt) { char c = GPS.read(); if (GPSECHO) if (c) Serial.print(c); //para quitar morralla } if (GPS.newNMEAreceived()) { if (!GPS.parse(GPS.lastNMEA())) return; } if (timer > millis()) timer = millis(); if (millis() - timer > 2000) { timer = millis(); // reset the timer if (GPS.fix) { //lo mio, para processing. ojo lectura compatible y quitar los serial print. mi_latitud_DMM = GPS.latitude; //Serial.println (mi_latitud); //dato 4227.92 mi_longitud_DMM = GPS.longitude; } } mi_latitud_DMM = 4227.92f ; mi_latitud_DDD = convertDegMinToDecDeg(mi_latitud_DMM); //Serial.println (mi_latitud_DDD ); mi_longitud_DMM = 225.59f ; mi_longitud_DDD = convertDegMinToDecDeg(mi_longitud_DMM); //Serial.println (mi_longitud_DDD ); float decima1_Latitud = mi_latitud_DDD; // 42.4652f ; no le hago nada float decimal_Longitud = mi_longitud_DDD * (-1); // -2.4261f; * (-1) por el tema de conversiones. porque yo trabajo sin signo //convierto LATITUD DDD 42.4650 a lo que recojo en processing-----------------------//lo primero de todo compruebo el signo. y ajusto. cojo un valor para mi signo y cambio el numero. if (decima1_Latitud < 0 ){ signo_Latitud = 1; //1 es negativo decima1_Latitud = decima1_Latitud * (-1); //lo pongo positivo para trabajar bien con el. } else signo_Latitud = 0; //Serial.println (decima1_Latitud); //parte entera la misma int parte_enteraA = (int) decima1_Latitud; //parte enetera = 42 seran los grados int grados_Latitud = parte_enteraA; //grados = 42 - primer byte //Serial.println (grados_Latitud); //parte enetera = 42 float quito_parte_entera = (decima1_Latitud - parte_enteraA ) *10000 ; // tengo 4650 int parte_enteraB = (int) quito_parte_entera; //Serial.println (parte_enteraB); float parteC = parte_enteraB / 100 ; //Serial.println (parteC); int parteD = (int) parteC; //Serial.println (parteD); // 46 - segundo byte int parteE = parte_enteraB % 100 ; //Serial.println (parteE); // 50 - tercer byte //resultados al buffer de Latitudes buffer [0] = grados_Latitud; buffer [1] = parteD; 51 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado buffer [2] = parteE; buffer [3] = signo_Latitud; // convierto LONGTUD -2.426f -------------------------------------------// lo primero de todo compruebo el signo. y ajusto. cojo un valor para mi signo y cambio el numero. if (decimal_Longitud < 0 ){ signo_Longitud = 1; //1 es negativo decimal_Longitud = decimal_Longitud * (-1); //lo pongo positivo para trabajar bien con el. } else signo_Longitud = 0; //parte entera la misma int parte_enteraF = (int) decimal_Longitud; //parte enetera = 42 seran los grados int grados_Longitud = parte_enteraF; //grados = 42 - primer byte //Serial.println (grados_Longitud); //parte enetera = 42 float quito_parte_enteraZ = (decimal_Longitud - parte_enteraF ) *10000 ; // tengo 4650 int parte_enteraG = (int) quito_parte_enteraZ; //Serial.println (parte_enteraG); float parteH = parte_enteraG / 100 ; //Serial.println (parteH); int parteI = (int) parteH; //Serial.println (parteI); // 46 - segundo byte int parteJ = parte_enteraG % 100 ; //Serial.println (parteJ); // 50 - tercer byte //resultados al buffer buffer buffer buffer buffer [4] [5] [6] [7] = = = = grados_Longitud; parteI; parteJ; signo_Longitud; //escribo de un tiron el buffer completo , tenga los componentes que tenga. //asi y solo asi, se escribe en puerto serie para envio de bytes Serial.write(buffer, sizeof(buffer) ); delay(1000); } // Funcion para convertir los datos de Latitud longitud DMM de Adafruit // parte del formato grados y minutos decimales a grados decimales // no me interesa grados minutos segundos pq luego en processing tendría que convertirlo otra vez // processing como google DDD. // DDM a DDD // Grados y minutos decimales (DMM): 41 24.2028, 2 10.4418 // Grados decimales (DDD): 41.40338, 2.17403 double convertDegMinToDecDeg (float degMin) { // me vendrá un varlo en grados y minutos decimales. DMM double min = 0.0; //ojo, poner 0.0 o 0.0f double decDeg = 0.0; //para los minutos, fmod() requiere trabajar siempe con doubles min = fmod((double)degMin, 100.0); //se devuelven las coordenadas en grados decimales DDD 52 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado degMin = (int) ( degMin / 100 ); decDeg = degMin + ( min / 60 ); return decDeg;} 53 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6.7 OTROS SENSORES En el Anejo correspondiente se explica la configuración de otros sensores. Metano CH4, monóxido de carbono C0 , dióxido de carbono, calidad del aire , humos, amoniaco NH3, humedad relativa Butano, LPG, Alcoholes, Etanoles, Gas Natural, Hidrógeno, Ozono, Benceno, Acetona, Formaldehídos, etc DHT 11 - HUMEDAD SERIE MQ X 4MQ2. 4MQ3. Etc. 54 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.7 IDE PARA PROCESSING 3.7.1 LIBRERIAS PARA PROCESSSING Como ejemplo se indica que durante el código programado bajo Processing se han usado varias Interrupciones del funcionamiento secuencial del código como por ejemplo. mouseClicked(): Ocurre cuando se presiona y se libera un botón del mouse. mousePressed(): Cuando se presiona un botón del mouse. mouseDragged(): Ocurre cuando se da clic con el mouse y se arrastra. mouseReleased(): Ocurre cuando se libera un botón del mouse . keyPressed(): Ocurre cuando se presiona un tecla. keyReleased(): Ocurre cuando se libera una tecla que estaba presionada. Estas interrupciones vienen por defecto en Processing, en la instalación básica desde las primeras versiones. Pero no existen funciones que generen eventos en puerto serie de forma avanzada. Para ello se instalarán funciones que nos darán unas opciones de programación más amplia. Principalmente : bufferUntil (): Leer Buffers hasta ciertas condiciones serialEvent () : Evento en puerto serie Serial.List (): Listado de los puertos serie disponibles y posibles. Serial.myPort () : Asignacion de puertos. 55 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.7.2 CONDICIONES DE EJECUCIÓN DE PROCESSING Previo a la instalación de librerías externas habrá que probar que la última versión del software funciona correctamente en el ordenador que será del operario con las condiciones mínimas del sistema operativo y del software. Processing es un software que funciona en modo portable. Es decir, no requiere una setup del sistema. Se descarga el software, se descomprime en cualquier carpeta y ya está listo para funcionar. Al no hacer instalación personalizada, el sistema no sabe en qué ordenador se está ejecutando, ni con que sistema operativo, ni si tendrá todas las librerías dll, y todos los condicionantes de ejecución requeridos para el formato gráfico, puerto serie, etc. Esto se verá la primera vez que se quiera ejecutar el software. Si se usa Linux, los problemas serán otros y como existen diferentes distribuciones no será cometido de intervenir en dicha explicación cuando ya los usuarios de Linux saben resolverse sus propios inconvenientes. Bajo Windows se hará doble click en el acceso directo y esté ejecutará el Sketch de trabajo. Ilustración 74 Processing Básico Se insta a todo operario que vaya a trabajar con este software que haga encarecidamente esta prueba ejecutando el conocido “hello world” para saber que está listo para comenzar a trabajar con las aplicaciones 56 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado // hola. soy la versión 2. la que se ha usado para el // proyecto de garba. 2014 void setup() { size(640, 360);} void draw() { print ("está listo para usar Processing en este proyecto");} Puede parecer trivial, insignificante, y sin ningún sentido. Pero todo programador y picador de código sabe que si no hay “hello world” no hay nada. Las configuraciones, setups que funcionen a un usuario en un ordenador, con un sistema operativo X, puede que no sean válidas para un ordenador más avanzado, o con el sistema operativo X, ya sea superior o inferior. De hecho en este caso, así ha sido en varias ocasiones. Por lo tanto será condición “sine qua non” que el operario ejecute el “hello world” adscrito para confirmar que el software portable está instalado correctamente, y que el ordenador dispone de las características básicas para su funcionamiento. Estando en el año 2014, cualquier ordenador portátil menor de 4 años de uso soportará este primer programa de confirmación. No se procederá a dar características básicas de lo que es un ordenador personal estándar. 3.7.3 PROBLEMAS DE EJECUCIÓN DE PROCESSING El IDE processing será problemático de ejecutar cuando se instalen librerías complejas, avanzadas, y cuando se tire de APIS externas, etc. Pero en ocasiones, también ha dado problemas en este PFC y como tal, aquí quedan reflejadas para que sirvan de ejemplo y base de configuración para diferentes usuarios de las APPS propias de este trabajo o usuarios externos que acaben en este documento buscando información sobre dicho IDE: No arranca nada. En Blanco. Como se ha explicado, Processing no se instala en la setup de Windows. Por ello es un poco más inestable que un software con setup que chequea ciertas 57 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado dependencias en la instalación. Hasta no hacer un doble click sobre el EXE no se sabrá si todo está ok. Si no arranca el sistema, se recomienda probar antes en una versión de Windows superior. Este problema es más propio de versiones anteriores de Windows. En concreto ha dado este error en Windows XP y en Windows 7. En la versión Windows 8, y en Windows 8.1 no ha habido este inconveniente. Para solucionar este error que a la postre será el más de los comunes se plantean las siguientes soluciones. 1.- Ejecutar como administrador Con el Botón derecho. Ejecutamos como admin. Ilustración 75 Fallo 1 de Pocessing 3.- Ejecutar el solucionador de compatibilidad. Ilustración 76 Solucion 2 58 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 77 Solucion 2. parte B. Ilustración 78 Solucion 2. Parte C. 4.- Solución drástica. Se podría pensar que una reinstalación del sistema solucionaría este problema, pero no es así. Al ser un software portable, el sistema no ha modificado librerías ni carpetas en system32. Es solo una carpeta, y apenas ha dejado rastro en nuestro sistema. Muy agradecidos por ello, por otro lado. Y con todas las ventajas de ser portable. La solución drástica consiste en borrar la carpeta de trabajo que ha creado el sistema. Para ello se ira a Mis Documentos: 59 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 79 Mis Documentos. …. Y aquí se borrarán estas tres carpetas. Se recomienda guardar la información que se tenga en el directorio “Librerías” Una vez borradas estas carpetas se ejecutará de nuevo el EXE y el sistema creará de nuevo un entorno de trabajo. Preguntará si desea crearlo, y la respuesta será afirmativa. Por qué ocurre esto. Pues tras diversos estudios y consultas en foros no se ha encontrado solución. Simplemente es un problema de las instalaciones portables. Preferentemente en Windows 7 y Windows XP. No así Como se ha indicado en Windows 8.1. No obstante, como el autor de este PFC ha realizado muchas pruebas ha constatado que los programas que limpian registros, archivos temporales, cachés, no son un entorno amigable para Processing. Y se recomienda no usarlos mientras se trabaje con dicho IDE. Modo avanzado. Una vez que el sistema está listo para funcionar con las especificaciones básicas, y que el programa de chequeo “hello world” funciona correctamente se procederá a instalar librerías específicas para el funcionamiento avanzado de Processing. Estas librerías dotarán a Processing de unas funcionalidades muy potentes. Son de uso gratuito y Open Source , lo que hará que además de usarlas 60 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado sin problemas de licencias, se podría usar el código y manipularlo para nuestros fines, como así ha sido y ha quedado explicado en la memoria. 3.7.4 LIBRERIAS PARA PROCESSING. Como se ha indicado tanto para incrementar las funcionalidades de Arduino como de Processing, habrá que cargar al programa con librerías extras. Plugins, modulos, etc. Para este PFC se han usado varias: ControlIP5, Unfolding, serial, extrapixel, etc. Se explica como hacer la instalación de una de ellas: En la web oficial desgarg de la web45 : Se descarga la librería: Se copia el rar completo al ordenador y la se debe copiar a donde el sistema operativo haya creado los SKETCH. Suele ser en / mis cocumentos/ processing / library / …. Ilustración 80 Librearías modo A. Se copia en la carpeta completa y ahora en Processing saldrá como librería contribuida. Muy importante, no como extras si no contribuida 45 http://unfoldingmaps.org/tutorials/getting-started-in-processing.html 61 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 81 Contribuida También se puede instalar en la carpeta del programa al ser Portable, pero se aconseja usar el método anterior. Ilustración 82 Librerías Processing método 2. 3.7.5 CONDICIONES DEL SISTEMA GRÁFICO El posicionamiento de los datos capturados por el GPS en Arduino serán procesados y posicionados usando la librería Unfolding basada en JAVA. Esta librería requiere una instalación de software similar a cualquier otra librería ya instalada, pero requiere principalmente de unas condiciones de hardware 62 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado que son realmente difíciles de satisfacer. El posicionamiento por hardware requiere principalmente dos condiciones. 1. Conexión a internet en tiempo real a alta velocidad. 2. Compatibilidad gráfica con versiones altas de OpenGL. 46 Para satisfacer este segundo requisito se deberá tener instalada en el ordenador una tarjeta gráfica especial con unas altas capacidades DX, GPU, etc. Como comprobación: Se buscará entre las características de la tarjeta que las versiones de OpenGL sean siempre las más actualizadas que los drivers propios de la tarjeta soporten. Ilustración 83 Comprobación Open GL Viene con los drivers de la tarjeta, no se puede actualizar por separado. Se puede comprobar también metiendo este comando “dxdiag” y ahí se verán las opciones de video. De cualquier forma OpenGL se actualiza instalando los últimos drivers de la tarjeta. Al contrario que DX, OpenGL no tiene un SDK ni una versión fija establecida por una empresa. Únicamente tienen un estándar y cada fabricante actualiza sus 46 Open Graphics Library 63 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado drivers para soportar las funcionalidades que se marcan. A veces incluso, aunque no debería ser así, en diferentes sistemas operativos se producen también incompatibilidades. 64 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.8 CONFIGURACION DE XBEE Los módulos XBee utilizan el protocolo IEEE 802.15.4 mejor conocido como ZigBee. Zigbee es un protocolo de comunicaciones inalámbrico basado en el estándar de comunicaciones para redes inalámbricas IEEE_802.15.4. Creado por Zigbee Alliance, una organización, teóricamente sin ánimo de lucro, de más de 200 grandes empresas (destacan Mitsubishi, Honeywell, Philips, ODEM do, Invensys, entre otras), muchas de ellas fabricantes de semiconductores. Zigbee permite que dispositivos electrónicos de bajo consumo puedan realizar sus comunicaciones inalámbricas. Es especialmente útil para redes de sensores en entornos industriales, médicos y, sobre todo, domóticos. Cada módulo Zigbee, al igual que ocurre con las direcciones MAC de los dispositivos Ethernet, tiene una dirección única. En el caso de los módulos Zigbee cada uno de ellos tiene una dirección única de 64bits que viene grabada de fábrica. Por otro lado, la red Zigbee, utiliza para sus algoritmos de ruteo direcciones de 16 bits. Cada vez que un dispositivo se asocia a una red Zigbee, el Coordinador al cual se asocia le asigna una dirección única en toda la red de 16bits. Por eso el número máximo teórico de elementos que puede haber en una red Zigbee es de 2^16 =65535, que es el nº máximo de direcciones de red que se pueden asignar. Estos módulos Xbee, pueden ser ajustados para usarse en redes de configuración puntoa-punto, punto-a-multipunto o peer-to-peer. 65 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 84 Arduino y Xbee Los módulos Xbee proveen 2 formas amigables de comunicación: Transmisión serial transparente (modo AT) y el modo API que provee muchas ventajas. MODO AT Esta el modo de transmisión serial transparente (Modo AT), en el cual la comunicación se asemeja a lo que sería una transmisión a través de un puerto serial, ya que el dispositivo se encarga de crear la trama y el dato que llegue al pin Tx será enviado de forma inalámbrica, por lo cual se considera como el modo más sencillo para utilizar estos nodos, su principal desventaja es que para enviar información a distintos nodos es necesario entrar constantemente al modo configuración para cambiar la dirección de destino. MODO API El otro modo de comunicación se conoce como Modo API, en este caso un microcontrolador externo se debe encargar de crear una trama especifica al tipo de información que se va a enviar, este modo es recomendado para redes muy grandes donde no se puede perder tiempo entrando y saliendo del modo configuración de los dispositivos. Para redes con topología en Malla este es el modo a utilizar. 66 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.8.1 CONFUSIÓN ZIGBEE, Y PROTOCOLO 802.15.4 EN MÓDULOS XBEE Se ha prestado a confusión por parte de los usuarios, sobre el protocolo que soportan los módulos XBEE. Por una parte mencionan el protocolo 802.15.4 y por otra el protocolo ZigBee. Para aclarar esto se debe indicar que los módulos XBEE soportan el protocolo 802.15.4, mientras que los módulos XBEE PRO soportan el protocolo ZigBee. 3.8.2 CARACTERÍSTICAS Los Xbee pueden comunicarse en arquitecturas punto a punto, punto a multi punto o en una red mesh. La elección del módulo XBee correcto pasa por escoger el tipo de antena (chip, alambre o conector SMA) y la potencia de transmisión (2mW para 300 pies o 60mW para hasta 1 km). El módulo requiere una alimentación desde 2.8 a 3.4 V, la conexión a tierra y las líneas de transmisión de datos por medio del UART (TXD y RXD) para comunicarse con un microcontrolador, o directamente a un puerto serial utilizando algún conversor adecuado para los niveles de voltaje. Buen Alcance: hasta 100 mts en línea vista para los módulos Xbee y hasta 1.6 Km para los módulos Xbee Pro. 9 entradas/salidas con entradas analógicas y digitales. Bajo consumo <50mA cuando están en funcionamiento y <10uA cuando están en modo sleep. Interfaz serial. 65,000 direcciones para cada uno de los 16 canales disponibles. Se pueden tener muchos de estos dispositivos en una misma red. Fáciles de integrar. 67 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.8.3 CONFIGURACIÓN DE LOS JUMPERS La Xbee shield tiene dos jumpers (las pequeñas fundas de plásticos que están sobre los tres pines etiquetados como Xbee/USB). Estos determinan como se conecta la comunicación serie del Xbee entre el microcontrolador ATmega328 y el chip serie FTDI de la placa Arduino. Con los jumpers en la posición Xbee ( los dos pines más cercanos al interior de la placa), el pin DOUT del módulo Xbee está conectado al pin RX del microcontrolador; y el pin DIN está conectado a TX. Notar que los pines RX y TX del microcontrolador están todavía conectados a los pines TX y RX (respectivamente) del chip FTDI – los datos enviados desde el microcontrolador serán transmitidos al ordenador vía USB y a la vez enviados de forma inalámbrica por el módulo Xbee. El microcontrolador, sin embargo, solo será capaz de recibir datos desde el módulo Xbee, no desde el USB del ordenador. Con los jumpers en la posición USB ( los dos pines más cercanos al borde de la placa), el pin DOUT del módulo Xbee está conectado al pin RX del pin del chip FTDI, y el DIN del módulo Xbee está conectado al pin TX del el chip FTDI. Esto significa que el módulo Xbee puede comunicarse directamente con el ordenador – sin embargo, esto solo funciona si el microcontrolador ha sido quitado de la placa Arduino. Si el microcontrolador se deja en la placa Arduino, solo será capaz de comunicarse con el ordenador vía USB, pero ni el ordenador ni el microcontrolador podrán comunicarse con el módulo Xbee. 3.8.4 SOFTWARE Los módulos Xbee pueden ser configurados desde el PC utilizando el programa X-CTU, Moltosenso o Cool Terms además de otros. Moltosenso y Cool Terms permite trabajar en múltiples plataformas, mientras que X-CTU solo trabaja en Windows. Aunque se puede acceder a él a través de Mac o Linux con una 68 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado máquina virtual que corra aplicaciones de Windows, como WINE. O viceversa usando una Virutal Box de Oracle por ejemplo. En este proyecto el funcionamiento correcto y más estable se ha conseguido con ambas versiones de X-CTU oficiales. Dentro de las versiones oficiales, se han hecho comprobaciones con la versión clásica y una actualización reciente. Se considera que al presentar ya por defecto las configuraciones básicas de setup de los softwares programadas y grabadas no cabe dicha configuración en este documento de Especificaciones Técnicas, por ello, todo el proceso de configuración se adjunta en un Anexo correspondiente, tanto para la versión clásica como para la versión 2014. Ilustración 85 versión 2014 69 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 86 Versión clásica 3.8.5 HARDWARE Ilustración 87 Xbee Hard 70 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 88 Xbee Asignación 71 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.9 CONFIGURACIÓN DE 3DR La conexión de los módulos inalámbricos 3DR siguen el mismo proceso que los módulos Xbee. Para la conexión solo cuatro cables son necesarios: 5 volts del Arduino a 5 volts del 3DR. GND a GND TX en Arduino a RX de 3DR. RX de Arduino a TX del 3DR El resto de cableado no es estrictamente necesario para este proyecto, pero se aconseja usar el manual de usuario si se desean hacer otro tipo de configuraciones más específicas: como hacer resets, u otro tipo de control remoto desde el ordenador. 3.9.1 SOFTWARE Se usará el software oficial de la compañía, pero se consultará como consulta básica el proyecto Open que la comunidad ha creado en google code.47 Se configurará la red a 9600 baudio. Es estándar elegido para este PFC. Habrá que ser cuidadosos en la configuración de los módulos, pues si uno de ellos se resetea habrá que configurar de nuevo los dos. El proceso será el siguiente: Se colocará en el ordenador el modulo emisor y se configurará a la frecuencia deseada, posteriormente se conecta el receptor y se cambia su frecuencia. Al tener la misma frecuencia, podrá conectar con el emisor y quedar configurado. DRIVERS: Habrá que configurar 2 tipos diferentes de Drivers. Ambos están en la web oficial y en enlace indicado. 47 https://code.google.com/p/ardupilot-mega/wiki/3DRadio 72 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.9.1.1 AJUSTES. Arriba a la izquierda : Se configura el puerto y la velocidad correspondiente Se conecta al USB Se pulsa en “load settings”. y carga las settings que tenga el receptor y el emisor. Se comprueba que son las mismas en ambos lados. Si no coincidente en el emisor las puedo copiar al emisor, y si da problemas se hace por partes. Se pone en el usb el emisor guardando settings, y luego el receptor. Esto es cuando se desconfigure. Por defecto, cargando uno, le envía todo al otro. Si está ok, no hace falta guardarlas. Confirmar que aquí, tiene que coincidir también los BAUDIOS. Abajo Izquierda, con lo que tenga arriba configurado, y con lo que tenga en Arduino. En este caso, 9600 arriba izda. Abajo se confirma que pone 9. Equivalente a 9600. 73 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 89 Configuración 3DR Se ve que se pueden configurar muchos más parámetros . Se han hecho pruebas que ha sido el único proceso válido para ajustar las mejoras de transmisión. Velocidad del aire, potencia. .. etc. Se recomienda partir de estas configuraciones pero modificarlas insitu para posteriores mejoras o configuraciones ambientales. El autor no se siente capaz de especificar cuáles serán las mejores opciones de vuelo, puesto que solo mediante prueba y error ha conseguido unos datos aceptables, olvidándose por completo de lo recomendado por el fabricante. Los datos de recepción se ven en la terminal o consola: 74 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 90 Configuración 3DR En la consola se ven los datos que llegan desde Arduino por el modo inalámbrico. A veces estos datos no serán los mismos que cuando se abra la consola de Processing si no se configuran bien las interrupciones por software tanto en Arduino para envío, como en Processing para recepción. 3.9.1.2 CONDICIONES TÉCNICAS PARA QUE FUNCIONE PROCESSING Problemas que surgen en las configuraciones de las comunicaciones: Para enviar a Arduino. Solo el usb de Arduino. quitar el TX y el RX del modulo 3dr. si no error de overdue. Desconectar Arduino. Poner Arduino con batería. 75 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Cargar 3dr config- load settings Quitar 3dr config. Con todo desconectado abrir Processing. Si no, error de port busy. 3.9.2 PLANOS No existen planos para los módulos 3DR. LA configuración es similar a los módulos Xbee. Se recomienda consultar estos planos. Son 4 conexiones idénticas. Tensión, Tierra, transmisión y recepción. 3.9.3 HARDWARE Ilustración 91 3DR sobre el APM2 76 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.10 GPS PARA ARDUINO Los 3 GPS usados para hacer diferentes pruebas en este proyecto han sido el GTPA 010, GTPA 013, y GPS3DR uBlox. Con el GPS GTPA 010 de Adafruit no se consiguieron buenos resultados, ni en interiores ni exteriores. Se hicieron pruebas con el 3DR y aunque daba buenos resultados en Matlab + Simulink + APM2 no se encontró compatibilidad con Arduino directamente. Ilustración 92 GTPA 013 3.10.1 LIBRERIAS PARA GPS Como se han probado diferentes módulos de GPS también se han probado diferentes librerías. Algunas incluso probando configuraciones APIS de google, etc. Cada librería 1. AdafruitGPS 2. TinyGPS 3. Temboo 4. GPS_MTK 5. Ardupilot El GPS puede funcionar en ocasiones en edificios interiores, pero no se garantiza su correcto funcionamiento. Como secuencia de puesta en marcha, se 77 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado aconseja que se configure en un lugar abierto, libre de interferencias y se espere unos minutos hasta que la recepción de satélites sea correcta. Con menos de 3 satélites no da ningún resultado, y hasta 6-7 satélites no crea una secuencia estable capaz de funcionar moviéndose o posicionándose en diferentes lugares. Par poder mover el GPS y generar una ruta, se recomiendan más de 10 satélites. Ilustración 93 GPS en exteriores Logroño. En exteriores, habrá que esperar también unos minutos para esperar la recepción de datos. En ocasiones, se podrá mover a un interior si la lectura es estable. Pero no siempre lo será Ilustración 94 GPS en interiores 78 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.10.2 INSTALACIÓN DE LIBRERÍAS PARA ARDUINO Las Librerías proveen funcionalidad extra al sketch. Se usan librerías cuando por defecto las funcionalidades no vienen instaladas en el Arduino seleccionado. Habrá librerías específicas para algunos Arduinos concretos. Por ejemplo la Ethernet, para el Arduno usado en este proyecto. No siempre habrá librerías creadas para todo lo que sea necesario. Aunque es complejo también se pueden crear nuestras propias librerías. Se desarrollan en C++. Para usar una librería dentro de un sketch. Seleccionar desde Sketch > Import Library (Importar Librería). Si se desea usar librerías que no vienen junto con Arduino, será necesario. Para hacerlo, descargue la librería y descomprimirla. Debería localizarse en una carpeta propia, y normalmente, contener dos archivos, uno con sufijo ".h" y otro con sufijo ".cpp". Abra su carpeta sketchbook de Arduino. Si ya existe una carpeta llamada "libraries", coloque la carpeta de la librería ahí dentro. Reiniciar el IDE de Arduino para encontrar la nueva librería en el menú Sketch > Import Library. Ilustración 95 Librerias Para Arduino 79 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Si se usa una versión portable de software de Arduino se pueden copiar las librerías directamente en su carpeta de instalación. Dentro del directorio en la carpeta “libreries”. Comprobar que el nombre no tiene espacios o letras extrañas que den problema posterior de compilación como la “ñ” , “/”, etc. . Ilustración 96 Librerias Arduino También se podrán crear librerías para ahorrar trabajo y limpieza a la hora de crear nuevos componentes: Aquí la documentación. En este proyecto no se han creado librerías puesto que el hardware usado no ha sufrido excesivas modificaciones, pero lo que si se han creado son varias funciones externas y funcionales con parámetros de ingreso y “return” completos para ahorrar mucho trabajo. 3.10.3 PROTOCOLO NMEA Se usará el Formato de datos "complejo": Consiste en un bloque de datos de 37 bytes de (generalmente) texto legible ASCII que da el error “cross-track”, proporciona un waypoint, presenta la Lat / Long actual, y un byte binario de estado. 80 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado El bloque de datos se enviarán a intervalos de 2 a 8 sec. Todos los bytes en el formato complejo tienen el bit 7 = 1 para distinguirse del formato simple. A un dispositivo remitente se le permite enviar datos simples y complejos, y incluso enviar un byte "simple" de datos en medio de un bloque "complejo" de datos. Bajo la norma NMEA-0183, todos los caracteres usados son texto ASCII imprimible (más retorno de carro y “line feed”). Los datos NMEA-0183 se envían a 4800 baudios, usando 8 bits de datos, 1 bit de stop y sin paridad. Los datos se transmiten en forma de "sentencias". Cada sentencia comienza con una "$", dos letras " talker ID", tres letras " ID sentencia ", seguido por un número de campos de datos separados por comas, y acaba con un checksum optativo, y un retorno de carro / “line feed”. Una frase puede contener hasta 82 caracteres incluyendo el "$" y CR / LF. En este proyecto se ha usado el GPS GTPA 013, bajo la librería propia de la marca distribuidora Adafruit que ha prestado a la comunidad un ejemplo de desarrollo para Arduino totalmente funcional y de acceso al código. Esta librería interpreta el protocolo NMEA y lo muestra en datos legibles y variables de acceso bajo el sistema DMM, que posteriormente se convertirá dentro del mismo código de Arduino a un DDD. Y es que este es el sistema ms empleado internacionalmente incluido en la librería que se usará en Processing. También se podría haber enviado el formato de bytes a Processing y hacer allí la conversión, pero se ha pensado que este formato es más correcto puesto que se necesitarán hacer comprobaciones en el mismo puerto serie de Arduino antes de enviarlo. 81 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 97 Coordenadas UR Latitud: D.d 42.464739 DMS 42 27 53 DM.m 42 27.88434 Longitud: D.d -2.424246 DMS -2 25 27 DM.m -2 25.45476 3.10.4 CONVERSIÓN PERSONALIZADA DE DATOS DMM , DDD Grados Minutos Segundos a Grados Minutos.m Grados = Grados Minutos.m = Minutos + (Segundos / 60) 82 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Grados Minutos.m a Grados Decimal .d = M.m / 60 Grados Decimal = Grados + .d Se crea una función en Arduino // Función para convertir los datos de Latitud longitud DMM de Adafruit // parte del formato grados y minutos decimales a grados decimales // no me interesa grados minutos segundos pq luego en // processing tendrá que convertirlo otra vez // processing como google DDD. // DDM a DDD // Grados y minutos decimales (DMM): 41 24.2028, 2 10.4418 // Grados decimales (DDD): 41.40338, 2.17403 double convertDegMinToDecDeg (float degMin) { // me vendrá un valor en grados y minutos decimales. DMM double min = 0.0; //ojo, poner 0.0 o 0.0f double decDeg = 0.0; //para los minutos, fmod() requiere trabajar siempre con doubles min = fmod((double)degMin, 100.0); //se devuelven las coordenadas en grados decimales DDD degMin = (int) ( degMin / 100 ); decDeg = degMin + ( min / 60 ); return decDeg; } 3.11 LIVE STREAMING VIA WIFI Todas las cámaras que tienen un sensor CMOS, al que afectan mucho las vibraciones verticales de alta frecuencia. Cuando se está grabando y la cámara se mueve verticalmente, en la dirección de la vibración se separan las líneas y cuando vuelve a la posición original se juntan. Esto produce un efecto oleaje, flan, gelatina o "Rolling Shutter" que es como se llama técnicamente. El sensor no lee la imagen como un todo, sino línea por línea. Un sensor está compuesto por miles o millones de fotodiodos y por su construcción es imposible leerlos todos juntos, por lo que la solución más sencilla es leer línea por línea su información y grabar la imagen final. Esto no tiene problemas con objetos estáticos, pero cuando se agrega algún factor de movimiento rápido se produce el problema 83 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ya que la última línea que está leyendo el sensor es, en cierta manera, más reciente que la primera que leyó. Los sensores no suelen leer toda la imagen de una sola vez sino que lo hacen mediante barridos en columnas verticales u horizontales. No se graba la imagen completa ni si quiera al mismo tiempo, por lo que si se mueve la cámara de forma ligera el contenido saldrá distorsionado. Se producen también otras deformaciones de imagen por Moiré o Aliasing: el problema con las réflex digitales es que a pesar de su descomunal resolución, sólo requieren de 1920x1080 (2MPs) para grabar videos en la más alta resolución (Full HD), y con el fin de acelerar el proceso de compresión, algunas marcas (Canon) se saltan algunas líneas de muestreo. Aparentemente cogería sólo una de cada tres, que luego serían comprimidas horizontalmente para finalmente ser recombinadas en un sólo cuadro final. Este proceso intensifica las irregularidades naturales, generando inaceptables patrones sobre principalmente las líneas rectas. Por experiencia se han probado diferentes configuraciones de muestreo de video para solucionar estos problemas. Antes de llevarlos a un editor de video donde se le puedan aplicar plugins para su manipulación y mejora en el tratamiento de imagen, es mejor que la señal llegue con la menor cantidad de incorrecciones posibles. Para solucionar estos problemas existen en el mercado los conocidos Gimbals que es un mecanismo de suspensión consistente en dos aros concéntricos cuyos ejes forman ángulo recto, lo cual permite mantener la orientación de un eje de rotación en el espacio aunque su soporte se mueva. Pero estos equipos se disparan en precio y también en peso para multirotores pequeños. Más aún cuando llevan servos de control de cámara por radiofrecuencia. En este caso, lo que se recomienda es una aportación de soluciones caseras que funcionan correctamente. No permitirán el control remoto de la cámara ni la grabación continua horizontal de ésta cuando el multirotor se mueva hacia los lados, pero darán una sensación de estabilidad muy alta. Las soluciones “caseras”, personales adoptadas consisten en: 84 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1. Dependiendo de la zona grabar a un mínimo de 30 frames. Recomendado 60 frames. Y para modelos superiores llegar hasta 100 frames aunque se baje la resolución de 1920pixels a 1280pixels. 2. Sacar la cámara. fuera del multirotor mediante poliespán, gomas, corcho etc, 3. Para conseguir grabación horizontal constante se puede usar una bola de plástico sacada de un viejo joystick con un agujero en suspensión que cuelgue del heli y sujete la cámara. Con estos 3 consejos de un euro se pueden conseguir resultados de grabación de video bastante aceptables sin tener que usar un Gimbal comercial de más de 400 euros. No es el fin de este proyecto conseguir un video de alta calidad grabado bajo condiciones de estabilidad total como si fuera para edición futura de video para cine. 3.11.1 WLAN, LA RED INALAMBRICA La abreviatura WLAN significa Wireless Local Area Network (“red de área local inalámbrica”) y describe una red en la que cada uno de los dispositivos individuales (PC, portátiles, router, teléfonos inteligentes y otros) no se conectan mediante cable de red sino por radio. Por este motivo, al hablar de una WLAN a menudo también se habla de ella como de una red inalámbrica (en inglés "wireless"). Esta conexión inalámbrica se puede proteger contra usuarios no deseados con ayuda de la codificación WLAN. En consecuencia, un “adaptador Wi-Fi” no será otra cosa que un “adaptador WLAN”. Al contrario de “WLAN”, el término “Wi-Fi” no es una abreviatura sino únicamente el nombre de identificador o de marca. La descripción técnica del estándar Wireless LAN (WLAN) se encuentra redactada en el estándar de la industria ISO 802.11, estipulado por el Institute of 85 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Electrical and Eletronics Engineers (IEEE). Mediante este estándar la transferencia de datos se realiza a través de ondas de radio en las bandas de frecuencia de 2,4 GHz o de 5 GHz. En España, en el ámbito de las redes domésticas, los estándares de comunicación inalámbrica WLAN más importantes son los siguientes (datos de agosto de 2011): 802.11g, 802.11a y 802.11n. Hoy día, el estándar 802.11 ya se considera anticuado. 3.11.2 802,11G El estándar 802.11g, a menudo abreviado con una simple “g”, transmite en la banda de frecuencia de 2,4 GHz y ofrece tasas de transferencia de hasta 54 Mbps (brutos). Sin embargo, el estándar g debe compartir la banda de frecuencia de 2,4 GHz con muchos otros aparatos, como por ejemplo aparatos Bluetooth o sistemas de videovigilancia inalámbricos, lo cual puede fácilmente conllevar interferencias y un menoscabo de la tasa de transferencia. A pesar de que está muy extendido, el estándar g está siendo sustituido cada vez más por el estándar n, utilizado en los aparatos WLAN más modernos. 3.11.3 802.11A El estándar 802.11a, a menudo abreviado con una simple “a”, transmite en la banda de frecuencia mayor de 5 GHz y también ofrece tasas de transferencia de hasta 54 Mbps (brutos). En España, la banda de 5 GHz está claramente menos saturada que la de 2,4 GHz, por lo que en ella casi no se dan interferencias con otros aparatos. Esto se debe, principalmente, a que en la banda de 5 GHZ el número de canales que no se solapan es mucho mayor que en la banda de 2,4 GHz (802.11g). Sin embargo, en hogares construidos con hormigón armado la tasa de transferencia es claramente menor debido a la mayor frecuencia. La WLAN en la banda de frecuencia de 5 GHz es ideal para transferencias en la misma estancia o a través de paredes “finas” (construcción de madera). El estándar a se utiliza sobre todo en América del Norte y en España se integró sobre todo en portátiles profesionales. 86 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Este estándar también está siendo reemplazado cada vez más por el n. Atención: Los aparatos con los estándares 802.11g y 802.11a no son compatibles. Un portátil con un adaptador WLAN a no puede establecer conexión inalámbrica con un router WLAN g, puesto que transmiten en dos frecuencias diferentes. 3.11.4 802.11N Hoy día, el estándar 802.11n (abreviado n) es el estándar WLAN más potente y en los dispositivos domésticos alcanza unas tasas de transferencia (brutas) de hasta 150 Mbps, 300 Mbps o 450 Mbps, dependiendo de la cantidad de antenas de emisión y recepción integradas. El estándar n está diseñado para transmitir en las dos bandas de frecuencia, es decir, en la de 2,4 GHz y en la de 5 GHz. Los dispositivos con el estándar 802.11n pueden mejorar claramente el mal rendimiento de recepción y las consecuentes bajas tasas de transferencia de datos de los estándares g y a, ya que integran varias antenas de recepción y emisión, y transfieren los datos por varios canales paralelos. En este contexto (varias unidades de emisión y recepción), también se habla de MIMO, que es la abreviatura de “Multiple Input Multiple Output”. La tecnología inteligente de antenas integrada en los aparatos con el estándar 802.11 también puede enviar y recibir datos con desfase. En realidad, esta tecnología de antenas utiliza las reflexiones no deseadas contra obstáculos, como paredes o muebles, para optimizar la tasa de transmisión. Los dispositivos con MIMO, disponen para ello de un mínimo de dos antenas que transmiten en diversas direcciones. El receptor unifica las señales que provienen de las diferentes direcciones, evitando las zonas ciegas y aumentando así la velocidad de transferencia. El alcance también mejora: mientras una antena WLAN con el estándar 802.11b o g tiene un alcance de alrededor de 20 metros en espacios cerrados, en condiciones óptimas el estándar 802.11n con tecnología MIMO logra alcanzar hasta 70 metros. 87 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.11.5 COMPATIBILIDAD DE LOS DOSPOSITIVOS WLAN N Actualmente (datos de agosto de 2011), la mayoría de dispositivos WLAN n sólo son compatibles con una de las dos bandas de frecuencia, es decir, o bien 802.11n con 2,4 GHz o bien 802.11n con 5 GHz. Un adaptador WLAN que sólo transmita con 2,4 GHz no puede establecer conexión inalámbrica con un router WLAN n que sólo transmita con 5 GHz, a pesar de que ambos dispositivos son compatibles con el estándar 802.11n. Algunos routers WLAN n pueden transferir o bien con 2,4 GHz o bien con 5 GHz, por lo que también se conocen como routers de banda dual. No obstante, en este caso el usuario debe optar por una de las dos frecuencias. Los routers de banda dual que pueden transmitir a la vez en ambas frecuencias también se denominan routers de doble banda simultánea o routers de banda dual simultánea. Si este no es el caso, por regla general el estándar 802.11n a 2,4 GHz es compatible con el 802.11g, y el estándar 802.11n a 5 GHz es compatible con el 802.11a. Sin embargo, en estos casos la velocidad de transferencia se adapta al aparato con el menor de los estándares de transferencia y por tanto sólo puede alcanzar una tasa máxima de 54 Mbps (brutos). 88 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.12 VUELO DEL DRONE 3.12.1 CONCICIONES MÍNIMAS DEL DRONE Controladora Dji Naza M V1 actualizada a V2. 4 Motores Brushless . Mínimo T-Motor Mt2216-12 800kv 4 variadores de velocidad de gama Alta. ESC Brushless (para motores sin escobillas). 7 hélices Graupner 10x5. Aconsejables Carbono Batería de 5000 Zippy Lightmax con 2 ciclos. Emisora de 9 canales (Turnigy, Spektrum, Futaba) con soft ERX y monitor y su soporte + batería Life. Módulos receptor emisor Fr-Sky con telemetría. Tren de aterrizaje - Ejemplo: Tarot. Chasis F450 o superior + 4 brazos cableado con conector Xt60(amarillo) y (JST rojo pequeño) Porta lipos. El compass (BRUJULA) que tienen los Multirotores (Phantoms) en el tren de aterrizaje es muy sensible a los campos magnéticos. Al acercar el compass a un campo magnético accidentalmente (Destornillador con punta magnética, altavoz de un coche teléfono, etc), este se puede descalibrar hasta tal punto que el procedimiento de calibración del Mutirotor no lo puede recalibrar en el modo local, usando el software interno del equipo. 89 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.12.2 COMPAS, GPS, IMUS 3.12.3 ¿POR QUÉ CALIBRAR LA BRÚJULA? Pequeñas influencias ferromagnéticas en zonas del rotor o alrededor de su entorno de trabajo no solo afectarán a la lectura de la tierra magnética para brújula digital, sino que también reduce la precisión del control multi-rotor, o incluso lee un encabezamiento incorrecto de datos. La calibración eliminará tales influencias, y asegurará que el sistema funcione bien en un entorno magnético no ideal. 3.12.4 ¿CUÁNDO HACERLO? 1. La primera vez que instale Naza en su multi-rotor. 2. Cuando se cambia la configuración mecánica multi-rotor.: a) Si el módulo GPS / Brújula se vuelve a colocar. Segunda instalación o cambio de modelo. b) Si se agregan dispositivos electrónicos / quitan / re-posicionado (controlador principal, servos, baterías, etc.) c) Cuando se cambia la estructura mecánica del multi-rotor. 3. Si la dirección de vuelo parece estar cambiando (es decir, el multi-rotor no "vuela recto"). El indicador LED indica a menudo anomalías y parpadea. (Es normal que esto suceda de vez en cuando) 3.12.5 AVISOS No se debe calibrar la brújula, donde haya una fuerte interferencia magnética, parking, etc. O en zonas ferrosas debajo de la tierra. NO llevar materiales ferromagnéticos durante la calibración, como llaves o teléfonos celulares. 90 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado No tiene que girar su multi-rotor en una superficie horizontal o vertical precisa, pero mantener al menos el 45° de diferencia entre la calibración horizontal y vertical. El Multirotor no puede trabajar en el círculo polar. 3.12.6 PROCDIMIENTO DE CALIBRACIÓN PASO 1: Entre en el modo de calibración: deslice rápidamente el interruptor de modo de control de la posición 1 a la posición-3 durante 6 a 10 veces, y el indicador LED se pondrá de modo constante en amarillo. PASO 2: Calibración en horizontal: gira multi-rotor, junto con la superficie horizontal hasta que la luz verde está encendida constantemente, y luego ir al siguiente paso; PASO 3: Calibración en vertical: mientras que la luz verde se ilumina continuamente, mantenga el multi-rotor vertical y gire junto con su eje vertical, mantenga girando hasta que la luz verde esté apagada. La calibración ha terminado. PASO 4: Después de terminar la calibración, el indicador LED muestra si la calibración se ha realizado correctamente o no: Si la calibración ha terminad salir del modo Auto; Si la luz roja sigue parpadeando rápidamente de forma intermitente, la calibración ha fallado. Deslizar el interruptor de modo de control Auto una vez para cancelar la calibración actual, y luego volver a empezar desde el paso 1 para recalibración. Consejos: Si sigue teniendo fallo de calibración, se podría sugerir que es una fuerte de interferencias magnéticas alrededor del módulo GPS y brújula. Por favor, evita volar en esta zona. 91 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 98 Calibración Compass Ilustración 99 Calibración Compass. 3.12.7 SOFTWARE DE CONFIGURACION DE EMISORA Y DRONE La emisora lleva otro sofware diferente y dependerá del número de canales a trabajar. Recomendado es usar el libro de instrucciones de cada modelo para su configuración y posteriormente usar el software NAZA para ajustarla y calibrarla para cada dispositivo. Es comercial pero de uso gratuito. 92 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” FIN DE DOCUMENTO: ESPECIFICACIONES DEL SISTEMA Eduardo Garbayo Herce Logroño, a 16 de Julio de 2014 93 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 94 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado PROYECTO FIN DE CARRERA: “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” DOCUMENTO Nº4: ANEJOS Peticionario: DEPARTAMENTO DE INGENIERÍA ELECTRICA Informantes: Eduardo Garbayo Herce Alumno de Ingeniería Industrial Universidad de La Rioja Lugar y Fecha: Logroño, 12 de Julio de 2014 1 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4. ANEXOS 4.1 ARDUINO Ilustración 100 Internet Shield Ilustración 101 Arduino Ethernet 4.1.1 ARDUINO MEGA 2 – ARDUPILOT Como extra para este proyecto se ha usado el Arduino mega 2. Especialmente convertido en Ardupilot. Se trata de una placa especial con sensores incorporados y con más módulos de comunicaciones TX RX. Que ha permitido el uso de GPS para la captura de datos. Microcontroller ATmega328 2 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Operating Voltage 5V Input Voltage Plug (recommended) Input Voltage Plug (limits) 6-20V Input Voltage PoE (limits) 36-57V Digital I/O Pins Arduino Pins reserved: 10 to 13 used for SPI 4 used for SD card 2 W5100 interrupt (when bridged) Analog Input Pins 6 DC Current per I/O Pin 40 mA DC Current for 3.3V Pin Flash Memory bootloader SRAM 2 KB (ATmega328) EEPROM Clock Speed 16 MHz W5100 TCP/IP Embedded Ethernet Controller Power Over Ethernet ready Magnetic Jack Micro SD card, with active voltage translators 7-12V 14 (of which 4 provide PWM output) 50 mA 32 KB (ATmega328) of which 0.5 KB used by 1 KB (ATmega328) Ilustración 102 Ardupilot 3 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.1.2 IDE DE ARDUINO La descarga del software es gratuita. http://arduino.cc/es/main/software 4.1.3 ARDUINO LENTO Si sucede que cuando se abre el ejecutable de arduino.exe, este se demora en iniciar, cuando se navega por el menú tools o este es muy lento o se queda unos instantes en cargar un sketch puede ser que el DLL de comunicaciones está obsoleto. Físicamente se comunica, hace es emular una comunicación serial sobre un bus USB y cuando se ejecuta hace un scan, pero si hay otros dispositivos que tengan o generen un puerto serial como un dispositivo bluetooth, ratará de verificar esto y en esta verificación se generan retardos de tiempo. Soluciones: Primera solución Si se deshabilitan los dispositivos que usan el puerto serial estos retardos ya no se verán, vaya a inicio y entre en el panel de control: Ilustración 103 Panel de Control 4 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Click en Administrador de dispositivos Ilustración 104 Administrador de dispositivos Una vez ahí deshabilite todos los dispositivos seriales que tenga instalados desntro de Puertos (COM y LPT) Ilustración 105 Administrador de dispositivos desinstalamos 5 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Segunda solución La solución más apropiada es modificar los archivos fuente del Arduino, con esto se elimina el problema definitivamente. Se necesita el archivo rxtxSerial.dll que es el encargado de la comunicación serial del Arduino IDE. Se descarga el Archivo rxtxSerial.dll48 que se encuentra en un archivo comprimido .rar y se descomprime en la carpeta donde ha instalado el IDE de Arduino, reemplazando la versión anterior. 48 Se adjunta enlace online y también estará en el CD del proyecto. 6 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.2 SENSORES EXTRA 4.2.1 DHT 11 - HUMEDAD Sensor DHT11 que va a servir para medir tanto la humedad relativa como la temperatura. Ilustración 106 Sensor humedad DHT 11 Ilustración 107 Arduino - Sensor humedad DHT11 Características DHT11 La lectura de este sensor requiere de librerías extra como se ve en el código de Arduino básico. Librería Extra #include <dht11.h> #include <SoftwareSerial.h> dht11 DHT11; #define DHT11PIN 2 SoftwareSerial eImpSerial(7, 8); // RX, TX 7 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado void setup() { Serial.begin(9600); eImpSerial.begin(9600); } void loop() { int chk = DHT11.read(DHT11PIN); Serial.print("Temperature (oC): "); Serial.println((float)DHT11.temperature, 2); eImpSerial.print((float)DHT11.temperature, 2); eImpSerial.write(0xFC); delay(60000); } 4.2.2 SERIE MQ X Toda la serie a 5V Ilustración 108 Adaptador Arduino de los MQX 8 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 109 Serie MQX Ilustración 110 Arduino Serie MQX 4.2.3 MQ2. Sensitivo para Metano, Butano, LPG, humo. Características de MQ2 Código para Arduino int A0; void setup() { Serial.begin(9600); } void loop() { float vol; int sensorValue = analogRead(A0); vol=(float)sensorValue/1024*5.0; Serial.println(vol,1); } 9 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.2.4 MQ3. Sensitivo para Alcohol, Etanol, humo Características de MQ3 Código para Arduino int gasPin = 0; int value = 0; void setup() { Serial.begin(9600); pinMode(gasPin,INPUT); } void loop() { value = analogRead(0)/2; Serial.print("Alcohol:"); Serial.println(value); delay(100); } 4.2.5 MQ4. Sensitivo para Metano, CNG Gas Detección de fugas de gas para casas, talleres, comercios...Sistema de seguridad de detección de fuego. Detección de gas de carbón, CO... para casas, talleres y comercio. Detector de gas, alarmas de escapes de gas.. Características MQ4 Código para Arduino void setup() { Serial.begin(9600); //Set serial baud rate to 9600 bps } void loop() { int val; val=analogRead(0);Read Gas value from analog 0 Serial.println(val,DEC);//Print the value to serial port delay(100); } 4.2.6 MQ-5 Sensitivo para Gas Natural , LPG 10 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Características MQ5 Código para Arduino void setup() { Serial.begin(9600); //Set serial baud rate to 9600 bps } void loop() { int val; val=analogRead(0);Read Gas value from analog 0 Serial.println(val,DEC);//Print the value to serial port delay(100);} 4.2.7 MQ-6 Sensitivo para LPG, Gas Butano Características MQ6 void setup() { Serial.begin(9600); //Set serial baud rate to 9600 bps } void loop() { int val; val=analogRead(0);Read Gas value from analog 0 Serial.println(val,DEC);//Print the value to serial port delay(100);} 4.2.8 MQ-7 Sensitivo para Monóxido de Carbono. Librería extra MQ7 Características MQ7 Código Arduino void setup() { Serial.begin(9600); //Set serial baud rate to 9600 bps } void loop() { int val; val=analogRead(0);Read Gas value from analog 0 Serial.println(val,DEC);//Print the value to serial port delay(100); } 11 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.2.9 MQ-8 Sensitivo para Gas Hidrógeno Características del MK8 4.2.10 MQ-9 Sensitivo para Monóxido de Carbon, y gases inflamables. Características MK9 4.2.11 MQ131 Sensitivo para Ozono Tensión a 6V Resistencias del circuito 100k...200k, Search for datasheet: Características MK131 Código Arduino int sensorValue; void setup() { Serial.begin(9600); // sets the serial port to 9600 } void loop() { sensorValue = analogRead(0); // read analog input pin 0 Serial.println(sensorValue, DEC); // prints the value read delay(100); // wait 100ms for next reading } 4.2.12 MQ135 Para calidad de aire. Sensitivo para Bencenos, Alcohol, humo. Características MQ135 Código Arduino int sensorValue; void setup() { Serial.begin(9600); } // sets the serial port to 9600 12 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado void loop() { sensorValue = analogRead(0); Serial.println(sensorValue, DEC); delay(100); } // read analog input pin 0 // prints the value read // wait 100ms for next reading 4.2.13 MQ136 Sensitivo para Sulfuro de Hidrógeno Características MQ136 4.2.14 MQ137 Sensitivo para Amoniaco NH3. Características MQ137 4.2.15 MQ138 Sensitivo para Benceno, Tolueno. Alcohol, Acetona, Propano, Formaldeídos, Hidrógeno. Características MQ138 4.2.16 MQ214 Sensitivo for Metano, Gas Natural. Trabaja a 6V. Características MQ124 4.2.17 MQ216 Sensitivo para Gas Natural for Natural gas, Coal gas (de Hulla o Alumbrado) Características MQ126 4.2.18 MQ303A Sensitivo para Alcohol, Etanol, humo. Similar al MQ3 13 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado The heater uses 0.9V Características MQ303A 4.2.19 MQ306A Sensitivo para LPG y Gas Butano Características MQ306A 4.2.20 MQ307A Sensitivo para Monóxido de Carbono Características MQ307A 4.2.21 MQ309A Sensitivo para Monóxido de Carbono y otros gases inflamables Características MQ309A 4.2.22 MG811 Sensitivo para Dióxido de Carbono (CO2). Voltaje a 6V. Se puede conectar directamente , pero es recomendable amplificar la señal. Características MG811 4.2.23 AQ-104 Para calidad del aire. Características AQ-104 4.2.24 AQ-2 Sensitivo para gases inflamables y humos Características AQ2 14 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.2.25 AQ-3 Sensitivo para Alcohol, Benceno Características AQ3 4.2.26 AQ-7 Sensitivo para Monóxido de Carbono Características AQ7 4.3 OTROS FORMATOS Azzure, Pachube - NO USADOS 4.4 COMUNICACIÓN PUERTO SERIE A través de este tipo de puerto la comunicación se establece usando un protocolo de transmisión asíncrono. En este caso, se envía en primer lugar una señal inicial anterior al primer bit de cada byte, carácter o palabra codificada. Una vez enviado el código correspondiente, se envía inmediatamente una señal de stop después de cada palabra codificada. La señal de inicio (start) sirve para preparar al mecanismo de recepción o receptor, la llegada y registro de un símbolo, mientras que la señal de stop sirve para predisponer al mecanismo de recepción para que tome un descanso y se prepare para la recepción del nuevo símbolo. La típica transmisión start-stop es la que se usa en la transmisión de códigos ASCII a través del puerto RS-232, como la que se establece en las operaciones con teletipos. El puerto serie RS-232 (también conocido como COM) es del tipo asincrónico, utiliza cableado simple desde 3 hilos hasta 25 y conecta computadoras o microcontroladores a todo tipo de periféricos, desde terminales a impresoras y módems pasando por mouses. La interfaz entre el RS-232 y el microprocesador generalmente se realiza mediante el chip UART 8250 (computadoras de 8 y 16 bits, PC XT) o el 16550 (IBM Personal Computer/AT y posteriores). El RS-232 original tenía un conector tipo DB-25, sin embargo la 15 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado mayoría de dichos pines no se utilizaban, por lo que IBM estandarizó con su gama IBM Personal System/2 el uso del conector DB-9 (ya introducido en el AT) que se usaba, de manera mayoritaria en computadoras. Sin embargo, a excepción del mouse, el resto de periféricos solían presentar el DB-25 Ilustración 111 Serial 4.4.1 PUERTOS SERIE MODERNOS Uno de los defectos de los puertos serie iniciales era su lentitud en comparación con los puertos sin embargo, con el paso del tiempo, aparecieron multitud de puertos serie de alta velocidad Por ello, el puerto RS-232, se está sustituyendo reemplazándose por los nuevos puertos serie como el USB, el FireWire o el Serial ATA. 4.4.2 USB ESTÁNDAR Ilustración 112 USB logo Universal Serial Bus USB Icon.svg Símbolo USB Tipo Bus Diseñador : Ajay Bhatt, Intel1 Diseñado en: Enero 1996 16 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Fabricante:IBM, Intel, Northern Telecom, Compaq, Microsoft, Digital Equipment Corporation y NEC Sustituye a:Puerto serie, puerto paralelo, puerto de juegos, Apple Desktop Bus, PS/2 Sustituido por: Universal Serial Bus High Speed Especificaciones Longitud: 5 metros (máximo) Ancho: 11,5 mm (conector A), 8,45 mm (conector B) Alto_ 4,5 mm (conector A), 7,78 mm (conector B, antes de v3.0) Conectable en caliente :Sí Externo :Sí Eléctrico 5 voltios CC Voltaje máximo 5 voltios Corriente máxima: 500 a 900 mA (depende de la versión) Señal de Datos :Paquete de datos, definido por las especificaciones Ancho: 1 bit Ancho de banda: 1,5/12/480/5.000 Mbit/s (depende de la versión) Max nº dispositivos: 127 Protocolo: Serial Cable: 4 hilos en par trenzado; 8 en USB 3.0 Pines: 4 (1 alimentación, 2 datos, 1 masa) Conector: Único 17 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.4.2.1 PATILLAJE Ilustración 113 Patillaje Pin 1 VCC (+5 V) Pin 2 Data- Pin 3 Data+ Pin 4 Masa 4.5 MODULOS INALAMBRICOS Zona de Fresnel se le llama al volumen de espacio entre emisor y receptor RF de manera que el desfase entre las ondas en dicho volumen no supere los 180º. 18 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 114 Zona Fresnel En color gris se representa a la primera zona de fresnel. Es decir para conseguir comunicarnos a una distancia D con una señal portadora de frecuencia f, debemos conseguir que la altura r de la primera zona de Fresnel (o al menos el 80% de r) esté libre de obstáculos. Ilustración 115 Módulos alámbricos vs. Inalámbricos. 19 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.5.1 COMUNICACIÓN XBEE Las comunicaciones Zigbee se realizan en la banda libre de 2.4GHz. A diferencia de bluetooth no utiliza FHSS (Frequency hooping), sino que realiza las comunicaciones a través de una única frecuencia, es decir, de un canal. Normalmente puede escogerse un canal de entre 16 posibles. El alcance depende de la potencia de emisión del dispositivo así como el tipo de antenas utilizadas (cerámicas, dipolos, …) El alcance normal con antena dipolo en visión directa suele ser aproximadamente (tomando como ejemplo el caso de MaxStream, en la versión de 1mW de potencia) de 100m y en interiores de unos 30m. La velocidad de transmisión de datos de una red Zigbee es de hasta 256kbps. Por último decir que una red Zigbee la pueden formar, teóricamente, hasta 65535 equipos, es decir, el protocolo está preparado para poder controlar en la misma red esta cantidad enorme de dispositivos. La realidad es menor, siendo, de todas formas, de miles de equipos. Existen 2 series de estos módulos. La serie 1 y la serie 2 o también conocida como 2.5. Los módulos de la Serie 1 y la Serie 2 tienen el mismo pin-out, sin embargo, NO son compatibles entre sí ya que utilizan distintos chipset y trabajan con protocolos diferentes. La serie 1 está basada en el chipset Freescale y está pensado para ser utilizado en redes punto a punto y punto a multipunto. Los módulos de la serie 2 están basados en el chipset de Ember y están diseñados para ser utilizados en aplicaciones que requieren repetidores o una red mesh. Ambos módulos pueden ser utilizados en los modos AT y API. 20 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.5.2 XBEE 1MW – SERIE 1 Ilustración 116 Serie 1 - 250kbps máxima velocidad de datos - 1mW de salida (0 dBm) - 100m rango línea abierta, 30 metros en interiores - 6 pines de 10bits para entrada ADC - 8 pines de E / S digitales 4.5.3 XBEE 2MW – SERIE 2 Ilustración 117 Serie 2 - 250kbps máxima velocidad de datos - 2mW de salida (+3 dBm) - 120m rango línea abierta, 40 metros en interiores - 6 pines de 10bits para entrada ADC 21 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado - 8 pines de E / S digitales Ilustración 118 Xbee 4.5.4 ARQUITECTURA BÁSICA DE UNA RED XBEE. Una red Zigbee la forman básicamente 3 tipos de elementos. Un único dispositivo Coordinador, dispositivos Routers y dispositivos finales (end points). Los módulos XBee son versátiles a la hora de establecer diversas topologías de red, dependiendo la serie de XBee que escojamos pueden crearse redes: El Coordinador: Es el nodo de la red que tiene la única función de formar una red. Es el responsable de establecer el canal de comunicaciones (como hablábamos antes) y del PAN ID (identificador de red) para toda la red. Una vez establecidos estos parámetros, el Coordinador puede formar una red, permitiendo unirse a él a dispositivos Routers y End Points. Una vez formada la red, el Coordinador hace las 22 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado funciones de Router, esto es, participar en el enrutado de paquetes y ser origen y/o destinatario de información. Los Routers: Es un nodo que crea y mantiene información sobre la red para determinar la mejor ruta para enrutar un paquete de información. Lógicamente un router debe unirse a una red Zigbee antes de poder actuar como Router retransmitiendo paquetes de otros routers o de End points. End Device: Los dispositivos finales no tienen capacidad de enrutar paquetes. Deben interactuar siempre a través de su nodo padre, ya sea este un Coordinador o un Router, es decir, no puede enviar información directamente a otro end device. Normalmente estos equipos van alimentados a baterías. El consumo es menor al no tener que realizar funciones de enrutamiento. Ilustración 119 Redes Xbee Los módulos XBee son versátiles a la hora de establecer diversas topologías de red, dependiendo la serie de XBee escogida puede crea redes: 1. Punto a punto 2. Estrella 3. Malla 4. Árbol 23 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5. Mixtas 4.5.5 MODOS RECIBIR/TRANSMITIR. Se encuentra en estos modos cuando al módulo le llega algún paquete RF a través de la antena(modo Receive) o cuando se manda información serial al buffer del pin 3 (UART Data in) que luego será transmitida (modo Transmit). La información transmitida puede ser Directa o Indirecta. En el modo directo la información se envía inmediatamente a la dirección de destino. En el modo Indirecto la información es retenida durante un período de tiempo y es enviada sólo cuando la dirección de destino la solicita. Además es posible enviar información por dos modos. Unicast y Broadcast. Por el primero, la comunicación es desde un punto a otro, y es el único modo que permite respuesta de quien recibe el paquete RF, es decir, quien recibe debe enviar un ACK (paquete llamado así, y que indica que recibió el paquete, el usuario no puede verlo, es interno de los módulos) a la dirección de origen. Quien envió el paquete, espera recibir un ACK, en caso de que no le llegue, reenviará el paquete hasta 3 veces o hasta que reciba el ACK. En el modo Broadcast la comunicación es entre un nodo y a todos los nodos de la red. En este modo, no hay confirmación por ACK. Modo de Bajo Consumo (Sleep Mode). El modo de sueño hace posible que el módulo RF entre en un modo de bajo consumo de energía cuando no se encuentra en uso. Modo de Comando. Este modo permite ingresar comandos AT al módulo Xbee, para configurar, ajustar o modificar parámetros. Permite ajustar parámetros como la dirección propia o la de destino, así como su modo de operación entre otras cosas. Para poder ingresar los comandos AT es necesario utilizar un Hyperterminal como el programa CoolTerms. 24 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Idle Cuando el módulo no se está en ninguno de los otros modos, se encuentra en éste. Es decir, si no está ni transmitiendo ni recibiendo, ni ahorrando energía ni en el modo de comandos, entonces se dice que se encuentra en un estado al que se le llama IDLE. Xbee Shield El XBee shield para Arduino permite comunicar tu Arduino de forma inalámbrica usando ZigBee. 4.5.6 MÁS FUNCIONES El protocolo 802.15.4 no sólo permite la comunicación punto a punto, también permite comunicarse punto-a-multipunto. Si tiene más de dos XBees y los puso a todos a la misma PAN ID (con ATID) y luego ponga la dirección de destino bajo de la emisora a FFFF (con ATDL FFFF). Ahora, al escribir en el terminal del XBee emisor, debemos ver el texto en todas las otras estaciones terminales. +++ Enter command mode. ATRE Reset to factory defaults. ATID Get/set the radio’s PAN (Personal Area Network) ID. Radios working together must be in the same PAN. ATBD Get/set baud rate for the radio. ATCH Get/set the channel the radio will use to transmit/receive. ATMY Get/set a radio’s unique receive address. ATDL Get/set a radio’s transmission destination address. ATWR Write changes to the radio’s non-volatile memory. ATCN Exit command mode. Comandos ATBD: 25 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1 = 2400bps 2 = 4800bps 3 = 9600bps (Si se quiere configurar el BaudRate a 9600bps, ATBD 3.) 4 = 19200bps 5 = 38400bps 6 = 57600 bps 7 = 115200 bps El estándar de comunicaciones 802.15.4 define el hardware y software de las capas physical (Phy) y media access control (MAC). Cada capa es responsable de una serie de funciones necesarias para la comunicación, ZigBee añade capas sobre las dos capas anteriores del 802.15.4, una capa no sabe nada sobre la capa que está por encima de ella y cada capa que añadimos añade una serie de funciones a la base de las inferiores. Ilustración 120 Trama Xbee Cualquier dispositivo de un fabricante que soporte este estándar de comunicaciones y pase la certificación correspondiente, podrá comunicarse con otro dispositivo de otro fabricante distinto. Un dispositivo ZigBee estaría formado por una radio según el estándar 802.15.4 conectada a un microcontrolador con la pila (stack) de ZigBee, donde se implementan las capas por encima de las del 802.15.4. Esta pila está diseñada para poder ser implementada en microcontroladores de 8 bits. Características de las redes/dispositivos ZigBee serían las siguientes: 26 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Velocidad de transmisión entre 25-250 kbps. Protocolo asíncrono, half duplex y estandarizado, permitiendo a productos de distintos fabricantes trabajar juntos. Se pueden formar redes que contengan desde dos dispositivos hasta cientos de ellos. Los dispositivos de estas redes pueden funcionar en un modo de bajo consumo, lo que supone años de duración de sus baterías. Opera en la frecuencia de 2.4 GHz (16 canales) y también en las frecuencias de 868 MHz y 915 MHz. Es un protocolo fiable, la red se organiza y se repara de forma automática y se rutean los paquetes de manera dinámica. Es un protocolo seguro ya que se puede implementar encriptación y autentificación. Se puede decir que ZigBee ocupa el vacío que hay por debajo de Bluetooth, para comunicaciones de datos que no requieren altas velocidades. Una comparativa con Wifi y Bluetooth: 27 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 121 Comparativa wifi Zig Blue Los campos de aplicación de ZigBee son muchos, todos en los que se requiera transmitir comandos o recoger lectura de sensores, etc.. y no interese o no sea práctico usar cables. Campos de aplicación pueden ser: Agricultura: redes de sensores de bajo consumo en el campo para medir y recoger distintos parámetros. Domótica, automatización de edificios y hogares, control industrial. Atención sanitaria: recoger información de sensores en los pacientes, un ejemplo puede ser la ropa inteligente. Control remoto de electrónica de consumo, como el mando de la televisión, luces, etc 28 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 122 Usos ZigBee 29 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.5.7 MÓDULOS PRO Ilustración 123 Comparativa con la serie PRO 4.5.8 DIGI EN ESPAÑA, LOGROÑO, LA RIOJA. Cabe destacar que esta empresa puntera en la tecnología usada en este proyecto, tiene su única sucursal española en la ciudad de Logroño. 30 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 124 Digi Logo Digi International Spain S.A. Milicias 13 - Bajo E-26003 Logroño (La Rioja) - España Phone:+34-941-27-00-60 , Fax:+34-941-23-77-70 4.5.9 LIBRERIA SERIAL. COMUNICACIONES PUERTO SERIE Enlaces a todos los eventos que se precisarán de la librería SERIAL. SserialEvent() readBytes() lastChar() available() readBytesUntil() buffer() read() readString() last() readChar() readStringUntil() bufferUntil() write() clear() stop() 31 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.5.10 CREACIÓN DE UN TIMELINE Tanto como para la documentación del proyecto como para presentaciones se ha usado el sistema de diapositivas TimelineJS. Una herramienta de código abierto que permite a cualquier persona crear líneas de tiempo interactivas. Se pueden crear con una spreadsheet49 de Google. También se pueden importar datos de JSON. Mediante el proyecto : http://timeline.knightlab.com Y se va a “crear nuestra propia hoja de cálculo” Ilustración 125 Timeline Ese enlace lleva a la cuenta de google del usuario: 49 Similar a una hoja de cálculo de Google. 32 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 126 Cuenta de google timeline Se hace que el resultado sea “publico” para poder acceder a los enlaces desde entornos externos. Y se guarda “Publicar en web”. También se podrá exportar en el futuro como pdf, o cualquier otro formato que se necesite tal y como se adjuntará en memoria. 33 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 127 Publicación web Se usa este enlace en la web de TimelineJS Ilustración 128 Resultado del código Y se usa el código embebido resultante. Iframe es todavía válido para html5. 34 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.6 GPS Se adjunta información básica ( mediante links ) de los GPS probados y no usados, como información más extensa del GPS definitivo usado para este proyecto. Ilustración 129 GPS 3DR Características Aquí. Ilustración 130 GPS GTPA 010 Características Aquí. 4.6.1 GPS GTPA 013 – BASADO EN MTK3339 Tiene una alta sensibilidad (-165dBm!), funciona con 5V y puede ser pinchado directamente sobre una protoboard sin mayor complicación. Puede alcanzar una velocidad de refresco de hasta 10Hz (programable) y soporta hasta 66 canales para capturar hasta 22 satélites simultáneamente. Por si fuera poco, tiene la posibilidad de incluir una pequeña batería de backup (no incluida) y un diseño muy atractivo. 35 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Está construido a partir del chip MTK3339, un GPS de alta calidad y grandes prestaciones con antena integrada y que consume tan solo 20mA. Desarrollan con el bricogeek.com, que son distribuidores oficiales de Adafruit.com plataforma que desarrolla kits de montaje completos para desarrollo e incluso distribuciones Occidentalis) de Linux para Raspberry Pi. Ilustración 131 GTPA 013 de Adafruit -165 dBm sensitivity, 10 Hz updates, 66 channels 5V friendly design and only 20mA current draw Breadboard friendly + two mounting holes RTC battery-compatible Built-in datalogging PPS output on fix We have received reports that it works up to ~32Km altitude (the GPS theoretically does not have a limit until 40Km) Internal patch antenna + u.FL connector for external active antenna Fix status LED 36 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.6.2 DETALLES TÉCNICOS Satellites: 22 tracking, 66 searching Patch Antenna Size: 15mm x 15mm x 4mm Update rate: 1 to 10 Hz Position Accuracy: < 3 meters (all GPS technology has about 3m accuracy) Velocity Accuracy: 0.1 meters/s Warm/cold start: 34 seconds Acquisition sensitivity: -145 dBm Tracking sensitivity: -165 dBm Maximum Altitude for PA6H: according to the factory, this module will perform up to 40Km but it is only known-tested up to 32,000 Meters Maximum Velocity: 515m/s Vin range: 3.0-5.5VDC MTK3339 Operating current: 25mA tracking, 20 mA current draw during navigation Output: NMEA 0183, 9600 baud default DGPS/WAAS/EGNOS supported FCC E911 compliance and AGPS support (Offline mode : EPO valid up to 14 days ) Up to 210 PRN channels Jammer detection and reduction Multi-path detection and compensation Firmware version 5153 37 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Breakout board details: Weight (not including coin cell or holder): 8.5g Dimensions (not including coin cell or holder): 25.5mm x 35mm x 6.5mm / 1.0" x 1.35" x 0.25" 4.6.3 DESCARGAS DE HOJAS TECNICAS DRIVERS Y SOFTWARE MTK3329/MTK3339 command set sheet for changing the fix data rate, baud rate, sentence outputs, etc! Datasheet for the PA6B (MTK3329) GPS module itself - used in version 1 of this module Datasheet for the PA6C (MTK3339) GPS module itself - used in version 2 of this module Datasheet for the PA6H (MTK3339) GPS module itself - used in version 3 of this module MT3339 GPS PC Tool (windows only) and the PC Tool manual Mini GPS tool (windows only) 4.6.4 PROTOCOLO NMEA Se usará el Formato de datos "complejo": Consiste en un bloque de datos de 37 bytes de (generalmente) texto legible ASCII que da el error “cross-track”, proporciona un waypoint, presenta la Lat / Long actual, y un byte binario de estado. Byte Datos Bajo la norma NMEA-0183 1$ 2 M | dispositivo 3 P | dirección 38 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4 K = kilómetros | cross track N = millas náuticas | error U = microsegundos | unidades 5 - 8 0 - 9 o . valor del error “cross track” 9 L o R posición del error “cross track” 10 T o M presentación cierta o magnética 11 - 13 0 - 9 proporciona el siguiente waypoint 14 - 23 12D34'56"N o latitud actual 12D34.56'N 24 - 34 123D45'56"W o longitud actual 123D45.67"W 35 byre de estado no - ASCII bit 0 = 1 para la cerradura manual de ciclo 1 = 1 SNR bajo 2 = 1 salto de ciclo 3 = 1 parpadea 4 = 1 alarma de llegada 5 = 1 discontinuidad de TDs 6 = 1 siempre 36 carácter “NUL" (hex 80) (byte de estado reservado) 37 carácter "ETX" (hex 83) Cualquier dato no disponible se llena de bytes "NUL". 4.6.5 RECEPCIÓN E INTERCAMBIO DE DATOS DEL GPS Una vez interpretado el protocolo del GPS existen diferentes formatos para mostrar los datos: UTM COORDINADAS A diferencia del sistema de coordenadas geográficas, expresadas en longitud y latitud, las magnitudes en el sistema UTM se expresan en metros únicamente al nivel del mar, que es la base de la proyección del elipsoide de referencia. 39 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado COORDENADAS GEOGRÁFICAS (LATITUD, LONGITUD) 1. Hemisferio. 2. DMS Grados, minutos y segundos 3. DMM Grados y minutos decimales 4. DDD Grados decimales 4.7 ANEJOS NO IMPRESOS PRESENTADOS EN FORMATO DIGITAL ENLAZADO Listado de Anejos y documentación extra no presentada en formato papel. Descartada su impresión por no aportar información imprescindible para la ejecución del proyecto. Simple consulta informativa. Se presentarán enlazados los documentos, PDF principalmente que el autor de este PFC ha consultado pero no ha realizado en parte o en su totalidad. 4.7.1 CUADRO NACIONAL DE ATRIBUCIÓN DE FRECUENCIAS (CNAF) CNAF 2013. Listado de frecuencias permitidas para España. Espectro radioeléctrico Ilustración 132 Radiofrecuencias. Anexo a la orden: Cuadro Nacional de Atribución de Frecuencias [PDF] Notas del artículo 5 del Reglamento de Radiocomunicaciones [PDF] Tablas de atribución de frecuencias [PDF] 40 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Notas de utilización nacional (UN) [PDF] Figuras de canalizaciones y/o disposición de bandas de frecuencias [PDF] Plan de PLAN DE BANDAS DE LA IARU REGIÓN 1 4.7.2 SOLUCIONES WIFI DE LARGO ALCANCE Cámaras IP Cámaras inalámbricas Soluciones wifi de largo alcance de vivotek aplicadas a cámaras IP 4.7.3 CONFIGURACIÓN CON VERSIÓN CLÁSICA Para poder utilizar los módulos lo primero es configurarlos, para ello se tiene que bajar el X-CTU de la página de Digi, con él se puede cambiar el firmware de los módulos XBee, también se puede usar como terminal serie para mandar y recibir datos por el módulo desde el PC. Se baja e instala el programa, diciendo que NO a las actualizaciones si el sistema pregunta. Se conecta la placa XBee Explorer USB con uno de los módulos XBee al puerto USB y abrimos el programa X-CTU. 41 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 133 XCTU clásico Se dejan todos los parámetros de la comunicación serie como vienen por defecto, seleccionando el puerto donde está conectado el módulo al y se pulsa a Test/Query para probar el módulo. Si todo está bien devolverá algo como esto: 42 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 134 Versión clásica XCTU Un cuadro de diálogo donde se puede ver el tipo de módulo que se ha pinchado en la XBee Explorer USB, la versión del programa interno del microcontrolador que lleva grabada y su número de serie. Este número de serie de los módulos es único, es decir no hay dos módulos ZigBee con el mismo número de serie igual. 43 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 135 XCTU clásico 4.7.4 CONFIGURACIÓN CON VERSIÓN ACTUALIZADA 2014 Hubo cambios en el software mediante se trabajaba con este PFC y al final se usó esta nueva versión de XCT-U para la configuración de los módulos tanto emisor como receptor. Pasos de Configuración 44 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Arriba derecha. Se pulsa para que busque dispositivos Se marca el deseado y se pulsa seguir Ilustración 136 XCTU versión 2014 Ilustración 137 XCTU versión 2014 Selecciono principalmente la velocidad de configuración de todo el sistema 45 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 138 XCTU versión 2014 Se pulsa “finish” El sistema busca automáticamente el nodo principal. Ilustración 139 XCTU versión 2014 Si no detecta nada, se repite la operación. Se extrae el cable con el software encendido y se prueba de nuevo. Se recomienda usar otra frecuencia: 57600 y hacer lo mismo. Usar dos frecuencias para luego poder elegir. 46 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 140 XCTU versión 2014 Se pulsa en “añadir dispositivo” Una vez que está en la red. Es el que tengo conectado. Se le dice al sistema que busque otros. Ilustración 141 XCTU versión 2014 Se pulsa “Discover” Ilustración 142 XCTU versión 2014 47 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado NOTA IMPORTANTE. Si se desconfigura un módulo cualquiera habrá que calibrar de nuevo los dos módulos. Pinchando primero el modulo emisor en modo USB al ordenador y luego el receptor. Una vez configurados ambos dispositivos en frecuencias no habrá que volver a configurarlos si no se cambia el modo de comunicaciones. Es decir, este proceso, solo habrá que hacerlo una vez para cada instalación. 4.8 IMPORTAR UNA LIBRERÍA PARA FRITZING Para hacer los esquemas más precisos se ha usado este software de edición de circuitos, pero algunas librerías no vienen por defecto. Si se quiere que todos los componentes estén en las librerías gráficas habrá que hacer nuevas importaciones. Añadir e importar una librería. Ejemplo: la de Adafruit : Aquí Se descarga la librería en rar.se descomprimo. Abro el Fritzing. Use "File | Open", navigate to the AdaFruit.fzbz file and open it. 48 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.9 LISTADO DE CODIGOS Se adjuntarán solo algunas de las funciones más importantes Se presentan a continuación algunos de los códigos usados en Arduino. Sólo las funciones principales. Si se imprimieran todas las líneas de código serán varios cientos de páginas y no aportaría nada al documento, si no que sería más farragosa su lectura. Los archivos se presentarán en formato digital y se duplicarán online. 4.9.1 FUNCIONES BÁSICAS DE ARDUINO Se adjuntan las funciones básicas para lecturas de cada sensor en el Documento de Especificaciones del Sistema. 4.9.1.1 LOCALIZAR LA IP DE MI ARDUINO – DHCP Con esta función que adjunta se consigue la IP de mi Arduino en el momento de conectarlo a internet directamente al pasarlo por el Router. Son los datos propios dentro de mi red. IP que asignaré a mi Arduino para que sea única dentro de mi subred. Otra opción es autoasignar IP. DHCP50. Pero al haber varios ordenadores conectados, a la vez que trabajar con diferentes ordenadores portátiles y tabletas es conveniente hacer este paso. #include <SPI.h> #include <Ethernet.h> // me da como resultado la IP de ethernet arduino dentro de mi red particular // desde el router movistar en abril 2014 : 192.168.1.33 // desde el router yacom 192.168.1.10 // datos necesarios // Busco y convierto la MAC de mi Arduino. Dirección única // Cada Arduino tiene su número de MAC debajo de la placa byte mac[] = { 0x90, 0xA2, 0xDA, 0x0D, 0x69, 0xDB }; //mac de arduino garba abril 2014 50 Dynamic Host Configuration Protocol 49 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado EthernetClient client; void setup() { Serial.begin(9600); // start the serial library: if (Ethernet.begin(mac) == 0) // start the Ethernet connection: { Serial.println("Fallo en la configuracion DHCP”); for(;;); } Serial.println(Ethernet.localIP());// print your local IP address: } void loop() { } 4.9.1.2 COMUNICACIÓN ARDUINO CON SERVIDORES LOCALES Y REMOTOS //conecto arduino al router directamente para salir a internet sin pasar por el ordenador. #include <SPI.h> #include <Ethernet.h> byte mac[] = { 0x90, 0xA2, 0xDA, 0x0D, 0x69, 0xDB }; 2014 IPAddress ip(192, 168, 1, 33); //la IP de mi arduino //IPAddress server(74,125,232,128); DNS) //char server[] = "www.google.com"; IPAddress server(168,144,87,229); acceso externo //IPAddress server(192, 168, 1, 1 ); :) //IPAddress server(127,0,0,1); //IPAddress server(192,168,1,34); //char server[] = "localhost"; //mac de arduino garba abril // usando la IP numeric IP for Google (no // usando DNS // zainder.com para bases de datos de // mi router . ahi veo que es de telefonica // mi localhost con easyphp 127.0.0.1/home // sumando 10 a la de casa. // usando nombre - no RESUELVE EthernetClient client; void setup() { Serial.begin(9600); // velocidad para puerto serie // start the Ethernet connection: if (Ethernet.begin(mac) == 0) { Serial.println("Fallo en la configuracion DHCP"); // no point in carrying on, so do nothing forevermore: // try to congifure using IP address instead of DHCP: Ethernet.begin(mac, ip); } delay(1000); // DaMos un segundo para inicializar la placa Ethernet: Serial.println("conectando..."); // if you get a connection, report back via serial: if (client.connect(server, 80)) { Serial.println("conectado"); // Make a HTTP request: //client.println("GET /search?q=arduino HTTP/1.1"); //client.println("Host: www.google.com"); client.println("GET http://zainder.com/arduino/arduino.txt"); 50 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado client.println("Cerramos conexion"); client.println(); } else { // if you didn't get a connection to the server: Serial.println("fallo en la conexion");} } void loop() { // if there are incoming bytes available // from the server, read them and print them: if (client.available()) { char c = client.read(); Serial.print(c);} // if the server's disconnected, stop the client: if (!client.connected()) { Serial.println(); Serial.println("desconectamos."); client.stop(); // do nothing forevermore: while(true);} } 4.9.1.2.1 ALGUNOS RESULTADOS DE DIFERENTES CONEXIONES char server[ ] = "www.google.com"; --------------------------------connecting... connected HTTP/1.0 400 Bad Request Content-Type: text/html; charset=UTF-8 Content-Length: 1419 Date: Wed, 30 Apr 2014 10:27:39 GM disconnecting. char server[ ] = "www.zainder.com"; ---------------------------------connecting... connected HTTP/1.1 400 Bad Request Content-Type: text/html Cache-Control: no-cache Connection: close Content-Length: 480 X-Iinfo: 10-556476181-0 0NNN RT(1398853551254 3) q(-1 -1 -1 -1) r(0 -1) <html><head><META NAME="ROBOTS" CONTENT="NOINDEX, NOF disconnecting. 51 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado IPAddress server(192, 168, 1, 1 ); //mi localhost ---------------------------------connecting... connected HTTP/1.1 200 OK Server: Virtual Web 0.9 Set-Cookie: SessionID=; path=/ Content-Type: text/html Content-Length: 151 <html><head><meta HTTP-EQUIV="Pragma" CONTENT="no-cache"><script language='javascript'>parent.location="/login.htm"</script></head><body></body></h tml> disconnecting. HTTP/1.1 200 ok : Means that the server is responding using the HTTP protocol version 1.1. 200 is the code used when everything is ok. 4.9.1.2.2 LECTURAS BÁSICAS Y CONVERSIONES EN ARDUINO ETHERNET #include <Adafruit_GPS.h> #include <SoftwareSerial.h> // Test code for Adafruit GPS modules using MTK3329/MTK3339 driver // Tested and works great with the Adafruit Ultimate GPS module // using MTK33x9 chipset // y para mis operaciones matematicas en flotante. flooooat !! #include <Math.h> byte buffer[] = {0, 1, 2, 3, 4, 5, 6, 7}; //doy unos valores cualesquiera. luego los actualizaré. int signo_Latitud =0, signo_Longitud=0; float mi_latitud_DMM , mi_longitud_DMM; float mi_latitud_DDD , mi_longitud_DDD; //Grados y minutos decimales (DMM): 41 24.2028, 2 10.4418 //Grados decimales (DDD): 41.40338, 2.17403 // muy importante. pines digitales a vigilar // Connect the GPS TX (transmit) pin to Digital 3 // Connect the GPS RX (receive) pin to Digital 2 SoftwareSerial mySerial(3, 2); 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 false // 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 52 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado void setup() { // connect at 115200 so we can read the GPS fast enough and echo without dropping chars // also spit it out Serial.begin(9600); //Serial.println("Adafruit GPS library basic test!"); // 9600 NMEA is the default baud rate for Adafruit MTK GPS's- some use 4800 GPS.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); // 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! useInterrupt(true); delay(1000); //Ask for firmware version //mySerial.println(PMTK_Q_RELEASE); } // 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; 53 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado TIMSK0 |= _BV(OCIE0A); usingInterrupt = true; } else { // do not call the interrupt function COMPA anymore TIMSK0 &= ~_BV(OCIE0A); usingInterrupt = false; } } 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); //para quitar morralla } // 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 } // 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); 54 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado if (GPS.fix) { //lo mio, para processing. ojo lectura compatible y quitar los serial print. mi_latitud_DMM = GPS.latitude; //Serial.println (mi_latitud); //dato 4227.92 mi_longitud_DMM = GPS.longitude; //Serial.println (mi_longitud); //dato 225.59 //fin de los datos que voy a enviar. 8 bytes en total. dos floats. //Serial.print("Location: "); //Serial.print(GPS.latitude, 4); //dato 4227.9155 //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); } } // fin de recogida de datos del GPS - comienzo codigo para enviar datos mi_latitud_DMM = 4227.92f ; mi_latitud_DDD = convertDegMinToDecDeg(mi_latitud_DMM); //Serial.println (mi_latitud_DDD ); mi_longitud_DMM = 225.59f ; mi_longitud_DDD = convertDegMinToDecDeg(mi_longitud_DMM); //Serial.println (mi_longitud_DDD ); float decima1_Latitud = mi_latitud_DDD; float decimal_Longitud = mi_longitud_DDD * (-1); tema de conversiones. porque yo trabajo sin signo // 42.4652f ; no le hago nada // -2.4261f; * (-1) por el //convierto LATITUD DDD 42.4650 a lo que recojo en processing----------------------------------------------//lo primero de todo compruebo el signo. y ajusto. cojo un valor para mi signo y cambio el numero. if (decima1_Latitud < 0 ){ signo_Latitud = 1; //1 es negativo decima1_Latitud = decima1_Latitud * (-1); //lo pongo positivo para trabajar bien con el. } else signo_Latitud = 0; //Serial.println (decima1_Latitud); //parte entera la misma int parte_enteraA = (int) decima1_Latitud; //parte enetera = 42 seran los grados int grados_Latitud = parte_enteraA; //grados = 42 - primer byte //Serial.println (grados_Latitud); //parte enetera = 42 float quito_parte_entera = (decima1_Latitud - parte_enteraA ) *10000 ; // tengo 4650 int parte_enteraB = (int) quito_parte_entera; //Serial.println (parte_enteraB); float parteC = parte_enteraB / 100 ; //Serial.println (parteC); 55 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado int parteD = (int) parteC; //Serial.println (parteD); // 46 - segundo byte int parteE = parte_enteraB % 100 ; //Serial.println (parteE); // 50 - tercer byte //resultados al buffer de Latitudes buffer [0] = grados_Latitud; buffer [1] = parteD; buffer [2] = parteE; buffer [3] = signo_Latitud; //convierto LONGTUD -2.426f -------------------------------------------//lo primero de todo compruebo el signo. y ajusto. cojo un valor para mi signo y cambio el numero. if (decimal_Longitud < 0 ){ signo_Longitud = 1; //1 es negativo decimal_Longitud = decimal_Longitud * (-1); //lo pongo positivo para trabajar bien con el. } else signo_Longitud = 0; //parte entera la misma int parte_enteraF = (int) decimal_Longitud; //parte enetera = 42 seran los grados int grados_Longitud = parte_enteraF; //grados = 42 - primer byte //Serial.println (grados_Longitud); //parte enetera = 42 float quito_parte_enteraZ = (decimal_Longitud - parte_enteraF ) *10000 ; // tengo 4650 int parte_enteraG = (int) quito_parte_enteraZ; //Serial.println (parte_enteraG); float parteH = parte_enteraG / 100 ; //Serial.println (parteH); int parteI = (int) parteH; //Serial.println (parteI); // 46 - segundo byte int parteJ = parte_enteraG % 100 ; //Serial.println (parteJ); // 50 - tercer byte //resultados al buffer buffer buffer buffer buffer [4] [5] [6] [7] = = = = grados_Longitud; parteI; parteJ; signo_Longitud; //escribo de un tiron el buffer completo , tenga los componentes que tenga. //asi y solo asi, se escribe en puerto serie para envio de bytes Serial.write(buffer, sizeof(buffer) ); delay(1000); } // Funcion para convertir los datos de Latitud longitud DMM de Adafruit // parte del formato grados y minutos decimales a grados decimales // no me interesa grados minutos segundos pq luego en processing tendrÃ-a que convertirlo otra vez // processing como google DDD. // DDM a DDD // Grados y minutos decimales (DMM): 41 24.2028, 2 10.4418 56 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado // Grados decimales (DDD): 41.40338, 2.17403 double convertDegMinToDecDeg (float degMin) { // me vendrá un varlo en grados y minutos decimales. DMM double min = 0.0; //ojo, poner 0.0 o 0.0f double decDeg = 0.0; //para los minutos, fmod() requiere trabajar siempe con doubles min = fmod((double)degMin, 100.0); //se devuelven las coordenadas en grados decimales DDD degMin = (int) ( degMin / 100 ); decDeg = degMin + ( min / 60 ); return decDeg;} 57 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.9.2 FUNCIONES BÁSICAS DE PROCESSING Se adjuntarán solo algunas de las funciones más importantes Se presentan a continuación algunos de los códigos usados en Processing. Sólo las funciones principales. Si se imprimieran todas las líneas de código serán varios cientos de páginas y no aportaría nada al documento, si no que sería más farragosa su lectura. Los archivos se presentarán en formato digital y se duplicarán online. 4.9.2.1 CONSOLA 1 4.9.2.1.1 VARIABLES DE CONFIGURACIÓN // Declaro las variables aqui. antes del codigo. // variables de configuraciones import processing.serial.*; //Importamos la librería Serial import gifAnimation.*; Serial puerto; //Nombre del puerto serie String COM_serie = "COM5"; //Serial.list()[1]; //se corresponde al com5 . ejecutar y mirar esto cada vez int baudios = 9600; //variables de datos, ficheros, etc int datos1 , datos2 , datos3; int dato_critico = 50; //dato por el cual el color del punto pasa a ser rojo y el termometro o lo que sea, se pone full float datos4; PrintWriter fichero; //Para crear el archivo de texto donde guardar los datos //variables para dibujar int pantalla_ayuda = 0 ; int paramostrarimagenes = 0 ; int recX = 0; int size_punto = 5 ; // tamaño del punto a dibujar int dist_recX = 5; //distancia para el siguiente punto en X int lienzo_sizeX = 800, lienzo_sizeY = 600; //tamaño del lienzo int size_cuadricula = 20 ; //tamaño de los cuadraditos. los cambio con teclado int textX = 10, textY =10 , lineas =1; //para sacar los datos en formato gráfico. int convert_dato , dato_a_dibujar; //imagenes de archivo para consola- estructura PImage medida_Bajo, medida_Mitad, medida_Alto , medida_Alto_Luz , medida_Bajo_Luz , medida_Mitad_Luz; 58 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado int size_imagen_termoX = 100, size_imagen_termoY = 200, size_imagen_bombillaX = 300, size_imagen_bombillaY = 200 ; //163 * 371 el termo float reduce_images = 2.6 ; //valor para ajustar imagenes al lienzo 2= grandes. //eventos de teclado boolean teclaB = false ; 4.9.2.1.2 PARTE DE LA FUNCIÓN MAIN void setup() { //configuracion del puerto serie puerto = new Serial(this, COM_serie, baudios); variables - (this, "COM5", 9600); puerto.buffer(3); //para preparar para 3 datos //otra forma de ponerlo con //configuraciones del fichero para guardar datos fichero = createWriter("temperatura_datos.txt"); //Creamos el archivo de texto, que es guardado en la carpeta del programa //imagenes de medida_Alto into the program medida_Bajo into the program medida_Mitad into the program archivo para consola- estructura = loadImage("imagenes/3medidores-Alto.png"); 163*371 = loadImage("imagenes/3medidores-Bajo.png"); = loadImage("imagenes/3medidores-Medio.png"); medida_Alto_Luz into the program 250 medida_Bajo_Luz into the program medida_Mitad_Luz into the program // Load the image // Load the image // Load the image = loadImage("imagenes/3luces-Alto.png"); * 350 = loadImage("imagenes/3luces-Bajo.png"); // Load the image = loadImage("imagenes/3luces-Medio.png"); // Load the image // Load the image //configuracion del lienzo para dibujar size(lienzo_sizeX,lienzo_sizeY); //tamaño del lienzo dibuja_fondo (); // fondo } 4.9.2.1.3 FUNCIONES PARA DIBUJAR FONDOS Y REJILLAS //funciones ----------------------------------------------------------///--------------------------------------------------------------------fin de evento de puerto serie int serialEvent(Serial puerto_serie) { datos1 = puerto_serie.read(); //este sistema funciona mejor. es una INT. solo tener cuidado al poner el buffer. println( "datos1: " + datos1); //solo sacp datos por consola par comprobacion. 59 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado datos2 = println( datos3 = println( puerto_serie.read(); "datos2: " + datos2); puerto_serie.read(); "datos3: " + datos3); return datos1 + datos2 + datos3; // me devuelve los X datos que tenga en el buffer. en el orden de envio. FIFO. //datos1 = temperatura ; datos2 = Lectura LDR ; datos3= sonda NT } //--------------------------------------------------------------------fin de evento de puerto serie void dibujar_por_pantalla_todo (int dato_a_dibujar) { //dibujo por pantalla ---------------------------------------------------//dibujo una imagen segun la lectura de los datos. if ( (dato_a_dibujar >= 0) && (dato_a_dibujar <= 30) ){ image(medida_Bajo, lienzo_sizeX - size_imagen_termoX , lienzo_sizeY -size_imagen_termoY, medida_Bajo.width/reduce_images, medida_Bajo.height/reduce_images); //la coloco cambiandole el tamaño. tint(255, 126); } else if ((dato_a_dibujar >= 31) && (dato_a_dibujar <= 50) ) { image( medida_Mitad, lienzo_sizeX - size_imagen_termoX, lienzo_sizeY -size_imagen_termoY, medida_Mitad.width/reduce_images, medida_Mitad.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. else if ((dato_a_dibujar >= dato_critico) && (dato_a_dibujar <= 9999999) ) { image(medida_Alto, lienzo_sizeX - size_imagen_termoX, lienzo_sizeY -size_imagen_termoY, medida_Alto.width/reduce_images, medida_Alto.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. if ( (dato_a_dibujar >= 0) && (dato_a_dibujar <= 30) ){ image(medida_Bajo_Luz, lienzo_sizeX - size_imagen_bombillaX , lienzo_sizeY -size_imagen_bombillaY, medida_Bajo_Luz.width/reduce_images, medida_Bajo_Luz.height/reduce_images); //la coloco cambiandole el tamaño. //tint(255, 126); } else if ((dato_a_dibujar >= 31) && (dato_a_dibujar <= 50) ) { image( medida_Mitad_Luz, lienzo_sizeX - size_imagen_bombillaX, lienzo_sizeY -size_imagen_bombillaY, medida_Mitad_Luz.width/reduce_images, medida_Mitad_Luz.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. else if ((dato_a_dibujar >= dato_critico) && (dato_a_dibujar <= 9999999) ) { image(medida_Alto_Luz, lienzo_sizeX - size_imagen_bombillaX, lienzo_sizeY -size_imagen_bombillaY, medida_Alto_Luz.width/reduce_images, medida_Alto_Luz.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. 60 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado convert_dato = lienzo_sizeY/2 - dato_a_dibujar ; //para dibujar de abajo a arriba . justo en la mitad ellipse(recX, convert_dato , size_punto, size_punto); if (dato_a_dibujar >= dato_critico) {fill (193,15,27); } else { fill(0,128,0); } //rojo o verde. //si se pasa en X del lienzo reseteo. y resto de variables. if (recX > lienzo_sizeX ) { dibuja_fondo (); recX = 0; textY =0; textX =0; lineas =0; } recX = recX + dist_recX ; //incremento en X para siguente punto } //fin de dibujar por pantalla ------------------------------------------------ //--------------------------------------------------------------------funcion para dibujar fondo void dibuja_fondo () { background(16776695); //#FFFDF7 int ref_arribaIZDA = 20, ref_arribaDCHA = 20; //referencia para poner una pantalla de medida int desplazoX = lienzo_sizeX / size_cuadricula , desplazoY = lienzo_sizeY / (size_cuadricula -5); //lo que desplazo para dibujar cuadricula int ejeX = 0, ejeY =0; //rect(ref_arribaIZDA, ref_arribaIZDA, 300, 200, //stroke(255); 7); //pantalla de datos //linea 0 y siguientes. stroke(200,200,200); line (ejeX, lienzo_sizeY/2, lienzo_sizeX , lienzo_sizeY/2); stroke(0); fill(0); text("0", 10, lienzo_sizeY/2); for (int i =0 ; i <= lienzo_sizeX/desplazoX ; i ++) { ejeX = ejeX + desplazoX; stroke(200,200,200); line (0, lienzo_sizeY/2 + ejeX, lienzo_sizeX , lienzo_sizeY/2 + ejeX); line (0, lienzo_sizeY/2 - ejeX, lienzo_sizeX , lienzo_sizeY/2 - ejeX); } //linea 0 y siguientes. stroke(200,200,200); line (lienzo_sizeX/2, 0 , lienzo_sizeX/2 , lienzo_sizeY ); for (int i =0 ; i <= lienzo_sizeY/desplazoY ; i ++) { 61 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ejeY = ejeY + desplazoY; stroke(200,200,200); line (lienzo_sizeX/2 + ejeY, 0 , lienzo_sizeX/2 +ejeY , lienzo_sizeY ); line (lienzo_sizeX/2 - ejeY, 0 , lienzo_sizeX/2 -ejeY , lienzo_sizeY ); } } //----------------------------------------------------fin de dibujo fondo----------------------------//------------------------------------------eventos de tecla pulsada----------------------------void keyPressed() { if (keyPressed) { if (key == 'b' || key == 'B') { text(datos3, textX +5 , textY+ 5); //en la pantalla gráfica if (lineas >= 5 ) { textX = textX + 50; textY = 0; lineas = 0; } textY = textY + 10; lineas ++ ; } //---------------fin de dibujo datos de texto con tecla B if (key == 'c' || key == 'C') { size_cuadricula = size_cuadricula + 10; } if (key == 't' || key == 'T') { dato_critico ++; } //---------------fin de dibujo datos de texto con tecla B } } //----------------------------------fin de eventos de tecla pulsada ------------------------------------- //----------------------------------evento de raton pulsado ------------------------------------void mousePressed() { //dibujo datos si raton if (mouseButton == LEFT) { stroke(0); fill(175); rectMode(CENTER); rect(mouseX,mouseY,35,25); stroke(0); fill(0); text(dato_a_dibujar, mouseX-5, mouseY+5); //en la pantalla gráfica 62 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado //fin de dibujo datos de texto con click de raton } if (mouseButton == RIGHT) { pantalla_ayuda = 1; } else pantalla_ayuda =0; } //----------------------------------escribir datos en fichero PLANO------------------------------------void escribir_datos_fichero (int dato_a_escribir) { //Escribimos los datos de la temperatura con el tiempo (h/m/s) en el archivo de texto. mismo directorio fichero.print(dato_a_escribir + " ºC fichero.print(hour( )+":"); fichero.print(minute( )+":"); fichero.println(second( )); fichero.println(""); "); } //----------------------------------escribir datos en fichero ------------------------------------//----------------------------------pantalla de ayuda --------void pantalla_ayuda () { background(16776695); stroke(0); fill(0); text("datos de ayuda, configuraciones", 5, 15); //en la pantalla gráfica // temperatura stroke(0); fill(175); rectMode(CENTER); rect(150,60,35,20); stroke(0); fill(0); text("Dato crítico de Temperatura", 175, 65); //en la pantalla gráfica text(dato_critico, 150-5, 60+5); //en la pantalla gráfica if ( (datos1 >= 0) && (datos1 <= 30) ){ image(medida_Bajo, 50, 50, medida_Bajo.width/reduce_images, medida_Bajo.height/reduce_images); //la coloco cambiandole el tamaño. tint(255, 126); } else if ((datos1 >= 31) && (datos1 <= 50) ) { image( medida_Mitad, 50, 50, medida_Mitad.width/reduce_images, medida_Mitad.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. else if ((datos1 >= dato_critico) && (datos1 <= 9999999) ) 63 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado { image(medida_Alto, 50, 50, medida_Alto.width/reduce_images, medida_Alto.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. } 4.9.2.2 CONSOLA PRINCIPAL 4.9.2.2.1 DECLARACIÓN DE VARIABLES Y CONFIGURACIONES // Declaro las variables aqui. antes del codigo. // variables de configuraciones import processing.serial.*; //Importamos la librería Serial import gifAnimation.*; Serial puerto; //Nombre del puerto serie String COM_serie = "COM5"; //Serial.list()[1]; //se corresponde al com5 . ejecutar y mirar esto cada vez int baudios = 9600; int size_buffer_recepcion_datos = 3; //todo lo relativo a la libreria LP5 de eontorno gráfico. import controlP5.*; ControlP5 cp5; Textarea myTextarea; Println console; Textarea mi__texto_ayuda; public int Aviso_1_Temp = 10 , Aviso_2_Temp = 40; //valors de los slides con muescas public int Temp_Critico = 50; //dato por el cual el color del punto pasa a ser rojo y el termometro o lo que sea, se pone full public int Aviso_1_Luz = 20, Aviso_2_Luz = 30; //valors de los slides con muescas public int Luz_critico = 60 ; //dato por el cual el color del punto pasa a ser rojo y la bombilla o lo que sea, se pone full //variables de datos, ficheros, etc int datos1 , datos2 , datos3; float datos4; PrintWriter fichero; //Para crear el archivo de texto donde guardar los datos //variables para dibujar int ref_arriba = 400; //referencia para poner una pantalla de medida int paramostrarimagenes = 0 ; int recX = 0 , recXX =0; int size_punto = 10 , size_punto_Luz = 2 , size_punto_Temp = 5 ; // tamaño del punto a dibujar int dist_recX = 5; //distancia para el siguiente punto en X int lienzo_sizeX = 1000, lienzo_sizeY = 600; //tamaño del lienzo int size_cuadricula = 30 , size_cuadricula_Temp = 20 , size_cuadricula_Luz = 10 ; //tamaño de los cuadraditos. los cambio con teclado int textX = 10, textY =10 , lineas =1; //para sacar los datos en formato gráfico. int convert_dato , dato_a_dibujar; 64 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado int background_color = 0; //imagenes de archivo para consola- estructura PImage medida_Bajo, medida_Mitad, medida_Alto , medida_Alto_Luz , medida_Bajo_Luz , medida_Mitad_Luz; int size_imagen_termoX = lienzo_sizeX - 20, size_imagen_termoY = lienzo_sizeY, size_imagen_bombillaX = lienzo_sizeX, size_imagen_bombillaY = lienzo_sizeY 200 ; //163 * 371 el termo float reduce_images = 2.6 ; //valor para ajustar imagenes al lienzo 2= grandes. //eventos de teclado boolean teclaB = false ; boolean saca_consola_texto = true; 4.9.2.2.2 ALGUNAS FUNCIONES DEL SISTEMA //funciones ----------------------------------------------------------///--------------------------------------------------------------------fin de evento de puerto serie int serialEvent(Serial puerto_serie) { datos1 = puerto_serie.read(); //este sistema funciona mejor. es una INT. solo tener cuidado al poner el buffer. println( "datos1: " + datos1); //solo sacp datos por consola par comprobacion. datos2 = puerto_serie.read(); println( "datos2: " + datos2); datos3 = puerto_serie.read(); println( "datos3: " + datos3); return datos1 + datos2 + datos3; // me devuelve los X datos que tenga en el buffer. en el orden de envio. FIFO. //datos1 = temperatura ; datos2 = Lectura LDR ; datos3= sonda NT } //--------------------------------------------------------------------fin de evento de puerto serie void dibujar_por_pantalla_temp (int temp_a_dibujar) { //dibujo por pantalla ---------------------------------------------------//dibujo una imagen de termometro segun la lectura de los datos. if ( (temp_a_dibujar >= 0) && (temp_a_dibujar < Aviso_1_Temp) ){ image(medida_Bajo, lienzo_sizeX - size_imagen_termoX , lienzo_sizeY -size_imagen_termoY, medida_Bajo.width/reduce_images, medida_Bajo.height/reduce_images); //la coloco cambiandole el tamaño. tint(255, 126); } else if ((temp_a_dibujar >= Aviso_1_Temp ) && (temp_a_dibujar <= Aviso_2_Temp ) ) { image( medida_Mitad, lienzo_sizeX - size_imagen_termoX, lienzo_sizeY -size_imagen_termoY, medida_Mitad.width/reduce_images, medida_Mitad.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. 65 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado else if ((temp_a_dibujar >= Temp_Critico) && (temp_a_dibujar <= 9999999) ) { image(medida_Alto, lienzo_sizeX - size_imagen_termoX, lienzo_sizeY -size_imagen_termoY, medida_Alto.width/reduce_images, medida_Alto.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. convert_dato = ref_arriba/2 + lienzo_sizeY/2 - temp_a_dibujar ; //para dibujar de abajo a arriba . justo en la mitad ellipse(recX, convert_dato , size_punto_Temp, size_punto_Temp); if (temp_a_dibujar >= Temp_Critico) {fill (193,15,27); } else { fill(0,128,0); } //rojo o verde. //si se pasa en X del lienzo reseteo. y resto de variables. if (recX > lienzo_sizeX / 2 ) { dibuja_fondo (); recX = 0; } recX = recX + size_punto_Temp; //incremento en X para siguente punto //variables demo para pruebas y configuraciones--> borrar println( "temp: " + temp_a_dibujar); } void dibujar_por_pantalla_Luz (int Luz_a_dibujar) { //dibujo por pantalla ---------------------------------------------------//dibujo una imagen de bombilla segun la lectura de los datos. if ( (Luz_a_dibujar >= 0) && (Luz_a_dibujar < Aviso_1_Luz) ){ image(medida_Bajo_Luz, lienzo_sizeX - size_imagen_bombillaX , lienzo_sizeY -size_imagen_bombillaY, medida_Bajo_Luz.width/reduce_images, medida_Bajo_Luz.height/reduce_images); //la coloco cambiandole el tamaño. //tint(255, 126); } else if ((Luz_a_dibujar > Aviso_1_Luz) && (Luz_a_dibujar <= Aviso_2_Luz) ) { image( medida_Mitad_Luz, lienzo_sizeX - size_imagen_bombillaX, lienzo_sizeY -size_imagen_bombillaY, medida_Mitad_Luz.width/reduce_images, medida_Mitad_Luz.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. else if ((Luz_a_dibujar >= Luz_critico) && (Luz_a_dibujar <= 9999999) ) { image(medida_Alto_Luz, lienzo_sizeX - size_imagen_bombillaX, lienzo_sizeY -size_imagen_bombillaY, medida_Alto_Luz.width/reduce_images, medida_Alto_Luz.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. convert_dato = ref_arriba/2 + lienzo_sizeY/2 - Luz_a_dibujar ; //para dibujar de abajo a arriba . justo en la mitad ellipse(lienzo_sizeX/2 + recXX, convert_dato , size_punto_Luz, size_punto_Luz); if (Luz_a_dibujar >= Luz_critico) {fill (193,15,27); } else { fill(#FFFF00); } //rojo o verde. //si se pasa en X del lienzo reseteo. y resto de variables. if (recXX > lienzo_sizeX / 2 ) { 66 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado dibuja_fondo (); recXX = 0; } recXX = recXX + size_punto_Luz; //incremento en X para siguente punto //variables demo para pruebas y configuraciones--> borrar println( "temp: " + Luz_a_dibujar); } //fin de dibujar por pantalla ---------------------------------------//--------------------------------------------------------------------funcion para dibujar fondo void dibuja_fondo () { int color_lineas = #026C9E; int size_grafica_mostrar = 200; int ejeX = 0, ejeY =0; background(background_color); //pantalla del sistema grafico. fill (#02344D); stroke(#026C9E); // #02344D=azul oscuro #026C9E:azulclaro rect(1, lienzo_sizeY - size_grafica_mostrar , lienzo_sizeX-1, size_grafica_mostrar -1, 0); //255 es el valor mas grande que recojo de arduino. pongo 300 line (lienzo_sizeX/2, lienzo_sizeY -size_grafica_mostrar , lienzo_sizeX/2 , lienzo_sizeY ); //primera grafica grafica - horizontales for (int i = 1 ; i <= lienzo_sizeX/2/size_cuadricula_Temp ; i ++) { ejeY = ejeY + size_cuadricula_Temp; fill(0); stroke(#026C9E); line (0 +ejeY, lienzo_sizeY - size_grafica_mostrar , 0 + ejeY , lienzo_sizeY ); } //segunda grafica - verticales ejeY = 0; // hago reset for (int i = 1 ; i <= lienzo_sizeX/2/size_cuadricula_Luz ; i ++) { ejeY = ejeY + size_cuadricula_Luz; fill(0); stroke(#026C9E); line (lienzo_sizeX/2 +ejeY, lienzo_sizeY - size_grafica_mostrar , lienzo_sizeX/2 + ejeY , lienzo_sizeY ); } //primera grafica grafica - horizontales for (int i = 1 ; i <= lienzo_sizeX/2/size_cuadricula_Temp ; i ++) { ejeX = ejeX + size_cuadricula_Temp; fill(0); stroke(#026C9E); line ( 0, lienzo_sizeY - size_grafica_mostrar + ejeX , lienzo_sizeX/2 , lienzo_sizeY - size_grafica_mostrar + ejeX ); } //segunda grafica - horizontales 67 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ejeX = 0; // hago reset for (int i = 1 ; i <= lienzo_sizeX/2/size_cuadricula_Temp ; i ++) { ejeX = ejeX + size_cuadricula_Luz; fill(0); stroke(#026C9E); line ( lienzo_sizeX/2, lienzo_sizeY - size_grafica_mostrar + ejeX , lienzo_sizeX , lienzo_sizeY - size_grafica_mostrar + ejeX ); } } //----------------------------------------------------fin de dibujo fondo----------------------------//------------------------------------------eventos de tecla pulsada----------------------------//relativo a tecla pulsada. void keyPressed() { switch(key) { case('1'): console.pause(); //paramos la consola de datos break; case('2'): console.play(); //activo consola de datos break; case('3'): //console.clear(); //limpio consola break; case('b'): text(datos3, textX +5 , textY+ 5); //en la pantalla gráfica if (lineas >= 5 ) { textX = textX + 50; textY = 0; lineas = 0; } textY = textY + 10; lineas ++ ; break; case('c'): size_cuadricula = size_cuadricula + 10; break; case('t'): //saca_consola_texto = true; // no me funciona ok. refresco. llamada de setup no posible. puerto serie fallo. ocupado. se vuelve ciclico. consola_texto(); break; case('y'): saca_consola_texto = false; break; } } 68 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado //----------------------------------fin de eventos de tecla pulsada ------------------------------------//----------------------------------evento de raton pulsado ------------------------------------void mousePressed() { } //----------------------------------fin de evento de raton pulsado ------------------------------------//----------------------------------configuracion_entorno_grafico ------------------------------------//----------------------------------datos por consola grafica-----------------------------------void sacar_datos_consola () { cp5 = new ControlP5(this); cp5.enableShortcuts(); frameRate(100); // consola de datos myTextarea = cp5.addTextarea("txt") .setPosition(350, 20) .setSize(100, 250) .setFont(createFont("", 10)) .setLineHeight(14) .setColor(color(180)) .setColorBackground(color(0, 100)) .setColorForeground(color(255, 100)); ; console = cp5.addConsole(myTextarea); } //-------------------------texto informativo void consola_texto() { cp5 = new ControlP5(this); mi__texto_ayuda = cp5.addTextarea("txt") .setPosition(475,50) .setSize(200,200) .setFont(createFont("arial",10)) .setLineHeight(14) .setColor(color(128)) .setColorBackground(color(255,100)) .setColorForeground(color(255,100)); ; mi__texto_ayuda.setText("Cuadro de texto informativo. todas las teclas. funciones, etc" +" Cuadeo de texto informativo. todas las teclas. funciones, etc" +" Cuadeo de texto informativo. todas las teclas. funciones, etc" +" Cuadeo de texto informativo. todas las teclas. funciones, etc" 69 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado +" Cuadeo de texto informativo. todas las teclas. funciones, etc" +" Cuadeo de texto informativo. todas las teclas. funciones, etc" +" Cuadeo de texto informativo. todas las teclas. funciones, etc," +" Cuadeo de texto informativo. todas las teclas. funciones, etc" +" Cuadeo de texto informativo. todas las teclas. funciones, etc" ); cp5.addSlider("Ancho") .setRange(30,500) .setValue(200) .setPosition(475,10) .setSize(100,15) ; cp5.addSlider("Alto") .setRange(30,500) .setValue(200) .setPosition(475,30) .setSize(100,15) ; } void Ancho(int theValue) { mi__texto_ayuda.setWidth(theValue);} void Alto(int theValue) { mi__texto_ayuda.setHeight(theValue);} //--------------------------------------------------cuadros de texto - string solo informativos OJO , no integers-------------void cuadros_texto_informativos() { String[][] s = new String[3][]; ControlP5 controlP5; ListBox cuadro_informativo; controlP5 = new ControlP5(this); cuadro_informativo = controlP5.addListBox("Configuraciones",800,20,200,300); //cuadro_informativo.actAsPulldownMenu(true); cuadro_informativo.setItemHeight(23); s[1] = new String[] { "Baudios : " + baudios, "Puerto Seleccionado : " + COM_serie, "Buffer de Recepcion : " + size_buffer_recepcion_datos, "d", "e", "f", "Tamano del punto Temp : " + size_punto_Temp , "h", "i", "j", "k", "l", "Cuadricula de Dibujo C : " + size_cuadricula, 70 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado "n" }; for(int i=0;i<s[1].length;i++) { cuadro_informativo.addItem(s[1][i],i); } } //--------------------------------------potenciomeotros knob circulares -----------------------------void potenciometros_circulares () { cp5 = new ControlP5(this); Knob size_punto_Temp; size_punto_Temp = cp5.addKnob("size_punto_Temp") .setRange(0,25) .setValue(5) .setPosition(250,333) .setRadius(20) .setDragDirection(Knob.VERTICAL) ; Knob size_punto_Luz; size_punto_Luz = cp5.addKnob("size_punto_Luz") .setRange(0,15) .setValue(2) .setPosition(350,333) .setRadius(20) .setDragDirection(Knob.VERTICAL) ; Knob Rejilla_T; Rejilla_T = cp5.addKnob("Rejilla_T") .setRange(0,100) .setValue(20) .setPosition(450,333) .setRadius(20) .setDragDirection(Knob.VERTICAL) ; Knob Rejilla_L; Rejilla_L = cp5.addKnob("Rejilla_L") .setRange(0,100) .setValue(8) .setPosition(550,333) .setRadius(20) .setDragDirection(Knob.VERTICAL) ; Knob Pot_Fondo; Pot_Fondo = cp5.addKnob("Pot_Fondo") .setRange(0,65000) .setValue(0) .setPosition(650,333) .setRadius(20) .setDragDirection(Knob.VERTICAL) ; } 71 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado //creo estas funciones para asignar las variables. lo puedo hacer directamente , pero asi se ve mejor. void size_punto_Temp(int size_punto_Temperatura){ size_punto_Temp = size_punto_Temperatura; //con esto asigno al valor del potenciometro , una de mis varibles para que las vaya modificiando. } void size_punto_Luz(int size_punto_Luces){ size_punto_Luz = size_punto_Luces; //con esto asigno al valor del potenciometro , una de mis varibles para que las vaya modificiando. } void Rejilla_L (int Valor_Rejilla_L){ size_cuadricula_Luz = Valor_Rejilla_L; //con esto asigno al valor del potenciometro , una de mis varibles para que las vaya modificiando. } void Rejilla_T (int Valor_Rejilla_T){ size_cuadricula_Temp = Valor_Rejilla_T; //con esto asigno al valor del potenciometro , una de mis varibles para que las vaya modificiando. } void Pot_Fondo (int Pot_Fondo){ background_color = Pot_Fondo; //con esto asigno al valor del potenciometro , una de mis varibles para que las vaya modificiando. } //-----------------------slides horizontales con muescas ------------------------------void slides_horizontales_con_muescas () { cp5 = new ControlP5(this); noStroke(); cp5.addSlider("Aviso_1_Temp") .setRange(0, 50) .setValue(30) .setPosition(120, 20) .setSize(100, 15) .setNumberOfTickMarks(5) .setSliderMode(Slider.FLEXIBLE) ; cp5.addSlider("Aviso_2_Temp") .setRange(0, 50) .setValue(40) .setPosition(120, 60) .setSize(100, 15) .setNumberOfTickMarks(5) .setSliderMode(Slider.FLEXIBLE) ; cp5.addSlider("Temp_Critico") .setRange(0, 50) .setValue(50) .setPosition(120, 100) .setSize(100, 15) .setNumberOfTickMarks(5) .setSliderMode(Slider.FLEXIBLE) 72 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado ; } //-----------------------slides horizontales sin muescas ------------------------------void slides_horizontales () { noStroke(); cp5 = new ControlP5(this); cp5.addSlider("Aviso_1_Luz") .setRange(0, 50) .setValue(12) .setPosition(120, 200) .setSize(100, 15) ; cp5.addSlider("Aviso_2_Luz") .setRange(0, 50) .setValue(20) .setPosition(120, 240) .setSize(100, 15) ; cp5.addSlider("Luz_critico") .setRange(0, 50) .setValue(60) .setPosition(120, 290) .setSize(100, 15) ; } //----------------------------------fin de configuracion_entorno_grafico ------------------------------------//----------------------------------escribir datos en fichero PLANO------------------------------------void escribir_datos_fichero (int dato_a_escribir) { //Escribimos los datos de la temperatura con el tiempo (h/m/s) en el archivo de texto. mismo directorio fichero.print(dato_a_escribir + " ºC fichero.print(hour( )+":"); fichero.print(minute( )+":"); fichero.println(second( )); fichero.println(""); "); } //---------------------------------fin escribir datos en fichero ------------------------------------- 4.9.2.2.3 OTRAS FUNCIONES COMPARITDAS ENTRE APLICACIONES //otras funciones void dibuja_fondo_1_grafica_ajustable () { //background(16776695); //#FFFDF7 73 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado background(background_color); //#FFFDF7 int desplazoX = lienzo_sizeX / size_cuadricula , desplazoY = lienzo_sizeY / (size_cuadricula -5); //lo que desplazo para dibujar cuadricula int ejeX = 0, ejeY =0; int color_lineas = 90; //pantalla del sistema grafico. fill (0); stroke(6); rect(0, ref_arriba, lienzo_sizeX, lienzo_sizeY/3, 0); //linea 0 y siguientes. stroke(color_lineas); fill(color_lineas); stroke(color_lineas,color_lineas,color_lineas); line (ejeX, ref_arriba/2 + lienzo_sizeY/2, lienzo_sizeX , ref_arriba/2 + lienzo_sizeY/2); stroke(color_lineas); fill(color_lineas); //text("0", 10, ref_arriba/2 + lienzo_sizeY/2); for (int i =0 ; i <= ref_arriba/2/desplazoX/3 ; i ++) { ejeX = ejeX + desplazoX; stroke(color_lineas); fill(color_lineas); stroke(color_lineas,color_lineas,color_lineas); line (0, ref_arriba/2 + lienzo_sizeY/2 + ejeX, lienzo_sizeX , ref_arriba/2 + lienzo_sizeY/2 + ejeX); line (0, ref_arriba/2 + lienzo_sizeY/2 - ejeX, lienzo_sizeX , ref_arriba/2 + lienzo_sizeY/2 - ejeX); } //linea 0 y siguientes. stroke(color_lineas); fill(color_lineas); stroke(color_lineas,color_lineas,color_lineas); line (lienzo_sizeX/2, ref_arriba , lienzo_sizeX/2 , lienzo_sizeY ); for (int i =0 ; i <= lienzo_sizeY/desplazoY ; i ++) { ejeY = ejeY + desplazoY; stroke(color_lineas); fill(color_lineas); stroke(color_lineas,color_lineas,color_lineas); line (lienzo_sizeX/2 + ejeY, ref_arriba , lienzo_sizeX/2 +ejeY , lienzo_sizeY ); line (lienzo_sizeX/2 - ejeY, ref_arriba , lienzo_sizeX/2 -ejeY , lienzo_sizeY ); } } void dibujar_por_pantalla_todo (int dato_a_dibujar) { //dibujo por pantalla ---------------------------------------------------//dibujo una imagen de termometro segun la lectura de los datos. 74 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado if ( (dato_a_dibujar >= 0) && (dato_a_dibujar < Aviso_1_Temp) ){ image(medida_Bajo, lienzo_sizeX - size_imagen_termoX , lienzo_sizeY -size_imagen_termoY, medida_Bajo.width/reduce_images, medida_Bajo.height/reduce_images); //la coloco cambiandole el tamaño. tint(255, 126); } else if ((dato_a_dibujar >= Aviso_1_Temp ) && (dato_a_dibujar <= Aviso_2_Temp ) ) { image( medida_Mitad, lienzo_sizeX - size_imagen_termoX, lienzo_sizeY -size_imagen_termoY, medida_Mitad.width/reduce_images, medida_Mitad.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. else if ((dato_a_dibujar >= Temp_Critico) && (dato_a_dibujar <= 9999999) ) { image(medida_Alto, lienzo_sizeX - size_imagen_termoX, lienzo_sizeY -size_imagen_termoY, medida_Alto.width/reduce_images, medida_Alto.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. //dibujo una imagen de bombilla segun la lectura de los datos. if ( (dato_a_dibujar >= 0) && (dato_a_dibujar < Aviso_1_Luz) ){ image(medida_Bajo_Luz, lienzo_sizeX - size_imagen_bombillaX , lienzo_sizeY -size_imagen_bombillaY, medida_Bajo_Luz.width/reduce_images, medida_Bajo_Luz.height/reduce_images); //la coloco cambiandole el tamaño. //tint(255, 126); } else if ((dato_a_dibujar >= Aviso_1_Luz) && (dato_a_dibujar <= Aviso_2_Luz) ) { image( medida_Mitad_Luz, lienzo_sizeX - size_imagen_bombillaX, lienzo_sizeY -size_imagen_bombillaY, medida_Mitad_Luz.width/reduce_images, medida_Mitad_Luz.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. else if ((dato_a_dibujar >= Luz_critico) && (dato_a_dibujar <= 9999999) ) { image(medida_Alto_Luz, lienzo_sizeX - size_imagen_bombillaX, lienzo_sizeY -size_imagen_bombillaY, medida_Alto_Luz.width/reduce_images, medida_Alto_Luz.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. convert_dato = ref_arriba/2 + lienzo_sizeY/2 - dato_a_dibujar ; //para dibujar de abajo a arriba . justo en la mitad ellipse(recX, convert_dato , size_punto_Temp, size_punto_Temp); if (dato_a_dibujar >= Temp_Critico) {fill (193,15,27); } else { fill(0,128,0); } //rojo o verde. //si se pasa en X del lienzo reseteo. y resto de variables. if (recX > lienzo_sizeX ) { dibuja_fondo (); recX = 0; textY =0; textX =0; lineas =0; } recX = recX + dist_recX ; //incremento en X para siguente punto //variables demo para pruebas y configuraciones--> borrar println( "Dato: " + paramostrarimagenes); println( "consola: " + saca_consola_texto); } 75 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.9.2.3 CONSOLA GPS 4.9.2.3.1 CONFIGURACION PRINCIPAL DE LA CONSOLA GPS //-----------------------------variables de configuraciones TOTALES //Importamos la librería Serial import processing.serial.*; Serial puerto; //Nombre del puerto serie String COM_serie = "COM5"; //Serial.list()[1]; //se corresponde al com5 . ejecutar y mirar esto cada vez int baudios = 9600; int size_buffer_recepcion_datos = 8; int datos1 , datos2 , datos3, datos4, datos5, datos6, datos7, datos8; boolean zoom_mapa_derecho = false ; int cambio_proveedor_mapas = 1; int salto_linea = 10; int lienzo_sizeX = 800, lienzo_sizeY = 600; //tamaño del lienzo int size_cuadricula = 30 , size_cuadricula_Temp = 20 , size_cuadricula_Luz = 10 ; //tamaño de los cuadraditos. los cambio con teclado int ref_arriba = 400; //referencia para poner una pantalla de medida public int Aviso_1_Temp = 10 , Aviso_2_Temp = 40; //valors de los slides con muescas public int Temp_Critico = 50; //dato por el cual el color del punto pasa a ser rojo y el termometro o lo que sea, se pone full int convert_dato , dato_a_dibujar; int recX = 0 , recXX =0; int size_punto = 10 , size_punto_Luz = 2 , size_punto_Temp = 5 ; // tamaño del punto a dibujar int size_buffer_datos_GPS_recogidos = 9 , recorro_buffer_datosGPS_recogidos = 0; float[] buffer_latitudes = new float[size_buffer_datos_GPS_recogidos]; float[] buffer_longitudes = new float[size_buffer_datos_GPS_recogidos]; //tema de libreria GPS import de.fhpotsdam.unfolding.*; import de.fhpotsdam.unfolding.geo.*; import de.fhpotsdam.unfolding.utils.*; import de.fhpotsdam.unfolding.events.EventDispatcher; import de.fhpotsdam.unfolding.interactions.MouseHandler; import de.fhpotsdam.unfolding.providers.* ; // para cargar mapas de otros proveedores. UnfoldingMap UnfoldingMap UnfoldingMap UnfoldingMap map; mapDetail; mapOverview; map_microsoft; float nuevaX = 42.465f; //latitud horizontal float nuevaY = -2.426f; //longitud vertical Location locationUniversidadRioja = new Location(nuevaX , nuevaY); 2.426 //42.465, - 76 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Location locationLogrono = new Location(42.465, -2.426); //Londres 51.5f, 0f 4.9.2.3.2 CONFIGURACIÓN 2 DE LA CONSOLA GPS – SETUP – public void setup() { size(800, 600, P2D); noStroke(); //configuracion del puerto serie puerto = new Serial(this, COM_serie, baudios); variables - (this, "COM5", 9600); puerto.buffer(size_buffer_recepcion_datos); datos que bienen de arduino //otra forma de ponerlo con //para preparar para size_buffer //configuracion basica de los mapas map = new UnfoldingMap(this); map.setTweening(true); //zoom de entrada //map.zoomToLevel(4); //map.panTo(new Location(20f, -4f)); MapUtils.createDefaultEventDispatcher(this, map); //para crear un mapa detallado--------------------------mapDetail = new UnfoldingMap(this, "Detalle", 0, 0, 800, 400); mapDetail.setTweening(true); mapDetail.zoomToLevel(1); mapOverview = new UnfoldingMap(this, "Vista", 600, 400, 200, 200); mapOverview.setTweening(true); EventDispatcher eventDispatcher = new EventDispatcher(); // Añado la iteración del raton en ambos mapass MouseHandler mouseHandler = new MouseHandler(this, mapDetail, mapOverview); eventDispatcher.addBroadcaster(mouseHandler); // Como cada mapa se escucha el uni al otro. cada iteracion en uno la duplico en el otro eventDispatcher.register(mapDetail, "pan", mapDetail.getId(), mapOverview.getId()); eventDispatcher.register(mapDetail, "zoom", mapDetail.getId(), mapOverview.getId()); eventDispatcher.register(mapOverview, "pan", mapDetail.getId(), mapOverview.getId()); eventDispatcher.register(mapOverview, "zoom", mapDetail.getId(), mapOverview.getId()); //carga de otro proveedor map_microsoft = new UnfoldingMap(this, new Microsoft.AerialProvider()); map_microsoft.setTweening(true); MapUtils.createDefaultEventDispatcher(this, map_microsoft ); } 77 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.9.2.3.3 FUNCION PARA EL CAMBIO DE PROVEEDOR DE MAPAS switch( cambio_proveedor_mapas) { case(1): map.draw(); //mapa normal. break; case(2): dibuja_fondo (); mapa_detallado_derecha (); // para este caso dibujo en el mapa con zooms break; case(3): map_microsoft.draw(); // para este caso dibujo en el mapa de microsoft break; default: map.draw(); break ; } 4.9.2.3.4 PARTE DEL BUCLE DE LA FUNCIÓN MAIN public void draw() { background(0); //por defecto mostraré el mapa de unfolding, pero añado diferentes mapas y pantallas. // Código para ver encima del raton por donde ando. Location location = map.getLocation(mouseX, mouseY); text(location.toString(), mouseX, mouseY); // Hago zoom dependiendo de marcas. /* ScreenPosition posLogrono = map.getScreenPosition(locationLogrono); fill(200, 0, 0, 100); float s = map.getZoom(); ellipse(posLogrono.x, posLogrono.y, s, s); */ //Draws locations on screen positions according to their geo-locations. //Fixed-size marker //ScreenPosition posUniversidadRioja = map.getScreenPosition(locationUniversidadRioja); //fill(0, 200, 0, 100); //ellipse(posUniversidadRioja.x, posUniversidadRioja.y, 10 , 10); //unos ejemplos de puntos para chequeo DDD /*coloca_punto_en_mapa (42.465f, -2.427f); coloca_punto_en_mapa (42.466f, -2.427f); coloca_punto_en_mapa (42.46, -2.42); coloca_punto_en_mapa (nuevaX, nuevaY); coloca_punto_en_mapa (nuevaX, nuevaY+datos1); text(20, 42.475, -2.426); */ 78 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado //compruebo en consola los datos println( "datos1: " + datos1); println( "datos2: " + datos2); println( "datos3: " + datos3); println( "datos4: " + datos4); println( "datos5: " + datos5); println( "datos6: " + datos6); println( "datos7: " + datos7); println( "datos8: " + datos8); que recibo. // grados_Latitud; // parteD; // parteE; // signo_Latitud; // grados_Longitud; // parteI // parteJ // signo_Longitud; //compongo los 4 bytes de la latitud float genero_latitudA; genero_latitudA = (datos1 * 10000) ; //println( "genero_latitudA: " + genero_latitudA); float genero_latitudB; genero_latitudB = (datos2 * 100); //println( "genero_latitudB: " + genero_latitudB); float genero_latitudAmasBmasC; genero_latitudAmasBmasC = genero_latitudA +genero_latitudB + datos3; //println( "genero_latitudAmasBmasC: " + genero_latitudAmasBmasC); if (datos4 == 1) { genero_latitudAmasBmasC = genero_latitudAmasBmasC * (-1) ; //si el signo es 1 lo pongo negativo } else genero_latitudAmasBmasC = genero_latitudAmasBmasC * (+1) ; float Latitud_capturada = genero_latitudAmasBmasC / 10000 ; println( "Latitud_capturada: " + Latitud_capturada); //compongo los 4 bytes de la longitud float genero_longitudA; genero_longitudA = (datos5 * 10000) ; //println( "genero_longitudA: " + genero_longitudA); float genero_longitudB; genero_longitudB = (datos6 * 100); //println( "genero_longitudB: " + genero_longitudB); float genero_longitudAmasBmasC; genero_longitudAmasBmasC = genero_longitudA +genero_longitudB + datos7; //println( "genero_longitudAmasBmasC: " + genero_longitudAmasBmasC); if (datos8 == 1) { genero_longitudAmasBmasC = genero_longitudAmasBmasC * (-1) ; //si el signo es 1 lo pongo negativo } else genero_longitudAmasBmasC = genero_longitudAmasBmasC * (+1) ; float Longitud_capturada = genero_longitudAmasBmasC / 10000 ; println( "Longitud_capturada : " + Longitud_capturada); // if { if { if { coloco el punto solo en el mapa correspondiente ( cambio_proveedor_mapas == 1 ) coloca_punto_en_mapa (Latitud_capturada, Longitud_capturada); } ( cambio_proveedor_mapas == 2 ) coloca_punto_en_mapa_Zoomeado (Latitud_capturada, Longitud_capturada); } ( cambio_proveedor_mapas == 3 ) coloca_punto_en_mapa_microsoft (Latitud_capturada, Longitud_capturada);} 79 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado //guardo en un buffer X datos de recogida buffer_latitudes [recorro_buffer_datosGPS_recogidos] = Latitud_capturada ; buffer_longitudes [recorro_buffer_datosGPS_recogidos] = Longitud_capturada ; recorro_buffer_datosGPS_recogidos ++ ; if ((recorro_buffer_datosGPS_recogidos == size_buffer_datos_GPS_recogidos ) || (recorro_buffer_datosGPS_recogidos == buffer_latitudes.length) || (recorro_buffer_datosGPS_recogidos == buffer_longitudes.length)) { recorro_buffer_datosGPS_recogidos = 0; } //por seguridad. comparo sizes de todos arrays. desbordamiento. //muestro el buffer println( "Saco Buffer lat : " + buffer_latitudes [recorro_buffer_datosGPS_recogidos]); println( "Saco Buffer long : " + buffer_longitudes [recorro_buffer_datosGPS_recogidos ]); text("Buffer Lat: " + buffer_latitudes [recorro_buffer_datosGPS_recogidos ] , 10, 50 + salto_linea ); text("Buffer Long: " + buffer_longitudes [recorro_buffer_datosGPS_recogidos ] , 150, 50 + salto_linea ); salto_linea = salto_linea + 10; if (salto_linea >= 100) {salto_linea = 0;} delay (0);} 4.9.2.3.5 FUNCIONES LLAMADAS EN CONSOLA GPS //----------------------------coloco datos en mapa -----------------void coloca_punto_en_mapa (float dameX, float dameY) { int size_punto = 10; Location locationUniversidadRioja = new Location(dameX , dameY); //42.465, 2.426 ScreenPosition posUniversidadRioja = map.getScreenPosition(locationUniversidadRioja); ellipse(posUniversidadRioja.x, posUniversidadRioja.y, size_punto , size_punto); fill(0, 200, 0, 100); println( "Dato geolocalizado en: " + dameX + " " + dameY); } //--------------------------fin de--coloco datos en mapa ----------------//----------------------------coloco datos en mapa de microsoft -----------------void coloca_punto_en_mapa_microsoft (float dameXmicro, float dameYmicro) { int size_punto_micro = 10; Location location_microsoft = new Location(dameXmicro , dameYmicro); //42.465, 2.426 ScreenPosition pos_microsoft = map_microsoft.getScreenPosition(location_microsoft); ellipse(pos_microsoft .x, pos_microsoft .y, size_punto_micro , size_punto_micro); fill(255,0,0); println( "Dato geolocalizado en microsoft : " + dameXmicro + " " + dameYmicro); } //--------------------------fin de--coloco datos en mapa ----------------- 80 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado //----------------------------coloco datos en mapa cuando hago zoom sobre ella. ----------------void coloca_punto_en_mapa_Zoomeado (float dameXZoom, float dameYZoom) { int size_punto_Zoom = 10; Location location_Zoom = new Location(dameXZoom , dameYZoom); //42.465, -2.426 ScreenPosition pos_Zoom = mapDetail.getScreenPosition(location_Zoom); ellipse(pos_Zoom.x, pos_Zoom.y , size_punto_Zoom , size_punto_Zoom); fill (#02344D); println( "Dato geolocalizado en microsoft : " + dameXZoom + " " + dameYZoom); } //--------------------------fin de--coloco datos en mapa ----------------- //-----------------------------------------enventos en el puerto serie . interrupcion. int serialEvent(Serial puerto_serie) { //este sistema funciona mejor. es una INT. solo tener cuidado al poner el buffer. datos1 = puerto_serie.read(); datos2 = puerto_serie.read(); datos3 = puerto_serie.read(); datos4 = puerto_serie.read(); datos5 datos6 datos7 datos8 = = = = puerto_serie.read(); puerto_serie.read(); puerto_serie.read(); puerto_serie.read(); return datos1 datos5 + datos2 + datos3 + datos4 + + datos6 + datos7 + datos8 ; // me devuelve los X datos que tenga en el buffer. en el orden de envio. FIFO. } //------------------------------------fin de-----enventos en el puerto serie . interrupcion. //----------------------------------- funcion de eventos con tecla pulsada ----------------------void keyPressed() { switch(key) { case('1'): nuevaX = nuevaX+ 0.001; nuevaY = nuevaY+ 0.001; break; case('0'): haz_un_recorrido (); break; case('8'): zoom_mapa_derecho = false; break; case('9'): zoom_mapa_derecho = true; 81 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado break; case('z'): cambio_proveedor_mapas = 1; break; case('x'): cambio_proveedor_mapas = 2; break; case('c'): cambio_proveedor_mapas = 3; mapas tenga. break; } } //pongo tantas variables como proveedores de //-----------------------------------------------------------------void haz_un_recorrido () { Location[] locations = new Location[] { new Location(52.5, 13.4), new Location(53.6f, 10), new Location(51.34, 12.37) }; int currentLocation = 0; for (currentLocation = 0; currentLocation < locations.length; currentLocation ++) { map.setTweening(true); map.zoomAndPanTo(locations[currentLocation], 8); map.panTo(locations[currentLocation]); delay (100); } } // mapa detalle void mapa_detallado_derecha () { mapDetail.draw(); mapOverview.draw(); fill (#02344D); rect(0, 600 , 800, 600, 0); line (0, 400, 800, 400); //dos lineas para separar mapa y datos graficos. line (0, 401, 800, 401); stroke(0); // #02344D=azul oscuro #026C9E:azulclaro //dibujo dato recogido por sensor. temperatura, luz, etc dibujar_por_pantalla_temp (20); } //-------------------------dibujo ejes para mostrar datos por pantalla. //--------------------------------------------------------------------funcion para dibujar fondo void dibuja_fondo () { 82 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado int color_lineas = #026C9E; int size_grafica_mostrar = 200; int ejeX = 0, ejeY =0; background(0); //pantalla del sistema grafico. fill (#02344D); stroke(#026C9E); // #02344D=azul oscuro #026C9E:azulclaro rect(1, lienzo_sizeY - size_grafica_mostrar , lienzo_sizeX-1, size_grafica_mostrar -1, 0); //255 es el valor mas grande que recojo de arduino. pongo 300 line (lienzo_sizeX/2, lienzo_sizeY -size_grafica_mostrar , lienzo_sizeX/2 , lienzo_sizeY ); //primera grafica grafica - horizontales for (int i = 1 ; i <= lienzo_sizeX -200 ; i ++) { ejeY = ejeY + size_cuadricula_Temp; fill(0); stroke(#026C9E); line (0 +ejeY, lienzo_sizeY - size_grafica_mostrar , 0 + ejeY , lienzo_sizeY ); } //segunda grafica - verticales /* ejeY = 0; // hago reset for (int i = 1 ; i <= lienzo_sizeX/2/size_cuadricula_Luz ; i ++) { ejeY = ejeY + size_cuadricula_Luz; fill(0); stroke(#026C9E); line (lienzo_sizeX/2 +ejeY, lienzo_sizeY - size_grafica_mostrar , lienzo_sizeX/2 + ejeY , lienzo_sizeY ); } */ //primera grafica grafica - horizontales for (int i = 1 ; i <= lienzo_sizeX - 200 ; i ++) { ejeX = ejeX + size_cuadricula_Temp; fill(0); stroke(#026C9E); line ( 0, lienzo_sizeY - size_grafica_mostrar + ejeX , lienzo_sizeX - 200 , lienzo_sizeY - size_grafica_mostrar + ejeX ); } //segunda grafica - horizontales - para sacar mas datos /* ejeX = 0; // hago reset for (int i = 1 ; i <= lienzo_sizeX/2/size_cuadricula_Temp ; i ++) { ejeX = ejeX + size_cuadricula_Luz; fill(0); stroke(#026C9E); line ( lienzo_sizeX/2, lienzo_sizeY - size_grafica_mostrar + ejeX , lienzo_sizeX , lienzo_sizeY - size_grafica_mostrar + ejeX ); } */ 83 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado } //----------------------------------------------------fin de dibujo fondo----------------------------void dibujar_por_pantalla_temp (int temp_a_dibujar) { //dibujo por pantalla ---------------------------------------------------/* //dibujo una imagen de termometro segun la lectura de los datos. if ( (temp_a_dibujar >= 0) && (temp_a_dibujar < Aviso_1_Temp) ){ image(medida_Bajo, lienzo_sizeX - size_imagen_termoX , lienzo_sizeY -size_imagen_termoY, medida_Bajo.width/reduce_images, medida_Bajo.height/reduce_images); //la coloco cambiandole el tamaño. tint(255, 126); } else if ((temp_a_dibujar >= Aviso_1_Temp ) && (temp_a_dibujar <= Aviso_2_Temp ) ) { image( medida_Mitad, lienzo_sizeX - size_imagen_termoX, lienzo_sizeY -size_imagen_termoY, medida_Mitad.width/reduce_images, medida_Mitad.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. else if ((temp_a_dibujar >= Temp_Critico) && (temp_a_dibujar <= 9999999) ) { image(medida_Alto, lienzo_sizeX - size_imagen_termoX, lienzo_sizeY -size_imagen_termoY, medida_Alto.width/reduce_images, medida_Alto.height/reduce_images); tint(255, 126); } //la coloco cambiandole el tamaño. */ convert_dato = ref_arriba/2 + lienzo_sizeY/2 - temp_a_dibujar ; //para dibujar de abajo a arriba . justo en la mitad ellipse(recX, convert_dato , size_punto_Temp, size_punto_Temp); if (temp_a_dibujar >= Temp_Critico) {fill (193,15,27); } else { fill(0,128,0); } //rojo o verde. //si se pasa en X del lienzo reseteo. y resto de variables. if (recX > lienzo_sizeX - 200 ) { recX = 0; } recX = recX + size_punto_Temp; //incremento en X para siguente punto //variables demo para pruebas y configuraciones--> borrar println( "temp: " + temp_a_dibujar); } 84 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.9.3 FUNCIONES BÁSICAS DE LA APLICACIÓN WEB Se adjuntarán solo algunas de las funciones más importantes Se presentan a continuación algunos de los códigos usados en la aplicación web. Sólo las funciones principales. Si se imprimieran todas las líneas de código serán varios cientos de páginas y no aportaría nada al documento, si no que sería más farragosa su lectura. Los archivos se presentarán en formato digital y se duplicarán online. Por otro lado el código de las librerías usadas se adjunta en formato digital, pero no impreso ya que no es código desarrollado por el alumno. 4.9.3.1 BOOSTRAP DE TWITTER MODIFICADO Se considera que la modificación no es suficiente para añadir el código ya que ha sido menor al 10%. Las funciones se cargan en formato externo en código embebido principalmente. 4.9.3.2 DESARROLLOS EN PHP – MYSQL - HTML 4.9.3.2.1 HACER UN GET EXTERNO PARA INSERCCIÓN <?php //estos son mis datos de la base de datos. hosting, etc //estos son mis daficheros de configuracion //include '/ruta/al/fichero/externo.php'; //include '/config-hosting-localhost.php'; include 'config-hosting-zainder.php'; //si pongo la /config.... etc me da problemas en algunos servidores //variables para rellenar la base de datos $temperatura = $_GET['temperatura']; // lo puedo coger de un formulario, por get desde url, o de arduino //con esto conecto con el servidor externo. $conecta = mysql_connect ($hostDB, $usuarioDB , $passwordDB ) or die ("problemas al conectar"); //asi, conecto ya con la base datos. pasando el nombre de la base de datos, y los datos que acabo de conseguir de la instruccion anterior. 85 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado mysql_select_db ($base_datosDB, $conecta) or die ("problemas con la base de datos"); //mysql_query("INSERT INTO $tabla_BD ($campo1 ,$campo2, $campo3) VALUES ('90' , now() , curtime() ) " , $conecta ); //ingreso desde formulario por get desde url, o de arduino mysql_query("INSERT INTO $tabla_BD ($campo1 ,$campo2, $campo3) VALUES ($temperatura , now() , curtime() ) " , $conecta ); echo "insertados" ; /* echo "saco dato en concreto de la base de datos . </br> " ; $datos = mysql_query("SELECT * FROM $tabla_BD WHERE temperatura ='18' ") ("problemas al leer" .mysql_error() ); while ( $reg = mysql_fetch_array ($datos)) { echo "identificador: "; echo $reg [$campo0] ."</br>"; echo $reg [$campo1] ."</br>"; echo $reg [$campo2] ."</br>"; echo $reg [$campo3] ."</br>"; } */ or die ?> 4.9.3.2.2 BORRAR UN DATO EN UNA BASE DE DATOS <?php //estos son mis datos de la base de datos. hosting, etc //estos son mis daficheros de configuracion //include '/config-hosting-localhost.php'; include 'config-hosting-zainder.php'; //si pongo la /config.... etc me da problemas en algunos servidores //con esto conecto con el servidor externo. $conecta = mysql_connect ($hostDB, $usuarioDB , $passwordDB ) or die ("problemas al conectar"); //asi, conecto ya con la base datos. pasando el nombre de la base de datos, y los datos que acabo de conseguir de la instruccion anterior. mysql_select_db ($base_datosDB, $conecta) or die ("problemas con la base de datos"); echo "borro dato en concreto de la base de datos . </br> " ; //ahora borro el dato que me viene de un formulario . mysql_query("DELETE FROM $tabla_BD WHERE $campo1 = '$_GET[temperatura]' $conecta ); echo " borrado el dato: $_GET[temperatura] " ; ", ?> 86 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.9.3.2.3 BORRAR TODA UNA BASE DE DATOS <?php //estos son mis datos de la base de datos. hosting, etc //estos son mis daficheros de configuracion //include '/config-hosting-zainder.php'; include 'config-hosting-locahost.php'; //con esto conecto con el servidor externo. $conecta = mysql_connect ($hostDB, $usuarioDB , $passwordDB ) or die ("problemas al conectar"); //asi, conecto ya con la base datos. pasando el nombre de la base de datos, y los datos que acabo de conseguir de la instruccion anterior. mysql_select_db ($base_datosDB, $conecta) or die ("problemas con la base de datos"); mysql_query("DELETE FROM $tabla_BD") ); or die ("problemas al borrar" .mysql_error() ?> 4.9.3.2.4 CREAR UNA BASE DE DATOS DE PRUEBA --------- phpMyAdmin SQL Dump version 4.1.4 http://www.phpmyadmin.net Host: 127.0.0.1 Generation Time: May 05, 2014 at 11:01 AM Server version: 5.6.15-log PHP Version: 5.4.24 SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO"; SET time_zone = "+00:00"; /*!40101 /*!40101 /*!40101 /*!40101 SET SET SET SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; NAMES utf8 */; --- Database: `arduinodemos` --- ---------------------------------------------------------- Table structure for table `tabla_arduino_demo` -- 87 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado CREATE TABLE IF NOT EXISTS `tabla_arduino_demo` ( `identificador` int(32) unsigned NOT NULL AUTO_INCREMENT, `temperatura` int(32) NOT NULL, `fechayhora` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, `hora` time NOT NULL, PRIMARY KEY (`identificador`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci AUTO_INCREMENT=76 ; /*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */; /*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */; /*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */; 4.9.3.2.5 INSERTAR UN DATO EN HTML POR GET <!DOCTYPE html> <html> <head> </head> <body> <form action="arduino-get.php" method="get"> <table border="0" width="331"> <tbody> <tr> <td width="137">temperatura a ingresar</td> <td width="184"><input name="temperatura" type="text"></td> </tr> <tr> <td>Ingresa este Dato</td> <td><input name="ingresar_dato" type="submit"></td> </tr> </tbody> </table> </form> </body> </html> 4.9.3.2.6 BORRAR UN DATO MEDIANTE FORMULARIO <!DOCTYPE html> <html> <head> </head> <body> <form action="borrar-dato-temperatura.php" method="get"> <table border="0" width="331"> <tbody> 88 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado <tr> <td width="137">temperatura a borrar</td> <td width="184"><input name="temperatura" type="text"></td> </tr> <tr> <td>Borra este Dato</td> <td><input name="borra_dato" type="submit"></td> </tr> </tbody> </table> </form> </body> </html> 4.9.3.2.7 SACA POR PANTALLA EL VALOR DE LA TEMPERATURA <!DOCTYPE html> <html> <head> </head> <body> <form action="saca-dato-concreto.php" method="get"> <table border="0" width="331"> <tbody> <tr> <td width="137">temperatura a buscar</td> <td width="184"><input name="temperatura" type="text"></td> </tr> <tr> <td>Busca este Dato</td> <td><input name="busca_dato" type="submit"></td> </tr> </tbody> </table> </form> </body> </html> 4.9.3.2.8 MOSTRAR LA BASE DE DATOS <?php //estos son mis datos de la base de datos. hosting, etc //estos son mis daficheros de configuracion //include '/ruta/al/fichero/externo.php'; //include '/config-hosting-localhost.php'; include 'config-hosting-zainder.php'; //si pongo la /config.... etc me da problemas en algunos servidores //include '/arduino-get.php'; 89 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado //con esto conecto con el servidor externo. $conecta = mysql_connect ($hostDB, $usuarioDB , $passwordDB ) or die ("problemas al conectar"); //asi, conecto ya con la base datos. pasando el nombre de la base de datos, y los datos que acabo de conseguir de la instruccion anterior. mysql_select_db ($base_datosDB, $conecta) or die ("problemas con la base de datos"); echo "</br> saco todos los datos de la tabla . </br> " ; $datos = mysql_query("SELECT * FROM $tabla_BD") or die ("problemas al leer" .mysql_error() ); while ( $reg = mysql_fetch_array ($datos)) { echo "identificador : "; echo $reg [$campo0] ."</br>"; echo "temperatura : "; echo $reg [$campo1] ."</br>"; echo "fecha y hora : "; echo $reg [$campo2] ."</br>"; echo "solo la hora : "; echo $reg [$campo3] ."</br>"; echo "_________________________________________. </br>"; } ?> 90 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.10 PENDIENTE Aplicaciones, funcionalidades extras que no se han conseguido implementar y hacer funcionar y que todavía están a la espera de respuesta en forums. 1. GPS en modo Arduino http://forum.arduino.cc/index.php?topic=243669.msg1745041#msg174 5041 aunque sí que funciona vía Matlab más Simulink más librería Actualización 25 junio 2014. El problema se ha solucionado probando otro modelo de GPS y otra placa arduino. Bajo el GPS GTPA 010, no se conseguía conexión. Pero con el modelo GTPA 013 el resultado ha sido positivo. 2. Escribir datos via GET desde Arduino en modo local con un router sin internet http://forum.arduino.cc/index.php?topic=237411.msg1705701#msg170 5701 Sí que se hace enviando datos directos a un server de internet con un router conectado. 3. Hacer live streaming con gopro3 via wifi y processing http://forum.processing.org/two/discussion/5472/is-there-possible-alive-streaming-with-gopro3-wifi-and-processing-#Item 1 sí que se hace funcionar vía Url, y también con VLC bajo Ubuntu y código embeb. 4. Uso de las librerías unfolding de procesamiento de datos del GPS en Windows http://forum.processing.org/two/discussion/5070/problemswith-unfolding-some-scripts-goes-on-win8-but-not-in-win7-why-#Item_1 91 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Sí que se funciona en windows8, pero solo en uno de los ordenadores probados. Sé que es por las librerías OpenGL pero no se sabe cómo solucionarlo. 92 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.11 OPEN SOURCE Y CREATIVE COMMONS Dada la concienciación del autor con el mundo del Open Source se ha procurado que todo el desarrollo posible del proyecto se haga con software de código abierto. Además el software seleccionado es GRATUITO (no confundir con OS) tanto para uso educativo como comercial, por lo tanto no existe ningún coste de licencias en el desarrollo de este proyecto ni en sus documentos. 4.11.1 OPEN HARDWARE Protege y defiende la soberanía, permitiendo a las naciones no depender de ninguna otra que le provea los recursos necesarios para su desarrollo e independencia tecnológica. Fomenta a que el hardware pueda ser de calidad, los estándares abiertos y que sean más económicos. La reutilización y la adaptación de diseños permitiendo así innovar y mejorar los diseños de forma colaborativa a nivel mundial. Ayudaría a las compañías a ahorrar costes y tiempos de diseño en sus trabajos. Existen comunidades de diseño, programación, pruebas, y soporte que día a día crecen de forma dinámica y participativa. Evita la alianza trusted computing y la gestión digital de derechos (DRM), que imponen restricciones a los dispositivos electrónicos como por ejemplo electrodomésticos, computadoras, entre otras más. 93 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Sirva de homenaje esta colección de logos de sus respectivos Programas recopilados de los programas usados en este PFC. Ilustración 143 Open Source Ilustración 146 Processing Ilustración 144 Logo Ilustración 145 Frizting Arduino Ilustración 147 Java Ilustración 148 Javascript 94 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 151 Aptana Std Ilustración 149 Html5 Y CSS3 Ilustración 152 MySQL Ilustración 155 LESS CSS Ilustración 158 Boostrap d Twitter Ilustración 150 PHP Ilustración 153 SO Linux Ilustración 156 Eclipse Ilustración 154 Distro Ubuntu Ilustración 157 PhP MyAdmin Logo Ilustración 159 Jquery lustración 161 Open Office Ilustración 162 Wamp Ilustración 160 Json Ilustración 163 Gimp Ilustración 165 Apache Ilustración 164 Phone GAP Ilustración 166 EasyPhp 95 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 96 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” FIN DE DOCUMENTO: ANEJOS Eduardo Garbayo Herce Logroño, a 16 de Julio de 2014 97 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 98 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado PROYECTO FIN DE CARRERA: “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” DOCUMENTO Nº5: PLIEGO DE CONDICIONES Peticionario: DEPARTAMENTO DE INGENIERÍA ELECTRICA Informantes: Eduardo Garbayo Herce Alumno de Ingeniería Industrial Universidad de La Rioja Lugar y Fecha: Logroño, 12 de Julio de 2014 1 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 2 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5. PLIEGO DE CONDICIONES 3 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.1 PLIEGO DE CONDICIONES GENERAL El presente pliego tiene por objeto describir los trabajos y enumerar las materias que han de ser objeto de estudio, así como definir las condiciones y los criterios técnicos, y concretar los documentos en cuya realización ha de intervenir el adjudicatario para que el trabajo pueda ser aceptado por el cliente final, y previamente por la UR. Condiciones generales de instalación, configuración, y puesta en marcha del Hardware y Software del Proyecto para la medición mediante UADs. Condiciones de buen uso del material, de los componentes y de funcionamiento de los equipos. 5.1.1 PLIEGO DE CONDICIONES LEGALES Este documento contiene las condiciones legales que guiarán la realización, en este proyecto, de “Supervisión remota de parámetros medioambientales capturados por UAV”. En lo que sigue, se supondrá que el proyecto ha sido encargado por una empresa cliente a una empresa consultora con la finalidad de realizar dicho sistema. Dicha empresa ha debido desarrollar una línea de investigación con objeto de elaborar el proyecto. Esta línea de investigación, junto con el posterior desarrollo de los programas está amparada por las condiciones particulares del siguiente pliego. Supuesto que la utilización industrial de los métodos recogidos en el presente proyecto ha sido decidida por parte de la empresa cliente o de otras, los servicios a realizar se regulará por las siguientes: 5.1.2 Condiciones generales 1. La modalidad de contratación será el concurso. La adjudicación se hará, por tanto, a la proposición más favorable sin atender exclusivamente al valor económico, 4 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado dependiendo de las mayores garantías ofrecidas. La empresa que somete el proyecto a concurso se reserva el derecho a declararlo desierto. 2. El montaje y mecanización completa de los equipos que intervengan será realizado totalmente por la empresa licitadora. 3. En la oferta, se hará constar el precio total por el que se compromete a realizar los servicios y el tanto por ciento de baja que supone este precio en relación con un importe límite si este se hubiera fijado. 4. Los servicios o servicios de vuelo, se realizará bajo la dirección técnica de un Ingeniero Superior Industrial, auxiliado por el número de Ingenieros Técnicos y Programadores que se estime preciso para el desarrollo de la misma. Se aconseja uno por cada vehículo no tripulado a controlar, que también vigilará su ordenador correspondiente de servidor de datos. 5. Aparte del Ingeniero Director, el contratista tendrá derecho a contratar al resto del personal, pudiendo ceder esta prerrogativa a favor del Ingeniero Director, quien no estará obligado a aceptarla. 6. El contratista tiene derecho a sacar copias a su costa de los planos, pliego de condiciones y presupuestos. El Ingeniero autor del proyecto autorizará con su firma las copias solicitadas por el contratista después de confrontarlas. 7. Se abonará al contratista los servicios que realmente ejecute con sujeción al proyecto que sirvió de base para la contratación, a las modificaciones autorizadas por la superioridad o a las órdenes que con arreglo a sus facultades le hayan comunicado por escrito al Ingeniero Director de servicios siempre que dicha obra se haya ajustado a los preceptos de los pliegos de condiciones, con arreglo a los cuales, se harán las modificaciones y la valoración de las diversas unidades sin que el importe total pueda exceder de los presupuestos aprobados. Por consiguiente, el número de unidades que se consignan en el proyecto o en el presupuesto, no podrá servirle de fundamento para entablar reclamaciones de ninguna clase, salvo en los casos de rescisión. 5 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 8. Tanto en las certificaciones de servicios como en la liquidación final, se abonarán los trabajos realizados por el contratista a los precios de ejecución material que figuran en el presupuesto para cada unidad de los servicios y-o servicios de vuelo contratados. 9. Si excepcionalmente se hubiera ejecutado algún trabajo que no se ajustase a las condiciones de la contrata pero que sin embargo es admisible a juicio del Ingeniero Director de obra, se dará conocimiento a la Dirección, proponiendo a la vez la rebaja de precios que el Ingeniero estime justa y si la Dirección resolviera aceptar los servicios, quedará el contratista obligado a conformarse con la rebaja acordada. 10. Cuando se juzgue necesario emplear materiales o ejecutar servicios que no figuren en el presupuesto de la contrata, se evaluará su importe a los precios asignados a otras servicios o materiales análogos si los hubiere y cuando no, se discutirán entre el Ingeniero Director y el contratista, sometiéndolos a la aprobación de la Dirección. Los nuevos precios convenidos por uno u otro procedimiento, se sujetarán siempre al establecido en el punto anterior. 11. Cuando el contratista, con autorización del Ingeniero Director, emplee materiales de calidad más elevada o de mayores dimensiones de lo estipulado en el proyecto, o sustituya una clase de fabricación por otra que tenga asignado mayor precio o ejecute con mayores dimensiones cualquier otra parte de las servicios, o en general, introduzca en ellas cualquier modificación que sea beneficiosa a juicio del Ingeniero Director de servicios, no tendrá derecho sin embargo, sino a lo que le correspondería si hubiera realizado los servicios con estricta sujeción a lo proyectado y contratado. 12. Las cantidades calculadas para servicios accesorios, aunque figuren por partida alzada en el presupuesto final (general), no serán abonadas sino a los precios de la contrata, según las condiciones de la misma y los proyectos particulares que para ellas se formen, o en su defecto, por lo que resulte de su medición final. 6 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 13. El contratista queda obligado a abonar al Ingeniero autor del proyecto y director de servicios así como a los Ingenieros Técnicos, el importe de sus respectivos honorarios facultativos por formación del proyecto, dirección técnica y administración en su caso, con arreglo a las tarifas y honorarios vigentes. 14. Concluida la ejecución de los servicios, será reconocida por el Ingeniero Director que a tal efecto designe la empresa. 15. La garantía definitiva será del 4% del presupuesto y la provisional del 2%. 16. La forma de pago será por certificaciones mensuales de los servicios ejecutada, de acuerdo con los precios del presupuesto, deducida la baja si la hubiera. 17. La fecha de comienzo de las servicios será a partir de los 15 días naturales del replanteo oficial de las mismas y la definitiva, al año de haber ejecutado la provisional, procediéndose si no existe reclamación alguna, a la reclamación de la fianza. 18. Si el contratista al efectuar el replanteo, observase algún error en el proyecto, deberá comunicarlo en el plazo de quince días al Ingeniero Director de servicios, pues transcurrido ese plazo será responsable de la exactitud del proyecto. 19. El contratista está obligado a designar una persona responsable que se entenderá con el Ingeniero Director de servicios, o con el delegado que éste designe, para todo relacionado con ella. Al ser el Ingeniero Director de servicios el que interpreta el proyecto, el contratista deberá consultarle cualquier duda que surja en su realización. 20. Durante la realización de los servicios, se girarán visitas de inspección por personal facultativo de la empresa cliente, para hacer las comprobaciones que se crean oportunas. Es obligación del contratista, la conservación de los servicios ya ejecutados hasta la recepción de la misma, por lo que el deterioro parcial o total de ella, aunque sea por agentes atmosféricos u otras causas, deberá ser reparado o reconstruido por su cuenta. 7 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 21. El contratista, deberá realizar los servicios en el plazo mencionado a partir de la fecha del contrato, incurriendo en multa, por retraso de la ejecución siempre que éste no sea debido a causas de fuerza mayor. A la terminación de los servicios, se hará una recepción provisional previo reconocimiento y examen por la dirección técnica, el depositario de efectos, el interventor y el jefe de servicio o un representante, estampando su conformidad el contratista. 22. Hecha la recepción provisional, se certificará al contratista el resto de los servicios, reservándose la administración el importe de los gastos de conservación de la misma hasta su recepción definitiva y la fianza durante el tiempo señalado como plazo de garantía. La recepción definitiva se hará en las mismas condiciones que la provisional, extendiéndose el acta correspondiente. El Director Técnico propondrá a la Junta Económica la devolución de la fianza al contratista de acuerdo con las condiciones económicas legales establecidas. 23. Las tarifas para la determinación de honorarios, reguladas por orden de la Presidencia del Gobierno el 19 de Octubre de 1961, se aplicarán sobre el denominado en la actualidad “Presupuesto de Ejecución de Contrata” y anteriormente llamado “Presupuesto de Ejecución Material” que hoy designa otro concepto. 5.1.3 CONDICIONES PARTICULARES. La empresa consultora, que ha desarrollado el presente proyecto, lo entregará a la empresa cliente bajo las condiciones generales ya formuladas, debiendo añadirse las siguientes condiciones particulares: 1. La propiedad intelectual de los procesos descritos y analizados en el presente trabajo, pertenece por entero a la empresa consultora representada por el Ingeniero Director del Proyecto. 2. La empresa consultora se reserva el derecho a la utilización total o parcial de los resultados de la investigación realizada para desarrollar el siguiente proyecto, 8 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado bien para su Proyecto Fin de Carrera: publicación o bien para su uso en trabajos o proyectos posteriores, para la misma empresa cliente o para otra. 3. Cualquier tipo de reproducción aparte de las reseñadas en las condiciones generales, bien sea para uso particular de la empresa cliente, o para cualquier otra aplicación, contará con autorización expresa y por escrito del Ingeniero Director del Proyecto, que actuará en representación de la empresa consultora. 4. En la autorización se ha de hacer constar la aplicación a que se destinan sus reproducciones así como su cantidad. 5. En todas las reproducciones se indicará su procedencia, explicitando el nombre del proyecto, nombre del Ingeniero Director y de la empresa consultora. 6. Si el proyecto pasa la etapa de desarrollo, cualquier modificación que se realice sobre él, deberá ser notificada al Ingeniero Director del Proyecto y a criterio de éste, la empresa consultora decidirá aceptar o no la modificación propuesta. 7. Si la modificación se acepta, la empresa consultora se hará responsable al mismo nivel que el proyecto inicial del que resulta el añadirla. 8. Si la modificación no es aceptada, por el contrario, la empresa consultora declinará toda responsabilidad que se derive de la aplicación o influencia de la misma. 9. Si la empresa cliente decide desarrollar industrialmente uno o varios productos en los que resulte parcial o totalmente aplicable el estudio de este proyecto, deberá comunicarlo a la empresa consultora. 10. La empresa consultora no se responsabiliza de los efectos laterales que se puedan producir en el momento en que se utilice la herramienta objeto del presente proyecto para la realización de otras aplicaciones. 11. La empresa consultora tendrá prioridad respecto a otras en la elaboración de los proyectos auxiliares que fuese necesario desarrollar para dicha aplicación industrial, siempre que no haga explícita renuncia a este hecho. En este caso, deberá autorizar expresamente los proyectos presentados por otros. 9 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 12. El Ingeniero Director del presente proyecto, será el responsable de la dirección de la aplicación industrial siempre que la empresa consultora lo estime oportuno. En caso contrario, la persona designada deberá contar con la autorización del mismo, quien delegará en él las responsabilidades que ostente. 5.1.4 SEGURIDAD Y CONFIDENCIALIDAD El adjudicatario estará obligado a mantener la más absoluta confidencialidad y reserva de todos aquellos datos y documentos que maneja. A estos tendrán acceso, exclusivamente, aquellas personas estrictamente imprescindibles para el desarrollo de las tareas inherentes a este contrato. Todas ellas serán advertidas del carácter confidencial y reservado de la información. Todos los ficheros que se pongan a disposición del personal de la empresa, para la ejecución de los servicios contratados son propiedad de la Universidad de La Rioja y estarán registrados y sometidos a la salvaguardia que establece la legislación vigente, en especial la relativa a la protección de datos personales (LOPD). Toda utilización con propósito distinto del contratado y, en especial, toda cesión de información a terceros serán perseguidas ante los tribunales. El adjudicatario estará obligado a poner en conocimiento del responsable designado por el órgano de Contratación, inmediatamente después de ser detectado, cualquier sospecha de errores eventuales que pudieran producirse en el sistema de seguridad de la información. 10 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.2 NORMAS LEYES Y REGLAMENTOS El proyecto también cumple las siguientes normativas UNE: UNE 157001:2002 sobre criterios generales para la elaboración de proyectos, que establece las consideraciones generales que permitan precisar las características que deben satisfacer los proyectos de productos servicios y edificios, instalaciones, servicios o software, para que sean conformes al fin que están destinados. IEEE 802.11b define el uso de los dos niveles inferiores de la arquitectura OSI (capas física y de enlace de datos), especificando sus normas de funcionamiento en una WLAN. Los protocolos de la rama 802.x definen la tecnología de redes de área local y redes de área metropolitana. ISO/IEC 25000, conocida como SQuaRE (System and Software Quality Requirements and Evaluation), es una familia de normas que tiene por objetivo la creación de un marco de trabajo común para evaluar la calidad del producto software. ISO/IEC 25001 - Planning and Management: establece los requisitos y orientaciones para gestionar la evaluación y especificación de los requisitos del producto software. 11 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.3 PROPIEDAD INTELECTUAL DEL SOFTWARE. La propiedad intelectual del autor y director del Proyecto o Trabajo Fin de Carrera se regirá por el Real Decreto Legislativo 1/1996, de 12 de abril, por el que se aprueba el texto refundido de la Ley de Propiedad Intelectual El autor de este proyecto permitirá la distribución del software en formato Open Source..GPL…Y aunque se permitirá su distribución y copia Creative Commons derivativa..etc al autor se la asignará la Propiedad Intelectual de creación del software y rseto de material que acompaña este PFC. 5.3.1 COMPETENCIAS REFERIDAS A LA PROGRAMACIÓN Artículo 1. Los programas de ordenador serán protegidos mediante los derechos de autor como servicios literarias tal como se definen en el Convenio de Berna para la protección de servicios literarias y artísticas. A los efectos de la presente Ley, la expresión programas de ordenador comprenderá también su documentación preparatoria. El programa de ordenador será protegido únicamente si fuese original, en el sentido de ser una creación intelectual propia de su autor. La protección prevista en la presente Ley se aplicará a cualquier forma de expresión de un programa de ordenador, salvo aquéllas creadas con el fin de ocasionar efectos nocivos a un sistema informático. Las ideas y principios en los que se base cualquiera de los elementos de un programa de ordenador, incluidos los que sirven de fundamento a sus interfaces, no estarán protegidos mediante los derechos de autor con arreglo a la presente Ley. Artículo 2. Titularidad de los derechos. 12 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Será considerado autor del programa de ordenador la persona o grupo de personas físicas que lo hayan creado, o la persona jurídica que sea contemplada como titular de los derechos de autor en los casos expresamente previstos por la Ley de Propiedad Intelectual. Cuando se trate de servicios colectivas tendrá la consideración de autor, salvo pacto en contrario, la persona física o jurídica que la edite y divulgue bajo su nombre. Los derechos de autor sobre un programa de ordenador que sea resultado unitario de la colaboración entre varios autores serán propiedad común y corresponderán a todos éstos en la proporción que determinen. Cuando un trabajador asalariado cree un programa de ordenador, en el ejercicio de las funciones que le han sido confiadas o siguiendo las instrucciones de su empresario, la titularidad de los derechos económicos correspondientes al programa de ordenador así creado -tanto el programa fuente como el programa objeto- corresponderán, exclusivamente, al empresario, salvo pacto en contrario. Artículo 3. Beneficiarios de la protección. La protección se concederá a todas las personas físicas y jurídicas que cumplan los requisitos establecidos en la Ley de Propiedad Intelectual para la protección de los derechos de autor. Artículo 4. Actos sujetos a restricciones. Sin perjuicio de lo dispuesto en los artículos 5 y 6, los derechos exclusivos de la explotación del programa de ordenador por parte de quien sea su titular con arreglo al artículo 2, incluirán el derecho de realizar o de autorizar: a) La reproducción total o parcial de un programa de ordenador por cualquier medio y bajo cualquier forma, ya fuere permanente o transitoria. Cuando la carga, presentación, ejecución, transmisión o almacenamiento de un programa necesiten tal reproducción deberá disponerse de autorización para ello, que otorgará el titular del derecho. 13 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado b) La traducción, adaptación, arreglo o cualquier otra transformación de un programa de ordenador y la reproducción de los resultados de tales actos, sin perjuicio de los derechos de la persona que transforme el programa de ordenador. c) Cualquier forma de distribución pública incluido el alquiler del programa de ordenador original o de sus copias. La primera venta en la Comunidad de una copia de un programa por el titular de los derechos o con su consentimiento, agotará el derecho de distribución de dicha copia, salvo el derecho de controlar el subsiguiente alquiler del programa o de una copia del mismo. Artículo 5. Excepciones a los actos sujetos a restricciones. No necesitarán autorización del titular, salvo disposición contractual en contrario, la reproducción o transformación de un programa de ordenador incluida la corrección de errores, cuando dichos actos sean necesarios para la utilización del mismo por parte del usuario legítimo, con arreglo a su finalidad propuesta. La realización de una copia de seguridad por parte de quien tiene derecho a utilizar el programa no podrá impedirse por contrato en cuanto resulte necesaria para dicha utilización. El usuario legítimo de la copia de un programa estará facultado para observar, estudiar o verificar su funcionamiento, sin autorización previa del titular, con el fin de determinar las ideas y principios implícitos en cualquier elemento del programa, siempre que lo haga durante cualquiera de las operaciones de carga, visualización, ejecución, transmisión o almacenamiento del programa que tiene derecho a hacer. Artículo 6. Decompilación. No será necesaria la autorización del titular del derecho cuando la reproducción del código y la traducción de su forma en el sentido de las letras a) y b) del artículo 4 de la presente Ley, sea indispensable para obtener la información necesaria para la interoperabilidad de un programa creado de forma independiente con otros programas, siempre que se cumplan los siguientes requisitos: 14 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado a) que tales actos sean realizados por el usuario legítimo o por cualquier otra persona facultada para utilizar una copia del programa, o, en su nombre, por parte de una persona debidamente autorizada; b) que la información necesaria para conseguir la interoperabilidad no haya sido puesta previamente, y de manera fácil y rápida, a disposición de las personas a que se refiere la letra anterior; c) que dichos actos se limiten a aquellas partes del programa original que resulten necesarias para conseguir la interoperabilidad. La excepción contemplada en el número 1 de este artículo será aplicable siempre que la información así obtenida: a) se utilice únicamente para conseguir la interoperabilidad del programa creado de forma independiente; b) sólo se comunique a terceros cuando sea necesario para la interoperabilidad del programa creado de forma independiente, y c) no se utilice para el desarrollo, producción o comercialización de un programa sustancialmente similar en su expresión, o para cualquier otro acto que infrinja los derechos de autor. Las disposiciones del presente artículo no podrán interpretarse de manera que permitan que su aplicación perjudique de forma injustificada los legítimos intereses del titular de los derechos o sea contraria a una explotación normal del programa informático. Artículo 7. Duración de la protección. Los derechos reconocidos en esta Ley serán protegidos en los términos establecidos en el artículo 97 de la Ley de Propiedad Intelectual en el caso de que el autor sea una persona jurídica y durante la vida del autor y cincuenta años después de la muerte o declaración de fallecimiento del mismo o del último coautor sobreviviente cuando sea una persona física. 15 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Cuando el programa de ordenador sea una obra anónima o bajo seudónimo, el plazo de protección será de cincuenta años desde el momento en que se puso legalmente por primera vez a disposición del público, considerándose que el plazo de protección comienza el 1 de enero del año siguiente al de este hecho. Artículo 8. Infracción de los derechos. A efectos de la presente Ley y sin perjuicio de lo establecido en los artículos 5 y 6 de la misma, tendrán la consideración de infractores de los derechos de autor quienes, sin autorización del titular de los mismos, realicen los actos previstos en el artículo 4 y, en particular: a) quienes pongan en circulación una o más copias de un programa de ordenador conociendo o pudiendo presumir su naturaleza ilegítima, b) quienes tengan con fines comerciales una o más copias de un programa de ordenador, conociendo o pudiendo presumir su naturaleza ilegítima, o c) quienes pongan en circulación o tengan con fines comerciales cualquier medio cuyo único uso sea facilitar la supresión o neutralización no autorizadas de cualquier dispositivo técnico utilizado para proteger un programa de ordenador. Artículo 9. Medidas especiales de protección. El titular de los derechos reconocidos por la presente Ley, sin perjuicio de otras acciones que le correspondan, podrá instar el cese de la actividad ilícita del infractor, exigir una indemnización acorde con los daños materiales y morales causados, y solicitar del Juez la adopción de medidas cautelares de protección urgente en los términos del Título I del Libro III de la Ley de Propiedad Intelectual. A los efectos de esta Ley, y antes de dar traslado a las partes del escrito de solicitud de medidas cautelares, tal y como previene el artículo 127 de la Ley de Propiedad Intelectual, el Juez podrá requerir los informes u ordenar las investigaciones que estime oportunas. 16 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Las medidas cautelares para la protección urgente de los derechos de autor podrán comprender el secuestro de los medios a que se refiere la letra c) del artículo 8 en los términos establecidos por el artículo 126 de la Ley de Propiedad Intelectual. El cese de la actividad ilícita podrá comprender la inutilización y, en caso necesario, destrucción de los instrumentos referidos en el número anterior. 17 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.4 PLIEGO DE CONDICIONES PARA EL TRATAMIENTO ESTANDARIZADO DE LOS DATOS – OPEN DATA – La gestión de la información es algo de suma relevancia para el aprovechamiento y reutilización de la misma. Una óptima gestión de la información, no sólo irá destinada a una mejora de la experiencia de los usuarios finales y las operarios de captura y de los controladores de la APP en Processing y web, sino que deberá tener en cuenta el procesado automático por parte de las máquinas y aplicaciones que actúa como efecto multiplicador y aliado a la hora de incrementar el uso de los servicios. 5.4.1 SEMÁNTICA Y LINKED DATA Con la evolución de la Web, existen mecanismos que permiten describir la información de forma que no sólo sea legible y comprensible por las personas, sino que también permite que las máquinas interpreten los conceptos que esa información representa. Dentro de la Web existen diferentes creadores de información y servicios especializados en sus ámbitos que ofrecen sus datos para que sean reutilizados por otras entidades, lo que permite a los consumidores, centrarse en sus objetivos de negocio sin preocuparse por las áreas que desconoce. Los datos que se relacionan entre sí podrán ser reutilizados por otros de forma recursiva. Esto se conoce como Linked Data o datos enlazados en la Web. En este caso la mezcla de diferentes hardwares como Arduinos y Softwares en diferentes plataformas. 18 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.4.2 REUTILIZACIÓN DE INFORMACIÓN Para la información generada desde las placas microcontroladoras de Arduino; el 16 de noviembre se decretó la Ley 37/2007 sobre reutilización de la información, que pretende promover la puesta a disposición de los documentos de interés a través de medios electrónicos. De esta forma, es importante que los datos que sean susceptibles de ser publicados queden a disposición del público en formato electrónico para así poder sacar un mayor rendimiento a toda la información y fomentar la participación democrática. Una buena estructuración y definición de los datos es de suma importancia para que se consiga una interoperabilidad entre las distintas partes interesadas en integrar y compartir esta información, siendo un objetivo del proyecto la potenciación de dicha interoperabilidad 5.4.3 JUSTIFICACIÓN Y ENFOQUE Se considera la necesidad de crear un sistema que favorezca la promoción, la optimización y un incremento del uso de los servicios electrónicos. Capturas en hardware y uso en software incluido. Los usuarios deberán poder consumir dicha información en formatos estructurados y fácilmente procesables (p.e., RSS, ATOM o cualquier otro mecanismo que favorezca el procesado automático de los datos) en este caso se optó por JSON y que permita las suscripciones selectivas a los temas de interés. Con ello se persigue la contextualización del servicio a las preferencias concretas de quien lo utiliza, enfocando y acercando la información en el proceso. La información relacionada deberá estar enlazada entre sí, a través de enlaces que se permita el acceso entre las partes, y así poder enriquecer cualquier dato con datos específicos en un área. En este caso haciendo especial hincapié en que esa información en modo web de los datos ya almacenados por los Apps generadas en Processing puedan generar históricos compatibles. 19 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Por último, la plataforma deberá tener en cuenta aspectos como el acceso a la información y a los servicios desde dispositivos móviles, cada vez más relevante en la proporción del número de accesos a los sitios web así como creación de widgets, o pequeñas aplicaciones web, que permitan tratar los datos o combinaciones de los mismos. Será en este caso un RWP como se ha explicado en la memoria, y por ello no será necesaria la creación de Apps propias. 5.4.4 ALCANCE Y OBJETIVOS Se debe desarrollar un sistema que sea fácilmente integrable e interoperable. 5.4.5 CLASIFICACIÓN Y SEGUIMIENTO DE LOS SERVICIOS ELECTRÓNICOS Esta información, además de ser legible por las personas, deberá poder ser tratada de forma automática mediante el procesamiento de los metadatos de clasificación. La publicación de esta información se lleva a cabo mediante un servicio web que, ante una petición web, devuelva la información estructurada en formatos legibles para las máquinas (XML, RSS, RDF, json para files etc.). La llamada al servicio web debe hacerse mediante una dirección web (URL) y la respuesta obtenida debe estar claramente identificada. En el caso de devolver un fichero XML o RDF, el usuario debe tener la posibilidad de conocer el esquema que sigue para la representación. En la llamada al servicio web, se debe poder especificar los criterios de selección de los servicios a mostrar, en función de sus categorías y los formatos entregados estarán sujetos a negociación automática. Además de esta información accesible desde un punto de entrada concreto, la información sobre los trámites electrónicos, que está expresada en XHTML, HTML5 deberá incluir metadatos sencillos y, en la medida de lo posible, 20 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado estándares en el etiquetado (fechas, datos adquiridos por sensores), que permita a las máquinas hacer procesamientos automatizados sobre los servicios. La información deberá tener un punto de consulta sobre la totalidad de los servicios y su información a través de un lenguaje de consulta estándar, que permita obtener datos específicos. 5.4.6 DATOS ENLAZADOS El sistema de introducción de los datos, debe tener presente la posibilidad de enriquecer la información existente con otros datos ya presentes, incluso de terceros, como información geográfica de GPS suplementaria o datos estadísticos de historiales. Esta información, si es susceptible de ser enlazada, no es necesario que sea replicada, sino que sería suficiente añadir un enlace. Cabe destacar que estos enlaces, siguiendo el paradigma de los Datos Enlazados o Linked Data, no son enlaces de hipertexto, sino que en lugar de enlazar a documentos textuales, lo hacen a datos procesables automáticamente (documentos XML, RDF, etc.). Esta funcionalidad del sistema debe de ser aplicable a la hora de la introducción de información sobre nuevos servicios en el backoffice que se diseñe en web y bajo Processing y debe permitir añadir y modificar esa información en los trámites ya existentes. Para enriquecer los servicios, se valorará la identificación y representación de información relacionada con las áreas de competencia próximas a los mismos, utilizando mecanismos y formatos estándares abiertos. Esta información otorgará al servicio un valor adicional tras la vinculación entre sí. Para el acceso a la información será necesario establecer un modelo de acceso a los datos unívoco y persistente en el tiempo a través de URIs (Identificador de Recurso único). Dicho sistema de URIs deberá abstraer la estructura corporativa que presta el servicio. 21 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.4.7 FACILIDAD AL USUARIO Y MULTICANALIDAD Para facilitar el consumo de la información, y dada la diversidad de dispositivos que pueden solicitar la información, es requisito de este PFC que en el proceso se apliquen estándares que faciliten este objetivo. La publicación de los datos reutilizables se realizará siguiendo formatos abiertos y estándares. Ésto facilita la creación de aplicaciones con datos enlazados (mashups) y widgets (pequeñas aplicaciones que se pueden incrustar en los sitios web). Es una de las funcionalidades más avanzadas de este proyecto, que un PFC muestre mashups tan potentes como las usadas a través de las APIs bajo Unfolding. 5.4.8 REQUISITOS TÉCNICOS Todas las acciones recogidas en la propuesta deberán cumplir los requisitos en cuanto a la Ley 11/2007 de Acceso Electrónico de los Ciudadanos a los Servicios Públicos y la 37/2007 para la Reutilización de Información. Cualquier actuación que suponga un enriquecimiento semántico de la información deberán seguir las recomendaciones del W3C en materia de Web Semántica. En todo lo referente a independencia de dispositivo, se tendrá en cuenta las recomendaciones propuestas por la Iniciativa de Web Móvil del W3C. En la parte de accesibilidad de los contenidos Web, se deberá cumplir con las recomendaciones de Accesibilidad Web (WCAG 2.0) del WAI-W3C. En este sentido, cualquier actuación del proyecto que sea de aplicación sobre la capa de presentación web, deberá tener en cuenta y alienarse con la política de accesibilidad Web que se concreta en la Certificación de Accesibilidad UNE139803, 22 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado La accesibilidad deberá tenerse en cuenta en dos aspectos: El desarrollo basado en XHTML, HTML5 deberá ser accesible doble A según la normativa actual y las WCAG 2.0. Los formatos para reutilización deberán ser igualmente accesibles. Idem para el tratamiento en php, html5, y su vinculación entre apps. 5.4.9 PLATAFORMA CLIENTE El sistema desarrollado deberá poder ser ejecutado en su totalidad desde navegadores Web estándar. El sistema garantizará su funcionamiento al 100% al menos en los siguientes navegadores: Internet Explorer 6 o superior Mozilla Firefox 2.0 o superior Safari versión 3 o superior Google Chrome Opera Además, los datos deberán poder ser consultados a través navegadores semánticos como los siguientes: Marbles Disco 23 de Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.4.10 Listado de navegadores en diferentes versiones y su compatibilidad Para comprobar la compatibilidad de nuestra aplicación web se le somete a un test de compatibilidad en todos los navegadores del mercado en sus diferentes versiones. Al estar desarrollada principalmente en html5, Jquery, Javascript se ve que la compatibilidad es del 99%. Ilustración 167 Compatibilidad Navegadores 24 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 168 Compatibilidad Navegadores Ilustración 169 Compatibilidad Navegadores 25 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Ilustración 170 Compatibilidad Navegadores 26 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.4.11 PERFILES Y PERSONAS Los perfiles requeridos para desarrollar el proyecto son los que especifican a continuación: 5.4.12 CONSULTOR SEMÁNTICO Ingeniero técnico informático o superior, o licenciatura similar. Este perfil de consultor debe tener conocimientos y experiencia demostrable sobre tecnologías y mecanismos de Web Semántica, ontologías, arquitectura de la Web. 5.4.13 ANALISTA FUNCIONAL Ingeniero técnico informático o superior, o licenciatura similar. Este perfil desarrolla la función de analista que permite identificar las necesidades del sistema, contando con conocimientos y experiencia demostrable en proyectos sobre tecnologías semánticas y en la reutilización de datos. 5.4.14 PROGRAMADOR Ingeniero técnico informático o superior, o licenciatura similar. Este perfil representa a un desarrollador que dispone de conocimientos y experiencia demostrable en tecnologías de la Web Semántica, tratamiento de RDF, RDFa, Esquemas XML, Servicios Web, OWL, Esquemas RDF, json, php, mysql , etc. 5.4.15 EXPERTO EN A RQUITECTURA DE LA INFORMACIÓN Lingüista. Este perfil define a un experto con experiencia demostrable que permita la integración de los datos semánticos con los datos existentes, con experiencia en la gestión de ontologías. Debe tener un dominio de los vocabularios estándares, que se usan en la representación semántica de la información. 27 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.4.16 CONDICIONES DEL SERVICIO Cualquier actuación sobre los servicios en producción (cambios, pruebas, etc.), deberá realizarse fuera del horario laboral, en las condiciones que el servicio por su criticidad determine. Todas estas acciones deberán ser valoradas y aceptadas por el Dtor Principal del proyecto y creador del código similar a la figura del committer de Debian. 5.4.17 REPOSITORIO DOCUMENTAL El proveedor utilizará el repositorio de la Universidad de La Rioja designe en el que el adjudicatario mantendrá y actualizará toda la información relativa al proyecto. En este repositorio se recopilará, al menos, la información siguiente: Configuración detallada de los sistemas y servicios Registro de los cambios efectuados en la configuración. Documentación del proyecto Contactos autorizados para el servicio A esta herramienta accederá el equipo de soporte del proveedor así como las personas designadas por la Universidad de La Rioja. 5.4.18 PROPIEDAD INTELECTUAL, SEGURIDAD YCONFIDENCIALIDAD. PROPIEDAD INTELECTUAL El adjudicatario aceptará expresamente que la propiedad intelectual de todos los documentos y resultados de los trabajos realizados quedarán en poder compartido en La Universidad de La Rioja, que podrá reproducirlos o divulgarlos total o parcialmente. Toda la documentación quedará en copropiedad de la Universidad de La Rioja sin que el adjudicatario pueda conservarla o facilitarla a terceros sin la expresa 28 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado autorización de este centro directivo, que le daría en su caso previa petición formal del contratista con expresión del fin. El adjudicatario deberá entregar obligatoriamente a la Universidad de La Rioja el código fuente actualizado de la aplicación y proporcionar una solución de continuidad, en caso de cese en su actividad o bajo cualquier otra circunstancia imputable a dicha empresa que impida el correcto mantenimiento de los programas. La Universidad de La Rioja tendrá en consideración los intereses legítimos del prestador del servicio en lo referente a la protección de los secretos técnicos o comerciales de su empresa, comprometiéndose específicamente en relación con las fuentes de la aplicación a no distribuir las mismas y a hacer uso de ellas exclusivamente en el ámbito propio. Se entregará un planning temporal y formal detallado y exhaustivo que incluya todos los hitos de desarrollo, coordinación, puesta en marcha, formación, etc. Toda la información ha de estar disponible, al menos, en formato ODT, PDF y HTML Todos los documentos que componen la documentación estarán estructurados de la misma forma. Toda la documentación estará en castellano. 29 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.5 PLIEGO DE CONDICIONES ADMINISTRATIVAS 5.5.1 DOCUMENTACIÓN DEL PROYECTO Este proyecto consta de los siguientes documentos que nos ayudarán a comprender el desarrollo del mismo. Estos documentos y planos son: Un Índice General con cada uno de los índices individuales de los diferentes documentos básicos del proyecto. En él se incluyen datos del proyecto, de quién encarga el mismo y de sus autores. Una Memoria donde se consideran las necesidades a satisfacer y los factores técnicos a tener en cuenta entrando en profundidad en las posibles soluciones técnicas y en la justificación de la solución elegida. Anexos donde se recoge la documentación considerada para establecer los requisitos de diseño. Cálculos y decisiones donde se justifiquen las soluciones adoptadas en cuanto a elección de valores en los diferentes componentes ( placas Arduinos , cuatricopteros etc ) del esquema electrónico y otros documentos como catálogos, datasheets, etc. Una serie de Planos de Montaje (carga de sensores en el cuatrirotor) los cuales deben servir para la perfecta realización de la PCB, este caso presentada bajo Fritzing así como su instalación, expresando con exactitud la distribución de los componentes por la placa y las medidas de la misma. Incluyendo un diagrama de bloques que facilite la comprensión de los vínculos físicos entre los diferentes elementos. Pliego de Condiciones y Especificaciones del Sistema donde se establecerán las diferentes condiciones técnicas, económicas y administrativas para que el objeto del proyecto pueda materializarse en las correspondientes condiciones específicas y especificadas, evitando posibles mal interpretaciones referentes a cualquier tema. 30 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Presupuesto donde se recoge el coste de todos los componentes utilizados y la suma total que junto a la mano de obra dará el coste final del proyecto. Dicho presupuesto contendrá la valoración económica global, desglosada y ordenada por partidas. Asimismo el presupuesto tendrá opciones diferentes para la salida de este trabajo y su posterior implantación, ya sea venta, alquiler de los equipos de vuelo o régimen concursal 5.5.2 CONDICIONES DE SEGURIDAD Software de conola o web obra de nuestro proyecto forma parte de las instalaciones interiores o receptoras según dice el manual electrotécnico para baja tensión. Las instalaciones interiores o receptoras son las que, alimentadas por una red de distribución o por una fuente de energía propia, tienen como finalidad principal la utilización de la energía eléctrica. Dentro de este concepto hay que incluir cualquier instalación receptora aunque toda ella o alguna de sus partes esté situada a la intemperie, como nuestro caso que es totalmente intemperie que será principalmente el tema de vuelos de estos multirotores. En toda instalación interior o receptora que se proyecte y realice se alcanzará el máximo equilibrio en las cargas que soportan los distintos conductores que forman parte de la misma, y ésta se subdividirá de forma que las perturbaciones originadas por las averías que pudieran producirse en algún punto de ella afecten a una mínima parte de la instalación. Esta subdivisión deberá permitir también la localización de las averías y facilitar el control del aislamiento de la parte de la instalación afectada. Los sistemas de protección para las instalaciones interiores o receptoras para baja tensión impedirán los sobretensiones que por efectos distintas de causas las sobreintensidades cabe prever en las y mismas y resguardarán a sus materiales y equipos, principalmente ordenadores , placas microcontroladoras, etc .de las acciones y efectos de los agentes externos. Asimismo, y condiciones que deben a efectos de seguridad general, se 31 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado determinarán las cumplir dichas instalaciones para proteger de los contactos directos e indirectos. En la utilización de la energía eléctrica para instalaciones receptoras se adoptarán las medidas de seguridad, tanto para la protección de los usuarios como para la de las redes, que resulten proporcionadas a las características y potencia de los aparatos receptores utilizados en las mismas. 5.5.3 SEGURIDAD Y PREVENCIÓN Durante la realización de los servicios de vuelos en régimen de Alquiler de Multirotores se estará de acuerdo en todo momento con el "Reglamento de Seguridad e Higiene en el Trabajo" y, en general, con todas aquellas normas y ordenanzas encaminadas a proporcionar el más alto grado de seguridad, tanto al personal, como al público en general. Si fuera necesario licencias o permisos de vuelo se está al día en normativa, incluyendo las nuevas disposiciones que están pendientes para este 2014 en sistemas de vuelo de Drones. El instalador efectuará a su cargo el plan de seguridad y el seguimiento correspondiente a sus trabajos, debiendo disponer de todos los elementos de seguridad, auxiliares y de control exigidos por la legislación vigente. Todo ello con la debida coordinación en relación al resto de los servicios, por lo que será preceptiva la compatibilidad y aceptación de este trabajo con el plan de seguridad general de los servicios y, en cualquier caso, deberá contar con la conformidad de la Dirección Técnica responsable en obra de esta materia y el contratista general. En cualquier caso, queda enterado el instalador, por este pliego de condiciones técnicas, que es de su total responsabilidad vigilar y controlar que se cumplen todas las medidas de seguridad descritas en el plan de seguridad, así como las normas relativas a montajes y otras indicadas en este apartado. 32 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.5.4 NORMATIVA Y REGLAMENTACIÓN El proyecto está supeditado tanto a normativa española como a normas de uso internacional. Una de las principales normas que debemos tener en cuenta para la realización de este proyecto es La normativa del RBT (Reglamento de Baja Tensión). Considerándose pequeñas tensiones a aquellas inferiores o iguales a 50 V eficaces. Asimismo el RBT nos indica que las instalaciones que puedan producir perturbaciones deberán de estar dotadas de sistemas correctores. Respecto al desarrollo de productos electrónicos, se pueden encontrar en AENOR (Asociación Española de Normalización y Certificación) las siguientes normativas: Norma UNE1302-2:1973. Vocabulario electrotécnico. Electrónica. Norma UNE-EN-50090-2-1:1996. Sistemas electrónicos para viviendas y edificios. Norma UNE-EN61000-4-3-1998. Compatibilidad electromagnética. Norma EB123500:1992. Placas de circuitos impresos flexibles con taladros para inserción de componentes. UNE 20-050-74. Código para las tolerancias. Valores y marcas de resistencia y condensadores. UNE 20-531-73. Series de colores nominales para resistencias y condensadores. Otras normas para la fabricación y empleo de placas de circuitos impresos (PCB) son las siguientes: NORMAS DIN: DIN40801. Parte 1. Circuitos impresos, fundamentos, retículos. DIN 40801. Parte 2. Circuitos impresos, fundamentos, orificios y espesores nominales. 33 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado DIN 40803. Parte 1. Circuitos impresos, placas de circuito impreso, requisitos generales y comprobaciones, tablas de tolerancias. DIN 40803. Parte 2. Circuitos impresos, placas de circuito impreso, documentación. DIN40804. Circuitos impresos, conceptos. DIN 41494. Formas de construcción para dispositivos electrónicos, placas de circuito impreso, medidas. NORMAS UNE UNE 20-524-75. Técnica circuitos impresos. Parámetros fundamentales. Sistema de cuadrícula. UNE 20-524. Equipos electrónicos y sus componentes. Soldabilidad de circuitos impresos. UNE20-524. Técnica de circuitos impresos. Terminología. UNE 20 552 75. Diseño y utilización de componentes para cableados y circuitos impresos. UNE 20620-1:1993. Material base para circuitos impresos. Métodos de ensayo. UNE 20621-3:1984. Circuitos impresos. Diseño y utilización de placas impresas. Otra de las normas que sustentan este proyecto es la normativa RoHS (Restriction of use of certain Hazardous Substances), su objetivo consiste en la reducción de sustancias peligrosas usadas en la fabricación. Se disminuyen con su aplicación los riesgos del tratamiento de los residuos, con lo que se requieren menos precauciones de manipulación. 34 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado La RoHS es una directiva de la UE que restringe el uso de 6 materiales peligrosos en la fabricación de diversos electrónicos, obligando a los fabricantes a tipos de demostrar equipos eléctricos y que sus productos contienen valores de concentración por debajo de los valores de concentración máximos (VCM), en las siguientes substancias: plomo, mercurio, cadmio, cromo hexavalente, bifenilos (PBDE). policromados (PBB) y éter de bifenilo policromado. Es una directiva de “mercado único”, es decir, establece estándares de productos y se aplica a todos los estados miembros, debiéndose implantar de la misma manera en todos ellos. 5.5.5 ÁMBITO DE ACTUACIÓN La adquisición de este proyecto de mediciones medioambientales mediante UAD está relacionada con la necesidad de conocer datos medioambientales determinados de un lugar de transito ciudadano, ya que su misión principal es la de proporcionar información. Su ámbito de aplicación puede ser cualquier punto del territorio nacional o territorio internacional, tanto para empresas privadas como para entidades públicas como ayuntamientos. Variable Temperatura Humedad relativa Dióxido de Azufre Ozono Dióxido de Nitrógeno Sulfuro de Hidrógeno Monóxido de Carbono Límite inferior -20ºC 5% RH 0 ppm 0 ppm 0 ppm 0 ppm 0 ppm Límite superior 100ºC 85%RH 500 ppm 500 ppm 500 ppm 500 ppm 1000 ppm Tabla: Límites válidos. 35 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.6 PLIEGO DE CONDICIONES TÉCNICAS En este apartado se analizan los pasos a seguir para la correcta consecución del producto mediante la explicación del proceso de fabricación del mismo, junto a las precauciones que se deberán tener en cuenta tanto en su manejo como en su fabricación, en relación a la verificación del conjunto. Se hará referencia a las características de las que deben disponer los sensores y el propio software de medición de Processing las cuales serán de obligado cumplimiento. 5.6.1 VERIFICACIONES PREVIAS Una vez que se han realizado sobre el los ensayos fijados por la normativa vigente y los especificados en el apartado de normas de mediciones e inspección de partidas de materiales, y se han superados todos y cada uno de ellos, se procederá a verificar que el resultado cumple los requerimientos impuestos por el cliente. A tal efecto se revisará: Facilidad de uso Fiabilidad del conjunto del sistema El marcado CE indica que estas revisiones han sido realizadas y que el producto es seguro de acuerdo con la Normativa Europea, esta normativa será quien establezca las normas y criterios que rijan estas verificaciones. La Dirección de Obra y/o la propiedad podrán solicitar cualquier tipo de Certificación Técnica de materiales y/o montajes. Asimismo, podrán realizar todas las revisiones o inspecciones que consideren. Especialmente las relacionadas con dispositivos de vuelo, que pueden generar problemas de altos riesgo. Las mencionadas inspecciones pueden ser totales o parciales, según los criterios que la dirección de obra dictamine al respecto para cada caso. 36 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.6.2 CONDICIONES GENERALES DE LOS MATERIALES Todos los componentes utilizados en el proyecto cumplen las especificaciones técnicas que aparecerán descritas tanto en la Memoria, como en los planos, estando presente en estos últimos las particularidades técnicas referentes a valores, referencias y demás especificaciones relevantes utilizadas en resistencias, condensadores, sensores, transformador, etc. 5.6.3 COMPONENTES ELECTRÓNICOS Todos los componentes electrónicos empleados en la elaboración del Proyeco de Medición y Supervisión remota de parámetros ambientales mediante UAD deben atender a los requerimientos de potencia, tensión y corriente demandados por el sistema. Todos los elementos deben cumplir al menos con las especificaciones del sistema, incluso las podrán mejorar si eso no afecta de manera constatable al aumento del coste final del proyecto. Vendrá convenientemente especificado en el Listado de Materiales (Bill of Materials) especifico en cada plano y adjunta documentación listada. Asimismo adjunta en los listados del software Fritzing, si los distintos componentes son SMD (Surface Mounted Device) o THD (Through-Hole Device), donde cada elemento electrónico usado irá asociado con su encapsulado y dimensiones. 5.6.4 SENSORES Los sensores a utilizar, deben atender a los requerimientos eléctricos del sistema y a las condiciones tecnológicas que se les exigen. Además deben ajustarse a las características exigidas por el sistema para la medición precisa de las diferentes variables. Explicadas en la memoria, y adjuntos un anexo un listado de sensores alternativos a usar para estas mediciones. Sensores para la medida de la calidad del aire: 37 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Este proyecto está pensado para una finalidad real de mediciones ambientales. Para la medida de la calidad del aire, se utilizan sensores de gas químicos que se basan fundamentalmente en la toma de una muestra de partículas que produce un cambio físico o químico de un material sensible, el que, mediante una circuitería de interface, provoca una señal eléctrica que constituye la respuesta del sensor. Se tratan de sensores, en la mayoría de los casos (salvo el sensor de detección de ozono de la serie MQ, del Anejo ) electroquímicos en modo amperimétrico, es decir, generan una corriente lineal proporcional a la fracción de volumen de gas detectado Esto da como resultado un sensor fácilmente ajustable a los niveles de entrada de la unidad de procesamiento sin necesidad de mucha circuitería de adaptación que eleve el coste. En este caso, la salida es corriente y resulta fácilmente ajustable a los niveles de tensión del microprocesador. Además todos los sensores utilizados son adaptables para la placa Arduino. Compatibles, probados y con so código de Arduino fácilmente operable. En el caso del sensor de detección de ozono, el problema resulta menor todavía, ya que se trata de un sensor con una salida de tensión analógica, el cual sin más que adaptar esa tensión a los niveles del microprocesador, tenemos la adaptación. En cuanto a la durabilidad de los sensores, al tratarse de sensores e electroquímicos, no tienen una durabilidad relativamente elevada, ya que el gas que entra en contacto con el sensor, reacciona sobre la superficie del electrodo sensor generando una reacción de oxidación o reducción. Los materiales del electrodo, específicamente desarrollados para el gas de interés, catalizan estas reacciones. Dada esta tecnología, deberán cambiarse los sensores cada 2 años para obtener una medida fiable. Siempre consultando las Hojas de especificaciones del fabricante. Adjuntas todas las series MQ en los Anejos de este proyecto en formato de link directo. 38 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.6.5 MATERIAL DE LOS CABLES El cable que se utiliza para la instalación será un cable de 0,75 milímetros de sección de hilo y será rojo para llevar la alimentación, negro para la masa, verde para el cable de conexión de tierra y el resto de cables serán de color azul para no confundirlos con el resto. Los colores vendrán especificados en los planos, especiales para GPS, Xbee, etc. 5.6.6 CARACTERÍSTICAS DE LOS SERVICIOS CIVIL De acuerdo con el BOE-A-2010-4057, se entiende por mobiliario urbano el conjunto de elementos existentes en los espacios públicos urbanizados y áreas de uso peatonal, cuya modificación o traslado no genera alteraciones sustanciales. Los elementos de mobiliario urbano de uso público se diseñarán y ubicarán para que puedan ser utilizados de forma autónoma y segura por todas las personas. Su ubicación y diseño responderá a las siguientes características: No existe obra civil pero se regirá por la normativa actual de vuelo de equipos multirotores actualizada en previsiones para 2014. 5.6.7 ENSAMBLADO E INTERCONEXIONADO DE LOS DISTINTOS ELEMENTOS El ensamblado e interconexionado de los distintos elementos integrados en las placas, ambas separadas, lo llevará a cabo el instalador según la disposición indicada en los planos correspondientes. 5.6.8 TEST DE VALIDACIÓN DE DATOS La información mostrada relativa a la medida de cada sensor debe ser validada como paso previo a cualquier aplicación. Esta validación asegura que la información está siendo generada adecuadamente, identifica los registros 39 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado erróneos y permite detectar problemas para resolverlos mediante las oportunas labores de mantenimiento, reparación, calibración o sustitución de las partes que ocasionen contrariedades. Validación de los datos según límites. En este nivel de validación se comprueba el rango de los valores de concentración límite de cada sensor. Por rango entendemos el límite superior y el inferior entre los que debe estar el valor de un dato para ser considerado como válido. Se definen dos tipos de límites: límites físicos e instrumentales y límites flexibles (efemérides meteorológicas). Límites rígidos: físicos e instrumentales. Se aplicarán los límites que resulten más restrictivos de los físicos e instrumentales. Cualquier dato fuera de los límites establecidos será un dato no válido. En la tabla se indican los límites físicos de cada medida. Variable Temperatura del aire Humedad relativa del aire Dióxido de Azufre Ozono Dióxido de Nitrógeno Sulfuro de Hidrógeno Monóxido de Carbono Unidad ºC % Rango -20ºC / 100ºC 0/100 0 ppm 0 ppm 0 ppm 0 ppm 0 ppm 500 ppm 500 ppm 500 ppm 500 ppm 500 ppm Tabla Límites físicos de cada medida. Limites flexibles: efemérides meteorológicas Estos límites se basarán en los valores extremos que las distintas variables puedan tomar en la zona donde está ubicada la estación o el vuelo del multirotor. Lo ideal es contar con un conjunto de efemérides meteorológicas para cada mes, que sean representativas del entorno de donde provienen los datos que se validan. Si el dato no superase este test de límites flexibles será calificado como sospechoso y se deberá hacer una inspección visual para considerarlo válido o no. 40 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.6.8.1 Validación de la coherencia interna de los datos. Relaciones entre variables. Los procedimientos denominados de coherencia interna están basados en la verificación de la coherencia física o climatológica de cada variable observada o también de la consistencia entre variables. Valores medidos al mismo tiempo y en el mismo lugar no pueden ser incoherentes entre ellos. En este caso, puesto que no se puede discernir cuál de las variables involucradas es la responsable, se considerará que ambas observaciones no han superado este test. Inspección visual. Para llevar a cabo una inspección visual sobre los datos que se pretende analizar, resulta muy útil representar la evolución temporal de las distintas variables en varios niveles de agregación, especialmente cuando se trate de determinar si un dato sospechoso es válido o no válido. Igualmente, resulta muy útil cartografiar valores máximos, mínimos, acumulados, etc. de las distintas variables así como de parámetros derivados. Para identificar problemas sutiles, en el caso de la temperatura, se recomienda un análisis de valores promedio a una hora específica del día. En el caso de la humedad relativa, la media de los máximos y la media de los mínimos. 5.6.9 PUESTA EN MARCHA Y MANTENIMIENTO El cliente deberá verificar el buen estado de los elementos que hayan sido instalados, placas, rotores, trasnsmisión, arduino, etc comprobando que no han recibido ningún golpe durante el transporte, ni que hayan llegado defectuosos. El cliente deberá leer detenidamente el manual de instrucciones de este Proyecto de mediciones ambientales mediante UAD, en caso de tener dudas deberá ponerse en contacto con el distribuidor del equipo. Una vez realizados los dos pasos anteriores, el usuario deberá poner en marcha y comprobar el funcionamiento de los equipos verificando que este sea correcto y viendo que cumple con las expectativas previstas. En caso de no ser así 41 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado se deberá poner en contacto con el distribuidor si detecta cualquier fallo o un mal funcionamiento para que se proceda a la subsanación del mismo o a la retirada del equipo en caso de insatisfacción del comprador. Si el sistema no fuese manipulado conforme a lo establecido por el fabricante, este no se hace cargo de los posibles fallos venideros. El fabricante se compromete a llevar a cabo un mantenimiento anual durante los dos primeros mese corriendo a su cargo el gasto originado por la sustitución de componentes de parte del equipo. Por otra parte, debe haber una serie de operaciones a realizar por el personal de mantenimiento del mismo, con la intención de evitar posibles fallos del sistema. * Las operaciones que se tienen que realizar con una frecuencia trimestral son: Las típicas revisiones de cableado de sensores que se monten el UAD, estado de hélices y tren de aterrizaje, baterías, y en resumen todo lo indicado en los catálogos oficiales de los equipos. 5.6.10 PRECAUCIONES DE USO Las regidas por la norma vigente sobre rotores menores de 5 kilos en vuelo, mas las básicas sobre dispositivos electrónicos. 5.6.11 PLIEGO DE CONDICIONES ECONÓMICAS 5.6.11.1 DERECHOS Y DEBERES DEL CONTRATISTA A continuación se enumeran los diferentes derechos y deberes del contratista entendiéndose tal como la persona física o jurídica que asume contractualmente ante el promotor, con medios humanos y materiales propios o ajenos, el compromiso de ejecutar la totalidad o parte de los servicios con sujeción al proyecto y al contrato. 42 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.6.11.2 DERECHOS 1. Derecho al abono del precio del contrato ejecutado con el arreglo a las cláusulas del presente pliego, dentro del término de dos meses a contar desde la expedición de los documentos que acrediten la realización total o parcial del contrato y entrada de la factura en el Registro General. 2. Derecho a cobrar el interés legal del dinero incrementado en 1,5 puntos sobre las cantidades adecuadas, si se demorase el pago del precio, a partir del incumplimiento de dicho plazo.* 3. Derecho a la suspensión del cumplimiento del contrato en el supuesto de que la demora del pago fuera superior a cuatro meses, debiendo comunicar a la Administración con un mes de antelación tal circunstancia, reconocimiento de a efectos del derechos que pudiera derivarse de la suspensión, en los términos establecidos en la ley 13/95 del 18 de Mayo. 4. Derecho a resolver el contrato y al resarcimiento de los perjuicios que como consecuencia de ello se originen, si la demora fuera superior a ocho meses. 5. Derecho a transmitir los derechos de cobro en los términos de los artículos 101 de la Ley 13/95 de 18 de Mayo. * No obstante, respecto a lo indicado en el segundo apartado, en el supuesto de que algún documento de los exigidos para efectuar el pago contuviera algún error u omisión, y el contratista no hubiera advertido en el momento de prestar conformidad a la recepción, expresamente y por escrito la existencia del mismo, el plazo para exigir el interés de demora no se iniciaría hasta que se subsanen los defectos u errores que contuviera el expediente de pago, computándose por lo tanto el plazo para exigir el interés legal del dinero a partir de la expedición de la documentación subsanada. De igual modo, si la factura contuviera algún error u omisión, el plazo para exigir interés de demora no se iniciará hasta que se subsanen los defectos que contuviera la factura. 43 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.6.11.3 DEBERES 1. El contratista deberá de cumplir las especificaciones descritas en el Pliego de Condiciones y en el documento de Especificaciones del sistema. 2. El contratista deberá de cumplir o realizar los servicios en el plazo estipulado en el Pliego de Condiciones. 3. El contratista deberá avisar o notificar cualquier cambio que quiera que sea realizado tanto en el diseño del prototipo como en el diseño del producto final. 5.6.12 DERECHOS Y DEBERES DEL CONTRATANTE Entenderemos contratante como la persona natural o jurídica, que se compromete mediante su firma a pagar el precio del proyecto, siendo por lo tanto su dueño. Tiene también el derecho de nombrar los beneficiarios y disponer de los valores garantizados del proyecto. 5.6.13 DERECHOS 1. Derecho a obtener unos beneficios a partir del tiempo estipulado para la realización del proyecto. 2. Derecho a poder elegir un contratista para la ejecución o realización de la puesta en funcionamiento del proyecto que él ha diseñado. 3. Derecho al control y supervisión en todo momento de la realización del proyecto, así como poder permitir variaciones en ellos, haciéndose cargo en la parte correspondiente a su cargo, de la valoración monetaria variada en el proyecto. 5.6.14 DEBERES 1. Deberá notificar todos los cambios producidos en el diseño del proyecto así como asimilar los gastos correspondientes. 2. Deberá comprobar que el contratista realiza las acciones según el Pliego de Condiciones. 44 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3. Deberá de haber realizado un Pliego de Condiciones según la Ley 13/95 de 18 de Mayo. 4. Deberá en todo momento de cumplir y hacer cumplir las especificaciones impuestas en el Pliego de Condiciones que él mismo ha diseñado. 5.6.15 FORMALIZACIÓN DEL CONTRATO El contrato se ejecutará a riesgo del contratista aunque ambas partes han de estar conformes en el contenido del contrato así como en las responsabilidades que se deriven de dicho contrato, las cuales están expuestas en este Pliego de Condiciones. Una vez se hayan puesto en contacto ambas partes se notificará al contratista para la formalización del oportuno contrato. En el contrato deberán estipularse, además de las condiciones ya descritas en el Pliego de Condiciones, 5.6.16 EXTINCIÓN DEL CONTRATO En caso de abandono, incumplimiento de contrato o de retraso en la finalización del proyecto, la empresa o usuario contratante podrá penalizar a la empresa encargada de la fabricación del panel informativo medioambiental con multas y hasta incluso con la anulación del contrato. El contrato se extinguirá por conclusión o cumplimiento, o bien por resolución. Siendo causas de resolución las siguientes: 1. El incumplimiento de las cláusulas contenidas en el Pliego de Condiciones. 2. La muerte del contratista individual, salvo que los herederos ofrezcan llevar a cabo el contrato bajo las condiciones estipuladas en el mismo. 3. La extinción de la personalidad jurídica de la sociedad mercantil del contratista, salvo que el patrimonio y organización de la sociedad extinguida sea incorporado a otra entidad, asumiendo ésta última las obligaciones de aquélla y 45 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado siempre que la nueva entidad, en el plazo de un mes, ofrezca llevar a cabo el contrato en las condiciones estipuladas. 4. El mutuo acuerdo entre el contratista y contratante. 5. La cesión a terceros del contrato sin autorización del contratante. 6. La declaración de quiebra del contratista o suspensión de pagos al contratista. 7. Cualquier otra causa que se establezca expresamente en el Pliego de Condiciones o en el contrato. 5.6.17 PLAZOS DE EJECUCIÓN El plazo de ejecución se establecerá después de la firma del contrato por parte de las partes correspondientes. En nuestro caso el plazo será de 3 días para la instalación del equipo, la realización del cableado y la puesta en marcha y funcionamiento de todo el sistema eléctrico-electrónico, El Software, equipos de vuelo, y personalización de consolas de captura de datos bajo Processing. El plazo de entrega se ha considerado haciendo un desmenuzamiento de los plazos parciales de entrega de los servicios en días, siendo los siguientes: 5.6.18 FORMA DE PAGO Las condiciones de pago del proyecto realizado serán determinadas por medio de la voluntad de las partes que deberá ponerse de manifiesto a través de dicho contrato. En este deberán figurar los datos de la persona física que ha encargado el proyecto tales como: nombre y apellidos de su representante legal, D.N.I., dirección profesional, etc. también deberán aparecer los datos del autor o autores del proyecto, la fecha de encargo, la fecha de entrega, así como 46 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado cualquier otro aspecto que las partes deseen de mutuo acuerdo que conste en dicho documento. La forma de pago adoptada debe de constar claramente en el contrato firmado por ambas partes pudiendo ser al contado, mediante talón bancario, tarjeta de crédito u otras opciones según se convenga. 5.6.19 FIANZA El contratista viene obligado a constituir y acreditar una fianza, previa a la formalización del contrato, siendo como mínimo de un 10% del precio del contrato, en el plazo de diez 10 días desde que se firme el contrato garantizando así su ejecución con el valor y en el plazo estipulado en el mismo. La fianza podrá constituirse en metálico o mediante aval prestado por alguno de los bancos, cajas de ahorros, cooperativas de crédito, establecimientos financieros de crédito operar en España. El importe de la y sociedades de garantía recíproca autorizados para fianza se destinará al resarcimiento de los daños y perjuicios que por cualquier causa pudieran incurrir en la ejecución del contrato o durante el período de vigencia de la garantía fijada. Cuando a consecuencia de la modificación del contrato, este experimente alguna variación en el valor total, si ambas partes deciden seguir adelante con él, se ajustará la fianza constituida en la cuantía necesaria para que se mantenga la debida proporcionalidad entre la fianza y el presupuesto del contrato. Dentro del plazo de seis meses a partir de la finalización de la instalación, se procederá a la devolución del importe de la fianza, en cancelación del aval ejecutable. 47 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.6.20 GARANTÍAS Y PLAZOS DE GARANTÍA Tanto los componentes de la instalación, como su montaje y funcionabilidad, quedarán garantizados por el tiempo indicado por la legislación vigente, a partir de la recepción provisional y, en ningún caso, esta garantía cesará hasta que sea realizada la recepción definitiva. Se dejará a criterio de la dirección de obra determinar ante un defecto de maquinaria su posibilidad de reparación o el cambio total de la unidad. Este concepto aplica a todos los componentes y materiales de las instalaciones, sean éstos los especificados, de modo concreto, en los documentos de proyecto o los similares aceptados. El software y sus respectivas aplicaciones asociadas pose un plazo de garantía total de 12 meses, a partir de la fecha de finalización de montaje y puesta en marcha de la misma. Esta garantía incluye la posible sustitución de materiales y el servicio técnico, además de los desplazamientos. No se aplica para el régimen de alquiler para vuelos esporádicos. El plazo de garantía se extiende a 24 meses para el servicio técnico, la garantía quedará totalmente anulada en el caso de que el aparato sufra daños por la manipulación inadecuada por parte del cliente o haya sido manipulado por personas ajenas a nuestros Servicios Técnicos Oficiales. Para el primer caso se incluye en el Manual de Instrucciones una guía de precauciones de uso. No están incluidas las reparaciones concernientes a averías debidas a causas accidentales: incendios, inundaciones, rayos, etc., siempre que se demuestre que su origen es independiente del normal funcionamiento del panel medioambiental; tampoco estarán incluidas aquellas averías ocasionadas por actos vandálicos. En estos u otros supuestos de avería, el contratista estará obligado a suministrar a la parte contratante, antes de quince días, un presupuesto de reparación de averías. De encontrarse elementos defectuosos en el momento de la entrega, estos serán sustituidos sin coste alguno para el usuario en un plazo inferior a 48 horas por 48 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado parte del servicio técnico, para el caso de pedidos nacionales y en un tiempo inferior a una semana en el caso de pedidos internacionales. 5.7 CALIDAD Cualquier elemento, Drone, tarjetas, sensores, material y, en general, cualquier concepto en el que pueda ser definible una calidad, ésta será la indicada en el proyecto, bien determinada por una marca comercial o por una especificación concreta. Si no estuviese definida una calidad, la dirección de obra podrá elegir la que corresponda en el mercado a niveles considerados similares a los del resto de los materiales especificados en proyecto. En este caso, el instalador queda obligado, por este pliego de condiciones técnicas, a aceptar el material que le indique la Dirección de Obra. Si el instalador propusiese una calidad similar a la especificada en proyecto, corresponde exclusivamente a la dirección de obra definir si ésta es o no similar. Por tanto, toda marca o calidad que no sea la específicamente indicada en el documento de medición y presupuesto o en cualquier otro documento del proyecto deberá haber sido aprobada por escrito por la dirección de obra previamente a su instalación, pudiendo ser rechazada, por tanto, sin perjuicio de ningún tipo para la propiedad, si no fuese cumplido este requisito. Todos los materiales y equipos deberán ser productos normalizados de catálogo de fabricantes dedicados con regularidad a la fabricación de tales materiales o equipos y deberán ser de primera calidad y del más reciente diseño del fabricante que cumpla con los requisitos de estas especificaciones y la normativa vigente. Salvo indicación expresa escrita en contrario por la dirección de obra, no se aceptará ningún material y/o equipo cuya fecha de fabricación sea anterior, en 9 meses o más, a la fecha de contrato del instalador. Todos los componentes principales de equipos deberán llevar el nombre, la dirección del fabricante y el modelo y número de serie en una placa fijada con 49 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado seguridad en un sitio visible. No se aceptará la placa del agente distribuidor. En aquellos equipos en los que se requiera placa o timbre autorizados y/o colocados por la delegación de industria o cualquier otro organismo oficial, será competencia exclusiva del instalador procurar la correspondiente placa y abonar cualquier derecho o tasa exigible al respecto. Durante los servicios, el instalador queda obligado a presentar a la dirección de obra cuantos materiales o muestras de los mismos le sean solicitados. En el caso de materiales voluminosos, se admitirán catálogos que reflejen perfectamente las características, terminado y composición de los materiales de que se trate. 5.7.1 NORMAS DE CALIDAD Los sistemas se diseñarán de forma que cumplan las normas UNE, CEI y EN aplicables a este tipo de productos, así como las normas ETSI (European Telecommunications Standards Institute) para sistemas de radiofrecuencia. Normas de seguridad e higiene. El proyecto cumplirá con la Ley 31/95 de Prevención de Riesgos Laborales. Vida útil del producto Los sistemas se diseñarán para una vida útil no inferior a 2 años en funcionamiento continuo. Equipo Informático El equipo informático debe estar homologado conforme a la normativa Europea y Española a fecha de Junio de 2009. El equipo informático debe instalarse conforme a las indicaciones del fabricante, manteniendo las condiciones de humedad y temperatura entre los límites marcados. Los programas informáticos empleados han de contar con la licencia preceptiva y cumplir con las condiciones de la misma. En caso de usar programas de licencia GNU, se deberán respetar las condiciones de la misma. La mayor parte del software de este proyecto se presenta bajo GNU – GPL. 50 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Elementos electrónicos os sistemas electrónicos habrán de conectarse y manejarse conforme a las especificaciones del administrador. Además, se emplearán componentes normalizados para los circuitos electrónicos. Sistema de radiofrecuencia. El sistema de radio frecuencia cumplirá con los requisitos establecidos en la normativa Europea (R&TTE Directive 1999-5-EC). El sistema de radiofrecuencia se atendrá a la normativa vigente de protección del espacio radioeléctrico y protección de la salud: LEY GENERAL DE TELECOMUNICACIONES 11/1998, DE 24 DE ABRIL DE 1998. Aplicable 3DR. Xbee, señales wifi, etc. 5.8 CONCEPTOS COMPRENDIDOS Es competencia exclusiva del Instalador y, por lo tanto, queda totalmente incluido en el precio ofertado, el suministro de todos los elementos y materiales, mano de obra, medios auxiliares y, en general, todos aquellos elementos y/o conceptos que sean necesarios para el perfecto acabado y puesta a punto del Proyecto de Mediciones Ambientales mediante UAD instalaciones, según se describen en la memoria, son representadas en los planos, quedan relacionadas de forma básica en el presupuesto y cuya calidad y características de montaje se indican en el Pliego de Condiciones Técnicas. Queda entendido que los ocho Documentos de Proyecto, es decir, Memoria, Mediciones y Presupuesto, Planos y Pliego de Condiciones Técnicas etc forman todo un conjunto. Si fuese advertida o existiese alguna discrepancia entre estos cuatro documentos, su interpretación será la que determine la Dirección de Obra, en el día del montaje por su Director de Proyecto, el creador del software y documentación. Salvo indicación contraria en su oferta, lo que debe quedar explícitamente indicado en contrato, queda entendido que el instalador acepta este criterio y no 51 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado podrá formular reclamación alguna por motivo de omisiones y/o discrepancias entre cualquiera de los cuatro documentos que integran el proyecto Cualquier exclusión, incluida implícita o explícitamente por el instalador en su oferta y que difiera de los conceptos expuestos en los párrafos anteriores, no tendrá ninguna validez, salvo que en el contrato, de una forma particular y explícita, se manifieste la correspondiente exclusión. Es responsabilidad del Instalador el cumplimiento de toda la normativa oficial vigente aplicable al proyecto. Durante la realización de este proyecto se ha puesto el máximo empeño en cumplir toda la normativa oficial vigente al respecto. No obstante, si en el mismo existiesen conceptos que se desviasen o no cumpliesen con las mismas, es obligación del instalador comunicarlo en su oferta y en la forma que se describirá más adelante. Queda, por tanto, obligado el instalador a efectuar una revisión del proyecto, previo a la presentación de su oferta, debiendo indicar, expresamente, en la misma, cualquier deficiencia a este respecto o, en caso contrario, su conformidad con el proyecto en materia de cumplimiento de toda la normativa oficial vigente aplicable al mismo. El instalador efectuará a su cargo el plan de seguridad y el seguimiento correspondiente a sus trabajos, debiendo disponer de todos los elementos de seguridad, auxiliares y de control exigidos por la legislación vigente, todo ello con la debida coordinación en relación al resto de los servicios, por lo que será preceptiva la compatibilidad y aceptación de este trabajo con el plan de seguridad general de los servicios y, en cualquier caso, deberá contar con la conformidad de la Dirección Técnica y el contratista general. Quedan incluidos también, como parte de los trabajos del instalador, la preparación de todos los planos de las placas de Arduino, así como la gestión y preparación de toda la documentación técnica necesaria, incluido visado y legalizado de proyectos y certificados de obra, así como su tramitación ante los diferentes organismos oficiales, al objeto de obtener todos los permisos requeridos de acuerdo a la legislación. 52 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado También quedan incluidas la realización de todas las pruebas de puesta en marcha de las instalaciones básicas de sensores, realizadas según las indicaciones de la dirección de obra. No se procederá a efectuar la recepción provisional si todo lo anterior no estuviese debidamente cumplimentado a satisfacción de la dirección de obra. Asimismo, quedan incluidos todos los trabajos correspondientes a la definición, coordinación e instalación de todas las acometidas de servicios, tales como sensores, rotores, palas, arduinos, y otros que pudieran requerirse, ya sean de forma provisional para efectuar los montajes en obra o de forma definitiva para satisfacer las necesidades del proyecto. Se entiende, por tanto, que estos trabajos quedan plenamente incluidos en la oferta del instalador, salvo que se indique expresamente lo contrario. Queda, por tanto, el Instalador enterado por este pliego de condiciones que es responsabilidad suya la realización de las comprobaciones indicadas, previo a la presentación de la oferta, así como la presentación en tiempo, modo y forma de toda la documentación mencionada y la consecución de los correspondientes permisos. El instalador, en caso de subcontratación, o la empresa responsable de su contratación, no podrán formular reclamación alguna con respecto a este concepto, ya sea por omisión, desconocimiento o cualquier otra causa. 5.8.1 CONCEPTOS NO COMPRENDIDOS En general, solamente quedan excluidos de realización por parte del instalador los conceptos que responden a actividades de albañilería, salvo que en los documentos de proyecto se indicase expresamente lo contrario. Los conceptos excluidos son los que se indican a continuación. 53 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.8.2 INTERPRETACIÓN DEL PROYECTO La interpretación del proyecto corresponde en primer lugar al ingeniero autor del mismo o, en su defecto, a la persona que ostente la Dirección de Obra. Se entiende el proyecto en su ámbito total de todos los documentos que lo integran, es decir, memoria, planos, mediciones y presupuesto y pliego de condiciones técnicas quedando, por tanto, el instalador enterado por este pliego de condiciones técnicas que cualquier interpretación del proyecto para cualquier fin y, entre otros, para una aplicación de contrato, debe atenerse a las dos figuras (Autor o Director), indicadas anteriormente. Cualquier delegación del autor o director del proyecto, a efectos de una interpretación del mismo, debe realizarse por escrito y así solicitarse por la persona o entidad interesada. 5.8.3 COORDINACIÓN DEL PROYECTO Será responsabilidad exclusiva del instalador la coordinación de las instalaciones de su competencia. El instalador pondrá todos los medios técnicos y humanos necesarios para que esta coordinación tenga la adecuada efectividad consecuente, tanto con la empresa constructora, como con los diferentes oficios o instaladores de otras especialidades que concurran en los montajes de placas en el Drone. Por tanto, cada instalador queda obligado a coordinar las instalaciones de su competencia con las de los otros oficios. Por coordinación de las instalaciones se entiende su representación en planos de obra, realizados por el instalador a partir de los planos de proyecto adaptados a las condiciones reales de obra y su posterior montaje, de forma ordenada, de acuerdo a estos planos y demás documentos de proyecto. En aquellos puntos concurrentes entre dos oficios o instaladores y que, por lo tanto, pueda ser conflictiva la delimitación de la frontera de los trabajos y responsabilidades correspondientes a cada uno, el instalador se atendrá a lo que figure indicado en proyecto o, en su defecto, a lo que dictamine sobre el particularmente la Dirección de Obra. Queda, por tanto, enterado el instalador que no podrá efectuar o aplicar sus criterios particulares al respecto. 54 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.8.4 MODIFICACIONES AL PROYECTO Sólo podrán ser admitidas modificaciones a lo indicado en los documentos de proyecto por alguna de las causas que se indican a continuación. Mejoras en la calidad, cantidad o características del montaje de los diferentes componentes de la instalación, siempre y cuando no quede afectado el presupuesto o, en todo caso, sea disminuido, no repercutiendo, en ningún caso, este cambio con compensación de otros materiales. En este caso, la variación de instalaciones se sensores en placas, marcha puesta en vuelo será exclusivamente la que defina la dirección de obra o, en su caso, el instalador con aprobación de aquélla. Cualquier modificación al proyecto, ya sea en concepto de interpretación del proyecto, cumplimiento de normativa o por ajuste de obra, deberá atenerse a lo indicado en los apartados correspondientes del pliego de condiciones técnicas y, en cualquier caso, deberá contar con el consentimiento expreso y por escrito del autor del proyecto y/o de la Dirección de Obra. Toda modificación que no cumpla cualquiera de estos requisitos carecerá de validez. 5.8.5 REGLAMENTACIÓN DE OBLIGADO CUMPLIMIENTO Con total independencia de las prescripciones indicadas en los documentos del proyecto, es prioritario para el instalador el cumplimiento de cualquier reglamentación de obligado cumplimiento que afecte, directa o indirectamente, a su instalación, bien sea de índole nacional, autonómico, municipal, de compañías o, en general, de cualquier ente que pueda afectar a la puesta en marcha legal y necesaria para la consecución de las funciones previstas en el vuelo del Drone. El concepto de cumplimiento de normativa se refiere no sólo al cumplimiento de toda normativa del propio equipo o instalación, sino también al cumplimiento de cualquier normativa exigible durante el montaje, funcionamiento y/o rendimiento del equipo y/o sistema. Es, por tanto, competencia, obligación y responsabilidad del instalador la previa revisión del proyecto antes de la presentación de su oferta y, una vez 55 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado adjudicado el contrato, antes de que realice ningún pedido, ni que ejecute ningún montaje. Esta segunda revisión del proyecto, a efectos de cumplimiento de normativa, se requiere tanto por si hubiera habido una modificación en la normativa aplicable después de la presentación de la oferta, como si, con motivo de alguna modificación relevante sobre el proyecto original, ésta pudiera contravenir cualquier normativa aplicable. Si esto ocurriera, queda obligado el instalador a exponerlo ante la dirección técnica y la propiedad. Esta comunicación deberá ser realizada por escrito y entregada en mano a la dirección técnica de obra. 5.8.6 DOCUMENTACIÓN GRÁFICA A partir de los planos del proyecto es competencia exclusiva del instalador preparar todos los planos de Arduino, incluyendo tanto los planos de coordinación, como los planos de montaje necesarios, mostrando en detalle las características de construcción precisas para el correcto montaje de los equipos 5.8.7 DOCUMENTACIÓN FINAL DE OBRA Previo a la recepción provisional de las instalaciones, cada instalador queda obligado a presentar toda la documentación de proyecto, ya sea de tipo legal y/o contractual, según los documentos de proyecto y conforme a lo indicado en este pliego de condiciones. Como parte de esta documentación, se incluye toda la documentación y certificados de tipo legal, requeridos por los distintos organismos oficiales y compañías suministradoras. En particular, esta documentación se refiere a lo siguiente: Certificados de cada instalación, presentados ante la Delegación del Ministerio de Industria y Energía. Incluye autorizaciones de suministro, boletines, etc Ídem ante Compañías Suministradoras. Protocolos de pruebas completos de las instalaciones (original y copia). Manual de instrucciones (original y copia), incluyendo fotocopias de catálogo con instrucciones técnicas de funcionamiento, mantenimiento y conservación de 56 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado todos los equipos de la instalación. propuesta de stock mínimo de recambios. Libro oficial de mantenimiento Legalizado. Proyecto actualizado (original y copia), incluyendo planos as-built de las instalaciones. 57 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9 PLIEGO DE CONDICIONES PARA ESTANDARES DEL SOFTWARE 5.9.1 PLAN DE ASEGURAMIENTO DE LA CALIDAD IEEE STD 730-2002 La calidad se puede definir como “el conjunto de las propiedades de un producto, procesos o servicio que le confieren aptitud para satisfacer las necesidades declaradas o implícitas del cliente”. Quién será responsable de la calidad, que documentación se requiere, que técnica se usará para asegurar la calidad, qué procedimientos se seguirán para administrar el proyecto, pruebas, informe de problemas y acción correctiva, herramientas técnicas y metodologías, control de proveedores, capacitación, gestión de riesgos. Se dirige hacia el desarrollo y mantenimiento de software. A menudo los desarrolladores no se basan tanto en los deseos del mercado, como en lo que el ingeniero considera técnicamente fabricable u óptimo, según los criterios de calidad. El cumplir las exigencias que el cliente impone al producto en lo relativo a su funcionamiento, solidez, estabilidad, diseño, etc., es decir, su idea de la calidad, es más valorado en la compra que el aspecto económico. Así lo prueban varios estudios sobre la estrategia del mercado, realizados a principios de los 80. 5.9.1.1 LA CALIDAD EN INGENIERÍA DEL SOFTWARE Lo primero que se debe considerar a la hora de abordar el tema de la calidad del software es que éste constituye un producto con unas características muy específicas. Se desarrolla, no se fabrica en el sentido clásico del término. Todo el coste de su producción se centra en el diseño de la primera copia, ya que la replicación de un programa es una tarea trivial. Se trata de un producto lógico, sin existencia física. El verdadero producto del software es el diseño de una serie de instrucciones para el computador. Su 58 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado existencia en papel (listado) o en soporte magnético (fichero) no es más que una representación en un código o en lenguaje de su auténtica naturaleza, las instrucciones. De hecho, está protegido por leyes de propiedad intelectual al igual que la música o las servicios escritas. No se degrada con el uso. La naturaleza lógica del software permite que permanezca inalterable por muy intensa que sea su utilización. Se puede degradar su representación magnética pero no su esencia. La complejidad del software, la ausencia de controles adecuados y el mercado actual lleva a que sea un producto que muchas veces se entrega conscientemente con defectos, incluso públicamente declarados. Un porcentaje muy grande de la producción se hace aún a medida, en vez de emplear componentes existentes y ensamblarlos, aunque las bibliotecas de funciones o componentes están ya cambiando en parte esta situación. Es muy flexible. Se puede cambiar con facilidad e incluso, se pueden reutilizar trozos de un producto para construir otro. Sin embargo la facilidad para cambiarlo, aunque es un peligro, que hay que controlarlo. 5.9.1.2 DEFINICIÓN DE LA CALIDAD DEL SOFTWARE Según el estándar IEEE std.610-1991 [IEE, 1991a] indica que calidad es el grado con el que un sistema, componente o proceso cumple: a) Los requisitos especificados. b) Las necesidades o expectativas del cliente o usuario. Hay que recordar que: a) Los requisitos establecidos SRS pueden ser: o Requisitos funcionales, que determinan funciones a realizar por el software o Requisitos de otros tipos: De rendimiento, de seguridad, de interfaz, etc. b) Los estándares y las normas de desarrollo determinan como se debe realizar el proceso de desarrollo de software. Su seguimiento permite que se 59 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado consiga una calidad técnica en el software producido, que influye en la calidad de cara al usuario, es decir, conformidad con requisitos. c) Existen requisitos explícitos, no expresamente declarados, es decir, en la SRS o en un contrato; pero que el usuario del software desea obtener. 5.9.1.3 EL MODELO SPICE El proyecto SPICE (Software Process Improvement and Capability Determination: Determinación del mejoramiento y capacidad del proceso de software), representa el mayor marco de colaboración internacional establecido con la finalidad de desarrollar un estándar de evaluación de procesos de software. Se inició con tres objetivos claves: - Desarrollar un marco de trabajo común para la evaluación y mejora de procesos de software. - Aplicar el estándar desarrollado en la industria del software. - Promover la transferencia de conocimiento y de tecnología sobre procesos de software entre todas las empresas. Proporciona un marco conceptual de valoración que cumple con ISO/IEC 15504: 2003 e ISO/IEC 12207. ISO/IEC 15504, es un estándar internacional que es aplicable a cualquier organización/empresa que quiere conocer y mejorar la capacidad de sus procesos, independientemente del tipo de organización, del modelo del ciclo de El estándar completo vigente hoy en día se denomina ISO/IEC 15504, Information Technology-Process Assessment: Evaluación de Procesos de la tecnología de la información. vida adoptado, de la metodología de desarrollo y de la tecnología utilizada. 1.ISO/IEC 15504-1:2004. Conceptos y vocabulario. Representa una introducción de la norma, proporciona un guía de uso de la misma. Se incluyen términos definidos específicamente para la norma. 60 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 2.ISO/IEC 15504-2:2003/Cor 1:2004.Desarrollo de la evaluación. Define los requisitos que debe cumplir una evaluación para que produzca resultados repetibles, fiables y consistentes. 3.ISO/IEC 15504-3:2004. Orientación sobre cómo realizar una evaluación. Proporciona una guía para poder utilizar los resultados de una evaluación en la mejora de los procesos evaluados. 4.ISO/IEC 15504-5. Ejemplar del proceso de evaluación del modelo. Proporciona un modelo totalmente compatible con la parte normativa, incluye un conjunto de indicadores que facilitan el cálculo de la capacidad de los procesos. De ISO/IEC 12207 se obtienen todos los procesos que una organización puede realizar para comprar, suministrar, desarrollar, operar, mantener y dar soportar software. La dimensión de la capacidad, formada por seis niveles de capacidad y nueve atributos de procesos, proporciona una base para medir la capacidad de dichos procesos, en función del grado de cumplimiento de sus atributos. 5.9.1.4 DESCRIPCIÓN DE LOS REQUISITOS DEL SOFTWARE (SRD) El SRD debe especificar los requisitos para un determinado producto de software, proyecto o conjunto de proyectos que realizan ciertas funciones en un entorno específico. Por tanto el SRD es un documento fundamental y es el punto de partida del desarrollo de cualquier sistema software, debe cubrir todos los objetivos en el análisis de requisitos del software preferiblemente se recomienda el uso del estándar IEEE 830-1998 ya analizado. 5.9.1.5 DOCUMENTACIÓN DEL USUARIO La documentación de usuario debe describir el control de entradas de datos, secuencias de entrada, opciones, las limitaciones del programa, y cualquier otra información esencial para el producto de software. La documentación de usuario forma parte de las especificaciones de requisitos. IEEE 828-2005 61 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.1.6 PLAN DE GESTIÓN DE CONFIGURACIÓN DEL SOFTWARE (SCMP) El SCMP debe documentar, las actividades y formas que deben llevarse a cabo, quién es el responsable de distintas tareas, calendario de eventos, y qué recursos se utilizarán. 5.9.1.7 VERSIONES DEL SOFTWARE Conforme un proyecto evoluciona lo hacen al mismo tiempo los elementos de software. Una versión de un elemento del software es un elemento identificado, debe definirse una forma no ambigua de identificar cada versión de los componentes para asegurar que se incluyan los componentes adecuados, no se puede usar el nombre del elemento de la configuración para identificar las versiones debido a que hay diferentes versiones para cada elemento de la configuración, existen tres técnicas básicas utilizadas para la identificación de los componentes. 5.9.1.8 BIBLIOTECA DE SOFTWARE La biblioteca de software es una colección donde se almacena el software para ofrecer un adecuado manejo de código de software, documentación, medios de comunicación, manejo de versiones, datos relacionados en diversas formas, múltiples desarrolladores y está diseñada para ayudar en el desarrollo del software uso y mantenimiento. Para cada biblioteca se deberá determinar el formato, los requisitos de documentación, requisitos de recepción e inspección, procedimientos de control de acceso, localización, etc. 5.9.1.9 CONTROL DE LA CONFIGURACIÓN DEL SOFTWARE El control de configuración del software le corresponde durante el ciclo de vida del software a la gestión de cambios, el control de cambios es vital, son de gran importancia los cambios porque una pequeña transformación en el código puede crear un gran fallo en el producto, el cambio incontrolado conduce al caos, esta actividad es primordial y su principal objetivo es realizar un mecanismo para el 62 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado control de cambios, combina procedimientos humanos y herramientas automatizadas. Tareas específicas en el plan de gestión de configuración - Identificación y documentación de la necesidad del cambio. - Análisis y evaluación de la petición de cambio. - Aprobación o desaprobación de la petición. - Verificación, implementación y liberación del cambio. 5.9.2 ESPECIFICACIÓN DE LOS REQUISITOS SOFTWARE IEEE 830 – 1998 Se concretan las necesidades que se desean cubrir y se fijan las restricciones con las que debe trabajar el software a desarrollar. El análisis se realiza dentro de la primera fase (fase de definición) del ciclo de vida y tiene una importancia decisiva para conseguir que el sistema que se construya finalmente sea realmente el que se deseaba. En este apartado se hace una descripción de lo que va a contener el documento. Para ello definiremos la importancia de los requisitos: “Una condición o necesidad del usuario para resolver un problema o alcanzar un objetivo”.(Std 610.12-1900,IEEE62). “Condición o capacidad que debe estar presente en un sistema o componente del sistema para satisfacer un contrato, estándar, especificación u otro documento formal” (Std 610.12-1900,IEEE62). 5.9.2.1 CABE DESTACAR: El contrato: Es un documento legal obligatorio en el cual están implicados el cliente y proveedor. Se incluyen los requisitos técnicos, requisitos de la organización, costo y tiempo para un producto. Un contrato también puede contener 63 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado la información informal pero útil como los compromisos o expectativas de las partes involucradas. Cliente y Proveedor: Establecer las bases para un acuerdo entre los clientes y los proveedores en lo que se refiere al producto del software en que se va realizar, descripción completa de las funcionalidades para una buena especificación de requisitos del software, esto es muy importante ya que ayudará a los usuarios potenciales a satisfacer sus necesidades, y esto conlleva modificaciones que pueden reducir el esfuerzo del desarrollo y revisiones de los requisitos ya que puede revelar omisiones, malentendidos y contradicciones a principios del ciclo de desarrollo cuando los problemas son más fáciles de corregir. 5.9.2.2 REFERENCIAS a) Especificar las fuentes de las cuales pueden obtenerse los documentos referenciados. b) Especificar las fuentes de las referencias obtenidas. Esta información puede ofrecerse haciendo alusión a un apéndice o hacia otro documento. c) Identificar cada documento por título, número de informe, fecha y editorial. Como parte de documentación utilizada mencionamos la siguiente documentación: - Descripción del diseño del software (DDS). - Plan de aseguramiento de la calidad del software (PAQS). - Plan de documentación del usuario de software (PDUS). - Documentación de pruebas de software. - IEEE 1233- 1998 Guía para el desarrollo de especificaciones. Establecer una gestión y entornos de ingeniería basados en los requisitos de calidad de ISO / IEC 12119: 1994 (E). 64 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.2.3 ELABORACIÓN DE LOS PERFILES DE USUARIO No se puede diseñar correctamente una interfaz de usuario sin saber para quién se hace, ya que un diseño apropiado para un usuario (en sentido colectivo) no puede ser para otro. Hay que evitar en especial el error de que los desarrolladores del software diseñen la interfaz de usuario como si los usuarios fueran ellos mismos, ya que tienen una cultura profesional y unos conocimientos de informática muy diferentes a los de la gran mayoría de los usuarios. 1. Experiencia en torno hardware y software (ratón, teclado, ventanas etc.). 2. Experiencia en el trabajo. 3. Frecuencia de uso del software y grado de rotación del personal 5.9.2.4 FIABILIDAD Especificar los factores requeridos para establecer la fiabilidad requerida del sistema del software al momento de la entrega. Definición. La norma ISO / IEC 9126: 2004 define la "fiabilidad" como: "Un conjunto de atributos que influyen en la capacidad de software para mantener su nivel de desempeño bajo las condiciones establecidas para un período determinado de tiempo. " 5.9.2.5 USABILIDAD Definición. La norma ISO / IEC 9126:2004 define la "usabilidad" como: "Un conjunto de atributos que influyen en el esfuerzo necesario para su uso, y en la evaluación individual de tal uso, implícita por un conjunto de usuarios. Se proponen, además, las definiciones de sub-características: comprensibilidad, facilidad de aprendizaje y operatividad. 65 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.2.6 SEGURIDAD Especificar los factores que protegen el software del acceso accidental o malévolo, uso, modificación, destrucción o revelación. La integridad de los datos recogidos debe ser protegida. 5.9.2.7 MANTENIMIENTO La norma ISO / IEC 9126: 2004 define el "mantenimiento", como "un conjunto de atributos que influyen en el esfuerzo necesario para realizar las modificaciones especificadas." Se propone, además, las definiciones de sub-características: análisis, variabilidad, estabilidad y la capacidad de prueba. Para una entidad adquiriente, el mantenimiento es especialmente importante cuando un objetivo es adquirir el producto completo, incluyendo trazas del proceso de desarrollo de software, con el fin de ser capaz de mantener el software después de su entrega 5.9.2.8 PORTABILIDAD Especificar atributos de software que relacionan la facilidad de portar el software a otra computadora (servidor) y/o sistemas operativos. Definición. La norma ISO / IEC 9126:2004 define "portabilidad" como: "Un conjunto de atributos que influyen en la capacidad del software para ser transferido de un entorno a otro." Las definiciones de sub-características: capacidad de adaptación, facilidad de instalación, la conformidad y reemplazo. 5.9.3 DESCRIPCIONES DEL DISEÑO DE SOFTWARE IEEE STD 1016 – 2009 En el diseño se inicia en el estudio de las etapas de desarrollo. Después de haber especificado QUÉ se quiere resolver durante la especificación, las etapas de desarrollo se dedican a determinar CÓMO se debe resolver el proyecto. 66 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.3.1 ÁMBITO DE APLICACIÓN Esta norma describe los diseños de software y establece el contenido de la información y la organización de una descripción del diseño de software (SDD). El SDD es una representación de un diseño de software que se utilizará para el registro de información sobre el diseño y la comunicación de la información de diseño a las partes interesadas claves en el diseño. 5.9.3.2 PROPÓSITO Esta norma específica los requisitos sobre el contenido de la información y la organización de las SDD. La norma específica los requisitos para la selección de lenguajes de diseño que se utilizarán para SDD, y los requisitos para la documentación de puntos de vista de diseño que se utilizarán en la organización de un SDD. 5.9.4 FUNDAMENTOS DE LAS PRUEBAS. ADAPTADO DEL ESTÁNDAR IEEE 729 El propósito del software basado en pruebas de sistemas es ayudar a la organización de desarrollo de la calidad a la construcción del software y al sistema durante los procesos del ciclo de vida y para comprobar que la calidad se ha logrado. 5.9.4.1 INTRODUCCIÓN Se ha tomado de referencia el estándar IEEE 729-2008, el propósito de esta norma está basado en pruebas del software, ayuda a la organización de desarrollo de la calidad a la construcción del software y al sistema durante los procesos del ciclo de vida y a comprobar que la calidad se ha logrado. La prueba del software determina si los productos de una actividad del ciclo de vida cumplen con las expectativas de los requisitos y además el producto cumple con el uso previsto y las necesidades del usuario. Para ello he suscitado algunos aspectos de mayor 67 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado importancia con respecto a esta norma adecuándolos al estudio del siguiente esquema: Ilustración 171 división de los temas para el KA de las Pruebas de Software Se ha decidido optar por este esquema para su estudio porque me aporta mayor claridad, está orientado a la confiabilidad del software y por ende las pruebas del software es uno de los procesos fundamentales dentro del control de la calidad de software. La complejidad del software causa que los procesos de prueba jueguen un papel primordial para aumentar la calidad del producto final, a lo largo de este capítulo se describen aspectos que están relacionados con la prueba del software. La fase de las pruebas del software es un elemento crítico para la garantía de la calidad del software y representa revisiones de las especificaciones, del diseño y de la codificación. La importancia de las pruebas del software supone un 40% del coste total de desarrollo. 68 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.4.2 PRUEBAS DE ACEPTACIÓN Implican la planeación y ejecución de pruebas funcionales, de desempeño y de tensión para demostrar que el sistema implantado satisface sus requisitos. A menudo, se hacen correr en el programa dos conjuntos de prueba de aceptación: 1. Aquellas pruebas desarrolladas por el grupo de control de calidad. 2. Y las que desarrolla el cliente 5.9.4.3 ERRORES VS FALLOS Se define formalmente un error como la discrepancia entre un valor o condición calculado, observado o medido y el valor o condición específica o teóricamente correcta. Se define formalmente un fallo: que comete el desarrollador. Se define un defecto como la desviación de estándares, y finalmente, fallo es la consecuencia de un defecto. Por lo tanto estos dos términos tienden a la confusión y se utiliza uno de ellos de forma genérica. 5.9.4.4 CRITERIOS PARA DAR POR FINALIZADAS LAS PRUEBAS Partiendo de la base, estadísticamente no hay ningún software entregado y dado por finalizado que esté libre de errores, sí es necesario que exista un alto porcentaje de confianza en el sistema desarrollado. Estadísticamente se acepta un 95% como porcentaje válido. En cualquier caso, un buen diseño de caso de prueba ayuda a elevar el grado de confianza escogiendo aquellos casos de prueba que tengan más probabilidades de tener errores y cubran el espectro de pruebas de la forma más amplia posible. 5.9.4.5 REALIZAR PRUEBAS PARA LA IDENTIFICACIÓN DE DEFECTOS Una de las consideraciones más importantes en la aplicación del sistema de prueba es determinar quién debe hacerlo. Para responder a esto de una manera negativa, los programadores no deben realizar una prueba del sistema, y todas las 69 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado fases de prueba, en que la organización responsable del desarrollo de los programas definitivamente no debe realizarse. El primer punto se deriva del hecho de que una persona que realiza una prueba del sistema debe ser capaz de pensar como un usuario final, lo que implica un conocimiento profundo de las actitudes del usuario final y de cómo el programa se utilizará. Obviamente, si es posible, un candidato a prueba es uno o más usuarios finales. Sin embargo, debido a que el usuario final típico no tiene la capacidad ni la experiencia para realizar muchas de las categorías de las pruebas descritas anteriormente, un equipo de sistema de prueba ideal podría estar compuesto por unos pocos expertos profesionales del sistema de prueba (las personas que pasan su vida en la realización de pruebas del sistema). El segundo punto se deriva del hecho de que una prueba del sistema es un "todo vale, no todo vale" de actividad. Una vez más, la organización de desarrollo tiene vínculos psicológicos con el programa que van en contra de este tipo de actividad. 5.9.4.5.1 Pruebas vs depuración Las pruebas tienen sus intentos de provocar fallos con el fin de detectar fallos, mientras que la depuración implica tanto el análisis de fallos para localizar e identificar las fallas asociadas y corrección de fallos posteriores. Las pruebas pueden necesitar los resultados de análisis de fallos de depuración para decidir sobre un curso de acción. Estas acciones pueden incluir la terminación de la prueba o una solicitud de cambios en los requerimientos o corrección de fallo. 5.9.4.5.2 Pruebas y certificación El enfoque de certificación involucra los siguientes aspectos: 1. Creación de escenarios de uso. 2. Especifica un perfil de uso. 70 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3. Generación de casos de uso a partir del perfil 4. Las pruebas se ejecutan y los datos de fallo se registran y analizan Se calcula la confiabilidad y se certifica 5.9.4.6 CONCLUSIONES Se destacan los siguientes puntos: - El objetivo de las pruebas del software es detectar el mayor número posible de errores. Para lograrlo existen diferentes técnicas de pruebas: procedimientos técnicos o de gestión que ayudan en la ejecución, evaluación y mejora de los procesos de desarrollo software - Técnicas de caja blanca denominadas pruebas estructurales, utilizan el código fuente del programa y especialmente su estructura de control para seleccionar casos de prueba. Técnicas de caja negra o funcional, obtienen casos a partir de los requisitos funcionales del programa a probar, por lo que no se tiene en cuenta la forma en que se codifica esa funcionalidad, sino que se consideran únicamente las entradas y las salidas. 5.9.4.7 PRUEBAS DE SISTEMA La prueba del sistema es el proceso de prueba de un sistema integrado en su entorno hardware y software para verificar que cumple con los requisitos especificados, es decir: - Cumplimiento de todos los requisitos funcionales, considerado el producto software final al completo, en un entorno del sistema. - Funcionamiento y rendimiento en las interfaces hardware, software, usuario, operador. - Acondicionamiento de la documentación de usuario. - Ejecución y rendimiento en condiciones límite y de sobrecarga En ocasiones se realiza antes que las pruebas de validación. 71 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Entre otras pruebas consta de: - Pruebas de interfaces externas (hardware, software, usuario). - Prueba de volumen. - Pruebas de funcionamiento (funciones que desempeña) - Pruebas de recuperación. - Pruebas de seguridad. - Pruebas de resistencia (condiciones de sobrecarga o límite). - Prueba de rendimiento / pruebas de comportamiento (condiciones normales). - Pruebas de fiabilidad. - Pruebas de documentación. Las pruebas del sistema presentan tres fuentes principales para su diseño: - Basado en los requisitos gracias a la técnica de caja negra aplicada a las especificaciones. - Casos para probar el rendimiento del sistema y su capacidad funcional. - Casos basados en el diseño de alto nivel, gracias a la técnica de caja blanca, aplicada a flujos de datos de alto nivel. 5.9.4.8 PRUEBAS DE INSTALACIÓN Las pruebas de instalación deben ser desarrolladas por la organización que produjo el sistema, entregadas como parte del sistema, y ejecutar después de que el sistema está instalado. Entre otras cosas, los casos de prueba pueden comprobar que un conjunto compatible de opciones ha sido seleccionado, que todas las partes del sistema existen, que todos los archivos han sido creados y tienen los contenidos necesarios, y que la configuración de hardware es la adecuada. La prueba de instalación consiste en probar la aplicación en su configuración de hardware final. Esto implica instalar la aplicación en su entorno operativo real, 72 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado después de ejecutar el conjunto de pruebas del sistema. Para las aplicaciones comprimidas, las pruebas de instalación consisten en ejecutar la aplicación en plataformas que tipificarían los entornos de los clientes. Acontecimientos que se producen en la instalación de sistemas de software. Una breve lista de ejemplos incluye lo siguiente: - El usuario debe seleccionar una variedad de opciones. - Los archivos y las bibliotecas deben ser asignados y cargados. - Las configuraciones de hardware válidas deben estar presentes. - Los programas pueden necesitar una conectividad de red para conectarse a otros programas. 5.9.4.9 PRUEBAS ALFA Y BETA Para comprobar que un producto software es realmente útil para sus usuarios es conveniente que estos últimos intervengan también en las pruebas finales del sistema. De esta manera se pueden poner de manifiesto nuevas deficiencias no caracterizadas hasta entonces. Ejemplo: - Mensajes ininteligibles para el usuario. - Presentación inadecuada de resultados. - Deficiencias en el manual de usuario. - Procedimientos de operación inusuales - … etc. Para la realización de estas pruebas se pueden necesitar semanas o meses porque el usuario necesita ir aprendiendo el manejo del nuevo sistema. Es probable que los problemas más graves aparezcan ya al comienzo y por ello es aconsejable que alguien del equipo de desarrollo acompañe al usuario durante la primera toma de contacto. 73 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Se denominan pruebas alfa a unas primeras pruebas que se realizan en un entorno controlado donde el usuario tiene el apoyo de alguna persona del equipo de desarrollo y a su vez esta misma persona puede seguir muy de cerca la evolución de las pruebas. En las pruebas beta, uno o varios usuarios trabajan con el sistema en su entorno normal, sin apoyo de nadie, y anotando cualquier problema que se presente. Las versiones alfa: Se dan a los usuarios internos o a un grupo selecto y confiable de usuarios externos para los primeros usos antes de la liberación. Su propósito es proporcionar retroalimentación a la organización de desarrollo e información de defectos de un grupo más grande que el de los probadores, sin afectar la reputación del producto no liberado. Después de repartir las versiones alfa, se liberan las versiones beta. Las versiones beta: Se dan a parte de la comunidad de clientes con el entendimiento de que informarán acerca de los errores encontrados. Además, las versiones alfa y beta se usan para convencer a los clientes potenciales de que en realidad se trata de un producto que respalda las promesas de los proveedores 5.9.4.10 PRUEBAS DE RENDIMIENTO Sirven para comprobar las prestaciones del sistema que son críticas en el tiempo. Estas pruebas son fundamentales para los sistemas de tiempo real o sistemas embebidos. Para medir los tiempos se necesitan equipos de instrumentación. Ejemplo, se puede forzar al sistema provocando múltiples interrupciones simultáneamente para medir el tiempo máximo que se emplea en tratarlas. La prueba de rendimiento ocurre a lo largo de todos los pasos de prueba e incluso en el nivel de unidad, se puede acceder al rendimiento de un módulo individual a medida que se desarrollan las pruebas. Todas estas pruebas se han realizado en este software tanto a nivel de Processing como Arduino más Web y se adjuntan resultados en el Anejo correspondiente. 74 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.4.11 PRUEBAS DE CONFIGURACIÓN Programas tales como sistemas operativos, sistemas de gestión de datos y programas de conmutación de mensajes de apoyo de gran variedad de hardware de configuraciones, incluyendo diferentes tipos y números de E/S y dispositivos de líneas de comunicación, o de distintos tamaños de memoria. A menudo, el número de configuraciones posibles es demasiado grande para poner a prueba cada una de ellas, pero por lo menos, debe probar el programa con cada tipo de dispositivo de hardware y con la configuración mínima y máxima. Si el propio programa puede ser configurado para omitir los componentes del programa, o si el programa puede ejecutarse en equipos diferentes, de cada posible configuración del programa debe hacerse la prueba 5.9.4.12 PRUEBAS DE FACILIDAD DE USO Las pruebas de uso se diseñan para determinar el grado de la interfaz que facilita la vida del usuario. Las pruebas finales las realizará el usuario final siguiendo para ello la siguiente secuencia de pasos: - Definir un conjunto de prueba de uso mediante categorías e identificar las metas que se persiguen de cada una. - Diseño de pruebas que conllevan la evaluación de cada una de las metas que se deben alcanzar. - Seleccionar al usuario que desarrollará las pruebas. - Realizar un mecanismo para valorar el uso 5.9.4.13 ANÁLISIS DE LOS VALORES LÍMITE El análisis de los valores límites se centra en el límite del espacio de entrada para identificar casos de prueba. El fundamento de las pruebas de valor de límite es que los errores tienden a ocurrir cerca de los valores límites de una variable de entrada. 75 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado La idea básica del análisis de valores límite es el uso de valores de entrada, es obtener un valor nominal mínimo y valor nominal máximo para controlar el valor de las variables fronteras. 5.9.4.14 PRUEBAS ORIENTADAS A LA CONFIABILIDAD DEL SOFTWARE La meta de todo tipo de pruebas es la mejora de la fiabilidad del programa, pero si los objetivos del programa incluyen declaraciones específicas sobre la confiabilidad, las pruebas específicas de fiabilidad pueden ser desarrolladas. Las pruebas en los objetivos de confiabilidad pueden ser difíciles. Por ejemplo, en una red de área extensa (WAN), un proveedor de servicios de Internet tiene generalmente un tiempo de actividad específica del 99,97 por ciento durante la vida útil del sistema. No se conoce ninguna manera de que se podría poner a prueba este objetivo con un período de prueba de meses o incluso años. Los sistemas críticos en el software de hoy en día tienen estándares de confiabilidad, y el hardware de hoy posiblemente se podría esperar para apoyar estos objetivos. 5.9.4.15 BASADAS EN COMPONENTES Denominada prueba de función, permite un enfoque mediante un conjunto de pruebas que intentan descubrir errores en funciones webapps (web del conjunto de aplicaciones de productividad. Las aplicaciones web permiten a los usuarios acceder a sus documentos directamente desde cualquier parte dentro de un navegador web así como compartir archivos y colaborar con otros usuarios en línea). Cada función webapps es un componente del software implantado en uno o varios lenguajes de programación y se prueban utilizando técnicas de caja negra y en algunos casos de caja blanca. A continuación especificaremos los casos de prueba en los siguientes métodos aunque los hemos explicado con más detalle en apartados anteriores: 76 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.4.16 PRUEBAS PARA INTERNET Las aplicaciones de Internet son esencialmente aplicaciones cliente-servidor en las que el cliente es un navegador web y el servidor es un servidor web o aplicación. La complejidad de estas aplicaciones es muy dispar. Algunas empresas han construido aplicaciones para el negocio-a-consumidor y utilizan como servicios bancarios o tiendas al por menor, mientras que otros tienen las aplicaciones de negocio como la gestión de la cadena de suministro. Desarrollo y presentación de usuario/estrategias de interfaz de usuario varían para los distintos tipos de sitios web, y por lo tanto el enfoque de las pruebas varía para los diferentes tipos de sitios. El objetivo de las pruebas de aplicaciones basadas en Internet no es diferente de la de las aplicaciones tradicionales. Es necesario para descubrir errores en la aplicación antes de implementarla en Internet. Dada la complejidad de estas aplicaciones y la interdependencia de los componentes. 5.9.4.17 LAS ESTRATEGIAS DE EVALUACIÓN Desarrollar una estrategia de pruebas para aplicaciones basadas en Internet requiere de una sólida comprensión de cada uno de los componentes de hardware y software que componen la aplicación. Capa a nivel de presentación La capa de presentación consiste en encontrar errores en la guía de interfaz de usuario (GUI). Esta capa es importante porque proporciona el encanto de la aplicación, el detectar y corregir errores en esta capa son críticos al presentar un enfoque de calidad. Las pruebas de capa a nivel de presentación son muy laboriosas. Se identifican tres grandes áreas de pruebas en capa de presentación: - Contenido de prueba: Estética general, las fuentes, el color, la ortografía, la exactitud del contenido, los valores por defecto. - Sitio web de arquitectura: Los enlaces rotos o gráficos. 77 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado - Entorno de usuario: Versiones del navegador web y la configuración del sistema operativo. Capa a nivel de negocio La Prueba de la capa de negocio se centra en la búsqueda de errores, en la lógica de negocio de la aplicación de Internet. Es muy similar a las pruebas de aplicaciones independientes en las que se pueden emplear tanto técnicas de caja blanca como de caja negra. Se crean planes de pruebas y procedimientos que detectan errores en los requisitos de rendimiento de la aplicación, adquisición de datos y procesamiento de transacciones. Capa a nivel de datos La prueba de la capa de datos consiste principalmente en probar el sistema de gestión de base de datos que utiliza la aplicación para almacenar y recuperar información. Sitios más pequeños pueden almacenar datos en archivos de texto, pero más grandes, es decir los sitios más complejos utilizan todas las funciones de nivel empresarial de bases de datos. Dependiendo de sus necesidades, se pueden utilizar ambos métodos. Uno de los mayores desafíos relacionados con las pruebas de esta capa es duplicar el entorno de producción. Deben utilizarse las plataformas de hardware y las versiones equivalentes de software para realizar pruebas válidas. Una vez que se obtienen los recursos, tanto financieros como de trabajo, se debe desarrollar una metodología para el mantenimiento de producción y pruebas sincronizadas. Al igual que con los demás niveles, deben buscarse errores en ciertas áreas cuando se prueba la capa de datos 5.9.4.18 PRUEBAS PARA GUI La característica principal de cualquier interfaz gráfica de usuario (GUI) es que está orientado a eventos. Los usuarios pueden causar cualquiera de varios eventos en cualquier orden. Aunque es posible crear aplicaciones GUI en secuencia 78 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado de eventos, muchas interfaces gráficas de usuario son deficientes en este sentido. Las pruebas de interfaz de usuario hombre–máquina. Existen dos roles bien diferenciados: - Probar la interfaz de usuario para garantizar que funciona correctamente desde el punto de vista técnico y que cumple los estándares y requisitos definidos. - Usabilidad de la interfaz. La usabilidad se deriva de una comunicación efectiva de la información. Por ende, es necesario tener en cuenta los requisitos de usuario y desarrollar la interfaz de usuario de acuerdo con ellos. Las principales GUIs de este PFC están basadas en Processing, y existe una aplicación web con interface multiplataforma. La compatibilidad se adjunta en el Anejo anteriormente citado. 5.9.4.19 GUÍAS PARA LAS PRUEBAS Para la mayoría de las empresas la guía para un plan de pruebas es una parte muy importante en la gestión del proceso de pruebas. Objetivos Los objetivos de cada fase de prueba deben ser definidos Los criterios de terminación: Los criterios deben ser diseñados para especificar cada fase de pruebas y deberá evaluarse si son completos. Horarios: La agenda planifica el tiempo necesario para cada fase. Se deben indicar los casos de prueba diseñados, escritos y ejecutados. Algunas metodologías de software, tales como la programación extrema exigen que se diseñen los casos de prueba y pruebas unitarias antes de codificar la aplicación y antes de comenzarlas. Responsabilidades: Para cada fase, las personas que diseñan, escriben, ejecutan y controlan los casos de prueba, y las personas que se comprometen a reparar los errores descubiertos, deben ser identificados. Ya que en los grandes proyectos las disputas por desgracia pueden surgir en torno si los resultados de la 79 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado prueba en particular representan los errores, para no entrar en discusión deben ser identificados. Bibliotecas de casos de prueba y las normas: En un proyecto grande, los métodos sistemáticos para identificar, escribir y almacenar casos de prueba son necesarios. Herramientas: Las herramientas de prueba necesarias deben ser identificadas, incluyendo un plan de desarrollo, adquisición, cómo se van a utilizar, y cuando se necesitan. Tiempo en el ordenador: Este es un plan para la cantidad de tiempo de ordenador necesario en cada fase de pruebas. Esto incluye los servidores utilizados para compilar aplicaciones, si es necesario, las máquinas de escritorio necesarias para las pruebas de instalación, los servidores web para aplicaciones basadas en web, los dispositivos de red, si son necesarios, y así sucesivamente. Configuración de hardware: Si las configuraciones especiales de hardware o dispositivos son necesarios, un plan es necesario que se describen los requisitos, la forma en que se cumplen, y cuando se necesitan. Integración: Parte del plan de pruebas es una definición de cómo el programa será reconstruido. Un sistema que contiene los principales subsistemas o programas puede ser reconstruido de forma incremental, utilizando el enfoque de arriba hacia abajo o de abajo hacia arriba, por ejemplo, los bloques de construcción son los programas o subsistemas, en lugar de los módulos. Si este es el caso, un plan de integración de sistemas es necesario. El plan de integración del sistema define el orden de integración, la capacidad funcional de cada versión del sistema, y las responsabilidades para la producción y el código que simula el funcionamiento de los componentes no existentes. Seguimiento de los procedimientos: Los medios deben ser identificados para realizar un seguimiento de diversos aspectos del progreso de las pruebas, incluyendo la ubicación de módulos propensos a errores y la estimación de los avances con respecto al calendario, los recursos y los criterios de terminación. 80 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Depuración de procedimientos: Los mecanismos de depuración deben ser definidos mediante un informe en el cual se ha detectado el seguimiento del progreso de las correcciones, y el añadir las correcciones al sistema. Horarios, responsabilidades, herramientas, equipo y tiempo, recursos también deben ser parte del plan de depuración. Pruebas de regresión: Se llevan a cabo después de realizar una mejora funcional o reparación para el programa. Su propósito es determinar si el cambio ha retrocedido en otros aspectos del Programa. Por lo general se vuelve a ejecutar un subconjunto de casos de prueba del programa. Las pruebas de regresión son importantes porque los cambios y correcciones de errores tienden a ser mucho más propensos al error que el código del programa original. Un plan para las pruebas de regresión, quién, cómo, cuándo, también es necesario. 5.9.5 ESTÁNDARES INTERNATIONAL STANDARD IEEE Std 12207-2008. Systems and Software Engineering Software life cycle processes. Second edition 2008-02-01, 138 p. INTERNATIONAL STANDARD IEEE Std 1016-2009. IEEE Standard for Information Technology Systems Design Software Design Descriptions. 20 July 2009, 40 p. INTERNATIONAL STANDARD IEEE Std 15288-2008. Systems and software engineering System life cycle processes. Second edition 2008-02-01, 84p. INTERNATIONAL STANDARD IEEE Std 1471-2000. Systems and software engineering Recommended practice for architectural 81 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado description of software intensive systems. First edition 2007-07-15, 34p. lEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology. 84p. IEEE Std 1320.1-1998 IEEE Standard for Functional Modeling Language Syntax and Semantics for IDEF0. 115 p. INTERNATIONAL STANDARD IEEE Std 1465-1998(R2004). Adoption of International Standard ISO/IEC 12119: 1994(E) Information Technology Software Packages Quality requirements and testing. Reaffirmed 8 December 2004, 25 p. INTERNATIONAL STANDARD IEEE Std 1465-1998(R2004) [Adoption of ISO/IEC 12119: 1994(E)]. Information Technology Software packages Quality requirements and testing. Reaffirmed 8 December 2004, 25 p. INTERNATIONAL STANDARD IEEE Std 1028-2008 (Revision of IEEE Std 1028-1997). IEEE Standard for Software Reviews and Audits. Approved 16 June 2008, 52 p. INTERNATIONAL STANDARD IEEE Std 828-2005 (Revision of IEEE Std 828- 1998). IEEE Standard for Software Configuration Management Plans. 12 August 2005, 27 p. 82 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.10 ERRORES EN EL PROYECTO En el caso de existir errores de diseño se dará cuenta al proyectista para dar con la solución al problema. Además se prohibirá el uso de la aplicación por posibles daños que pueda ocasionar hasta que el error se vea subsanado. 5.11 LIQUIDACIÓN Terminada la elaboración del proyecto se procederá a la liquidación, donde se incluyen los importes correspondientes a la elaboración del proyecto. En el caso de que surgiera alguna posible modificación aprobada por la dirección del proyecto el contratante será el encargado de abonar este importe íntegramente. En el momento de que el cliente manifieste su conformidad con el producto recibido se consideran concluidos los compromisos por ambas partes, exceptuando el anterior periodo de garantía, que será de obligado cumplimiento por parte del proyectante. Los tiempos y porcentajes están explicados en este mismo documento en capítulos anteriores 5.12 DISPOSICIÓN FINAL Las partes contratantes, se ratifican en el contenido del pliego de condiciones, el cual tiene igual validez a todos los efectos, que una escritura pública, prometiendo fiel cumplimiento. 83 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 84 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” FIN DE DOCUMENTO: PLIEGO DE CONDICIONES Eduardo Garbayo Herce Logroño, a 16 de Julio de 2014 85 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 86 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado PROYECTO FIN DE CARRERA: “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” DOCUMENTO Nº 6: PRESUPUESTO Peticionario: DEPARTAMENTO DE INGENIERÍA ELECTRICA Informantes: Eduardo Garbayo Herce Alumno de Ingeniería Industrial Universidad de La Rioja Lugar y Fecha: Logroño, 12 de Julio de 2014 1 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 6. PRESUPUESTO 6.1 INTRODUCCIÓN Este presupuesto no incluye amortizaciones de material, ni otro tipo de gastos básicos como ordenadores personales de sobremesa, portátiles, o teléfonos móviles. Siendo prácticos, se sobreentiende que se dispone de dicho material. Tampoco se tiene en cuenta gastos como conexiones a internet, wifi, etc. De la misma forma no se ha contado para ello, un Beneficio Industrial de lo supondría la venta de este proyecto, principalmente porque éste PFC es sólo una base de partida de lo que se puede llegar a implantar con las aplicaciones que aquí se desarrollan o que se pueden llegar a crear usando las funciones básicas programadas. Igualmente, no se han contado las horas de programación, puesto que se desconocía por completo el funcionamiento de Processing, Arduino ,etc . Y aunque se tenían conocimientos altos en programación, comenzar el estudio de un nuevo lenguaje siempre es un reto complejo. Se podría estimar: Horas dedicadas a aprendizaje y posterior programación: 250-275 horas. … a un coste teórico de 40 euros la hora (10 euros real), dispararía el precio del proyecto en 10.000 euros, lo que lo hace inviable. También es cierto que si ahora se tuviera que desarrollar este mismo paquete de software las horas que harían falta serían alrededor de 100 horas, lo que ya acercan el precio a un valor de mercado, a un pago real de 10 euros la hora, el incremento del presupuesto sería de 1.000 euros, asumible perfectamente para cualquier empresa interesada. Pero, como se ha explicado, una vez desarrolladas las apps principales, y las configuraciones de sensores, etc. Todo el sistema está preparado implantar nuevas aplicaciones a partir de las funciones creadas. Si ahora se recibiera un encargo de instalar dos sensores cualesquiera en la placa y crear una aplicación personalizada 2 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado las horas dedicadas apenas serían unas 25 si no surgen complicaciones. Lo que incrementa el coste de material, en 250 euros. Correcto. Por otro lado hay que pensar con mentalidad de empresarios y no de ingenieros. Para hacer viable un proyecto de este tipo habrá que pensar en generar unos costes constantes. Vender una aplicación en un pago único, no licenciada como este caso no sería viable a nivel comercial. Se explica en el siguiente capítulo algunas opciones para ofertar este producto. 3 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 6.2 ESTADO DE MEDICIONES Unidades necesarias de material. DESCRIPCIÓN DEL MATERIAL FUTABA 14 SG (FASSTEST 2.4GHz) Estabilizador Naza GPS V2 kit DJI Naza H Pareja porta helice cw + cww Leopard 730 Kv LC2835 MN3508 700KV Brushless Regulador DJI 15A (ESC) 3-4 Lipo T-Motor ESC S35A 2-6S 600 Hz E600 (6*Motor/ESC; props; Accessories) T-Mot 15-5.5 V2 CF MULTIROTOR PROPS Bateria lipo 5100mAh 11.1V 3S 35C bateria lipo 3000 mA 4S 40C Phantom 2 y Vision DJI F 330 Lipo 2650mAh 3S 30C Lipo Pack bateria lipo 3000 mA 4S 40C Chasis DJI F550 Cableado Completo Phantom 2 - 330 + Tx - RTF GoPro Hero3 Wifi Tarjeta ultra fast class 10 Maletines de transporte Licencia IDE de Arduino Licencia Hardware Arduino Licencia del IDE Processing Licencia GIMP Licencia Bootstrap Licencia html5 Licencia CSS3 Licencia J2me Licencia JavaScript Licencia LSS Licencia Json Licencia PHPtriad Licencia WAMP Licencia Easy PHP Licencia Linux Ubuntu 13 Licencia Windows 7 OEM Licencia Google Chrome Licencia Mozilla Firefox Licencia Libreria Adafruit Licencia Eclipse Licencia Librería MTK GPS Licencia Librería Control IP5 Licencia Librería Unfolding Licencia Notepad ++ Licencia Sublime Text Licencia Brackets LSS Licencia 3DR radion config Licencia XCTU para Xbee Licencia OpenGL Editor CSS Editor LSS UNIDADES 1 1 1 2 4 4 4 4 1 2 1 1 1 1 1 1 20 1 1 1 1 3 3 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Licencia Json Edit Licencia Blue Griffon Licencia Open Office Licencia PHP Licencia php My Admin Licencia Apache Licencia JS FUTABA 14 SG (FASSTEST 2.4GHz) Estabilizador Naza GPS V2 kit DJI Naza H Pareja porta helice cw + cww Leopard 730 Kv LC2835 MN3508 700KV Brushless Regulador DJI 15A (ESC) 3-4 Lipo T-Motor ESC S35A 2-6S 600 Hz E600 (6*Motor/ESC; props; Accessories) T-Mot 15-5.5 V2 CF MULTIROTOR PROPS Bateria lipo 5100mAh 11.1V 3S 35C bateria lipo 3000 mA 4S 40C Phantom 2 y Vision DJI F 330 Lipo 2650mAh 3S 30C Lipo Pack bateria lipo 3000 mA 4S 40C Chasis DJI F550 Cableado Completo Phantom 2 - 330 + Tx - RTF GoPro Hero3 Wifi Tarjeta ultra fast class 10 Maletines de transporte 1 1 1 1 1 1 1 1 1 1 2 4 4 4 4 1 2 1 1 1 1 1 1 20 1 1 1 1 5 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 6.3 LISTA DE PRECIOS Actualizado julio 2014. DESCRIPCIÓN DEL MATERIAL COSTE UNITARIO Arduino Ethernet 45 Router de 4 Puertos 35 Cable de Red 12 Fuente de Alimentación 21 Pila 9v. 3 Conectores Pila – Arduino 1 Cabel usb 9 Resistencia 10k 0,1 Ardupilot Mega 2. 50 Arduino Uno 39 LM35 0,99 Xbee explorer usb 22 3DR 80 Xbee 115 Sonda NTC 19 Sensor LDR 0,54 Potenciometro 0,25 GPS GTPA 010 35 GPS GTPA 013 39 Cableado 0,1 Protoboards 1 Licencia IDE de Arduino 0 Licencia Hardware Arduino 0 Licencia del IDE Processing 0 Licencia GIMP 0 Licencia Bootstrap 0 Licencia html5 0 Licencia CSS3 0 6 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Licencia J2me 0 Licencia JavaScript 0 Licencia LSS 0 Licencia Json 0 Licencia PHPtriad 0 Licencia WAMP 0 Licencia Easy PHP 0 Licencia Linux Ubuntu 13 0 Licencia Windows 7 OEM 0 Licencia Google Chrome 0 Licencia Mozilla Firefox 0 Licencia Libreria Adafruit 0 Licencia Eclipse 0 Licencia Librería MTK GPS 0 Licencia Librería Control IP5 0 Licencia Librería Unfolding 0 Licencia Notepad ++ 0 Licencia Sublime Text 0 Licencia Brackets LSS 0 Licencia 3DR radion config 0 Licencia XCTU para Xbee 0 Licencia OpenGL 0 Editor CSS 0 Editor LSS 0 Licencia Json Edit 0 Licencia Blue Griffon 0 Licencia Open Office 0 Licencia PHP 0 Licencia php My Admin 0 Licencia Apache 0 Licencia JS 0 FUTABA 14 SG (FASSTEST 2.4GHz) 529 7 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Estabilizador Naza 155 GPS V2 kit DJI Naza H 161 Pareja porta helice cw + cww 19,9 Leopard 730 Kv LC2835 38 MN3508 700KV Brushless 65 Regulador DJI 15A (ESC) 3-4 Lipo 22,99 T-Motor ESC S35A 2-6S 600 Hz 40 E600 (6*Motor/ESC; props; Accessories) 450 T-Mot 15-5.5 V2 CF MULTIROTOR PROPS 121 Bateria lipo 5100mAh 11.1V 3S 35C 79 bateria lipo 3000 mA 4S 40C 26 Phantom 2 y Vision DJI F 330 109 Lipo 2650mAh 3S 30C Lipo Pack 49 bateria lipo 3000 mA 4S 40C 65 Chasis DJI F550 55 Cableado 0,5 Completo Phantom 2 - 330 + Tx - RTF 625 GoPro Hero3 Wifi 350 Tarjeta ultra fast class 10 65 Maletines de transporte 210 8 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 6.4 LISTA DE MATERIAL Se adjuntan listas de materiales necesarios para fabricación y pruebas. Para listas definitivas habría que contar solo con el material imprescindible. Por ejemplo, en este caso se han montado dos equipos para vuelo, uno personalizado, y otro comercial, cada uno con una serie de características. Asimismo, al hacer pedidos de material en componentes electrónicos no se compran por unidades si no por packs en parejas, o decenas. De los cuales sobrarían luego bastantes elementos. Se podría estudiar si fuera preciso el coste por unidad. Desestimado, por ser insignificante. Estos costes de materiales se podría decir que son para estudio y análisis. No para el proyecto final de cada situación, de un cliente en particular. 9 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 6.4.1 PLACAS, ARDUINOS Y COMPONENTES Este es un listado expandido. Hay más componentes de los que realmente necesita el proyecto. Pero este material es importante para fabricación y montaje. PFC - 2014 Presupuestos Dirección : Logroño Ciudad, Código postal Teléfono: 629486109 Fax: 629486109 DESCRIPCIÓN DEL MATERIAL Arduino Ethernet Router de 4 Puertos Cable de Red Fuente de Alimentación Pila 9v. Conectores Pila – Arduino Cabel usb Resistencia 10k Ardupilot Mega 2. Arduino Uno LM35 Xbee explorer usb 3DR Xbee Sonda NTC Sensor LDR Potenciometro GPS GTPA 010 GPS GTPA 013 Cableado Protoboards FECHA: Nº DE PRESUPUESTO: 16/07/2014 PARA: Universidad de La Rioja FACTURAR A: Nombre : Universida de La Rioja 1 Dirección Ciudad, Código postal Teléfono: 629486109 UNIDADES 1 1 1 1 4 4 3 10 1 1 1 1 1 1 1 1 1 2 1 20 2 COSTE UNITARIO 45 35 12 21 3 1 9 0,1 50 39 0,99 22 80 115 19 0,54 0,25 35 39 0,1 1 SUBTOTAL IVA OTROS TOTAL IMPORTE € € € € € € € € € € € € € € € € € € € € € € 45,00 35,00 12,00 21,00 12,00 4,00 27,00 1,00 50,00 39,00 0,99 22,00 80,00 115,00 19,00 0,54 0,25 70,00 39,00 2,00 2,00 596,78 21,00% - € 722,10 10 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 6.4.2 LICENCIAS EN EL SOFTWARE El 99% del proyecto se realiza sobre licencias OS. Y el resto, son de uso gratuito aunque no de acceso al código. Véase, Windows OEM PFC - 2014 Presupuestos Dirección : Logroño Ciudad, Código postal Teléfono: 629486109 Fax: DESCRIPCIÓN DEL MATERIAL Licencia IDE de Arduino FECHA: 16/07/2014 Nº DE PRESUPUESTO: 2 PARA: UR FACTURAR A: Nombre : Universidad de La Rioja Dirección Ciudad, Código postal Teléfono: UNIDADES 3 COSTE UNITARIO 0 IMPORTE € - Licencia Hardware Arduino 3 0 € - Licencia del IDE Processing Licencia GIMP Licencia Bootstrap Licencia html5 Licencia CSS3 Licencia J2me Licencia JavaScript Licencia LSS Licencia Json Licencia PHPtriad Licencia WAMP Licencia Easy PHP Licencia Linux Ubuntu 13 Licencia Windows 7 OEM Licencia Google Chrome Licencia Mozilla Firefox Licencia Libreria Adafruit Licencia Eclipse Licencia Librería MTK GPS Licencia Librería Control IP5 Licencia Librería Unfolding Licencia Notepad ++ Licencia Sublime Text Licencia Brackets LSS Licencia 3DR radion config 3 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 € € € € € € € € € € € € € € € € € € € € € € € € € - 11 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado Licencia XCTU para Xbee Licencia OpenGL Editor CSS Editor LSS Licencia Json Edit Licencia Blue Griffon Licencia Open Office Licencia PHP Licencia php My Admin Licencia Apache Licencia JS Donaciones a Proyectos Open Source 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 € € € € € € € € € € € - 5 2 € 10,00 SUBTOTAL IVA OTROS TOTAL € 10,00 21,00% 12,10 € 12 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 6.4.3 LISTADO DE MATERIAL RELATIVO AL VUELO Este es un listado expandido. Hay más componentes de los que realmente necesita el proyecto. Pero este material es importante para fabricación y montaje. PFC - 2014 Presupuestos Dirección : Logroño Ciudad, Código postal Teléfono: 629486109 Fax: DESCRIPCIÓN DEL MATERIAL FECHA: Nº DE PRESUPUESTO: 16/07/2014 PARA: Universidad de La Rioja FACTURAR A: Universidad de La Rioja Universidad de La Rioja Dirección Ciudad, Código postal Teléfono: 629486109 3 UNIDADES COSTE UNITARIO IMPORTE FUTABA 14 SG (FASSTEST 2.4GHz) 1 529 € 529,00 Estabilizador Naza GPS V2 kit DJI Naza H Pareja porta helice cw + cww Leopard 730 Kv LC2835 MN3508 700KV Brushless Regulador DJI 15A (ESC) 3-4 Lipo T-Motor ESC S35A 2-6S 600 Hz E600 (6*Motor/ESC; props; Accessories) T-Mot 15-5.5 V2 CF MULTIROTOR PROPS Bateria lipo 5100mAh 11.1V 3S 35C Bateria lipo 3000 mA 4S 40C Phantom 2 y Vision DJI F 330 Lipo 2650mAh 3S 30C Lipo Pack Nateria lipo 3000 mA 4S 40C Chasis DJI F550 Cableado Completo Phantom 2 - 330 + Tx - RTF GoPro Hero3 Wifi Tarjeta ultra fast class 10 Maletines de transporte 1 1 2 4 4 4 4 1 155 161 19,9 38 65 22,99 40 450 € € € € € € € € 155,00 161,00 39,80 152,00 260,00 91,96 160,00 450,00 2 121 € 242,00 1 1 1 1 1 1 20 1 1 1 1 79 26 109 49 65 55 0,5 625 350 65 210 SUBTOTAL IVA OTROS TOTAL € € € € € € € € € € € € € 79,00 26,00 109,00 49,00 65,00 55,00 10,00 625,00 350,00 65,00 210,00 3.883,76 21,00% 4.699,35 13 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 6.5 RESUMEN DEL PRESUPUESTO. El coste necesario para crear las placas, montajes, componentes asciende a 596,78 € Quinientos noventa y seis euros y setenta y ocho céntimos. IVA no incluido. El coste en licencias de software asciende a: 10 € . Diez euros. IVA no incluido. Desgravable por ser donación. El coste de material de vuelo asciende a 3.883,76 € Tres mil ochocientos ochenta y tres euros y setenta y seis céntimos. IVA no incluido. Firmado: Eduardo Garbayo Herce Logroño, a 16 de Julio de 2014 14 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 6.6 PRECIO PARA VENTA COMO PACK No sería viable vender un solo pack de este producto. Para amortizarlo se deberían vender miles de unidades y eso sería realmente difícil por la infraestructura que conllevaría una empresa de dichas características de stock, ingenieros técnicos y programadores de alto nivel. 6.7 PRECIO PARA ALQUILER La única salida de este proyecto sería en licencia de alquiler. Una contratación mensual, o salidas discretas previa contratación personalizada. Se ven algunos ejemplos: Una salida para tomar mediciones de humos en una fábrica: 300 euros la media jornada. Incluyendo viajes, seguros de vuelo, licencias, etc. Contratación mensual que incluya una salida de urgencia 24horas, y 3 programadas: 1.000 euros/mensuales. Incluyendo viajes, seguros de vuelo, licencias, etc. Sistema de Arduino conectado a Ethernet sin equipo de vuelo: Dando mediciones en una bodega de las humedades y temperaturas de la misma; incluyendo apps, servicio web, hosting, dominio, etc : 300 euros mensuales. Con este tipo de servicios este PFC podría llegar a ser viable, y así lo cree su autor. 15 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 6.8 PRESENTACIÓN A CONCURSOS PUBLICOS. RÉGIMEN CONCURSAL Sin incurrir en baja temeraria se mantendrá el precio de listado de material del proyecto y se cambiarán las horas de programación para convertirlo en un proyecto realista. Se usarían las horas dedicadas a software como se ha explicado en el segundo punto. Descartando por completo todo el periodo de aprendizaje o de creación de las aplicaciones. Se eliminan las horas de los programadores y técnicos que tuvieran que desarrollar y montar el proyecto y se parte desde cero en este punto. Se calcularán las horas necesarias solo para la aplicación personalizada del cliente basándose en el código ya existente. Por otro lado el precio por hora como se indica bajará a precio de mercado. *Los precios no incluyen IVA. *Los precios y presupuesto no incluyen retenciones de IRPF u otros impuestos o gravámenes. 16 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” FIN DE DOCUMENTO: PRESUPUESTOS Eduardo Garbayo Herce Logroño, a 16 de Julio de 2014 17 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 18 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado PROYECTO FIN DE CARRERA: “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” DOCUMENTO Nº7: ESTUDIOS CON ENTIDAD PROPIA Peticionario: DEPARTAMENTO DE INGENIERÍA ELECTRICA Informantes: Eduardo Garbayo Herce Alumno de Ingeniería Industrial Universidad de La Rioja Lugar y Fecha: Logroño, 12 de Julio de 2014 1 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 2 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 7. ESTUDIOS CON ENTIDAD PROPIA La norma UNE 157001 (aplicada como segunda norma en este proyecto, pero siendo en la que se basa la norma aplicada) “Criterios Generales para la Elaboración de Proyectos” establece que el proyecto constará de los documentos presentados en los capítulos anteriores (Memoria, Planos, Pliego de Condiciones y Presupuesto) y cuando proceda de Estudios con Entidad Propia. Los Estudios con Entidad Propia tienen como misión incluir los documentos requeridos por exigencias legales. Como indica la norma UNE anteriormente mencionada en su apartado 12.2, NO se incluirán en este documento entre otros y sin carácter limitativo: Estudios de Seguridad y Salud. Estudios de Impacto Ambiental. Dadas las condiciones y especificaciones de este proyecto no será necesario la incursión documental de estudios con entidad propia relativos a Impacto Ambiental ni Seguridad y salud. Estudios de Seguridad y Salud. Estudios de Impacto Ambiental 3 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 7.1 MARCO NORMATIVO BÁSICO SOBRE SEGURIDAD Y SALUD La Ley 31/1995, de 8 de noviembre de 1995, de Prevención de Riesgos Laborales tiene por objeto la determinación del cuerpo básico de garantías y responsabilidades, preciso para establecer un adecuado nivel de protección de la salud de los trabajadores. Su finalidad es hacer frente a los riesgos derivados de las condiciones de trabajo. Como ley establece un marco legal a partir del cual se han definido normas reglamentarias que han ido fijando y concretando los aspectos más técnicos de las medidas preventivas. En el amplio conjunto de normas complementarias desarrolladas destacan, en el campo de la actividad proyectual, las siguientes: REAL DECRETO 1627/1997, de 24 de octubre, por el que se establecen disposiciones mínimas de seguridad y salud en las obras de construcción. REAL DECRETO 486/1997, de 14 de abril, por el que se establecen las disposiciones mínimas de seguridad y salud en los lugares de trabajo. REAL DECRETO 485/1997, 14 de abril, sobre disposiciones mínimas en materia de señalización de seguridad y salud en el trabajo. • Real Decreto 1215/1997, de 18 de julio, por el que se establecen las disposiciones mínimas de seguridad y salud para la utilización por los trabajadores de los equipos de trabajo. REAL DECRETO 773/1997, 30 de mayo, sobre disposiciones mínimas de seguridad y salud relativas a la utilización por los trabajadores de equipos de protección individual. Del Real Decreto 1627/1997, que establece las disposiciones mínimas de seguridad y de salud aplicables a las obras de construcción, destacan en relación a la obligatoriedad de la elaboración de los documentos del proyecto y en concreto de los Estudios con Entidad propia los siguientes artículos: Artículo 1. Objeto y ámbito de aplicación. 4 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1. El presente Real Decreto establece, en el marco de la Ley 31/1995, de 8 de noviembre, de Prevención de Riesgos Laborales, las disposiciones mínimas de seguridad y de salud aplicables a las obras de construcción. 2. Este Real Decreto no será de aplicación a las industrias extractivas a cielo abierto o subterráneas o por sondeos, que se regularán por su normativa específica. 3. Las disposiciones del Real Decreto 39/1997, de 17 de enero, por el que se aprueba el Reglamento de los Servicios de Prevención, se aplicarán plenamente al conjunto del ámbito contemplado en el apartado 1, sin perjuicio de las disposiciones específicas previstas en el presente Real Decreto. Artículo 4. Obligatoriedad del estudio de seguridad y salud o del estudio básico de seguridad y salud en las obras. 1. El promotor estará obligado a que en la fase de redacción del proyecto se elabore un estudio de seguridad y salud en los proyectos de obras en que se den alguno de los supuestos siguientes: a. Que el presupuesto de ejecución por contrata incluido en el proyecto sea igual o superior a 75 millones de pesetas. b. Que la duración estimada sea superior a 30 días laborables, empleándose en algún momento a más de 20 trabajadores simultáneamente. c. Que el volumen de mano de obra estimada, entendiendo por tal la suma de los días de trabajo del total de los trabajadores en la obra, sea superior a 500. d. Las obras de túneles, galerías, conducciones subterráneas y presas. 2. En los proyectos de obras no incluidos en ninguno de los supuestos previstos en el apartado anterior, el promotor estará obligado a que en que en la fase de redacción del proyecto se elabore un estudio básico de seguridad y salud. 5 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 7.2 PROYECTOS SOMETIDOS A EVALUACIÓN DE IMPACTO AMBIENTAL El artículo 3 del REAL DECRETO LEGISLATIVO 1/2008, de 11 de enero, por el que se aprueba el texto refundido de la Ley de Evaluación de Impacto Ambiental de proyectos establece que: Artículo 3. Ámbito. 1. Los proyectos, públicos y privados, consistentes en la realización de obras, instalaciones o cualquier otra actividad comprendida en el anexo I deberán someterse a una evaluación de impacto ambiental en la forma prevista en esta ley. Anexo I Grupo 3. Industria energética. a. Refinerías de petróleo bruto (con la exclusión de las empresas que produzcan únicamente lubricantes a partir de petróleo bruto), así como las instalaciones de gasificación y de licuefacción de, al menos, 500 toneladas de carbón de esquistos bituminosos (o de pizarra bituminosa) al día. b. Centrales térmicas y nucleares Instalaciones industriales para la producción de electricidad, vapor y agua caliente con potencia térmica superior a 300 MW. f. Tuberías para el transporte de gas y petróleo con un diámetro de más de 800 milímetros y una longitud superior a 40 kilómetros. g. Construcción de líneas aéreas para el transporte de energía eléctrica con un voltaje igual o superior a 220 kV y una longitud superior a 15 kilómetros. h. Instalaciones para el almacenamiento de productos petrolíferos mayores de 100.000 toneladas. i. Instalaciones para la utilización de la fuerza del viento para la producción de energía (parques eólicos) que tengan 50 o más aerogeneradores, o que se encuentren a menos de 2 kilómetros de otro parque eólico. 6 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 2. Sólo deberán someterse a una evaluación de impacto ambiental en la forma prevista en esta ley, cuando así lo decida el órgano ambiental en cada caso, los siguientes proyectos: a) Los proyectos públicos o privados consistentes en la realización de las obras, instalaciones o de cualquier otra actividad comprendida en el anexo II. Anexo II Grupo 4. Industria energética. a. Instalaciones industriales para el transporte de gas, vapor y agua caliente; transporte de energía eléctrica mediante líneas aéreas (proyectos no incluidos en el anexo I), que tengan una longitud superior a 3 kilómetros b. Fabricación industrial de briquetas de hulla y de lignito c. Instalaciones para la producción de energía hidroeléctrica (cuando, según lo establecido en el anexo I, no lo exija cualquiera de las obras que constituyen la instalación). d. Instalaciones de oleoductos y gasoductos (proyectos no incluidos en el anexo I), excepto en suelo urbano, que tengan una longitud superior a 10 kilómetros. e. Almacenamiento de gas natural sobre el terreno. Tanques con capacidad unitaria superior a 200 toneladas. f. Almacenamiento subterráneo de gases combustibles. Instalaciones con capacidad superior a 100 metros cúbicos. g. Instalaciones para el procesamiento y almacenamiento de residuos radiactivos (que no estén incluidas en el anexo I). h. Parques eólicos no incluidos en el anexo I. i. Instalaciones industriales para la producción de electricidad, vapor y agua caliente con potencia térmica superior a 100 MW. b) Los proyectos públicos o privados no incluidos en el anexo I que pueda afectar directa o indirectamente a los espacios de la Red Natura 2000. 7 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado La decisión, que debe ser motivada y pública, se ajustará a los criterios establecidos en el anexo III. La normativa de las comunidades autónomas (Comunidad Autónoma de Murcia. Ley 1/1995, de Protección del Medio Ambiente de la Región de Murcia) podrá establecer, bien mediante el análisis caso a caso, bien mediante la fijación de umbrales, y de acuerdo con los criterios del anexo III, que los proyectos a los que se refiere este apartado se sometan a evaluación de impacto ambiental. 8 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV” FIN DE DOCUMENTO: ESTUDIOS CON ENTIDAD PROPIA Eduardo Garbayo Herce Logroño, a 16 de Julio de 2014 9 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 10 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1. MEMORIA ............................................................................................... 16 1.1 OBJETO .................................................................................................................................... 17 1.1.1 PALABRAS CLAVE .................................................................................................................. 17 1.1.2 KEYWORDS ........................................................................................................................... 17 1.1.3 APARTADOS DE LA MEMORIA .............................................................................................. 18 1.2 ANTECEDENTES ........................................................................................................................ 21 1.2.1 ANTECEDENTES DEL AUTOR ................................................................................................. 21 1.2.2 ANTECEDENTES DEL PROYECTO ........................................................................................... 24 1.3 1.2.2.1 QUÉ ES ARDUINO Y SUS ALTERNATIVAS: ........................................................................ 24 1.2.2.2 VEHÍCULO AÉREO NO TRIPULADO UAV. DRONE............................................................. 25 OBJETIVOS DEL PROYECTO ....................................................................................................... 28 1.3.1 OBJETIVOS CUMPLIDOS ........................................................................................................ 29 1.3.2 EXTRAS AÑADIDOS ............................................................................................................... 31 1.3.3 CONOCIMIENTOS PREVISO NECESARIOS .............................................................................. 32 1.3.4 CONOCIMIENTOS A ADQUIRIR ............................................................................................. 32 1.4 CONCLUSIONES Y VÍAS DE CONTINUACIÓN .............................................................................. 34 1.4.1 APLICACIONES ...................................................................................................................... 34 1.5 TIMELINE ................................................................................................................................. 38 1.6 ARDUINO ................................................................................................................................. 40 1.6.1 SELECCIÓN DE LA TARJETA USADA ....................................................................................... 40 1.6.2 ALTERNATIVA CON EL MODULO ETHERNET ........................................................................ 41 1.6.3 POWER OVER ETHERNET, POE ............................................................................................. 42 1.6.4 SALIDA VIA ROUTER A RED ................................................................................................... 42 1.6.5 MODO SERVIDOR EN LOCAL – LOCALHOST .......................................................................... 42 1.6.6 MODO SERVIDOR EN INTERNET ........................................................................................... 44 1.6.7 SENSORES INSTALADOS. ....................................................................................................... 46 1.6.7.1 1.7 OTROS SENSORES............................................................................................................ 47 NUEVO PARADIGMA ................................................................................................................ 48 11 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.7.1 RECOGIDA DE DATOS EN PUERTO SERIE .............................................................................. 49 1.7.2 MODULOS INALAMBRICOS ................................................................................................... 54 1.7.3 SISTEMA 3DR ........................................................................................................................ 54 1.7.4 SISTEMA XBEE - ZIGBEE ........................................................................................................ 56 1.7.5 POSICIONAMIENTO GLOBAL GPS ......................................................................................... 58 1.7.6 EMISIÓN Y RECEPCIÓN DE DATOS ........................................................................................ 60 1.7.7 EMISIÓN DESDE ARDUINO.................................................................................................... 62 1.8 PROCESSING – RECEPCIÓN DE DATOS - .................................................................................... 63 1.8.1 USO DEL PUERTO SERIE COM ............................................................................................... 65 1.8.2 CONSOLAS DE CONTROL EN PROCESSING ............................................................................ 67 1.8.3 CONSOLA BÁSICA.................................................................................................................. 67 1.8.4 CONSOLA COMPLETA DE CONTROL PARA MUESTRESO REALTIME ...................................... 68 1.8.5 CONSOLA COMPLETA DE CONTROL PARA POSICIONAMIENTO GPS .................................... 73 1.8.6 ALTERNATIVAS A ARDUINO-PROCESSING (JAVA,PHP) ......................................................... 80 1.9 PANEL DE ADMIN WEB ............................................................................................................ 82 1.9.1 CAMARA WIFI MONTADA EN DRONE ................................................................................... 83 1.9.2 LIVE STREAMING................................................................................................................... 88 1.9.3 ANGULARES DE GRABACIÓN ................................................................................................ 89 1.9.4 EFECTO FLAN – GELATINA O ROLLING SHUTTER .................................................................. 89 1.9.5 RECEPCIÓN DE VIDEO LIVE STREAMING ............................................................................... 89 1.10 CAPACIDAD DE TRABAJAR EN TIEMPO REAL........................................................................ 92 1.10.1 EN MODO CONSOLA LOCAL.................................................................................................. 92 1.10.2 EN MODO ONLINE. ............................................................................................................... 92 1.11 FLUJO DE DATOS Y OPEN DATA ........................................................................................... 95 1.11.1 OPEN DATA ........................................................................................................................... 96 1.11.2 TIEMPO REAL DE LAS APLICACIONES .................................................................................. 101 1.11.3 FUNCIONAMIENTO MODELO 1 TIEMPO REAL .................................................................... 103 1.11.4 FUNCIONAMIENTO MODELO 2 Y 3 TIEMPO REAL .............................................................. 104 1.11.5 ALTERNATIVA PARA EL MODELO 2 Y 3 ............................................................................... 105 1.12 BOOTSTRAP DE TWITTER .................................................................................................. 107 1.12.1 VISUALIZACIÓN EN INTERNET DE LOS DATOS .................................................................... 110 1.12.2 COMO RESULTADO UN SISTEMA MULTIPLATAFORMA ...................................................... 112 12 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 1.12.3 FORMATOS GRAFICOS DE LOS DATOS ................................................................................ 113 1.13 VERSIONES DEL SOFTWARE ............................................................................................... 116 1.14 REQUISITOS DE EXPOSICIÓN-PRESENTACIÓN .................................................................... 118 1.15 ORDEN DE PRIORIDAD DOCUMENTAL ............................................................................... 120 1.15.1 1.16 COMPATIBILIDAD Y RELACION ENTRE DICHOS DOCUMENTOS .......................................... 120 BIBLIOGRAFÍA ................................................................................................................... 120 1.16.1 REFERENCIAS BIBLIOGRÁFICAS DE ESTUDIOS CON ENTIDAD PROPIA. ............................... 121 1.17 DEFINICIONES Y ABREVIATURAS........................................................................................ 122 1.18 NORMAS Y REFERENCIAS .................................................................................................. 128 1.18.1 1.19 NORMAS PARA CONSULTA ................................................................................................. 128 INDICE DE ILUSTRACIONES ................................................................................................ 137 2. PLANOS ................................................................................................... 3 2.1 INTRODUCCIÓN ......................................................................................................................... 3 SONDA DE TEMPERATURA NTC ........................................................................................................... 4 SENSOR LDR ........................................................................................................................................ 4 SENSOR LM35 ..................................................................................................................................... 4 POTENCIOMETRO................................................................................................................................ 4 SISTEMA INALAMBRICO XBEE ............................................................................................................. 4 GPS GTPA 013 ..................................................................................................................................... 4 GPS GTPA 013 + LM 35 ....................................................................................................................... 4 LDR + LM35 + XBEE + GPS + ARDUINO ETHERNET ................................................................................ 4 POTENCIOMETRO + GPS + XBEE + ARDUINO....................................................................................... 4 13 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3. ESPECIFICACIONES DEL SISTEMA ...................................................... 3 3.1 CONFIGURACIONES BÁSICAS ..................................................................................................... 3 3.2 CONFIGURACIÓN PUESTA EN MARCHA DEL DRONE ................................................................... 3 3.2.1 3.3 SOFTWARE DE CONFIGURACION ............................................................................................ 7 ARDUINO ................................................................................................................................... 8 3.3.1 PUESTA EN MARCHA .............................................................................................................. 8 3.3.2 PUERTO SERIE ......................................................................................................................... 8 3.3.3 IDE DE ARDUINO ..................................................................................................................... 9 3.3.4 INSTALACIÓN EN WINDOWS XP-7-8-8.1................................................................................. 9 3.3.5 INSTALACIÓN EN LINUX - UBUNTU ....................................................................................... 10 3.3.6 DRIVERS DE ARDUINO. ......................................................................................................... 11 3.3.7 PUERTOS SERIE. .................................................................................................................... 11 3.3.8 PROBLEMAS DE INSTALACIÓN. IDE, DRIVERS, ETC ............................................................... 12 3.3.9 NO DETECTA DRIVERS........................................................................................................... 12 3.3.10 PUERTO OCUPADO ............................................................................................................... 13 3.3.11 MUY LENTO EL IDE BAJO WINDOWS 7 ................................................................................. 14 3.3.12 ARRCANCA LA IDE DE ARDUINO ........................................................................................... 14 3.3.13 USO DE LA SHIELD ETHERNET ............................................................................................... 15 3.3.14 LIBRERÍAS PARA ARDUINO.................................................................................................... 15 3.3.15 CONFIGURANDO LA RED EN MODO LOCALHOST E INTERNET DIRECTO .............................. 16 3.3.15.1 3.4 CONFIGURACIÓN DEL ROUTER ..................................................................................... 21 CONVERTIR EL ORDENADOR EN UN SERVIDOR ........................................................................ 23 3.4.1 CREACIÓN DE UN WAMP ...................................................................................................... 24 3.4.2 CREACIÓN DE UN LAMP ....................................................................................................... 24 3.4.3 COMPROBACIÓN .................................................................................................................. 25 3.4.4 COMUNICACIÓN BÁSICA- COMPROBACIONES ..................................................................... 26 3.4.5 CODIGO BASICO PARA ENVIAR DATOS VIA ETHERNET CON GET A UNA SQL ....................... 26 3.5 ENVÍO DE DATOS DESDE ARDUINO A PROCESSING VIA SERIAL ................................................ 27 3.5.1 3.6 DESDE PHP ............................................................................................................................ 29 INSTALACIÓN DE SENSORES ..................................................................................................... 31 3.6.1 ENTRADAS. SALIDAS PVM. .................................................................................................... 31 14 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.6.2 POTENCIOMETRO ................................................................................................................. 33 3.6.2.1 3.6.3 CODIGO BÁSICO EN ARDUINO PARA UN POTENCIOMETRO ........................................... 34 SONDA NTC DE TEMPERATURA ............................................................................................ 35 3.6.3.1 CODIGO ARDUINO PARA NTC – STEINHARHART............................................................. 38 3.6.3.2 CODIGO ARDUINO PARA NTC – MÉTODO 2 - .................................................................. 39 3.6.4 INSTALACIÓN DE UNA LDR ................................................................................................... 41 3.6.4.1 ACONDICIONAMIENTO DE SEÑAL ................................................................................... 42 3.6.5 SENSOR LM35 ....................................................................................................................... 45 3.6.6 CONFIGURACIÓN DEL GPS .................................................................................................... 49 3.6.6.1 CONFIGURACIÓN HARDWARE ........................................................................................ 49 3.6.6.2 CODIGO ARDUINO PARA LECTURA DEL GPS ................................................................... 50 3.6.7 3.7 OTROS SENSORES ................................................................................................................. 54 IDE PARA PROCESSING ............................................................................................................. 55 3.7.1 LIBRERIAS PARA PROCESSSING ............................................................................................. 55 3.7.2 CONDICIONES DE EJECUCIÓN DE PROCESSING .................................................................... 56 3.7.3 PROBLEMAS DE EJECUCIÓN DE PROCESSING ....................................................................... 57 3.7.4 LIBRERIAS PARA PROCESSING............................................................................................... 61 3.7.5 CONDICIONES DEL SISTEMA GRÁFICO .................................................................................. 62 3.8 CONFIGURACION DE XBEE ....................................................................................................... 65 3.8.1 CONFUSIÓN ZIGBEE, Y PROTOCOLO 802.15.4 EN MÓDULOS XBEE...................................... 67 3.8.2 CARACTERÍSTICAS ................................................................................................................. 67 3.8.3 CONFIGURACIÓN DE LOS JUMPERS ...................................................................................... 68 3.8.4 SOFTWARE ............................................................................................................................ 68 3.8.5 HARDWARE........................................................................................................................... 70 3.9 CONFIGURACIÓN DE 3DR ......................................................................................................... 72 3.9.1 SOFTWARE ............................................................................................................................ 72 3.9.1.1 AJUSTES. .......................................................................................................................... 73 3.9.1.2 CONDICIONES TÉCNICAS PARA QUE FUNCIONE PROCESSING........................................ 75 3.9.2 PLANOS ................................................................................................................................. 76 3.9.3 HARDWARE........................................................................................................................... 76 3.10 GPS PARA ARDUINO ............................................................................................................ 77 3.10.1 LIBRERIAS PARA GPS ............................................................................................................. 77 15 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 3.10.2 INSTALACIÓN DE LIBRERÍAS PARA ARDUINO........................................................................ 79 3.10.3 PROTOCOLO NMEA .............................................................................................................. 80 3.10.4 CONVERSIÓN PERSONALIZADA DE DATOS DMM , DDD ....................................................... 82 3.11 LIVE STREAMING VIA WIFI ................................................................................................... 83 3.11.1 WLAN, LA RED INALAMBRICA ............................................................................................... 85 3.11.2 802,11G ................................................................................................................................ 86 3.11.3 802.11A................................................................................................................................. 86 3.11.4 802.11N ................................................................................................................................ 87 3.11.5 COMPATIBILIDAD DE LOS DOSPOSITIVOS WLAN N .............................................................. 88 3.12 VUELO DEL DRONE .............................................................................................................. 89 3.12.1 CONCICIONES MÍNIMAS DEL DRONE ................................................................................... 89 3.12.2 COMPAS, GPS, IMUS ............................................................................................................. 90 3.12.3 ¿POR QUÉ CALIBRAR LA BRÚJULA? ...................................................................................... 90 3.12.4 ¿CUÁNDO HACERLO?............................................................................................................ 90 3.12.5 AVISOS .................................................................................................................................. 90 3.12.6 PROCDIMIENTO DE CALIBRACIÓN ........................................................................................ 91 3.12.7 SOFTWARE DE CONFIGURACION DE EMISORA Y DRONE ..................................................... 92 4. ANEXOS ................................................................................................... 2 4.1 ARDUINO ................................................................................................................................... 2 4.1.1 ARDUINO MEGA 2 – ARDUPILOT ............................................................................................ 2 4.1.2 IDE DE ARDUINO ..................................................................................................................... 4 4.1.3 ARDUINO LENTO ..................................................................................................................... 4 4.2 SENSORES EXTRA ....................................................................................................................... 7 4.2.1 DHT 11 - HUMEDAD................................................................................................................ 7 4.2.2 SERIE MQ X ............................................................................................................................. 8 4.2.3 MQ2. ....................................................................................................................................... 9 4.2.4 MQ3. ..................................................................................................................................... 10 4.2.5 MQ4. ..................................................................................................................................... 10 4.2.6 MQ-5..................................................................................................................................... 10 4.2.7 MQ-6..................................................................................................................................... 11 4.2.8 MQ-7..................................................................................................................................... 11 16 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.2.9 MQ-8..................................................................................................................................... 12 4.2.10 MQ-9..................................................................................................................................... 12 4.2.11 MQ131 .................................................................................................................................. 12 4.2.12 MQ135 .................................................................................................................................. 12 4.2.13 MQ136 .................................................................................................................................. 13 4.2.14 MQ137 .................................................................................................................................. 13 4.2.15 MQ138 .................................................................................................................................. 13 4.2.16 MQ214 .................................................................................................................................. 13 4.2.17 MQ216 .................................................................................................................................. 13 4.2.18 MQ303A ............................................................................................................................... 13 4.2.19 MQ306A ............................................................................................................................... 14 4.2.20 MQ307A ............................................................................................................................... 14 4.2.21 MQ309A ............................................................................................................................... 14 4.2.22 MG811 .................................................................................................................................. 14 4.2.23 AQ-104 .................................................................................................................................. 14 4.2.24 AQ-2 ...................................................................................................................................... 14 4.2.25 AQ-3 ...................................................................................................................................... 15 4.2.26 AQ-7 ...................................................................................................................................... 15 4.3 OTROS FORMATOS .................................................................................................................. 15 4.4 COMUNICACIÓN PUERTO SERIE ............................................................................................... 15 4.4.1 PUERTOS SERIE MODERNOS................................................................................................. 16 4.4.2 USB ESTÁNDAR ..................................................................................................................... 16 4.4.2.1 4.5 PATILLAJE ........................................................................................................................ 18 MODULOS INALAMBRICOS ...................................................................................................... 18 4.5.1 COMUNICACIÓN XBEE .......................................................................................................... 20 4.5.2 XBEE 1MW – SERIE 1 ............................................................................................................ 21 4.5.3 XBEE 2MW – SERIE 2 ............................................................................................................ 21 4.5.4 ARQUITECTURA BÁSICA DE UNA RED XBEE. ......................................................................... 22 4.5.5 MODOS RECIBIR/TRANSMITIR. ............................................................................................. 24 4.5.6 MÁS FUNCIONES .................................................................................................................. 25 4.5.7 MÓDULOS PRO ..................................................................................................................... 30 4.5.8 DIGI EN ESPAÑA, LOGROÑO, LA RIOJA. ................................................................................ 30 4.5.9 LIBRERIA SERIAL. COMUNICACIONES PUERTO SERIE ........................................................... 31 17 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.5.10 4.6 CREACIÓN DE UN TIMELINE ................................................................................................. 32 GPS .......................................................................................................................................... 35 4.6.1 GPS GTPA 013 – BASADO EN MTK3339 - .............................................................................. 35 4.6.2 DETALLES TÉCNICOS ............................................................................................................. 37 4.6.3 DESCARGAS DE HOJAS TECNICAS DRIVERS Y SOFTWARE .................................................... 38 4.6.4 PROTOCOLO NMEA .............................................................................................................. 38 4.6.5 RECEPCIÓN E INTERCAMBIO DE DATOS DEL GPS ................................................................. 39 UTM COORDINADAS....................................................................................................................... 39 COORDENADAS GEOGRÁFICAS (LATITUD, LONGITUD) ................................................................. 40 4.7 ANEJOS NO IMPRESOS PRESENTADOS EN FORMATO DIGITAL ENLAZADO ............................... 40 4.7.1 CUADRO NACIONAL DE ATRIBUCIÓN DE FRECUENCIAS (CNAF) ........................................... 40 4.7.2 SOLUCIONES WIFI DE LARGO ALCANCE ................................................................................ 41 4.7.3 CONFIGURACIÓN CON VERSIÓN CLÁSICA ............................................................................ 41 4.7.4 CONFIGURACIÓN CON VERSIÓN ACTUALIZADA 2014 .......................................................... 44 4.8 IMPORTAR UNA LIBRERÍA PARA FRITZING ............................................................................... 48 4.9 LISTADO DE CODIGOS .............................................................................................................. 49 4.9.1 FUNCIONES BÁSICAS DE ARDUINO ....................................................................................... 49 4.9.1.1 LOCALIZAR LA IP DE MI ARDUINO – DHCP - .................................................................... 49 4.9.1.2 COMUNICACIÓN ARDUINO CON SERVIDORES LOCALES Y REMOTOS............................. 50 4.9.2 4.9.1.2.1 ALGUNOS RESULTADOS DE DIFERENTES CONEXIONES........................................... 51 4.9.1.2.2 LECTURAS BÁSICAS Y CONVERSIONES EN ARDUINO ETHERNET ............................. 52 FUNCIONES BÁSICAS DE PROCESSING .................................................................................. 58 4.9.2.1 CONSOLA 1...................................................................................................................... 58 4.9.2.1.1 VARIABLES DE CONFIGURACIÓN ............................................................................. 58 4.9.2.1.2 PARTE DE LA FUNCIÓN MAIN .................................................................................. 59 4.9.2.1.3 FUNCIONES PARA DIBUJAR FONDOS Y REJILLAS ..................................................... 59 4.9.2.2 CONSOLA PRINCIPAL ....................................................................................................... 64 4.9.2.2.1 DECLARACIÓN DE VARIABLES Y CONFIGURACIONES .............................................. 64 4.9.2.2.2 ALGUNAS FUNCIONES DEL SISTEMA ....................................................................... 65 4.9.2.2.3 OTRAS FUNCIONES COMPARITDAS ENTRE APLICACIONES ..................................... 73 4.9.2.3 CONSOLA GPS ................................................................................................................. 76 4.9.2.3.1 CONFIGURACION PRINCIPAL DE LA CONSOLA GPS ................................................. 76 18 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 4.9.2.3.2 CONFIGURACIÓN 2 DE LA CONSOLA GPS – SETUP – ............................................... 77 4.9.2.3.3 FUNCION PARA EL CAMBIO DE PROVEEDOR DE MAPAS ........................................ 78 4.9.2.3.4 PARTE DEL BUCLE DE LA FUNCIÓN MAIN ............................................................... 78 4.9.2.3.5 FUNCIONES LLAMADAS EN CONSOLA GPS.............................................................. 80 4.9.3 FUNCIONES BÁSICAS DE LA APLICACIÓN WEB ..................................................................... 85 4.9.3.1 BOOSTRAP DE TWITTER MODIFICADO............................................................................ 85 4.9.3.2 DESARROLLOS EN PHP – MYSQL - HTML......................................................................... 85 4.9.3.2.1 HACER UN GET EXTERNO PARA INSERCCIÓN ......................................................... 85 4.9.3.2.2 BORRAR UN DATO EN UNA BASE DE DATOS ........................................................... 86 4.9.3.2.3 BORRAR TODA UNA BASE DE DATOS ...................................................................... 87 4.9.3.2.4 CREAR UNA BASE DE DATOS DE PRUEBA ................................................................ 87 4.9.3.2.5 INSERTAR UN DATO EN HTML POR GET .................................................................. 88 4.9.3.2.6 BORRAR UN DATO MEDIANTE FORMULARIO ......................................................... 88 4.9.3.2.7 SACA POR PANTALLA EL VALOR DE LA TEMPERATURA ........................................... 89 4.9.3.2.8 MOSTRAR LA BASE DE DATOS ................................................................................. 89 4.10 PENDIENTE .......................................................................................................................... 91 4.11 OPEN SOURCE Y CREATIVE COMMONS................................................................................ 93 4.11.1 OPEN HARDWARE ................................................................................................................ 93 5. PLIEGO DE CONDICIONES .................................................................... 3 5.1 PLIEGO DE CONDICIONES GENERAL ........................................................................................... 4 5.1.1 PLIEGO DE CONDICIONES LEGALES ........................................................................................ 4 5.1.2 CONDICIONES GENERALES ..................................................................................................... 4 5.1.3 CONDICIONES PARTICULARES. ............................................................................................... 8 5.1.4 SEGURIDAD Y CONFIDENCIALIDAD ..................................................................................... 10 5.2 NORMAS LEYES Y REGLAMENTOS ............................................................................................ 11 5.3 PROPIEDAD INTELECTUAL DEL SOFTWARE. .............................................................................. 12 5.3.1 5.4 COMPETENCIAS REFERIDAS A LA PROGRAMACIÓN ............................................................. 12 PLIEGO DE CONDICIONES PARA EL TRATAMIENTO ESTANDARIZADO DE LOS DATOS ............... 18 5.4.1 SEMÁNTICA Y LINKED DATA ................................................................................................. 18 5.4.2 REUTILIZACIÓN DE INFORMACIÓN ....................................................................................... 19 19 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.4.3 JUSTIFICACIÓN Y ENFOQUE ................................................................................................ 19 5.4.4 ALCANCE Y OBJETIVOS ...................................................................................................... 20 5.4.5 CLASIFICACIÓN Y SEGUIMIENTO DE LOS SERVICIOS ELECTRÓNICOS .............................. 20 5.4.6 DATOS ENLAZADOS ............................................................................................................. 21 5.4.7 FACILIDAD AL USUARIO Y MULTICANALIDAD .................................................................. 22 5.4.8 REQUISITOS TÉCNICOS....................................................................................................... 22 5.4.9 PLATAFORMA CLIENTE ........................................................................................................ 23 5.4.10 LISTADO DE NAVEGADORES EN DIFERENTES VERSIONES Y SU COMPATIBILIDAD ............... 24 5.4.11 PERFILES Y PERSONAS ....................................................................................................... 27 5.4.12 CONSULTOR SEMÁNTICO .................................................................................................... 27 5.4.13 ANALISTA FUNCIONAL ......................................................................................................... 27 5.4.14 PROGRAMADOR ................................................................................................................... 27 5.4.15 EXPERTO EN A RQUITECTURA DE LA INFORMACIÓN ....................................................... 27 5.4.16 CONDICIONES DEL SERVICIO.............................................................................................. 28 5.4.17 REPOSITORIO DOCUMENTAL .............................................................................................. 28 5.4.18 PROPIEDAD INTELECTUAL, SEGURIDAD YCONFIDENCIALIDAD. ....................................... 28 5.5 PLIEGO DE CONDICIONES ADMINISTRATIVAS .......................................................................... 30 5.5.1 DOCUMENTACIÓN DEL PROYECTO....................................................................................... 30 5.5.2 CONDICIONES DE SEGURIDAD .............................................................................................. 31 5.5.3 SEGURIDAD Y PREVENCIÓN .................................................................................................. 32 5.5.4 NORMATIVA Y REGLAMENTACIÓN ....................................................................................... 33 5.5.5 ÁMBITO DE ACTUACIÓN ....................................................................................................... 35 5.6 PLIEGO DE CONDICIONES TÉCNICAS ......................................................................................... 36 5.6.1 VERIFICACIONES PREVIAS ..................................................................................................... 36 5.6.2 CONDICIONES GENERALES DE LOS MATERIALES .................................................................. 37 5.6.3 COMPONENTES ELECTRÓNICOS ......................................................................................... 37 5.6.4 SENSORES ............................................................................................................................. 37 5.6.5 MATERIAL DE LOS CABLES .................................................................................................... 39 5.6.6 CARACTERÍSTICAS DE LOS SERVICIOS CIVIL .......................................................................... 39 5.6.7 ENSAMBLADO E INTERCONEXIONADO DE LOS DISTINTOS ELEMENTOS.............................. 39 5.6.8 TEST DE VALIDACIÓN DE DATOS........................................................................................... 39 5.6.8.1 VARIABLES. 5.6.9 VALIDACIÓN DE LA COHERENCIA INTERNA DE LOS DATOS. RELACIONES ENTRE 41 PUESTA EN MARCHA Y MANTENIMIENTO ........................................................................... 41 20 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.6.10 PRECAUCIONES DE USO........................................................................................................ 42 5.6.11 PLIEGO DE CONDICIONES ECONÓMICAS .............................................................................. 42 5.6.11.1 DERECHOS Y DEBERES DEL CONTRATISTA .................................................................... 42 5.6.11.2 DERECHOS ..................................................................................................................... 43 5.6.11.3 DEBERES ........................................................................................................................ 44 5.6.12 DERECHOS Y DEBERES DEL CONTRATANTE .......................................................................... 44 5.6.13 DERECHOS ............................................................................................................................ 44 5.6.14 DEBERES ............................................................................................................................... 44 5.6.15 FORMALIZACIÓN DEL CONTRATO ........................................................................................ 45 5.6.16 EXTINCIÓN DEL CONTRATO .................................................................................................. 45 5.6.17 PLAZOS DE EJECUCIÓN ......................................................................................................... 46 5.6.18 FORMA DE PAGO .................................................................................................................. 46 5.6.19 FIANZA .................................................................................................................................. 47 5.6.20 GARANTÍAS Y PLAZOS DE GARANTÍA .................................................................................... 48 5.7 CALIDAD .................................................................................................................................. 49 5.7.1 5.8 NORMAS DE CALIDAD........................................................................................................... 50 CONCEPTOS COMPRENDIDOS .................................................................................................. 51 5.8.1 CONCEPTOS NO COMPRENDIDOS ........................................................................................ 53 5.8.2 INTERPRETACIÓN DEL PROYECTO ........................................................................................ 54 5.8.3 COORDINACIÓN DEL PROYECTO........................................................................................... 54 5.8.4 MODIFICACIONES AL PROYECTO .......................................................................................... 55 5.8.5 REGLAMENTACIÓN DE OBLIGADO CUMPLIMIENTO ............................................................ 55 5.8.6 DOCUMENTACIÓN GRÁFICA ................................................................................................. 56 5.8.7 DOCUMENTACIÓN FINAL DE OBRA ...................................................................................... 56 5.9 PLIEGO DE CONDICIONES PARA ESTANDARES DEL SOFTWARE ................................................. 58 5.9.1 PLAN DE ASEGURAMIENTO DE LA CALIDAD IEEE STD 730-2002 .......................................... 58 5.9.1.1 LA CALIDAD EN INGENIERÍA DEL SOFTWARE .................................................................. 58 5.9.1.2 DEFINICIÓN DE LA CALIDAD DEL SOFTWARE .................................................................. 59 5.9.1.3 EL MODELO SPICE ........................................................................................................... 60 5.9.1.4 DESCRIPCIÓN DE LOS REQUISITOS DEL SOFTWARE (SRD) .............................................. 61 5.9.1.5 DOCUMENTACIÓN DEL USUARIO ................................................................................... 61 5.9.1.6 PLAN DE GESTIÓN DE CONFIGURACIÓN DEL SOFTWARE (SCMP)................................... 62 5.9.1.7 VERSIONES DEL SOFTWARE ............................................................................................ 62 21 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.1.8 BIBLIOTECA DE SOFTWARE ............................................................................................. 62 5.9.1.9 CONTROL DE LA CONFIGURACIÓN DEL SOFTWARE ........................................................ 62 5.9.2 ESPECIFICACIÓN DE LOS REQUISITOS SOFTWARE IEEE 830 – 1998 ..................................... 63 5.9.2.1 CABE DESTACAR: ............................................................................................................. 63 5.9.2.2 REFERENCIAS .................................................................................................................. 64 5.9.2.3 ELABORACIÓN DE LOS PERFILES DE USUARIO ................................................................ 65 5.9.2.4 FIABILIDAD ...................................................................................................................... 65 5.9.2.5 USABILIDAD..................................................................................................................... 65 5.9.2.6 SEGURIDAD ..................................................................................................................... 66 5.9.2.7 MANTENIMIENTO ........................................................................................................... 66 5.9.2.8 PORTABILIDAD ................................................................................................................ 66 5.9.3 DESCRIPCIONES DEL DISEÑO DE SOFTWARE IEEE STD 1016 – 2009 .................................... 66 5.9.3.1 ÁMBITO DE APLICACIÓN ................................................................................................. 67 5.9.3.2 PROPÓSITO ..................................................................................................................... 67 5.9.4 FUNDAMENTOS DE LAS PRUEBAS. ADAPTADO DEL ESTÁNDAR IEEE 729 ............................ 67 5.9.4.1 INTRODUCCIÓN ............................................................................................................... 67 5.9.4.2 PRUEBAS DE ACEPTACIÓN .............................................................................................. 69 5.9.4.3 ERRORES VS FALLOS ........................................................................................................ 69 5.9.4.4 CRITERIOS PARA DAR POR FINALIZADAS LAS PRUEBAS .................................................. 69 5.9.4.5 REALIZAR PRUEBAS PARA LA IDENTIFICACIÓN DE DEFECTOS......................................... 69 5.9.4.5.1 PRUEBAS VS DEPURACIÓN ..................................................................................... 70 5.9.4.5.2 PRUEBAS Y CERTIFICACIÓN .................................................................................... 70 5.9.4.6 CONCLUSIONES ............................................................................................................... 71 5.9.4.7 PRUEBAS DE SISTEMA ..................................................................................................... 71 5.9.4.8 PRUEBAS DE INSTALACIÓN ............................................................................................. 72 5.9.4.9 PRUEBAS ALFA Y BETA .................................................................................................... 73 5.9.4.10 PRUEBAS DE RENDIMIENTO.......................................................................................... 74 5.9.4.11 PRUEBAS DE CONFIGURACIÓN ..................................................................................... 75 5.9.4.12 PRUEBAS DE FACILIDAD DE USO ................................................................................... 75 5.9.4.13 ANÁLISIS DE LOS VALORES LÍMITE ................................................................................ 75 5.9.4.14 PRUEBAS ORIENTADAS A LA CONFIABILIDAD DEL SOFTWARE ..................................... 76 5.9.4.15 BASADAS EN COMPONENTES ....................................................................................... 76 5.9.4.16 PRUEBAS PARA INTERNET ............................................................................................. 77 5.9.4.17 LAS ESTRATEGIAS DE EVALUACIÓN............................................................................... 77 5.9.4.18 PRUEBAS PARA GUI ....................................................................................................... 78 22 Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado 5.9.4.19 5.9.5 GUÍAS PARA LAS PRUEBAS ............................................................................................ 79 ESTÁNDARES ......................................................................................................................... 81 5.10 ERRORES EN EL PROYECTO .................................................................................................. 83 5.11 LIQUIDACIÓN ...................................................................................................................... 83 5.12 DISPOSICIÓN FINAL ............................................................................................................. 83 6. PRESUPUESTO ....................................................................................... 2 6.1 INTRODUCCIÓN ......................................................................................................................... 2 6.2 ESTADO DE MEDICIONES............................................................................................................ 4 6.3 LISTA DE PRECIOS....................................................................................................................... 6 6.4 LISTA DE MATERIAL.................................................................................................................... 9 6.4.1 PLACAS, ARDUINOS Y COMPONENTES ................................................................................. 10 6.4.2 LICENCIAS EN EL SOFTWARE ................................................................................................ 11 6.4.3 LISTADO DE MATERIAL RELATIVO AL VUELO ........................................................................ 13 6.5 RESUMEN DEL PRESUPUESTO. ................................................................................................. 14 6.6 PRECIO PARA VENTA COMO PACK ........................................................................................... 15 6.7 PRECIO PARA ALQUILER ........................................................................................................... 15 6.8 PRESENTACIÓN A CONCURSOS PUBLICOS. RÉGIMEN CONCURSAL ........................................... 16 7. ESTUDIOS CON ENTIDAD PROPIA........................................................ 3 7.1 MARCO NORMATIVO BÁSICO SOBRE SEGURIDAD Y SALUD ....................................................... 4 7.2 PROYECTOS SOMETIDOS A EVALUACIÓN DE IMPACTO AMBIENTAL .......................................... 6 23
