Labview_practica_final - Rodríguez Rivas César Iván

Vista previa del material en texto

Práctica final: Sensor de velocidad
Labview
1st César Iván Rodrı́guez Rivas 221393
Ingenierı́a en nanotecnologı́a, Facultad de ingenierı́a
Universidad Autónoma de Querétaro
crodriguez19@alumnos.uaq.mx
2nd Jesús Antonio Sánchez Moreno 243530
Ingenierı́a en nanotecnologı́a, Facultad de ingenierı́a
Universidad Autónoma de Querétaro
jsanchez110@alumnos.uaq.mx
Resumen—Los instrumentos de seguridad que puedan advertir
a los ciclistas es una necesidad que debe estar al alcance de
todos ellos. Para lograr esto es necesario desarrollar también
instrumentos de validación, es de ahı́ el motivo del proyecto
aquı́ presentado. Implementado sensores ultrasonicos, se logró
crear un sistema que permita registrar velocidades tanto de
vehiculos, como tiempos de reacción. Este proyecto permite
comparar los datos con otros que ya se encuentren diseñados
para implementarse en el campo y comprobar su eficacia.
Index Terms—Speed, Count, Sensors, Cycling, Labview, Ar-
duino, Ultrasound
I. INTRODUCCIÓN
Actualmente la seguridad de los ciclistas es de sumo
interés. De acuerdo con el Censo de Población y Vivienda
2020 del Instituto Nacional de Geografı́a y Estadı́stica
(INEGI), dos de cada 10 hogares en el paı́s cuenta con una
bicicleta. Esto significa que en casi 75 millones de casas
mexicanas alguien emplea una bici como medio de transporte.
Lo preocupante radica en que tan solo en el 2019, activistas
regsitraron que murieron en accidentes viales más del doble
de ciclistas que los reportados en cifras oficiales. Estos
accidentes se repiten en las calles, avenidas y carreteras de
todo el paı́s. Por esa razón es necesario desarrollar otras
medidas de seguridad que le brinden mayor seguridad a los
ciclistas y prevenirlos en caso de imprudencias de conductores
de vehiculos pesados.
II. OBJETIVO
Diseñar y poner en práctica un sistema que permita medir
el tiempo de reacción de usuarios, la velocidad y realizar el
conteo de los vehiculos sensados. Esto con el fin de comparar
las mediciones con otros sistemas.
La práctica experimental se llevará acabo en un ambiente
controlado, de forma que en la distancia cero se encuentre
una bicicleta estatica con un usuario, en el cual se colocará
un botón para medir el tiempo de reacción del usuario al
sentir la presencia de un vehiculo. Se colocarán tres sensores
a las distancias de 10m, 15m y 20m.
Además, se debe llevar un registro en excel de los datos
antes mencionados, junto con la fecha y hora. Se da libertad
al alumno para implementar el sistema siempre y cuando se
cumplan los puntos antes mencionados.
III. MATERIAL
Protoboard
Modulos de ultrasonido HC-SR04
Arduino Uno
Botón push
Cable de cobre de calibre 20
Alambre de cobre
Resistencias de 330 ohms
Laptop
Labview
Tripies
IV. FUNDAMENTACIÓN TEÓRICA
IV-A. Arduino
Arduino es una plataforma de desarrollo que se basa en
una placa electrónica de hardware libre, la cual incorpora
un microcontrolador programable y dispone de varios pines
hembra. Estos últimos permiten establecer conexiones entre
diferentes dispositivos y el microcontrolador de manera
sencilla (Fig.1).
Figura 1. Ejemplo de una tarjeta Arduino Uno.
Las tarjetas Arduino llevan el microcontrolador
ATmega328P, de la marca Atmel. Es un microcontrolador de
alto rendimiento y bajo consumo, por lo que es ampliamente
utilizado en diferentes modelos de la marca. [1]
Su popularidad se debe a que su lenguaje de programación
es sencillo de comprender, su costo es relativamente bajo,
son muy versátiles y, además, hoy en dı́a existe una gran
comunidad que trabaja con esta plataforma y constantemente
se está generando nueva documentación.
IV-B. LabVIEW
LabVIEW es un software enfocado a ingenierı́a donde se
simplifica la integración de hardware para diversas aplica-
ciones. Permite programar usando un sistema de bloques y
visualizar resultados por medio de una interfaz de usuario
(Fig.2) [2].
Figura 2. Ejemplo de un proyecto en LabVIEW. En la parte de la izquierda se
observa el panel frontal y en la parte de la derecha se encuentra el diagrama
de bloques.
IV-C. Entorno de LabVIEW
IV-C1. Instrumentos Virtuales VIs: Los programas ge-
nerados con LabVIEW llevan el nombre de Ïnstrumentos
virtuales.o VIs (Virtual Instruments), debido a que su aparien-
cia y forma de operar simulan a los instrumentos fı́sicos que
podemos encontrar en la vida real.
IV-C2. Panel Frontal: El panel frontal de un VI es el
nombre que recibe la interfaz de usuario, desde la cual se
puede interactuar con el programa creado (Fig.2 izquierda).
IV-C3. Diagrama de Bloques: El diagrama de bloques
se utiliza para realizar la parte de programación del VI,
utilizando bloques de programación unidos por cables de datos
representados por diferentes colores (Fig.2 derecha) [3].
IV-D. Datos en LabVIEW
El software de LabVIEW es capaz de manejar distintos
tipos de datos y de organizarlos de diferente manera. Son
distinguidos por color y se usan por razones especı́ficas [4].
Existen 4 tipos de datos principales (Fig.3):
Tipo de Dato Cadena de Caracteres (Rosa)
Tipo de Dato Numérico (Azul y naranja)
Tipo de Dato Booleano (Verde)
Tipo de Dato Dinámico (Azul oscuro)
Figura 3. Tipos de datos en LabVIEW representados con su color.
IV-E. LIFA/LINX
La interfaz de LabVIEW para Arduino (LIFA) es
un conjunto de herramientas que permiten realizar la
comunicación entre los microcontroladores Arduino con
LabVIEW para procesar datos y realizar la programación que
permite este último con su interfaz gráfica. [5]
Para este proyecto se usó la versión más actualizada
llamada LINX, el funcionamiento es similar pero esta
nueva versión tiene soporte para más microcontroladores,
tiene mejoras de compatibilidad y algunos bloques de
programación adicionales.
Estas herramientas son gratuitas y se pueden añadir fácil-
mente a LabVIEW. También se debe cargar previamente el
código de LINX en una tarjeta Arduino antes de poder
empezar a programar con LabVIEW, aunque esto puede ser
realizado dentro del mismo software.
V. DESCRIPCIÓN METODOLÓGICA
Para la parte de la construcción del circuito, se realizaron
las conexiones de cada módulo de ultrasonido directamente
a los pines del Arduino uno. El botón utilizado para
medir el tiempo de respuesta fue conectado por medio de
una protoboard, incluyendo resistencias, para después ser
conectado a uno de los pines del Arduino y poder leer la
entrada dentro de la programación de LabVIEW.
En la parte de la programación se realizó todo el manejo
de la información para poder obtener los valores de tiempo
de respuesta, velocidad, fecha y hora. Al mismo tiempo, a
través del panel frontal (Fig.4) fue posible observar en tiempo
real la detección realizada por cada sensor y leer los datos
obtenidos.
A continuación se explicará el significado de cada recuadro
e indicador del panel frontal:
Serial Port: En este recuadro se selecciona el puerto en
el cual está conectado el Arudino a la computadora.
Figura 4. Panel frontal del VI construı́do.
Centimeters: Este recuadro indica el valor en centı́me-
tros de la distancia a la cual se encuentran los objetos
que detecta el primer sensor.
Centimeters 2: Este recuadro indica el valor en centı́me-
tros de la distancia a la cual se encuentran los objetos
que detecta el segundo sensor.
Centimeters 3: Este recuadro indica el valor en centı́me-
tros de la distancia a la cual se encuentran los objetos
que detecta el tercer sensor.
Contador: Indica el número de veces que un objeto pasa
por un sensor determinado, el cual sirve para llevar la
cuenta de pruebas realizadas.
Reiniciar: Este botón sirve para reiniciar el contador.
Stop: Botón para detener la ejecución del programa.
Siempre se recomienda pulsar este botón para detener el
ciclo en vez de abortar, ya que esta última opción puede
trabar el programa.
Boton Usuario: Este indicador sirve para mostrar vi-
sualmente cuando el botón colocado en la bicicleta es
presionado y para comprobar su funcionamiento.
Fecha: Indica la fechaen formato DD/MM/AA.
Hora: Indica la hora, minutos y segundos del dı́a trans-
curridos.
S1: Indicador que sirve para comprobar que el primer
sensor detectó un objeto dentro del rango preestablecido.
S2: Indicador que sirve para comprobar que el segundo
sensor detectó un objeto dentro del rango preestablecido.
S3: Indicador que sirve para comprobar que el tercer
sensor detectó un objeto dentro del rango preestablecido.
Reloj 1: Indica el tiempo en ms del contador interno de
LabVIEW cuando el sensor 1 detecta un objeto.
Reloj 2: Indica el tiempo en ms del contador interno de
LabVIEW cuando el sensor 2 detecta un objeto.
Reloj 3: Indica el tiempo en ms del contador interno de
LabVIEW cuando el sensor 3 detecta un objeto.
Timer Respuesta: Indicador que muestra el valor del
contador interno de LabVIEW en ms cuando se presiona
el botón en la bicicleta.
Tiempo de respuesta (ms): Tiempo de respuesta en
ms calculado desde la detección del tercer sensor (el
más alejado) hasta el momento en que el botón fue
presionado.
Tiempo 1: Tiempo que tardó el objeto en pasar del sensor
2 al sensor 1.
Tiempo 2: Tiempo que tardó el objeto en pasar del sensor
3 al sensor 2.
Distancia (m): Control de distancia entre el sensor 1 y
2.
Velocidad 1: Indica la velocidad calculada a la que pasó
el objeto entre el sensor 1 y 2.
Distancia 2 (m): Control de distancia entre el sensor 2
y 3.
Velocidad 2: Indica la velocidad calculada a la que pasó
el objeto entre el sensor 2 y 3.
En el diagrama de bloques (Fig.5) se puede observar cómo
se programó el sistema para medir las distancias, tiempos y
velocidades. El elemento inicial para la construcción de este VI
fue el ciclo while, indicado por el margen gris, que simula un
loop como el que encontrarı́amos al programar en el entorno
de Arduino IDE.
A continuación, se coloca el control del puerto para poder
indicar en el panel frontal en cuál estaremos trabajando y
que el programa pueda leer las señales que recibe el arduino.
Después es colocado el bloque que marca el inicio de la
conexión Serial y donde irán colocados el resto de bloques:
los tres sensores y un bloque que sirve para leer la entrada
digital del botón colocado en la bicicleta. Por último, en esa
misma lı́nea y fuera del ciclo while, se coloca un bloque para
indicar el fin de la conexión.
A cada bloque de sensor se le ajustan los parámetros de valor
máximo y mı́nimo de detección, en este caso se eligieron
valores de 400 cm como máximo y 10 cm como mı́nimo.
Igualmente se le colocó a cada bloque de sensor que funcione
con la condición ”false-true”para que no se envié constante-
mente un valor diferente, ya que con cada valor detectado
dentro del rango se realiza una operación.
Conectado al primer sensor se puede observar una estructura
case, el objetivo de esto es que, cada vez que el sensor 1
detecte un objeto dentro del rango preestablecido, se ejecuta
todo lo que esté marcado en el caso True. En este caso, cuando
un objeto pasa por el sensor 1 ocurre lo siguiente:
1. Inicia el contador y se almacena en un arreglo de datos.
2. Se guarda el valor de la fecha (obtenido del bloque
fecha/hora).
3. Se guarda el valor de la hora (obtenido también del
bloque fecha/hora).
4. Se guarda el tiempo de respuesta.
5. Se almacena el valor de la velocidad 1.
Figura 5. Diagrama de bloques del proyecto realizado.
6. Se almacena el valor de la velocidad 2
7. Por último, todos los valores almacenados se envı́an a
un documento.
Este documento mantiene el formato de todos los valores
registrados en un orden predefinido, el cual puede observarse
a la izquierda, fuera del ciclo while, en el diagrama de
bloques. De esta manera es posible almacenar todos los datos
fuera de LabVIEW. Además, se evitan los datos innecesarios
ya que estos procesos solo se ejecutan cuando el sensor 1
detecta un objeto dentro del rango de interés (Fig.6).
El resto del diagrama de bloques incluye las operaciones
necesarias para el cálculo de la velocidad y el tiempo de
respuesta. Se utilizó una estructura case para que cada
contador se activara con su sensor correspondiente y con las
condiciones indicadas.
Finalmente, se colocó un botón de paro como condición de
todo el ciclo while donde se encuentran casi todos los bloques
para detener la ejecución del programa de manera segura.
VI. RESULTADOS
Los resultados obtenidos de cada prueba fueron anotados a
mano, tomados directamente del panel frontal del VI y también
fueron almacenados en un documento de Excel automática-
mente. Los valores tomados del panel frontal coincidieron con
las condiciones reales de las pruebas, pero los valores guar-
dados en el documento de Excel fueron incorrectos (Fig.6).
Figura 6. Documento de Excel generado automáticamente. Los valores
negativos de velocidad y tiempos de respuesta en cero se deben a fallos
ocasionales de detección por parte de los sensores y la misma condición de que
los valores se almacenan cuando el sensor 1 detecta un movimiento dentro del
rango, sin importar si los demás sensores detectaron movimiento o no. Esto
resulta en operaciones con mezclas de valores obtenidos de pruebas anteriores,
con las que se obtienen estos datos incorrectos. Los textos de las columnas
se generan cada vez que el programa se detiene y se vuelve a ejecutar, razón
por la cual se observa la repetición de estos. En condiciones ideales, donde
todos los sensores detecten siempre sin fallo, los valores almacenados en la
gráfica deberı́an corresponder a los valores observados en tiempo real con el
panel frontal.
Fuera de los errores obtenidos a causa del fallo de detección
ocasional por los sensores, el VI funcionó como se esperaba.
Especialmente el panel frontal, fue muy útil para la detección
en tiempo real de los valores en cada prueba y además sirvió
para notar cuando algún sensor en especı́fico no detectaba un
objeto dentro del rango. Esto demuestra la importancia de
tener una interfaz con la que el usuario pueda familiarizarse
para leer datos y detectar problemas con facilidad.
Como se puede observar en las siguientes figuras, los senso-
res ultrasonicos debı́an mantenerse estables en todo momento,
por lo que se montaron en tripies, además las conexiones se
soldaron para evitar falsos contactos o que se desconectaran
por algún incidente.
Figura 7. Montaje de sensor ultrasonico en tripie.
Figura 8. Vista de sensor ultrasonico utilizado.
También se puede observar el montaje de la bicicleta de
prueba, la cual lleva en el manubrio el botón que se utiliza
para registrar los tiempos de reaación, a su vez se muestra
una vista lateral del montaje de los tres sensores en la pista
de pruebas.
Figura 9. Usuario realizando prueba.
Figura 10. Vista lateral de montaje del sistema.
VI-A. Circuito simulado
Como se puede observar en el siguiente circuito, el sistema
trabaja utilizando 6 pines digitales y obteniene el suministro
de energı́a para funcionar del propio arduino uno.
Figura 11. Circuito del sistema de tres sensores ultrasonicos simulado en
Tinkercad.
VII. CONCLUSIONES
La práctica realizada sirvió como refuerzo final de todos
los conocimientos adquiridos a lo largo de este semestre.
Fue posible desarrollar habilidades usando el software de
LabVIEW para programar y se logró construir un proyecto
que, aunque se puede mejorar, sirvió para cumplir con el
objetivo planteado.
El principal punto de mejora del trabajo realizado serı́a
realizar ajustes en el diagrama de bloques. Considerando que
los sensores pueden fallar y no detectar siempre, se deberı́an
agregar condiciones adicionales para evitar que se tomen en
cuenta las mediciones cuando alguno de estos no envı́a una
señal de detección. De esta manera se evitarı́a el cálculo de
operaciones con datos erróneos, que no pertenecen a la prueba
actual, y solo se almacenarı́an los valores en el documento
generado automáticamente cuando los tres sensores manden
una señal al arduino.
La experiencia obtenida tanto con LabVIEW, como con
estos problemas que surgieron,nos dejan mejor preparados
para futuros proyectos. Ahora tenemos otro punto de vista
desde el cual podemos cuestionar si el sistema puede fallar,
cómo puede fallar y qué podemos hacer para evitar esos
fallos o cómo podemos diseñar un producto para que esos
fallos no afecten a los resultados que deseamos obtener. Algo
similar a lo que pudimos lograr gracias al funcionamiento
deseado de la interfaz, en el panel frontal de LabVIEW.
Finalmente, la elaboración de este reporte permitió dar un
vistazo al trabajo que logramos diseñar y probar. Aunque
quizás no fue un proyecto tan avanzado, nos hace reflexionar
de lo que somos capaces cuando aplicamos los conocimientos
que vamos adquiriendo durante nuestra formación siendo
estudiantes y futuros ingenierios profesionales.
REFERENCIAS
[1] ¿Qué es Arduino?. Arduino. Recuperado de: https://arduino.cl/
que-es-arduino/
[2] LabVIEW. National Instruments. Recuperado de: https:
//www.ni.com/es-mx/support/downloads/software-products/download.
labview.html#411240.
[3] Entorno NI LabVIEW. National Instruments. Recuperado de: https:
//www.ni.com/academic/students/learnlabview/esa/environment.htm
[4] Tipos de Datos y Estructuras. National Instruments. Recuperado de:
https://www.ni.com/academic/students/learnlabview/esa/datatypes.htm
[5] LabVIEW Interface for Arduino Documents. National Instruments. Re-
cuperado de: https://forums.ni.com/t5/LabVIEW-Interface-for-Arduino/
LabVIEW-Interface-for-Arduino-FAQ/ta-p/3521717?profile.language=
es
	Introducción
	Objetivo
	Material
	Fundamentación Teórica
	Arduino
	LabVIEW
	Entorno de LabVIEW
	Instrumentos Virtuales VIs
	Panel Frontal
	Diagrama de Bloques
	Datos en LabVIEW
	LIFA/LINX
	Descripción Metodológica
	Resultados
	Circuito simulado
	Conclusiones
	Referencias