Treball Fin al de Grau
GRAU D’ENGINYERIA ELECTRÒNICA INDUSTRIAL I AUTOMÀTICA
Prototipo de nodo wifi para medida de nivel de ruido y lecturas GPS con aplicaciones IoT
JAVIER MARÍN MARTÍN
Tutor
Bartomeu Alorda Ladaria
Escola Politènica Superior Universitat de les Illes Balears
Palma, junio de 2017
i
Índice general
Índice general ... i
Índice de figuras ... iii
Índice de tablas ... v
Acrónimos ...vi
Resumen ... vii
Capítulo 1. Introducción ... 1
1.1 Conceptos clave del proyecto ... 1
1.2 Contextualización ... 2
1.3 Motivación ... 2
1.4 Objetivos ... 3
1.5 Fases del proyecto ... 3
Capítulo 2. Diseño del nodo ... 5
2.1 Esquema general ... 5
2.2 Bloques del nodo ... 5
2.2.1 Computación ... 6
2.2.2 Capacidad sensorial ... 8
2.2.2.1 Transceptor de sonido ... 8
2.2.2.2 Receptor GPS ... 10
2.2.3 Conexión a la red ... 14
2.2.3.1 Transmisor wifi ... 14
2.2.4 Alimentación ... 18
2.2.4.1 Porta baterías ... 18
2.2.4.2 Análisis de consumos ... 18
2.3 Diseño de la PCB ... 21
2.3.1 Layout ... 22
2.3.2 Esquemático ... 25
Capítulo 3. Firmware del nodo ... 29
3.1 Plataforma web ... 29
3.1.1 Introducción ... 29
3.1.2 Configuración ... 30
3.1.3 Envío de datos ... 34
3.1.4 Consulta y visualización de datos ... 35
3.2 Programación Arduino ... 38
3.2.1 Librerías ... 39
3.2.2 Métodos código ... 40
3.2.2.1 getRuido() ... 40
3.2.2.2 getLatitud() y getLongitud() ... 42
3.2.3 Implementación final ... 43
Capítulo 4. Verificación ... 45
Capítulo 5. Conclusiones ... 49
5.1 Valoración global ... 49
5.2 Conocimientos adquiridos ... 49
5.3 Otras valoraciones ... 50
5.4 Futuro del prototipo ... 50
ii
Bibliografía ... 51
Anexos ... 53
A) Fabricación de la PCB ... 53
B) Calibración del transceptor de sonido ... 57
C) Cambios en el proyecto respecto a la idea inicial ... 59
iii
Índice de figuras
2-1: recorrido de los datos tomados por el nodo ... 5
2-2: placa de desarrollo utilizada en el proyecto ... 6
2-3: transceptor de sonido utilizado en el proyecto ... 8
2-4: receptor GPS utilizado en el proyecto ... 10
2-5: formato de las tramas del receptor GPS ... 10
2-6: circuito necesario para implementar el modo backup en el receptor GPS ... 11
2-7: formato del comando para acceder al modo periódico del receptor GPS ... 12
2-8: ejemplo de consumo del receptor GPS en distintos modos de funcionamiento ... 13
2-9: transmisor wifi utilizado en el proyecto ... 14
2-10: conector para configurar el transmisor wifi desde un pc ... 15
2-11: inicio del programa XCTU para configurar el transmisor wifi ... 15
2-12: algunos parámetros configurables del transmisor wifi ... 16
2-13: configuración del modo sleep del transmisor wifi ... 17
2-14: porta baterías utilizado en el proyecto ... 18
2-15: PCB utilizada en el proyecto ... 21
2-16: layout de la placa Arduino M0 ... 22
2-17: layout de la PCB sin componentes ... 22
2-18: layout de la PCB sin vías ... 23
2-19: layout de la PCB con todos los componentes y vías ... 24
2-20: layout definitivo de la PCB ... 24
2-21: esquemático de la placa Arduino M0 (hoja 1) ... 25
2-22: esquemático de la placa Arduino M0 (hoja 2) ... 26
2-23: componentes a aprovechar para la PCB ... 26
2-24: esquemático definitivo de la PCB ... 27
3-1: pantalla de inicio de Sentilo ... 30
3-2: panel de control de Sentilo ... 31
3-3: application por defecto de Sentilo ... 31
3-4: componente creado para el proyecto en Sentilo ... 32
3-5: formulario para dar de alta sensores y actuadores en sentilo ... 32
3-6: sensores dados de alta para el proyecto en Sentilo ... 33
3-7: tipos de sensores que se pueden dar de alta en Sentilo ... 34
3-8: método para verificar la llegada de datos a Sentilo ... 35
3-9: vista del componentes en el mapa de Sentilo ... 36
3-10: detalle de los datos recibidos por el componente ... 36
3-11: atributos de uno de los sensores dados de alta ... 37
3-12: vista de los últimos 10 datos recibidos de un sensor ... 37
3-13: estructura de un código para Arduino ... 38
3-14: diagrama de flujo del método getRuido() ... 41
3-15: diagrama de flujo de los métodos getLatitud() y getLongitud() ... 42
3-16: estructura final del código ... 43
4-1: datos subidos correctamente a la plataforma ... 45
4-2: localización en la que se han realizado las pruebas... 46
4-3: localización al no disponer de cobertura el receptor GPS ... 46
4-4: datos de longitud del receptor GPS ... 47
4-5: datos de latitud del receptor FPS ... 47
iv
4-6: datos de nivel de ruido ambiental del transceptor de sonido ... 48
4-7: pruebas del transceptor de sonido sometido a altos niveles de ruido ambiental ... 48
A-1: layout previo a la fabricación de la PCB... 53
A-2: máquina de prototipado de PCBs ... 53
A-3: evolución de tiempo real de la fabricación de la PCB ... 54
A-4: estado intermedio de la fabricación de la PCB ... 54
A-5: detalle de una vía de la PCB en un microscopio ... 55
A-6: layout de la cara inferior de la PCB ... 55
A-7: PCB impresa ... 55
B-1: calibrador utilizado para calibrar el transceptor de sonido ... 57
C-1: microcontroladores contemplados inicialmente para el proyecto ... 59
C-2: esquemático de la PCB descartada ... 60
C-3: layout de la PCB descartada ... 60
C-4: PCB descartada ... 60
v
Índice de tablas
Tabla 2-1: Estudio de intensidades ... 19 Tabla B-1: Medidas para calibración del transceptor de sonido ... 58
vi
Acrónimos
IoT Internet of Things
TIC Tecnologías de la información y la comunicación GPS Global Positioning System
UART Universal Asynchronous Receiver Transmitter SPL Sound Pressure Level
ADC Analog-to-Digital Converter LPWAN Low Power Wide Area Network M2M Machine to Machine
USB Universal Serial Bus
NMEA National Marine Electronics Association HTTP Hypertext Transfer Protocol
API Application Programming Interface IDE Integrated Development Environment SSID Service Set Identifier
RTC Real Time Clock
URL Uniform Resource Locator
vii
Resumen
En este proyecto se ha llevado a cabo la creación desde cero de un prototipo de un nodo de información IoT, el cual es capaz de subir a internet información sobre el entorno que percibe. Para ello se ha utilizado una placa de desarrollo, dos sensores (un transceptor de sonido y un receptor GPS) y un transmisor wifi. Además, se ha diseñado y fabricado una PCB para facilitar la inclusión de todos los componentes en el nodo y minimizar su tamaño.
Ha sido necesaria la confección de un código que lleve a cabo la gestión de la información recibida por el transceptor de sonido y el receptor GPS, así como la transmisión a una plataforma de gestión de datos online.
Se ha tratado también de minimizar el consumo del nodo con los modos de ahorro de energía de los distintos componentes de manera que pueda funcionar de manera autónoma el mayor tiempo posible.
El aporte energético para el funcionamiento del nodo lo proporcionan unas baterías colocadas bajo la placa de desarrollo en un porta baterías conectado con un cable de alimentación DC a la placa de desarrollo.
El dispositivo ha sido creado con la intención de ser utilizado en el futuro para recopilación de datos en el campus de la universidad u otras localizaciones con una red wifi que cubra un área amplia, formar parte de una red de sensores o ser objeto de mejoras para próximos trabajos de fin de grado.
Además de la presente memoria, se han adjuntado una serie de archivos y documentos para poder realizar un correcto seguimiento y posible replicación de este proyecto.
1
Capítulo 1. Introducción
1.1 Conceptos clave del proyecto
Las descripciones que se hacen a continuación sobre conceptos del contexto del proyecto son muy superficiales y no se pretende profundizar, pero sí dar a entender los muchos aspectos que engloban cada uno de ellos. Se entiende como una aportación mínima para contextualizar de forma adecuada la idea, objetivos, alcance y desarrollo de este proyecto.
1 · Internet of Things (IoT): se trata del concepto de interconectar entre sí y a internet prácticamente cualquier dispositivo, de manera que podamos interactuar o conseguir información útil en tiempo real. Objetos, personas, animales, condiciones ambientales, fenómenos meteorológicos… El mundo está lleno de datos que se pueden extraer y almacenar y que pueden tener una aplicación práctica a la hora de facilitar y mejorar la calidad de vida de las personas.
2 · Nodo: Dentro del entorno del IoT un nodo es cada una de las entidades que proporciona información a través de la red. Están formados generalmente por uno o más sensores acompañados de algún tipo de computador o microcontrolador capaz de gestionar la información obtenida de los sensores y de algún medio para poder establecer una conexión a internet a través de la cual subir los datos.
3 · Red de sensores: Conjunto de nodos que colaboran en una tarea común. Pese a que el origen de este concepto es, como en tantas otras ocasiones, militar, las ventajas que presentan las han convertido en una idea con aplicaciones mucho más amplias que las pensadas de inicio. Algunas de las más interesantes y más destacables para este proyecto son las siguientes:
- Reducido coste energético y económico.
- Versatilidad para funcionar como transmisores y como receptores.
- Sencilla implementación.
- Conexión inalámbrica.
4 · Ciudades inteligentes: es un concepto emergente que procede del término en inglés
“Smart city”, y se refiere a aquellas ciudades que aplican las tecnologías de la información y de la comunicación (TIC) con el objetivo de proveerla de una infraestructura que garantice:
- Un desarrollo sostenible.
- Un incremento de la calidad de vida de los ciudadanos.
- Una participación ciudadana activa.
- Una mayor eficacia de los recursos disponibles.
Cumpliéndose todas estas condiciones se habla de ciudades sostenibles social, económica y medioambientalmente.
2
1.2 Contextualización
El presente trabajo se enfoca en un concepto de IoT que está sufriendo una amplia expansión:
Un claro ejemplo es Corea de Sur [1] donde el operador de telefonía SK Telecom con la colaboración de Samsung ha presentado una red nacional IoT que cubre al 99% de su población basada las redes LoRa [2], cuya función es proveer de redes LPWAN principalmente para aplicaciones de ciudades inteligentes y aplicaciones industriales que requieran comunicación M2M y bidireccional.
La principal diferencia entre estas redes y otras de transmisión de datos es la notable diferencia en la reducción de los requisitos de flujo de datos que necesitan los dispositivos a los que están enfocados y el consecuente ahorro económico que ello conlleva. Dada la baja cantidad de información que cada uno de los nodos transmite y recibe, un nodo IoT resulta una mejor solución frente a utilizar otras redes como puede ser el 3G o el 4G, ya que se enviarían muchos menos datos de los que permite la red y se pagarían tarifas desproporcionadas para esa misma cantidad de información.
Para poder entender hasta qué punto podría utilizarse la interconexión entre objetos se pueden utilizar de ejemplo casos en los que ya se lleva a cabo, siendo uno de ellos es el sistema de control de tráfico de embarcaciones en canales con sensores inalámbricos en Holanda [3]. Este proyecto permite conocer y monitorizar la distancia, dirección y velocidad de las embarcaciones que navegan por ciertos puntos de los canales de una ciudad con el objetivo de poder gestionar y planificar de manera óptima el tráfico de dichos vehículos y automatizar la apertura y cierre de los puentes levadizos. Para ello se han utilizado sensores láser añadidos a la red de sensores de Libelium, Waspmote Sensor Platform, y su gateway propio, Meshlium.
1.3 Motivación
Visto el prometedor futuro del paradigma del IoT, poder crear un nodo que vaya a ser utilizado en casos prácticos se presenta como una gran motivación no sólo por motivos académicos, sino también profesionales. Dado el más que probable éxito de este tipo de tecnologías y las crecientes oportunidades de puestos de trabajo que ello puede conllevar, la opción de realizar como trabajo de fin de grado un prototipo de nodo IoT resulta una gran oportunidad.
Junto a esto, las posibilidades de ampliar conocimientos en un campo del que solamente se tenían nociones a la hora de empezar el proyecto y de comprobar de primera mano cuales son los puntos más importantes y los más críticos a lo largo de un proceso de fabricación de inicio a fin, hicieron tomar la decisión de emprender este proyecto.
3
1.4 Objetivos
El principal objetivo de este proyecto es llevar a cabo de principio a fin todas las fases que conforman la creación de un nodo IoT, consiguiendo como resultado final un prototipo.
Estos dispositivos se caracterizan principalmente por su reducido tamaño para su fácil despliegue en cualquier ubicación, por su capacidad sensorial para percibir el entorno y por su bajo consumo y ahorro de energía.
Se buscará por tanto la optimización de estos puntos, creando una PCB capaz de incluir todos los dispositivos en un diseño compacto y reducido y con un código capaz de gestionar la información de los sensores y los distintos modos de funcionamiento de los componentes ahorrando la máxima energía posible.
Además, se pretende poder visualizar a través de internet los últimos datos que el nodo haya recopilado.
Finalmente y al tratarse de un prototipo será importante analizar posibles mejoras una vez dado por finalizado para un posible futuro TFG que optimice, amplíe o mejore el presente proyecto.
1.5 Fases del proyecto
Una vez definidas las motivaciones y objetivos del proyecto se han establecido unas etapas para su correcto cumplimiento.
Es importante destacar que la elección de los componentes de este proyecto recae sobre el tutor del proyecto, los cuales son un transceptor de sonido y un receptor GPS como sensores y un transmisor wifi sobre una placa de desarrollo Arduino. Como se explica en el anexo C esta placa de desarrollo se incorporó posteriormente para corregir algunos problemas de funcionamiento.
Esto significa que en ningún momento se ha planteado: ni la posibilidad de elegir algún otro componente de distintas especificaciones que pudiese cumplir con las mismas funciones que los utilizados, ni se ha llevado a cabo ningún estudio para buscar algún otro componente que pudiese dar mejores resultados para este proyecto dentro de las posibilidades que ofrece el mercado.
La aclaración anterior es necesaria para argumentar la ausencia de elección de componentes en las fases que se enumeran a continuación:
- Analizar y proponer conexión de las partes del nodo a nivel de bloques.
- Analizar los consumos estimados a partir de datos proporcionados por los fabricantes.
- Realizar esquemático con la herramienta EAGLE del diseño. Si no existen elementos bloques de los componentes elegidos, realizar las librerías necesarias.
- Realizar la placa a nivel de layout. Incluir elementos de reducción de ruido en caso necesario.
- Estudiar el servidor y su correcta implementación para el proyecto.
4
- Programa para la captura de la geolocalización y del valor de nivel de ruido ambiental en el nodo IoT.
- Programar la tarea de envío de datos al servidor. Decidir frecuencia y formato de envío.
- Verificación del nodo en una red local wifi con sólo el servidor y el nodo IoT.
- Comparar los datos de consumo teóricos con datos experimentales.
5
Capítulo 2. Diseño del nodo
2.1 Esquema general
La figura 2-1 muestra el proceso de funcionamiento del nodo desde que los sensores toman medidas de su entorno hasta que éstas se pueden consultar en un ordenador. Cada uno de estos pasos o procesos, resumidos en los siguientes puntos, se explican en apartados posteriores en este documento.
- Los sensores recogen información periódicamente.
- La placa de desarrollo genera una trama con una estructura definida con esos datos.
- La trama es enviada del transmisor al router a través de una conexión wifi para que llegue al servidor de la plataforma web.
- Dicha información puede ser consultada desde un ordenador.
Figura 2-1: recorrido de los datos tomados por el nodo
Se debe mencionar además que una vez finalizado este proceso, el nodo entrará en modo de bajo consumo hasta pasados 20 minutos desde el momento en que se despertó para realizar este ciclo.
2.2 Bloques del nodo
Un nodo está compuesto por distintos bloques donde cada uno de ellos debe realizar una tarea bien diferenciada a la del resto. A la vez cada uno de estos bloques puede estar compuesto por uno o más componentes.
Estos bloques en conjunto consiguen que el nodo cumpla con todos los requisitos necesarios para funcionar correctamente. A continuación se enumeran y explican cada uno de estos bloques y los componentes que los forman:
6 - Computación.
- Capacidad sensorial.
- Conexión a la red.
- Alimentación.
Si bien este nodo es relativamente sencillo y no está formado por un gran número de componentes, el número de estos podría verse incrementado sin que ello implicase un mayor número de bloques, por ejemplo añadiendo un nuevo sensor.
2.2.1 Computación
Es el bloque encargado de procesar y gestionar toda la información que fluye por el nodo ya sea en forma de datos recibidos por los sensores, la creación de tramas para enviar información nueva al servidor o controlar los tiempos en modo de bajo consumo que pasa cada uno de los componentes. Es el cerebro del nodo.
Este bloque está formado únicamente por un componente, la placa de desarrollo Arduino M0 (figura 2-2).
Figura 2-2: placa de desarrollo utilizada en el proyecto
Entre la gran cantidad de prestaciones de esta placa, las más relevantes para este proyecto son las siguientes:
- ADC incorporado de 10 bits, lo que le permite tener una resolución de 1024 niveles y lo hace perfecto para conectar a la salida analógica del transceptor de sonido.
- Incorpora comunicación serie a través de los pines 0 y 1 mediante una UART, además de permitir incorporar más comunicaciones de este tipo en algunos de sus pines digitales. En este caso tanto el receptor GPS como el transmisor wifi precisan de este tipo de comunicación, por lo que se ha conectado el receptor GPS a los pines 0 y 1 y se han habilitado los pines 9 y 8 como transmisor y receptor UART para el transmisor wifi.
- Dispone de un puerto micro-USB utilizado tanto para la alimentación del nodo durante todo el periodo de pruebas como para el volcado de código al microcontrolador. Además, dispone de un monitor serie que permite enviar y recibir datos de la placa y visualizarlos por pantalla, especialmente útil para utilizar
7
a modo debugger para seguir el funcionamiento del nodo y los errores que se deben corregir durante el periodo de pruebas.
- Incorpora un RTC que ha sido utilizado para establecer los tiempos que el nodo debe pasar en modos de bajo consumo.
Otra de las ventajas de la incorporación de una placa de desarrollo Arduino en el proyecto es el hecho de poder redactar el código con el software que proporciona el propio fabricante (ARDUINO IDE 1.7.11) en su página web [4]. Dado que es open-source, es posible beneficiarse de gran cantidad de librerías y funciones proporcionadas tanto por la propia Arduino como de cualquier empresa, equipo o persona que haya decidido compartir su trabajo en internet.
Las funciones de la placa en este proyecto se enumeran a continuación:
- Recibir la información que transmiten el transceptor de sonido y el GPS y gestionarla de manera que sea comprensible, pues, como se explica en los apartados correspondientes a cada sensor (apartados 2.2.2.1 y 2.2.2.2), no proporcionan esta información en el formato adecuado y requiere ser procesada.
- Proporcionar una salida de 3,3V estable para alimentar al transceptor de sonido, el receptor GPS y el transmisor wifi. Si bien la energía la proporcionan las baterías que se han incorporado, la placa garantiza una salida constante estabilizada de 3,3V para la alimentación de los componentes.
- Estabilidad y eliminación de ruido en las señales generadas por los componentes.
- Creación con el formato correcto de las tramas a enviar con los datos de nivel de ruido y de geolocalización.
- Dormir y despertar el receptor GPS, el transmisor wifi y el propio microcontrolador de la placa para minimizar sus consumos de energía.
Finalmente, cabe destacar que esta placa pertenece al conjunto de placas Arduino que utilizan el microcontrolador ATSAMD21G18 de Atmel, lo que permite implementar la librería EnergySaving (apartado 3.2.1). Al utilizar los métodos de esta librería se puede introducir la placa en modo Standby para reducir el consumo.
De acuerdo a la información disponible en la página correspondiente a la placa[5], la diferencia entre consumos es de 29mA en el modo operativo habitual y 2 mA en el modo de bajo consumo.
8
2.2.2 Capacidad sensorial
Este bloque incluye todos aquellos componentes que proporcionan información que perciben del entorno en el que se encuentra el nodo. Como ya se ha mencionado anteriormente, los sensores que se han utilizado para este prototipo son un transceptor de sonido y un receptor GPS. Este bloque presenta una gran capacidad de ampliación y escalabilidad en el futuro, ya que no sería muy complicado incrementar el número de sensores para ampliar la capacidad de recaudación de información del entorno.
A continuación se proporciona más en detalle los aspectos más importantes de cada uno de los sensores.
2.2.2.1 Transceptor de sonido
Este transceptor (figura 2-3) está formado por el amplificador MAX4466 del fabricante Adafruit y el micrófono CMA-4544PF-W del fabricante CUI INC. Opera con voltajes de 2,4V a 5 V, siendo una opción idónea para la salida de 3,3V de la placa Arduino. La función de este conjunto es proporcionar el nivel de ruido ambiental que haya en el entorno del nodo. Para hacerlo dispone de una salida que proporciona un valor analógico que se puede convertir a voltaje a partir del cual es posible obtener el nivel de ruido. En el apartado 3.2.2.1 se muestran las operaciones necesarias para obtener el valor de nivel de ruido ambiental correcto.
Figura 2-3: transceptor de sonido utilizado en el proyecto
El amplificador tiene incorporado en la parte trasera un potenciómetro que permite ajustar la ganancia entre25x y 125x, aunque dicho ajuste únicamente puede realizarse de manera manual con un destornillador o una herramienta similar. Este hecho es relevante ya que fue necesario ajustar la ganancia de manera que los valores obtenidos fuesen lo más elevado posibles para ganar precisión en los datos tomados, pero a la vez no debía verse saturado para altos niveles de ruido. El proceso de calibración puede consultarse en el anexo B.
9
De acuerdo a los datasheets (documentos adjuntos datasheet_MAX4466 y datasheet_microfono) el consumo de los dispositivos es de 24µA para el amplificador y 0,5mA para el micrófono, resultando en un total de 0,524mA.
10
2.2.2.2 Receptor GPS
El L80-m39 (figura 2-4) es un receptor GPS con antena incorporada del fabricante element14 cuya función será proporcionar la posición en la que se encuentra el nodo.
Figura 2-4: receptor GPS utilizado en el proyecto
Utiliza el protocolo NMEA 0183 para facilitar los datos extraídos de las señales de los satélites. Este protocolo envía tramas a través de la UART a una frecuencia de 1Hz, es decir, cada segundo se transmite una tipología de trama siguiendo los encabezados especificados en la figura 2-5, del documento adjunto Manual_de_Usuario_Arduino_M2M_Shield, siempre y cuando haya captado señal, para lo que deberá estar a cielo descubierto. En caso de no disponer de suficiente calidad de señal o número reducido de satélites identificados, se reciben las mismas tramas con los campos de información vacíos.
Figura 2-5: formato de las tramas del receptor GPS
En el apartado 3.2.1 se especifican las librerías y funciones que se han utilizado para la correcta gestión de la información de las tramas. No se han utilizado todas ya que para este proyecto solamente se deseaba obtener los datos correspondientes a la posición geográfica:
longitud y latitud.
11
De acuerdo al documento adjunto L80 Hardware Design V1.1 este módulo dispone de los siguientes modos de funcionamiento:
Full On. Es el modo que permite recibir datos y, por tanto, el que más recursos necesita y más consume. El funcionamiento se basa en buscar satélites y determinar cuáles están disponibles. Una vez determinados, pasa a rastrearlos constantemente y decodificar las señales que recibe para transmitirlas en forma de tramas a cada segundo.
Se activará cada 20 minutos hasta que sea capaz de determinar la geolocalización o se supere 1 minuto sin conseguirlo, en cuyo caso los campos latitud y longitud de la trama de datos que se envíe al servidor serán igual a cero.
Se ha comprobado que la primera vez que se desea determinar la geolocalización tras encender el receptor GPS requiere de un tiempo aproximado entre 30 y 45 segundos a cielo descubierto, mientras que después 5 segundos suelen ser suficiente para volverla a determinar.
El consumo en este modo es de aproximadamente 25mA a 3,3V.
Standby. Al acceder a este modo de ahorro de energía se detiene la búsqueda y rastreo de satélites, lo que provoca que el tiempo que requiere el receptor desde que se despierta hasta que vuelve a recibir datos es variable.
Para acceder a este modo se debe enviar el comando “$PMTK161,0*28” y se puede volver a activar el modo Full On en cualquier momento enviando cualquier carácter a través de la UART del receptor GPS.
Se utilizará por lo menos 19 de cada 20 minutos, alternándolo con el modo Full On cuando se requiera recoger información.
Este es el modo que se ha implementado, cuyo consumo es de aproximadamente 1mA a 3,3V.
Backup mode. Es el modo de más bajo consumo en el que únicamente se alimenta el pin V_BCKP. Uno de los inconvenientes que presenta es que para acceder a él se debe incluir un circuito externo que funcione como interruptor tal y como se muestra en la figura 2-6 perteneciente al documento L80 Hardware Design V1.1.
Figura 2-6: circuito necesario para implementar el modo backup en el receptor GPS
12
El acceso a este modo se debe realizar manteniendo baja la señal GPS_EN y enviar el comando “$PMTK225,4*2F”, si bien esto hará que se acceda a este modo para siempre, por lo que no es una opción. Para evitar que esto suceda se debe utilizar implementándolo combinado en alguno de los 2 métodos que se explican a continuación, Periodic mode y AlwaysLocate mode.
El consumo puede llegar a ser de tan solo 7uA.
Periodic mode. Permite alternar entre los modos Full On y Standby/Backup debiéndose indicar previamente los periodos de tiempo que se debe permanecer en cada uno de ellos.
Se ha descartado su uso para poder pasar del modo Full On al modo Standby una vez se haya recibido una nueva posición, acortando así los periodos de tiempo en los que se mantiene activado el modo Full On y consiguiendo un mayor ahorro de energía.
Para acceder a este modo se debe enviar un comando con el formato establecido en la figura 2-7 perteneciente al documento L80 Hardware Design V1.1:
Figura 2-7: formato del comando para acceder al modo periódico del receptor GPS
El consumo en este modo de calcula a partir de los tiempos establecidos en los que debe permanecer en cada modo aplicando la siguiente fórmula:
Donde T1 es el tiempo en modo Full On y T2 el tiempo en los modos standby o Backup.
13
En la figura 2-8 del documento L80 Hardware Design V1.1 se muestran dos ejemplos del consumo del módulo en Periodic Mode:
Figura 2-8: ejemplo de consumo del receptor GPS en dinstintos modos de funcionamiento
En el primer ejemplo se alterna entre los modos Full On y Standby y en el segundo entre Full On y Backup, siendo inferior el consumo en el segundo.
AlwaysLocate. Se trata de un modo inteligente capaz de alternar de manera autónoma entre los modos Full On y Standby/Backup según las condiciones ambientales y de movimiento permitiendo mantener una referencia de geolocalización, teniendo como principal inconveniente cierta pérdida de precisión.
El acceso a este modo se realiza introduciendo el comando “$PMTK225,8*23” para el caso de alternar entre los modos Full On y Standby, del que se debería recibir la respuesta
“$PMTK001,225,3*35”, o introduciendo el comando “$PMTK225,9*22” para alternar entre los modos Full On y Backup, del que se debería recibir la respuesta “$PMTK225,0*2B”.
El consumo en este modo es de 3.5mA cuando se alterna entre Full On y Standby y de 3mA cuando se alterna entre y Full On y Backup.
Se ha descartado su uso por tener mayor consumo y peor precisión respecto a la implementación elegida.
14
2.2.3 Conexión a la red
Una función imprescindible de un nodo IoT es su capacidad para estar interconectado a la red. Para dotarlo de esta capacidad y con la intención de utilizarlo en redes wifi se ha utilizado un transmisor wifi cuyos aspectos más importantes se exponen en el siguiente apartado.
2.2.3.1 Transmisor wifi
El XBEE S6B (figura 2-9) es un transmisor wifi del fabricante DIGI con una potencia máxima de transmisión de hasta 28,75dBm que permite crear conexiones con puntos de acceso wifi. Su función es la de establecer este tipo de conexión a la red con el objetivo de poder enviar tramas para la subida de datos a una plataforma remota para su posterior visualizado y análisis.
Figura 2-9: transmisor wifi utilizado en el proyecto
La configuración del módulo se ha llevado a cabo a través del software XCTU disponible para descarga en la página del fabricante [6]. Dicho software permite definir todos los parámetros que son configurables en este módulo, siendo los más importantes el nombre de la red con la que se va a establecer conexión (SSID), el tipo de clave de seguridad, la propia clave y el modo de bajo consumo elegido, así como habilitar los pines necesarios para la comunicación UART y la activación y desactivación del modo de bajo consumo.
Para llevar a cabo esta configuración el software requiere que el módulo esté conectado al ordenador. Esta conexión ha sido realizada utilizando el dispositivo XBee Explorer USB de Sparkfun (figura 2-10), en el cual se puede colocar el transmisor wifi y conectarlo al ordenador mediante un cable USB-miniUSB.
15
Figura 2-10: conector para configurar el transmisor wifi desde un pc
La figura 2-11 muestra una captura del programa XCTU en el momento de seleccionar el dispositivo del que se desea modificar sus parámetros. Para hacerlo, se debe seleccionar el módulo pulsando en el símbolo add, dentro del rectángulo rojo en la esquina superior izquierda de la figura 2-11.
Figura 2-11: inicio del programa XCTU para configurar el transmisor wifi
Una vez que se ha seleccionado un módulo, la modificación de los parámetros configurables es tan sencilla como modificar los campos con los valores deseados tal como se puede apreciar en la figura 2.12, donde se han habilitado los pines necesarios para la comunicación UART (DOUT y DIN) y la activación y desactivación del modo sleep (SLEEP_REQUEST).
16
Figura 2-12: algunos parámetros configurables del transmisor wifi
El consumo de este componente depende de la configuración de los 2 distintos modos sleep que se pueden implementar, cuyas diferencias según el datasheet adjunto (Xbee Wi-Fi RF Module) son:
- Pin Sleep. Permite que un microcontrolador externo determine cuando debe dormirse y despertarse el módulo a través de los pins SleepRq o SPI_NSSEL.
- Cyclic Sleep. La gestión del tiempo que el módulo permanece en modo sleep se gestiona a través de los comandos AT por UART o SPI y, como el propio nombre indica, los tiempos que el módulo está activo o dormido están previamente establecidos.
Se ha decidido utilizar Pin Sleep para minimizar el tiempo que el módulo está activo y reducir con ello el consumo, evitando también posibles problemas de sincronización entre los modos de bajo consumo del propio módulo y la placa de desarrollo. De igual manera que el receptor GPS, sólo se saldrá del modo de bajo consumo para realizar la tarea destinada para este componente.
En cuanto a las posibles configuraciones de consumo de corriente, la elección de la configuración Associated Sleep sobre Deep Sleep se debe a que, pese a tener esta última un consumo medio más reducido (6µA con Deep Sleep frente a 2mA con Associated Sleep), la configuración Associated Sleep garantiza que no va a haber nunca perdida de información ya que el módulo se mantiene asociado al punto de acceso en todo momento.
Para poder implementar esta configuración se debe conectar el pin 9 del módulo wifi (SLEEP_REQUEST) a uno de los pines digitales de la placa de desarrollo. Declarando dicho pin como salida, se activa el modo sleep por nivel alto (3,3V) y se desactiva por nivel bajo (0V).
De esta manera, una vez se hayan recogido los datos que se quieran transmitir, se podrá desactivar el modo de bajo consumo el tiempo necesario para enviar la información a la plataforma y volverlo a activar justo después, siendo este tiempo ligeramente variable. En la figura 2.13 se muestra como los parámetros SM y SO que se han modificado para la correcta implementación del modo de bajo consumo, habilitando el Pin Sleep y AP Associated Sleep respectivamente.
17
Figura 2-13: configuración del modo sleep del transmisor wifi
18
2.2.4 Alimentación
Para la alimentación del nodo se utilizan baterías AA. Para incluirlas en el nodo se ha incorporado un porta baterías (figura 2-14) con capacidad para incluir 4 baterías, siendo capaz de proporcionar una forma de conectarlo al nodo minimizando el incremento de su tamaño.
2.2.4.1 Porta baterías
La alimentación del nodo se ha llevado a cabo mediante 4 baterías AA de litio de 1.5V y 3000mAh (documento adjunto datasheet_L91_FR6) colocadas en serie para alcanzar un total de 6V. Como se indica en la página de la placa de desarrollo utilizada [5], ésta tiene un regulador de tensión para asegurar una salida de 3,3V estables y que el nodo no se va a apagar en ningún momento. Se recomienda suministrar un mínimo de 6V y no superar los 12V, voltaje que podría dañar la placa.
Figura 2-14: porta baterías utilizado en el proyecto
Se ha conectado a este componente un cable de alimentación DC como salida que se conecta directamente a la placa de desarrollo M0.
2.2.4.2 Análisis de consumos
Una vez seleccionados todos los componentes y antes de entrar en la fase de fabricación de la nueva placa se debe asegurar que la placa Arduino va a ser capaz de suministrar las corrientes necesarias para el óptimo funcionamiento de todos los componentes.
19
En la tabla 2-1 se comprueba con los datos extraídos de la documentación que efectivamente la placa tiene capacidad para alimentar a todos los componentes con corriente suficiente.
M0 (suministra) XBEE S6B L80-m39 Max4466
IMAX (mA) 1000 225 25 0.524
Tabla 2-1: corriente suministrada por la placa y consumida por los componentes
Sumando la máxima corriente requerida por todos los componentes se obtiene un consumo máximo de corriente de IMAX ≈ 250.524mA que deben ser aportados por parte de la placa M0. Teniendo en cuenta que dicha placa puede suministrar un máximo de 1000mA, se puede confirmar que no se darán problemas con el suministro de corriente.
Para calcular el consumo total del nodo se debe tener en cuenta que los tiempos que el nodo pasa en modo de bajo consumo no son siempre los mismos, pudiendo haber pequeñas variaciones dentro de ciclos de 20 minutos. El motivo es que, como ya se ha explicado en los apartados correspondientes a ambos dispositivos, tanto el receptor GPS como el transmisor wifi sólo saldrán del modo sleep el tiempo necesario para realizar su tarea, siendo este tiempo variable. Una vez las hayan realizado, se dormirá durante el tiempo correspondiente para completar el ciclo de 20 minutos de manera que la llegada de datos sí que sea periódica.
Para obtener el consumo teórico se debe utilizar la siguiente fórmula, en la que se suman los distintos consumos de cada componente en cada modo de funcionamiento. Dado que dichos tiempos son variables, se han estimado durante el proceso experimental:
Donde:
= Intensidad total (mA)
= Intensidad full on placa (mA)
= Intensidad sleep placa (mA)
= Intensidad full on GPS (mA)
= Intensidad sleep GPS (mA)
= Intensidad full on wifi (mA)
= Intensidad sleep wifi (mA)
= Tiempo full on placa (s)
= Tiempo sleep placa (s)
= Tiempo full on GPS (s)
20
= Tiempo sleep GPS (s)
= Tiempo full on wifi (s)
= Tiempo sleep wifi (s)
= Intensidad transceptor sonido (mA)
Sustituyendo con los valores extraídos de los datasheets se obtiene:
Para obtener el consumo experimental se ha medido con un voltímetro la caída de tensión en una resistencia a la entrada del circuito durante el modo operativo y el de bajo consumo. Dicha resistencia está formada por 3 resistencias en paralelo con una resistencia teórica de 11Ω, siendo la resistencia real equivalente de 3,9Ω.
Los voltajes obtenidos son de 0.023V durante el tiempo que todos los componentes están en modo de bajo consumo (V1), de 0.232V cuando la placa de desarrollo y el receptor GPS están en modo operativo y el transmisor wifi en modo de bajo consumo (V2), y de 1.002V mientras la placa de desarrollo están en modo operativo y el receptor GPS en modo de bajo consumo (V3).
Con estas medidas y aplicando la Ley de Ohm los consumos resultantes son de 5.90mA, 134.36mA y 256.92mA respectivamente, con lo que ya se puede calcular el consumo experimental:
Con estos datos de consumo y las baterías de 3000mAh seleccionadas, la autonomía teórica y experimental del nodo es de:
21
2.3 Diseño de la PCB
Para diseñar la PCB utilizada en este proyecto (figura 15), cuyos archivos se encuentran adjuntos como PCB_nodoIoT_JMM, se ha utilizado el software Eagle 7.7, descargable desde la página web de Autodesk [7]. Para cada PCB se generan dos archivos, uno para el diseño esquemático y otro para el layout. Estos archivos estarán vinculados entre ellos, por lo que una modificación en uno de ellos afecta también al otro.
Este programa presenta la gran ventaja de poder incluir librerías creadas por otros usuarios que incluyen bloques que representan distintos componentes (resistencias, baterías, sensores…), pudiendo evitarse así tener que crear los bloques de los componentes que no vengan incluidos en las librerías propias de la versión 7.7.
Las librerías del receptor GPS, del transmisor wifi y del transceptor de sonido fueron proporcionadas por el tutor del proyecto, pues ya había trabajado con estos elementos previamente y disponía de los bloques. Por lo tanto, no ha sido necesario crear ninguna librería para ningún elemento.
Figura 2-151: PCB utilizada en el proyecto
Esta PCB se ha diseñado específicamente para poder acoplarla y desacoplarla tantas veces como se desee al modelo M0 de Arduino, pudiéndose utilizar también para otros modelos del mismo fabricante como las placas ZERO o UNO, entre otras. Para ello se ha partido de los archivos del diseño esquemático y de layout que proporciona Arduino de la placa M0 [5].
La fase previa a la fabricación de una PCB se divide en dos etapas de diseño: la primera a nivel esquemático, donde se incluyen todos los componentes que se van a situar sobre la PCB y como se van a conectar entre ellos. La segunda a nivel de layout, donde se establecen las dimensiones de la PCB y las vías o caminos que van a seguir esas conexiones, así como la ubicación de los componentes a escala real.
En cambio en este caso, al disponer de partida de ambos archivos, resulta más cómodo retirar en el layout todos aquellos elementos y vías que no se vayan a incluir en el diseño y posteriormente incluir en el esquemático los componentes del nodo. Finalmente, y de nuevo en el layout, se deben situar de manera adecuada sobre la PCB.
En los siguientes apartados se explica como se ha realizado el diseño de esta PCB paso a paso.
22
2.3.1 Layout
Como ya se ha mencionado anteriormente, el punto de partida es el layout de la placa M0 facilitado por Arduino (figura 2-16). La distribución de los componentes y las vías se ha llevado a cabo con la idea de no ampliar el tamaño del nodo en superficie obteniendo un conjunto fácil de ubicar en cualquier localización. De este archivo original, el único interés es aprovechar el contorno de la placa M0 como plantilla y las filas de zócalos, que se deben mantener en la misma ubicación para poder acoplar y desacoplar la PCB a la placa M0.
Figura 2-16: layout de la placa Arduino M0
Por tanto, el primer paso a realizar es eliminar el resto de elementos y la circuitería, cuyo resultado puede apreciarse en la figura 2-17. Cabe destacar que todos los elementos que se retiren en este archivo se desvincularán automáticamente del esquemático asociado a este diseño.
Figura 2-17: layout de la PCB sin componentes
23
El siguiente paso consiste en añadir en el esquemático los componentes que van a formar parte del nodo y las conexiones entre ellos (apartado 2.3.2). En la figura 2-18 se muestra el estado del layout tras realizar esta acción. En los zócalos dentro de los rectángulos de color lila irá situado el receptor GPS, en los del rectángulo amarillo el transceptor de sonido y en los del rectángulo marrón el transmisor wifi.
Figura 2-18: layout de la PCB sin vías
A continuación, se debe definir el recorrido de las vías para establecer las conexiones entre los componentes. Los criterios seguidos para determinar los trazos de las vías son los siguientes, todos ellos con el objetivo de mantener la mejor calidad posible de las señales eléctricas:
- Minimizar la longitud de las vías.
- Evitar cruces entre vías.
- Introducir el mínimo número posible de cambios de dirección.
- Utilizar una única cara de la PCB.
El resultado después de haber incluido todas las conexiones entre los componentes y las conexiones extra se muestra en la figura 2-19.
24
Figura 2-19: layout de la PCB con todos los componentes y vías
Finalmente y como consejo del tutor, se añadieron tres bloques de vías auxiliares para poder utilizar como puentes en el futuro en caso de algún problema eléctrico o con la intención de añadir algún componente (figura 2-20). Además, se realizó una última conexión para habilitar la implementación del modo sleep del transmisor wifi a través del pin sleep_RQ como se ha explicado en el apartado 2.2.3.1.
Figura 2-20: layout definitivo de la PCB
Una vez acabado, se envió el archivo layout al laboratorio de robótica para su fabricación, proceso que se puede consultar en el anexo A.
25
2.3.2 Esquemático
En este caso, el punto de partida es el archivo del esquemático de la placa M0 (figuras 2-21 y 2-22). El esquemático resultante tras la retirada en el layout de todos los elementos y las vías que no se deseaban aprovechar (apartado 2.3.1) se muestra en la figura 2-23 (se ha centrado la imagen en los elementos para comodidad del lector). En ella figuran los bloques correspondientes a las filas de zócalos de la placa M0.
Figura 2-21: esquemático de la placa Arduino M0 (hoja 1)
26
Figura 2-22: esquemático de la placa Arduino M0 (hoja 2)
Figura 2-23: componentes a aprovechar para la PCB
27
El siguiente paso fue añadir los bloques correspondientes al transceptor de sonido, el receptor GPS y el transmisor wifi, que se encuentran representados de izquierda a derecha respectivamente en el interior de los recuadros azules en la parte superior de la figura 2-24.
También se duplicaron los zócalos para que, una vez fabricada la PCB y en caso de necesidad, sea posible soldar algún elemento extra o cable si se presentase algún imprevisto, como pueden ser una señal que no se recibe correctamente.
Figura 2-24: esquemático definitivo de la PCB
En caso de que dos o más vías compartan una misma etiqueta, pasan a formar una conexión aunque el cable verde no esté conectado a ambos extremos. Esta funcionalidad permite crear esquemas con aspecto más sencillo y menos cargado, evitando conexiones excesivamente largas y cruces entre ellas.
Se han establecido etiquetas en los pines a utilizar del transceptor de sonido, del receptor GPS y del transmisor wifi. Éstas coinciden con las etiquetas de los pines correspondientes a los zócalos de la parte media e inferior del esquema para interconectar estos componentes a la placa M0.
28
Los nombres de las vías que no tenían ninguna función se han retirado para facilitar la comprensión del esquema.
Así, se puede apreciar que tanto el transceptor de sonido como el receptor GPS y el transmisor wifi están conectados a GND (tierra) y a 3,3V. Además de estos pines, también están conectados los necesarios para la comunicación con el microcontrolador de la placa Arduino.
En el caso del transceptor de sonido está conectada la salida analógica al ADC de la placa M0.
Por otra parte, el transmisor wifi tiene conectado su pin transmisor UART al pin receptor de la primera UART de la placa M0 con una conexión denominada M0_TX0, y su receptor UART al pin transmisor de la primera UART en la placa M0 con otra conexión denominada M0_RX0. Además, para poder controlar el modo de bajo consumo del transmisor wifi se ha establecido una conexión denominada SLEEP_RQ entre el pin 9 de dicho transmisor al pin digital 10 de la placa de desarrollo.
Finalmente, el caso del receptor GPS es muy similar al del transmisor wifi, con la diferencia de que el receptor GPS tiene conectado su pin transmisor UART al pin receptor de la segunda UART de la placa M0 con una conexión denominada M0_TX1, y su receptor UART al pin transmisor de la segunda UART en la placa M0 con otra conexión denominada M0_RX1.
En este punto no se debe realizar ninguna tarea más en el esquemático y sólo queda definir el recorrido de las vías y la ubicación exacta de los componentes sobre la PCB en el layout para finalizar su diseño (apartado 2.3.1).
29
Capítulo 3. Firmware del nodo
3.1 Plataforma web 3.1.1 Introducción
Una vez determinado el hardware necesario para poder establecer una conexión a la red, es necesario establecer también cuál será la plataforma que se utilizará para subir la información que reciba el nodo IoT. Se necesita una plataforma que permita enviar las medidas que tomen los sensores en tiempo real y visualizar la información desde un ordenador.
Por consejo del tutor del proyecto se decidió utilizar Sentilo [8]. Se trata de un software gratuito de código abierto dirigido a las ciudades inteligentes, cuyo objetivo es explotar la información generada por la propia ciudad a través de una red de sensores y actuadores interconectados a la red.
Entre otros colectivos, está enfocada a aquellos que estén interesados en contribuir a la expansión del IoT y las ciudades inteligentes con la idea de mejorar la calidad de vida de la población.
Las principales ventajas que ofrece esta plataforma son:
- Plataforma gratuita.
- Posibilidad de visualizar la información desde un ordenador.
- Simplicidad a la hora de subir datos.
- Actualización de los datos en tiempo real.
- Visualización de la localización real de los nodos.
- Consulta de los últimos 10 últimos datos subidos de cada sensor.
- Posibilidad de añadir una gran cantidad de nodos y sensores.
Antes de poder hacer uso de esta plataforma se debe descargar el código desde la web de Sentilo [9] para poder instalar la máquina virtual Sentilo – Ubuntu Server 14.04.2 LTS 32b junto con Una vez hecho, se accede con un login a través de un navegador, introduciendo una URL que debe seguir el siguiente formato:
http://ip:port/sentilo-catalog-web/
En este caso la URL correcta sería la siguiente:
http://192.168.1.50:8080/sentilo-catalog-web/
Finalmente, se deben introducir las credenciales de acceso user y password, que por defecto son:
User: admin Password: 1234
30
3.1.2 Configuración
La plataforma Sentilo cuenta con una pantalla de inicio (figura 3-1) en la que destaca un botón Start que permite acceso al panel de control (figura 3-2) desde el que se puede crear, modificar y gestionar todo aquello relativo al nodo IoT del proyecto desde distintos menús.
Figura 3-1: pantalla de inicio de Sentilo
A continuación se detallan los aspectos más relevantes para este proyecto de cada uno de ellos:
- Organization. Se pueden modificar los datos básicos (nombre de la organización, correo electrónico de contacto, etc) y se puede configurar la posición en el mapa terrestre sobre la que se situará la aplicación al iniciarse, que por defecto es en la ciudad de Barcelona.
En la figura 3-1 se puede apreciar que se ha modificado esa posición para que la imagen esté centrada en la ubicación real desde donde se han tomado las muestras para este proyecto, en Palma.
31
Figura 3-2: panel de control de Sentilo
- Users. Se pueden dar de alta y de baja usuarios para la plataforma que tengan acceso al panel de control. Se les debe asignar un nombre de usuario, contraseña, descripción, etc.
Existen tres tipo de usuarios:
Admin. Puede crear, editar y eliminar usuarios, además de gestionar el resto de elementos del panel de control (componentes, sensores…).
Platform. Con los mismos permisos que admin excepto en la gestión de usuarios.
User. Pueden visualizar toda la información disponible desde el panel de control pero no pueden llevar a cabo ninguna modificación.
Para este proyecto no ha sido necesario crear ningún usuario extra, se han utilizado los que ya se incluyen por defecto.
- Applications. Por defecto se crean dos siendo la más importante sentilo-catalog, que es la aplicación interna que hace las llamadas a la API (figura 3-3). La segunda de ellas, TestApp, no se ha utilizado en ningún momento.
Figura 3-3: application por defecto de Sentilo
- Providers. Es el encargado de enviar los datos, el proveedor. Para poder hacerlo, cada provider tiene un Autorization Token, que es una clave identificativa para que sólo los usuarios con acceso a ella puedan tratar los datos, que será necesario incluir en el código que ejecutará la placa Arduino para poder publicar datos.
Cada provider tiene asocioados componentes, sensores, actuadores y suscripciones que pueden ser consultados.
Dado que todas las pruebas se han realizado en el mismo sitio, se ha creado un provider con el nombre casa.
32
- Components. En este entorno, los componentes se utilizan para agrupar sensores que tienen propiedades en común. En el caso de este proyecto el receptor GPS y el transceptor de sonido forman un componente al pertenecer mismo nodo (figura 3-4).
Los componentes pueden ser estáticos o móviles. Esta característica influye a la hora de reflejar en el mapa la posición de cada uno de ellos. El componente que se ha creado para este proyecto es móvil, pues cada vez que se envía una trama se desea actualizar la posición en el mapa con la latitud y longitud obtenidas.
En caso de crear uno estático se le tiene que asignar unas coordenadas de latitud y longitud fijas.
Al dar de alta los componentes que se quieran incluir en la plataforma, se deben asociar a un provider.
Se ha creado un componente llamado IoT de tipo móvil.
Figura 3-4: componente creado para el proyecto en Sentilo
- Sensors/actuators. Permite la gestión de dichos dispositivos, pudiendo crearlos, modificarlos y eliminarlos, además de consultar los últimos datos de cada uno de ellos.
En la figura 3-5 se muestra los campos que es necesario rellenar a la hora de crear un sensor para a plataforma y se puede apreciar como cada sensor se debe asociar a un provider y a un component. Todos los campos excepto los 2 primeros (sensor/actuator y provider) son modificables una vez se ha creado el sensor.
33
Figura 3-5: formulario para dar de alta sensores y actuadores en Sentilo
Para poder visualizar los sensores en el mapa de la aplicación se deben establecer como públicos (quinta opción en la figura 3-5), de lo contrario no aparecerán.
Como se explica en el apartado types of sensors/actuartors de esta misma sección ha sido necesario crear dos tipos de sensores ya que el número de tipos que ofrece Sentilo es bastante reducido.
Como se ve en la figura 3-6 se han tenido que crear tres sensores (Micófono, latitudGPS y longitudGPS) en este apartado pese a que físicamente sólo se han incluido dos.
Figura 3-6: sensores dados de alta para el proyecto en Sentilo
El motivo de haber creado dos sensores en vez de uno para el receptor GPS es que cada sensor sólo puede contener un valor numérico, por lo que no era posible incluir la latitud y la longitud en uno solo.
- Alerts. Sentilo incluye la opción de programar avisos para situaciones concretas, como podría ser un valor muy elevado si se está midiendo la temperatura de una cámara frigorífica. No se ha hecho uso de esta opción en este proyecto.
34
- Types of sensors/actuators. Existe una gran cantidad de tipos de sensores/actuadores y sólo unos pocos vienen definidos en Sentilo. Si se desea añadir un tipo de sensor/actuador que no viene predefinido en la plataforma se puede crear en este apartado.
En el punto anterior sensors/actuators de este mismo apartado se explica que se han tenido que crear dos sensores para las posiciones GPS. No existe ningún tipo de sensor en la plataforma llamado latitud y longitud por lo que ha sido necesario crearlos.
Aparecen en la figura 3-7 junto a los incluidos de inicio.
El tipo de sensor para el transceptor de sonido ya estaba incluido en Sentilo como noisemeter.
Figura 3-7: tipos de sensores que se pueden dar de alta en Sentilo
- Types of components. Se trata del mismo caso que el anterior pero con componentes en vez de sensores/actuadores. No se ha creado ningún tipo de componente.
Si se desea conocer más información acerca de alguno de estos apartados puede ser consultada en la página web de Sentilo[11].
3.1.3 Envío de datos
La subida de datos a Sentilo se realiza utilizando el protocolo HTTP con tramas que incluyen peticiones PUT con el formato JSON. En cada trama se debe incluir la siguiente información:
- Tipo de petición. En este proyecto únicamente se harán peticiones tipo PUT. Con tramas tipo GET se podría consultar el histórico de datos que se va almaceando.
- Identity_key. Aplication token del provider al que se desean subir los datos.
- Host. Dirección IP asignada a la máquina virtual.
- Connection. Indica si se mantendrá la conexión una vez enviada la trama.
- Content-Length. Longitud de la trama.
- Content-type. Indica el tipo del contenido que se requiera subir a la plataforma.
35
- Trama. Incluye la información/datos que se desea subir a la plataforma. Se pueden incluir uno o más valores de uno o más sensores en una sola trama.
En la figura 3-8 se muestra un método del código Arduino utilizado durante el periodo de pruebas para verificar que los datos incluidos en las tramas se enviaban satisfactoriamente a la plataforma. En ella se puede apreciar la inclusión de todos los campos enumerados previamente. Debe ser mencionado que en la línea 113 casa y sensorPrueba son el provider y el sensor respectivamente de los que se va a registrar el valor (10 en este caso) incluido en el campo Trama (línea 119).
Figura 3-8: método para verificar la llegada de datos a Sentilo
Con el código utilizado, adjunto en el archivo código_nodoIoT_JMM, el nodo enviará dos tramas similares a la de la figura 3-8 cada vez que se requiera publicar datos, una primera trama para el envío de las medidas de ruido ambiental, longitud y latitud, y una segunda trama para actualizar la posición del nodo en el mapa.
3.1.4 Consulta y visualización de datos
Existen dos maneras distintas de consultar la información proporcionada por los sensores en la plataforma Sentilo, desde el mapa y desde el apartado sensors/actuators.
- El acceso al mapa se realiza a través del menú despegable con la etiqueta explore que se aprecia en la figura 3-1. Esto permite la opción de mostrar un mapa con la interfaz de Google Maps de dos formas diferentes: universal viewer y route viewer. La diferencia entre ellas es que universal viewer simplemente muestra todos los componentes públicos dados de alta en la plataforma en su última ubicación mientras que route viewer permite ver la ruta seguida por los componentes móviles mostrando los últimos 20 puntos desde los que han realizado transmisiones.
Esta opción para la visualización se muestra en las figuras3-9 y 3-10, donde se ve un símbolo que representa el nodo en la localización donde se han llevado a cabo las pruebas. La primera de ellas (figura 3-9) es previa a clicar sobre el símboloy no muestra información alguna. Después de clicar (figura 3-10), se pueden visualizar los últimos datos recibidos por un componente. Esta funcionalidad toma sentido en caso de haber dado de alta varios nodos para no saturar la pantalla con información.
36
Figura 3-9: vista del componente en el mapa de Sentilo
Figura 3-10: detalle de los datos recibidos por el componente
- La segunda forma de visualización es accesible desde el panel de control del apartado sensors/actuators (figura 3-11), clicando en la pestaña Latest data. En este caso se pueden consultar las últimas 10 medidas de un sensor en particular (figura 3-12).
37
Figura 3-11: atributos de uno de los sensores dados de alta
Figura 3-12: vista de los últimos 10 datos recibidos de un sensor
38
3.2 Programación Arduino
Establecidos todos los bloques necesarios, los componentes que van a formar cada uno de ellos e instalado el software para poder configurarlos y gestionarlos, se debe proceder la fase de programación del nodo, que se lleva a cabo íntegramente con el IDE de Arduino.
Al utilizar este IDE, cualquier programa debe contener por lo menos las dos partes que se muestran en la figura 3-13, las funciones setup() y loop(), donde la primera de ellas es la encargada de establecer la configuración del nodo y la segunda contiene un programa que se ejecutará en bucle indefinidamente.
Figura 3-13: estructura de un código para Arduino
La función setup() sólo se va a ejecutar una única vez al inicio del programa y, en este caso, se va a utilizar para establecer los pines como entradas o salidas y establecer la configuración de las comunicaciones serie.
La función loop() se ejecutará una vez lo haya hecho la función de configuración. En esta función/bucle se llamará a las rutinas para poder tomar lecturas de los sensores y se gestionarán los tiempo para minimizar el consumo de energía haciendo uso de los modos sleep de los distintos componentes.
Esta estructura puede verse ampliada con declaraciones e inicializaciones de variables antes de la función setup() o añadiendo librerías y métodos después del bucle principal. Las librerías y métodos que se utilizan para este proyecto se explican en los siguientes apartados de este capítulo.
39
3.2.1 Librerías
Para el desarrollo del código se han utilizado cuatro librerías que implementan funciones necesarias para el nodo: SoftwareSerial, EnergySaving, RTCInt y TinyGPSPlus. Las tres primeras ya están incluidas en el IDE descargado previamente [4].
- La primera liberería, SoftwareSerial, permite comunicaciones UART usando cualquier pin digital de la placa M0. Los aspectos más importantes a tener en cuenta son:
- Se debe crear un objeto con la instancia SoftwareSerial mySerial(Rx, Tx), donde mySerial es el nombre que se quiera dar al nuevo objeto y Rx y Tx los pines de la placa de desarrollo que se quieren utilizar para recibir y transmitir datos respectivamente. A continuación se tiene que iniciar la conexión indicando el baud rate o número de unidades de señal por segundo, por ejemplo begin.uartGPS(9600).
- Si se establece más de una conexión en un mismo código, la placa M0 sólo puede recibir datos por una de ellas a la vez, por lo que cada vez que se quiera recibir información por un puerto de comunicaciones distinto se tendrá que utilizar la función listen() referenciada a este objeto, por ejemplo uartGPS.listen().
- Las dos funciones más utilizadas son read(), que lee la información que llega por el pin configurado como receptor y print(), para enviar datos por el pin configurado como transmisor.
- La segunda librería, EnergySaving, permite implementar el modo de bajo consumo en las placas Arduino con el microcontrolador ATSAMD21G18. Para realizarlo introduce al microcontrolador en modo de espera, del que se puede salir tanto por interrupción externa como por alarma del reloj incorporado en la placa (RTC).
Los 2 métodos básicos que proporciona esta librería son:
- begin(WAKE_RTC_ALARM): habilita la opción de introducir el microcontrolador en modo de bajo consumo con salida por interrupción del RTC.
- standby(): se utiliza para dormir el microcontrolador. Cuando se da una interrupción externa o del RTC, el microcontrollador se despierta.
- La tercera librería, RTCInt, permite utilizar el RTC incorporado en las placas Arduino de la gama M0. En este proyecto se utilizará para salir del modo de ahorro de energía.
Los métodos que se deben usar son:
- enableAlarm(): habilita el uso de alarmas para poder despertar el microcontrolador cuando esté en standby.
- SetTime() y setDate(): inicializa la hora y fecha en el RTC.
- setAlarm(): activa una alarma. La hora a la que se disparará se debe establecer en la variables time.second, time.minute y time.hour antes de utilizar este método, que a su vez se debe utilizar antes de dormir la placa.
