Phase 3 (Février 2012 à aujourd’hui)

A ce stade, j’ai repris le projet dans son intégralité pour la phase 3. Cette nouvelle phase consiste à réaliser le prototype, permettant la capture de mouvements et la navigation à l’intérieur des bâtiments, performant, robuste et intégrant toutes les fonctionnalités respectant les spécifications du projet ibNav. Le projet est réparti en 5 sections de développement différentes (Figure 1.1).

Le micro-logiciel des IMU

L’architecture

matérielle Le logiciel pour l’iPad

Les algorithmes inertiels

Figure 1.1 Répartition des différentes sections du projet ibNav

Afin de réaliser cette nouvelle phase de développement, chaque section du projet est reprise et une première analyse est effectuée afin de prendre en compte les changements à effectuer ainsi que les fonctions récupérables. Par la suite, une nouvelle base fonctionnelle est créée et chaque fonctionnalité à implémenter suit une nouvelle méthodologie afin de s’assurer qu’elle ne comporte aucune erreur (Figure 1.2).

Figure 1.2 Méthodologie de développement pour le projet ibNav

Les différentes tâches à réaliser pour la phase 3 du projet ibNav sont globalement :

Le micro-logiciel des IMU :

Il doit être modifié afin d’offrir une communication globale SPI et UART plus performante tout en offrant de nouvelles fonctionnalités telles que la communication bidirectionnel pour l’UART et la connexion/déconnexion d’IMUs durant le fonctionnement du système pour le SPI. Les données du capteur de température interne doivent être récupérées. La gestion des exceptions doit être prise en compte afin de prévenir les problèmes au niveau de la communication. La consommation de chaque IMUs doit idéalement être plus faible ainsi que la demande de ressources afin de permettre la récupération des données brutes et des données calculées (après application des algorithmes inertiels).

Le système de communication :

Il doit être robuste afin de permettre la récupération des données brutes des capteurs inertiels au niveau de l’iPad. Contrairement à l’utilisation des données calculées, l’utilisation des

données brutes est sensible aux erreurs puisqu’elles sont par la suite appliquées sur des algorithmes inertiels en post-traitement. Il nous faut donc un système avec un nombre de trames manquantes négligeables tendant vers zéro. De plus, le système de communication sans-fil doit pouvoir fonctionner en deux modes différents. Le premier étant une liaison directe entre le système et l’iPad, permettant ainsi de se déplacer où l’on veut dans le bâtiment et le deuxième est une liaison passant par un point d’accès (AP) permettant d’avoir l’internet et de pouvoir ainsi transmettre les données pour du post-traitement.

L’architecture matérielle :

Elle doit être constituée de câbles flexibles afin que le système soit incorporé dans un vêtement et ne nuise pas aux mouvements de l’utilisateur. La répartition énergétique doit être faite de façon étoilée afin que l’intensité circulant dans l’architecture ne nuise pas au système de communication. Le même principe doit également être adopté pour l’horloge de la communication SPI. Des régulateurs de tensions et des optocoupleurs doivent être ajoutés. Un blindage sur les câbles serait également intéressant à mettre en place. De plus, il faudrait mettre des connecteurs sur chaque boîtier contenant un IMUs afin d’éviter des fils cassant au niveau des soudures dû aux mouvements de l’utilisateur. Ces connecteurs permettront également, en cas de panne d’un IMUs, de pouvoir le remplacer facilement et efficacement. Il faut également prévoir un connecteur/câble permettant la reconfiguration de l’IMUs en cas de besoin (mise à jour ou panne du système). Finalement, il faudrait ajouter un écran LCD afin d’avoir un visuel directement sur le bon fonctionnement du système.

Le logiciel pour l’iPad :

Il doit présenter de nouvelles fonctionnalités, que ce soit pour la capture de mouvements ou la navigation à l’intérieur des bâtiments. Il doit également être plus ergonomique et mettre l’accent sur l’esthétique. Elle nécessite de fonctionner sous 3 modes de traitements différents suivant le choix de l’utilisateur :

1. En mode connecté « maître » où les algorithmes sont appliqués au niveau de l’iPad en mode temps réel;

2. En mode connecté « esclave » où les algorithmes sont appliqués soit sur l’iPad « maître », soit au niveau des IMUs en mode temps réel;

3. En mode post-traitement.

Elle doit intégrer une interface pour la localisation des bâtiments et améliorer l’interface pour la capture de mouvements afin de pouvoir visualiser correctement les mouvements du corps en 3D. Puisque c’est également une plateforme permettant l’étude des capteurs inertiels et de ses algorithmes, une interface permettant la visualisation des données brutes et calculées sous forme de graphique sera réalisée ainsi qu’une autre interface permettant l’analyse et la modification des algorithmes.

Les algorithmes inertiels :

Ils doivent être vérifiés dans un premier temps en post-traitement sous Microsoft Visual C++ et Matlab. Cette première étape concernera les algorithmes existants soit l’algorithme de calibration avec EKF et l’algorithme de navigation AHRS/EKF avec ses modèles de connaissances associées. Des améliorations et modifications importantes seront surement nécessaires. Dans un deuxième temps, l’algorithme pour la navigation à l’intérieur des bâtiments doit être réalisé soit INS/EKF avec ses modèles de connaissances associées et la méthodologie PDR. Il faudrait également effectuer une dernière fois l’analyse des erreurs stochastiques et déterministes pour chacun des IMUs. Finalement, le robot développé lors de la phase 1 permettra de vérifier la performance des algorithmes inertiels.