Sistema de seguridad para personas dependientes

i

Proyecto Fin de Carrera

Ingeniería de Telecomunicación

Sistema de seguridad para personas dependientes

Autor: Rodrigo Pajares Barroso

Tutor: Alfredo Pérez Vega-Leal

Dep. Ingeniería Electrónica

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2016

iii

Proyecto Fin de Carrera

Ingeniería de Telecomunicación

Sistema de seguridad para personas dependientes

Autor:

Rodrigo Pajares Barroso

Tutor:

Alfredo Pérez Vega-Leal

Profesor titular

Dep. Ingeniería Electrónica

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2016

v

Proyecto Fin de Carrera: Sistema de seguridad para personas dependientes

Autor: Rodrigo Pajares Barroso

Tutor: Alfredo Pérez Vega-Leal

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2016

El Secretario del Tribunal

vii

A mi familia, y en especial a mis

padres.

ix

Agradecimientos

A mis padres, a mis abuelos por ser una inspiración continua, a toda mi familia por estar siempre conmigo, en

los buenos y en los malos momentos, a lo largo de esta etapa de mi vida y a todos mis amigos, compañeros y

profesores que me han ayudado a cerrar con éxito este ciclo de mi formación.

xi

Resumen

El proyecto se basa en el diseño e implementación de un sistema de asistencia para personas con problemas de

salud, con necesidades especiales o de una avanza edad. Con el fin de alcanzar este objetivo, se ha

implementado un sistema que tiene como pieza central una placa Arduino Uno Rev3, y esta obtiene distintos

datos de los distintos módulos que forman el sistema. Con esos datos se pone en funcionamiento un sistema

que tiene capacidad para detectar caídas, establecer zonas de seguridad, recoger llamadas del pulsador de

emergencia y tener un contacto continuo en el tiempo a través de la red GSM.

Tras un análisis previo de los distintos microcontroladores del mercado, se optó por Arduino. Esta elección se

llevó a cabo por el interés que tenía conocer estos microcontroladores, que además de ser de software libre

tienen la ventaja de que existe gran cantidad de información en torno a estas placas.

El sistema implementa las funciones anteriormente descritas a través de los distintos módulos que lo forman,

GSM, GPS e IMU. Se diseñan las comunicaciones con estos módulos, y tras esto, se adquieren datos que son

tratados a través de distintos algoritmos por el microprocesador. Finalmente estos algoritmos son

implementados por un algoritmo principal que es el que hace posible que el sistema funcione correctamente.

xiii

Abstract

The project is based on the design and implementation of a system of care for people with health problems,

with special needs or older age. In order to achieve this goal, we have implemented a system that has as main

piece an Arduino Uno Rev3 board, Arduino gets different data from different modules that make up the

system. With these data a system that has ability to detect falls, establish safety zones, emergency button and

have continuous contact over time through the GSM network .

After a preliminary analysis of the different microcontrollers on the market, we select Arduino. This election

was held for the interest that had to know these microcontrollers, which besides being free software have the

advantage that we have lot of information around these boards

The system implements the funtions through the various modules that form the system, GSM, GPS and IMU.

Firts, we designed communications with these modules, then data are processed by the microprocessor.

Finally, these algorithms are implemented by a main algorithm which is what makes it possible for the system

to function properly.

Índice

Agradecimientos ix

Resumen xi

Abstract xiii

Índice xiv

Índice de Tablas xvi

Índice de Figuras xviii

Notación xxi

1 Introducción 1 1.1 Objetivos del proyecto 5

2 Fundamentos teóricos 7 2.1 Sistemas de referencia en navegación 7

2.1.1 Sistemas de coordenadas en navegación 7 2.2 IMU: Sensores Inerciales 12 2.3 Sistemas de navegación por satélite(GNSS) 14

2.3.1 Global Positioning System (GPS) 14 2.4 Global System Mobile 18

2.4.1 Arquitectura GSM 18 2.4.2 Servicios GSM 20

3 HARDWARE 22 3.1 Arduino Uno rev3 22 3.2 Sensor inercial MPU-9050 25 3.3 Modulo GPS 26

3.3.1 Sentencias NMEA 28 3.4 Modulo GSM 32

3.4.1 Comandos AT o Hayes 33

4 SOFTWARE 35 4.1 Arduino IDE 35 4.2 Matlab 36 4.3 Google Earth Pro 36

5 Arquitectura y desarrollo del sistema 38 5.1 Esquema electrónico general 38 5.2 Alimentación del Sistema 39 5.3 Protocolos de comunicación 42

5.3.1 Protocolo I2C 43 5.3.2 Protocolo UART-TTL 44

5.4 Desarrollo de Algoritmos 45 5.4.1 Algoritmo de detección de caídas 46 5.4.2 Algoritmo de localización 62 5.4.3 Algoritmo de envío de SMS 70 5.4.4 Algoritmo principal 70

xv

6 Resultados 75

7 Conclusiones 80

Referencias 83

Índice de Conceptos 86

Glosario 88

Anexo A: Librerías 89

Anexo B: Esquemáticos 115

Índice de Tablas

Tabla 1 – Población anciana en el mundo 2

Tabla 2 – Tramas NMEA 28

Tabla 3 – Trama datos GGA 28

Tabla 4 – Indicador de posición fijada 29

Tabla 5-– Trama de datos GSA 29

Tabla 8 – Trama GSV 30

Tabla 6 – Modo 1 GSA 30

Tabla 7 – Modo 2 GSA 30

Tabla 9 – Trama RMC 31

Tabla 10 – Trama VTG 32

Tabla 11 - Consumo 42

Tabla 12 – Umbrales de caídas 59

Tabla 13 - Presupuesto 81

Índice de Figuras

Figura 1- Población mayores 65 años 3

Figura 2 - Clasificación Motivos soledad personas mayores 4

Figura 3 – Sistema de envío SMS 6

Figura 4 – Sistema ECI 8

Figura 5 – Sistema ECEF 9

Figura 6 – Sistema referencia topocéntrico 9

Figura 7 - LLS 10

Figura 8 – Sistema de referencia azimut 11

Figura 9 – Sistema de ejes de cuerpo 11

Figura 10 – Acelerómetro tradicional 13

Figura 11 – Acelerómetro MEMS 13

Figura 12 – Sistema GPS 15

Figura 13 – Segmento de control GPS 16

Figura 14 – Segmentos GPS 16

Figura 15 - Localización GPS 17

Figura 16 – Arquitectura funcional GSM 19

Figura 17 – Sistema GSM 20

Figura 18 – Arduino Uno Rev3 23

Figura 19 – Atmega328p mapa de pines 24

Figura 20 – MPU 9150 25

Figura 21 – Ultimate GPS Adafruit 27

Figura 22 – Modulo GSM/GPRS Lonet 32

Figura 23 – Arduino IDE 35

Figura 24 - Google Earth Pro 36

Figura 25 – Esquema electrónico general 38

Figura 26 – Consumo de microprocesador ATmega328p 40

Figura 27 – Esquema eléctrico alimentación 41

Figura 28 – Alimentación del sistema 41

Figura 29- Medición consumo en el laboratorio 42

Figura 30 – Maestro y esclavo I2C 43

Figura 31 – Trama de datos I2C 44

Figura 32 – Trama de datos UART 45

Figura 33 – Fases de una caída 46

Figura 34 – Tiempo en las fases de una caída 47

xix

Figura 35 – Ejes respecto al cuerpo 48

Figura 36 – Prueba caída hacia adelante 49

Figura 37 – Prueba caída hacia adelante aceleración total 50

Figura 38 – Prueba caída hacia atrás 50

Figura 39 –Prueba caída hacia atrás aceleración total 51

Figura 40 - Prueba caída lateral leve 51

Figura 41 - Prueba caída lateral leve aceleración total 52

Figura 43 – Prueba caída lateral aceleración total 53

Figura 42 - Prueba caída lateral 53

Figura 44 – Prueba acostarse en una cama 54

Figura 45 – Prueba acostarse en una cama aceleración total 54

Figura 46 – Prueba sentarse en una silla 55

Figura 47 - Prueba sentarse en una silla aceleración total 56

Figura 48 - Prueba bajar escaleras 56

Figura 49 - Prueba bajar escaleras aceleración total 57

Figura 50 - Prueba levantarse tras caída 58

Figura 51 – Prueba levantarse tras caída 58

Figura 52 – Diagrama de flujo algoritmo de caídas 60

Figura 53 – Meridianos y paralelos 63

Figura 54- Zona de seguridad 1 63

Figura 55 – Zona de seguridad 2 64

Figura 56 – Zona de seguridad 3 65

Figura 57 – Zonas de seguridad 66

Figura 58 – Diagrama de Flujo Algoritmo de zonas 69

Figura 59 – diagrama de flujo algoritmo principal 74

Figura 60 – SMS pulsador 75

Figura 61 – SMS caída 76

Figura 63 – SMS zona 3 77

Figura 62 – SMS zona 2 77

Figura 64 – SMS zona peligrosa 78

Figura 65 – SMS vuelta a zona 1 79

xxi

Notación

ax Modulo de la aceleración en el eje x

ay Módulo de la aceleración en el eje y

az Módulo de la aceleración en el eje z

aceltotal Suma del modulo de las aceleraciones

GSM Global System for Mobile

SMS Short Message Service

GPS Global Position System

IMU Inertial Measurement Unit

GNSS Global Navigation Satelite System

LED Light Emisor Diode

IMSERSO Instituto de Mayores y Servicios Sociales

INE Instituto Nacional de Estadística

MPU Multiple Process Unit

MEMS Microelectromechanical Systems

ECEF Earth-Centered, Earth-Fixed

ECI Earth Centered Inertial

EEUU Estados Unidos

CE Comunidad Europea

ETSI European Telecommunications Standards Institute

RDSI Red Digital de Servicios Integrados

I2C Inter-Integrated Circuit

UART Universal Asynchronous Receiver-Transmitter

TTL Transistor-Transistor Logic

NMEA National Marine Electronics Association

e número e

sen Función seno

tg Función tangente

arctg Función arco tangente

sen Función seno

sinxy Función seno de x elevado a y

cosxy Función coseno de x elevado a y

Sa Función sampling

sgn Función signo

rect Función rectángulo

Sinc Función sinc

∂y ∂x

x◦

Derivada parcial de y respecto

Notación de grado, x grados.

Pr(A) Probabilidad del suceso A

SNR Signal-to-noise ratio

MSE Minimum square error

: Tal que

< Menor

> Mayor

\ Backslash

1

1 INTRODUCCIÓN

There´s nothing I believe in more strongly than getting young people

interested in sicence and engeneering, for a better tomorrow, for all

humankind

Bill Nye

Este proyecto está pensado para la asistencia a las personas de la tercera edad, para que este grupo de

población pueda sentirse autónomo y a la vez seguro, proporcionando a sus familiares la tranquilidad de

saber que el anciano va a estar continuamente localizado, y con unos sistemas de seguridad a su servicio.

Para cuantificar el sector de población al que va dirigido este proyecto, se toma el informe de 2012 del

IMSERSO de las personas mayores en España. En un primer texto se va a ver el tamaño y la evolución de

este grupo de población que va en aumento desde hace unos años.

En España, según los datos oficiales del Censo del 2011 había 46.815.916 habitantes. De ese conjunto de

población, las personas de 65 y más años representaban el 17,3% (8.116.350 personas) frente al 16,6% en

el año 2009. Y de ese colectivo formado por personas mayores, nada menos que el 5,2% tenían 80 y más

años (2.456.908 habitantes, 2011).

Las mejoras en las condiciones de vida generales de la población han permitido que, desde principios del

siglo veinte, el número de españoles aumente de forma significativa. En concreto, desde 1900 hasta la ac-

tualidad, la población española se ha multiplicado por 2,5. Sin embargo, es el grupo de edad de 65 años y

más el que ha experimentado un mayor incremento. Desde 1900 a 2011, las personas de 65 años y más se

han multiplicado por algo más de ocho.

En España, al igual que en el resto de países del área meridional europea, el proceso de envejecimiento de

la población se inició más tarde pero con una intensidad superior que en el resto de países de su entorno.

La proporción de población de 65 y más años ha pasado de representar un 11,2% en 1981 a un 17,3% en

2011, pero que si se traduce a efectivos supone que entre 1981 y 2011 casi se ha duplicado la población

anciana.

En España, además, las proyecciones de población apuntan a que, en las próximas décadas, la población

de 65 años y más seguirá aumentando. En el año 2050 habrá algo más de 15 millones de mayores, casi el

doble que en la actualidad y representarán más de un tercio del total de la población española (36,4%).

Otra de las tendencias previstas es la del denominado «envejecimiento de la población mayor». En un

futuro a largo plazo se producirá un incremento de la población más anciana, es decir, la que supere los

80 años. Según las estimaciones de Naciones Unidas, en el año 2050 el 9% de la población de los países

desarrollados superará los 80 años y el 4% en los países en vías de desarrollo.

En España, los mayores de 80 años han pasado de representar el 0,6% sobre el total de población de 65 y

más años a principios del siglo veinte, al 1,2% en el año 1960 y al 5,2% en 2011. Las proyecciones de

población apuntan a que en el año 2050 las personas de más de 80 años representarán un 14,9% sobre el

total de población mayor.

El envejecimiento de la población mayor tiene implicaciones que trascienden del ámbito estrictamente

demográfico. Por ejemplo, el aumento de las personas mayores dependientes. Edad y dependencia están

Introducción

2

2

estrechamente relacionadas, ya que el volumen de personas con limitaciones de su capacidad funcional

aumenta en los grupos de edad superiores, sobre todo a partir de los 80 años. Pero la dependencia en las

personas mayores no es un fenómeno nuevo. El elemento que ha dado una nueva dimensión al problema

es el proceso de envejecimiento de la población. El aumento del volumen y del peso relativo de personas

mayores, unido a cambios en las formas de organización de la familia y en el papel social de las personas

cuidadoras, han situado a la dependencia en el punto de mira de las políticas sociales.

Previsiblemente, en las próximas décadas también aumentará la población centenaria. Las proyecciones

realizadas por el INE señalan que las personas de 100 años y más pasarán de 8.143 en la actualidad (1

enero 2012), a 13.413 individuos en el año 2020, y 69.386 en 2050. Sobre el total de personas de 65 años

y más, los centenarios pasarán de representar un 0,10% en el 2011, a un 0,14% en 2020 y un 0,45% en el

año 2050.

Mantener y mejorar la calidad de vida de las personas mayores es uno de los principales retos que plantea

el proceso de envejecimiento. En los países desarrollados, el aumento de la longevidad de la población ha

ido acompañado de una contracción de la morbilidad, es decir, de una reducción del número de años

vividos en mala salud. Por el contrario, en los países en vías de desarrollo, la aceleración de la transición

demográfica y epidemiológica junto con niveles inferiores de ingresos y un escaso desarrollo de los siste-

mas de bienestar, no ha incidido en la disminución de la morbilidad. En los países en vías de desarrollo,

por tanto, es esencial la formulación y puesta en práctica de medidas efectivas que incidan en mejorar la

calidad de vida de las personas mayores y por tanto descienda la morbilidad

Tabla 1 – Población anciana en el mundo

3

3 Sistema de seguridad para personas dependientes

En este informe se puede ver claramente que la población anciana va en ascenso, y lo que es peor es que

la calidad de vida en muchos casos desciende con esta edad debido al sedentarismo, en muchos casos este

sedentarismo viene siendo consecuencia del miedo a las caídas, ya sea este miedo del mismo individuo o

el miedo de las familias a la caída de su familiar cuando se encuentra solo. El dispositivo cubrirá esa

necesidad de tener bajo control a tu ser querido, teniendo este a su vez más autonomía para desplazarse

fuera del hogar.

El Instituto Nacional de Estadística (en adelante, INE) acaba de publicar los resultados detallados del

Censo de Población y Viviendas de 2011. Entre ellos, existe información acerca de las formas de

convivencia que mantienen las personas mayores en España. Un indicador fundamental sobre ellas es el

tamaño del hogar en el que habitan. Según esta fuente, de las 7.933.755 personas de 65 o más años

residentes en viviendas principales, prácticamente la mitad se hallan en hogares formados por dos

miembros: representan en concreto el 48,69%, esto es, cerca de cuatro millones. Es el tipo de hogar más

común entre ellas, con diferencia. Por otro lado, un 21,54% habita en hogares unipersonales, lo que en

cifras absolutas equivale a más del millón setecientas mil personas. En cuanto a las demás personas

mayores, el 17,31% vive en hogares constituidos por tres miembros, el 6,73% en hogares de cuatro

miembros y el 5,72% restante en hogares de cinco o más miembros.

Con respecto a los resultados que ofrecieron los censos de población anteriores (de 1991 y de 2001), cabe

destacar el auge que han experimentado tanto los hogares bipersonales como los unipersonales, en detri-

mento de los de mayor tamaño. El retroceso de la viudedad, que sucede en un momento del ciclo familiar

cada vez más tardío, así como la decisión que toman un número creciente de personas cuando pierden a la

pareja de continuar en su domicilio, aun debiendo ser en solitario, en lugar de mudarse con los hijos como

era costumbre en España, explican esa tendencia hacia la simplificación de los hogares en los cuales

residen las personas mayores. Es algo que viene ocurriendo en las últimas décadas: en 1991, por ejemplo,

alrededor del 15% de ellas se encontraban en hogares de cinco o más miembros, un porcentaje que casi

triplica, en efecto, al actual.

En relación a aquellas personas mayores que viven solas, otra encuesta del IMSERSO (realizada en 2010,

por teléfono, a una muestra representativa de 2.535 personas de 65 o más años) indaga sobre por qué

viven así y no de otro modo. La gran mayoría, casi las dos terceras partes, afirma que porque las circuns-

Figura 1- Población mayores 65 años

Introducción

4

4

tancias le han obligado a ello, pero que se han adaptado. En segundo lugar, cerca del 30% declara que

prefieren esta forma de vida a cualquier otra alternativa y, por último, apenas el 7% confiesan que les

gustaría convivir con familiares. Cabe destacar que el argumento voluntario o preferencia por la vida soli-

taria es citado más por los hombres que por las mujeres, así como por las personas de hasta 75 años que

por las que superan esa edad. En cuanto a la postura de rechazo, pese a resultar minoritaria, se da más

entre las mujeres que entre los varones. Junto a los motivos para vivir en solitario, la encuesta informa del

tiempo que llevan haciéndolo: una media en general de doce años, aunque para las mujeres casi alcanza

trece mientras que en el de los hombres no llega a diez.

Como se ha podido observar en el estudio previo estas personas en su mayoría por circunstancias o por

preferirlo acaban viviendo solas, lo que conlleva un riesgo para su seguridad por falta de autonomía

necesaria para en caso de un suceso como puede ser una caída, avisar a alguien para que la socorra en un

periodo leve de tiempo.

Tras una primera introducción a las circunstancias actuales del grupo de población que va dirigido este

dispositivo, vamos a constatar con sendos textos recogidos de distintos informes médicos, la importancia

en un primer caso de una atención temprana en caso de sufrir cualquier percance relacionado con una

caída, en segundo lugar la importancia de la rápida actuación tras un infarto y, por último, la importancia

de la localización para personas con alzhéimer.

En 2009 fallecieron por una caída 1.438 españoles mayores de 65 años. Esto supone el 25 por ciento del

total de muertes accidentales anuales en ese rango de edad, según la Sociedad Española de Geriatría. Las

consecuencias de las caídas suponen con frecuencia el inicio de la discapacidad. Así, una de cada diez

caídas genera lesiones severas, como fractura de cadera y hematoma subdural Así pues, una rápida

intervención tras la caída seria vital para la reducción de este porcentaje.

La Sociedad Española de Cardiología (SEC) advierte de la importancia de intervenir de manera rápida y

eficaz tras una parada cardiaca, siguiendo el protocolo marcado por las Guías de Práctica Clínica de

Reanimación Cardiopulmonar, pues, durante el primer minuto transcurrido tras el evento cardiaco, las

posibilidades de supervivencia si se comienza una reanimación básica, sin esperar al personal

especializado, son del 70%.

Figura 2 - Clasificación Motivos soledad personas mayores

5


Esta probabilidad va reduciéndose un 10% sucesivamente cada minuto que pasa sin realizar compresiones

torácicas, debido a la falta de oxígeno a la que se ve expuesto el cerebro durante el tiempo que dura la

parada cardiaca. Por ello, el riesgo de lesión cerebral también aumenta un 10% cada minuto transcurrido

tras este episodio, pudiendo padecer hemiplejia, déficit de memoria, de habla o de movilidad de manera

temporal o incluso irreversible.

Tal y como recomienda la nueva versión de estas Guías, publicadas en 2010, tras la parada cardiaca de

un individuo, resulta imprescindible confirmar la inconsciencia y la falta de respiración, aunque puede

persistir una respiración suave e irregular durante el primer minuto. La causa más frecuente de pérdida de

conciencia es una lipotimia, que es benigna, transitoria y no precisa reanimación, así que conviene

detectar bien los síntomas. La lipotimia y la parada cardiaca se pueden distinguir fácilmente, ya que en la

lipotimia persiste la respiración y se recupera la conciencia en menos de uno o dos minutos. En tal caso,

se recomienda tumbar al individuo y levantarle las piernas.

Ante la sospecha de una parada cardiaca se deberá llamar al teléfono de emergencias 112, dando un

mensaje claro y sin demoras, alertando del estado de inconsciencia y de la falta de respiración del

individuo e informando de la presencia o ausencia de dolor torácico y de los antecedentes de enfermedad

cardiaca, en caso de que los hubiera.

Los anteriores párrafos pertenecen a un estudio de la sociedad española de cardiología, y como podemos

observar la activación del SMS de emergencia, pulsando el pulsador de emergencia del dispositivo, puede

salvar muchas vidas.

Por último se ha querido incluir una referencia lo importante que puede resultar tener localizado a una

persona enferma de alzhéimer en todo momento, pues los primeros momentos de desorientación resultan

cruciales.

Según la Fundación Alzheimer España, el enfermo con Alzheimer sufre un drástico cambio en su

personalidad, con tendencia a deprimirse o irritarse. La persona ya no puede seguir instrucciones, sufre

confusión y desorientación en el tiempo y el espacio, pudiendo incluso, llegar a perderse en lugares conocidos

para él. Por lo que siempre es importante en todo lugar y momento que esté localizado el individuo que sufre

la enfermedad pues puede llegar a perderse en cualquier lugar, siendo también bueno que pueda interactuar

con los servicios de emergencias en caso de sentirse agobiado por algún cambio drástico que pueda sufrir

debido a su enfermedad.

1.1 Objetivos del proyecto

El objetivo principal de este proyecto es el diseño de un dispositivo de seguridad para personas mayores o con

problemas de salud. Con este proyecto se espera cubrir todas las necesidades de seguridad que pueda tener una

persona mayor para poder seguir desarrollando una vida activa, dando a su vez seguridad a su entorno familiar.

Se tiene localizada a la persona en todo momento, teniendo el dispositivo un sistema de detección de caídas y

un botón de emergencia para avisar rápidamente a los servicios de emergencia en caso de encontrarse sola la

persona atendida.

Introducción

6

6

El alcance de este proyecto es:

Configurar y testear un sistema de medición inercial MPU-9150

Configurar y testear sensor GPS

Establecer comunicación entre los dispositivos y Microprocesador

Diseñar algoritmos en el procesador para la obtención de los datos

Diseñar algoritmo de detección de caídas

Diseñar algoritmo de posicionamiento GPS y gestión de zonas de seguridad

Diseñar algoritmo central de gestión de emergencias

Diseñar algoritmo de envío de mensajes a la red GSM

Figura 3 – Sistema de envío SMS

7


2 FUNDAMENTOS TEÓRICOS

Engineering stimulates the mind. Kids get bored easily. They have got to

get out and get their hands dirty: make things, dismantle things, fix things.

When the schools can offer that¸you´ll have an engineer for life.

Bruce Dickinson, 1948

En este capítulo se van a detallar las bases teóricas que se usan en este proyecto

2.1 Sistemas de referencia en navegación

Para poder entender los sistemas de navegación es imprescindible dominar los distintos sistemas de referencia

con los que se va a trabajar, se van a explicar los fundamentos matemáticos de los principios de los sistemas de

navegación. A continuación se introducirá el concepto de sistemas de coordenadas, y dentro de esto se

desglosaran los distintos tipos de sistemas de coordenadas según sus características y el uso que le vaya a ser

dado a dicho sistema. Se verán los siguientes sistemas de referencia:

Sistema inercial geocéntrico (ECI: Earth Centered Inertia.).

Sistemas de ejes tierra (ECEF: Earth Centered, Earth Fixed).

Sistema de referencia topocéntrico.

Sistema de ejes horizonte local (LLS: Local Level System, NED: North East Down).

Sistema de referencia de azimut de deriva (Wander Azimut Frame).

Sistemas de ejes de cuerpo (BFS: Body Fixed System).

Además, se estudiarán las relaciones entre los distintos sistemas y como pasar de uno a otro. En este proceso se

irán definiendo variados conceptos de navegación tales como posición, velocidad, aceleración, aceleración

angular, latitud, longitud, etc.

2.1.1 Sistemas de coordenadas en navegación

Un sistema de referencia viene dado por un punto de referencia denominado origen y un sistema de

Fundamentos teóricos

8

8

coordenadas. El origen de coordenadas es el punto de referencia de un sistema de coordenadas y en él el valor

de todas las coordenadas es nulo. Sobre cada uno de los ejes se definen vectores unitarios, que indican la

dirección del eje.

Un sistema de coordenadas es un conjunto de valores y puntos que permite definir unívocamente la posición

de cualquier punto de un espacio euclídeo.

En este proyecto se utilizarán sistemas de coordenadas ortogonales y orientadas a derechas.

En navegación se usan como mínimo dos sistemas de coordenadas: un sistema objeto y un sistema de

referencia. El primero describe el objeto cuya posición y orientación se desea conocer, mientras el de

referencia describe el cuerpo conocido, normalmente la Tierra, relativo al cual se obtiene la posición y

orientación del objeto.

A continuación se describen los sistemas de referencia principales usados en navegación, enumerados en el

anterior subapartado:

2.1.1.1 Sistema Inercial Geocéntrico (ECI)

Este sistema es especialmente útil para el estudio del movimiento de cuerpos orbitando la tierra, como pueden

serlo los satélites GPS, de hecho en navegación es el sistema de coordenadas usado más comúnmente. Se

define como un sistema de coordenadas inercial, es decir, como aquel que no tiene aceleración ni rotación con

respecto al resto del universo. Aunque este sistema no es realmente inercial, pues se está despreciando el

movimiento de la tierra respecto al sol, y el propio movimiento del Sol respecto a las estrellas, se hace una

aproximación que es válida para el entorno de navegación en el que estamos trabajando.

El eje z coincide con el eje de rotación de la tierra. Los ejes x e y contienen al ecuador y el eje x apunta al

primer punto de Aries (una dirección fija de las estrellas), esta es la mima dirección que la que va desde el

centro de la Tierra hasta la intersección del plano ecuatorial de la Tierra con el plano medio de la órbita

de la Tierra alrededor del Sol (Plano de la eclíptica).

El conjunto de sistemas inerciales son muy importantes para el tema de la navegación pues las leyes de

Newton se pueden considerar aproximadamente ciertas y esto permite trabajar más fácilmente con otros

marcos de referencia no inerciales. En la figura siguiente se puede visualizar un sistema ECI respecto a la

tierra sus elementos diferenciados.

Figura 4 – Sistema ECI

9


2.1.1.2 Sistema de ejes tierra (ECEF)

Este sistema está ligado a la tierra pues rota con ella, así pues, es un sistema muy útil para referenciar

posiciones terrestres. Es similar al ECI excepto por el detalle mencionado anteriormente, así pues, los ejes

quedarían como se definen a continuación, el eje z seguiría siendo igual que en el ECI pero El eje x va desde

el centro de masas hasta la intersección del ecuador con el CZM (Conventional Zero Meridian) conocido

como meridiano de Greenwich, que define la longitud 0 grados. El eje y, completando el sistema de ejes

ortogonales, apunta a la intersección del ecuador con el meridiano 90º Este. O sea, el plano xy contiene al

Ecuador y el plano xz contiene al meridiano de Greenwich. En la siguiente figura se muestra todos los

elementos de un sistema ECEF respecto a la tierra.

2.1.1.3 Sistema de referencia topocéntrico

El sistema de referencia topocéntrico está ligado íntimamente a la Tierra, con origen donde se encuentre el

observador (E). Suele ser usado para tomar medidas desde Tierra. El plano xy es tangente al Elipsoide

Internacional WGS84 en la superficie, la dirección del eje x apunta al Este, la dirección del eje y al

Figura 5 – Sistema ECEF

Figura 6 – Sistema referencia topocéntrico


10

10

Norte, y la del eje z sigue la vertical local " hacia arriba" (cénit). La dirección local " hacia abajo" se

denomina nadir. Las medidas en este sistema se obtienen por tres medidas: r o ρ (distancia al objeto); A ,

azimut; y h la altura sobre el plano horizontal.

En la figura anterior se puede ver una representación del sistema de referencia topocéntrico.

2.1.1.4 Sistema de ejes horizonte local (LLS, NED)

Es un sistema que está centrado en un punto, en el cual se solicita la solución de navegación, que puede estar o

no en la superficie de la tierra. Por tanto el sistema cambia al moverse el punto. Esta representación es

conocida en inglés como North East Down (NED) o Local Level System (LLS) , Es un sistema local con

sus ejes X e Y en el plano tangente al punto de la Tierra donde está el origen. Típicamente el eje

X apuntará al norte, el eje Y al Este y el eje Z abajo (De ahí su nombre en inglés), aunque debe

ser especificado.

En la figura superior se puede observar cómo está definido el sistema respecto al elipsoide: La dirección Norte

es e , la dirección Este es e y la dirección abajo es he . Es el sistema de referencia fundamental en

navegación aunque en ocasiones es sustituido por el de azimut errante (próximo apartado).

2.1.1.5 Sistema de referencia de azimut de deriva

Conocida en inglés como Wander Azimut Frame , se usa frecuentemente en navegación en lugar del sistema

de referencia horizonte local, debido a que dicho sistema en las proximidades de los polos está mal definido

pues en cada polo existe una singularidad, ya que aquí los ejes Norte y Este están sin definir ,y esto ocasiona

numerosos problemas numéricos.

Se rota un ángulo α respecto a la dirección N/E. Dicho ángulo y su variación se deben de definir por el diseñador del sistema de navegación.

Figura 7 - LLS

11


2.1.1.6 Sistemas de ejes de cuerpo (BFS)

Conocido en inglés como Body Fixed System, este sistema nos proporciona tanto la posición como la

orientación del objeto referido al sistema. El centro del sistema de referencia es el centro de masas del objeto.

El eje x siempre apunta en la dirección usual de avance del objeto, mientras el eje y apunta hacia la derecha

formando 90 grados con el eje x. El eje z de este sistema apunta hacia abajo, en la dirección de la fuerza de la

gravedad. En la figura que se muestra a continuación se describe este sistema: El eje bx contenido en el plano

de simetría del avión, hacia el morro, el ángulo rotado en torno a bx es φ (roll). El eje bz contenido en el avión

hacia abajo, el ángulo rotado entorno a bz es (yaw). El eje by completa los ejes hacia la dirección

aproximada del ala derecha, el ángulo rotado en torno a by es θ (pitch).

Figura 8 – Sistema de referencia

azimut

Figura 9 – Sistema de ejes de cuerpo


12

12

2.2 IMU: Sensores Inerciales

Un sensor inercial o IMU( Inertial Measurement Unit ) consta de giroscopios y acelerómetros, que miden la

velocidad, orientación y fuerzas gravitacionales del módulo. Este tipo de sensores tiene distintas aplicaciones

en la actualidad, se suele usar en los aviones y todo el campo de la navegación aérea, seguridad vial (como es

el caso de los airbag), naves espaciales, etc.

El modulo IMU se compone normalmente de acelerómetro y giroscopio, los cuales son ortogonales entre sí

formando un sistema de referencia ortogonal, como es el caso del sistema de referencia body visto en capítulos

anteriores.

Un desarrollo avanzado de los IMU son los sistemas MEMS, que son sistemas micro electromecánicos que

son construidos sobre el mismo sustrato que la electrónica, ofreciendo ventajas en cuanto a consumo y tamaño.

Al adaptar esta tecnología a los circuitos integrados se logran construir sistemas mecánicos de precisión.

Actualmente, gracias a esta tecnología MEMS se están combinando los IMUs con diversos sensores como

termómetros o magnetómetros consiguiendo de esta manera datos de mayor precisión. El motivo de incluir un

sensor de temperatura es corregir los errores térmicos comunes a los demás sensores que forman parte del

IMU.

Un modelo típico de medida sería:

ˆ (1 ) ;m m b

Donde m̂ es la medida del valor real m , es el factor de escala, b es el sesgo y es el ruido en la medida

obtenida. Estos valores se pueden calibrar pero están sujetos a variaciones.

Las principales características de estos dispositivos son:

Ancho de banda: determina la frecuencia máxima de aceleración o giro que son capaces de detectar.

Se asimila a la velocidad máxima a la que se realizan las medidas

Rango de medición

Supervivencia a choques

Ruido (En unidades de medida por Hz ). Mide , se puede usar para calcular como se degrada la

medida acumulada.

Inestabilidad del sesgo (en unidades de medida).Mide el ruido aleatorio que entra en b .

Inestabilidad en el factor de escala (en porcentaje). Mide el ruido aleatorio que entra en .

Con estas características se puede valorar la calidad de un IMU, y se puede valorar si es válido para el

proyecto que se desea diseñar.

El acelerómetro será el principal elemento que se usara en el proyecto, por ello se hace una introducción a este

elemento.

13


El principio de funcionamiento de un acelerómetro es medir el desplazamiento de una masa testigo. En los

primeros acelerómetros solían constar de un muelle. Un ejemplo de estos acelerómetros se muestra en la

imagen.

Con la llegada de la tecnología MEMS este tipo de acelerómetros fue evolucionando a una versión más precisa

y de menor tamaño.

Los acelerómetros están entre los primeros productos de micro sistemas (MST/MEMS) desarrollados,

surgieron en el final de la década de 1980. Sin embargo, para alcanzar un éxito comercial necesitó el desarrollo

que surgió durante las décadas de los 70, 80, hasta la del 90 con aplicaciones principalmente en los mercados

de la automoción y aeronáutica. Los sensores micrómetro-clasificados miden el movimiento tal como

aceleración, vibración, choque, inclinación, e inclinación. Actualmente, con la tecnología muy madura,

fabricación en volúmenes muy elevados y a un bajo costo, los acelerómetros están en la mejor posición para

moverse con éxito hacia otras aplicaciones, tales como el área médica, industrial y de transporte. Con la

tecnología MEMS, la aceleración puede obtenerse por medio de dos efectos:

Desplazamiento de una masa testigo sostenida por un flexor

Variación en la frecuencia de vibración de un elemento

En el primer caso, los sensores son análogos a una masa suspendida entre resortes, que se desplaza al ser

acelerada. Su sensibilidad es menor que en el segundo caso, aunque cuenta con la ventaja de un fácil y versátil

encapsulamiento. En el segundo, en cambio, la aceleración es obtenida a través de la variación en la

frecuencia de resonancia de vigas en contacto con una masa testigo.

Figura 10 – Acelerómetro tradicional

Figura 11 – Acelerómetro MEMS


14

14

La estructura de los acelerómetros como se puede observar en la imagen anterior, está compuesta una masa

testigo cuadrada relativamente pesada, sostenida por cuatro flexores. Unidos a estos, se encuentran unas vigas

que se hacen oscilar electrostáticamente, induciendo la vibración sobre la masa. Las vigas sufren una carga

axial adicional en presencia de una aceleración en la dirección de la vibración, que se manifiesta como una

variación en su frecuencia de resonancia.

Como es el caso del proyecto que se está tratando, uno de los ejes está en la misma dirección que la gravedad,

es por ello que a la hora de medir se debe hacer la consideración de suponer que el objeto esta en caída libre,

puesto que para aplicar la ley de Newton debemos encontrarnos en un sistema inercial, pero como el objeto

esta en caída libre, tenemos que tener en cuenta que el sistema de referencia fijo en el cuerpo (sistema body)

no es inercial. Sin embargo, en reposo sobre la tierra, existe una fuerza de la misma magnitud que la

gravitatoria pero de sentido opuesto, por tanto se puede considerar que es una medida indirecta de la gravedad.

La definición correcta de acelerómetro es dispositivo que mide las desviaciones del estado de caída libre.

2.3 Sistemas de navegación por satélite(GNSS)

Los sistemas de navegación por satélite o GNSS (Global Navegation Satellite System) se refiere al conjunto de

tecnologías de sistemas de navegación por satélite que obtienen información de posición y tiempo con una

cobertura de tipo global.

En la actualidad existen varios sistemas GNSS, el estadounidense que es el Global Positioning System (GPS),

el GLONASS desarrollado por la antigua Unión Soviética, el Galileo desarrollado por la Agencia Espacial

Europea, el chino conocido como Beiduo-1, etc. En este apartado se va a desarrollar el usado en este proyecto

que es el GPS.

2.3.1 Global Positioning System (GPS)

En los años 60 las agencias de EEUU se interesan por desarrollar un sistema global, en 3 dimensiones y de

gran precisión de posicionamiento. A principios de los años 70 nace el GPS , desarrollado por EEUU con fines

militares , este sistema estaba ideado para proporcionar datos de posición de sus unidades de tierra. A

principios de los 80 el sistema es liberado para su uso civil.

El sistema GPS se compone de tres segmentos: el segmento espacial, el segmento de control y el segmento

usuario.

15


2.3.1.1 Arquitectura Sistema GPS

El segmento espacial está formado por los satélites, que en conjunto de 24 satélites forman una constelación

nominal en 6 planes orbitales, con 4 satélites por plano, estos satélites envían información a los segmentos de

control y usuarios. La constelación se ubica en la órbita media con una altitud aproximada de 20200

kilómetros sobre la tierra. Está compuesta por satélites NAVSTAR, fabricados por Rockwell International y

cada uno tiene un peso estimado de 860 kg. Cada uno de estos satélites lleva a bordo un reloj atómico

sincronizado con el tiempo GPS. Cada satélite emite continuamente un mensaje en dos frecuencias, L1

(1575.42MHz) y L2(1227.6MHz). El mensaje tiene dos partes una parte C/A code y otra P code, estas

contienen una secuencia que permite estimar el tiempo de recepción e información sobre la localización del

satélite.

El segmento de control es una red de estaciones que monitoriza el estado de los satélites, actualiza con

observaciones la posición real de los satélites y sincroniza los relojes atómicos. Las estaciones de

monitorización se establecen en lugares cuyas ubicaciones son establecidas de manera precisa, y

dentro de las mismas se sitúan los relojes sincronizados, que permiten el conocimiento de la

relación de tiempo entre la recepción de la señal proveniente del satélite y el momento exacto de

su utilización, para que no existan errores. Este segmento está controlado por el ejercito de los

EEUU y la estación de control maestra se sitúa en Colorado.

Figura 12 – Sistema GPS


16

16

El segmento usuario está formado por un dispositivo formado por una antena, un receptor de radio y un reloj

de cuarzo, a partir de este implementa un algoritmo de estimación de posición. Las señales de entrada son

desmoduladas a partir del uso del reloj de cuarzo que proporciona una referencia en el tiempo. El procesador

de distancias usa algoritmos de adquisición y seguimiento para obtener la distancia recorrida por

las señales desde cada uno de los satélites hasta la antena. Entonces, el procesador de navegación

utiliza las mediciones del procesador de distancias para determinar una solución de posición,

velocidad y tiempo.

Para obtener la posición en un GPS, la solución es obtenida a partir de la determinación de las

distancias recorridas por las señales que envían los satélites. Así, el tiempo de recepción de una

señal 1t , es determinado por el reloj de cuarzo del receptor, mientras que el tiempo de

Figura 14 – Segmentos GPS

Figura 13 – Segmento de control GPS

17


transmisión de la señal

0t es determinado a partir de la señal enviada por el satélite, el primer

observable que se obtiene es la diferencia entre tiempos 1 0t t t , si llamamos a la

distancia entre el receptor y el satélite , y c es la velocidad de la luz entonces tenemos que

i ic t

Donde el subíndice i se utiliza para indicar el número de satélites.

Si el reloj estuviera perfectamente sincronizado entonces la medida sería exacta, pero hay que

introducirle un error debido al reloj de cuarzo, por esto se conoce el parámetro como

pseudodistancia.

Por tanto para cada satélite i que sea visible en un instante dado tendremos una ecuación del tipo

anteriormente mencionado, así pues cada ecuación de este tipo equivale a una esfera. Con las

intersecciones de estas esferas se determinará la posición , y puesto se sabe que la intersección

de dos esferas es una circunferencia, la de tres esferas son dos puntos para obtener un punto en el

que converjan las esferas necesitamos al menos 4 satélites activos. Así pues este es el mínimo

numero de satélites que debemos disponer para obtener una posición aproximada del receptor.

Figura 15 - Localización GPS


18

18

2.4 Global System Mobile

A lo largo de la década de los ochenta se establecieron en Europa sistemas de radiotelefonía móvil celular con

arreglo a estándares distintos, por lo que el ámbito de servicio se limitaba al territorio de cada país. Parecía

conveniente desarrollar una norma europea para la radiotelefonía móvil que permitiera el establecimiento de

un sistema único al menos para todos los países de la comunidad europea, y destinado a un mercado potencial

estimado en varios millones de abonados para el año 2000.

Por otro lado comenzaba a vislumbrarse la liberalizaci6n de las Telecomunicaciones que a1 introducir la

competencia entre operadores provocaría una reducci6n de costes con el increment0 subsiguiente de la

demanda. En consecuencia se constituy6 en la CEPT el Groupe Spéciale Mobile (GSM) con el mandato de

desarrollar esa Norma. Posteriormente, a1 crearse el ETSI, el Grupo GSM pas6 a integrarse en esta Instituci6n.

El nuevo sistema a desarrollar debería ser capaz de dar servicio a un gran número de abonados con

cobertura internacional y ser muy flexible en cuanto a servicios, coberturas y tipos de terminales.

Asimismo debería estar abierto a la interacción con las futuras redes avanzadas de telecomunicaciones.

El grupo GSM definió una serie de requisitos básicos para el nuevo sistema digital, entre 10s que cabe

destacar los siguientes:

Itinerancia internacional, dentro de la CE.

Tecnología digital.

Número telefónico único

Gran capacidad de tráfico.

Utilización eficiente del espectro radioeléctrico.

Sistema de señalización digital.

Servicios básicos de voz y datos.

Amplia variedad de servicios telemáticos.

Posibilidad de conexión RDSI.

Seguridad y privacidad en la interfaz radio, con protección de la identidad de los usuarios y

encriptación de sus transmisiones.

Utilización de teléfonos portátiles.

Calidades altas de cobertura, tráfico y señal recibida.

2.4.1 Arquitectura GSM

La arquitectura de red correspondiente al sistema GSM, está formada por múltiples estaciones base(BTS), que

se conectan con un controlador de estaciones base(BSC), encargado en su caso de la administración de la red.

El sistema compuesto por BSC y BTS es conocido como BSS( Subsistema de estación base).

En la interfaz de línea estarían los centros de conmutación móvil (MSC), al que se conectan físicamente los

BSC. Este es el encargado de establecer la conexión con la RTC( Red de telefonía pública) y con Internet. La

administración de este centro corre a cargo del operador de la red telefónica. El MSC pertenece a un

Subsistema de conmutación de red (NSS), el cual se encarga de identificar a los usuarios, determinar su

ubicación, y gestionar las comunicaciones con otros usuarios de la red. A su vez, el Centro de Conmutación

19


móvil (MSC) se conecta a una serie de base de datos que le proporcionan funciones adicionales.

La tarjeta SIM es la encargada de identificar en la red al usuario y al terminal móvil. Estos dispositivos se

identifican gracias a un número exclusivo de identificación denominado IMEI (Identificador internacional de

equipos móviles). Por otro lado, la tarjeta SIM también tiene un número de identificación único denominado

IMSI (Identificador internacional de abonados móviles).

La arquitectura funcional define las entidades que tienen a su cargo la ejecución de funciones definidas del

sistema. Los interfaces establecen fronteras de repartici6n funcional. Se han definido dos interfaces físicas que

se denominan interfaz de línea e interfaz aire o interfaz radio.

La interfaz de línea separa el Centro de Conmutación (MSC) del Sistema de Estación Base (BSS). La interfaz

radio delimita la frontera entre la estación de base (BS) y las estaciones móviles (MS).

La partici6n funcional más importante tiene lugar en la interfaz de línea que se separan las funciones

relativas a los aspectos de red y conmutación (MSC. VLR y HLR) y las relacionadas con los aspectos

radioeléctricos, ejecutadas en el BSS.

Entre las funciones relativas a aspectos de red y conmutación destacan:

Autentificación

Localización

Radio-búsqueda

Interfuncionamiento con redes asociadas

Figura 16 – Arquitectura funcional GSM


20

20

Figura 17 – Sistema GSM

Las funciones básicas de los elementos más importantes del esquema de arquitectura son:

MSC: Realiza todas las actividades de gesti6n de las llamadas desde hacia las estaciones m6viles y establece

las conexiones con la red telefónica fija.

Registros de localizaci6n: Almacenan informaciones relativas a los abonados residentes y transeúntes.

El HLR es el registro doméstico del abonado, donde se almacena el tipo de abono, c6digo de identificación,

numero, información de localización, etc.

El VLR es un registro de visitantes o transeúntes, donde se inscribe temporalmente un abonado cuando está

situado dentro de la zona de localización dependiente de un MSC.

Para que las estaciones de base radioeléctricas sean lo más simples posible, muchas de las funciones de control

se ejecutan en forma centralizada y compartida en el BSC.

En el centro de autentificación (AUC) se almacena informaci6n de identidad del abonado m6vil y de su equipo

para la verificación de las llamadas.

El centro de operación y mantenimiento ejecuta funciones de supervisi6n técnica del sistema, programa

dotaciones de recursos, ayuda a la localización de averías, genera estadísticas de servicio, etc.

2.4.2 Servicios GSM

En GSM se han especificado los siguientes servicios básicos:

Telefonía digital con códec a la velocidad plena (full rate) de 13 Kbit/s, o a la velocidad mitad (half

rate) de 6,5 Kbit/s, que permite duplicar la capacidad de los canales.

Mensajes cortos SMS, que permite a los usuarios enviar y recibir mensajes breves a través de un

centro de control, incluyendo mensajes de difusi6n a grupos de usuarios.

21


Tratamiento de mensajes. Servicio de mensajería basado en la Red X.400 del UIT-T.

Facsímil. Permite la conexión de aparatos FAX del Grupo 3 para transmitir o recibir documentos en la

estación móvil.

Servicio de transmisión de datos con conmutación de paquetes, GPRS (General Packet Radio

Service), con velocidades de hasta 170 Kbit/s.

Mensajería Multimedia, MMS para la transmisión de mensajes de voz, texto, imágenes fijas y

m6viles.

En cuanto a servicios suplementarios, también su número es grande, pudiendo destacarse 10s siguientes:

Identificaci6n del abonado llamante.

Redireccionamiento de llamadas.

Llamada en espera.

Terminación de llamadas de usuarios ocupados.

Grupos cerrados de usuarios.

Tarificación (llamadas gratuitas. a cobro revertido, avisos).

Buz6n de voz.

Transferencia de llamadas.

Conferencias múltiples

Prohibición de determinadas llamadas desde el terminal.

HARDWARE

22

22

3 HARDWARE

To the optimist,the glass is half full. To the pessimist, the glass is haft

empty.To the engineer, the glass is twice as big as it needs to be.

Unknown,

En este apartado se va a describir el hardware usado en este proyecto, sus funciones dentro del proyecto y la

configuración que se les da para sus usos dentro del mismo.

El conjunto del hardware usado en este proyecto está compuesto por un modulo Arduino Uno rev3 basado en

el microcontrolador ATmega328p de Atmel, un receptor GPS, un modulo GSM/GPRS y un IMU.

3.1 Arduino Uno rev3

Para este proyecto se ha seleccionado el Arduino Uno rev3 basado en el microcontrolador ATmega328p,

debido principalmente a su costo, la gran cantidad de información existente sobre Arduino y la gran cantidad

de opciones que tiene a la hora de desarrollar un sistema.

Para el proyecto es muy importante que esta placa sea compatible con comunicaciones I2C y serie pues son las

que se llevaran a cabo en este proyecto.

En un primer lugar se van a describir las características de esta placa, Arduino Uno es una placa

microcontroladora basada en ATmega328. Tiene 14 Entradas/Salidas digitales (6 de las cuales pueden

utilizarse como salidas PWM), 6 entrada analógicas, conector USB, clavija hembra tipo Jack, conector ICSP y

botón de reset. Tiene un oscilador interno que funciona a 16MHz. Contiene todo lo necesario para el correcto

funcionamiento del microcontrolador.

Esta versión de Arduino UNO incorpora un ATmega16U2 programado como convertidor serie a USB. Este

chip tiene USB nativo y puede ser reprogramado para que la Arduino sea reconocida al conectarla al

ordenador como cualquier tipo de periférico USB.

Las características principales de la placa Arduino Uno rev3 son:

Microcontrolador ATmega328P

Voltaje de funcionamiento: 5V

Voltaje de entrada recomendado: 7-12V

23


Voltaje de entrada mínimo-máximo: 6-20V

Pines digitales I/O:14( de los cuales 6 pueden usarse como salida PWM)

Entradas analógicas: 6

Corriente DC para I/O Pin: 20mA

Corriente DC para 3.3V PIN: 50mA

Memoria FLASH de 32 KB(ATmega328P) de los cuales 0.5 KB son usados por el bootlader

Memoria SRAM de 2 KB(ATmega328P)

Memoria EEPROM de 1 KB (ATmega328P)

Velocidad de reloj de 16MHz

Los pines de la placa Arduino y sus funciones son las siguientes:

VIN: Es el pin de entrada de la alimentación cuando se usa una fuente externa de alimentación. En el

caso de que alimentación sea por el puerto USB, se puede acceder a este voltaje de alimentación a

través de este pin.

5V: Este pin de salida proporciona 5V desde el regulador de la placa. La placa puede ser alimentada

con desde DC power jack (7-12V), el conector USB (5V) o el pin VIN (7-12V). No debe ser

alimentada la placa desde este pin pues puede ser dañada.

3.3V: Parecido al anterior pin solo que este suministra 3.3V. Tiene una corriente máxima de 50 mA

Figura 18 – Arduino Uno Rev3

HARDWARE

24

24

GND: Pines de Tierra.

IOREF: Este pin proporciona el voltaje de referencia con el que Arduino Uno está trabajando. La

configuración puede ser 3.3V o 5V

AREF: Voltaje de referencia para los pines analógicos

RESET: Se emplea para resetear o detener el microcontrolador

Las posibles funciones de algunos pines son:

Pines Serial: 0(RX) y 1(TX). Usados para recibir y transmitir por el puerto serial datos. Estos pines

están conectados a los correspondientes pines ATmega8U2 US-to-TTL serial chip.

Interrupciones externas: 2 y 3. Estos pines están configurados para interrupciones externas en algunos

de sus modos.

PWM: Los pines 3, 5, 6, 9,10 y 11. Proporciona una salida PWM de 8 bits.

SPI: Los pines 10(SS), 11(MOSI), 12(MISO), 13 (SCK). Estos pines apoyan las comunicaciones SPI

basándose en la librería SPI.

LED: Pin 13.Cuando el valor es alto el LED está encendido, cuando es bajo está apagado.

I2C: A4 o SDA pin y el A5 o SCL pin. Soportara una comunicación I2C usando la librería wire.

A continuación se muestra la relación de pines entre el microprocesador ATmega328p y la placa Arduino

UNO rev3.

Figura 19 – Atmega328p mapa de pines

25


3.2 Sensor inercial MPU-9050

Se ha hecho un estudio de mercado buscando un IMU que cumple con los requisitos del proyecto que se va

llevar a cabo, y se ha optado por un MPU-9150. Según la disponibilidad y garantías se seleccionara la marca

del MPU-9150, rondando su precio los 20€.

El MPU-9150 combina dos chips en uno solo, el MPU-6050 que contiene un giroscopio de 3

ejes, acelerómetro de 3 ejes y un procesador de movimiento digital (DMP) capaz de procesar

algoritmos complejos de fusión de movimiento. Adicionalmente tiene un AK8975, una brújula

digital de 3 ejes. En este proyecto finalmente solo se usara el acelerómetro del MPU-6050,

pudiendo utilizarse el resto de dispositivos que tiene este modulo en futuras aplicaciones.

El MPU-9150 opera con 3.3 voltios y usa un protocolo de comunicación I2C, este protocolo se

verá mas adelante con mayor detalle.

Las características principales de este modulo son:

Información de fusión de movimiento digital de los 9 ejes en una matriz de rotación, cuaterniones,

euler, ángulo e información en bruto

Giroscopio de 3 ejes angular con sensibilidades hasta de 131 LSBs/dps y una escala programable de

rango entre ±250, ±500, ±1000, and ±2000dps

Acelerómetro de 3 ejes con un rango programable de ±2g, ±4g, ±8g y ±16g. En el caso de este

proyecto programado a ±8g.

Brújula de 3 ejes con escala completa de rango ±1200µ

Reducción de los efectos de sedimentación y de la deriva del sensor mediante la eliminación de

errores a nivel de placa de alineación del eje transversal entre el acelerómetro, giroscopio y brújula

Figura 20 – MPU 9150

HARDWARE

26

26

Alimentación VDD en el rango de 2.4V-3.46V; voltaje de la lógica de 1.8V ±5% o VDD

Corriente de operación del giroscopio 3.6mA

Corriente de operación del giroscopio + acelerómetro de 3.8mA

Corriente del módulo completo: giro + acelerómetro + brújula + DMP de 4.25mA

Acelerómetro modo de baja potencia, corriente de funcionamiento: 10uA a 1Hz, 20uA a 5Hz, 70uA a

20Hz, 140uA a 40Hz

Se va a hacer una introducción al acelerómetro del MPU-9150 en más detalle ya que es lo que se

usara en este proyecto.

El acelerómetro mide la aceleración en los tres ejes X, Y y Z, las tres dimensiones del espacio. A

la hora de obtener los datos de aceleraciones se debe tener en cuenta que la aceleración de la

gravedad de la tierra es aproximadamente de 29.8 /m s , y perpendicular a la superficie.

Suponiendo que tenemos la IMU alineada según lo queremos utilizar para el proyecto el eje X

estará en un ángulo perfecto de 90 grados con la superficie, marcando la aceleración del eje X 29.8 /m s y siendo aproximadamente nulas la aceleración tanto en el eje Y como en el Z.

A la hora de obtener los valores la IMU da los valores en enteros de 16 bits, estos valores estarán

especificados entorno a un ratio de conversión en el caso del acelerómetro es de 16384 siendo

este el valor correspondiente a 1g en caso de que la configuración del rango del acelerómetro sea

2g , pues el máximo sería 152 32768 y el mínimo valor 152 32768 . Así pues, el rango de

valores que entrega el IMU es [ 32768,32768] siendo a este aplicado su rango de conversión

según el rango del acelerómetro configurado. En el caso que nos concierne el rango configurado

es 8g , lo que llevara a una equivalencia de 1g sea igual a una salida de 4096.

Para la configuración de este modulo se van a usar como referencia las librerías del modulo

mpu6050 ya que solo se da uso en el proyecto al acelerómetro. Esta librería fue diseñada por Jeff

Rowberg, no obstante ha sido modificada por dos motivos, para configurar el módulo mpu-6050

conforme al proyecto que se está llevando a cabo y para optimizar el uso de la memoria del

microcontrolador borrando las funciones que no se usan en este proyecto.

Una vez se ha adaptado la librería a las configuraciones deseadas para el modulo y se ha

optimizado el uso de variables y funciones en la librería se configura la frecuencia de muestro.

3.3 Modulo GPS

El criterio a la hora de la elección del modulo GPS será un sensor económico con unas buenas características

de posicionamiento y que posibilite una conexión optima con el microcontrolador ATmega328p.

Finalmente tras un exhaustivo estudio de mercado hemos decidido seleccionar una placa Ultimate GPS

Breakout de Adafruit, basado en el modulo MTK3339, pues tiene los requisitos que buscamos y además tiene

buena disponibilidad dentro del mercado. También se ha elegido este modulo debido a las librerías de las que

27


dispone Adafruit para su implementación con Arduino.

El coste económico de este sensor ronda los 35-40€ aproximadamente lo que permite que el sistema tenga un

coste reducido en comparación con precios establecidos en el mercado para este tipo de dispositivos.

Este es un modulo de alta calidad que puede rastrear hasta 22 satélites en 66 canales disponibles, tiene una

muy buena sensibilidad como receptor y una antena acoplada.

Las principales características de este dispositivo son:

Frecuencia de muestreo programable entre 1 y 10 Hz

Precisión en posición: 1.8 m

Precisión en velocidad: 0.1 m/s

Tiempo de arranque medio: 34 segundos

Sensibilidad de adquisición: -145 dBm

Sensibilidad de rastreo: .165 dBm

Velocidad máxima: 515 m/s

Voltaje de entrada: 3-5.5V

MTK3339 consumo de corriente en funcionamiento: 25mA en rastreo, 20mA durante navegación

LED de rastreo integrado

Salida de datos: NMEA 0183, 9600 baudios por defecto

Peso: 8.5 gr

Dimensiones: 25.5mm x 35mm x 6.5mm

Para la configuración del dispositivo el fabricante incluye una librería, que además de configurar el

dispositivo, permite extraer los datos del mismo en distintas estructuras.

Figura 21 – Ultimate GPS Adafruit

HARDWARE

28

28

3.3.1 Sentencias NMEA

Los datos que entrega el dispositivo lo hace por medio de sentencias NMEA (National Marine Electronics

Association). Estas sentencias son un código cifrado que en función del encabezado de la trama se podrán

conocer los datos que está recibiendo el microcontrolador ATmega328p. Se podrá filtrar los datos según el

encabezado gracias al código implementado por la librería que almacenara cada dato en el campo

correspondiente de la estructura. A continuación se van a desglosar los distintos códigos de cifrado que puede

recibir el microcontrolador en su comunicación con el GPS.

Ahora analizaremos en profundidad cada uno de los tipos de tramas recibidas. En un primer lugar se analizará

la trama GGA, que se detectara pues viene precedida de una cabecera $GPGGA.

Tabla 2 – Tramas NMEA

Tabla 3 – Trama datos GGA

29


El campo de position fix indicator nos indicara si el GPS tiene datos disponibles:

Los primeros datos obtenidos de la fila UTC Time son relativos a la hora en el formato horas,

minutos, segundos.

El segundo campo nos muestra la latitud en grados, al que hay que añadir el segundo campo que

indica la orientación es norte o sur.

El siguiente nos muestra la longitud, transmitido en grados y con una información complementaria en

la siguiente fila que se refiere a si su orientación es este u oeste.

El siguiente dato es fix que ya lo hemos descrito en la tabla anterior, que indica si está en

funcionamiento el GPS.

Por último se envían datos relativos a la altitud respecto al mar .

Para cerrar la trama y terminar la comunicación se reciben los caracteres <CR><LF>

Esta primera trama es la que más interesa al proyecto pues contiene los datos que se van a usar para el

posicionamiento del individuo.

Tabla 4 – Indicador de posición fijada

Tabla 5-– Trama de datos GSA

HARDWARE

30

30

El siguiente tipo de trama se puede ver en la anterior tabla, es la trama con formato GSA, la cual no entramos

en excesivo detalle pues se refiere a los satélites con los que contacta el receptor GPS, lo cual no es de gran

interés para el proyecto.

En esta primera tabla se muestran cada uno de los campos de la trama, siendo detallados los campos Mode 1 y

Mode 2 en las siguientes tablas.

Ahora veremos la información relativa a la trama GSV, que es relativa a la información de los satélites, por lo

que no se entrará en detalle.

Tabla 8 – Trama GSV

Tabla 6 – Modo 1 GSA

Tabla 7 – Modo 2 GSA

31


La trama RMC es la trama Recommended Minimum Navegation information, por tanto es de gran

importancia pues permite un modo optimo de enviar información. Los datos son similares a la trama GGA,

pero incluyendo el dato de la velocidad.

Si se analiza esta trama se ve que están todos los datos que se necesitan en el proyecto, por lo que para el

proyecto que se está llevando a cabo son validas tanto la trama GGA como la RMC. Por último se mostrara un

ejemplo de trama VTG que es la trama relativa a la información sobre la velocidad respecto a la tierra.

Tabla 9 – Trama RMC

HARDWARE

32

32

3.4 Modulo GSM

Para completar el proyecto era necesario el envío de datos de forma segura desde cualquier localización

geográfica para ello se añadió al proyecto un modulo GSM/GPRS de lonet basado en la SIM800L. Las

características de la placa se adaptan al proyecto por su coste económico y por su bajo consumo.

Figura 22 – Modulo GSM/GPRS Lonet

Tabla 10 – Trama VTG

33


Las características principales de este modulo se enumeran a continuación:

Quad-band 850/900/1800/1900MHz

Control por comandos AT (3GPP TS 27.007, 27.005 y SIMCOM AT Commands)

Soporta RTC (Real Time Clock)

Alimentación: 3.4V - 4.4V DC

Niveles lógicos de 3.0V a 5.0V

Ultra Bajo Consumo: 1mA en modo sleep

Tamaño: 23x35x5.6mm

Incluye antena GSM/GPRS

Como se especifica en sus características este modulo se controla por medio de los comandos AT, estos

comandos serán de vital importancia para el desarrollo del proyecto por lo que vamos a ver sus principales

características a continuación:

3.4.1 Comandos AT o Hayes

Como se ha detallado con anterioridad el control del modem GSM a través de la interfaz de usuario, se basa en

el uso de comandos AT, estos se envían por el puerto serie de Arduino esperando la respuesta por el mismo

puerto.

Puesto que la lista de comandos AT es muy extensa solo se van a analizar los que potencialmente se van a usar

en el proyecto actual.

Existen dos tipos principales de comandos:

Comandos que ejecutan acciones inmediatas (por ejemplo: ATD marcación)

Comandos para cambiar la configuración del modem(por ejemplo: CGMF activa modo texto)

Principalmente se va a trabajar con mensajes de texto, así pues se describen a continuación este tipo de

mensajes.

Podemos dividir los comandos referidos a mensajes de texto en dos grupos:

1. Configuración del sistema de envío o recepción:

AT+CMGF (Message Format): Con este comando se configura el tipo de mensaje que se va a

usar, pueden ser dos tipos, si es igual a 1 será tipo texto, y si es igual a 0 será tipo PDU (Modo

binario).

AT+CPMS(Preferred Message Storage): Selecciona los valores de las 3 memorias existentes. La

primera es la de lectura, borrado y reenvío de mensajes, la segunda es la que contiene los

mensajes escritos pero no enviados, mientras la tercera es donde se almacenan los nuevos

HARDWARE

34

34

mensajes recibidos.

AT+CSMP(Set Text Mode parameters): Entre otros, configura el tiempo máximo de

permanencia de un mensaje en el centro de servicio antes de su envío al destinario final.

AT+CSCA(Service Centre Address): Es el que establece el número del centro de servicio,

correspondiente al servidor.

AT+CNMI(New Message Indications to TE). Configura la metodología de notificación de un

mensaje nuevo recibido.

2. Acciones

AT+CMGR (Read Message): Lee un mensaje recibido de la memoria seleccionada

anteriormente.

AT+CMGD (Delete Message): Borra un mensaje recibido de la memoria seleccionada

anteriormente.

AT+CMGW (Write Message to Memory): Escribe un mensaje en la primera posición que tenga

la memoria libre para su posterior envío, lectura o almacenamiento.

AT+CMGS(Send Message): Envía un mensaje, cuyo contenido se debe especificar, y

anteriormente también se debe especificar el destinatario. El formato es orden-número destino-

contenido.

AT+CMSS(Send From Storage): Envia un mensaje almacenado en una determinada posición de

memoria.

Además de estos comandos básicos se usaran algunos más que están incluidos en el manual de comandos

AT del chip SIM800L, el cual se puede consultar en el enlace que se muestra a continuación:

(http://www.seeedstudio.com/wiki/images/5/51/SIM800_ATCommand_Manual_V1.02.pdf).

http://www.seeedstudio.com/wiki/images/5/51/SIM800_ATCommand_Manual_V1.02.pdf

35


4 SOFTWARE

Software is a great combination between artistry and engineering

Bill Gates

Se describen a continuación el software utilizado para el desarrollo del proyecto, con este software se han

elaborado labores de diseño, testeo, procesado de datos y control.

4.1 Arduino IDE

Este el entorno de programación que usa Arduino para escribir, compilar y descargar el código en sus placas,

en concreto con la que se usa en este proyecto, Arduino Uno Rev3 funciona correctamente.

Este entorno de programación tiene entre sus puntos a favor que facilita la implementación de un gran número

de bibliotecas, que desarrollan numerosas funciones matemáticas o de comunicación para su aplicación en el

código. Cabe destacar que es un software libre y la existencia de un puerto terminal serie para la comunicación

con la placa que es muy útil a la hora de testear que el código cumpla con los esperado.

Figura 23 – Arduino IDE

SOFTWARE

36

36

Entre sus puntos negativos, el más significativo es la simplicidad del entorno del que se echa en falta muchas

de las opciones que si traen otros programas como el que veremos en el siguiente punto.

4.2 Matlab

Según se define el programa en su propia web, MATLAB es un lenguaje de cálculo técnico de alto nivel y un

entorno interactivo para el desarrollo de algoritmos, la visualización de datos, el análisis de datos

y programación.

Todo el trabajo de visualización y análisis de datos realizado en este proyecto se ha realizado a través de este

programa, incluyendo también la elaboración de las gráficas realizadas.

4.3 Google Earth Pro

Este programa según se define en su propia web sirve para la Visualización de imágenes de satélite, mapas,

relieve, edificios en 3D, lejanas galaxias del espacio y las profundidades marinas. En el contexto de este

proyecto se usara para visualizar los mapas, visualizar distintas áreas, la medición de distancias y el

posicionamiento de coordenadas geográficas.

Se ha escogido la versión pro debido a que dispone a las siguientes características que serán útiles para la

realización del proyecto. Google Earth Pro incluye las mismas funciones sencillas y las mismas imágenes que

la versión gratuita de Google Earth, pero dispone de otras herramientas especialmente diseñadas para

profesionales.

Utiliza capas de datos para ubicar tus objetivos demográficos.

Figura 24 - Google Earth Pro

37


Calcula distancias y áreas utilizando herramientas de medición.

Utiliza Movie Maker para producir medios colaterales

Imprime imágenes de alta resolución para presentaciones e informes.

Importa archivos vectoriales de imágenes de gran tamaño para representar datos SIG en un mapa.

Crea mapas de direcciones con Spreadsheet Importer.

Arquitectura y desarrollo del sistema

38

38

5 ARQUITECTURA Y DESARROLLO DEL SISTEMA

One machine can do the work of tifty ordinary men. No machine can do

the work of one extraordinary man.

Elbert Hubbard

En este apartado se va a tratar todo lo relacionado a la integración de los distintos dispositivos hardware

enumerados anteriormente. Se va a hacer una descripción detallada de las conexiones entre los pines de los

distintos módulos, la alimentación del sistema y de cada uno de los módulos, los protocolos de comunicación

que usan para comunicarse, y las funciones que hacen estos módulos dentro del sistema detallando los

algoritmos que se han desarrollado convenientemente.

5.1 Esquema electrónico general

A continuación se muestra un esquema electrónico general donde se pueden apreciar las conexiones entre los

pines de los distintos módulos hardware pertenecientes al sistema.

Figura 25 – Esquema electrónico general

39


Como se puede apreciar en el esquema anterior el sistema está diseñado entorno al módulo Arduino Uno

Rev3, que contiene el microprocesador. El microprocesador será el encargado de establecer las conexiones con

los distintos módulos que forman el sistema, y a su vez del manejo de los datos adquiridos para implantar un

algoritmo central que lleve a cabo los objetivos del sistema.

El conjunto hardware que forma parte de este proyecto está constituido por un IMU, que se comunica con el

microcontrolador a través del protocolo I2C, un módulo GPS, que se comunica por medio del protocolo

UART y por ultimo un modulo GSM que se comunica a través del protocolo UART. Estos se utilizan para

obtener las distintas mediciones necesarias para el funcionamiento del sistema. Con el IMU se obtienen los

datos de las aceleraciones en los tres ejes, que se usan en el algoritmo de detección de caídas. El GPS obtiene

los datos de posición en coordenadas ECEF y la hora, que se usarán en el algoritmo función localiza y en la

función principal del sistema. Así, el módulo GSM a través del algoritmo de envíos de SMS, será el encargado

de enviar la información adquirida a través de la red al usuario final del sistema. Así pues, las comunicaciones

usadas serán detalladas en próximos apartados así como los diferentes algoritmos utilizados para implementar

el sistema.

Aparte de los módulos nombrados anteriormente, se incorpora al sistema un pulsador que se comunica con el

microprocesador por medio de un circuito pull-down conectado a un pin digital que se configura como

entrada. Este pulsador se usa para enviar una señal al microprocesador para que envíe un SMS de auxilio en

caso de problemas de salud como puede ser un fallo cardiovascular. Además el sistema incorpora un LED

externo conectado a un pin digital, que emitirá luz en caso de que se envíe un SMS.

5.2 Alimentación del Sistema

En este apartado se va a detallar la alimentación que demanda cada uno de los módulos, así como la fuente de

alimentación principal del sistema que se basará en una batería LiPo. A continuación se van a detallar las

especificaciones de potencia de los distintos módulos del proyecto.

El módulo Arduino Uno Rev3, puede operar con una alimentación externa de entre 6 a 20 Voltios, esta

alimentación le será proporcionada a través del jack de 2.1mm que lleva la placa incorporada. Pero hay que

tener en cuenta que si se suministran menos de 7 Voltios, el pin de 5V suministrará menos de 5 Voltios por lo

que no es recomendable que sea menor, pues puede producirse inestabilidad. Sí se usa más de 12 Voltios el

regulador interno de la placa puede sobre calentarse por lo que lo más recomendable es usar un Voltaje

comprendido entre 7 y 12 Voltios. El consumo de corriente del microcontrolador, ATmega328p a una

frecuencia de trabajo de 16 MHz, es aproximadamente de unos 11 mA, a este consumo hay que añadirle que la

placa no integra sólo el microcontrolador, sino un regulador de tensión, conversor Serie-USB, LEDs,

condensadores, resistencias, cristal (marca los pulsos de reloj para hacer funcionar el microcontrolador a

16Mhz), diodos, etc. Esto dispara el consumo a entorno 30 mA en un modo de funcionamiento normal.


40

40

La placa Arduino Uno Rev3 tiene además salidas para alimentar distintos periféricos, estas salidas son de 5 o

3.3Voltios. La salidas de 5 y 3.3 Voltios puede proporcionar una corriente máxima de alimentación de 50 mA.

Y cada uno de sus puertos de entrada/salida puede proporcionar o recibir un máximo de 40 mA. Por lo que

tanto el módulo GPS como el módulo IMU serán alimentados desde la placa de Arduino, pues como veremos

a continuación cumplen los requisitos de potencia descritos anteriormente y por tanto son compatibles. No así

el módulo GSM pues como veremos a continuación requiere una tensión de entrada que no se puede

suministrar desde la placa Arduino.

Las especificaciones eléctricas del módulo GPS nos llevan a una tensión de entre 3 y 5.5 Voltios y según sus

especificaciones a un consumo de corriente de 25mA en modo búsqueda, y un consumo de unos 20 mA

durante la fase de navegación. Como se puede comprobar estas especificaciones son compatibles con la

alimentación suministrada por la placa Arduino Uno Rev3 por lo que se alimentara desde el pin de 5 V el

modulo GPS.

Como se puede ver en apartados anteriores las especificaciones eléctricas del modulo IMU, con un voltaje de

entrada de entre 2.375 y 3.465 V y un consumo de corriente en nuestro caso (que están deshabilitados tanto el

giroscopio como el magnetómetro) de aproximadamente 1mA, el modulo IMU es perfectamente compatible

con la alimentación de 3.3V que suministra la placa Arduino Uno Rev3 en uno de sus pines.

El modulo GSM tendrá una entrada de entre 3.4 y 4.4V, así pues necesitará una alimentación externa que

cumpla esos requisitos. El consumo de corriente de este módulo será diseñado para que cuando no este activo

este en modo de mínima energía, en este modo el módulo consume 0.796 mA, y en el momento que este

activo (cuando tenga que enviar un SMS) se activara el modo de funcionalidad completa con un consumo de

1.02mA. Este consumo tendrá picos de corta duración de tiempo en el momento en el que se envíe el SMS,

pero esos picos siempre estarán dentro del rango de admisión del suministrador de potencia por tanto no debe

haber problemas de caídas de tensión.

Finalmente hay que tener en cuenta también el consumo del LED externo, puesto que tiene en serie una

resistencia de 220 Ohm será de entorno unos 20 mA que puede suministrar sin problema la placa Arduino Uno

Rev3. Sin embargo, el consumo del pulsador será despreciable, puesto que el circuito pull-down está

compuesto de una resistencia de 10k será entorno a 0.5mA, que está dentro del rango que puede proporcionar

los puertos digitales de la placa Arduino Uno Rev3.

Figura 26 – Consumo de microprocesador ATmega328p

41


Una vez se han descrito los requisitos de alimentación de los distintos módulos, se adopta la decisión de

alimentar el sistema a través de una Batería LiPo de 7.4V 2200 mAh lo que proporcionará al sistema una

autonomía muy interesante que se calculará a continuación.

Comentar que puesto que todos los módulos a excepción del GSM pueden ser alimentados desde la placa

Arduino Uno Rev3, se diseñara un circuito de alimentación por el que la batería alimentará directamente la

placa Arduino Uno Rev3, y paralelamente se alimentará el módulo GSM a través de un circuito reductor DC

step down, en este caso uno basado en el LM2596, que convierte cualquier voltaje comprendido entre 3.2 y 40

V DC a entre 1.25 y 35 V DC para un máximo de 3A.

Por último se hará un estudio tanto práctico como teórico de la autonomía que proporciona, a continuación se

muestra una tabla con los datos teóricos de consumo obtenidos de las especificaciones, y los datos prácticos

obtenidos de una prueba en el laboratorio.

Figura 27 – Esquema eléctrico alimentación

Figura 28 – Alimentación del

sistema


42

42

Así pues teniendo en cuenta el consumo medio real del sistema se dispone de una autonomía de más de 31

horas, este dato es muy positivo pues el individuo que porta el sistema puede estar más de 24 horas sin tener

que cargar el dispositivo estando el dispositivo a pleno rendimiento. En la imagen se muestra el consumo de

nuestro dispositivo en estado de búsqueda GPS y en proceso de envió de un SMS activado mediante pulsador,

estos eventos disparan el consumo de corriente hasta los 94 mA como se puede apreciar.

5.3 Protocolos de comunicación

Para el correcto envió de datos entre distintos módulos del sistema se requiere que estos módulos hablen un

lenguaje común, este lenguaje común son los protocolos, y a continuación se van a detallar los distintos

protocolos usados en el sistema, así como una descripción detallada de los mismos.

El modulo IMU usa para comunicarse con el microcontrolador el protocolo I2C, así pues tanto el modulo

GSM como el GPS usan el protocolo UART TTL para su comunicación con el microcontrolador, tras detallar

los distintos protocolos se detallará también la configuración adoptada en las distintas comunicaciones.

Figura 29- Medición consumo

en el laboratorio

Tabla 11 - Consumo

43


5.3.1 Protocolo I2C

El I2C es un bus de comunicaciones en serie diseñado en 1992. Su nombre proviene de Inter-Integrated

Circuit. La velocidad de transmisión es de 100 Kbits/s en el modo estándar, aunque puede permitir velocidades

de hasta 3.4 Mbit/s. Este bus es muy utilizado en electrónica para comunicar microcontroladores y sus

módulos periféricos en sistemas empotrados.

I2C permite hasta cuatro velocidades:

100 Kbit/s Estándar

400 Kbit/s Modo rápido

1 Mbit/s Modo rápido Plus

3.4 Mbit/s Modo alta velocidad

La principal característica del I2C es que utiliza dos líneas para transmitir la información, una para los datos

(SDA) y otra para la señal de reloj (SCL). Además de estas dos líneas, es necesaria una tercera línea de

referencia o tierra (GND).

Los dispositivos conectados al bus I2C tienen una dirección única para cada uno de ellos, a su

vez pueden ser configurados como maestros o esclavos. El dispositivo maestro es el encargado

de inicializar la transferencia de datos, y además es el que genera la señal de reloj. La

característica de ser maestro no tiene que ser proporcionada al mismo dispositivo siempre, sino

que puede intercambiarse entre los distintos módulos que tengan esa capacidad.

Las características principales de comunicación del bus I2C se muestran a continuación:

El bus está libre cuando SDA y SCL están en estado lógico alto.

En estado del bus libre, cualquier dispositivo puede ocupar el bus I2C como maestro.

El maestro comienza la comunicación con el envío de un patrón llamado start bit. Esto

alerta a los esclavos poniéndolos en modo espera de una comunicación.

El maestro para dirigirse al dispositivo con el que va a realizar la comunicación envía un

byte que contiene los siete bits(A7-A1) que componen la dirección del esclavo con que se

quiere comunicar, el octavo bit que compone el byte , el bit A0 el de menor peso, se

corresponde con el bit de operación R/W , si el bit esta a 1 será de lectura y si el bit esta a

0 será una operación de escritura.

Figura 30 – Maestro y esclavo I2C


44

44

La dirección enviada será comparada por el esclavo con su propia dirección, en caso de

que ambas coincidan, el esclavo se considera direccionado como esclavo transmisor en el

caso de que el bit R/W = 1 y como esclavo receptor en caso de que el bit R/W = 0.

El esclavo responde enviando un bit de ACK que le indica que conoce la solicitud y que

está en condiciones de comunicarse, en caso de no ser así y no corresponderse la

dirección enviada con la del esclavo se envía un bit NACK.

Seguidamente comienza la fase de intercambio de información entre los dispositivos

El maestro envía la dirección del registro interno del dispositivo que se desea leer o

escribir (en el caso del proyecto el registro del acelerómetro).

El esclavo responde con otro bit de ACK en caso de que todo este correcto.

Ahora es cuando el maestro empieza a escribir o leer bytes de datos. Todos los bytes de

datos deben constar de 8 bits , el número máximo de bytes que se pueden enviar en una

comunicación no están restringidos, siendo el esclavo el que fija la cantidad de acuerdo a

sus características

Cada byte leído/ escrito por el maestro debe ser obligatoriamente asentido por un bit

ACK por el dispositivo esclavo

Se repiten los dos pasos anteriores hasta finalizar la comunicación entre maestro y

esclavo.

Aun cuando el maestro siempre controla el estado de la línea del reloj, un esclavo de baja

velocidad o que deba detener la transferencia de datos mientras efectúa otra función,

puede forzar la línea SCL a nivel bajo. Esto hace que el maestro entre en un estado de

espera, durante el cual, no transmite información esperando a que el esclavo esté listo

para continuar la transferencia en el punto donde había sido detenida.

Cuando la comunicación termina, el maestro transmite una stop condition para dejar el

bus libre.

Un ejemplo de comunicación entre un Maestro y un esclavo se muestra en la siguiente imagen.

Siguiendo las características vista anteriormente, con la ayuda de las librerías de Jeff Rowberg que se muestran

en el apartado anexos, se configura el dispositivo MPU 9150 para que establezca comunicaciones

correctamente con el microprocesador. Se configura a una velocidad estándar de 100 Kbit/s y se activa el bit

de lectura R/W pues es el microprocesador el que recibe la información del acelerómetro.

5.3.2 Protocolo UART-TTL

UART es uno de los protocolos serie más utilizados. La mayoría de los microcontroladores disponen de

hardware UART. Usa una línea de datos simple para transmitir y otra para recibir datos. Comúnmente, 8 bits

de datos son transmitidos de la siguiente forma: un bit de inicio, a nivel bajo, 8 bits de datos y un bit de parada

a nivel alto.

Figura 31 – Trama de datos I2C

45


Un transmisor serie asíncrono debe ser capaz de recibir los datos del procesador a través de un bus y enviarlos

de forma serie al exterior. Para ello el componente esencial de un transmisor serie es un registro de

desplazamiento. Este registro no es accesible directamente. El procesador carga el byte a transmitir en un

registro llamado Registro de Mantenimiento de la Transmisión (THRE), que está conectado a las entradas del

registro de desplazamiento (TSR).

El protocolo asíncrono está orientado al carácter, cada byte que se transmite se rodea de un grupo de bits

necesarios para la comunicación y que describiremos a continuación. Cuando no hay datos que transmitir la

línea o salida del transmisor se encuentra en el estado lógico 1 "MARK".

Previo a la transmisión del byte, la línea se pone a 0 lógico durante el tiempo de un bit, esto es el bit de start.

Esto se utiliza para avisar y sincronizar al receptor de la existencia de un dato. A continuación van los bits del

carácter comenzando por el menos significativo, el bit de paridad (opcional) cuyo objetivo es el control de

errores y, en último lugar, el bit de stop que marca el final de un carácter.

Para comunicarse a través del puerto serie UART se transmite en un rango de velocidad desde los 9600 bps

hasta los 115200 bps, este método de comunicación en ocasiones, como es el caso, se encuentra referido a

TTL serial ( transistor-transistor logic). La comunicación serie al nivel lógico TTL, está siempre referida a

valores de tensión entre 0V y Vcc, que está a su vez entre 5V y 3.3V. Un uno lógico está representado por Vcc

y un cero lógico por 0V.

En relación al proyecto se utilizara esta comunicación para el envío y recibo de información con el modulo

GPS, y para el envío de información al modulo GSM. A continuación detallaremos las configuraciones de

ambos módulos al respecto de la comunicación UART-TTL.

El modulo GSM se configura para una tasa de envío de datos de 9600 baudios con una frecuencia de

actualización de 1 Hz, el envío de los datos se hará por medio de secuencias NMEA que están descritas en el

apartado correspondiente. Conforme va llegando esta información al microprocesador se va guardando en una

variable tipo char, que tras ser completada, se analiza y se guarda la información en los distintos campos de la

estructura GPS. Este proceso es realizado con la ayuda de la librería Adafruit_GPS que proporciona el

fabricante y que se muestra en la sección de anexos.

Por su parte el modulo GSM se configura también a una velocidad de 9600 baudios, y se envía/recibe

información por medio de los comandos AT, que han sido detallados en apartados anteriores. La configuración

e implementación de este modulo se lleva a cabo directamente en los algoritmos diseñados para tal fin, estos

algoritmos se mostrarán en apartados posteriores.

5.4 Desarrollo de Algoritmos

En este apartado se van a detallar los distintos algoritmos que se usan para implementar las funciones deseadas

en el sistema.

Figura 32 – Trama de datos UART


46

46

5.4.1 Algoritmo de detección de caídas

Se va a implementar un algoritmo para la detección de caídas a través de las lecturas del acelerómetro, para la

implementación de este algoritmo lo primero que se va a hacer es definir las fases de una caída, tras esto se

clasificaran los tipos de impacto, y finalmente se diseñará el algoritmo de detección de caídas.

5.4.1.1 Fases de una caída

Para estudiar las fases de una caída se ha hecho una simulación de una caída frontal, y se han capturado los

datos que envía el acelerómetro para definir cada una de las fases de la caída.

En esta primera gráfica se pueden observar cada una de las aceleraciones en los tres ejes x,y,z , detallándose

las fases de la caída y los instantes de tiempo en los que se suceden.

En la siguiente gráfica se muestra la suma del módulo de las aceleraciones. Donde también se pueden

distinguir cada una de las fases de una caída.

Figura 33 – Fases de una caída

47


Se pueden observar claramente que una caída está compuesta de tres fases temporales, estas fases son:

1. Fase de reposo: En esta fase la suma de los módulos de las aceleraciones esta a aproximadamente 1g,

puesto que se está hablando de un sistema inercial, esto quiere decir que el objeto medido esta en

reposo con respecto a la tierra.

2. Fase de Caída Libre: En esta fase el cuerpo del paciente toma un movimiento que es parecido a un

objeto en caída libre, pues se dirige el paciente en dirección vertical hacia el suelo. La aceleración en

el eje x tomará en algún momento de la caída el valor 0 pues es el eje que está alineado con la

dirección de la fuerza de la gravedad. Esta etapa es considerada la fase inicial de la caída puesto que

debido a la gravedad en la tierra después de cada fase de caída libre hay un impacto con su

correspondiente aceleración en el sentido opuesto a la caída. Como se puede observar en la grafica en

esta etapa la suma del modulo de las aceleraciones disminuye de 1g a 0g. La duración de esta etapa no

contemplamos que dure más de 1 segundo pues suponemos que el paciente estará a una altura con

respecto al suelo no superior a los aproximadamente 5 metros que se desplaza un cuerpo en caída libre

en ese tiempo. Así siendo la altura media española en torno a 1.75 metros , la media de duración de

esta fase está en torno a los 350 ms, despreciando su dinámica y la resistencia que el paciente pueda

poner a la caída por lo tanto en la mayoría de los casos este tiempo será inferior a 350 ms.

3. Fase de Impacto: Tras la etapa de caída libre, debido a la gravedad en la tierra, el paciente choca con

el suelo o objetos en su camino vertical descendiente, dando como respuesta un pico de la suma de los

módulos de las aceleraciones debido a la desaceleración que se produce al frenar la caída libre.

Tras esta última fase de impacto se vuelve de nuevo a la fase de reposo.

5.4.1.2 Clasificación de los eventos de impacto

Viendo estas tres fases ya se puede definir el proceso de una caída, una vez se ha hecho esto, procedemos a

clasificar los tipos de caídas, y los distintos actos cotidianos que podrían dar lugar a confusión y considerarse

una caída cuando esta no se ha producido. Los eventos que debemos detectar como caída son:

Figura 34 – Tiempo en las fases de una caída


48

48

Caída hacia delante

Caída hacia atrás

Caída lateral derecha

Caída lateral izquierda

Suponiendo también que una combinación de las anteriores será detectado como caída.

Los eventos cotidianos que el sistema no debe detectar como caídas son:

Acostarse/Reclinarse en una cama

Sentarse en una silla

Bajar unas escaleras

A continuación se van a detallar las gráficas y se van a analizar los resultados de las pruebas realizadas para

cada uno de los eventos descritos anteriormente. En la siguiente imagen se detallan los ejes de coordenadas

según la posición de nuestro dispositivo. (Aclarar que por estética se muestra la parte negativa del eje y)

Figura 35 – Ejes respecto al cuerpo

49


En la siguiente gráfica se puede observar las aceleraciones obtenidas para una simulación de caída hacia

delante, con un mecanismo físico que simula el comportamiento humano, al que se ha añadido el módulo

MPU-9150 a la altura aproximada de una cadera humana, perteneciente a una persona de estatura media.

En esta primera gráfica aparecen por separadas cada una de las aceleraciones en los 3 ejes, en un primer

momento se puede ver que el individuo está en posición erguida, pues la aceleración del eje x (eje alineado con

la dirección de la fuerza de la gravedad) es igual a 1g, mientras que tanto en el eje Z como en el Y es igual a

0g. Después de este estado de reposo erguido el individuo tropieza hacia delante produciéndose un momento

de caída libre en el que la suma de los módulos de las tres aceleraciones es igual a 0. Tras la caída libre viene

la fase de impacto del individuo con el suelo o con algún objeto que se encuentre en su trayectoria vertical

descendente, es entonces cuando se produce un pico de desaceleración. En la siguiente gráfica se puede ver la

suma de los módulos de las aceleraciones que intervienen en este proceso.

Figura 36 – Prueba caída hacia adelante


50

50

En la gráfica anterior se puede comprobar que la magnitud de la suma de los módulos de las aceleraciones del

impacto del individuo llega a tener picos de hasta 16g, y que tras este primer impacto se suceden varios

impactos más en el descenso vertical del individuo.

En las siguientes dos gráficas se muestra la aceleración en el caso de una caída hacia atrás del individuo,

quedando claramente definidas cada una de las fases de la caída.

Figura 37 – Prueba caída hacia adelante aceleración total

Figura 38 – Prueba caída hacia atrás

51


En esta última grafica se puede ver que es una caída más limpia que la caída mostrada anteriormente, pues en

este caso el individuo describe una trayectoria vertical descendente limpia hacia el pavimento, este caso se

asimilaría mucho a un desvanecimiento repentino del individuo.

Una vez se ha tratado las caídas frontal y hacia atrás, simulamos las caídas laterales, en una primera gráfica se

muestra una caída lateral de carácter leve, esta caída la asemejamos por condiciones a una caída desde una silla

o similar de forma indirecta, es decir, no tratándose de un desplome lateral hacia el suelo, sino que el individuo

Figura 39 –Prueba caída hacia atrás aceleración total

Figura 40 - Prueba caída lateral leve


52

52

trata de parar su caída o algún objeto frena su trayectoria vertical descendente.

Como se puede comprobar en la imagen es una caída lateral leve hacia la derecha, esto se puede deducir de las

aceleraciones del eje z y el eje y que según están orientados los ejes del sistema de coordenadas se produce una

desaceleración en un caso y una aceleración en el otro.

En esta segunda grafica se puede comprobar que la suma de los módulos de las aceleraciones tiene un pico en

5.6g, una caída de leve impacto en el caso de que el individuo fuera una persona joven pero que en el caso de

un anciano podría producir una rotura de hueso.

En las siguientes dos graficas se verá las respuesta en aceleración a una caída lateral izquierda, siendo esta

caída de una magnitud considerable.

Figura 41 - Prueba caída lateral leve aceleración total

53


Como se puede ver en la gráfica el individuo cae lateralmente desde una posición erguida, produciéndose una

caída donde el mayor impacto se produce en el eje y pero también tiene un impacto de gran magnitud el eje z

finalmente como se puede comprobar el individuo queda inconsciente en el suelo en una posición hacia arriba

pero levemente inclinado hacia el lado.

Figura 43 – Prueba caída lateral aceleración total

A partir de estas cuatro simulaciones, hemos visto las posibles caídas que se pueden producir en este entorno,

siendo los demás tipos de caídas una combinación de las 4 descritas anteriormente.

Una vez descritos los casos en los que el algoritmo debería dar un caso positivo de caída, se va a describir las

Figura 42 - Prueba caída lateral


54

54

situaciones cotidianas que debería detectar el sistema como falso positivo, para diferenciarlos de los

verdaderos positivos compararemos distintos parámetros como magnitud de aceleraciones, fases de la caída,

tiempos, etc.

En el caso de acostarse en una cama, se puede decir que se producen una serie de aceleraciones que pueden

llevar a la confusión a nuestro sistema, para evitar esta situación se analizarán los resultados de la respuesta en

Figura 44 – Prueba acostarse en una cama

Figura 45 – Prueba acostarse en una cama aceleración total

55


aceleración en esta situación.

Podemos observar en la gráfica anterior que la variación de las aceleraciones son mucho más suaves que en el

contexto de una caída, pues en una situación de control nuestros músculos ejercen una desaceleración(gracias a

las fuerzas aplicadas por nuestros músculos) con respecto a la aceleración vertical de la gravedad que se

produce en una caída libre.

En esta segunda gráfica se puede observar que tampoco se cumplen las fases habituales de una caída pues no

existe una fase de caída libre pues como se puede observar la suma de los módulos de las aceleraciones

siempre son superiores a 0.8g, y no se llega a producir un impacto de magnitud considerable pues la suma de

los módulos de las aceleraciones nunca superan los 2.2g.

Otra de las acciones cotidianas que pueden suponer un falso positivo que se estudiará será la acción de sentarse

en una silla.

Como se puede observar en la gráfica anterior en ningún momento se cumple la primera fase de caída libre

que se puede suponer que habría en una caída, en este caso como en el anterior se produce dentro de una

situación de control por parte del individuo que gracias a su fuerza muscular reducirá la aceleración vertical

producida por la gravedad paulatinamente, lo que a su vez llevara a un impacto de magnitud reducida que no

estará dentro del rango en el que se considera que existe una caída.

Figura 46 – Prueba sentarse en una silla


56

56

Como se puede observar en la gráfica anterior, esta prueba tiene un pico cercano a los 3g en el momento que el

individuo impacta con la silla de forma controlada y un mínimo de entorno a los 0.6 g que se corresponde al

momento en el que el individuo se deja caer suavemente sobre la silla.

El último posible falso positivo que se analizará será el acto de bajar unas escaleras, que puede ser el más

problemático pues en caso de bajarlas con cierta habilidad se produciría un notable impacto contra el

pavimento.

Figura 47 - Prueba sentarse en una silla aceleración total

Figura 48 - Prueba bajar escaleras

57


Como se puede observar en la gráfica esta prueba es la que más dificultades puede dar a la hora de

considerarse un falso positivo, pues existen breves momentos en los que el movimiento del individuo se

aproximan a la caída libre, llegando a estar en valores inferiores a los 0.5g la aceleración en el eje x que es en

este caso la que soporta la aceleración gravitacional pues es la que está alineada con el individuo erguido. Tras

esta fase de caída libre se pueden observar picos de una magnitud considerable, estos picos de magnitud se

pueden cuantificar mejor en la próxima grafica que se muestra la suma de los módulos de las aceleraciones.

Como se puede observar en la prueba se bajan cuatro escalones en los que las magnitudes de las respuesta de

aceleración ante el impacto varían en el rango entre 2.3g y 3.5 g.

Después de obtenerse los resultados de las distintas pruebas, evaluando las fases que deben producirse y los

rangos de las respuestas en aceleración ante los impactos, se puede decir que tenemos los rangos admisibles de

un evento de caída para poder aplicar estos datos obtenidos a la consecución de un algoritmo de detección de

caídas.

Finalmente se va a añadir una prueba para poder aportar más información al algoritmo, y poder determinar tras

la caída si el individuo se encuentra consciente o no. Esta prueba consiste en que el individuo se levante desde

el suelo tras una caída, y se muestran las graficas de los resultados obtenidos a continuación.

Figura 49 - Prueba bajar escaleras aceleración total


58

58

Se puede observar en la gráfica que tras varios intentos de levantarse, el individuo consigue levantarse en el

pico de aceleración de 3.3g, tras la caída con que haya cierto movimiento como el que se observa a partir del

segundo 7 se puede considerar que el individuo está consciente.

Figura 50 - Prueba levantarse tras caída

Figura 51 – Prueba levantarse tras caída

59


5.4.1.3 Diseño del algoritmo de caídas

Una vez obtenidos todos los resultados de las pruebas y con el conocimiento de cada una de las fases de la

caída podemos diseñar el algoritmo de caídas, en la siguiente tabla se muestra con los umbrales que se

trabajará en el posterior algoritmo, del que se muestra su diagrama de flujo a continuación.

Caídas Umbral Valor

Umbral Caída Libre 0 g

Tiempo Max Caída libre 1 s

Umbral Impacto 4 g

Rango Reposo [0.5,2] g

Umbral Levantarse 2 g

Tiempo Levantarse 15 s

Tabla 12 – Umbrales de caídas


60

60

Figura 52 – Diagrama de flujo algoritmo de caídas

61


La función correspondiente al algoritmo anterior, estará situada en el algoritmo principal del proyecto, que

proveerá en cada ciclo de reloj a la función de nuevos valores de aceleración y del estado de la misma. A

continuación se muestra el código correspondiente a dicho algoritmo.

int funcioncaida(int16_t acelx,int16_t acely,int16_t acelz,int16_t estado){

int16_t aceltotal;

aceltotal= abs(acelx)+abs(acely)+abs(acelz);//Se calcula la suma del modulo

de las acelaraciones

if((aceltotal==0)&& (estado==REPOSO))//comprobamos si se ha producido caida

libre

{

estado=CAIDALIBRE;

}

if((estado==CAIDALIBRE)&& (aceltotal>=4))//si la acelaracion total supera

modulo 4 entra en el estado de deteccion de impacto

{

counter=millis();

estado=ESPERATRASIMPACTO;

Serial.println("IMPACTO FUERTE,ATENCION");

}

if(estado==ESPERATRASIMPACTO)

{

if((aceltotal>=0.5)&&(aceltotal<=2))//estado de reposo tras caida,

{

delay(2000);//tiempo para que se estabilice la señal y poder determinar

los efectos de la caida

estado=PRESMS;

}

}

if(estado==PRESMS)//en este estado se valora si ha sido una caida en la

que el usuario a quedado inscosciente o se ha levantado tras la caida, si en

15 seg no se levanta se activa protocolo de emergencia

{

if(aceltotal>=2)

{

estado=SMS;// se ha levantado

}

else if (aceltotal<2)

{

if (counter > millis()) counter = millis();

if (millis() - counter > 15000)

{

counter=millis();

estado=SMSINS; //no se ha levando

}

}

}

if(estado==SMS)//envia sms a numero de contacto


62

62

{

Serial.println("SMS ENVIADO A JUAN,la victima esta consciente");

delay(3000);

estado= REPOSO;

}

if(estado==SMSINS)//envia sms a numero de contacto y a emergencias ,

victima insconsciente

{

Serial.println("SMS ENVIADO A JUAN y 112 ,ALERTA la victima no esta

consciente");

delay(3000);

estado= REPOSO;

}

return estado;

}

En este código se usa una sola variable global, la variable counter, que sirve como contador temporal, las

demás variables están definidas con carácter local dentro de la función. También comentar que el uso del

puerto serie dentro de la función es solo de carácter verificativo, pues en el envío del sms de alerta se hace

fuera de esta función y a través del modulo GSM.

5.4.2 Algoritmo de localización

Unos de los objetivos del proyecto es implementar un algoritmo, que partiendo de los datos de posición, pueda

detectar la presencia del individuo dentro de determinadas zonas. Estas zonas se seleccionarán en función del

desarrollo de la vida habitual del individuo, con distintos niveles de seguridad y teniendo como referencia la

vivienda habitual del individuo.

A partir de los datos de posicionamiento, la longitud y la latitud, se pueden definir áreas dentro del globo

terrestre. La magnitud de cada una de las áreas es de vital importancia para las aproximaciones que se llevan a

cabo en el proyecto, pues son áreas dentro de un rango desde un mínimo de una hectárea hasta un máximo de

varios kilómetros cuadrados. Este rango nos permite aproximar los meridianos y paralelos como líneas rectas

respecto a la superficie que se quiere acotar. Puesto que el meridiano terrestre mide 40008 Km, y este son 360

grados, un grado de latitud representa aproximadamente 111.11 km. Por ello puesto que se trabaja en el rango

definido anteriormente, esto se convierte en grados en milésimas de grado, puesto que 0.001 grado latitud =

0.1111 km, aplicando una regla de tres se obtiene que 100 metros es igual a 0.0009 grados de latitud

Respecto a los paralelos la cosa es más complicada ya que no todos lo paralelos tienen el mismo radio .En la

tierra, el paralelo de mayor radio es el Ecuador y según se te van acercando los paralelos a los polos la longitud

de los paralelos disminuye. En cualquier paralelo el radio del mismo es igual al coseno del ángulo

correspondiente multiplicado el radio de la tierra en el ecuador (6376 km) .Se puede tomar como ejemplo el

paralelo 0, tenemos que 0 1cos

, por lo tanto el radio del Ecuador será 6376, y en el polo norte o el polo

sur ese radio seria 0, debido a que 90 0cos

y que el 90 0cos

. Puesto que estamos en el

hemisferio norte, y en el caso que se está tratando la latitud esta próxima a los 37º se tomará ese paralelo para

el cálculo de la distancia a la que corresponde un grado de longitud. Por tanto el radio del paralelo será

37 *( ) 5092.100;cos Radio en el ecuador e introduciendo el resultado en la fórmula de la longitud

de la circunferencia, queda 2 31994.608;r ahora se divide entre 360 grados que son una circunferencia y

se tiene que cada grado son 88.874 km. Así pues 0.001 grado de longitud = 0.0888 km, realizando una regla de

tres se obtiene que 100 metros es igual a 0.0011 grados de longitud.

63


Por lo detallado anteriormente, el algoritmo se basará en áreas rectangulares que serán acotadas por cuatro

puntos, una longitud máxima y una mínima, y una latitud máxima y una mínima. En el caso de la Zona 1 será

una zona de seguridad alrededor del lugar de residencia del individuo, con un área de una hectárea. Se trata de

la primera zona de seguridad para detectar las salidas del individuo de su lugar de residencia para mantener

cierto control de las salidas del individuo. En la siguiente imagen se muestra la zona 1 de seguridad que sea

tomado en este proyecto, pudiendo esta variar conforme a los requisitos demandados.

Como se puede ver en la imagen anterior esta zona una está delimitada por el cuadrado exterior de lado 100

Figura 53 – Meridianos y paralelos

Figura 54- Zona de seguridad 1


64

64

metros, así pues se tendrá un área de seguridad de una hectárea entorno al lugar de residencia habitual del

individuo.

Tras la elección de una primera zona de seguridad alrededor de la vivienda del individuo, se va a acotar una

segunda zona que abarca desde la primera hasta unos límites exteriores marcados por la zona 2. En este caso

estos límites van establecidos a elección del demandante, así pues en el algoritmo se tomará como zona 2 el

barrio de residencia del individuo.

Como se puede ver en la imagen anterior la zona 2 es una zona de relativa seguridad alta para el individuo,

pero conviene estar alerta cuando pase de la zona 1 a la 2. En este caso la zona 2 tiene un área de 16 Hectáreas

y abarca el barrio del individuo.

En la siguiente imagen se muestra en la próxima imagen la zona 3, esta zona delimita el área de seguridad

estable del individuo, a partir de esta área el individuo corre un riesgo considerable.

Figura 55 – Zona de seguridad 2

65


Como se ve esta área es aproximadamente el área de la población donde reside el individuo, se puede acotar

más este área si fuera necesario, la facción de área mínima que tenemos en cuenta en la hectárea, así pues se

puede formar hectárea por hectárea las distintas zonas requeridas si fuera necesario.

Por último se detalla la superposición de las distintas zonas de seguridad.

Figura 56 – Zona de seguridad 3


66

66

Una vez se ha detallado el proceso de selección de zonas, y cómo se han seleccionado en el caso de este

proyecto, se va a implementar el algoritmo que a partir de las entradas de longitud y latitud del GPS distingue

en la zona que se encuentra el individuo. A continuación se muestra el código de la función que lleva a cabo

esa tarea:

Figura 57 – Zonas de seguridad

67


//ZONAS LIMITADAS

#define HOMELAT 36.57600

#define HOMELON -6.21950

#define LIMITEALTLATZ1 36.57645

#define LIMITEBAJLATZ1 36.57555

#define LIMITEALTLONZ1 -6.21895

#define LIMITEBAJLONZ1 -6.22005









int funcionlocaliza(int estado)

{

if(estado>=10)

{

estado=estado-10;//si en el anterior ciclo hubo un envio de sms,

el valor de estado vuelve a su valor normal para que no salte como que ha

cambiado su valor

}

int estadoant=estado;

if (GPS.fix) {

if(((GPS.latitudeDegrees<= LIMITEALTLATZ1) &&

(GPS.latitudeDegrees>=LIMITEBAJLATZ1))&&((GPS.longitudeDegrees<=LIMITEALTLONZ

1)&&(GPS.longitudeDegrees>=LIMITEBAJLONZ1)))

{

estado=1;

if(estadoant!=estado)

{

Serial.print(F("Dentro de Zona :"));

Serial.println(estado);

estado=11;//Si cambia el estado le añadimos un uno al

estado para detectar que hay que enviar un sms

}

}

else if(((GPS.latitudeDegrees <= LIMITEALTLATZ2) &&

(GPS.latitudeDegrees>=LIMITEBAJLATZ2))&&((GPS.longitudeDegrees<=LIMITEALTLONZ

2)&&(GPS.longitudeDegrees>=LIMITEBAJLONZ2)))

{

estado=2;


{






68

68

}

}

else if(((GPS.latitudeDegrees <= LIMITEALTLATZ3) &&

(GPS.latitudeDegrees >= LIMITEBAJLATZ3))&&((GPS.longitudeDegrees <=

LIMITEALTLONZ3)&&(GPS.longitudeDegrees >=LIMITEBAJLONZ3)))

{

estado=3;


{





}

}

else

{

estado=4;


{

Serial.print(F("Dentro de Zona Peligrosa, Alerta"));



}

}

estadoant=estado;

}

return estado;

}

69


La función anterior está enmarcada en el contexto de la función principal a la que proporciona una salida, la

variable estado, y según esta el algoritmo principal tiene que llevar a cabo unas funciones u otras. Este

algoritmo principal se mostrara en los próximos apartados y es que el implementa el resto de funciones. A

continuación se muestra un diagrama de flujo de la función localiza:

Figura 58 – Diagrama de Flujo Algoritmo de zonas


70

70

5.4.3 Algoritmo de envío de SMS

Para el envío de SMS se recurre a un algoritmo basado en los comandos AT, que se explicaron en apartados

anteriores. Este algoritmo recibe una cadena de caracteres que es parte de la información que se va a transmitir

en el mensaje además se transmite la última posición valida del individuo junto con la hora a la que fue

enviada desde el modulo GPS dicha posición.

int enviosms(char cadena[])

{

digitalWrite(SMSLED_PIN, HIGH);

mySerialGSM.print(F("AT+CFUN=1\r\n"));

delay(10000);

mySerialGSM.print(F("AT+CLIP=1\r\n")); //Activar alarma llamada

delay(1500);

mySerialGSM.print(F("AT+CMGF=1\r\n")); //Activar modo texto

delay(1500);

mySerialGSM.print(F("AT+CMGS=\"664513107\"\r\n")); //Comando AT enviar SMS

delay(1000);

mySerialGSM.println(cadena);

mySerialGSM.println(F("estoy en:"));

mySerialGSM.print(F("\"https://www.google.es/maps/search/"));

mySerialGSM.print(latitudult,4);

mySerialGSM.print(F("%2C"));// es una coma codificada

mySerialGSM.print(longitudult,4);

mySerialGSM.println(F("\""));

mySerialGSM.println(F("Hora de ultima localizacion:"));

mySerialGSM.print(horault+1, DEC);

mySerialGSM.print(":");

if(minutoult<=9&&minutoult>=0){mySerialGSM.print("0");}

mySerialGSM.print(minutoult, DEC);

mySerialGSM.print(":");

if(segundoult<=9&&segundoult>=0){mySerialGSM.print("0");}

mySerialGSM.println(segundoult, DEC);

//Mensaje

delay(1000);

mySerialGSM.print(F("\x1A")); //Enviar ascii SUB

delay(1000);

digitalWrite(SMSLED_PIN, LOW);

mySerialGSM.print(F("AT+CFUN=0\r\n"));

return 0;

}

Este código simplemente escribe en el modulo GPS las ordenes adecuadas para que envie un sms con los datos

necesarios, a su vez enciende un led de aviso de que se está enviando un sms.

5.4.4 Algoritmo principal

El algoritmo principal es el encargado de centralizar todos los datos obtenidos y por medio de las variables

globales “estadoppal” para las caídas y “estadoposicion” para la localización, administra el envío de SMS de

71


emergencia, indicando en qué casos deben enviarse a través de la función “enviosms” vista en el apartado

anterior.

#include <Adafruit_GPS.h>

#include <SoftwareSerial.h>

#include "Wire.h"

#include "I2Cdev.h"

#include "MPU6050.h"

#define A_R 16384.0

#define G_R 131.0

#define GPSECHO true

#define LED_PIN 13

#define SMSLED_PIN 4

//ESTADOS DEL PROCESO DE CAIDA

#define REPOSO 0

#define CAIDALIBRE 1

#define IMPACTO 2

#define ESPERATRASIMPACTO 3

#define PRESMS 4

#define SMS 5

#define SMSINS 6

//ZONAS LIMITADAS

#define HOMELAT 36.57600

#define HOMELON -6.21950













int16_t ax, ay, az;

int inPin = 7; // pin 7 asignado para el pulsador

int16_t estadoppal=REPOSO;

uint32_t counter = millis();

int estadoposicion=1;//inicializamos en zona 1(Zona segura)

float latitudult=HOMELAT;

float longitudult=HOMELON;

uint8_t horault;

uint8_t minutoult;

uint8_t segundoult;

uint32_t timer = millis();

bool blinkState = false;

SoftwareSerial mySerial(3, 2);

SoftwareSerial mySerialGSM(10, 11); // RX, TX

MPU6050 accelgyro;//declaracion funcion obtencion datos acelerometro

Adafruit_GPS GPS(&mySerial);// Declaracion funcion GPS y asignación de

puertos 3 y 2 digitales para transmision serie

int funcioncaida(int16_t acelx,int16_t acely,int16_t acelz);


72

72

int funcionlocaliza(int estado);

int enviosms(char cadena[]);

//rutinas de interrupcion que se usan para obtener los datos del GPS

boolean usingInterrupt = false;

void useInterrupt(boolean);

void setup()

{

Wire.begin();

Serial.begin(115200);

mySerialGSM.begin(9600);

accelgyro.initialize();

Serial.println(accelgyro.testConnection() ? F("MPU6050 connection

successful") : F("MPU6050 connection failed"));

pinMode(LED_PIN, OUTPUT);//Configura el pin 13 como salida

pinMode(SMSLED_PIN, OUTPUT);//Configura el pin del ledsms como salida

//ahora inicializamos el GPS

GPS.begin(9600);// 9600 NMEA es la velocidad estándar del puerto serie

GPS

GPS.sendCommand(PMTK_SET_NMEA_OUTPUT_RMCONLY);// Consufiguramos el Gps

para que envie solo la sentencia minima recomendada NMEA

GPS.sendCommand(PMTK_SET_NMEA_UPDATE_1HZ); // Configuramos para que

tenga una tasa de descarga de datos de 1 Hz

GPS.sendCommand(PGCMD_ANTENNA);//Para obetener el estado de la antena

useInterrupt(true);

delay(1000);

mySerial.println(PMTK_Q_RELEASE);

}

void loop()

{

//COMPROBAMOS CAIDAS Y SE ENVIA SMS EN CASO DE QUE SEA NECESARIO---------

-----------------------------------------------------------------------------

------------------------------------

accelgyro.getAcceleration(&ax, &ay, &az);//actualizamos los datos del

acelerometro

estadoppal=funcioncaida(4*(ax/A_R),4*(ay/A_R),4*(az/A_R),estadoppal);

// Refrescamos si se ha recibido algun dato nuevo del GPS, despues

actualizamos estado de zona donde esta, y en caso de que cambie de zona se

envia sms------------------------------------

if (GPS.newNMEAreceived()) {

if(GPS.fix){

latitudult=GPS.latitudeDegrees;

longitudult=GPS.longitudeDegrees;

horault=GPS.hour;

minutoult=GPS.minute;

segundoult=GPS.seconds;

}

if (!GPS.parse(GPS.lastNMEA()))

return;

}

estadoposicion=funcionlocaliza(estadoposicion);

73


if(estadoposicion==11)//estado de envio de sms porque han cambiado a la

zona 1

{

enviosms("El individuo vuelve a la zona 1, zona segura\0");

}

else if(estadoposicion==12)//estado de envio de sms porque han cambiado a

la zona 2

{

enviosms("Aviso, El individuo está actualmente en la zona 2, zona

seguridad intermedia\0");

}


la zona 3

{

enviosms("Alerta, El individuo está actualmente en la zona 3, zona no

segura\0");

}


la zona de alerta

{

enviosms("Alerta, El individuo está actualmente fuera de la zona de

control, zona peligrosa\0");

}

// Se comprueba si el pulsador esta pulsado durante mas de 2 segundos------

-----------------------------------------------------------------------------

---------------------------------------

if (digitalRead(inPin) == HIGH) // testea si la entrada esta activa HIGH

{

delay(2000); // espera 2 segundo

if (digitalRead(inPin) == HIGH)

{

enviosms("Alerta, Pulsador de emergencia apretado\0");

}

}

}


74

74

La función consta de dos partes una primera en la que se configuran los distintos parámetros de inicio de las

distintas comunicaciones y dispositivos, y la segunda que es bucle constante que es donde se desarrollan las

acciones principales del algoritmo.

En cada uno de estos bucles comprueba el estado del sistema y actualiza los datos que proceden de los

dispositivos, y tras la actualización llama a las funciones pertinentes que serán las que cambien el estado del

sistema en caso de que se cumplan una serie de condiciones impuestas por la función. Finalmente se muestra

el diagrama de flujo de la función principal

Figura 59 – diagrama de flujo algoritmo principal

75


6 RESULTADOS

Science and technology revolutionize our lives, but memory, tradition

and myth frame our response

Arthut Schelsinger

Para comprobar el correcto funcionamiento del sistema integrado, se han realizado una serie de pruebas con el

dispositivo llevado por una persona a modo de cinturón en su costado. Para verificar el resultado de las

pruebas, el individuo además del sistema, lleva un teléfono móvil android con capacidad para recibir SMS y

con conexión 4G lo que facilitara la obtención de la posición del individuo.

La prueba inicial que se ha llevado a cabo es la pulsación del botón de emergencias dentro de la casa del

individuo, esta pulsación se hará tras haber encendido el sistema a los aproximadamente 10 segundos, así pues

no debe de dar tiempo al GPS a situarse, además de por estar en un situación de cobertura medio-baja como es

un techo interior por no tener tiempo suficiente para cuadrar la señal. En este caso se debe de recibir un SMS

alertando de la pulsación del botón y puesto que no se ha tomado ninguna posición debería de indicarse la

posición base e indicar que como se ha configurado por defecto el último dato recibido del GPS fue a las

1:00:00. Los resultados de esta prueba son satisfactorios como se comprueba en las siguientes imágenes.

Figura 60 – SMS pulsador

Resultados

76

76

Tras verificar el funcionamiento en interiores la siguiente prueba testeará el detector de caídas en una situación

cotidiana de un paseo. Se trata de una caída leve tras la que el individuo se encuentra en estado de consciencia.

Los resultados obtenidos son correctos pues se obtiene un SMS indicando la situación de caída, el estado de

consciencia y la posición y hora del evento ocurrido.

Se recibe el mensaje pasados unos 20 segundos aproximadamente desde la caída, con la posición exacta de la

caída y la hora del suceso.

La siguiente prueba que se llevara a cabo será un conjunto de acciones que pondrá a prueba nuestro sistema.

En un primer momento el individuo se encuentra sentado y tras levantarse de su silla y comprobar que el

estado del sistema es el correcto se aproxima a bajar unas escaleras de 12 peldaños, tras bajar esta escalera y

comprobar que el estado es correcto va a iniciar un paseo por cada uno de las Zonas establecidas de seguridad,

acabando finalmente fuera de la zona de control, tras esto el individuo volverá al punto de partida.

Una vez a salido de la casa y a pesar de que las condiciones meteorológicas son adversas pues hay cielos

nublados, el dispositivo tarda unos 15 seg en localizar la señal GPS, cuando localiza la señal el individuo

todavía se encuentra en la zona 1 pero segundos después rebasara el límite establecido de esta zona por lo que

se recibirá un SMS como que el que se muestra en la Figura 62.

Figura 61 – SMS caída

77


Tras rebasar los límites de la zona 1 el individuo entra en la zona 2 como indica el SMS anteriormente

recibido, el individuo continua su trayectoria y sale de los límites de la zona 2, lo que provoca el envío de otro

SMS indicando que ahora se encuentra en la zona 3, recibido con éxito.

Figura 63 – SMS zona 3

Figura 62 – SMS zona 2

Resultados

78

78

Tras comprobar con éxito la recepción del mensaje se continúa la trayectoria y ahora una vez se han rebasado

los límites de seguridad de la zona 3, última zona de control, se recibe un mensaje alertando de que el

individuo ha sobrepasado estos límites y se aproxima a los límites de la ciudad o pueblo.

Tras la comprobación de las limitaciones de todas las zonas, el individuo vuelve al punto de partida, que es la

zona 1 recibiendo por último el mensaje que se muestra a continuación.

Figura 64 – SMS zona peligrosa

79


La prueba anterior es el ejemplo del correcto funcionamiento del dispositivo pues se realiza un análisis

completo de las funciones del dispositivo respondiendo este positivamente a todas ellas. La integración de los

módulos del dispositivo se ha realizado de manera acertada pues responde perfectamente a sus funciones el

dispositivo diseñado.

Figura 65 – SMS vuelta a zona 1

Conclusiones

80

80

7 CONCLUSIONES

Genius is one percent inspiration and ninety-nine percent perspiration

Thomas Edison

El objetivo del proyecto era la implementación y diseño de un sistema de posicionamiento humano para

seguridad y dependencia, se buscaba un sistema que integrara GPS, IMU y GSM para obtener un dispositivo

de bajo coste y gran autonomía. Tras una exhaustiva búsqueda en el mercado se seleccionaron los distintos

módulos elegidos buscando una relación calidad precio competente. A continuación se hace balance de los

objetivos planteados y el grado de consecución de los mismos.

El primer objetivo del proyecto era a través del acelerómetro del IMU obtener los datos de forma ordenada a

través del protocolo de comunicación I2C, y tras la obtención de estos datos a una frecuencia de muestreo

seleccionada previamente poder detectar las caídas en un individuo. Este objetivo se ha conseguido con éxito

pues como se ha expuesto en esta memoria este algoritmo funciona correctamente tanto en casos de caídas

como en caso de “falsas caídas” como puede ser la bajada de unas escaleras.

Otro objetivo primordial era la obtención de los datos de posición para la elaboración de un algoritmo de zonas

de seguridad. La comunicación con el Ultimate GPS de Adafruit y la obtención de los datos de

posicionamiento, se consiguen con una comunicación UART TTL con la placa Arduino que a través de las

librerías elaboradas para tal fin obtiene los datos de posición de forma ordenada. Una vez obtenemos los datos

de posición con una frecuencia de 1Hz, se implementa un algoritmo de zonas que nos indica en que zona se

encuentra el individuo, así como el grado de seguridad de la zona correspondiente. Este objetivo se ha

conseguido con éxito pues las pruebas realizadas así lo ponen de manifiesto.

El tercer objetivo era conseguir enviar los SMS a través de la placa GSM, a través del envío de códigos AT

desde la placa Arduino. Una vez conocidos los códigos AT se implementó un código por el cual enviaba un

SMS a los números indicados con los diversos datos de seguridad correspondientes.

El objetivo principal del proyecto era la implementación de todos los módulos en el dispositivo añadiendo a

este un botón pulsador de emergencia. Este objetivo se lleva a cabo con la creación de un código principal de

Arduino que elimina los problemas de sincronización entre los dispositivos configurándolos

convenientemente. El correcto funcionamiento del dispositivo integrado avala la consecución de este objetivo,

como se puede comprobar en el apartado anterior.

Finalmente, una de las intenciones de este proyecto era elaborar un dispositivo al alcance de prácticamente

cualquier consumidor. Al ser este proyecto un prototipo se debe tener en cuenta que este no sería su precio en

el mercado pues se ha optado por obtener los productos en empresas distribuidoras nacionales, y en pequeñas

unidades, lo que eleva el coste del producto. A continuación se muestra un presupuesto total del sistema.

81


Descripción Unidades Precio unidad Subtotales

Arduino Uno Rev3 1 20 € 20 €

Modulo GSM lonet 1 32.92 € 32.92 €

MPU 9150 1 12.26 € 12.26 €

GPS Adafruit 1 35.19 € 35.19 €

Batería LiPo 7.4V 1 14.95 € 14.95 €

Step Down DC-DC 1 5.50 € 5.50 €

Pulsador 1 1.45 € 1.45 €

Varios (LED, res,etc.) 1 0.90 € 0.90 €

TOTAL - - 123.17€

Tabla 13 - Presupuesto

Conclusiones

82

82

83


REFERENCIAS

[1] IMSERSO, "Informe 2012, Las personas mayores en España" Colección de documentos, Primera

edición. 2014.

[2] Juan López Doblas, "Personas mayores viviendo solas" Colección de estudios, IMSERSO,Primera

edicion. 2005.

[3] Antonio Abellan García, "Un perfil de las personas mayores en España,2015", revista,Informes

envejecimiento en red. 2015.

[4] Damian Rivas Rivas y Rafael Vazquez Valenzuela, "Apuntes Navegación aérea" Apuntes, Universidad

de Sevilla, Departamento de Ingeniería Aeroespacial. 2015

[5] José María Hernando Rábanos, "Transmision por radio", Edictorial universitaria Ramón Areces, Sexta

edición. Marzo 2008.

[6] Alejandro Vázquez Fraga,"Integración mediante Filtro de Kalman de sensores inerciales y GPS para la

estimacion de la posicion de un vehículo" TFG. Septiembre ,2014.

[7] Miguel Ángel Indurain Yubero, "Sistema Didáctico para las prácticas de microcontroladores basados en

un dispositivo GPS" TFG. 2014.

[8] Ramiro Blanco y Alejandra Hoyos, "Sistema de deteccion de caida en personas de la tercera edad para

uso en centros geriatricos" Tesis. 2010.

[9] Alberto Castro Dominguez, "Sistema de control de temperatura a traves de Arduino y la tecnología

GPRS\GSM"PFC. 2011.

Referencias

84

84

[10] Manuales y datasheets de Arduino Uno Rev3 . https://www.arduino.cc/

[11] Manuales y datasheets de ATmega328p . https://www.atmel.com/

[12] Manuales y datasheets de Invensense MPU 9150 . http://www.invensense.com/products/motion-

tracking/9-axis/mpu-9150/

[13] Manuales y datasheets de Ultimate GPS Adafruit Breakout . https://www.adafruit.com/products/746

[13] Manual de SIM800L y manual de comandos AT .http://www.seeedstudio.com/wiki/LoNet_-

_GSM/GPRS_Breakout

[14] Webs:

https://github.com/sparkfun/MPU-9150_Breakout

http://blog.bricogeek.com/noticias/programacion/como-programar-arduino-con-atmel-studio-6/

https://learn.adafruit.com/adafruit-ultimate-gps/parsed-data-output

https://forum.arduino.cc

http://fritzing.org/projects/gsm-alarmanlage-motion-detect

http://www.smssolutions.net/tutorials/gsm/receivesmsat/

http://robologs.net/2014/01/12/arduino-y-matlab/

https://www.arduino.cc/

https://www.atmel.com/

http://www.invensense.com/products/motion-tracking/9-axis/mpu-9150/

http://www.invensense.com/products/motion-tracking/9-axis/mpu-9150/

https://www.adafruit.com/products/746

http://www.seeedstudio.com/wiki/LoNet_-_GSM/GPRS_Breakout

http://www.seeedstudio.com/wiki/LoNet_-_GSM/GPRS_Breakout

https://github.com/sparkfun/MPU-9150_Breakout

http://blog.bricogeek.com/noticias/programacion/como-programar-arduino-con-atmel-studio-6/

https://learn.adafruit.com/adafruit-ultimate-gps/parsed-data-output

https://forum.arduino.cc/

http://fritzing.org/projects/gsm-alarmanlage-motion-detect

http://www.smssolutions.net/tutorials/gsm/receivesmsat/

http://robologs.net/2014/01/12/arduino-y-matlab/

85


Índice de Conceptos

86

86

Índice de Conceptos

87


Glosario

88

88

Glosario

89


ANEXO A: LIBRERÍAS Librería MPU 6050

// I2Cdev library collection - MPU6050 I2C device class

// Based on InvenSense MPU-6050 register map document rev. 2.0, 5/19/2011

(RM-MPU-6000A-00)

// 10/3/2011 by Jeff Rowberg <[email protected]>

// Updates should (hopefully) always be available at

https://github.com/jrowberg/i2cdevlib

//

// Changelog:

// ... - ongoing debug release

// NOTE: THIS IS ONLY A PARIAL RELEASE. THIS DEVICE CLASS IS CURRENTLY

UNDERGOING ACTIVE

// DEVELOPMENT AND IS STILL MISSING SOME IMPORTANT FEATURES. PLEASE KEEP THIS

IN MIND IF

// YOU DECIDE TO USE THIS PARTICULAR CODE FOR ANYTHING.

/* ============================================

I2Cdev device library code is placed under the MIT license

Copyright (c) 2012 Jeff Rowberg

Permission is hereby granted, free of charge, to any person obtaining a copy

of this software and associated documentation files (the "Software"), to deal

in the Software without restriction, including without limitation the rights

to use, copy, modify, merge, publish, distribute, sublicense, and/or sell

copies of the Software, and to permit persons to whom the Software is

furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in

all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,

FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE

AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER

LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,

OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN

THE SOFTWARE.

===============================================

*/

#ifndef _MPU6050_H_

#define _MPU6050_H_

#include "I2Cdev.h"

#include <avr/pgmspace.h>

//Magnetometer Registers

#define MPU9150_RA_MAG_ADDRESS 0x0C

#define MPU9150_RA_MAG_XOUT_L 0x03

#define MPU9150_RA_MAG_XOUT_H 0x04

#define MPU9150_RA_MAG_YOUT_L 0x05

#define MPU9150_RA_MAG_YOUT_H 0x06

#define MPU9150_RA_MAG_ZOUT_L 0x07

Glosario

90

90

#define MPU9150_RA_MAG_ZOUT_H 0x08

#define MPU6050_ADDRESS_AD0_LOW 0x69 // address pin low (GND), default

for InvenSense evaluation board

#define MPU6050_ADDRESS_AD0_HIGH 0x69 // address pin high (VCC)

#define MPU6050_DEFAULT_ADDRESS MPU6050_ADDRESS_AD0_LOW

#define MPU6050_RA_XG_OFFS_TC 0x00 //[7] PWR_MODE, [6:1] XG_OFFS_TC,

[0] OTP_BNK_VLD

#define MPU6050_RA_YG_OFFS_TC 0x01 //[7] PWR_MODE, [6:1] YG_OFFS_TC,

[0] OTP_BNK_VLD

#define MPU6050_RA_ZG_OFFS_TC 0x02 //[7] PWR_MODE, [6:1] ZG_OFFS_TC,

[0] OTP_BNK_VLD

#define MPU6050_RA_X_FINE_GAIN 0x03 //[7:0] X_FINE_GAIN

#define MPU6050_RA_Y_FINE_GAIN 0x04 //[7:0] Y_FINE_GAIN

#define MPU6050_RA_Z_FINE_GAIN 0x05 //[7:0] Z_FINE_GAIN

#define MPU6050_RA_XA_OFFS_H 0x06 //[15:0] XA_OFFS

#define MPU6050_RA_XA_OFFS_L_TC 0x07

#define MPU6050_RA_YA_OFFS_H 0x08 //[15:0] YA_OFFS

#define MPU6050_RA_YA_OFFS_L_TC 0x09

#define MPU6050_RA_ZA_OFFS_H 0x0A //[15:0] ZA_OFFS

#define MPU6050_RA_ZA_OFFS_L_TC 0x0B

#define MPU6050_RA_XG_OFFS_USRH 0x13 //[15:0] XG_OFFS_USR

#define MPU6050_RA_XG_OFFS_USRL 0x14

#define MPU6050_RA_YG_OFFS_USRH 0x15 //[15:0] YG_OFFS_USR

#define MPU6050_RA_YG_OFFS_USRL 0x16

#define MPU6050_RA_ZG_OFFS_USRH 0x17 //[15:0] ZG_OFFS_USR

#define MPU6050_RA_ZG_OFFS_USRL 0x18

#define MPU6050_RA_SMPLRT_DIV 0x19

#define MPU6050_RA_CONFIG 0x1A

#define MPU6050_RA_GYRO_CONFIG 0x1B

#define MPU6050_RA_ACCEL_CONFIG 0x1C

#define MPU6050_RA_FF_THR 0x1D

#define MPU6050_RA_FF_DUR 0x1E

#define MPU6050_RA_MOT_THR 0x1F

#define MPU6050_RA_MOT_DUR 0x20

#define MPU6050_RA_ZRMOT_THR 0x21

#define MPU6050_RA_ZRMOT_DUR 0x22

#define MPU6050_RA_FIFO_EN 0x23

#define MPU6050_RA_I2C_MST_CTRL 0x24

#define MPU6050_RA_I2C_SLV0_ADDR 0x25

#define MPU6050_RA_I2C_SLV0_REG 0x26

#define MPU6050_RA_I2C_SLV0_CTRL 0x27



#define MPU6050_RA_I2C_SLV1_CTRL 0x2A

#define MPU6050_RA_I2C_SLV2_ADDR 0x2B

#define MPU6050_RA_I2C_SLV2_REG 0x2C

#define MPU6050_RA_I2C_SLV2_CTRL 0x2D

#define MPU6050_RA_I2C_SLV3_ADDR 0x2E

#define MPU6050_RA_I2C_SLV3_REG 0x2F




#define MPU6050_RA_I2C_SLV4_DO 0x33


#define MPU6050_RA_I2C_SLV4_DI 0x35

#define MPU6050_RA_I2C_MST_STATUS 0x36

#define MPU6050_RA_INT_PIN_CFG 0x37

#define MPU6050_RA_INT_ENABLE 0x38

#define MPU6050_RA_DMP_INT_STATUS 0x39

#define MPU6050_RA_INT_STATUS 0x3A

91


#define MPU6050_RA_ACCEL_XOUT_H 0x3B

#define MPU6050_RA_ACCEL_XOUT_L 0x3C

#define MPU6050_RA_ACCEL_YOUT_H 0x3D

#define MPU6050_RA_ACCEL_YOUT_L 0x3E

#define MPU6050_RA_ACCEL_ZOUT_H 0x3F

#define MPU6050_RA_ACCEL_ZOUT_L 0x40

#define MPU6050_RA_TEMP_OUT_H 0x41

#define MPU6050_RA_TEMP_OUT_L 0x42

#define MPU6050_RA_GYRO_XOUT_H 0x43

#define MPU6050_RA_GYRO_XOUT_L 0x44

#define MPU6050_RA_GYRO_YOUT_H 0x45

#define MPU6050_RA_GYRO_YOUT_L 0x46

#define MPU6050_RA_GYRO_ZOUT_H 0x47

#define MPU6050_RA_GYRO_ZOUT_L 0x48

#define MPU6050_RA_EXT_SENS_DATA_00 0x49

#define MPU6050_RA_EXT_SENS_DATA_01 0x4A

#define MPU6050_RA_EXT_SENS_DATA_02 0x4B

#define MPU6050_RA_EXT_SENS_DATA_03 0x4C

#define MPU6050_RA_EXT_SENS_DATA_04 0x4D

#define MPU6050_RA_EXT_SENS_DATA_05 0x4E

#define MPU6050_RA_EXT_SENS_DATA_06 0x4F











#define MPU6050_RA_EXT_SENS_DATA_17 0x5A

#define MPU6050_RA_EXT_SENS_DATA_18 0x5B

#define MPU6050_RA_EXT_SENS_DATA_19 0x5C

#define MPU6050_RA_EXT_SENS_DATA_20 0x5D

#define MPU6050_RA_EXT_SENS_DATA_21 0x5E

#define MPU6050_RA_EXT_SENS_DATA_22 0x5F


#define MPU6050_RA_MOT_DETECT_STATUS 0x61





#define MPU6050_RA_I2C_MST_DELAY_CTRL 0x67

#define MPU6050_RA_SIGNAL_PATH_RESET 0x68

#define MPU6050_RA_MOT_DETECT_CTRL 0x69

#define MPU6050_RA_USER_CTRL 0x6A

#define MPU6050_RA_PWR_MGMT_1 0x6B

#define MPU6050_RA_PWR_MGMT_2 0x6C

#define MPU6050_RA_BANK_SEL 0x6D

#define MPU6050_RA_MEM_START_ADDR 0x6E

#define MPU6050_RA_MEM_R_W 0x6F

#define MPU6050_RA_DMP_CFG_1 0x70

#define MPU6050_RA_DMP_CFG_2 0x71

#define MPU6050_RA_FIFO_COUNTH 0x72

#define MPU6050_RA_FIFO_COUNTL 0x73

#define MPU6050_RA_FIFO_R_W 0x74

#define MPU6050_RA_WHO_AM_I 0x75

#define MPU6050_TC_PWR_MODE_BIT 7

#define MPU6050_TC_OFFSET_BIT 6

#define MPU6050_TC_OFFSET_LENGTH 6

Glosario

92

92

#define MPU6050_TC_OTP_BNK_VLD_BIT 0

#define MPU6050_VDDIO_LEVEL_VLOGIC 0

#define MPU6050_VDDIO_LEVEL_VDD 1

#define MPU6050_CFG_EXT_SYNC_SET_BIT 5

#define MPU6050_CFG_EXT_SYNC_SET_LENGTH 3

#define MPU6050_CFG_DLPF_CFG_BIT 2

#define MPU6050_CFG_DLPF_CFG_LENGTH 3

#define MPU6050_EXT_SYNC_DISABLED 0x0

#define MPU6050_EXT_SYNC_TEMP_OUT_L 0x1

#define MPU6050_EXT_SYNC_GYRO_XOUT_L 0x2

#define MPU6050_EXT_SYNC_GYRO_YOUT_L 0x3

#define MPU6050_EXT_SYNC_GYRO_ZOUT_L 0x4

#define MPU6050_EXT_SYNC_ACCEL_XOUT_L 0x5

#define MPU6050_EXT_SYNC_ACCEL_YOUT_L 0x6

#define MPU6050_EXT_SYNC_ACCEL_ZOUT_L 0x7

#define MPU6050_DLPF_BW_256 0x00







#define MPU6050_GCONFIG_FS_SEL_BIT 4

#define MPU6050_GCONFIG_FS_SEL_LENGTH 2

#define MPU6050_GYRO_FS_250 0x00




#define MPU6050_ACONFIG_XA_ST_BIT 7

#define MPU6050_ACONFIG_YA_ST_BIT 6

#define MPU6050_ACONFIG_ZA_ST_BIT 5

#define MPU6050_ACONFIG_AFS_SEL_BIT 4

#define MPU6050_ACONFIG_AFS_SEL_LENGTH 2

#define MPU6050_ACONFIG_ACCEL_HPF_BIT 2

#define MPU6050_ACONFIG_ACCEL_HPF_LENGTH 3

#define MPU6050_ACCEL_FS_2 0x00




#define MPU6050_DHPF_RESET 0x00

#define MPU6050_DHPF_5 0x01

#define MPU6050_DHPF_2P5 0x02



#define MPU6050_DHPF_HOLD 0x07

#define MPU6050_TEMP_FIFO_EN_BIT 7

#define MPU6050_XG_FIFO_EN_BIT 6

#define MPU6050_YG_FIFO_EN_BIT 5

#define MPU6050_ZG_FIFO_EN_BIT 4

#define MPU6050_ACCEL_FIFO_EN_BIT 3

#define MPU6050_SLV2_FIFO_EN_BIT 2


93



#define MPU6050_MULT_MST_EN_BIT 7

#define MPU6050_WAIT_FOR_ES_BIT 6

#define MPU6050_SLV_3_FIFO_EN_BIT 5

#define MPU6050_I2C_MST_P_NSR_BIT 4

#define MPU6050_I2C_MST_CLK_BIT 3

#define MPU6050_I2C_MST_CLK_LENGTH 4

#define MPU6050_CLOCK_DIV_348 0x0










#define MPU6050_CLOCK_DIV_471 0xA

#define MPU6050_CLOCK_DIV_444 0xB

#define MPU6050_CLOCK_DIV_421 0xC

#define MPU6050_CLOCK_DIV_400 0xD

#define MPU6050_CLOCK_DIV_381 0xE

#define MPU6050_CLOCK_DIV_364 0xF

#define MPU6050_I2C_SLV_RW_BIT 7

#define MPU6050_I2C_SLV_ADDR_BIT 6

#define MPU6050_I2C_SLV_ADDR_LENGTH 7

#define MPU6050_I2C_SLV_EN_BIT 7

#define MPU6050_I2C_SLV_BYTE_SW_BIT 6

#define MPU6050_I2C_SLV_REG_DIS_BIT 5

#define MPU6050_I2C_SLV_GRP_BIT 4

#define MPU6050_I2C_SLV_LEN_BIT 3

#define MPU6050_I2C_SLV_LEN_LENGTH 4

#define MPU6050_I2C_SLV4_RW_BIT 7

#define MPU6050_I2C_SLV4_ADDR_BIT 6

#define MPU6050_I2C_SLV4_ADDR_LENGTH 7

#define MPU6050_I2C_SLV4_EN_BIT 7

#define MPU6050_I2C_SLV4_INT_EN_BIT 6

#define MPU6050_I2C_SLV4_REG_DIS_BIT 5

#define MPU6050_I2C_SLV4_MST_DLY_BIT 4

#define MPU6050_I2C_SLV4_MST_DLY_LENGTH 5

#define MPU6050_MST_PASS_THROUGH_BIT 7

#define MPU6050_MST_I2C_SLV4_DONE_BIT 6

#define MPU6050_MST_I2C_LOST_ARB_BIT 5

#define MPU6050_MST_I2C_SLV4_NACK_BIT 4





#define MPU6050_INTCFG_INT_LEVEL_BIT 7

#define MPU6050_INTCFG_INT_OPEN_BIT 6

#define MPU6050_INTCFG_LATCH_INT_EN_BIT 5

#define MPU6050_INTCFG_INT_RD_CLEAR_BIT 4

#define MPU6050_INTCFG_FSYNC_INT_LEVEL_BIT 3

#define MPU6050_INTCFG_FSYNC_INT_EN_BIT 2

#define MPU6050_INTCFG_I2C_BYPASS_EN_BIT 1

#define MPU6050_INTCFG_CLKOUT_EN_BIT 0

Glosario

94

94

#define MPU6050_INTMODE_ACTIVEHIGH 0x00

#define MPU6050_INTMODE_ACTIVELOW 0x01

#define MPU6050_INTDRV_PUSHPULL 0x00

#define MPU6050_INTDRV_OPENDRAIN 0x01

#define MPU6050_INTLATCH_50USPULSE 0x00

#define MPU6050_INTLATCH_WAITCLEAR 0x01

#define MPU6050_INTCLEAR_STATUSREAD 0x00

#define MPU6050_INTCLEAR_ANYREAD 0x01

#define MPU6050_INTERRUPT_FF_BIT 7

#define MPU6050_INTERRUPT_MOT_BIT 6

#define MPU6050_INTERRUPT_ZMOT_BIT 5

#define MPU6050_INTERRUPT_FIFO_OFLOW_BIT 4

#define MPU6050_INTERRUPT_I2C_MST_INT_BIT 3

#define MPU6050_INTERRUPT_PLL_RDY_INT_BIT 2

#define MPU6050_INTERRUPT_DMP_INT_BIT 1

#define MPU6050_INTERRUPT_DATA_RDY_BIT 0

// TODO: figure out what these actually do

// UMPL source code is not very obivous

#define MPU6050_DMPINT_5_BIT 5






#define MPU6050_MOTION_MOT_XNEG_BIT 7

#define MPU6050_MOTION_MOT_XPOS_BIT 6

#define MPU6050_MOTION_MOT_YNEG_BIT 5

#define MPU6050_MOTION_MOT_YPOS_BIT 4

#define MPU6050_MOTION_MOT_ZNEG_BIT 3

#define MPU6050_MOTION_MOT_ZPOS_BIT 2

#define MPU6050_MOTION_MOT_ZRMOT_BIT 0

#define MPU6050_DELAYCTRL_DELAY_ES_SHADOW_BIT 7

#define MPU6050_DELAYCTRL_I2C_SLV4_DLY_EN_BIT 4





#define MPU6050_PATHRESET_GYRO_RESET_BIT 2

#define MPU6050_PATHRESET_ACCEL_RESET_BIT 1

#define MPU6050_PATHRESET_TEMP_RESET_BIT 0

#define MPU6050_DETECT_ACCEL_ON_DELAY_BIT 5

#define MPU6050_DETECT_ACCEL_ON_DELAY_LENGTH 2

#define MPU6050_DETECT_FF_COUNT_BIT 3

#define MPU6050_DETECT_FF_COUNT_LENGTH 2

#define MPU6050_DETECT_MOT_COUNT_BIT 1

#define MPU6050_DETECT_MOT_COUNT_LENGTH 2

#define MPU6050_DETECT_DECREMENT_RESET 0x0

#define MPU6050_DETECT_DECREMENT_1 0x1



95


#define MPU6050_USERCTRL_DMP_EN_BIT 7

#define MPU6050_USERCTRL_FIFO_EN_BIT 6

#define MPU6050_USERCTRL_I2C_MST_EN_BIT 5

#define MPU6050_USERCTRL_I2C_IF_DIS_BIT 4

#define MPU6050_USERCTRL_DMP_RESET_BIT 3

#define MPU6050_USERCTRL_FIFO_RESET_BIT 2

#define MPU6050_USERCTRL_I2C_MST_RESET_BIT 1

#define MPU6050_USERCTRL_SIG_COND_RESET_BIT 0

#define MPU6050_PWR1_DEVICE_RESET_BIT 7

#define MPU6050_PWR1_SLEEP_BIT 6

#define MPU6050_PWR1_CYCLE_BIT 5

#define MPU6050_PWR1_TEMP_DIS_BIT 3

#define MPU6050_PWR1_CLKSEL_BIT 2

#define MPU6050_PWR1_CLKSEL_LENGTH 3

#define MPU6050_CLOCK_INTERNAL 0x00

#define MPU6050_CLOCK_PLL_XGYRO 0x01

#define MPU6050_CLOCK_PLL_YGYRO 0x02

#define MPU6050_CLOCK_PLL_ZGYRO 0x03

#define MPU6050_CLOCK_PLL_EXT32K 0x04

#define MPU6050_CLOCK_PLL_EXT19M 0x05

#define MPU6050_CLOCK_KEEP_RESET 0x07

#define MPU6050_PWR2_LP_WAKE_CTRL_BIT 7

#define MPU6050_PWR2_LP_WAKE_CTRL_LENGTH 2

#define MPU6050_PWR2_STBY_XA_BIT 5

#define MPU6050_PWR2_STBY_YA_BIT 4

#define MPU6050_PWR2_STBY_ZA_BIT 3

#define MPU6050_PWR2_STBY_XG_BIT 2

#define MPU6050_PWR2_STBY_YG_BIT 1

#define MPU6050_PWR2_STBY_ZG_BIT 0

#define MPU6050_WAKE_FREQ_1P25 0x0

#define MPU6050_WAKE_FREQ_2P5 0x1

#define MPU6050_WAKE_FREQ_5 0x2

#define MPU6050_WAKE_FREQ_10 0x3

#define MPU6050_BANKSEL_PRFTCH_EN_BIT 6

#define MPU6050_BANKSEL_CFG_USER_BANK_BIT 5

#define MPU6050_BANKSEL_MEM_SEL_BIT 4

#define MPU6050_BANKSEL_MEM_SEL_LENGTH 5

#define MPU6050_WHO_AM_I_BIT 6

#define MPU6050_WHO_AM_I_LENGTH 6

#define MPU6050_DMP_MEMORY_BANKS 8

#define MPU6050_DMP_MEMORY_BANK_SIZE 256

#define MPU6050_DMP_MEMORY_CHUNK_SIZE 16

// note: DMP code memory blocks defined at end of header file

class MPU6050 {

public:

MPU6050();

MPU6050(uint8_t address);

void initialize();

bool testConnection();

// AUX_VDDIO register

uint8_t getAuxVDDIOLevel();

Glosario

96

96

void setAuxVDDIOLevel(uint8_t level);

// SMPLRT_DIV register

uint8_t getRate();

void setRate(uint8_t rate);

uint8_t checkMagStatus();

// CONFIG register

uint8_t getExternalFrameSync();

void setExternalFrameSync(uint8_t sync);

uint8_t getDLPFMode();

void setDLPFMode(uint8_t bandwidth);

// GYRO_CONFIG register

uint8_t getFullScaleGyroRange();

void setFullScaleGyroRange(uint8_t range);

// ACCEL_CONFIG register

bool getAccelXSelfTest();

void setAccelXSelfTest(bool enabled);

bool getAccelYSelfTest();

void setAccelYSelfTest(bool enabled);

bool getAccelZSelfTest();

void setAccelZSelfTest(bool enabled);

uint8_t getFullScaleAccelRange();

void setFullScaleAccelRange(uint8_t range);

uint8_t getDHPFMode();

void setDHPFMode(uint8_t mode);

// FF_THR register

uint8_t getFreefallDetectionThreshold();

void setFreefallDetectionThreshold(uint8_t threshold);

// FF_DUR register

uint8_t getFreefallDetectionDuration();

void setFreefallDetectionDuration(uint8_t duration);

// MOT_THR register

uint8_t getMotionDetectionThreshold();

void setMotionDetectionThreshold(uint8_t threshold);

// MOT_DUR register

uint8_t getMotionDetectionDuration();

void setMotionDetectionDuration(uint8_t duration);

// ZRMOT_THR register

uint8_t getZeroMotionDetectionThreshold();

void setZeroMotionDetectionThreshold(uint8_t threshold);

// ZRMOT_DUR register

uint8_t getZeroMotionDetectionDuration();

void setZeroMotionDetectionDuration(uint8_t duration);

// FIFO_EN register

bool getTempFIFOEnabled();

void setTempFIFOEnabled(bool enabled);

bool getXGyroFIFOEnabled();

void setXGyroFIFOEnabled(bool enabled);

bool getYGyroFIFOEnabled();

void setYGyroFIFOEnabled(bool enabled);

bool getZGyroFIFOEnabled();

97


void setZGyroFIFOEnabled(bool enabled);

bool getAccelFIFOEnabled();

void setAccelFIFOEnabled(bool enabled);

bool getSlave2FIFOEnabled();

void setSlave2FIFOEnabled(bool enabled);





// I2C_MST_CTRL register

bool getMultiMasterEnabled();

void setMultiMasterEnabled(bool enabled);

bool getWaitForExternalSensorEnabled();

void setWaitForExternalSensorEnabled(bool enabled);



bool getSlaveReadWriteTransitionEnabled();

void setSlaveReadWriteTransitionEnabled(bool enabled);

uint8_t getMasterClockSpeed();

void setMasterClockSpeed(uint8_t speed);

// I2C_SLV* registers (Slave 0-3)

uint8_t getSlaveAddress(uint8_t num);

void setSlaveAddress(uint8_t num, uint8_t address);

uint8_t getSlaveRegister(uint8_t num);

void setSlaveRegister(uint8_t num, uint8_t reg);

bool getSlaveEnabled(uint8_t num);

void setSlaveEnabled(uint8_t num, bool enabled);

bool getSlaveWordByteSwap(uint8_t num);

void setSlaveWordByteSwap(uint8_t num, bool enabled);

bool getSlaveWriteMode(uint8_t num);

void setSlaveWriteMode(uint8_t num, bool mode);

bool getSlaveWordGroupOffset(uint8_t num);

void setSlaveWordGroupOffset(uint8_t num, bool enabled);

uint8_t getSlaveDataLength(uint8_t num);

void setSlaveDataLength(uint8_t num, uint8_t length);

// I2C_SLV* registers (Slave 4)

uint8_t getSlave4Address();

void setSlave4Address(uint8_t address);

uint8_t getSlave4Register();

void setSlave4Register(uint8_t reg);

void setSlave4OutputByte(uint8_t data);

bool getSlave4Enabled();

void setSlave4Enabled(bool enabled);

bool getSlave4InterruptEnabled();

void setSlave4InterruptEnabled(bool enabled);

bool getSlave4WriteMode();

void setSlave4WriteMode(bool mode);

uint8_t getSlave4MasterDelay();

void setSlave4MasterDelay(uint8_t delay);

uint8_t getSlate4InputByte();

// I2C_MST_STATUS register

bool getPassthroughStatus();

bool getSlave4IsDone();

bool getLostArbitration();

bool getSlave4Nack();




Glosario

98

98


// INT_PIN_CFG register

bool getInterruptMode();

void setInterruptMode(bool mode);

bool getInterruptDrive();

void setInterruptDrive(bool drive);

bool getInterruptLatch();

void setInterruptLatch(bool latch);

bool getInterruptLatchClear();

void setInterruptLatchClear(bool clear);

bool getFSyncInterruptLevel();

void setFSyncInterruptLevel(bool level);

bool getFSyncInterruptEnabled();

void setFSyncInterruptEnabled(bool enabled);

bool getI2CBypassEnabled();

void setI2CBypassEnabled(bool enabled);

bool getClockOutputEnabled();

void setClockOutputEnabled(bool enabled);

// INT_ENABLE register

uint8_t getIntEnabled();

void setIntEnabled(uint8_t enabled);

bool getIntFreefallEnabled();

void setIntFreefallEnabled(bool enabled);

bool getIntMotionEnabled();

void setIntMotionEnabled(bool enabled);

bool getIntZeroMotionEnabled();

void setIntZeroMotionEnabled(bool enabled);

bool getIntFIFOBufferOverflowEnabled();

void setIntFIFOBufferOverflowEnabled(bool enabled);

bool getIntI2CMasterEnabled();

void setIntI2CMasterEnabled(bool enabled);

bool getIntDataReadyEnabled();

void setIntDataReadyEnabled(bool enabled);

// INT_STATUS register

uint8_t getIntStatus();

bool getIntFreefallStatus();

bool getIntMotionStatus();

bool getIntZeroMotionStatus();

bool getIntFIFOBufferOverflowStatus();

bool getIntI2CMasterStatus();

bool getIntDataReadyStatus();

// ACCEL_*OUT_* registers

void getMotion9(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx,

int16_t* gy, int16_t* gz, int16_t* mx, int16_t* my, int16_t* mz);

void getMotion6(int16_t* ax, int16_t* ay, int16_t* az, int16_t* gx,

int16_t* gy, int16_t* gz);

void getAcceleration(int16_t* x, int16_t* y, int16_t* z);

int16_t getAccelerationX();

int16_t getAccelerationY();

int16_t getAccelerationZ();

// TEMP_OUT_* registers

int16_t getTemperature();

// GYRO_*OUT_* registers

void getRotation(int16_t* x, int16_t* y, int16_t* z);

int16_t getRotationX();

int16_t getRotationY();

99


int16_t getRotationZ();

// MAG_*OUT_* registers

void getMag(int16_t* x, int16_t* y, int16_t* z);

// EXT_SENS_DATA_* registers

uint8_t getExternalSensorByte(int position);

uint16_t getExternalSensorWord(int position);

uint32_t getExternalSensorDWord(int position);

// MOT_DETECT_STATUS register

bool getXNegMotionDetected();

bool getXPosMotionDetected();

bool getYNegMotionDetected();

bool getYPosMotionDetected();

bool getZNegMotionDetected();

bool getZPosMotionDetected();

bool getZeroMotionDetected();

// I2C_SLV*_DO register

void setSlaveOutputByte(uint8_t num, uint8_t data);

// I2C_MST_DELAY_CTRL register

bool getExternalShadowDelayEnabled();

void setExternalShadowDelayEnabled(bool enabled);

bool getSlaveDelayEnabled(uint8_t num);

void setSlaveDelayEnabled(uint8_t num, bool enabled);

// SIGNAL_PATH_RESET register

void resetGyroscopePath();

void resetAccelerometerPath();

void resetTemperaturePath();

// MOT_DETECT_CTRL register

uint8_t getAccelerometerPowerOnDelay();

void setAccelerometerPowerOnDelay(uint8_t delay);

uint8_t getFreefallDetectionCounterDecrement();

void setFreefallDetectionCounterDecrement(uint8_t decrement);

uint8_t getMotionDetectionCounterDecrement();

void setMotionDetectionCounterDecrement(uint8_t decrement);

// USER_CTRL register

bool getFIFOEnabled();

void setFIFOEnabled(bool enabled);

bool getI2CMasterModeEnabled();

void setI2CMasterModeEnabled(bool enabled);

void switchSPIEnabled(bool enabled);

void resetFIFO();

void resetI2CMaster();

void resetSensors();

// PWR_MGMT_1 register

void reset();

bool getSleepEnabled();

void setSleepEnabled(bool enabled);

bool getWakeCycleEnabled();

void setWakeCycleEnabled(bool enabled);

bool getTempSensorEnabled();

void setTempSensorEnabled(bool enabled);

uint8_t getClockSource();

void setClockSource(uint8_t source);

Glosario

100

100

// PWR_MGMT_2 register

uint8_t getWakeFrequency();

void setWakeFrequency(uint8_t frequency);

bool getStandbyXAccelEnabled();

void setStandbyXAccelEnabled(bool enabled);

bool getStandbyYAccelEnabled();

void setStandbyYAccelEnabled(bool enabled);

bool getStandbyZAccelEnabled();

void setStandbyZAccelEnabled(bool enabled);

bool getStandbyXGyroEnabled();

void setStandbyXGyroEnabled(bool enabled);

bool getStandbyYGyroEnabled();

void setStandbyYGyroEnabled(bool enabled);

bool getStandbyZGyroEnabled();

void setStandbyZGyroEnabled(bool enabled);

// FIFO_COUNT_* registers

uint16_t getFIFOCount();

// FIFO_R_W register

uint8_t getFIFOByte();

void setFIFOByte(uint8_t data);

void getFIFOBytes(uint8_t *data, uint8_t length);

// WHO_AM_I register

uint8_t getDeviceID();

void setDeviceID(uint8_t id);

// ======== UNDOCUMENTED/DMP REGISTERS/METHODS ========

// XG_OFFS_TC register

uint8_t getOTPBankValid();

void setOTPBankValid(bool enabled);

int8_t getXGyroOffset();

void setXGyroOffset(int8_t offset);

// YG_OFFS_TC register

int8_t getYGyroOffset();

void setYGyroOffset(int8_t offset);

// ZG_OFFS_TC register

int8_t getZGyroOffset();

void setZGyroOffset(int8_t offset);

// X_FINE_GAIN register

int8_t getXFineGain();

void setXFineGain(int8_t gain);

// Y_FINE_GAIN register

int8_t getYFineGain();

void setYFineGain(int8_t gain);

// Z_FINE_GAIN register

int8_t getZFineGain();

void setZFineGain(int8_t gain);

// XA_OFFS_* registers

int16_t getXAccelOffset();

void setXAccelOffset(int16_t offset);

// YA_OFFS_* register

int16_t getYAccelOffset();

101


void setYAccelOffset(int16_t offset);

// ZA_OFFS_* register

int16_t getZAccelOffset();

void setZAccelOffset(int16_t offset);

// XG_OFFS_USR* registers

int16_t getXGyroOffsetUser();

void setXGyroOffsetUser(int16_t offset);

// YG_OFFS_USR* register

int16_t getYGyroOffsetUser();

void setYGyroOffsetUser(int16_t offset);

// ZG_OFFS_USR* register

int16_t getZGyroOffsetUser();

void setZGyroOffsetUser(int16_t offset);

// INT_ENABLE register (DMP functions)

bool getIntPLLReadyEnabled();

void setIntPLLReadyEnabled(bool enabled);

bool getIntDMPEnabled();

void setIntDMPEnabled(bool enabled);

// DMP_INT_STATUS

bool getDMPInt5Status();






// INT_STATUS register (DMP functions)

bool getIntPLLReadyStatus();

bool getIntDMPStatus();

// USER_CTRL register (DMP functions)

bool getDMPEnabled();

void setDMPEnabled(bool enabled);

void resetDMP();

// BANK_SEL register

void setMemoryBank(uint8_t bank, bool prefetchEnabled=false, bool

userBank=false);

// MEM_START_ADDR register

void setMemoryStartAddress(uint8_t address);

// MEM_R_W register

uint8_t readMemoryByte();

void writeMemoryByte(uint8_t data);

void readMemoryBlock(uint8_t *data, uint16_t dataSize, uint8_t

bank=0, uint8_t address=0);

bool writeMemoryBlock(const uint8_t *data, uint16_t dataSize, uint8_t

bank=0, uint8_t address=0, bool verify=true, bool useProgMem=false);

bool writeProgMemoryBlock(const uint8_t *data, uint16_t dataSize,

uint8_t bank=0, uint8_t address=0, bool verify=true);

bool writeDMPConfigurationSet(const uint8_t *data, uint16_t dataSize,

bool useProgMem=false);

bool writeProgDMPConfigurationSet(const uint8_t *data, uint16_t

dataSize);

Glosario

102

102

// DMP_CFG_1 register

uint8_t getDMPConfig1();

void setDMPConfig1(uint8_t config);

// DMP_CFG_2 register

uint8_t getDMPConfig2();

void setDMPConfig2(uint8_t config);

// special methods for MotionApps 2.0 implementation

#ifdef MPU6050_INCLUDE_DMP_MOTIONAPPS20

uint8_t *dmpPacketBuffer;

uint16_t dmpPacketSize;

uint8_t dmpInitialize();

bool dmpPacketAvailable();

uint8_t dmpSetFIFORate(uint8_t fifoRate);

uint8_t dmpGetFIFORate();

uint8_t dmpGetSampleStepSizeMS();

uint8_t dmpGetSampleFrequency();

int32_t dmpDecodeTemperature(int8_t tempReg);

// Register callbacks after a packet of FIFO data is processed

//uint8_t dmpRegisterFIFORateProcess(inv_obj_func func, int16_t

priority);

//uint8_t dmpUnregisterFIFORateProcess(inv_obj_func func);

uint8_t dmpRunFIFORateProcesses();

// Setup FIFO for various output

uint8_t dmpSendQuaternion(uint_fast16_t accuracy);

uint8_t dmpSendGyro(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendAccel(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendLinearAccel(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendLinearAccelInWorld(uint_fast16_t elements,

uint_fast16_t accuracy);

uint8_t dmpSendControlData(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendSensorData(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendExternalSensorData(uint_fast16_t elements,


uint8_t dmpSendGravity(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendPacketNumber(uint_fast16_t accuracy);

uint8_t dmpSendQuantizedAccel(uint_fast16_t elements,


uint8_t dmpSendEIS(uint_fast16_t elements, uint_fast16_t

accuracy);

// Get Fixed Point data from FIFO

uint8_t dmpGetAccel(int32_t *data, const uint8_t* packet=0);


uint8_t dmpGetAccel(VectorInt16 *v, const uint8_t* packet=0);

uint8_t dmpGetQuaternion(int32_t *data, const uint8_t* packet=0);


uint8_t dmpGetQuaternion(Quaternion *q, const uint8_t* packet=0);

uint8_t dmpGet6AxisQuaternion(int32_t *data, const uint8_t*

packet=0);

103



packet=0);

uint8_t dmpGet6AxisQuaternion(Quaternion *q, const uint8_t*

packet=0);

uint8_t dmpGetRelativeQuaternion(int32_t *data, const uint8_t*

packet=0);


packet=0);

uint8_t dmpGetRelativeQuaternion(Quaternion *data, const uint8_t*

packet=0);

uint8_t dmpGetGyro(int32_t *data, const uint8_t* packet=0);


uint8_t dmpGetGyro(VectorInt16 *v, const uint8_t* packet=0);

uint8_t dmpGetMag (VectorInt16 *v, const uint8_t* packet=0);

uint8_t dmpSetLinearAccelFilterCoefficient(float coef);

uint8_t dmpGetLinearAccel(int32_t *data, const uint8_t*

packet=0);


packet=0);

uint8_t dmpGetLinearAccel(VectorInt16 *v, const uint8_t*

packet=0);

uint8_t dmpGetLinearAccel(VectorInt16 *v, VectorInt16 *vRaw,

VectorFloat *gravity);

uint8_t dmpGetLinearAccelInWorld(int32_t *data, const uint8_t*

packet=0);


packet=0);

uint8_t dmpGetLinearAccelInWorld(VectorInt16 *v, const uint8_t*

packet=0);

uint8_t dmpGetLinearAccelInWorld(VectorInt16 *v, VectorInt16

*vReal, Quaternion *q);

uint8_t dmpGetGyroAndAccelSensor(int32_t *data, const uint8_t*

packet=0);


packet=0);

uint8_t dmpGetGyroAndAccelSensor(VectorInt16 *g, VectorInt16 *a,

const uint8_t* packet=0);

uint8_t dmpGetGyroSensor(int32_t *data, const uint8_t* packet=0);


uint8_t dmpGetGyroSensor(VectorInt16 *v, const uint8_t*

packet=0);

uint8_t dmpGetControlData(int32_t *data, const uint8_t*

packet=0);

uint8_t dmpGetTemperature(int32_t *data, const uint8_t*

packet=0);

uint8_t dmpGetGravity(int32_t *data, const uint8_t* packet=0);


uint8_t dmpGetGravity(VectorInt16 *v, const uint8_t* packet=0);

uint8_t dmpGetGravity(VectorFloat *v, Quaternion *q);

uint8_t dmpGetUnquantizedAccel(int32_t *data, const uint8_t*

packet=0);


packet=0);

uint8_t dmpGetUnquantizedAccel(VectorInt16 *v, const uint8_t*

packet=0);

uint8_t dmpGetQuantizedAccel(int32_t *data, const uint8_t*

packet=0);


packet=0);

uint8_t dmpGetQuantizedAccel(VectorInt16 *v, const uint8_t*

packet=0);

Glosario

104

104

uint8_t dmpGetExternalSensorData(int32_t *data, uint16_t size,


uint8_t dmpGetEIS(int32_t *data, const uint8_t* packet=0);

uint8_t dmpGetEuler(float *data, Quaternion *q);

uint8_t dmpGetYawPitchRoll(float *data, Quaternion *q,


// Get Floating Point data from FIFO

uint8_t dmpGetAccelFloat(float *data, const uint8_t* packet=0);

uint8_t dmpGetQuaternionFloat(float *data, const uint8_t*

packet=0);

uint8_t dmpProcessFIFOPacket(const unsigned char *dmpData);

uint8_t dmpReadAndProcessFIFOPacket(uint8_t numPackets, uint8_t

*processed=NULL);

uint8_t dmpSetFIFOProcessedCallback(void (*func) (void));

uint8_t dmpInitFIFOParam();

uint8_t dmpCloseFIFO();

uint8_t dmpSetGyroDataSource(uint8_t source);

uint8_t dmpDecodeQuantizedAccel();

uint32_t dmpGetGyroSumOfSquare();

uint32_t dmpGetAccelSumOfSquare();

void dmpOverrideQuaternion(long *q);

uint16_t dmpGetFIFOPacketSize();

#endif

// special methods for MotionApps 4.1 implementation

#ifdef MPU6050_INCLUDE_DMP_MOTIONAPPS41

uint8_t *dmpPacketBuffer;

uint16_t dmpPacketSize;

uint8_t dmpInitialize();

bool dmpPacketAvailable();

uint8_t dmpSetFIFORate(uint8_t fifoRate);

uint8_t dmpGetFIFORate();

uint8_t dmpGetSampleStepSizeMS();

uint8_t dmpGetSampleFrequency();

int32_t dmpDecodeTemperature(int8_t tempReg);

// Register callbacks after a packet of FIFO data is processed

//uint8_t dmpRegisterFIFORateProcess(inv_obj_func func, int16_t

priority);

//uint8_t dmpUnregisterFIFORateProcess(inv_obj_func func);

uint8_t dmpRunFIFORateProcesses();

// Setup FIFO for various output

uint8_t dmpSendQuaternion(uint_fast16_t accuracy);

uint8_t dmpSendGyro(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendAccel(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendLinearAccel(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendLinearAccelInWorld(uint_fast16_t elements,


uint8_t dmpSendControlData(uint_fast16_t elements, uint_fast16_t

accuracy);

105


uint8_t dmpSendSensorData(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendExternalSensorData(uint_fast16_t elements,


uint8_t dmpSendGravity(uint_fast16_t elements, uint_fast16_t

accuracy);

uint8_t dmpSendPacketNumber(uint_fast16_t accuracy);

uint8_t dmpSendQuantizedAccel(uint_fast16_t elements,


uint8_t dmpSendEIS(uint_fast16_t elements, uint_fast16_t

accuracy);

// Get Fixed Point data from FIFO



uint8_t dmpGetAccel(VectorInt16 *v, const uint8_t* packet=0);



uint8_t dmpGetQuaternion(Quaternion *q, const uint8_t* packet=0);


packet=0);


packet=0);

uint8_t dmpGet6AxisQuaternion(Quaternion *q, const uint8_t*

packet=0);


packet=0);


packet=0);

uint8_t dmpGetRelativeQuaternion(Quaternion *data, const uint8_t*

packet=0);



uint8_t dmpGetGyro(VectorInt16 *v, const uint8_t* packet=0);

uint8_t dmpGetMag(int16_t *data, const uint8_t* packet=0);

uint8_t dmpGetMag(VectorInt16 *v, const uint8_t* packet=0);

uint8_t dmpSetLinearAccelFilterCoefficient(float coef);


packet=0);


packet=0);

uint8_t dmpGetLinearAccel(VectorInt16 *v, const uint8_t*

packet=0);

uint8_t dmpGetLinearAccel(VectorInt16 *v, VectorInt16 *vRaw,



packet=0);


packet=0);

uint8_t dmpGetLinearAccelInWorld(VectorInt16 *v, const uint8_t*

packet=0);

uint8_t dmpGetLinearAccelInWorld(VectorInt16 *v, VectorInt16

*vReal, Quaternion *q);


packet=0);


packet=0);

uint8_t dmpGetGyroAndAccelSensor(VectorInt16 *g, VectorInt16 *a,




Glosario

106

106

uint8_t dmpGetGyroSensor(VectorInt16 *v, const uint8_t*

packet=0);

uint8_t dmpGetControlData(int32_t *data, const uint8_t*

packet=0);

uint8_t dmpGetTemperature(int32_t *data, const uint8_t*

packet=0);



uint8_t dmpGetGravity(VectorInt16 *v, const uint8_t* packet=0);

uint8_t dmpGetGravity(VectorFloat *v, Quaternion *q);


packet=0);


packet=0);

uint8_t dmpGetUnquantizedAccel(VectorInt16 *v, const uint8_t*

packet=0);


packet=0);


packet=0);

uint8_t dmpGetQuantizedAccel(VectorInt16 *v, const uint8_t*

packet=0);

uint8_t dmpGetExternalSensorData(int32_t *data, uint16_t size,


uint8_t dmpGetEIS(int32_t *data, const uint8_t* packet=0);

uint8_t dmpGetEuler(float *data, Quaternion *q);

uint8_t dmpGetYawPitchRoll(float *data, Quaternion *q,


// Get Floating Point data from FIFO

uint8_t dmpGetAccelFloat(float *data, const uint8_t* packet=0);

uint8_t dmpGetQuaternionFloat(float *data, const uint8_t*

packet=0);

uint8_t dmpProcessFIFOPacket(const unsigned char *dmpData);

uint8_t dmpReadAndProcessFIFOPacket(uint8_t numPackets, uint8_t

*processed=NULL);

uint8_t dmpSetFIFOProcessedCallback(void (*func) (void));

uint8_t dmpInitFIFOParam();

uint8_t dmpCloseFIFO();

uint8_t dmpSetGyroDataSource(uint8_t source);

uint8_t dmpDecodeQuantizedAccel();

uint32_t dmpGetGyroSumOfSquare();

uint32_t dmpGetAccelSumOfSquare();

void dmpOverrideQuaternion(long *q);

uint16_t dmpGetFIFOPacketSize();

#endif

private:

uint8_t devAddr;

uint8_t buffer[14];

};

#endif /* _MPU6050_H_ */

Librería I2C

107


// I2Cdev library collection - Main I2C device class header file

// Abstracts bit and byte I2C R/W functions into a convenient class

// 6/9/2012 by Jeff Rowberg <[email protected]>

//

// Changelog:

// 2012-06-09 - fix major issue with reading > 32 bytes at a time with

Arduino Wire

// - add compiler warnings when using outdated or IDE or

limited I2Cdev implementation

// 2011-11-01 - fix write*Bits mask calculation (thanks sasquatch @

Arduino forums)

// 2011-10-03 - added automatic Arduino version detection for ease of use

// 2011-10-02 - added Gene Knight's NBWire TwoWire class implementation

with small modifications

// 2011-08-31 - added support for Arduino 1.0 Wire library (methods are

different from 0.x)

// 2011-08-03 - added optional timeout parameter to read* methods to

easily change from default

// 2011-08-02 - added support for 16-bit registers

// - fixed incorrect Doxygen comments on some methods

// - added timeout value for read operations (thanks mem @

Arduino forums)

// 2011-07-30 - changed read/write function structures to return success

or byte counts

// - made all methods static for multi-device memory savings

// 2011-07-28 - initial release

/* ============================================

I2Cdev device library code is placed under the MIT license

Copyright (c) 2012 Jeff Rowberg

Permission is hereby granted, free of charge, to any person obtaining a copy

of this software and associated documentation files (the "Software"), to deal

in the Software without restriction, including without limitation the rights

to use, copy, modify, merge, publish, distribute, sublicense, and/or sell

copies of the Software, and to permit persons to whom the Software is

furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in

all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR

IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,

FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE

AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER

LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,

OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN

THE SOFTWARE.

===============================================

*/

#ifndef _I2CDEV_H_

#define _I2CDEV_H_

// --------------------------------------------------------------------------

---

// I2C interface implementation setting

// --------------------------------------------------------------------------

---

#define I2CDEV_IMPLEMENTATION I2CDEV_ARDUINO_WIRE

Glosario

108

108

// comment this out if you are using a non-optimal IDE/implementation setting

// but want the compiler to shut up about it

#define I2CDEV_IMPLEMENTATION_WARNINGS

// --------------------------------------------------------------------------

---

// I2C interface implementation options

// --------------------------------------------------------------------------

---

#define I2CDEV_ARDUINO_WIRE 1 // Wire object from Arduino

#define I2CDEV_BUILTIN_NBWIRE 2 // Tweaked Wire object from Gene

Knight's NBWire project

// ^^^ NBWire implementation is still

buggy w/some interrupts!

#define I2CDEV_BUILTIN_FASTWIRE 3 // FastWire object from Francesco

Ferrara's project

// ^^^ FastWire implementation in

I2Cdev is INCOMPLETE!

// --------------------------------------------------------------------------

---

// Arduino-style "Serial.print" debug constant (uncomment to enable)

// --------------------------------------------------------------------------

---

//#define I2CDEV_SERIAL_DEBUG

#ifdef ARDUINO

#if ARDUINO < 100

#include "WProgram.h"

#else

#include "Arduino.h"

#endif

#if I2CDEV_IMPLEMENTATION == I2CDEV_ARDUINO_WIRE

#include <Wire.h>

#endif

#else

#include "ArduinoWrapper.h"

#endif

// 1000ms default read timeout (modify with "I2Cdev::readTimeout = [ms];")

#define I2CDEV_DEFAULT_READ_TIMEOUT 1000

class I2Cdev {

public:

I2Cdev();

static int8_t readBit(uint8_t devAddr, uint8_t regAddr, uint8_t

bitNum, uint8_t *data, uint16_t timeout=I2Cdev::readTimeout);

static int8_t readBitW(uint8_t devAddr, uint8_t regAddr, uint8_t

bitNum, uint16_t *data, uint16_t timeout=I2Cdev::readTimeout);

static int8_t readBits(uint8_t devAddr, uint8_t regAddr, uint8_t

bitStart, uint8_t length, uint8_t *data, uint16_t

timeout=I2Cdev::readTimeout);

static int8_t readBitsW(uint8_t devAddr, uint8_t regAddr, uint8_t

bitStart, uint8_t length, uint16_t *data, uint16_t

timeout=I2Cdev::readTimeout);

static int8_t readByte(uint8_t devAddr, uint8_t regAddr, uint8_t

*data, uint16_t timeout=I2Cdev::readTimeout);

static int8_t readWord(uint8_t devAddr, uint8_t regAddr, uint16_t

*data, uint16_t timeout=I2Cdev::readTimeout);

109


static int8_t readBytes(uint8_t devAddr, uint8_t regAddr, uint8_t

length, uint8_t *data, uint16_t timeout=I2Cdev::readTimeout);

static int8_t readWords(uint8_t devAddr, uint8_t regAddr, uint8_t

length, uint16_t *data, uint16_t timeout=I2Cdev::readTimeout);

static bool writeBit(uint8_t devAddr, uint8_t regAddr, uint8_t

bitNum, uint8_t data);

static bool writeBitW(uint8_t devAddr, uint8_t regAddr, uint8_t

bitNum, uint16_t data);

static bool writeBits(uint8_t devAddr, uint8_t regAddr, uint8_t

bitStart, uint8_t length, uint8_t data);

static bool writeBitsW(uint8_t devAddr, uint8_t regAddr, uint8_t

bitStart, uint8_t length, uint16_t data);

static bool writeByte(uint8_t devAddr, uint8_t regAddr, uint8_t

data);

static bool writeWord(uint8_t devAddr, uint8_t regAddr, uint16_t

data);

static bool writeBytes(uint8_t devAddr, uint8_t regAddr, uint8_t

length, uint8_t *data);

static bool writeWords(uint8_t devAddr, uint8_t regAddr, uint8_t

length, uint16_t *data);

static uint16_t readTimeout;

};

#if I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_FASTWIRE

//////////////////////

// FastWire 0.2

// This is a library to help faster programs to read I2C devices.

// Copyright(C) 2011

// Francesco Ferrara

//////////////////////

/* Master */

#define TW_START 0x08

#define TW_REP_START 0x10

/* Master Transmitter */

#define TW_MT_SLA_ACK 0x18

#define TW_MT_SLA_NACK 0x20

#define TW_MT_DATA_ACK 0x28

#define TW_MT_DATA_NACK 0x30

#define TW_MT_ARB_LOST 0x38

/* Master Receiver */

#define TW_MR_ARB_LOST 0x38

#define TW_MR_SLA_ACK 0x40

#define TW_MR_SLA_NACK 0x48

#define TW_MR_DATA_ACK 0x50

#define TW_MR_DATA_NACK 0x58

#define TW_OK 0

#define TW_ERROR 1

class Fastwire {

private:

static boolean waitInt();

public:

static void setup(int khz, boolean pullup);

static byte write(byte device, byte address, byte value);

Glosario

110

110

static byte readBuf(byte device, byte address, byte *data, byte

num);

};

#endif

#if I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_NBWIRE

// NBWire implementation based heavily on code by Gene Knight

<[email protected]>

// Originally posted on the Arduino forum at

http://arduino.cc/forum/index.php/topic,70705.0.html

// Originally offered to the i2cdevlib project at

http://arduino.cc/forum/index.php/topic,68210.30.html

#define NBWIRE_BUFFER_LENGTH 32

class TwoWire {

private:

static uint8_t rxBuffer[];

static uint8_t rxBufferIndex;

static uint8_t rxBufferLength;

static uint8_t txAddress;

static uint8_t txBuffer[];

static uint8_t txBufferIndex;

static uint8_t txBufferLength;

// static uint8_t transmitting;

static void (*user_onRequest)(void);

static void (*user_onReceive)(int);

static void onRequestService(void);

static void onReceiveService(uint8_t*, int);

public:

TwoWire();

void begin();

void begin(uint8_t);

void begin(int);

void beginTransmission(uint8_t);

//void beginTransmission(int);

uint8_t endTransmission(uint16_t timeout=0);

void nbendTransmission(void (*function)(int)) ;

uint8_t requestFrom(uint8_t, int, uint16_t timeout=0);

//uint8_t requestFrom(int, int);

void nbrequestFrom(uint8_t, int, void (*function)(int));

void send(uint8_t);

void send(uint8_t*, uint8_t);

//void send(int);

void send(char*);

uint8_t available(void);

uint8_t receive(void);

void onReceive(void (*)(int));

void onRequest(void (*)(void));

};

#define TWI_READY 0

#define TWI_MRX 1

#define TWI_MTX 2

#define TWI_SRX 3

#define TWI_STX 4

#define TW_WRITE 0

#define TW_READ 1

111




#define CPU_FREQ 16000000L

#define TWI_FREQ 100000L

#define TWI_BUFFER_LENGTH 32

/* TWI Status is in TWSR, in the top 5 bits: TWS7 - TWS3 */

#define TW_STATUS_MASK

(_BV(TWS7)|_BV(TWS6)|_BV(TWS5)|_BV(TWS4)|_BV(TWS3))

#define TW_STATUS (TWSR & TW_STATUS_MASK)

#define TW_START 0x08

#define TW_REP_START 0x10

#define TW_MT_SLA_ACK 0x18


#define TW_MT_DATA_ACK 0x28


#define TW_MT_ARB_LOST 0x38

#define TW_MR_ARB_LOST 0x38

#define TW_MR_SLA_ACK 0x40

#define TW_MR_SLA_NACK 0x48

#define TW_MR_DATA_ACK 0x50

#define TW_MR_DATA_NACK 0x58

#define TW_ST_SLA_ACK 0xA8

#define TW_ST_ARB_LOST_SLA_ACK 0xB0

#define TW_ST_DATA_ACK 0xB8

#define TW_ST_DATA_NACK 0xC0

#define TW_ST_LAST_DATA 0xC8

#define TW_SR_SLA_ACK 0x60

#define TW_SR_ARB_LOST_SLA_ACK 0x68

#define TW_SR_GCALL_ACK 0x70

#define TW_SR_ARB_LOST_GCALL_ACK 0x78

#define TW_SR_DATA_ACK 0x80

#define TW_SR_DATA_NACK 0x88

#define TW_SR_GCALL_DATA_ACK 0x90

#define TW_SR_GCALL_DATA_NACK 0x98

#define TW_SR_STOP 0xA0

#define TW_NO_INFO 0xF8

#define TW_BUS_ERROR 0x00

//#define _MMIO_BYTE(mem_addr) (*(volatile uint8_t *)(mem_addr))

//#define _SFR_BYTE(sfr) _MMIO_BYTE(_SFR_ADDR(sfr))

#ifndef sbi // set bit

#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))

#endif // sbi

#ifndef cbi // clear bit

#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))

#endif // cbi

extern TwoWire Wire;

#endif // I2CDEV_IMPLEMENTATION == I2CDEV_BUILTIN_NBWIRE

#endif /* _I2CDEV_H_ */

Librería GPS

Glosario

112

112

/***********************************

This is the Adafruit GPS library - the ultimate GPS library

for the ultimate GPS module!

Tested and works great with the Adafruit Ultimate GPS module

using MTK33x9 chipset

------> http://www.adafruit.com/products/746

Pick one up today at the Adafruit electronics shop

and help support open source hardware & software! -ada

Adafruit invests time and resources providing this open source code,

please support Adafruit and open-source hardware by purchasing

products from Adafruit!

Written by Limor Fried/Ladyada for Adafruit Industries.

BSD license, check license.txt for more information

All text above must be included in any redistribution

****************************************/

// Fllybob added lines 34,35 and 40,41 to add 100mHz logging capability

#ifndef _ADAFRUIT_GPS_H

#define _ADAFRUIT_GPS_H

#ifdef __AVR__

#if ARDUINO >= 100

#include <SoftwareSerial.h>

#else

#include <NewSoftSerial.h>

#endif

#endif

// different commands to set the update rate from once a second (1 Hz) to 10

times a second (10Hz)

// Note that these only control the rate at which the position is echoed, to

actually speed up the

// position fix you must also send one of the position fix rate commands

below too.

#define PMTK_SET_NMEA_UPDATE_100_MILLIHERTZ "$PMTK220,10000*2F" // Once

every 10 seconds, 100 millihertz.

#define PMTK_SET_NMEA_UPDATE_200_MILLIHERTZ "$PMTK220,5000*1B" // Once

every 5 seconds, 200 millihertz.

#define PMTK_SET_NMEA_UPDATE_1HZ "$PMTK220,1000*1F"

#define PMTK_SET_NMEA_UPDATE_5HZ "$PMTK220,200*2C"

#define PMTK_SET_NMEA_UPDATE_10HZ "$PMTK220,100*2F"

// Position fix update rate commands.

#define PMTK_API_SET_FIX_CTL_100_MILLIHERTZ "$PMTK300,10000,0,0,0,0*2C" //

Once every 10 seconds, 100 millihertz.

#define PMTK_API_SET_FIX_CTL_200_MILLIHERTZ "$PMTK300,5000,0,0,0,0*18" //

Once every 5 seconds, 200 millihertz.

#define PMTK_API_SET_FIX_CTL_1HZ "$PMTK300,1000,0,0,0,0*1C"

#define PMTK_API_SET_FIX_CTL_5HZ "$PMTK300,200,0,0,0,0*2F"

// Can't fix position faster than 5 times a second!

#define PMTK_SET_BAUD_57600 "$PMTK251,57600*2C"

#define PMTK_SET_BAUD_9600 "$PMTK251,9600*17"

// turn on only the second sentence (GPRMC)

#define PMTK_SET_NMEA_OUTPUT_RMCONLY

"$PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29"

// turn on GPRMC and GGA

113


#define PMTK_SET_NMEA_OUTPUT_RMCGGA

"$PMTK314,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28"

// turn on ALL THE DATA

#define PMTK_SET_NMEA_OUTPUT_ALLDATA

"$PMTK314,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0*28"

// turn off output

#define PMTK_SET_NMEA_OUTPUT_OFF

"$PMTK314,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28"

// to generate your own sentences, check out the MTK command datasheet and

use a checksum calculator

// such as the awesome http://www.hhhh.org/wiml/proj/nmeaxor.html

#define PMTK_LOCUS_STARTLOG "$PMTK185,0*22"

#define PMTK_LOCUS_STOPLOG "$PMTK185,1*23"

#define PMTK_LOCUS_STARTSTOPACK "$PMTK001,185,3*3C"

#define PMTK_LOCUS_QUERY_STATUS "$PMTK183*38"

#define PMTK_LOCUS_ERASE_FLASH "$PMTK184,1*22"

#define LOCUS_OVERLAP 0

#define LOCUS_FULLSTOP 1

#define PMTK_ENABLE_SBAS "$PMTK313,1*2E"

#define PMTK_ENABLE_WAAS "$PMTK301,2*2E"

// standby command & boot successful message

#define PMTK_STANDBY "$PMTK161,0*28"

#define PMTK_STANDBY_SUCCESS "$PMTK001,161,3*36" // Not needed currently

#define PMTK_AWAKE "$PMTK010,002*2D"

// ask for the release and version

#define PMTK_Q_RELEASE "$PMTK605*31"

// request for updates on antenna status

#define PGCMD_ANTENNA "$PGCMD,33,1*6C"

#define PGCMD_NOANTENNA "$PGCMD,33,0*6D"

// how long to wait when we're looking for a response

#define MAXWAITSENTENCE 5

#if ARDUINO >= 100

#include "Arduino.h"

#if defined (__AVR__) && !defined(__AVR_ATmega32U4__)

#include "SoftwareSerial.h"

#endif

#else

#include "WProgram.h"

#include "NewSoftSerial.h"

#endif

class Adafruit_GPS {

public:

void begin(uint16_t baud);

#ifdef __AVR__

#if ARDUINO >= 100

Adafruit_GPS(SoftwareSerial *ser); // Constructor when using

SoftwareSerial

#else

Adafruit_GPS(NewSoftSerial *ser); // Constructor when using

NewSoftSerial

#endif

#endif

Glosario

114

114

Adafruit_GPS(HardwareSerial *ser); // Constructor when using HardwareSerial

char *lastNMEA(void);

boolean newNMEAreceived();

void common_init(void);

void sendCommand(const char *);

void pause(boolean b);

boolean parseNMEA(char *response);

uint8_t parseHex(char c);

char read(void);

boolean parse(char *);

void interruptReads(boolean r);

boolean wakeup(void);

boolean standby(void);

uint8_t hour, minute, seconds, year, month, day;

uint16_t milliseconds;

// Floating point latitude and longitude value in degrees.

float latitude, longitude;

// Fixed point latitude and longitude value with degrees stored in units of

1/100000 degrees,

// and minutes stored in units of 1/100000 degrees. See pull #13 for more

details:

// https://github.com/adafruit/Adafruit-GPS-Library/pull/13

int32_t latitude_fixed, longitude_fixed;

float latitudeDegrees, longitudeDegrees;

float geoidheight, altitude;

float speed, angle, magvariation, HDOP;

char lat, lon, mag;

boolean fix;

uint8_t fixquality, satellites;

boolean waitForSentence(const char *wait, uint8_t max = MAXWAITSENTENCE);

boolean LOCUS_StartLogger(void);

boolean LOCUS_StopLogger(void);

boolean LOCUS_ReadStatus(void);

uint16_t LOCUS_serial, LOCUS_records;

uint8_t LOCUS_type, LOCUS_mode, LOCUS_config, LOCUS_interval,

LOCUS_distance, LOCUS_speed, LOCUS_status, LOCUS_percent;

private:

boolean paused;

uint8_t parseResponse(char *response);

#ifdef __AVR__

#if ARDUINO >= 100

SoftwareSerial *gpsSwSerial;

#else

NewSoftSerial *gpsSwSerial;

#endif

#endif

HardwareSerial *gpsHwSerial;

};

#endif

115


Anexo B: Esquemáticos


116

116

117



118

118

119



120

120

121


Sistema de seguridad para personas dependientes

Documents

Transcript of Sistema de seguridad para personas dependientes