ELECINF344/381

Partie interactive du site pédagogique ELECINF344/ELECINF381 de Télécom ParisTech (occurrence 2011).

Catégories

[CASPER] Demo de vendredi et API RS232

Voici dans ce post un bilan de la démonstration de Vendredi, ainsi qu’un bref état des lieux des avancées d’aujourd’hui concernant la programmation série en C sous linux.

 

Démonstration de vendredi

Nous avons Vendredi fait état de nos dernières avancées.

Nous avons débuté la démonstration par la présentation du PCB que nous avions réalisé et qu’Alexis nous avait remis il y a peu. Alain a, comme il l’a montré dans un post précédent, réussi à piloter l’écran LCD et afficher une animation simple comportant des rectangles de couleur et du texte.
Reste maintenant à réaliser l’interface série entre la carte et un ordinateur, puis programmer la mémoire flash embarquée.

Nous avons poursuivi par la démonstration de Thomas qui a piloté par l’intermédiaire de la carte de TP STM32 l’un des servomoteurs que nous allons utiliser. Grâce à son programme, nous sommes capables de piloter ces moteurs en leur fournissant une consigne angulaire.
Reste désormais à piloter le prototype en installant trois servomoteurs dans sa base.

Nous avons ensuite effectué une démonstration logicielle qui rassemblait les « helloworlds » que nous avions réalisés avec les différentes bibliothèques. Nous avons ainsi pu piloter à la voix l’ordinateur, lui demander de faire l’apprentissage de deux visages, puis de passer en mode reconnaissance. Une fois en mode reconnaissance, le moteur de synthèse vocale interfacé pour le moment avec pulseaudio a salué les visages connus en les nommant par leurs prénoms.

 

Comme Thomas l’a signalé dans son billet, nous avons pour le moment mis de côté le développement de drivers, pour nous concentrer essentiellement sur la mécanique, la programmation du PCB, et le port de nos applications sur la beagleboard.

Afin de préciser notre démarche, nous publierons bientôt sur ce site une liste actualisée de nos PSCC et des responsables associés.

 

Avancées de la journée : API RS232

De mon côté, je me suis penché sur la programmation du port série en C sous linux. J’ai trouvé à ce sujet une excellente source de documentation, qui m’a permis de comprendre rapidement l’interface posix permettant d’en effectuer la configuration. Vous retrouverez ce guide ici.

J’ai créé une interface de plus haut niveau permettant de lire et d’écrire sur un nombre indéfini de ports série, et de rentre transparente la gestion des lectures et écritures avec tampon.

Il suffit en effet pour utiliser un port série d’en demander l’ouverture en précisant le fichier /dev/tty* associé, et de donner en argument la fonction que l’on souhaite être appelée pour traiter les données.

L’API se charge ensuite d’appeler cette fonction lorsque de nouvelles données sont disponibles, ainsi que d’écrire les données stockées dans des tampons chainés lorsque le matériel est prêt.

L’utilisateur peut donc utiliser des fonctions non bloquantes pour écrire, et utiliser ses propres fonctions pour lire.

Pour finir, bien que cela ne soit pas encore implémenté, il est possible d’ajouter à cette API les sockets en plus des ports série. Cela permettrait de gérer par le biais d’une interface unique toutes les transmissions de la beagleboard, que ce soit par réseau ou avec le PCB.

RoseWheel : Une journée ensoleillée.

Tout d’abord, nous avons pu récupérer notre carte capteur en fin d’après-midi sur laquelle étaient soudés les principaux composants, en particulier l’accéléromètre, le gyroscope, un micromatch pour une UART et le STM32 de manière à ce que nous puissions effectuer les premiers tests et vérifier que les capteurs fonctionnaient bien.

Nous travaillons encore à traiter et à récupérer de façon propre les données de l’accéléromètre mais nous avons tout de même pu allumer une LED de deux couleurs différentes suivant l’inclinaison d’un axe, la preuve que celui-ci fonctionne comme il faut.

Nous sommes aussi en train de finaliser l’initialisation des drivers pour faire fonctionner l’I2C et le gyroscope. Les tests ne devraient pas tarder.

Enfin, nous avons pu faire fonctionner l’UART et envoyer des messages sur minicom. Ce fut un peu fastidieux et nous avons passé 2 heures à débugger une erreur très bête.

Coté filtrage, nous avons réussi à fusionner les 2 filtres de Kalman décrits dans le post précédent. Finalement nous obtenons un filtre de Kalman avec un vecteur d’état à 3 composantes [theta theta_dot drift]‘ et un vecteur de mesure à 2 composantes [theta_mes theta_dot_mes].

Les tests en simulation s’avèrent très bons, le filtre suit parfaitement le biais du gyroscope et ne décroche plus sur le long terme. Il a cependant fallu un peu de temps pour régler les valeurs d’initialisation. De plus, nous avons quasiment terminée l’implémentation en C et nous espérons pouvoir lancer des tests demain en fin de journée lorsque le gyroscope et l’accéléromètre seront en fonction.

To be continued.

RoseWheel : simulation et drivers

Aujourd’hui nous avons enfin terminé la partie simulation du RoseWheel. Nous sommes donc maintenant capables de simuler avec précision la dynamique du système ainsi que le filtrage des données des capteurs.

Évidemment, la modélisation exacte des différents paramètres, notamment les bruits des capteurs n’est qu’approximative et il faudra passer un peu de temps lors de l’implémentation en réel afin de les déterminer de manière correcte.

Concernant plus particulièrement la simulation du filtrage de Kalman, nous avons implémenté dans la simulation deux filtres de Kalman linéaires, le premier chargé d’extraire le biais de la mesure du gyroscope, le second chargé d’éliminer les composantes en hautes fréquences présentes dans les données du gyroscope et de l’accéléromètre. Cependant, pour des questions d’optimisation de temps CPU, on sera certainement amenés à fusionner ces deux filtres en un seul filtre, on espère que cela ne posera pas trop de soucis.

Nous avons cependant constaté que le filtre avait quand même du mal à suivre les variations du biais que nous simulions et que sur le long terme il lui arrivait de décrocher. Toutefois, nous pensons qu’il s’agit plus d’un problème au niveau de la simulation et que nous nous pencherons de façon plus approfondie sur le problème lorsque nous implémenterons le filtre en réel, c’est à dire demain.

Nous avons aussi pensé que cela pouvait être causé par la nature non linéaire du biais présent dans les données issus du gyroscope et qu’il serait peut-être nécessaire d’implémenter une forme de Kalman étendue plutôt que la forme linéaire. Mais encore une fois, nous testerons demain en réel afin de décider de la nécessité, ou non, de passer à une forme étendue du filtre.
Clément et Joao ont de leur côté continué d’implémenter les drivers pour les cartes.

Bonne nouvelle ! Alexis a terminé de souder les composants sur notre carte capteur. La journée de demain sera donc consacré aux différents tests de cette carte.

L’arrivée de notre carte est d’autant plus une bonne nouvelle que nous avons constaté un problème récurrent sur le gyroscope de la carte de Wheely que nous utilisions sur le testbench. En effet celui-ci a la fâcheuse tendance de ne plus rien retourner du tout parfois. Nous espérons que ce ne sera pas le cas sur notre carte.

Copterix : simulation du filtre de Kalman

Avec Axel, nous nous sommes penchés sur le filtre de Kalman. Après de longues lectures, nous sommes arrivés à clarifier les équations mises en jeu.

Nous avons finalement décidé d’opter pour un vecteur d’état contenant les trois biais des gyroscopes ainsi qu’un quaternion déterminant l’attitude de l’hélicoptère. Nous étions initialement partis sur un vecteur d’état contenant les trois biais des gyroscopes ainsi que les deux premières colonnes de la DCM (Direct Cosine Matrix) qui elle aussi permet de déterminer l’attitude de l’hélicoptère. Ce changement nous a permis de réduire de 2 éléments notre état.

Nous avons dans un premier temps implémenté le filtre sous Matlab. Voici quelques illustrations de nos avancées :

 

 

La courbe en rouge représente l’état prédit et la courbe bleue l’état mis à jour. Nous avons choisi d’accorder plus de confiance aux valeurs estimées par le filtre qu’aux mesures. Malgré un fort bruit, le filtre se comporte plutôt bien.

Mais encore pas mal de travail reste à faire notamment au niveau de la détermination des différentes constantes mises en jeu dans le filtre ou encore au niveau du testbench.