supervisión remota de parámetros medioambientales capturados

Eduardo Garbayo Herce

Montserrat Gil Martínez y Javier Rico Azagra

Escuela Técnica Superior de Ingeniería Industrial

Proyecto Fin de Carrera

Ingeniería Eléctrica

2013-2014

Título

Director/es

Facultad

Titulación

Departamento

PROYECTO FIN DE CARRERA

Curso Académico

Supervisión remota de parámetros medioambientalescapturados por vehículo aéreo no tripulado

Autor/es

© El autor© Universidad de La Rioja, Servicio de Publicaciones, 2014

publicaciones.unirioja.esE-mail: [email protected]

Supervisión remota de parámetros medioambientales capturados por vehículoaé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.

Supervisión remota de parámetros medioambientales capturados por vehículo aéreo no tripulado

1

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


2


3

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

https://www.boe.es/diario_boe/txt.php?id=BOE-A-2007-20618


4

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.


5

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.

Que por defecto no forman parte de la UNE 157801: 20071, 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/


6

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.


7

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.


8

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


1

PROYECTO FIN DE CARRERA: “SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV”

DOCUMENTO Nº1:

MEMORIA DESCRIPTIVA







2


3

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.2.2.1 QUÉ ES ARDUINO Y SUS ALTERNATIVAS: ........................................................................ 24

1.2.2.2 VEHÍCULO AÉREO NO TRIPULADO UAV. DRONE. ............................................................ 25

1.3 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 OTROS SENSORES............................................................................................................ 47

1.7 NUEVO PARADIGMA ................................................................................................................ 48


4

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


5

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 COMPATIBILIDAD Y RELACION ENTRE DICHOS DOCUMENTOS .......................................... 120

1.16 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 NORMAS PARA CONSULTA ................................................................................................. 128

1.19 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


6

3. ESPECIFICACIONES DEL SISTEMA ...................................................... 3

3.1 CONFIGURACIONES BÁSICAS ..................................................................................................... 3

3.2 CONFIGURACIÓN PUESTA EN MARCHA DEL DRONE ................................................................... 3

3.2.1 SOFTWARE DE CONFIGURACION ............................................................................................ 7

3.3 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 CONFIGURACIÓN DEL ROUTER ..................................................................................... 21

3.4 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 DESDE PHP ............................................................................................................................ 29

3.6 INSTALACIÓN DE SENSORES ..................................................................................................... 31

3.6.1 ENTRADAS. SALIDAS PVM. .................................................................................................... 31


7

3.6.2 POTENCIOMETRO ................................................................................................................. 33

3.6.2.1 CODIGO BÁSICO EN ARDUINO PARA UN POTENCIOMETRO ........................................... 34

3.6.3 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 OTROS SENSORES ................................................................................................................. 54

3.7 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


8

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


9

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 PATILLAJE ........................................................................................................................ 18

4.5 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


10

4.5.10 CREACIÓN DE UN TIMELINE ................................................................................................. 32

4.6 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.1.2.1 ALGUNOS RESULTADOS DE DIFERENTES CONEXIONES ........................................... 51

4.9.1.2.2 LECTURAS BÁSICAS Y CONVERSIONES EN ARDUINO ETHERNET ............................. 52

4.9.2 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


11

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 COMPETENCIAS REFERIDAS A LA PROGRAMACIÓN ............................................................. 12

5.4 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


12

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 VALIDACIÓN DE LA COHERENCIA INTERNA DE LOS DATOS. RELACIONES ENTRE

VARIABLES. 41

5.6.9 PUESTA EN MARCHA Y MANTENIMIENTO ........................................................................... 41


13

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 NORMAS DE CALIDAD ........................................................................................................... 50

5.8 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


14

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


15

5.9.4.19 GUÍAS PARA LAS PRUEBAS ............................................................................................ 79

5.9.5 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


16

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).


17

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.


18

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.


19

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.


20

Sirva el siguiente diagrama explicativo del proceso:


21

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 y

transformados en su integridad.

2 La Licencia Pública General de GNU


22

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.


23

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:


24

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 , etc. También existen proyectos similares ya dentro 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,


25

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


26

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


27

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.


28

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).


29

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 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.

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


30

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.


31

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.


32

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:

Arduino Hardware

6 Linux Apache MySQL PhP


33

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 OS8 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


34

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


35

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


36

Certificaciones

Vigilancia ferrocarril. Grafitis, mediante el uso de 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 de riego, 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


37

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

http://www.zainder.com/


38

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 JS10 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.

http://cdn.knightlab.com/libs/timeline/latest/embed/index.html?source=0AoJpgz3fNbY4dFItVTE4Y2x0MkdUQTN4YkFwZWZOWnc&font=Bevan-PotanoSans&maptype=toner&lang=es&height=650


39



40

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 15-

20 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



41

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.


42

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-


43

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


44

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 VPS11 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. Por ello la

11 virtual private server


45

selección de un VPS que permite mediante su plesk12 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 -


46

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


47

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.


48

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


49

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.


50

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 Una misma variable puede tomar valores de distinto tipo en distintos momento

14 Construcción de aplicaciones más potentes basadas en plantillas y datos previos.

Andamiaje.

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_de_prop%C3%B3sito_general

http://es.wikipedia.org/wiki/Script_del_lado_del_servidor

http://es.wikipedia.org/wiki/Script_del_lado_del_servidor

http://es.wikipedia.org/wiki/Desarrollo_web

http://es.wikipedia.org/wiki/Desarrollo_web

http://es.wikipedia.org/wiki/Contenido_din%C3%A1mico

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_interpretado

http://es.wikipedia.org/wiki/Tipado_din%C3%A1mico

http://es.wikipedia.org/wiki/Multiplataforma

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n


51

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..


52

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


53

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.


54

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.


55

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


56

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.

http://zigbee.org/


57

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.


58

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 standalone18 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


59

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.


60

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


61

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 checksum20 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


62

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.


63

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


64

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.


65

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


66

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.


67

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


68

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.


69

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”.


70

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


71

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.


72

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.


73

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


74

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 SDK23). 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.


75

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.


76

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.


77

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.


78

Ilustración 19 Desde otro proveedor de mapas. Físicos y Topográficos.


79

Ilustración 20 Proveedor Microsoft. Mapa Físico urbano.

Se ve una captura de datos por los sensores y geoposicionados.


80

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 Matlab26 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

https://www.mathworks.es/store/link/products/standard/new?s_iid=htb_buy_gtwy_cta1


81

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


82

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


83

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


84

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


85

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.


86

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


87

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)


88

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


89

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.


90

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 canvas30, 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

Se usará un software externo para la configuración de la cámara.

30 Canvas, lienzo. Elemento HTML5 que permite generación de gráficos dinámicamente por

scripting

31 Application PacKage


91

Se instalará una aplicación modificada web OS de Github32 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/

http://eduardogarbayo.com/streaming-con-gopro-hero3-via-wifi-en-linux-ubuntu/


92

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


93

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% RPW34. 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.


94

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.


95

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.

Diagrama: Flujo de Datos, Tipo de datos.

Por un lado están los datos en sí mismos, luego está el medio por donde

fluyen, y su formato de transporte.

F

l

u

j

o

d

e

d

a

t

o

s

Tipo de Datos

Flujo de Datos


96

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):

http://es.wikipedia.org/wiki/Filosof%C3%ADa

http://es.wikipedia.org/wiki/Derechos_de_autor

http://es.wikipedia.org/wiki/Patente

http://es.wikipedia.org/wiki/Software_libre

http://es.wikipedia.org/wiki/C%C3%B3digo_abierto

http://es.wikipedia.org/wiki/Acceso_abierto

http://es.wikipedia.org/w/index.php?title=Archivo_Nacional_del_Reino_Unido&action=edit&redlink=1


97

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.


98

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

http://www.larioja.org/datoabierto

http://www.iderioja.larioja.org/

http://datos.gob.es/content/licencias-de-uso-asociadas-iniciativas-de-datos-abiertos-espana

http://datos.gob.es/content/rioja-apuesta-apertura-de-datos-publicos


99

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.

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,

Datos estructurados.


100

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.


101

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.


102

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.


103

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


104

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.


105

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)


106

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.


107

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,


108

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.


109

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.


110

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.


111

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.


112

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/

http://mobilehtml5.org/


113

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.


114

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.


115

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.


116

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


117

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.


118

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.


119

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.


120

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://www.processing.org/

http://www.w3schools.com/

http://es.wikipedia.org/

http://www.aeromodelismovirtual.com/

http://www.aeromodelismofacil.com/

http://www.aenor.es

https://php.net/manual/es/

http://unfoldingmaps.org/

http://www.larioja.org/

http://www.phpmyadmin.net/

http://www.dji.com/

http://www.multicopters.es/

http://www.sojamo.de/

http://es.wikipedia.org/

http://www.dji.com/


121

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


122

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ó

http://es.wikipedia.org/wiki/Radio_digital

http://es.wikipedia.org/wiki/Radio_digital

http://es.wikipedia.org/wiki/Norma_(tecnolog%C3%ADa)

http://es.wikipedia.org/wiki/IEEE_802.15.4


123

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.

http://es.wikipedia.org/wiki/Desarrollo_de_software

http://es.wikipedia.org/wiki/Software

http://es.wikipedia.org/wiki/Programa_(computaci%C3%B3n)

http://es.wikipedia.org/wiki/Biblioteca_(programaci%C3%B3n)

http://es.wikipedia.org/wiki/Lenguaje_interpretado


124

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.

http://es.wikipedia.org/wiki/Programa_inform%C3%A1tico

http://es.wikipedia.org/w/index.php?title=Automatizaci%C3%B3n_de_dise%C3%B1o_electr%C3%B3nico&action=edit&redlink=1

http://es.wikipedia.org/wiki/Software_libre

http://es.wikipedia.org/wiki/Placa_de_pruebas

http://es.wikipedia.org/wiki/Processing

http://es.wikipedia.org/wiki/Arduino

http://es.wikipedia.org/wiki/China

http://es.wikipedia.org/wiki/GNSS

http://es.wikipedia.org/wiki/Osa_Mayor


125

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 escritor italiano) 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. 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

http://es.wikipedia.org/wiki/Advanced_Audio_Coding

http://es.wikipedia.org/wiki/Application_Programming_Interface

http://es.wikipedia.org/wiki/Multiplataforma

http://es.wikipedia.org/wiki/Computaci%C3%B3n_gr%C3%A1fica_2D

http://es.wikipedia.org/wiki/Gr%C3%A1ficos_3D_por_computadora

http://es.wikipedia.org/wiki/Girolamo_Cardano

http://es.wikipedia.org/wiki/Suspensi%C3%B3n_(autom%C3%B3vil)

http://es.wikipedia.org/wiki/%C3%81ngulo_recto


126

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,

http://es.wikipedia.org/wiki/Lengua_inglesa

http://es.wikipedia.org/wiki/World_Wide_Web_Consortium

http://es.wikipedia.org/wiki/World_Wide_Web_Consortium

http://es.wikipedia.org/wiki/Modelo_de_datos

http://es.wikipedia.org/wiki/Modelo_de_datos

http://es.wikipedia.org/wiki/Metadato


127

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)


128

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


129

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


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


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


Calculators ISO/IEC 2382-13:1996- Information technology -- Vocabulary

-- Part 13: Computer graphics


Reliability, maintainability and availability


Programming languages


Information theory ISO/IEC 2382-17:1999- Information technology --

Vocabulary -- Part 17: Databases


130


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


Computer- integrated manufacturing


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 -- Vocabulary -- Part 28: Artificial

ISO/IEC 2382-29:1999- Information technology intelligence -- Speech

recognition and synthesis -- Vocabulary -- Part 29: Artificial

ISO/IEC 2382-31:1997- Information technology intelligence -- Machine

learning -- Vocabulary Part 31: Artificial


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


131

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

Dictionary System (IRDS) framework

ISO/IEC 10728:1993- Information technology -- Information Resource

Dictionary System (IRDS) Services Interface

ISO/IEC 10746-1:1998- Information technology -- Open

Distributed Processing -- Reference model: Overview

ISO/IEC 10746-2:1996- Information technology -- Open Distributed

Processing -- Reference Model: Foundations


Distributed Processing -- Reference Model: Architecture


132


Distributed Processing -- Reference Model: 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


Process for developers


133


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


Protocol support for computational interactions


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


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


134

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


assessment -- Part 2: A reference model for processes and process capability


assessment -- Part 3: Performing an assessment


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


assessment -- Part 6: Guide to competency of assessors


135


assessment -- Part 7: Guide for use in process improvement


assessment -- Part 8: Guide for use in determining supplier process capability


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 Software engineering -- IFPUG 4.1

Unadjusted functional size measurement method -- 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


136

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)


137

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


138

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


139

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


140

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


141

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


142

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








143

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


144

Ilustración 167 Compatibilidad Navegadores ................................................. 24




Ilustración 171 división de los temas para el KA de las Pruebas de Software68


145

“SUPERVISIÓN REMOTA DE PARÁMETROS MEDIOAMBIENTALES CAPTURADOS POR UAV”

FIN DE DOCUMENTO: MEMORIA




146


1

PROYECTO FIN DE CARRERA:


DOCUMENTO Nº2: PLANOS







2


3

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

http://es.wikipedia.org/wiki/Processing

http://es.wikipedia.org/wiki/Arduino


4

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


SENSOR LM35


POTENCIOMETRO


SISTEMA INALAMBRICO XBEE


GPS GTPA 013


GPS GTPA 013 + LM 35


LDR + LM35 + XBEE + GPS + ARDUINO ETHERNET


POTENCIOMETRO + GPS + XBEE + ARDUINO


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

UR - PFC - Supervisión remota de parámetros medioambientales

capturados por UAV

DIBUJADO 20/05/2014 Eduardo Garbayo Herce

COMPROBADO 03/07/2014 Eduardo Garbayo Herce

GRUPO PFC – ARD – UAD - 0001 ESCALA

DENOMINACIÓN DEL PLANO: Chequeo del Sistema. Baterías, Puerto, Sensor, entradas y salidas. Setup.

PLANO Nº

1

2.3 SONDA DE TEMPERATURA NTC



Parte1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3)

R1 10k Ω Resistor paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio

entre pines 400 mil

R2 Temperature Sensor

(Thermistor)

resistance at 25° 10kΩ; paquete THT; thermistor type NTC; Tipo

thermistor



1 Arduino Uno (Rev3) Tipo Arduino UNO (Rev3)

1 10k Ω Resistor paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio

entre pines 400 mil

1 Temperature Sensor

(Thermistor)

resistance at 25° 10kΩ; paquete THT; thermistor type NTC; Tipo

thermistor



capturados por UAV




DENOMINACIÓN DEL PLANO: Sonda de Temperatura NTC. PLANO Nº

2

2.4 SENSOR LDR



Parte1 Arduino Board

Ethernet Tipo Arduino Ethernet Board

R1 Photocell (LDR) paquete THT; resistance@ dark 300 kOhms@ 10 seconds; resistance@

luminance 16 kOhms@ 10 lux

R2 10k Ω Resistor paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio entre pines

400 mil




1 Arduino Board

Ethernet Tipo Arduino Ethernet Board

1 Photocell (LDR) paquete THT; resistance@ dark 300 kOhms@ 10 seconds; resistance@


1 10k Ω Resistor paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio entre pines

400 mil




capturados por UAV




DENOMINACIÓN DEL PLANO: Sensor LDR en Arduino Uno PLANO Nº

3

2.5 SENSOR LM35




T1 LM35 Temperature Sensor paquete TO92 [THT]; Tipo LM35





1 LM35 Temperature Sensor paquete TO92 [THT]; Tipo LM35




capturados por UAV




DENOMINACIÓN DEL PLANO: Sensor LM35 de temperatura en Arduino Uno. PLANO Nº

4

2.6 POTENCIOMETRO




U1 POT paquete pot_alpha_rv16af-20; variant -rv16af-20





1 POT paquete pot_alpha_rv16af-20; variant -rv16af-20


FECHA NOMBRE Y A PELLIDOS


capturados por UAV




DENOMINACIÓN DEL PLANO: Potenciometro en Arduino Ethernet PLANO Nº

5

2.7 SISTEMA INALAMBRICO XBEE




U1 XBEE-1 paquete xbee-1_lock; variant xbee-1_lock





1 XBEE-1 paquete xbee-1_lock; variant xbee-1_lock




capturados por UAV




DENOMINACIÓN DEL PLANO: Xbee en Arduino Ethernet PLANO Nº

6

2.8 GPS GTPA 013



GPS1 Adafruit Ultimate GPS Breakout





1 Adafruit Ultimate GPS Breakout

1 Arduino Uno (Rev3 Tipo Arduino UNO (Rev3)




capturados por UAV




DENOMINACIÓN DEL PLANO: GTPA 013. Instalación GPS PLANO Nº

7

2.9 GPS GTPA 013 + LM 35





T1 LM35 Temperature Sensor paquete TO92 [THT]; Tipo LM35






1 LM35 Temperature Sensor paquete TO92 [THT]; Tipo LM35




capturados por UAV




DENOMINACIÓN DEL PLANO: GTPA 013 + LM 35 PLANO Nº

8



capturados por UAV




DENOMINACIÓN DEL PLANO: GTPA 013. + LM 35 PLANO Nº

8.1

2.10 LDR + LM35 + XBEE + GPS + ARDUINO ETHERNET



GPS1 Adafruit Ultimate GPS

Breakout


R3 10k Ω Resistor paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio entre

pines 400 mil

R4 Photocell (LDR) paquete THT; resistance@ dark 300 kOhms@ 10 seconds; resistance@


T1 LM35 Temperature

Sensor paquete TO92 [THT]; Tipo LM35





1 Adafruit Ultimate GPS

Breakout


1 10k Ω Resistor paquete THT; tolerance ±5%; bands 4; Resistencia 10kΩ; espacio entre

pines 400 mil

1 Photocell (LDR) paquete THT; resistance@ dark 300 kOhms@ 10 seconds;

resistance@ luminance 16 kOhms@ 10 lux

1 LM35 Temperature

Sensor paquete TO92 [THT]; Tipo LM35



capturados por UAV




DENOMINACIÓN DEL PLANO: GPS + LDR + LM35 + XBee PLANO Nº

9



capturados por UAV




DENOMINACIÓN DEL PLANO: GPS + LDR + LM35 + XBee PLANO Nº

9.1

2.11 POTENCIOMETRO + GPS + XBEE + ARDUINO






U3 POT paquete pot_alpha_rv16af-20; variant -rv16af-20







1 POT paquete pot_alpha_rv16af-20; variant -rv16af-20




capturados por UAV




DENOMINACIÓN DEL PLANO: GPS + XBee + Potenciometro PLANO Nº

10



capturados por UAV




DENOMINACIÓN DEL PLANO: GPS + XBee + Potenciometro PLANO Nº

10.1


1


2


FIN DE DOCUMENTO: PLANOS




3


1


DOCUMENTO Nº3: ESPECIFICACIONES DEL

SISTEMA







2


3

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


4

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


5

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


6

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.


7

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


8

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.


9

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/


10

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.


11

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


12

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

http://www.ftdichip.com/Drivers/VCP.htm


13

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.


14

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


15

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.


16

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.


17

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


18

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.


19

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


20

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.

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.

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 )

http://zainder.com/arduino/arduino.txt


21

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.

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"); }


22

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.


23

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,


24

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


25

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.

https://www.apachefriends.org/es/index.html


26

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 :

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.

mysql_query("INSERT INTO $tabla_BD ($campo1 ,$campo2, $campo3) VALUES ('$_GET[temperatura_desde_formulario]' , now() , curtime() ) " , $conecta );

http://localhost/scripts/envio%20datos%20a%20sql%20por%20formulario/

http://localhost/scripts/envio%20datos%20a%20sql%20por%20formulario/arduino-get.php?temperatura_desde_formulario=5544&ingresar_dato=Submit


27

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.

<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>


28

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


29

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

http://www.phpclasses.org/browse/file/17926.html


30

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; ?>


31

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.


32

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


33

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.


34

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); }


35

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


36

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


37

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

http://es.wikipedia.org/wiki/Divisor_de_tensi%C3%B3n

http://en.wikipedia.org/wiki/Steinhart-Hart_equation


38

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

http://www.skyeinstruments.com/wp-content/uploads/Steinhart-Hart-Eqn-for-10k-Thermistors.pdf


39

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


40

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);}


41

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

http://arduino.cc/documents/datasheets/LDR-VT90N2.pdf


42

//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


43

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

http://arduino.cc/es/Reference/Constrain


44

Ilustración 70 LDR en Arduino Ethernet


45

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


46

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.

*/


47

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.


48

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


49

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


50

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 :(


51

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;


52

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 [4] = grados_Longitud; buffer [5] = parteI; buffer [6] = parteJ; buffer [7] = 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


53

degMin = (int) ( degMin / 100 ); decDeg = degMin + ( min / 60 ); return decDeg;}


54

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.


55

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.


56

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


57

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

// 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");}


58

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


59

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:


60

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


61

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

http://unfoldingmaps.org/tutorials/getting-started-in-processing.html


62

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


63

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


64

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.


65

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 punto-

a-punto, punto-a-multipunto o peer-to-peer.


66

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.


67

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.


68

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


69

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


70

Ilustración 86 Versión clásica

3.8.5 HARDWARE

Ilustración 87 Xbee Hard


71

Ilustración 88 Xbee Asignación


72

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


73

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.


74

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:


75

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.


76

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


77

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


78

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


79

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


80

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.

http://arduino.cc/es/Hacking/LibraryTutorial


81

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.


82

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)


83

Grados Minutos.m a Grados Decimal .d = M.m / 60

Grados Decimal = Grados + .d

Se crea una función en Arduino

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

// 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;

}


84

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:

http://es.wikipedia.org/wiki/Suspensi%C3%B3n_(autom%C3%B3vil)

http://es.wikipedia.org/wiki/%C3%81ngulo_recto


85

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


86

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.


87

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.


88

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).


89

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 Xt-

60(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.

http://www.nitroylitio.com/web/component/glossary/Diccionario-1/B/Brushless-4/


90

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.


91

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.


92

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.


93


FIN DE DOCUMENTO:

ESPECIFICACIONES DEL SISTEMA




94


1


DOCUMENTO Nº4: ANEJOS







2

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


3

Operating Voltage 5V

Input Voltage Plug (recommended) 7-12V

Input Voltage Plug (limits) 6-20V

Input Voltage PoE (limits) 36-57V

Digital I/O Pins 14 (of which 4 provide PWM output)

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 50 mA

Flash Memory 32 KB (ATmega328) of which 0.5 KB used by bootloader

SRAM 2 KB (ATmega328)

EEPROM 1 KB (ATmega328)

Clock Speed 16 MHz

W5100 TCP/IP Embedded Ethernet Controller

Power Over Ethernet ready Magnetic Jack

Micro SD card, with active voltage translators

Ilustración 102 Ardupilot


4

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

http://arduino.cc/es/main/software


5

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


6

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.

https://www.dropbox.com/s/g6uvfpdf352s7qy/rxtxSerial-2.2_fixed_2009-03-17.rar


7

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

http://www.micro4you.com/files/sensor/DHT11.pdf

https://github.com/adafruit/DHT-sensor-library


8

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


9

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); }

http://www.seeedstudio.com/depot/datasheet/MQ-2.pdf


10

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

https://www.sparkfun.com/datasheets/Sensors/MQ-3.pdf

http://www.pololu.com/file/0J311/MQ4.pdf


11


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


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); }

http://seeedstudio.com/wiki/images/c/ce/MQ-5.pdf

https://www.sparkfun.com/datasheets/Sensors/Biometric/MQ-6.pdf

http://thesis.jmsaavedra.com/prototypes/software/mq-7-breakout-arduino-library/

https://www.sparkfun.com/datasheets/Sensors/Biometric/MQ-7.pdf


12

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.


Código Arduino int sensorValue; void setup() { Serial.begin(9600); // sets the serial port to 9600 }

https://dlnmh9ip6v2uc.cloudfront.net/datasheets/Sensors/Biometric/MQ-8.pdf

http://www.pololu.com/file/download/MQ9.pdf?file_id=0J314

http://www.sensorsportal.com/DOWNLOADS/MQ131.pdf

http://china-total.com/Product/meter/gas-sensor/MQ135.pdf


13

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.13 MQ136

Sensitivo para Sulfuro de Hidrógeno


4.2.14 MQ137

Sensitivo para Amoniaco NH3.


4.2.15 MQ138

Sensitivo para Benceno, Tolueno. Alcohol, Acetona, Propano, Formaldeídos,

Hidrógeno.


4.2.16 MQ214

Sensitivo for Metano, Gas Natural.

Trabaja a 6V.


4.2.17 MQ216

Sensitivo para Gas Natural for Natural gas, Coal gas (de Hulla o Alumbrado)


4.2.18 MQ303A

Sensitivo para Alcohol, Etanol, humo. Similar al MQ3

http://china-total.com/Product/meter/gas-sensor/MQ136.pdf

particle-sensor.com/immagini/MQ-137.pdf

http://duckduckgo.com/?q=%22mq138%22+gas+sensor+filetype%3Apdf

http://www.clinchem.org/content/29/2/369.full.pdf

http://duckduckgo.com/?q=%22mq216%22+gas+sensor+filetype%3Apdf


14

The heater uses 0.9V

Características MQ303A

4.2.19 MQ306A

Sensitivo para LPG y Gas Butano


4.2.20 MQ307A

Sensitivo para Monóxido de Carbono


4.2.21 MQ309A

Sensitivo para Monóxido de Carbono y otros gases inflamables


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

http://duckduckgo.com/?q=%22mq303a%22+gas+sensor+filetype%3Apdf




http://duckduckgo.com/?q=%22mg811%22+gas+sensor+filetype%3Apdf

http://duckduckgo.com/?q=%22aq-104%22+gas+sensor+filetype%3Apdf



15

4.2.25 AQ-3

Sensitivo para Alcohol, Benceno


4.2.26 AQ-7

Sensitivo para Monóxido de Carbono


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

:%20http:/duckduckgo.com/?q=%22aq-3%22+gas+sensor+filetype%3Apdf



16

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


17

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


18

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º.

http://commons.wikimedia.org/wiki/File:Types-usb_new.svg

http://commons.wikimedia.org/wiki/File:Types-usb_new.svg


19

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.


20

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.


21

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

http://www.andresduarte.com/wp-content/uploads/2013/06/150x150xxbee_s1.png.pagespeed.ic_.b-AWfeD0Rz.png

http://www.andresduarte.com/wp-content/uploads/2013/06/150x150xxbee_s1.png.pagespeed.ic_.b-AWfeD0Rz.png

http://www.andresduarte.com/wp-content/uploads/2013/06/150x150xxbee_s2.jpg.pagespeed.ic_.6vIIg-GsLQ.jpg

http://www.andresduarte.com/wp-content/uploads/2013/06/150x150xxbee_s2.jpg.pagespeed.ic_.6vIIg-GsLQ.jpg


22

- 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


23

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

http://www.andresduarte.com/wp-content/uploads/2013/06/images.jpg

http://www.andresduarte.com/wp-content/uploads/2013/06/images.jpg


24

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.


25

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:


26

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:


27

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:


28

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


29

Ilustración 122 Usos ZigBee


30

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.


31

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()

http://www.processing.org/reference/libraries/serial/Serial.html

http://www.processing.org/reference/libraries/serial/Serial_readBytes_.html

http://www.processing.org/reference/libraries/serial/Serial_lastChar_.html

http://www.processing.org/reference/libraries/serial/Serial_available_.html

http://www.processing.org/reference/libraries/serial/Serial_readBytesUntil_.html

http://www.processing.org/reference/libraries/serial/Serial_buffer_.html

http://www.processing.org/reference/libraries/serial/Serial_read_.html

http://www.processing.org/reference/libraries/serial/Serial_readString_.html

http://www.processing.org/reference/libraries/serial/Serial_last_.html

http://www.processing.org/reference/libraries/serial/Serial_readChar_.html

http://www.processing.org/reference/libraries/serial/Serial_readStringUntil_.html

http://www.processing.org/reference/libraries/serial/Serial_bufferUntil_.html

http://www.processing.org/reference/libraries/serial/Serial_write_.html

http://www.processing.org/reference/libraries/serial/Serial_clear_.html

http://www.processing.org/reference/libraries/serial/Serial_stop_.html


32

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.


33

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.


34

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.


35

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.

http://copter.ardupilot.com/wiki/common-installing-3dr-ublox-gps-compass-module/?lang=es

http://letsmakerobots.com/content/getting-data-gps-module-gtpa010


36

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

http://www.raspberryshop.es/


37

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


38

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

http://www.adafruit.com/datasheets/PMTK_A08.pdf

http://www.adafruit.com/datasheets/PA6B-Datasheet-A07.pdf

http://www.adafruit.com/datasheets/PA6B-Datasheet-A07.pdf

http://www.adafruit.com/datasheets/GlobalTop-FGPMMOPA6C-Datasheet-V0A-Preliminary.pdf

http://www.adafruit.com/datasheets/GlobalTop-FGPMMOPA6C-Datasheet-V0A-Preliminary.pdf

http://www.adafruit.com/datasheets/GlobalTop-FGPMMOPA6H-Datasheet-V0A.pdf

http://www.adafruit.com/datasheets/GlobalTop-FGPMMOPA6H-Datasheet-V0A.pdf

http://www.adafruit.com/datasheets/GlobalTop%20MT3339%20PC%20Tool%20v1.3%20without%20F2.0&I3.1.rar

http://www.adafruit.com/datasheets/GlobalTop%20MT3339%20PC%20Tool%20Operation%20Manual%20v1.1.pdf

http://www.adafruit.com/datasheets/MiniGPS_Tool_1.7.1.zip


39

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.


40

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]

http://www.minetur.gob.es/telecomunicaciones/Espectro/Paginas/index.aspx

http://www.minetur.gob.es/telecomunicaciones/Espectro/Paginas/index.aspx


41

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.

https://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCIQFjAA&url=http%3A%2F%2Fwww.ure.es%2Fdescargas%2Fdoc_download%2F303-plan-de-bandas.html&ei=qb-7U7rSMKmH0AXS_oDoDQ&usg=AFQjCNF-yaJCRMtftinZXwJCd1lAbZ_y-g&sig2=hi9Y_c25TjLpFZvGwkGIpg&bvm=bv.70138588,d.d2k&cad=rja

http://www.foscam.es/camaras-ip-faq.php

http://www.superinventos.com/inalambricas.htm

http://www.lsb.es/imagenes/Aplicaci%C3%B3n%20de%20soluciones%20Wifi%20de%20largo%20alcance.pdf

http://www.digi.com/support/productdetail?pid=3352&osvid=57&type=utilities


42

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:


43

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.


44

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


45

Arriba derecha. Se pulsa para que busque dispositivos

Se marca el deseado y se pulsa seguir

Ilustración 136 XCTU versión 2014


Selecciono principalmente la velocidad de configuración de todo el sistema


46


Se pulsa “finish” El sistema busca automáticamente el nodo principal.


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.


47


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.


Se pulsa “Discover”



48

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.

https://learn.adafruit.com/using-the-adafruit-library-with-fritzing/download-the-fritzing-library-from-github


49

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


50

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 }; //mac de arduino garba abril 2014 IPAddress ip(192, 168, 1, 33); //la IP de mi arduino //IPAddress server(74,125,232,128); // usando la IP numeric IP for Google (no DNS) //char server[] = "www.google.com"; // usando DNS IPAddress server(168,144,87,229); // zainder.com para bases de datos de acceso externo //IPAddress server(192, 168, 1, 1 ); // mi router . ahi veo que es de telefonica :) //IPAddress server(127,0,0,1); // mi localhost con easyphp 127.0.0.1/home //IPAddress server(192,168,1,34); // sumando 10 a la de casa. //char server[] = "localhost"; // 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");


51

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.


52

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></html> 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


53

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;


54

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);


55

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; // 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);


56

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 [4] = grados_Longitud; buffer [5] = parteI; buffer [6] = parteJ; buffer [7] = 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


57

// 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;}


58

4.9.2 FUNCIONES BÁSICAS DE PROCESSING


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;


59

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); //otra forma de ponerlo con variables - (this, "COM5", 9600); puerto.buffer(3); //para preparar para 3 datos //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 archivo para consola- estructura medida_Alto = loadImage("imagenes/3medidores-Alto.png"); // Load the image into the program 163*371 medida_Bajo = loadImage("imagenes/3medidores-Bajo.png"); // Load the image into the program medida_Mitad = loadImage("imagenes/3medidores-Medio.png"); // Load the image into the program medida_Alto_Luz = loadImage("imagenes/3luces-Alto.png"); // Load the image into the program 250 * 350 medida_Bajo_Luz = loadImage("imagenes/3luces-Bajo.png"); // Load the image into the program medida_Mitad_Luz = loadImage("imagenes/3luces-Medio.png"); // Load the image into the program //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.


60

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_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.


61

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, 7); //pantalla de datos //stroke(255); //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 ++) {


62

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


63

//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) )


64

{ 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;


65

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.


66

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 ) {


67

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


68

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; } }


69

//----------------------------------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"


70

+" 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,


71

"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) ; }


72

//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)


73

; } //-----------------------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


74

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.


75

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);

}


76

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 map; UnfoldingMap mapDetail; UnfoldingMap mapOverview; UnfoldingMap map_microsoft; float nuevaX = 42.465f; //latitud horizontal float nuevaY = -2.426f; //longitud vertical Location locationUniversidadRioja = new Location(nuevaX , nuevaY); //42.465, -2.426


77

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); //otra forma de ponerlo con variables - (this, "COM5", 9600); puerto.buffer(size_buffer_recepcion_datos); //para preparar para size_buffer datos que bienen de arduino //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 );

}


78

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); */


79

//compruebo en consola los datos que recibo. println( "datos1: " + datos1); // grados_Latitud; println( "datos2: " + datos2); // parteD; println( "datos3: " + datos3); // parteE; println( "datos4: " + datos4); // signo_Latitud; println( "datos5: " + datos5); // grados_Longitud; println( "datos6: " + datos6); // parteI println( "datos7: " + datos7); // parteJ println( "datos8: " + datos8); // 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); // coloco el punto solo en el mapa correspondiente if ( cambio_proveedor_mapas == 1 ) { coloca_punto_en_mapa (Latitud_capturada, Longitud_capturada); } if ( cambio_proveedor_mapas == 2 ) { coloca_punto_en_mapa_Zoomeado (Latitud_capturada, Longitud_capturada); } if ( cambio_proveedor_mapas == 3 ) { coloca_punto_en_mapa_microsoft (Latitud_capturada, Longitud_capturada);}


80

//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 -----------------


81

//----------------------------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 = puerto_serie.read(); datos6 = puerto_serie.read(); datos7 = puerto_serie.read(); datos8 = puerto_serie.read(); return datos1 + datos2 + datos3 + datos4 + datos5 + 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;


82

break; case('z'): cambio_proveedor_mapas = 1; break; case('x'): cambio_proveedor_mapas = 2; break; case('c'): cambio_proveedor_mapas = 3; //pongo tantas variables como proveedores de mapas tenga. break; } } //------------------------------------------------------------------ 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 () {


83

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 ); } */


84

} //----------------------------------------------------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);

}


85

4.9.3 FUNCIONES BÁSICAS DE LA APLICACIÓN WEB


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.


86

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' ") or die ("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>"; } */ ?>

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] " ;

?>


87

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 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; -- -- Database: `arduinodemos` -- -- -------------------------------------------------------- -- -- Table structure for table `tabla_arduino_demo` --


88

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>


89

<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';


90

//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>"; }

?>


91

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


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-a-

live-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/problems-

with-unfolding-some-scripts-goes-on-win8-but-not-in-win7-why-#Item_1





http://forum.processing.org/two/discussion/5472/is-there-possible-a-live-streaming-with-gopro3-wifi-and-processing-#Item 1

http://forum.processing.org/two/discussion/5472/is-there-possible-a-live-streaming-with-gopro3-wifi-and-processing-#Item 1

http://forum.processing.org/two/discussion/5070/problems-with-unfolding-some-scripts-goes-on-win8-but-not-in-win7-why-#Item_1

http://forum.processing.org/two/discussion/5070/problems-with-unfolding-some-scripts-goes-on-win8-but-not-in-win7-why-#Item_1


92

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.


93

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.


94

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 144 Logo

Arduino

Ilustración 145 Frizting

Ilustración 146 Processing

Ilustración 147 Java

Ilustración 148 Javascript


95

Ilustración 149 Html5 Y CSS3

Ilustración 150 PHP

Ilustración 151 Aptana Std

Ilustración 152 MySQL

Ilustración 153 SO Linux

Ilustración 154 Distro Ubuntu

Ilustración 155 LESS CSS

Ilustración 156 Eclipse

Logo

Ilustración 157 PhP MyAdmin

Ilustración 158 Boostrap d

Twitter

Ilustración 159 Jquery

Ilustración 160 Json

lustración 161 Open Office

Ilustración 162 Wamp

Ilustración 163 Gimp

Ilustración 164 Phone GAP

Ilustración 165 Apache

Ilustración 166 EasyPhp


96


97


FIN DE DOCUMENTO: ANEJOS




98


1


DOCUMENTO Nº5:

PLIEGO DE CONDICIONES







2


3

5. PLIEGO DE CONDICIONES


4

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,


5

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.


6

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.


7

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.


8

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,


9

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.


10

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.


11

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.

http://es.wikipedia.org/wiki/Modelo_OSI

http://es.wikipedia.org/wiki/WLAN

http://es.wikipedia.org/wiki/Red_de_%C3%A1rea_local

http://es.wikipedia.org/wiki/Red_de_%C3%A1rea_metropolitana

http://es.wikipedia.org/wiki/Red_de_%C3%A1rea_metropolitana


12

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.


13

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.


14

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:


15

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.


16

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.


17

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.


18

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.


19

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.


20

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,


21

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.


22

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 UNE-

139803,


23

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 de

navegadores semánticos como los siguientes:

Marbles

Disco


24

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


25




26



27

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.


28

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


29

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.


30

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.


31

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 efectos de las sobreintensidades y

sobretensiones que por distintas causas cabe prever en las 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


32

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.


33

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.


34

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.


35

La RoHS es una directiva de la UE que restringe el uso de 6 materiales

peligrosos en la fabricación de diversos tipos de equipos eléctricos y

electrónicos, obligando a los fabricantes a demostrar 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 Límite inferior Límite superior Temperatura -20ºC 100ºC Humedad relativa 5% RH 85%RH Dióxido de Azufre 0 ppm 500 ppm Ozono 0 ppm 500 ppm Dióxido de Nitrógeno 0 ppm 500 ppm Sulfuro de Hidrógeno 0 ppm 500 ppm Monóxido de Carbono 0 ppm 1000 ppm

Tabla: Límites válidos.


36

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.


37

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:


38

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.


39

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


40

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 Unidad Rango Temperatura del aire ºC -20ºC / 100ºC Humedad relativa del aire

% 0/100

Dióxido de Azufre 0 ppm 500 ppm Ozono 0 ppm 500 ppm Dióxido de Nitrógeno 0 ppm 500 ppm Sulfuro de Hidrógeno 0 ppm 500 ppm Monóxido de Carbono 0 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.


41

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í


42

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.


43

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, a efectos del

reconocimiento de 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.


44

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.


45

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


46

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


47

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.


48

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


49

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


50

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.


51

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


52

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.


53

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.


54

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.


55

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


56

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


57

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.


58

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


59

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


60

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.


61

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


62

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


63

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


64

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).


65

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.


66

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.


67

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


68

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.


69

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


70

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.


71

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.


72

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,


73

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.


74

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.


75

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.


76

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:


77

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.


78

- 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


79

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


80

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.


81

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.


software

engineering System life cycle processes. Second edition 2008-02-01,

84p.


software engineering Recommended practice for architectural


82

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.


83

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.


84


85


FIN DE DOCUMENTO:

PLIEGO DE CONDICIONES




86


1


DOCUMENTO Nº 6: PRESUPUESTO







2

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


3

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.


4

6.2 ESTADO DE MEDICIONES

Unidades necesarias de material. DESCRIPCIÓN DEL MATERIAL UNIDADES FUTABA 14 SG (FASSTEST 2.4GHz) 1 Estabilizador Naza 1 GPS V2 kit DJI Naza H 1 Pareja porta helice cw + cww 2 Leopard 730 Kv LC2835 4 MN3508 700KV Brushless 4 Regulador DJI 15A (ESC) 3-4 Lipo 4 T-Motor ESC S35A 2-6S 600 Hz 4 E600 (6*Motor/ESC; props; Accessories) 1 T-Mot 15-5.5 V2 CF MULTIROTOR PROPS 2 Bateria lipo 5100mAh 11.1V 3S 35C 1 bateria lipo 3000 mA 4S 40C 1 Phantom 2 y Vision DJI F 330 1 Lipo 2650mAh 3S 30C Lipo Pack 1 bateria lipo 3000 mA 4S 40C 1 Chasis DJI F550 1 Cableado 20 Completo Phantom 2 - 330 + Tx - RTF 1 GoPro Hero3 Wifi 1 Tarjeta ultra fast class 10 1 Maletines de transporte 1 Licencia IDE de Arduino 3 Licencia Hardware Arduino 3 Licencia del IDE Processing 3 Licencia GIMP 1 Licencia Bootstrap 1 Licencia html5 1 Licencia CSS3 1 Licencia J2me 1 Licencia JavaScript 1 Licencia LSS 1 Licencia Json 1 Licencia PHPtriad 1 Licencia WAMP 1 Licencia Easy PHP 1 Licencia Linux Ubuntu 13 1 Licencia Windows 7 OEM 1 Licencia Google Chrome 1 Licencia Mozilla Firefox 1 Licencia Libreria Adafruit 1 Licencia Eclipse 1 Licencia Librería MTK GPS 1 Licencia Librería Control IP5 1 Licencia Librería Unfolding 1 Licencia Notepad ++ 1 Licencia Sublime Text 1 Licencia Brackets LSS 1 Licencia 3DR radion config 1 Licencia XCTU para Xbee 1 Licencia OpenGL 1 Editor CSS 1 Editor LSS 1


5

Licencia Json Edit 1 Licencia Blue Griffon 1 Licencia Open Office 1 Licencia PHP 1 Licencia php My Admin 1 Licencia Apache 1 Licencia JS 1 FUTABA 14 SG (FASSTEST 2.4GHz) 1 Estabilizador Naza 1 GPS V2 kit DJI Naza H 1 Pareja porta helice cw + cww 2 Leopard 730 Kv LC2835 4 MN3508 700KV Brushless 4 Regulador DJI 15A (ESC) 3-4 Lipo 4 T-Motor ESC S35A 2-6S 600 Hz 4 E600 (6*Motor/ESC; props; Accessories) 1 T-Mot 15-5.5 V2 CF MULTIROTOR PROPS 2 Bateria lipo 5100mAh 11.1V 3S 35C 1 bateria lipo 3000 mA 4S 40C 1 Phantom 2 y Vision DJI F 330 1 Lipo 2650mAh 3S 30C Lipo Pack 1 bateria lipo 3000 mA 4S 40C 1 Chasis DJI F550 1 Cableado 20 Completo Phantom 2 - 330 + Tx - RTF 1 GoPro Hero3 Wifi 1 Tarjeta ultra fast class 10 1 Maletines de transporte 1


6

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


7

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


8

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


9

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.


10

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

FECHA: 16/07/2014

Presupuestos

Nº DE PRESUPUESTO: 1

PARA: Universidad de La Rioja Dirección : Logroño

Ciudad, Código postal

FACTURAR A: Nombre : Universida de La Rioja Teléfono: 629486109

Fax: 629486109

Dirección


Teléfono: 629486109

DESCRIPCIÓN DEL MATERIAL UNIDADES COSTE UNITARIO IMPORTE

Arduino Ethernet 1 45 € 45,00 Router de 4 Puertos 1 35 € 35,00 Cable de Red 1 12 € 12,00 Fuente de Alimentación 1 21 € 21,00 Pila 9v. 4 3 € 12,00 Conectores Pila – Arduino 4 1 € 4,00 Cabel usb 3 9 € 27,00 Resistencia 10k 10 0,1 € 1,00 Ardupilot Mega 2. 1 50 € 50,00 Arduino Uno 1 39 € 39,00 LM35 1 0,99 € 0,99 Xbee explorer usb 1 22 € 22,00 3DR 1 80 € 80,00 Xbee 1 115 € 115,00 Sonda NTC 1 19 € 19,00 Sensor LDR 1 0,54 € 0,54 Potenciometro 1 0,25 € 0,25 GPS GTPA 010 2 35 € 70,00 GPS GTPA 013 1 39 € 39,00 Cableado 20 0,1 € 2,00 Protoboards 2 1 € 2,00

SUBTOTAL € 596,78

IVA 21,00%

OTROS -

TOTAL € 722,10


11

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 FECHA: 16/07/2014

Presupuestos Nº DE PRESUPUESTO: 2

PARA: UR Dirección : Logroño

Ciudad, Código postal FACTURAR A: Nombre : Teléfono: 629486109


Fax:

Dirección


Teléfono:

DESCRIPCIÓN DEL MATERIAL UNIDADES COSTE UNITARIO IMPORTE Licencia IDE de Arduino 3 0 € -

Licencia Hardware Arduino 3 0 € -

Licencia del IDE Processing 3 0 € - Licencia GIMP 1 0 € - Licencia Bootstrap 1 0 € - Licencia html5 1 0 € - Licencia CSS3 1 0 € - Licencia J2me 1 0 € - Licencia JavaScript 1 0 € - Licencia LSS 1 0 € - Licencia Json 1 0 € - Licencia PHPtriad 1 0 € - Licencia WAMP 1 0 € - Licencia Easy PHP 1 0 € - Licencia Linux Ubuntu 13 1 0 € - Licencia Windows 7 OEM 1 0 € - Licencia Google Chrome 1 0 € - Licencia Mozilla Firefox 1 0 € - Licencia Libreria Adafruit 1 0 € - Licencia Eclipse 1 0 € - Licencia Librería MTK GPS 1 0 € - Licencia Librería Control IP5 1 0 € - Licencia Librería Unfolding 1 0 € - Licencia Notepad ++ 1 0 € - Licencia Sublime Text 1 0 € - Licencia Brackets LSS 1 0 € - Licencia 3DR radion config 1 0 € -


12

Licencia XCTU para Xbee 1 0 € - Licencia OpenGL 1 0 € - Editor CSS 1 0 € - Editor LSS 1 0 € - Licencia Json Edit 1 0 € - Licencia Blue Griffon 1 0 € - Licencia Open Office 1 0 € - Licencia PHP 1 0 € - Licencia php My Admin 1 0 € - Licencia Apache 1 0 € - Licencia JS 1 0 € -

Donaciones a Proyectos Open Source 5 2 € 10,00

SUBTOTAL € 10,00

IVA 21,00%

OTROS -

TOTAL € 12,10


13

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 FECHA: 16/07/2014

Presupuestos Nº DE PRESUPUESTO: 3

PARA: Universidad de La Rioja Dirección : Logroño

Ciudad, Código postal FACTURAR A: Universidad de La Rioja Teléfono: 629486109


Fax:

Dirección


Teléfono: 629486109

DESCRIPCIÓN DEL MATERIAL UNIDADES COSTE UNITARIO IMPORTE FUTABA 14 SG (FASSTEST 2.4GHz) 1 529 € 529,00

Estabilizador Naza 1 155 € 155,00 GPS V2 kit DJI Naza H 1 161 € 161,00 Pareja porta helice cw + cww 2 19,9 € 39,80 Leopard 730 Kv LC2835 4 38 € 152,00 MN3508 700KV Brushless 4 65 € 260,00 Regulador DJI 15A (ESC) 3-4 Lipo 4 22,99 € 91,96 T-Motor ESC S35A 2-6S 600 Hz 4 40 € 160,00 E600 (6*Motor/ESC; props; Accessories) 1 450 € 450,00 T-Mot 15-5.5 V2 CF MULTIROTOR PROPS 2 121 € 242,00

Bateria lipo 5100mAh 11.1V 3S 35C 1 79 € 79,00 Bateria lipo 3000 mA 4S 40C 1 26 € 26,00 Phantom 2 y Vision DJI F 330 1 109 € 109,00 Lipo 2650mAh 3S 30C Lipo Pack 1 49 € 49,00 Nateria lipo 3000 mA 4S 40C 1 65 € 65,00 Chasis DJI F550 1 55 € 55,00 Cableado 20 0,5 € 10,00 Completo Phantom 2 - 330 + Tx - RTF 1 625 € 625,00 GoPro Hero3 Wifi 1 350 € 350,00 Tarjeta ultra fast class 10 1 65 € 65,00 Maletines de transporte 1 210 € 210,00

SUBTOTAL € 3.883,76

IVA 21,00%

OTROS -

TOTAL € 4.699,35


14

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:




15

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.


16

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.


17


FIN DE DOCUMENTO:

PRESUPUESTOS




18


1


DOCUMENTO Nº7:

ESTUDIOS CON ENTIDAD PROPIA







2


3

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


4

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.


5

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.


6

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.


7

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.


8

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.


9

“SUPERVISIÓN REMOTA DE

PARÁMETROS MEDIOAMBIENTALES

CAPTURADOS POR UAV”

FIN DE DOCUMENTO:

ESTUDIOS CON ENTIDAD PROPIA




10


11

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.2.2.1 QUÉ ES ARDUINO Y SUS ALTERNATIVAS: ........................................................................ 24

1.2.2.2 VEHÍCULO AÉREO NO TRIPULADO UAV. DRONE. ............................................................ 25

1.3 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 OTROS SENSORES............................................................................................................ 47

1.7 NUEVO PARADIGMA ................................................................................................................ 48


12

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


13

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 COMPATIBILIDAD Y RELACION ENTRE DICHOS DOCUMENTOS .......................................... 120

1.16 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 NORMAS PARA CONSULTA ................................................................................................. 128

1.19 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


14

3. ESPECIFICACIONES DEL SISTEMA ...................................................... 3

3.1 CONFIGURACIONES BÁSICAS ..................................................................................................... 3

3.2 CONFIGURACIÓN PUESTA EN MARCHA DEL DRONE ................................................................... 3

3.2.1 SOFTWARE DE CONFIGURACION ............................................................................................ 7

3.3 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 CONFIGURACIÓN DEL ROUTER ..................................................................................... 21

3.4 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 DESDE PHP ............................................................................................................................ 29

3.6 INSTALACIÓN DE SENSORES ..................................................................................................... 31

3.6.1 ENTRADAS. SALIDAS PVM. .................................................................................................... 31


15

3.6.2 POTENCIOMETRO ................................................................................................................. 33

3.6.2.1 CODIGO BÁSICO EN ARDUINO PARA UN POTENCIOMETRO ........................................... 34

3.6.3 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 OTROS SENSORES ................................................................................................................. 54

3.7 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


16

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


17

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 PATILLAJE ........................................................................................................................ 18

4.5 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


18

4.5.10 CREACIÓN DE UN TIMELINE ................................................................................................. 32

4.6 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.1.2.1 ALGUNOS RESULTADOS DE DIFERENTES CONEXIONES ........................................... 51

4.9.1.2.2 LECTURAS BÁSICAS Y CONVERSIONES EN ARDUINO ETHERNET ............................. 52

4.9.2 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


19

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 COMPETENCIAS REFERIDAS A LA PROGRAMACIÓN ............................................................. 12

5.4 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


20

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 VALIDACIÓN DE LA COHERENCIA INTERNA DE LOS DATOS. RELACIONES ENTRE

VARIABLES. 41

5.6.9 PUESTA EN MARCHA Y MANTENIMIENTO ........................................................................... 41


21

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 NORMAS DE CALIDAD ........................................................................................................... 50

5.8 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


22

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


23

5.9.4.19 GUÍAS PARA LAS PRUEBAS ............................................................................................ 79

5.9.5 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

supervisión remota de parámetros medioambientales capturados

Documents