Presentado a
LA UNIVERSIDAD DE LOS ANDES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE INGENIERÍA ELÉCTRICA Y ELECTRÓNICA
Para obtener el título de
INGENIERO ELECTRÓNICO
por
Andrés Felipe Hernández Gómez
CONTROL DE VELOCIDAD EN UN TREN
Sustentado el 26 de Mayo de 2014 frente al jurado:
Composición del jurado
- Asesor: Michaël Canu, Profesor Asociado, Universidad de Los Andes
Resumen Ejecutivo
Este proyecto comprende el diseño e implementación de un sistema de control inalámbrico de velocidad para un tren, que permita mediante la manipulación de ciertas variables como el ciclo útil de la señal de control, los retardos entre lectura y escritura y ciertos parámetros de configuración del puerto serial entender más a fondo el modelo del controlador y los problemas que pueden presentarse a la hora de hacer un intercambio de datos de manera inalámbrica.
De esta forma se implementa un sistema en donde el control de la velocidad depende del ciclo útil de una señal PWM que se genera con uno de los “timers” incorporados en uno de los microcontroladores inalámbricos que se utilizan, el cual permite establecer el tiempo en alta y baja de la señal; mientras que la medición de esta misma, se lleva a cabo mediante el cálculo del periodo de la señal resultante de la salida de un sensor de Efecto Hall la cual es alterada mediante un campo magnético generado por un imán que se adhiere al eje de rotación del motor y pasara en frente de él cada vez que se cumpla una revolución de motor. Estos dos procesos, son realizados a través de comandos que vienen por defecto para interactuar con estos módulos, de manera que se establece un túnel entre los dos módulos y a través de estos comandos se manda y se solicita la información necesaria por medio de este.
Finalmente, luego de haber sido implementado, se automatizó el sistema en Labview buscando llegar a tener un lazo de control cerrado que pudiera corregir los errores en la velocidad y pudiera permitir un control y medición de la velocidad en tiempo real. Sin embargo, sobresalieron ciertos factores como el retardo en la comunicación, la ausencia de un buen modelo del motor y falencias en las mediciones que impidieron que el tiempo disponible no fuera suficiente para diseñar un control un poco más robusto que tuviera en cuenta toda esta serie de eventos.
Contenido
1 INTRODUCCIÓN ... 5
2 OBJETIVOS ... 5
2.1 Objetivo General ... 5
2.2 Objetivos Específicos ... 5
2.3 Alcance y productos finales ... 6
3 DESCRIPCIÓN DE LA PROBLEMÁTICA Y JUSTIFICACIÓN DEL TRABAJO ... 6
4 MARCO HISTÓRICO ... 6
4.1 Antecedentes Externos... 6
4.2 Antecedentes Locales ... 7
5 DEFINICION Y ESPECIFICACION DEL TRABAJO ... 7
6 METODOLOGÍA DEL TRABAJO ... 8
6.1 Búsqueda de información ... 8
6.2 Alternativas de desarrollo ... 8
6.2.1 Comunicación ... 9
6.2.2 Medición de velocidad ... 9
6.2.3 Control de Velocidad ... 10
7 TRABAJO REALIZADO ... 10
7.1 Descripción del sistema... 10
7.2 Areas de trabajo ... 10
7.2.1 Comunicación de los modulos ... 10
7.2.2 Programación de la comunicación ... 14
7.2.3 Comandos para establecer una conexión entre los módulos ... 15
7.2.4 Control de la velocidad del motor ... 17
7.2.4.1 Lenguaje de control de velocidad ... 18
7.3 Descripción del Resultado Final ... 22
7.4 Trabajo computacional ... 23
7.4.1 Configuración del puerto serial para el Coordinador y el “End Device” ... 23
7.4.2 Inicialización y lectura de la información en el “End Device” ... 24
7.4.3 Inicialización del módulo programado como Coordinador ... 26
7.2.3 Control y medición de la velocidad ... 26
8 VALIDACIÓN DEL TRABAJO ... 27
8.1 Metodología de prueba ... 27
8.2 Evaluación del plan de trabajo ... 28
9 DISCUSIÓN ... 28
10 CONCLUSIONES ... 28
11 AGRADECIMIENTOS ... 29
12 REFERENCIAS... 29
1
Introduccio n
Algunas instituciones de educativas, ven muy importante afianzar ciertos conocimientos de control en sus estudiantes de una manera más profunda, sin embargo, los instrumentos que muchas veces se requieren para hacer experimentos en esta área pueden resultar muy costosos o muy robustos, impidiendo que se logren estos objetivos. Es por esto que surge la idea de crear un sistema de control al que se pueda tener acceso a través de la red, para dar la oportunidad a otras instituciones de llevar a cabo una mejor enseñanza en esta área.
2
Objetivos
2.1Objetivo General
Diseñar un sistema que permita el control inalámbrico de velocidad en un tren, de manera que se pueda tener en un final una plataforma que permita realizar ciertos experimentos e impulsar de cierto modo el aprendizaje.
2.2Objetivos Específicos
La comunicación inalámbrica se realizara mediante unos módulos ya seleccionados de la firma Jennic, los cuales utilizan un protocolo de redes inalámbricas JenNet basado en el estándar IEEE 802.15.4.
Se utilizara Code Blocks como software para programar los módulos y otro software como Hyperterminal que permitirá establecer la comunicación e intercambiar datos entre los dos módulos.
El sistema se podrá controlar mediante el uso de Applet Java, la cual permitirá la conexión entre dos ordenadores vía internet, de manera que se pueda tener un control del sistema desde cualquier otro ordenador.
2.3
Alcance y productos finales
Realizar un control de velocidad en el tren mediante los módulos inalámbricos JN5139 del fabricante Jennic.
Permitir acceder al sistema a través de internet, logrando una conexión con el ordenador que tiene el control sobre el sistema mediante el uso de internet, de manera que pueda ser usado por otras Universidades para realizar ciertos experimentos o como un recurso para llevar a cabo la enseñanza.
3
Descripcio n de la problema tica y justificacio n
del trabajo
El proyecto surge como una idea de brindar a las instituciones educativas algunos instrumentos de apoyo para realizar prácticas en el área de control, de manera que los estudiantes logren adquirir conocimientos y atracción hacia esta área.
4
Marco Histo rico
4.1. Antecedentes externos
En los últimos años, la tecnología inalámbrica se ha ido introduciendo en una gran cantidad de aplicaciones, debido a que existen módulos con los que es posible realizarla a un bajo costo y que logran adaptarse fácilmente al sistema que se busca implementar. A nivel mundial podemos ver una serie de aplicaciones entre las cuales encontramos el control de ingreso de vehículos en ciertas zonas que son restringidas y la automatización de hogares, las cuales usan un protocolo de comunicación Zigbee, el cual resulta ser bastante similar al que se usara en este proyecto.
Esta primera, consiste en un control de autos al ingreso de un establecimiento. Para esto se disponía de un tag en el interior del auto y otro a la entrada del establecimiento los cuales consistían en dispositivos Zigbee, el primero configurado como dispositivo final y el segundo como coordinador. De esta manera, al presentarse un vehículo a la entrada del establecimiento, el tag del vehículo es para
comprobar su identidad y a continuación se solicita un password para comprobar la identidad del conductor. Esta información es llevada a una base de datos Ethernet donde se corrobora y se toma la decisión de si se le da acceso o no al vehículo. [1] En la automatización de hogares, se utilizó un método muy parecido al que se pretende usar en este proyecto. Se establece una red doméstica como una combinación de las tecnologías Zigbee y Wi-Fi. Cada dispositivo electrónico corresponde a un dispositivo Zigbee que es manejado por otro que cumple la labor de coordinador. Este coordinador a su vez se encuentra conectado con la red doméstica, a la cual se podrá acceder mediante el uso de Wi-Fi desde cualquier dispositivo remoto. Esta red doméstica resulta importante porque además de que permite la interconexión entre los dispositivos Zigbee e internet, provee una interfaz que permite la conexión de los dispositivos Zigbee. [2]
4.2. Antecedentes Locales
En conjunto con la Universidad Nacional, Universidad Tecnológica de Bolívar de Colombia y el Ecole des Mines Nantes y Ecole des Mines de Douai de Francia se posee una plataforma para la interacción e intercambio de proyectos realizados en cada una de estas instituciones con el fin de que cada una de ellas logre tener un repertorio más amplio para la realización de experimentos. De esta manera, al igual que con este proyecto, se han desarrollado otros que mediante el uso de Applet Java han logrado establecer una interfaz con la que el usuario podrá interactuar desde cualquier otro ordenador.
5
Definicio n y especificacio n del trabajo
El trabajo planteado consiste en realizar un control inalámbrico de velocidad para un tren mediante el uso de los microcontroladores JN5139 del fabricante Jennic. Además de esto, se propone la automatización de este mismo en un software de programación y control como Labview, de manera que haya una mejor interacción con el usuario. Finalmente, se busca poder acceder a él desde cualquier dispositivo con acceso a internet, permitiendo su control sin importar la ubicación geográfica donde se encuentre la persona.
6
Metodologí a del trabajo
El proyecto está compuesto por cuatro campos, los cuales guardan una estrecha relación entre sí para el completo funcionamiento del sistema, estos son: la comunicación, la medición de la velocidad, el control de la velocidad y finalmente, la disponibilidad de este mismo en la red. Teniendo estos campos definidos, se pueden observar más claramente los campos de trabajo y se puede llevar a cabo un desarrollo más organizado del proyecto.
6.1Búsqueda de información
La búsqueda de información relacionada con el funcionamiento de los módulos y sus especificaciones, se llevó a cabo en la página web del fabricante, donde se pudo tener acceso a un gran número de manuales y artículos que describían los diferentes usos y la manera correcta de utilizar estos mismos. Por otro lado, se recurrió a los foros de esta misma página, donde muchas veces se enunciaban problemas que podían presentarse a la hora de interactuar con los módulos y las maneras de solucionarlos.
Para la medición de velocidad, se consultaron varios métodos y se escogió finalmente el que podría resultar más aplicable y más preciso de acuerdo a las características del proyecto.
6.2Alternativas de desarrollo
A la hora de buscar soluciones al problema, se plantearon varias alternativas, las cuales se fueron descartando a lo largo del proyecto de acuerdo a los problemas y restricciones que se fueron presentando. A continuación, se enumeran las alternativas propuestas en un principio tanto para la comunicación como para el control y medición de velocidad y las restricciones o ventajas que presentaban cada una de ellas
6.2.1. Comunicación
Comunicación inalámbrica mediante un flujo de datos vía UART0:
Esta fue la primera alternativa considerada. De esta forma, se lograba mandar de un módulo a otro cualquier tipo de información y recibirla de manera exacta a la que fue enviada. Esta alternativa, a pesar de resultar ideal para el control de velocidad, puesto que se pretendía utilizar un controlador de velocidad con una entrada PWM vía serial (los cuales habían sido comprados), no permitía el intercambio de los datos de las mediciones ya que estas últimas eran simplemente voltajes DC obtenidos a la salida del sensor. Además de esto, esta forma de programación de los módulos, no permitía el uso de los periféricos integrados en cada uno de ellos, como los “timers”, ADCs, entre otros.
Intercambio de información mediante comandos preestablecidos para los módulos.
Esta forma de programación, permitía tener un acceso a cada uno de los periféricos de los microcontroladores, con los cuales se podía llevar a cabo la medición de la velocidad. Esta alternativa no resulto compatible con los controladores de velocidad con entrada serial de los cuales se disponía, puesto que cuando se manda una información mediante un comando, el otro modulo recibe esta información pero seguida también de un comando, junto con otra información que no era útil y que no fue posible extraer de manera que quedara solo la información necesaria para el módulo de control. Por esta razón, resulto más conveniente usar uno de los timers integrados en uno de los módulos, para generar una señal PWM con amplitud de 3V que entrara a un circuito de potencia y lograra controlara establecer la velocidad del motor.
6.2.2. Medición de velocidad
Sensor de proximidad
Permitía una medición de velocidad externa al tren, por lo que los datos no podían ser obtenidos en cualquier momento de tiempo.
Sensor infrarrojo
Al igual que con los sensores de proximidad, estos debían ser ubicados en la pista, de manera que se requería de la ubicación de varios de estos durante el trayecto del tren. Con estos, básicamente se pensaba calcular la velocidad de acuerdo al tiempo en que se dejaba de recibir la señal por este sensor y al largo del tren.
Sensor de efecto Hall.
Finalmente, esta fue la alternativa escogida, puesto que podía incorporarse en el tren que se pretendía usar y podían obtenerse datos casi que en tiempo real. Esta alternativa simplemente buscar medir el tiempo que toma una revolución del motor y con esto obtener una aproximación de la velocidad.
6.3.3. Control de velocidad
Controlador de velocidad para un motor con entrada serial
Esta fue la alternativa considerada en un inicio y durante una buena parte del proyecto por lo que se había realizado la compra de este controlador. Este simplemente recibía una entrada serial de 8 bits donde 7 de estos contenían la información que finalmente variaba el ciclo útil de la señal PWM que se obtendría a la salida. Esta alternativa fue descartada, al tener que cambiar la forma en que se comunicarían los módulos y al no resultar compatible con esta.
Timers incorporados en los microcontroladores JN5139
Esta fue finalmente la que alternativa que reemplazo la anterior, puesto que no requería adicionar otro dispositivo al sistema y el control podía realizarse de manera relativamente sencilla. Esta consiste en generar una señal PWM con los “timers” incorporados en los microcontroladores inalámbricos usados.
7
Trabajo realizado
7.1. Descripción del sistema
Fig.1. Diagrama de bloques del sistema
En la figura 1 se muestra el diagrama de bloques del sistema. Como se puede ver, se envían datos correspondientes al control de velocidad desde un ordenador, los cuales viajan a través de la comunicación inalámbrica establecida y llegan finalmente “End device”, el cual ejecutara las acciones correspondientes a los comandos enviados. En el sentido inverso, se obtienen mediciones del campo magnético existente entre el imán situado en el motor y el sensor de efecto Hall (línea puteada), las cuales son recibidas por el “End device” y enviadas finalmente al coordinador.
7.2. Áreas de trabajo
7.2.1. Comunicación de los módulos
Para realizar la comunicación entre el tren y el usuario, y poder intercambiar información, de manera que se pueda llevar a cabo un control y una medición de ciertas variables en el tren, se utilizaron los módulos JN5139 del fabricante Jennic, los cuales brindan al usuario una forma sencilla de realizar una comunicación entre dos dispositivos, mediante el uso del protocolo IEEE802.15.4. Cada uno de estos módulos se encuentra instalado en un kit de evaluación el cual tiene algunos botones y puertos seriales tanto RS232 y TTL que permite interactuar con ellos.
La alimentación del módulo se puede llevar a cabo mediante 3 formas: dos baterías AAA, una fuente externa o vía USB. En el caso de alimentarse mediante una fuente externa, los voltajes de entrada deben estar entre 5-6V DC o 4.5-6V AC. La selección del tipo de alimentación se lleva a cabo con la correspondiente ubicación del jumper J2. Para llevar a cabo la alimentación con baterías, el jumper debe estar conectando los pines 2 y 3, y para los casos restantes, el jumper debe conectar los pines 2 y 3. El diagrama del módulo se muestra en la figura 2.
Fig.2. Kit utilizado que contiene el módulo de conexión. [1]
Como se puede ver de la figura 2, el kit posee dos puertos seriales. El UART1, el cual corresponde a un puerto serial RS232 y el UART0, el cual corresponde a un puerto serial TTL. Para el primero de estos, se cuenta con un conversor de voltaje, de manera que se realiza la conversión 13V a 3.3V (el cual corresponde al nivel de alta en TTL para el modulo utilizado) antes de entrar al microprocesador, ya que a este solo pueden llegar señales con un voltaje máximo de 3.3V. Para el segundo, se cuenta con una conexión directa a los pines del módulo, ya que comparten los mismos niveles de voltaje. Para este proyecto, solo se hará uso del puerto UART0 (TTL), ya que la idea es utilizar solo el módulo de comunicación y así, si se usan niveles TTL no habría necesidad de implementar un conversor de voltaje. En la figura 3, se muestran los detalles de cada uno de los pines de la conexión con niveles TTL. Vale la pena anotar, que la configuración de los pines mostrada corresponde a los pines del UART0 ubicado en el módulo de comunicación; para el conector USB-TTL solo basta con invertir el orden de los pines 4 y 5.
Fig.3. Detalle de la conexión TTL. [2]
La conexión de cada uno de estos pines con el módulo de conexión se describe en detalle en la tabla 1.
Pin UART0 Pin Antena Nombre Pin Descripción
2 17 RTS0 Request to send
4 19 RXD0 Receive data
5 18 TXD0 Transmit data
6 16 CTS0 Clear to send
Tabla.1. Relación entre pines UART0 y pines módulo JN5139.
Además de esto, el modulo cuenta con conector de expansión (figura 5), el cual es simplemente contiene las conexiones al microcontolador.
Fig.5. Conector de expansion de los comulos de comunicación. [2]
En la tabla 2 se describen los pines utilizados para el desarrollo del proyecto.
PIn Funcion Microcontrolador Funcion proyecto
9 Timer 0 Clock/Gate (input) Referencia PWM 11 Timer 0 PWM (output) Control del Motor 12 Timer 1 Clock/Gate (input) Referencia Capture 13 Timer 1 Capture (Input) Medicion de velocidad
40 Ground Referencia
Tabla.2. Pines del conector de expansion utilizado. [2]
7.2.2. Programación de la comunicación
Para la comunicación de los módulos se llevó a cabo la programación de los módulos con un software disponible en la página web del fabricante. Con esto, se crea una red en la que uno de los dispositivos toma el papel de coordinador y el otro de receptor o “End device”, estableciendo una conexión bidireccional entre los dos, permitiendo mandar y recibir información en cada uno de ellos mediante de unos comandos establecidos por defecto.
7.2.3. Comandos para establecer una conexión entre los módulos
Para la inicialización de cada uno de los módulos y de esta manera lograr una conexión inalámbrica entre ellos, se requiere de ejecutar una serie de comandos, luego de encender cada uno de ellos. Estos se describen con gran detalle a continuación.
La configuracion de los parametros de la red que se va a establecer, por la cual se comunicaran los dos modulos, se lleva a cabo mediante el comando CFG, donde lo primero que se escribe es el comando a ejecutar, seguido de cada uno de los parametros separados como se muestra.
CFG,auto-scan-chs, max-childs, max-ed-child, max fails, ed-activity-timeout
Parámetro Descripción Entrada
auto-scan-chs Número del canal de comunicación a utilizar Núm. 32 bits
Max-child Máximo numero de nodos en la red 0-16
Max-ed-child Máximo número de “End-devices” en la red 0-8
Max fails Máximo numero de comunicaciones fallidas para
terminar la conexión
1-255
ed-activity-timeout Tiempo máximo en que no se reciba información del
“End device” antes de perder la conexión
Núm. 32 bits
Tabla.3. Parametros del comando CFG (Configuracion de la red). [4]
El siguiente comando inicializa una red por la que van a comunicarse los dos modulos:
INI,pan-id, radio-ch,nwk-app-id, restore-context, routing-en
Parámetro Descripción Entrada
Pan-id Pan-ID de la red a crear Núm. 16 bits
Radio-ch Radio-canal de la red a crear 0: Selección automática
del canal 11-26: Canal especifico
Nwk-app-id ID de la aplicación de la red Núm. 32 bits
Restore-context Habilita restaurar el contexto de los datos
de la red guardados en una memoria. 0: Desactivar 1:Activar
Routing-en Opción de enrutamiento. Siempre
desactivado para end-devices.
El siguiente comando inicializa el dispositivo como un tipo de nodo específico:
STR,node-type
Parámetro Descripción Entrada
Pan-id Pan-ID de la red a crear Núm. 16 bits
Node-type Inicializa el dispositivo como un tipo de
nodo especifico.
0: Coordinator 1: Router 2: End Device Tabla.5. Parámetros comando STR. (Inicialización del dispositivo). [4]
El siguiente comando, permite configurar un tunel entre dos nodos para el intercambio de información:
TCN, local-tnl-svce, remote-addr, remote-tnl-svce
Parámetro Descripción Entrada
Local-tnl-svce “Service ID” Núm. 1-32
Remote addr Dirección del nodo con el cual se quiere abrir el túnel Núm. 16 bits
Remote-tnl-svce “Remote tunelling service” “32”
Tabla.6. Parámetros comando TCN. (Configuración del túnel). [4]
Adicional a esto, luego de configurar el túnel, es necesario mandar el comando TCM,”TOP” para habilitar este y empezar a mandar información.
La respuesta del sistema ante una conexión exitosa está dada por el siguiente comando:
NTU,parent-addr, local-addr, depth-in-nwk,pan-id, radio-ch
Parámetro Descripción salida
Parent-addr Dirección del “parent-node” al cual se ha realizado
la conexión
Núm. 64 bits
Local-addr Dirección del nodo que se está uniendo a la red Núm. 64 bits
Depth-in-nwk Profundidad del nodo en la red 0: Coordinador
1: Router 2: End device
Pan-id PAN ID asignado Núm. 32 bits
Radio-ch Canal asignado para la conexión. 11-26
Tabla.7. Parámetros Comando NTU. (Respuesta del sistema). [4]
7.2.4. Control de la velocidad del motor
El control de velocidad del motor se realizó con uno de los “timers” incorporados en el “End device”. Con este, se genera una señal de PWM, la cual básicamente se le modifica el ciclo útil para obtener una mayor o menor velocidad. La configuración de este “timer” se realiza a través de los parámetros enunciados a continuación.
El siguiente parámetro permite configurar y activar el “timer” que se quiere utilizar:
PTE,timer,clock-divisor, int-config, ext-output, dio-en, clock-config
Parámetro Descripción Entrada
Timer Indica el timer que se quiere utilizar 0: Timer 0
1: Timer 1
Clock-divisor
Toma la frecuencia del timer y la divide entre donde p es la entrada
seleccionada.
Núm. 0-16
Int-config Condiciones de interrupción para el
timer
0: flanco de subida (off), fin timer(off) 1: flanco de subida (on)
Fin timer (off) 2: flanco de subida (off)
Fin timer (on) 3: flanco de subida (on)
Fin timer (on)
Ext-output Habilita la salida PWM 0: apagada
1: Encendida
Dio-en Habilita los pines para ser utilizados
por el timer
0: apagado 1: Encendido
Clock-config Selección y polaridad del “clock” 0: Externo/Normal
2: Interno/Invertido 3: Externo/Invertido Tabla.8. Parámetros comando PTE. (Configuración del “Timer”). [4]
El siguiente parámetro permite iniciar el timer seleccionado en cierto modo de operación:
PTG,timer, mode, time-to-rise, time-to-fall
Parámetro Descripción Entrada
Timer Indica el timer que se quiere utilizar 0: Timer 0
1: Timer 1
Mode Indica el modo de operación del timer
seleccionado
0: Single shot 1: Repeat 2: Delta-sigma RTZ 3: Delta-sigma NRZ
Time-to-rise Numero de ciclos de reloj de la señal en
baja (“0” lógico)
Núm. 16 bits Hex
Timer-to-fall Numero de ciclos de reloj de la señal
(en alta y en baja)
Núm. 16 bits Hex
Tabla.9. Parámetros comando PTG. (Inicialización del “Timer” y configuración PWM). [4]
Vale la pena mencionar, que el comando PTG, con el cual se controla la señal de salida PWM, debe ser mandado desde el coordinador hasta el “End device” a través del túnel configurado anteriormente, por lo que se requiere que este comando este contenido en el comando TCM, como se muestra a continuación.
TCM,”PTG,timer, mode, time-to-rise, time-to-fall”
7.2.4.1. Lenguaje de control de velocidad.
La velocidad, como se mencionó anteriormente, se controla mediante una señal PWM que sale de uno de los “timers”, mediante el comando PTG. De esta manera, se genera una señal repetitiva donde se establece un “time to fall” fijo y se varia el “time to rise” para ajustar el ciclo útil de la señal de acuerdo como se muestra en la figura 6.
Fig.6. Modelamiento señal PWM
Para el proyecto realizado, se tomó un periodo de la señal (“time to fall”) de 512 ciclos de reloj, lo que equivale a x0200 en hexadecimal, la cual es la manera de especificar estos parámetros en el comando.
7.2.5. Medición de la velocidad del motor
Para la medición de velocidad del motor, se utilizó el principio de funcionamiento del “Efecto Hall”. De manera que se sitúa un pequeño imán en el eje de rotación del motor y se dispondrá de un sensor de efecto hall de salida digital, que detectara el momento en que se cumple una revolución del motor, tal y como se muestra en la figura 7.
Fig.7. Principio de medición de la velocidad del motor.
El sensor a utilizar será el A3212EUA del fabricante Allegro y su diagrama de conexiones se muestra en la figura 8.
Fig.8. Diagrama de conexiones Sensor de Efecto Hall. [6]
Este sensor tiene un estado normal alto (Vcc). Cuando el campo magnético detectado por este excede el umbral BOPS o desciende por debajo de BOPN, la salida
automáticamente pasa a un estado de baja (0V), en el que permanecerá hasta que se crucen de nuevo los umbrales BRPS o BRPN. Esto se puede observar con más
detalle en la figura 9.
Fig.9. Funcionamiento del Sensor de Efecto Hall A3212. [6]
Esta señal de salida del sensor de efecto Hall, entra en uno de los “timers” que esta vez estará en un modo de operación “capture” el cual permite medir la duración un ciclo en alta (figura 10), de manera que teniendo la relación del ciclo útil de esta señal del sensor se puede estimar la velocidad en rpm del motor. Esta señal es enviada finalmente desde el “End-Device” hasta el coordinador, mediante el túnel que se abrió anteriormente para comunicación entre ellos.
FIg.10. Calculo del ancho del pulso a través del Timer 1 en modo “Capture”.
Para iniciar el “timer” en modo “capture”, se requiere de la utilización del comando PTE mencionado anteriormente y del comando PTC el cual tiene de entrada solo el número del “timer” seleccionado (0 o 1). Por último, para solicitar datos de la lectura del mismo, se requiere del parámetro PTR seguido nuevamente del número del “timer” al cual se le solicita la información. (Estos dos comandos deben ir contenidos en el comando TCM de manera que se garantice que la información viaje a través del túnel hasta el “End-Device”).
En esta sección del proyecto, se presentaron algunas fallas relacionadas con una medición imprecisa por parte del sensor de efecto hall, ya que la señal obtenida a la salida de este, presentaba grandes variaciones en el periodo para una misma velocidad. Este hecho se ilustra en la figura 11.
Además de esto, en muchos casos la frecuencia de la señal obtenida del sensor resultaba ser menor o igual para una velocidad mayor en el motor. Luego de una gran cantidad de mediciones para una serie de velocidades en el motor, se logró obtener una aproximación de la curva de frecuencia vs el ciclo útil de la señal PWM (figura 12), donde se evidencia un claro error en los datos. La curva solo se realizó hasta un ciclo útil del 25 %, porque por encima de este el error pasaba a ser mucho mayor.
Fig.12. Frecuencia de señal de salida de sensor de efecto hall vs ciclo útil de señal PWM.
7.3. Descripción del Resultado Final
En la figura 13 se muestra el circuito implementado para el control y medición de la velocidad del motor. A través del “PWM” se manda la señal de control y a través del “Capture” se recogen las mediciones realizadas por el sensor de efecto hall. Como anexo de este documento se presenta una imagen de la implementación final del proyecto. 0 1 2 3 4 5 6 7 8 9 10
0,08 0,1 0,17 0,2 0,25
Fr e cu e n ci a (H z)
Fig.13. Diagrama circuital de la solución propuesta.
7.4. Trabajo computacional
El trabajo computacional realizado, consistió en la automatización del sistema para el control y medición de la velocidad. Por un lado, se requirió automatizar el modulo configurado como coordinador para que solo fuera necesario insertar un parámetro de velocidad y el automáticamente enviara un comando al “End device”. Por el otro lado, se automatizo la medición de la velocidad, de manera que el coordinador estuviera solicitando constantemente al “End device” los datos de la medición y con estos se calculara la velocidad del motor en rpm.
7.4.1. Configuración del puerto serial para el coordinador y el End device.
En la figura 14 se muestra la configuración del puerto serial tanto para el coordinador, como para el “End device”. En primera instancia, se configuran los parámetros básicos del puerto serial, como la tasa de envió de datos, el nombre del puerto utilizado, entre otros. Seguido de esto, se habilita la terminación de un comando con un carácter especial (en este caso un espacio en blanco, simulando la tecla “Enter”). Finalmente, esta información que va llegando al puerto serial se almacena en un buffer, así los datos se leen de manera ordenada y se garantiza que no vaya a haber pérdida de información.
Fig.14. Automatización de la configuración del puerto serial.
7.4.2. Inicialización y lectura de la información en el End-Device
Luego de la configuración del puerto serial, se inicializa el “End device”, mediante comandos CFG, CFP, INI, y STR que fueron descritos anteriormente, para lo cual se utilizó una instrucción “case” en la cual se van ejecutando uno a uno los comandos (figura 15) y una vez termina (cuando i=3, ya que el conteo empieza desde 0), se pasa al otro caso en el que solo se reciben los datos y pasan automáticamente al bloque de lectura, el cual se muestra en la figura 16. Cabe resaltar, que entre el proceso de escritura y lectura, se ha adicionado un retardo o “delay” para que se alcancen a obtener las respuestas a cada comando y en el orden correcto, en caso de que existan. Por último, la información leída por el módulo pasa a un “String” para que sea visualizada por el usuario.
Fig.15. Inicialización del End-Device con Labview.
Vale la pena resaltar, que una vez inicializado en dispositivo configurado como “End-Device”, este puede ser desconectado del ordenador y funcionar con baterías, de manera que el paso que se muestra en la figura 16 se omitiría.
7.4.3. Inicialización del módulo programado como Coordinador
Fig.17. Inicialización del Coordinador.
De igual forma que en el “End device”, se puede ver de la figura 17, que en primera instancia, se ejecutan los comandos correspondientes a la configuración de la conexión del módulos (CFG, INI y STR); luego de esto se procede a abrir el túnel por donde serán enviados los datos de control y medición (mediante el comando TCN) y finalmente se habilitan los “timers” que van a ser usados en el proceso (PTE). De nuevo se ha establecido un “delay” entre los procesos de escritura y lectura para permitir que los las respuestas a los comandos alcancen a ser leídas por el módulo.
7.4.4. Control y medición de velocidad
Inmediatamente se termina la inicialización del coordinador, se comienza con el envió de comandos para establecer la velocidad y realizar la medición en el motor. Esto consiste en enviar repetidamente los comandos PTG, PTC y PTR a través del túnel y con los datos obtenidos calcular la velocidad en rpm tal como se muestra en la imagen adjunta a este documento.
La velocidad en rpm es calculada de la siguiente manera:
Se toman cuatro último bits de la respuesta que representan el número de ciclos de reloj para un periodo de la señal y se le restan los primeros cuatro que a su vez
son el número de ciclos de reloj en que esta señal se encuentra en estado de baja, obteniendo así el número de ciclos de reloj en que la señal estará en alta. Teniendo esto se procede a hacer las siguientes operaciones:
Donde CUSH es el ciclo útil de la señal del sensor de efecto hall y la frecuencia del reloj interno es de 16 MHz. Finalmente, se obtiene la velocidad mediante la siguiente relación.
( ) ( )
( )
Una vez se automatizó el sistema en Labview, se observaron ciertos retardos en la comunicación, llegando a obtener un desfase de hasta 10 segundos tanto en los datos de las mediciones como en la señal de control de la velocidad. Para esto, se buscó establecer un nuevo modelo, en el cual se obtuvieran los datos solo si el usuario los solicitaba, de manera que no se fuera haciendo cada vez más grande el buffer donde se iban almacenando uno a uno los datos, pero este hecho no logro reducir este retardo mencionado.
8.
Validacio n del trabajo
8.1. Metodología de prueba
Cada área del sistema se probó por separado, para tener corroborar su funcionamiento y saber los niveles de voltaje que se iban a obtener a la salida de cada uno de ellas de manera que se ajustaran a los límites de cada uno de los módulos que se iban a usar. Una vez se corroboro esto, se procedió a implementar todo el sistema y a si mismo comprobar de nuevo el funcionamiento. Finalmente, luego de haber rectificado lo anterior, se procedió a hacer la automatización en Labview.
8.2. Evaluación del plan de trabajo
Hasta cierto punto el proyecto pudo ser realizado de acuerdo al plan de trabajo establecido, con el cual se lograban cumplir todos los objetivos propuestos en un inicio, sin embargo, toco rediseñar algunos puntos que ya se habían desarrollado puesto que impedían cumplir con los objetivos finales, lo cual llevo a un retraso en las tareas restantes y por ende al no poder cumplir con todos los objetivos asignados.
9.
Discusio n
A través del desarrollo del proyecto, se presentaron una serie de problemas, los cuales resultan normales en todo proyecto, pero que sin embargo llevaron al cambio de la manera en que se habían programado los módulos y de la manera en que iba a ser controlada la velocidad. Por esta razón, los tiempos estipulados para la realización de cada tarea tuvieron ciertas variaciones y en un final no se lograron cumplir todos los objetivos propuestos en un inicio. Sin embargo, los resultados obtenidos conforman una gran parte de lo que se buscaba lograr. Como trabajo futuro, podría trabajarse en la robustez del sistema, para que de esta forma se tengan en cuenta los factores que pueden afectar el lazo de control y en el hacer disponible este en la red para que a través de un dispositivo con acceso a internet, sin importar su ubicación geográfica, pueda interactuar con este.
10.
Conclusiones
Todo lo que fue el desarrollo del proyecto y los inconvenientes que se presentaron, sirvieron para poder afianzar muchos conceptos y tener muy en cuenta ciertos factores que surgen en la realización de este. Se deja claro de esta manera, que para realizar un control de lazo cerrado del sistema que llegue a ser bastante preciso, se requiere de conocer muy bien la función de transferencia del motor a utilizar, la cual va asociada a algunos parámetros de los cuales muchas veces no se tiene información dificultando el desarrollo del proyecto. Sin embargo, mediante ciertas mediciones, se podría llegar a obtener una aproximación de ella que permita automatizar el sistema incluyendo una corrección de errores. Además de esto, se debe tener muy en cuenta que al realizar un control inalámbrico, pueden
presentarse una serie de retrasos en la comunicación, lo que lleva a que el control y mediciones, en el caso que se presenten, no puedan establecerse en tiempo real dificultando y haciendo muchas veces imposible el lazo de control.
11.
Agradecimientos
Se agradece a las personas que de una forma u otra tuvieron una participación en este proyecto de grado. Especial agradecimiento al profesor Michaël Canu quien fue el encargado de asesorar el proyecto y siempre estuvo disponible para la resolución de cualquier inquietud y así poder llevar a cabo el desarrollo del proyecto. Por último, también se agradece al profesor Mauricio Duque por haber asistido como jurado en la sustentación del proyecto.
12.
Referencias
[1]. Jennic. JN5139-EK020 802.15.4/JenNet Starter Kit. User Guide. (Application
Note: JN-UG-3040) Pag 12.
[2]. Jennic. DR1080 Starter Kit Board. Reference Manual. (Application Note: JN-RM-2037) Pags 13,14.
[3]. Jennic. Data Sheet: JN5139-xxx-Myy. IEE802.15.4/ZigBee Module Family. Pag 6.
[4]. Jennic. AT-Jenie Reference Manual. JN-RM-2038.
[5]. Jennic. Data Sheet: JN5139-001 and JN5139-Z01. IEEE802.15.4 and Zigbee Wireless Mircrocontrollers.
[6]. Allegro. A3211 and A3212 datasheet. Micropower, Ultrasensitive Hall-Effect Switches.
