Fonctionnalités du micro-logiciel des IMUs

Toutes les fonctionnalités nécessaires aux besoins du projet ont été implémentées tout en respectant les performances possibles du système. Ces changements permettent une grande robustesse de celui-ci en intégrant uniquement l’essentiel avec des méthodes d’analyses aussi souples que performantes. Les fonctionnalités sont désormais les suivantes :

Elle est bidirectionnelle, les flux de contrôle sont activités et le débit est à 460800 bits/s. La transmission est effectuée par DMA et la réception par interruption. Le codage du caractère de fin de trame a été simplifié et l’intégrité de celle-ci peut être vérifiée au niveau de l’iPad.

La liaison d’intercommunication SPI :

Dans les précédentes phases, l’initialisation du SPI, correspondant à la détection du nombre d’IMUs connectées au système prenait 12 secondes. Dans cette phase, de nouveaux algorithmes ont été développées et la détection du nombre d’IMU connectées prend désormais 0,4 secondes. De plus lors d’un redémarrage, l’IMU reçoit par le « maître » les informations nécessaires pour recréer son buffer automatiquement et ainsi ne pas perturber le système. De ce fait, dans le cas où une panne survient dans le système, l’IMU peut être retiré et remplacé sans perturber le fonctionnement du système. Il est également possible désormais de connecter ou de retirer des IMU durant le fonctionnement du système, en tenant compte que l’on informe l’IMU « maître » qu’il y a eu un changement. Chaque IMU « esclave » peut recevoir des informations de contrôle. Cette fonctionnalité permet pour l’instant le redémarrage des IMUs, mais une fois les algorithmes fonctionnels, elle permettra l’interaction avec eux. Une vérification robuste de l’intégrité de la trame est mise en place.

Note : Dans les phases précédentes, une fois le système ayant connaissance du nombre d’IMUs connectés, chacun d’entre eux créent leurs trames en utilisant l’allocation dynamique en mémoire. Ceci pouvant être une source d’erreurs potentielle (idéalement, il faut éviter de faire ce type d’allocation mémoire dans un microcontrôleur, pour des raisons de robustesse et de performance), elle est supprimée dans cette nouvelle version. Actuellement, juste la taille de la trame change pour les DMA (réception et émission) mais la place mémoire de la variable reste inchangée.

Le capteur de température interne :

Chaque microcontrôleur dispose d’un capteur de température interne relié à son ADC 1. Ce capteur de température se sert d’une tension de référence qui doit être stable afin d’obtenir

des résultats corrects. Dans la dernière phase développée, le DMA se chargeant de récupérer les données des gyroscopes, récupère en plus les données du capteur de température.

La remise à zéro automatique :

Cette fonction permet le redémarrage des IMUs de façon individuelle si un problème se produit au niveau de la communication ou durant le processus normal d’exécution. Plusieurs cas sont gérés : L’IMU « maître » est doté d’un « chien de garde » permettant son redémarrage après 0,08 seconde. Ce redémarrage se produit uniquement si l’utilisateur souhaite redémarrer tout le système ou dans le cas d’un arrêt du processus normal. Les IMUs « esclave » sont doté d’un « chien de garde » permettant leur redémarrage après 0,04 seconde ou dans le cas où la variable indiquant le redémarrage voulu par l’utilisateur est mise à 1. Le premier cas est utilisé lors d’un arrêt du processus normal et dans le cas où l’on connecte de nouveaux IMU au système durant le fonctionnement. Le deuxième cas est utilisé lorsque l’utilisateur spécifie un redémarrage, celui-ci pouvant être assignée uniquement à un IMU, lorsqu’on effectue un redémarrage du système global ou dans le cas où l’on connecte de nouveaux IMUs dans le fonctionnement.

Note : Le temps de redémarrage de l’IMU « maître » est plus long afin de permettre aux autres IMUs du système de redémarrer automatiquement si l’un d’entre eux voyait son processus arrêté (dans le cas d’une exception non gérée et non connue à l’heure actuelle).

La réception de commandes :

Lorsque l’iPad envoie une commande, celle-ci est traitée dans l’IMU « maître » qui l’analyse et transfère à son tour une commande par la liaison SPI si nécessaire. Dans le cas présent, les commandes servent uniquement au redémarrage des IMU mais par la suite, ils permettront d’interagir avec les algorithmes inertiels et de choisir les données à transférer. Les commandes reçues peuvent être appliquées de manière individuelle ou d’une manière globale sur l’ensemble du système. Présentement, on peut effectuer un redémarrage global ou individuel des IMU. Ces fonctionnalités permettent entre autre le retrait ou l’ajout d’IMU durant le fonctionnement du système, comme nous l’avons vu précédemment.

Informations importantes :

Il est important de prendre en compte qu’il faut maintenant un système de communication robuste où la tolérance des erreurs de transmission doit être inférieure à 1%. Dans le système développé pour la phase 2, seulement 42,7% des données transmissent étaient reçues. Ce qui ne permet pas l’utilisation des données brutes des capteurs inertiels. De plus, les données ne doivent pas être corrompues, sinon l’application et l’analyse de l’efficacité des algorithmes inertiels seront faussées et ne seront pas représentatives. De ce fait, des méthodes de vérification de l’intégrité des trames sont nécessaires pour la liaison SPI et UART.

Problèmes rencontrés :

La difficulté majeure rencontrée lors de l’élaboration du micro-logiciel concerne la combinaison des différentes fonctionnalités, essentiellement au niveau de la procédure de communication.