Paso 4: RTOS gratis
Para poder ejecutar todas las tareas necesarias en tiempo real, FreeRTOS fue utilizado. FreeRTOS es un sistema operativo de tiempo Real, que significa que responderá a los eventos dentro de un período predecible de tiempo. Esto es importante porque permite que el sistema sea predecible. El código fue diseñado para tener cuatro tareas que siguen:
- Lectura de la UART
- Lectura de ESP8266 WiFi módulo
- Lectura de la IMU MPU-6050
- Ejecutar una consola de línea de comandos
Lectura de la UART
Esto fue una tarea sencilla que encuestados el UART para nuevos personajes. Cuando encontraron a un nuevo personaje, el personaje se coloca en una cola, que fue leída por la tarea de consola de línea de comandos. Esto podría se han implementado utilizando interrupciones de la UART, pero votación era simple, trabajado, y haciendo esta tarea la prioridad más baja, sólo fue permitido correr cuando no había nada más que hacer. Esto significa que no estaba desperdiciando ciclos de CPU el UART de la interrogación cuando podrían hacer otras cosas. La otra preocupación con el UART de la votación fue si personajes venían demasiado rápido. En nuestra configuración, hemos consultados el UART para nuevos personajes cada 10 ms, que es significativamente más rápido que cualquier humano puede escribir. Esto puede ser problemático si la consola UART debía ser ejecutado desde un script de ordenador, pero decidimos que la sencillez del módulo compensó esa característica.
Lectura de ESP8266 WiFi módulo
Como parte de este proyecto hemos querido también comunicación inalámbrica. Después de todo, sería lamentable si el cubo es necesario para conectarse a un ordenador. Esto fue lograda usando un ESP8266, un módulo de WiFi pequeña, fácil de usar disponible en muchos diferentes. El ESP8266 se comunica a la Junta de Zynq también mediante una interfaz UART, que hizo necesario escribir otro conductor UART. Para este controlador UART, necesitamos leer en muchos personajes a la vez, que significó que las interrupciones fueron requeridas. La era de controlador de interrupción llamado cada vez que un personaje se leídas por el UART y agrega los datos a una cola. La cola es luego leída por la tarea de ESP8266, que decide qué hacer con el personaje.
La tarea fue compuesta de una máquina grande del estado para la inicialización del módulo y leer datos de entrada. Cuando la tarea recibe los paquetes desde el módulo les envió a la misma cola que fue utilizada por el módulo UART, que fue leído por la tarea de la consola. Esto permite que los mismos comandos de consola que se utilizará por tanto un operador conectado físicamente al sistema o por WiFi. Este método también permite la reutilización de código y mantiene el código base más organizado.
Lectura de la IMU MPU-6050
IMU-6050 es una IMU 6 ejes compuesto de un acelerómetro de 3 ejes y un giroscopio de 3 ejes. Esto permite detección de ángulo y velocidad de rotación del sistema, que son importante para el algoritmo de control. Recibiendo datos desde el sensor era sencillo. El sensor se comunica a través de I2C con una dirección de 0x68. Antes de leer los datos de acelerómetro y giroscopio, el sensor debe tomarse del modo de sueño escribiendo 0 a dirección 0x6B, el registro de gestión de energía. A partir de ahí, las lecturas de acelerómetro y giroscopio crudas pueden leerse a partir en dirección 0x3B. Consulte la hoja de datos y registro de ruta para una funcionalidad completa.
Cuando comenzamos a jugar con el sensor, nos dimos cuenta de que los datos en bruto no eran precisos además de ser ruidosos. Utilizamos dos técnicas diferentes para resolver estos problemas. Después de mirar los datos, nos dimos cuenta de que la IMU parece tener un desplazamiento de las lecturas correctas. Para resolver este problema, colocamos la IMU en una tabla, donde sabíamos que la orientación de cada uno de los ejes del acelerómetro. Luego tuvo un promedio de 5 mediciones de la IMU. Luego tomamos la orientación conocida y restar de la aceleración nos dio. El resultado fue un vector de desplazamiento que se resta de cada IMU de lectura. Esto aumentó considerablemente la precisión del sistema. Para resolver el problema del ruido se utilizó un simple punto 5 con un promedio de filtro. En lugar de devolver cada IMU leyendo, almacenar 5 lecturas y tomar la media de cada valor. Esto ayudó a eliminar un poco del ruido que estábamos viendo desde el sensor.
Desde aquí esperábamos enviar esta información a la FPGA, que funcionaría el algoritmo de control. Por desgracia, nos estaban teniendo dificultades en implementar el algoritmo de control en Verilog y decidió implementar en C. Debido a esto, una vez una IMU válida lectura fue tomada, la tarea RTOS entonces calcular la velocidad del motor es necesaria y enviar al motor mediante PWM bloque de generación. Mientras que esto hace la aplicación más simple, habría estado bien ejecutar los controles dentro de la FPGA lo que creemos que habría mejorado el bucle de control.
Lectura de una consola de línea de comandos
La consola de línea de comandos fue responsable de enviar comandos de nivel superiores y la información, como las lecturas de la IMU del sistema de votación. La consola de línea de comandos funcionó como su propio trabajo y toma de datos del UART y el ESP8266. Esto permitió que la consola para funcionar directamente desde un ordenador o una red inalámbrica. La tarea bloqueada en una cola de FreeRTOS hasta que hubo datos disponibles. La tarea entonces funciona como una máquina de estado, en un nombre de comando y los datos. Si el comando es válido entonces se ejecuta el código asociado y esperar otro comando. Esto permitió comandos flexibles y fue útil para depurar y ordenar el sistema.
