Industriales



Descargar 0.72 Mb.
Página5/7
Fecha de conversión14.01.2019
Tamaño0.72 Mb.
1   2   3   4   5   6   7

Capítulo 3




3. MARCO APLICATIVO

3.1. Diseño del sistema


Se procede a enumerar las distintas partes hardware y software del sistema en etapas separas, se tomó la decisión de realizar por fases para poder independizar en partes fuentes y partes que están diseñadas para cumplir funciones diferentes unas que otras lo que al diferenciarlo en secciones pude ayudar a la comprensión del funcionamiento del sistema.

Figura 31 Diagrama de bloques del abstracto del sistema completo



Fuente: Autor

3.1.1. Estructura Base


Para métodos didácticos y demostraciones se va a conseguir una estructura o base rígida y abierta de tal manera que muestre o tenga a la vista la electrónica y demás.

3.1.2. Etapa de control


En esta etapa debe contar con los microcontroladores o sub etapas, las cuales se encarguen de tomar decisiones.

Un micro controlador ARM STM32F3 cuenta con las características más que suficientes para poder llevar a cabo la función de controlar el sistema, ya que las lecturas de las conversiones de analógico al digital lo hace en 12 bits lo cual mucho es mejor a lo ofrecido por otros micro controladores como AVR o PIC, hay que mencionar que existen micro controladores STM32 con conversores denominados analógico a digital SIGMA-DELTA que tiene las caracterizas de ofrecer ganancias en sus entradas y una resolución de hasta 16 bits lo que aumentaría la precisión en las lecturas, un recurso muy útil para hacer lecturas de temperaturas con sensores industriales con grandes rangos de variación y la medición de peso las cuales usan sensores con variaciones muy pequeñas que un micro controlador normal puede no percibir, por esta razón se procedió a optar el uso de un sensor de temperatura LM35 que tiene un rango y ganancia adecuados y más que suficiente para le resolución de 12 bits de los STM32.

Para interactuar con el módulo SIM908 se inclinó por la opción de usar un micro controlador Atmega328 que se encargará de comunicarse por UART ya que es el protocolo el cual entiende el módulo y que se lo ha determinado como persistente ya que está a la espera o se detiene hasta que el módulo le responda ya que es una situación que se ve un poco obligada puesto que el sensor GPS tiene una latencia bastante considerable para recolectar la ubicación de los satélites disponibles la cual no es manejable por el micro controlador STM32.
A más de las partes antes mencionadas tiene conectores para enlazar con las demás etapas respectivamente.

Figura 32 Diagrama de bloques de etapa de control



Fuente: Autor

3.1.3. Etapa de adquisición de datos


Aquí se conectará una alimentación de 3,3 voltios los cuales con más que suficientes para la medición de los sensores lo cual podría representar una pequeña ventaja ya que no se necesitaría un proceso de acondicionamiento de señal para introducir esta información al micro controlador ya que funciona a 3,3 voltios.

Por la necesidad de que los sensores deben estar en el campo de medida y no cerca del campo de control se pondrá conectores para sacarlos a los sensores y conectores para el micro controlador.



Figura 33 Diagrama de bloques de etapa de adquisición de datos



Fuente: Autor

3.1.4. Etapa de potencia


Por la necesidad del manejo de cantidades considerables de corriente debe estar aislado el circuito por acopladores y por ello se procederá a usar módulos de relés los culés tienen la opción de hacer un doble acoplamiento ya que tiene opto acopladores y acopladores mecánicos, al usar estos módulos no hay necesidad de usar acopladores de señal de salida para amplificarlo ya que cuenta con transistores encargados de esta función para los relés mecánicos.

Figura 34 Diagrama de bloques de etapa de potencia



Fuente: Autor

3.2. Selección del Sistema Embebido


En este punto se puso en comparación dos tarjetas como son las Raspberry Pi 2 modelo B y la Wandboard Dual iMX6.

Tabla 31 Tabla comparativa entre Raspberry Pi 2 y Wandboard iMX6 Dual



 

Raspberry Pi 2

Wandboard iMX6 Dual

Procesador

ARM CorteX-A7 QUAD de 0,7 GHz

ARM CorteX-A9 DUAL de 1.2 GHz

Memoria

1 GB

1 GB

Gráficos

250 MHz

320MHz

HDMI

1

1

C. Cámara

1

1

Micro SD

1

2

USB

4

2

Ethernet

1

1

Wifi

0

1

Bluetooth

0

1

P. Serial DB9

0

1

Audio

1

1

Costo

85

200

Realizado por: Christian Salazar

Fuentes: WANDBOARD, Año Desconocido, Datasheet y Adafruit, 2015, DatasheetFebreo 015.

En cuanto a características generales de las dos tarjetas podemos notar que Wandboard tiene el doble de características mejores que la Raspberry Pi 2 lo que podría decir a breves rasgos que sería mejor, pero viendo a más profundidad cada una de ellas tenemos:

El procesador de Raspberry Pi 2 es 0.4 Ghz mayor que el anterior lo cual lo hace muy bueno ya que procesaremos grandes cantidades de información.

En cuanto a gráficos la Wandboard parece ser la más adecuada, pero es irrelevante para la selección en esta aplicación ya que no es necesario mostrar gráficos que requieran mucho procesamiento de este tipo porque además se pude dejar corriendo la aplicación solo en modo consola.

En las tarjetas de memoria micro SD y los Puertos USB podría juntarse ambos eliminando una ranura micro SD en cada tarjeta ya que es necesaria para la instalación del Sistema Operativo dejando al resto para periféricos y almacenamiento compensando así la Raspberry al tener más puertos USB.

Wifi es una ventaja muy grande en la Wandboard lo cual lo hace sin duda un dato relevante por sus diversas ventajas así mismo como las de Bluetooth.

Por otro lado, el puerto serial no es muy relevante en esta aplicación ya que con el USART que tiene las Raspberry es suficiente a menos que se necesite más control sobre el protocolo.

En cuanto a costo es evidente que Raspberry lleva ventaja por su bajo precio en comparación con la Wandboard.

Para el Raspberry se probó con el sistema Operativo Raspbian aconsejado por Raspberry Pi Foundation que permite instalar y probar sin ninguna complicación el software necesario como lo es OpenCV completo y corriendo ejemplos sin ningún problema.

Lo que por el contrario Wandboard se probó con Ubuntu 15 para Wandboard que a pesar de estar sustentado por la organización Canonical presento problemas para la instalación del software antes mencionado.

Entonces por la relevancia del procesamiento, numero de puertos USB, precio y las ventajas y respaldo que tiene Raspbian se optó por usar Raspberry tomando la opción de adquirir los módulos individuales de wifi y Bluetooth que encarece la tarjeta dejando a un costo aproximado de la Raspberry de la mitad que la Wandboard.

3.3. Comunicaciones del sistema

3.3.1. Comunicación STM32F3-RASPBERRY


Los métodos disponibles para comunicar las tarjetas ST32 y la Raspberry son USART, SPI e I2C.

El micro controlador no tiene mayores problemas al usar estos protocolos, ya sea por interrupciones, DMA o por sondeo simple, dejando la decisión en cuanto a las posibilidades y opciones mucho más cómodas y viables a implementar en la Raspberry.

En cuanto a UART tiene mayor velocidad de transmisión disponible, mayor distancia, menor número de cables.

SPI e I2C al ser protocolos destinados a la comunicación específicamente con periféricos extras y no entre sistemas como es este caso podrían ser un dato relevante para descartarlos.

La facilidad del uso de los puertos seriales en los sistemas operativos con la librería apropiada da otro punto a favor a UART.

En las pruebas y desarrollo de la interacción de OpenCV con un micro controlador se lo hizo con lenguaje C++, teniendo en cuenta que SPI e I2C cuenta con librerías escritas en lenguaje Python al igual que el periférico UART se puede optar por usar una librería general para manejar puertos seriales desde OpenCV.

Dejando como resultado que la opción más viable es usar el UART

Figura 35 Comunicación Sistema Embebido - Micro controlador



Fuente: Autor

3.3.2. Comunicación STM32F3-Módulo Bluetooth


Por defecto del diseño del módulo HC 05 que se pretende usar es posible usar el protocolo de comunicación serial que es el único disponible.

3.3.3. Comunicación ATMEGA328p-Modulo GSM


Al igual que el caso anterior el módulo SIM908 tiene disponible el uso del protocolo UART para interactuar con el atmega328.

3.4. Etapa de potencia y alimentación del sistema


Para un caso ya aplicado el uso de la batería disponible en el automóvil es suficiente para el sistema con las protecciones suficientes y mientras que para demostración se puede usar fuentes diferentes e independientes unos de otros en algunos casos.

3.5. Interfaz de control con Android


Para interactuar con el sistema podríamos usar un Smartphone con su respectiva aplicación lo cual nos puede obviar del uso de controles remotos extras, teclados extras para ingresar claves, receptor de coordenadas de ubicación de GPS, aplicación disponible para la localización.

Figura 36 Interfaz de control con Android



Fuente: Autor

La aplicación fue desarrollada en APP Inventor, es una aplicación personalizada para el sistema ya que se usa la MAC ADDRESS del módulo Bluetooth en el código fuente para conectarse al mismo desde el Smartphone, teniendo así botón en la parte superior para conectar al sistema, un botón en la parte inferior para salir de la aplicación, un botón de apagado de las luces o faros opcional si no se desea entrar en el modo seguro en el cual apaga las estas, tiene la parte de geo localización un text box que se llena al recibir las coordenadas por SMS desde el sistema y que al presionar el botos de buscar el mapa nos dará la ubicación aproximada del módulo GPS, así también un botón extra para ver mi localización y finalmente la parte de la clave de súper usuario que da arranque previo a estar en modo conducción que usa una clave secreta de cuatro dígitos, a continuación se muestra una figura de la apariencia de la aplicación.



Figura 37 Funciones de la aplicación de Android



Fuente: Autor

3.6. Reconocimiento facial

3.6.1. Selección de cámara


Para la aplicación que se pretende llevar a cabo la cámara es un dispositivo muy importante e imprescindible, por lo que se ha seleccionado tres tipos de fuentes de imágenes para ser analizadas en el Raspberry, estos tres tipos pueden ser conectados a la Raspberry y se pone a consideración las siguientes características para poder seleccionar la más se adapte al sistema.

Tabla 32 Tabla comparativa entre los tres tipos de cámara






Cámara Ip con Smartphone

Cámara web USB

Cámara Pi

Resolución

3 Mp

320x240(0,76Mp)

5 Mp

Conexión

Wifi

USB

SCCB

Streaming

Lento

Rápido

Rápido

Flash

No

Si

No

Auto Focus

Si

No

Si

Costo

Incluye

20

65










Realizado por: Christian Salazar

Fuentes: Autor

En las pruebas que se pudo realizar ayuda para descartar la posibilidad del uso de la cámara Ip simulada con el Smartphone es que tiene una latencia muy grande en llegar a parte de procesamiento lo que podría dificultar en gran dimensión el sistema llevando esta latencia a otros lados y en segunda instancia la conexión seria suplida con el uso de un módulo wifi en el Raspberry para poder transmitir haciendo al Smartphone o al Raspberry que trabaje como router de datos.

En segundo plano tenemos las dos últimas posibilidades que en cuanto a resolución es suficiente con la más baja ofrecida ya que la aplicación no requiere e incluso se puede requerir en la disminución del tamaño por lo que estaría sobredimensionado los 5 Mp de la cámara Pi, la conexión de USB no se ve afectada en su velocidad por la webcam puesto que contamos con los puertos suficientes y uno de ellos puede ser destinado para este propósito, mientras que la conexión SCCB puede ser un poco dificultosa al llevarlo a la práctica ya que para transmitir la información usa cableado súper sensible, de difícil manipulación y de dificultoso acceso al cable flexible como a la misma cámara Pi.

Al tener un juego de diodos led que pueden ayudar a l autenticación en la noche lo hace aún más viable su uso.

Y por último la relación beneficio costo determinan finalmente que el uso de una webcam USB es suficiente para la aplicación y hay que tomar en cuenta que la tecnología está muy avanzada y que por unos dólares más se puede tener una de aun mayor resolución, se tomó la menor resolución ya que es más que suficiente en este caso.

3.6.2. Autenticación en la noche


Para la obtención de imágenes por la noche se tienen varias opciones como son el uso de cámaras estrictamente nocturnas, pero de grandes costos que por el análisis anterior queda descartado.

gafas vision nocturna

Figura 38 Cámara de visión nocturna



Fuente: http://www.electronica-basica.com/images/gafas-vision-nocturna.jpg

Una segunda opción podría ser el uso de diodos led infrarrojos con un Angulo de apertura de luz muy amplio que hacen difícil conseguirlos, puesto que normalmente se encuentran son los diodos led infrarrojos con un Angulo muy cerrado ya que para las aplicaciones que se han llevado a cabo han sido necesarios como hacer un emisor receptor.



http://1.bp.blogspot.com/_jdvul0mj1so/s_7vf-ylwki/aaaaaaaabfs/ipsmgafwhz0/s1600/comprobando+led+emisor+de+infrarrojos.png

Figura 39 Led infrarrojo



Fuente: http://1.bp.blogspot.com/_jDvul0Mj1So/S_7vf-ylWkI/AAAAAAAABfs/IPsmgafWhZ0/s1600/Comprobando+LED+emisor+de+infrarrojos.png

Finalmente tenemos el uso de los diodos Led blancos que a más de contar con un juego incluido en la misma cámara sería necesario hacer un propio juego con la cantidad de luz suficiente ya que el juego de la cámara podría no ser suficiente y debido a que se está limitando a la energía que es capaz de suministrar el Raspberry Pi por el puerto USB.



http://www.nauticaygps.com.ar/tecnologia/estrobo/images/modulo_led2.jpg

Figura 310 Flash de led



Fuente: http://www.nauticaygps.com.ar/Tecnologia/estrobo/images/modulo_led2.jpg

3.6.3. Filtrado de la imagen

3.6.3.1. Reducción de imagen

Al aplicar este tipo de filtro lo que se pretende es reducir el tamaño de la imagen en cuanto al número de pixeles que la conforman teniendo así una matriz de trabajo normalizada a un tamaño adecuado.

Por ello se ha determinado REDUCED_SIZE a 480 para que sin importar el tamaño de la entrada se tenga un mismo tamaño para que no cambien los valores de las coordenadas de los ojos.


3.6.3.2. Corte

Para poder aplicar en el reconocimiento facial es necesario hacer un recorte de la imagen ya reducida, para ello lo que se hace es identificar los ojos para hacer el recorte de los mismos junto con partes relevantes del rostro, hay que destacar que no toda la imagen se usa para el reconocimiento. A paso seguido del recorte se la alinea de forma horizontal.

Para esto se puede hacer de varias formas y una de ellas es la siguiente:



Figura 311 Funciones en C++ para filtro de imágenes



Fuente: Autor

Es una función que por entrada tiene coordenadas previamente definidas y devuelve sub matriz recortada


3.6.3.3. Escala de Grises

Es necesario poner en binario la imagen (tener 1 y 0 en la matriz de la imagen), para ello se aplica un filtro para convertir la imagen en RGB a escala de grises reduciendo así en este punto gran cantidad de información que no es relevante.

3.6.4. Selección de algoritmo para reconocimiento facial


El algoritmo que está corriendo tiene un gran respaldo para su utilización en la parte de análisis estadístico de este trabajo, entrando en detalles del programa principal tiene una función que obtiene las coordenadas de los ojos y el rostro, devuelve true si las encuentra, función para alinear y recortar el rostro por la zona de interés, otra para resaltar y dibujar marcas del rostro encontrados, una función de inicialización que se encarga de abrir los algoritmos disponibles para el reconocimiento de ojos, rostros y reconocimiento facial, para en el bucle principal main hacer la respectiva apertura del puerto serial, filtros necesarios y llamadas a las funciones antes mencionadas junto con otra embarcándolas en un menú que cuenta con las opciones de entrenar el programa para luego dejarlo en modo reconocimiento y a la espera de una solicitud de respuesta por UART si hay compatibilidad de reconocimiento facial con el uso del algoritmo LBPHFaceRecognizer, librería disponible en el directorio de OpenCV.

3.6.5. Breve descripción del algoritmo para reconocimiento facial


El algoritmo tiene una función que obtiene las coordenadas de los ojos y el rostro, devuelve true si las encuentra, función para alinear y recortar el rostro por la zona de interés, otra para resaltar y dibujar marcas del rostro encontrados, una función de inicialización que se encarga de abrir los algoritmos disponibles para el reconocimiento de ojos, rostros y reconocimiento facial, para en el bucle principal main hacer la respectiva apertura del puerto serial, filtros necesarios y llamadas a las funciones antes mencionadas junto con otra embarcándolas en un menú que cuenta con las opciones de entrenar el programa para luego dejarlo en modo reconocimiento y a al espera de una solicitud de respuesta por UART si hay compatibilidad de reconocimiento facial con el uso del algoritmo LBPHFaceRecognizer, librería disponible en el directorio de OpenCV.

Figura 312 Reconocimiento facial



Fuente: Autor

3.7. Método de programación del microcontrolador ARM


Existen tres métodos o tipos de programación más conocidos como lo son por sondeo, por interrupciones y por DMA.

3.7.1. Programación por sondeo


Esta consiste en la programación de instrucciones de tal forma que la secuencia se la haga en un orden. Desde la primera hasta la última, método que complica en ciertas aplicaciones.

3.7.2. Programación por interrupciones


Es una herramienta muy potente a la hora de programar ya que el micro controlador permite interrumpir la programación anterior para atender una sub rutina generada por una interrupción interna o externa. Teniendo la característica de que después de atender la interrupción puede regresar a donde se dejó el programa principal para continuar con su ejecución.

En ARM tiene una característica muy particular de un sistema Operativo que es el manejo de prioridades de las interrupciones el cual está disponible en un vector llamado NVIC.


3.7.3. Programación por DMA


Otro recurso muy interesante es el manejo de los periféricos de DMA que quiere decir acceso directo a memoria, la característica principal de este periférico disponible es que puede hacer transferencias directamente entre un periférico como USART, ADC, etc a memoria o viceversa, a más de poder hacerlo de memoria a memoria sin que el programa principal sea interrumpido, se la puede combinar con interrupciones.

Para esta aplicación se ha incurrido en los tres métodos para optimizar los recursos que ofrece el micro controlador aplicando así:



ADC con DMA

HAL_ADC_Start_DMA(&hadc1,(uint32_t*)&valores,10);

Dos UART por interrupciones

if(HAL_UART_GetState(&huart4) == HAL_UART_STATE_READY)

{

HAL_UART_Receive_IT(&huart4, &RxByte, 1);

}

if(HAL_UART_GetState(&huart1) == HAL_UART_STATE_READY)

{

HAL_UART_Receive_IT(&huart1, &RxByte, 1);

}

while (1)

{}

3.8. Control del sistema


El sistema tiene varias características similares a las convencionales que encontramos en los sistemas de seguridad comunes y corrientes, cuenta para ponerlo en dos modos: modo seguro y modo conducción, en cada uno de estos modos hay procesos o algoritmos que se pueden ejecutar solo en ese modo y así mismo otros que son de forma general en cualquier instancia como la geo localización, al arrancar el sistema se deberá seleccionar uno de los modos ya que de no ser así solo estará ejecutando los algoritmos generales, lo cual se lo hará con la aplicación.

Figura 313 Diagrama de bloques secuencial de procesos



Fuente: Autor

3.8.1. Modo seguro


Las características principales de este modo son las de estar continuamente a la espera de alguna violación del sistema para proceder a alarmar con una sirena y con una llamada por la red GSM, además de hacer un aviso con la alarma si se acercan mucho al auto por la parte en la que se encuentre localizado el sensor.

3.8.2. Modo conducción


En este modo tenemos las opciones de protocolo a seguir para poder usar el automóvil que son dos: la de autenticación por reconocimiento facial y autenticación por clave de súper usuario, estos serán los que permitirán dar arranque para encenderlo, cuenta con sensor de luz para poder determinar si es necesario adecuar el enfoque de la cámara y para el control de las luces o faros para conducir en la noche, además de incluir un sensor de alcohol que podría quitar de igual manera el arranque de acuerdo al nivel de alcohol en el ambiente pero es poco aplicable, cuenta con las opciones hacer mando sobre los motores de seguros eléctricos, hace un control automático de la temperatura ambiente.

3.9. Construcción del sistema


Una vez que se ha determinado y tenido una idea más clara se procedió a diseñar el sistema completo a partir de un diagrama general representado en la siguiente figura.

Figura 314 Diagrama de bloques detallado del sistema



Fuente: Autor

3.9.1. Estructura base


Se tomó la decisión de usar unas planchas de aluminio acopladas con estructuras del mismo material para separarlo una cierta distancia por la parte inferior a manera de patas.

3.9.2. Etapa de control


Esta etapa está conformada principalmente por el micro controlador STM32F303VCT de arquitectura ARM incrustado en la tarjeta de desarrollo Discovery STM32F3 que es el encargado de la toma de decisiones programadas en los algoritmos insertados en su memoria de acuerdo a las condiciones y lecturas de los sensores que están conectados a sus respectivos pines, por el diseño de la tarjeta se procedió a realizar una placa adaptativa en el software Proteus que en la Figura 15-3 se puede apreciar, teniendo una alimentación principal de 7.5 Voltios a 2.5 Amperios y sobre la cual va montado la tarjeta Discovery, los módulos de comunicación Bluetooth HC-05 y USB a Serial CP2102, el controlador Atmega328p encargado de gobernar el módulo SIM908 e interactuar con la tarjeta Discovery, reguladores de voltaje a 5V y 3.3V y los conectores adecuados para conectar con las demás etapas.

c:\users\marce\pictures\union tesis proteus.png

Figura 315 Diagrama electrónico de la etapa de control



Fuente: Autor

Figura 316 PCB del diagrama electrónico de la etapa de control



Fuente: Autor

Figura 317 Imagen 3D del PCB del diagrama de electrónico de la etapa de control



Fuente: Autor

3.9.3. Etapa de adquisición de datos


Esta etapa cuenta con dos partes, la primera que es una placa que suministra la energía a los sensores que se puede observar en la Figura 18-3 y recoge las señales de los mismos para enviarlos al micro controlador por conexión directa por medio de cables y la segunda que son los sensores en sí, montados en placas individuales con sus conectores a manera de módulos de sensores, de igual manera el diseño de las placas fue en Proteus, además que en esta etapa entra el sistema embebido que está actuando como sensor que da la información al micro controlador.

Figura 318 Diagrama electrónico de la etapa de adquisición de datos



Fuente: Autor

Figura 319 PCB del diagrama electrónico de la etapa de adquisición de datos



Fuente: Autor

3.9.4. Etapa de potencia


La etapa de potencia está conformada por los dos módulos de relés que se encargaran de suministrar energía a los actuadores cuando el micro controlador así se lo ordene, además que también contamos con un módulo Sabertooth antes mencionado para manejar la energía de dos actuadores, otra parte del sistema que podría estar relacionado con la potencia seria las respectivas conexiones a la red de energía eléctrica.

3.10. OpenCV sobre Raspberry PI 2 con Raspbian


Se optó por usar la versión de OpenCV 4.9 completa para instalarlo en el Raspberry para lo cual fue necesario usar una memoria de 16 GB.

Antes de instalar cualquier cosa se debe hacer un update y un upgrade del sistema operativo para que actualice las cabeceras de donde procederán las dependencias necesarias.

Las dependencias instaladas para la aplicación fueron:


  • libopencv-dev

  • cmake

  • pkg-config

  • python-numpy

  • libdc1394-22-dev

  • libpng12-dev

  • libjasper-dev

  • libavformat-dev

  • libxine-dev

  • libgstreamer-plugins-base0.10-dev

  • libtbb-dev

  • libfaac-dev

  • libopencore-amrnb-dev

  • libtheora-dev

  • libxvidcore-dev

  • build-essential

  • libgtk2.0-dev

  • python-dev

  • libdc1394-22

  • libjpeg-dev

  • libtiff4-dev

  • libavcodec-dev

  • libswscale-dev

  • libgstreamer0.10-dev

  • libv4l-dev

  • libqt4-dev

  • libmp3lame-dev

  • libopencore-amrwb-dev

  • libvorbis-dev

  • v4l-utils

Una vez instalado y descargado OpenCV4.9 se lo descomprime.

Dentro de la carpeta creada con la descompresión se crea una carpeta necesaria llamada built para compilar.

Luego se compila con cmake y make.

Dejando con este breve resumen listo a OpenCV para programar o correr ejemplos.


3.11. Funcionamiento y algoritmos del sistema


La idea principal del Proyecto es reducir la incidencia de atracos exitosos por parte de anti sociales reduciendo así los índices e indicadores delincuenciales de este tipo en nuestro país.

La Tarjeta Discovery STM32F3 se encarga de tomar decisiones, ver el estado de las puertas, capturar valores analógicos de la distancia, temperatura y luminosidad, avisar al Atmega 328p para que comunique las anomalías por GSM con el SIM908, sonar sirenas, encender flash de led, activar enfriadores y calentadores, recibir órdenes por Bluetooth y pulsadores. Además, el Atmega 328p tiene la capacidad de responder por SMS a la aplicación Android con la localización por GPS obtenida con el SIM908, esto se logra programando los algoritmos necesarios usando el lenguaje de programación C de forma estructurada.

La Raspberry Pi 2 se comparó con un mini computador Wandboard IMX6 Dual y por los requerimientos del software OpenCV, es la encargada del reconocimiento facial sobre el Sistema Operativo Raspbian, en OpenCV encontramos las librerías EigenFaces, FisherFaces y LBPH para el reconocimiento facial, que sirven para calcular índices de coincidencia entre un rostro y otro, de tal forma que pueda autorizar el arranque del vehículo.

El proceso para la toma de decisiones del sistema en el vehículo está dado por:



  1. La aplicación Android cuenta con dos botones virtuales debidamente identificados para la interacción del usuario y del sistema, permitiendo con ellos enviar caracteres a la tarjeta STM32F3 la cual decidirá abrir o cerrar seguros, poner o quitar alarma. Otro botón permite apagar luces, tiene disponible un text box para Password propio de aplicaciones Android hace autenticación con clave de súper usuario que también informa si hay coincidencia de clave para casos de emergencia y permitir el arranque del vehículo por un cierto tiempo. La aplicación también receptará la localización por SMS que llegue al dispositivo mientras está ejecutando la aplicación en primer plano, que con acceso a internet se podrá vincular y ubicarla en GoogleMaps.

  2. Al quitar la alarma, abrir los seguros y una vez dentro del vehículo se puede solicitar autenticación por reconocimiento facial mediante un pulsador en la tarjeta STM32F3 la cual por UART ordena a la Raspberry que capture rostros y analice si hay o no coincidencia para responder con un carácter si hay autenticación superada o no, a más de ello la tarjeta STM32F3 enciende un flash led si hace falta luz si se lo indica el sensor LDR.

  3. Cuando esta sin alarma y listo el vehículo para conducir se puede hacer el control de temperatura, haciendo un control ON/OFF. En el caso que el vehículo ya se ha puesto la alarma la tarjeta STM32F3 acciona la alarma si se fuerza a abrir los pulsadores en las puertas, también ordena al Atmega 328p que haga una llamada perdida con el módulo SIM908, de esta manera podremos enviar un SMS al número del módulo SIM908 con una solicitud de localización para poder ubicarlo. Otra operación en este estado es que, si se reduce la distancia frontal del vehículo, este acciona una advertencia con la sirena.

Los algoritmos del sistema fueron representados en diagramas de flujo que a continuación se muestra.

Figura 320 Algoritmo de la tarjeta STM32F303



Fuente: Autor

Figura 321 Algoritmo del programa de reconocimiento facial



Fuente: Autor

Figura 322 Algoritmo del Atmega328 con SIM908



Fuente: Autor



c:\users\marce\pictures\junta andriod app.png




Figura 323 Algoritmo de la aplicación de Android




Fuente: Autor

1   2   3   4   5   6   7


La base de datos está protegida por derechos de autor ©bazica.org 2016
enviar mensaje

    Página principal