Carte centrale inertielle v2

IMG_0003IMG_0004

Depuis le workshop de février et le test de la précédente carte, nous sommes passés par une phase de spécification. Avec l’aide précieuse de Samuel Poiraud, nous avons réfléchi à ce que nous devions ajouter/changer sur cette carte.

Alimentation

Tout d’abord l’alimentation, notre carte possède deux régulateurs, un à 5V et un autre à 3.3V¹ ce qui permet de fournir une tension adéquate à tous les composants de la carte.

De plus, pour alimenter la carte nous utilisons un transformateur (produisant du 7V continu à partir de l’alimentation secteur 230V à 50Hz) en série avec un fusible convenablement dimensionné. La carte et l’ordinateur portable que nous emmènerons seront branchés sur une multiprise spéciale de Novespace. Cette multiprise peut être directement vissée sur les rails de l’avion et possède un bouton coup de poing, un porte-fusible et un disjoncteur différentiel.

Architecture générale de la carte

Diagramme blocLes différences notables entre la première version et la deuxième sont l’ajout de différentes fonctions et donc un nombre plus important de pins utilisées par le microprocesseur. En outre, le PIC18F46K22 que nous utilisions possède deux ports UART or nous avons désormais trois composants reliés en UART. Donc succinctement, deux choix étaient possibles : l’achat de deux pics ou d’un seul avec plus de ports UART.

Mais nous avons préféré découper notre carte en deux parties : l’acquisition et la transmission. C’est-à-dire l’utilisation d’un microprocesseur (toujours le PIC18F46K22) pour récupérer les données des capteurs et d’un autre pour les transmettre au PC et faire d’éventuels traitements.

Capteurs :

IMG_0015

Accéléromètre

MMA8451Q

Il a été décidé après réflexion d’utiliser un accéléromètre qui renverrait des données numériques et non plus analogiques. Les deux choix étaient défendables mais étant donné que nous avions à disposition un meilleur capteur communiquant numériquement (I²C) et que tous les autres composants en faisant de même, nous avons décidé de prendre celui-ci.

Gyromètre

LD3GD20

Malheureusement, nous n’avions pas pu tester le gyromètre que nous avions commandé pour la carte précédente (rappel). Etant donné ce fait, nous avons préféré réévaluer notre demande et si nécessaire rechercher un meilleur gyromètre. Ironiquement après en avoir comparé plusieurs, nous sommes retombés sur le même modèle. Néanmoins, entretemps, une nouvelle version était sortie et c’est celle-ci que nous avons décidé d’utiliser.

Finalement pour ne pas répéter la même erreur en prenant un composant que nous ne pourrions souder, nous l’avons recherché déjà implémenté sur un module.

GPS

GPS

MR350

Ce GPS était celui que nous avions utilisé avec la précédente carte malheureusement aucune datasheet n’était disponible, même en demandant directement au constructeur. Donc par défaut nous sommes obligé de récupérer les trames que nous renvoie le GPS tel quel sans aucun moyen de paramétrer ce dernier. A cause de cela, nous avons décidé de le remplacer par un autre GPS, le L70, plus adapté pour une utilisation sur circuit imprimé (car soudable directement sur la carte) et bénéficiant d’une documentation complète.

Cependant, nous avons préféré garder le MR350 sur la carte au cas où le L70 ne fonctionnerait pas le jour j ou si l’un des deux GPS viendrait à perdre temporairement le signal.

De plus nous avons décidé d’implémenter les GPS sur deux PICs différents, cela nous permet de marquer les trames d’une heure précise (voir plus bas).

IMG_0010

L70

Ce GPS a déjà été utilisé dans un des projets de Samuel Poiraud et donc nous étions sûr de pouvoir nous en servir convenablement. De plus, la fréquence de communication avec le PIC est plus rapide que le précédent GPS, c’est-à-dire que nous recevons plus de données à période égale.

Stockage et transmission :

IMG_0011 IMG_0008

Nous avons réfléchi à la meilleure manière de conserver et traiter les informations que nous allions récupérer des capteurs. Il nous semblait logique que les données ne soient pas mesurés à un instant que chaque capteur aurait décidé par lui-même mais à un instant t donné. Il est possible de garder en mémoire une donnée dans chaque capteur en utilisant un FIFO (hormis pour le GPS) ce qui permet de récupérer à un instant quasiment similaire les données mesurées. Ainsi nous transmettons au PC, une trame contenant toutes les mesures des capteurs.

Cependant, il nous semblait logique de ne pas mettre tous les œufs dans le même panier car, si par exemple, le PC avait un bug, câble débranché ou autre problème, il nous fallait pouvoir continuer à enregistrer des données. C’est pourquoi nous avons ajouté un support de carte SD. Cette carte nous permet d’enregistrer les mêmes trames qui sont envoyées au PC.

Si la carte SD a un but unique de stockage, cela en est différent pour la liaison avec le PC. En effet, l’un des objectifs de notre projet est de pouvoir visualiser (quasiment) en instantané la parabole se dessiner. Donc les données reçues par le PC doivent être stockées pour être retravaillées plus tard mais aussi analysées. Pour ce faire, nous utilisons le logiciel MATLAB qui nous permettra d’analyser sommairement les données pour les afficher en temps réel.

IHM :

description

On peut découper le vol en deux parties distinctes, l’une qui correspond au décollage, atterrissage ou vol linéaire et la deuxième partie, plus intéressante où nous effectuons une parabole. Il nous semblait logique de pouvoir distinguer ces deux parties. Au cours du vol, avant chaque parabole, un des membres d’équipage annonce le début de celle-ci. Donc nous avons implémenté un bouton sur notre carte qui indique au système que nous entrons dans une parabole. Puis un même appui sur ce bouton lorsque nous en sortons.

La première utilité de ce bouton est de pouvoir garder en mémoire chaque parabole et donc avoir des repères lors du traitement ultérieur. De plus, une autre idée est de se dire que seule la parabole nous intéresse vraiment donc les capteurs ne devraient pas être obligés de fonctionner à la fréquence maximale tout le temps. L’appui sur ce bouton permet de passer à un mode « repos » où les données sont prises moins souvent que dans un mode « parabole ».

En outre pour chaque capteur, nous avons implémenté une LED qui nous permet de vérifier en vol si le capteur correspondant communique bien avec son PIC. De même, elles sont un moyen simple de savoir si les capteurs se sont bien initialisés lors de la mise en marche. Nous avons aussi mis une LED test qui pourra servir si besoin s’en trouve, pourquoi pas mis en parallèle avec le bouton parabole.

De plus nous avons aussi intégré un écran LCD avec deux boutons de navigations. L’idée était de pouvoir suivre en direct le bon fonctionnement de la carte ce qui est bien sûr mis en parallèle avec l’analyse des données sur MATLAB.

Nous avons essayé au maximum d’ajouter des sécurités, des moyens de communiquer avec la carte pour pouvoir connaître à chaque instant l’état de fonctionnement de celle-ci.

Communication entre les PICs :

L’idée est de pouvoir transmettre simplement et sans problème les données captées par le premier PIC au deuxième PIC. Nous avons alors réfléchi sur un protocole de communication. Celui-ci se présente assez simplement et n’est pas forcément celui qui sera finalement implémenté. Mais l’idée choisie est la suivante :

Nous possédons 10 fils, 8 servant à l’envoie d’un octet et 2 autres aux acquittements. Le principe est assez simple. Le premier pic envoie sur son fil d’acquittement un bit attestant l’envoi d’une donnée. L’autre pic renvoie un OK sur son propre fil. Le premier pic envoie alors l’octet sut les 8 fils jusqu’à ce que le PIC 2 atteste de la bonne réception de ceux-ci. Cela est répété jusqu’à l’acquisition de la trame entière. Il est alors signalé par un message spécial au PIC2 que toute la trame a été envoyée.

Nous réfléchissons actuellement sur des variantes de ce protocole, notamment sur la vérification du nombre d’octets reçus et sur la meilleure manière de transmettre. Ceci n’est donc qu’un résumé de ce qui pourrait être implémenté.

Traitement des données

Comme ce qui a été expliqué plus haut, nous allons traiter les données via MATLAB mais plusieurs problèmes nous sont apparus au tout départ de la conception de la V2 :

Comment savoir à quel moment précis les données ont été capturées ?

Il faut savoir qu’un GPS récupère dans ces trames, l’heure exacte de sa communication avec les satellites, donc une heure fiable et identique pour deux GPS différents. Donc marquer les trames des capteurs avec une donnée GPS nous suffit pour indiquer à quel moment, elles ont été mesurées. Une autre solution possible aurait été d’utiliser une clock externe aux PICs mais cela aurait pu poser d’autres problèmes comme la marge d’erreur de cette clock.

Cependant le problème qui pourrait être rencontré est la non réception des trames GPS et donc l’impossibilité de marquer les trames. Ce problème a été pris en compte dans la question suivante.

Comment traiter des données qui peuvent subir une distorsion dans le temps, c’est-à-dire que la courbe mesurée soit différente de la courbe réelle ?

Dans ce cas, nous utilisons un filtre de Kalman qui permet, expliqué très sommairement, de rendre un aspect réel à une courbe qui ne le serait pas. Mais cela impose d’avoir un étalon, une courbe que l’on pourrait comparer.

C’est là que les GPS interviennent puisque ceux-ci mesurent à un instant précis la position de l’avion et donc, je vous le rappelle, ils permettent de tracer une courbe réelle. Donc la courbe des GPS est précise et réelle mais n’est pas détaillé et peut ne pas être complète. Alors que la courbe des capteurs est quant à elle est complète et détaillée mais subit une distorsion dans le temps (rappelez vous de la raison de l’hybridation GPS des centrales inertielles).


1 : Un régulateur permet avec une tension supérieure en entrée, de fournir une tension linéaire en sortie, exemple : en entrée nous mettons du 7V et en sortie nous avons du 5V.

Publicités

2 commentaires pour Carte centrale inertielle v2

  1. Aymeric dit :

    Bonjour,

    Je trouve super le projet. Vous parlez notamment des erreurs présentes sur les capteurs, comme les phénomènes de distorsions. Je ne sais pas si vous y avez pensé, mais la mesure des différents capteurs varie en fonction de la température. Par la suite, si le projet est toujours en cours, n’hésitez pas à intégrer un capteur de température assez précis afin de venir corriger les données des accéléros et gyros.

    Bonne continuation

    • brolandeau dit :

      Remarque très pertinente ! Nous avions noté aussi ce problème mais avons décidé de ne pas le prendre en compte. Pour une raison assez simple : l’air dans un avion est climatisé. Même si la température change au cours du vol cela restera de l’ordre du +1 ou -1 degré donc ayant un impact « négligeable » (du moins dans notre contexte de mesure) sur les capteurs.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s