Étape 4: Gratuit RTOS
Afin d’exécuter toutes les tâches nécessaires en temps réel, FreeRTOS a été utilisé. FreeRTOS est un système d’exploitation en temps réel, qui signifie qu’il va répondre aux événements dans un délai prévisible. Ceci est important car il permet au système d’être prévisible. Le code a été conçu pour avoir quatre tâches qui suivent :
- La lecture d’UART
- Lecture du Module WiFi ESP8266
- Lecture de l’IMU MPU-6050
- Une console de ligne de commande en cours d’exécution
La lecture d’UART
Il s’agissait d’une tâche simple qui a interrogé l’UART pour les nouveaux personnages. Quand un nouveau personnage a été trouvé, le personnage a été ensuite placé dans une file d’attente, ce qui a été lue par la tâche de console de ligne de commande. Cela aurait pu être implémenté en utilisant les interruptions de l’UART, mais vote était simple, travaillé, et en faisant cette tâche la priorité la plus faible, il seulement pouvait exécuter lorsqu’il n’y avait rien à faire. Cela signifie qu’il ne perdait pas cycles de l’UC du scrutin l’UART lorsque d’autres choses à faire. L’autre préoccupation avec l’UART de vote était si personnages venaient trop vite. Dans notre configuration, nous interrogé l’UART pour toutes les 10 ms, de nouveaux personnages qui est nettement plus rapide que n’importe quel homme pourrait taper. Cela peut être problématique si la console UART devait être exécuté à partir d’un script de l’ordinateur, mais nous avons décidé que la fonction l’emporte sur la simplicité du module.
Lecture du Module WiFi ESP8266
Dans le cadre de ce projet, nous voulions également la communication sans fil. Après tout, il serait malheureux si le cube a besoin d’être connecté à un ordinateur. Ceci a été accompli en utilisant un ESP8266, un module WiFi petit, facile à utiliser disponible auprès de nombreux fournisseurs différents. La ESP8266 communique au Conseil Zynq également via une interface UART, qui rendait nécessaire d’écrire un autre pilote UART. Pour ce pilote UART, nous devons lire en nombre de caractères à la fois, ce qui signifiait qu’il fallait d’interruptions. L’interruption gestionnaire wass appelée chaque fois qu’un personnage a été lue par l’UART et ajoute que les données à une file d’attente. La file d’attente est ensuite lue par la tâche de ESP8266, qui décide ce qu’il faut voir avec la nature.
La tâche était composée d’une machine de grand État pour l’initialisation du module et de lire des données entrantes. Lorsque la tâche a reçu des paquets provenant du module il l’envoya à la même file d’attente qui a été utilisé par le module UART, qui a été lue par la tâche de la console. Cela permet les mêmes commandes de console être utilisé par les deux un opérateur physiquement connecté au système ou en WiFi. Aussi, cette méthode permettant la réutilisation du code et maintient le code base plus organisée.
Lecture de l’IMU MPU-6050
L’IMU-6050 est un IMU contrôleur 6 axes, composé d’un accéléromètre 3 axes et d’un gyroscope à 3 axes. Cela permet pour la détection de l’angle et la vitesse de rotation du système, qui sont tous deux important à l’algorithme de contrôles. Il était simple d’obtenir des données sur le capteur. Le capteur communique via I2C avec l’adresse 0x68. Avant de lire les données de l’accéléromètre et gyroscope, le capteur doit être mis hors mode "veille" en écrivant 0 à l’adresse 0x6B, le registre de gestion de puissance. A partir de là, les premières lectures accéléromètre et gyroscope peuvent être lu à partir d’adresse 0x3B. Référez-vous à la fiche de données et enregistrer la carte pour une fonctionnalité complète.
Lorsque nous avons commencé à jouer avec le capteur, nous avons remarqué que les données brutes n’étaient pas précises en plus d’être bruyant. Nous avons utilisé deux techniques distinctes pour résoudre ces problèmes. Après avoir examiné les données, nous avons remarqué que l’IMU semble avoir un décalage de la lecture correcte. Pour résoudre ce problème, nous avons placé le Mio sur une table de niveau, où nous savions que l’orientation de chacun de l’axe de l’accéléromètre. Puis nous avons pris et en moyenne 5 mesures de l’IMU. Ensuite, nous avons pris l’orientation connue et il soustrait de l’accélération, qu'il nous a donné. Le résultat a été un vecteur d’offset qui a été soustrait de chaque IMU lecture. Cela augmente significativement la précision du système. Pour résoudre le problème du bruit, nous avons utilisé un simple point 5 avec une moyenne de filtre. Au lieu de retourner chaque IMU lecture, nous stocker 5 lectures et prendre la moyenne de chaque valeur. Cela a contribué à éliminer un peu juste du bruit que nous avons été voir du capteur.
De là, nous espérions d’envoyer cette information pour le FPGA, ce qui irait à l’algorithme de contrôles. Malheureusement, nous avaient des difficultés de mise en œuvre de l’algorithme de contrôles en Verilog et a décidé de mettre en oeuvre en C. Pour cette raison, une fois un IMU valide la lecture a été prise, la tâche RTOS ensuite calculer la vitesse du moteur nécessaire et envoyez-le au moteur par l’intermédiaire du bloc de génération de PWM. Alors que cela fait de la mise en oeuvre plus simple, il aurait été agréable d’exécuter les contrôles à l’intérieur le FPGA dont nous pensons qu’auraient amélioré la boucle de régulation.
Une Console de ligne de commande de lecture
La console de ligne de commande était responsable de l’envoi des commandes de niveau plus élevés et les informations, telles que les lectures de l’IMU provenant du système de vote. La console de ligne de commande se présente comme sa propre tâche et prend dans les données de l’UART et les ESP8266. Ceci a permis la console à être exploité directement depuis un ordinateur ou un réseau sans fil. La tâche est bloquée sur une file d’attente de FreeRTOS jusqu'à ce que les données étaient disponibles. La tâche a ensuite exploité comme une machine à États, lisant dans un nom de commande et de données. Si la commande est valide il serait exécuté le code associé et attendre pour une autre commande. Ce permis commandes souples et a été utile pour le débogage et commandant le système.
