Site ELEC344/ELEC381

Partie interactive du site pédagogique ELEC344/ELEC381 de Télécom ParisTech (occurrence 2010).

Catégories

GLiP : Problème d'affichage

Lundi matin, j’ai commencé à réviser la routine d’affichage car de différents problèmes sont apparues quand on a testé la communication par IRDAs avec l’affichage. Cela est dû au fait que les 4 UARTS qui gèrent les IRDAs interrompent la tâche qui gère l’affichage. Comme résultat des petits points se voient dans les LEDS.

L’après midi, SAM à recommandé de refaire la routine de d’affichage en utilisant que l’interruption par le TIMER.

Hier soir, j’ai réussi à faire marcher le SPI en utilisant le module DMA.

Aujourd’hui (Mardi) je me suis dédié à continuer l’implémentation d’une nouvelle routine d’affichage. Par contre je suis seulement arrivé à montrer une ligne, mais pas une image complète correcte. Après d’avoir parlé avec SAM, une modification plus profonde dans ma façon de générer le PWM pour les LEDS semble d’être le problème.

Améliorations pour le code de Wheely

Cette nuit, Alexis nous a communiqué le fruit de ses recherches sur le filtrage. Sa conclusion : Le filtre complémentaire que nous utilisions est très bon une fois qu’on lui soustrait le drift, mesuré à l’aide d’un filtre de Kalman tournant en parallèle.

Avec l’aide du code fourni par Alexis, j’ai intégré le Kalman et la soustraction du drift. Le code d’Alexis m’a par ailleurs inspiré sur pas mal de points, en terme de propreté, donc j’en ai profité pour faire une bonne petite refonte du code de Wheely, avec des variables plus claires, et une API pratique et compréhensible.

Cet après midi nous avons testé le code. Après que nous ayons corrigé quelques coquilles, nous obtenons sans l’asservissement sur X des résultats plutôt satisfaisant. Le robot tient assez bien sur place, à condition que le léger offset sur l’angle soit bien réglé à la main. Mais il est assez stable, autour de 0.6°, désormais codé en dur.

Difficile pour l’instant de bien contrôler les effets d’un asservissement sur X lorsque nous l’introduisons.

Encore une victoire de canard !

Suite à mon dernier article j’ai tenté toutes sortes de manières de debug pour trouver d’où le petit problème venait. Je suis passé par l’implémentation d’un programme en C sur mon ordinateur pour tester le filtre sur un échelon pour comparer à ce que donnait MATLAB (pareil), tester l’échelon sur la carte logique, j’en passe et des meilleures.

Après de longues heures à m’arracher les cheveux, j’ai enfin réussi à corriger le code. Le problème venait de l’accéléromètre. La récupération des valeurs via SPI posait des soucis et désynchronisait le filtre. J’ai donc créé une tâche  spécifique qui se charge d’updater une variable locale au programme avec ce qu’elle récupère via SPI. Ca permet d’éviter de perturber le bon déroulement du filtrage.

Voici le résultat obtenu lors du benchmark. Cela correspond pile poil aux mouvements donné à la carte par le servomoteur. Et l’axe des ordonnées indique pile poil l’angle d’inclinaison de la carte en centièmes de degrés. C’est trop cool, et surtout, ça va permettre de bosser sur la suite en ayant une totale confiance dans les angles que l’on va manipuler.

Ping et dhcp...

…sont opérationnels.
Enfin réglés, les problèmes de SPI, de configuration du contrôleur, de sombres headers IP, de buffers qui ne se vident pas. Finie, la recherche de l’erreur jusque dans les profondes couches de la pile IP (enfin je l’espère)…
Place maintenant à la fructifiaction. Et pour cause, le protocole dhcp (configuration automatique de l’adresse IP) n’aura résisté qu’un après-midi à Xavier et moi-même.
Le comportement du contrôleur semble fiable et nous allons maintenant nous atteler à la communication du module Ethernet avec le module ILDA.

Affichage d’images dans GLiP

Je décrit mes activités et avances de hier 9 avril et aujoud’hui:

Hier, j’ai fini une premier version du code d’affichage (En fait j’ai pris les recommandations d’Alexis et Sam pour ajuster mon idée originale). Mon code utilise les interruptions par SPI (transmission) et Timer2 (mode counter). Ce dernier travaille à 8KHz, ce qui représente la fréquence de ligne des modules. Je suis arrivé à faire allumer une ligne de la matrice (ce qui signifie que ma configuration du SPI était bien), mais pas à faire marcher l’affichage dans le module complète (mauvaise configuration du Timer 2).

Aujourd’hui j’ai utilisé environ deux heures pour corriger la configuration du Timer 2, faire une test de couleurs (pour vérifier que la matrice montre les couleurs exactes que je voulais montrer) et créer une fonction qui actualise l’image que se montre dans la matrice.

Finalement le code  est capable maintenant de montrer une image fixe et grâce à la fonction d’actualisation, on pourra gérer aussi les animations. Il manque maintenant faire le lien entre le code de Micka (celle des animations) et le mien!

Heliokter : acquisition des gyros

Hier et aujourd’hui, je me suis centré sur l’acquisition des données des gyroscopes, à l’aide des ADC (contrairement à l’accéléromètre et aux magnétomètre qui possédaient une interface numérique SPI). J’ai eu un peu de mal hier après-midi pour faire marcher l’ADC puisqu’il fallait mettre le bit ‘enable’ de l’ADC deux fois à 1 : une fois pour ‘power up’ et l’autre pour activer réellement la conversion.
J’ai vu (et corrigé) ce problème hier soir ce qui m’a permis de reprendre aujourd’hui sur un bon pied et d’implémenter l’acquisition sur plusieurs canaux, avec la DMA.
J’ai essayé de faire une mise à l’echelle (avec un rapport VDD/nbre de bits et la sensibilité des gyroscopes) pour obtenir des valeurs en degrés par seconde mais je doute un peu de la méthode. Voilà une des courbes que j’obtient en prenant un point toutes les 20ms, et en faisant l’intégration en post-production (avec awk). Le mouvement que je fais faire à la carte est une rotation de 90° dans un sens puis dans l’autre (du plan horizontal au plan vertical, autour de l’axe Y).

Sur cette courbe, on voit que :

  • La forme est correcte (c’est déjà ça !)
  • Les valeurs non nulles des gyros au repos (je n’ai pas encore fait d’offset) entraine une grosse déviation de l’angle (15°  environ au bout des 2 secondes de test ici)
  • Ma fonction de mise à l’échelle n’est pas terrible, même en prenant en compte la déviation du gyro. C’est aussi peut être dû à l’intégration offline qui n’est faite que toutes les 20 ms du coup …
  • Ou alors c’est la calibration de l’ADC …
  • Peut-être aussi qu’on a aucune garantie du fait que  Vdd correspond à 4095 et Gnd à 0 une fois encodé sur l’ADC, même en calibrant tout ce qu’on veut …

Voilà sinon, c’est à la mode, j’ai fait un petit diagramme de Gant pour les deux semaines qui vont venir. Les noms indiqués sont les noms des responsables et bien sûr il y aura de la collaboration sur certaines tâches.

C’est assez flou sur la dernière semaine puisque ça dépend beaucoup de ce qu’on aura effectivement réussi.

Edit (00:36) :

J’ai implémenté le calcul de l’intégrale sur la carte. Pour le problème de la virgule fixe (qu’on ne peut pas résoudre avec la nouvelle norme de C avec les _Fract et _Accum, celle-ci n’etant pas porté pour nos architectures), j’ai pour le moment fait un bête scaling de 1000 et je représente mon nombre sur un long. C’est ce qui m’a paru le plus logique puisque je sample des valeurs entières sur un nombre entier de millisecondes. C’est peut être pas le plus malin en terme de bits mais ça a le mérite d’être simple . Et voilà la nouvelle courbe que j’obtiens, beaucoup plus satisfaisante (en post-traitement, j’ai juste recalé la valeur intégrée à 0 au début et divisé la valeur par 1000). Modulo le décalage, on atteint plus que 80°, sachant que je n’ai pas vraiment pris mon équerre pour faire le mouvement.

A ce propos, est-ce qu’on peut disposer à peu de frais d’un dispositif tournant à vitesse lente, constante et connue sur lequel on pourrait tester les gyroscopes précisément ?

Pulse : initialisations

Hier je me suis occupé des initialisations du Hardware, des leds et du port série. On a passé pas mal de temps à comprendre pourquoi rien ne marchait (un switch était mal placé). Je n’ai pas encore testé le port série, je fais ça demain.
J’ai aussi commencé l’initialisation de la carte SD. Je m’inspire beaucoup d’un exemple donné par ST.

08/04 : Bilan de la journée

Ce matin j’ai débugué l’initialisation des DAC, et des amplis. J’ai pu valider la sortie d’un signal dans les bonnes bornes (0-10V vers la carte K12N).
Cet après midi je me suis mis à coder la tâche de gestion de la carte K12N, qui regarde s’il y a une image à afficher, et qui l’affiche point par point. Il ne faut pas afficher les points trop vite : 50us par point minimum. Du coup j’ai initialisé un timer qui lève une interruption toutes les 50us. Visiblement le timer s’initialise correctement, puisque j’arrive à faire générer une PWM en lui mettant une sortie sur une patte non attribuée. En revanche les interruptions ne sont pas levées. Entre ca et un autre problème (un vTaskDelay entraine une hardfault) je n’ai pas pu terminer et passer des images sur l’écran de l’oscilloscope. J’essaierai de faire ca demain.

A part ca j’ai aidé Etienne en faisant la configuration du bus SPI nécessaire pour le controleur ethernet.

Au niveau du temps passé je dirais 2h30 ce matin et 6h cet aprem.

Les PCB de Pâques

Non, ils ne sont pas enc chocolat mais ils sont arrivés aujourd’hui (pour nous en tout cas et pour plusieurs autres groupes aussi je crois). Cette après-midi, nous avons d’ailleurs (entre autres) aidé Alexis à souder les composants

Voici une petite photo du joujou :


Ce soir, j’ai converti tout ce que j’avais fit sur l’IMU sur cette carte et ça c’est fait plutôt sans douleur puisqu’il suffisait de changer les affectations des pins (et encore, le Bluetooth etait branché au même endroit et il y avait juste une permutation entre les ports SPI pour l’accéléromètre et le magnétomètre). Modulo le magnéto-résistor vertical, non encore soudé sur la carte pour des raisons de fragilité,  on a donc  pour le moment les mêmes fonctionnalités que sur la carte IMU.

Pour ce qui est du Wahba, le résultat n’est toujours pas très probant mais Fernando m’a parlé d’un algorithme qui pourrait mieux nous aider que le TRIAD. Pourtant les valeurs de base semblent bonnes puisqu’avec le magnétometre seul, je détecte bien le lacet et avec l’accéléromètre seul je détecte bien le roulis/tangage. C’est la combinaison des deux (avec les noeuds au cerveau qui viennent avec, dès qu’on pense ordre des rotations dans l’espace) qui n’est pas au point.

Le fait de se voir tous les quatres après les vacances de Pâques a été aussi l’occasion de mettre tout le monde à jour, de fixer les tâches de chacun et de préparer la soutenance de demain.

IMU bluetooth et antibouncing sur carte TP

J’ai avancé sur deux points. Tout d’abord sur le bouncing avec les boutons. En effet, sans prendre de précaution, un appui sur un bouton déclenche plusieurs interruptions en général, car il y a bouncing au niveau électrique. Pour palier à cela, je ne considère par bouton poussoir qu’au maximum une interruption chaque 100ms.

En ce qui concerne la carte IMU, suite à l’aide d’Alexis, la discussion en bluetooth se fait très bien et dans les deux sens. Voici la méthode utilisée sous linux, pour mémoire (ou pour F-X :p)  :

  • hcitool scan
  • sudo rfcomm connect /dev/rfcomm0 00:0B:CE:03:8C:B5
  • minicom ou bien un bête cat /dev/rfcomm0 pour la lecture

Désormais, je vais bosser sur l’ADC avec la carte de TP et le potentiomètre qu’Alexis vient d’y attacher. Pendant ce temps, Daniel à récupéré la carte IMU pour jouer avec l’accéléromètre et le bus SPI.