Site ELEC344/ELEC381

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

Catégories

Pulse, état d’avancement actuel

Actuellement le serveur web (http://137.194.66.145) est à peu près opérationnel. Il reste un problème de fuite de mémoire à résoudre (sachant que j’ai trouvé les objets qui génèrent la fuite de mémoire). Il délivre pour le moment une page html simple avec un petit formulaire en GET. J’ai adapté aujourd’hui un parseur de requêtes HTTP qui marche depuis le début d’après midi. J’ai passé le reste du temps à tester le serveur et à essayer de comprendre les résultats sortis par l’ensemble (parseur + serveur web + protocole HTTP (sur lequel je ne suis encore pas au point (désolé Samuel, mais je comprends pas les choses du premier coup, il faut un peu de temps pour que ca se mette en place (j’aime faire des parenthèses imbriquées)))). Pendant les vacances j’avais commencé à faire la page web de configuration, je la continuerai cette semaine quand le serveur sera plus fiable.

Du coté de la carte SD on a été assez décu ce matin puisqu’après un formattage, la carte ne répondait plus. Cet après midi, après un retour en arrière sur le code, ca a remarché avec les erreurs qu’on avait avant. On arrive à lire dans un fichier, mais pas encore à y écrire. Etienne et Thibaut s’y mettent ce soir et demain sur la base du boulot de Thibaut. C’est clairement le point critique du projet, puisque sans carte SD, pas de vidéo.

Etienne a commencé à se plonger dans un algorithme de détection de beat en se basant sur ce que j’avais fait avec les ADC pendant les vacances.

Je n’ai pas autant suivi le travail de Romain (en particulier son avancement cet après midi), donc je vais poster une version un peu en retard. Le script qui génère un fichier ILDA contenant du texte marche. Il affiche une cinquantaine de caractères dans une image, sur plusieurs lignes. Il reste à gérer le défilement et les espacements. Il a commencé le programme de configuration qui permettra entre autre de twitter. Pour plus de précisions, il faut se référer à ses posts :)

vacances de printemps

Depuis que nous ne sommes plus bloquées à cause des bibliothèques ST, on a pu avancer.

Cette semaine j’ai fait :

-          L’ADC fonctionne dans le mode non continu ;

-          J’ai amélioré l’interface pour control du serpent en utilisant la carte du TP ;

-          J’ai modifié l’interface écrit en python du bootloader/contrôleur de l’année dernière, et on peut l’utiliser pour contrôler notre serpent.



J-22

Alors comme ça fait plusieurs jours que je n’ai pas mis à jour voici ce que j’ai fait durant les derniers jours :

Jeudi 15

J’ai amélioré mon code de benchmark, voici des résultats plus extensifs sur les opérations :

.

.

Math timings double Timing ( µs ) Cycles

.

offset add mul div cos sin abs sqrt abs

.

offset 14492 14.492 1043.424

.

add 28827 28.827 2075.544

.

mul 28823 28.823 2075.256

.

div 28826 28.826 2075.472

.

cos 14464 14.464 1041.408

.

sin 14487 14.487 1043.064

.

offset abs 14463 14.463 1041.336

.

sqrt(abs()) 41676 41.676 3000.672

.

Math timings floats

.

offset add mul div cos sin abs sqrt abs

.

offset 14501 14.501 1044.072

.

add 28826 28.826 2075.472

.

mul 28855 28.855 2077.56

.

div 28855 28.855 2077.56

.

cos 14473 14.473 1042.056

.

sin 14492 14.492 1043.424

.

offset abs 14501 14.501 1044.072

.

sqrt(abs()) 42032 42.032 3026.304

Je ne suis pas vraiment satisfait car les résultats ne me semblent pas vraiment cohérents, mais peut être est-ce à cause de l’influence de divers paramètres pas controlés : cache, optimisation, autre.

Explication de la méthode : le temps à gauche représente le temps d’exécution pour 1000 opérations en µs.
offset : temps d’exécution d’une fonction pour avoir une nombre alétatoire double ou float( mul, add, modulo, sauvegarde dans une variable double ou float static ), fonction appelée myrandd() ou myrandf()
add/mul/div : 2 appels à myrand, 2 cast int->float ou double, addition/mulitplication/division des deux nombres et sauvegarde dans une variable float/double.
cos/sin : 1 appel à myrand(), 1 cast, 1 sauvegarde
offset abs : 1 appel à abs( myrand( ) ) 1 cast et 1 sauvegarde
sqrt : 1 appel à sqrt(abs(myrand( ))) 1 cast et 1 sauvegarde

Le problème est que l’on ne peut pas vraiment soustraire l’offset des opérations … car le temps d’exécution n’est pas vraiment linéaire. Un autre point qui m’étonne est le nombre de cycles qu’il faut pour faire une simple addition …

Bref je vous donne les résultats as is, car j’ai du mal à les interpréter. On retiendra qu’une opération arithmétique sur un double ou un float est du même ordre de grandeur : quelques dizaines de µs.

Vendredi 16

J’ai écrit le code pour les télémètres, ce qui était assez rapide puisque j’ai juste eu à m’intégrer dans le code de FX pour les gyros. Mais comme les télémètres étaient bloqués au Royaume Uni à cause de l’arrêt du traffic aérien, une fois mon code fini, j’en ai profité pour me mettre à jour sur le code qu’avaient écrit les autres.

J’ai aussi commencé à nettoyer mon code et à agencé un peu l’architecture globale du code.

Samedi , Dimanche, Lundi 19

Vacances

Mardi 20

Retour en A405 par une magnifique journée de printemps. Aujourd’hui j’ai écrit le squelette de notre version propre alpha pour l’heliokter avec des prises de sémaphore bien claires, des delays là où il faut et une beau découpage en fichier pour la compilation séparée. Ca m’a pris un peu de temps dans le sens où j’ai du lire le code un peu de tout le monde et réfléchir à comment wrapper les fonctions de chacun pour ne pas avoir à réécrire trop de choses.

Ensuite comme les télémètres étaient arrivés, j’ai pu vérifier mon code, qui marchait du premier coup ! ( merci FX ) ensuite j’ai pu étalonner le télémètre et maintenant je récupère une distance en cm. Celle-ci est bonne pour une distance entre 8cm et 70 cm environ ( comme nous n’avions qu’une règle de 30 cm ( merci Flavia ) , les mesures au delà de 30 cm n’étaient pas très précises).

La méthode pour étalonner : regarder la valeur en « int12″ renvoyée par l’ADC à 8 cm, celle renvoyée à 30 cm, regarder la courbe sur la datasheet qui ressemble fortement à a/x+b, ensuite trouver a et b à partir de ces deux points. Ci dessous le résultat sous forme de courbe ( axes : distance en cm )

  • En rouge : y=x
  • En vert : y= f(x) où f est la fonction d’interpolation. Dans l’idéal elle devrait donner l’identité.

C’est assez satisfaisant !

Mercredi 21

Aujourd’hui on a réussi à avoir une version « sale » mais complète du code qui compile ( c’est à dire senseurs, filtrage, asservissement et moteurs ).

On a ensuite fait un vol d’essai pour faire une acquisition et un test du filtre de Kalman depuis notre propre carte. Ce qu’on a constaté dans ce premier vol et qui m’inquiète un peu c’est que les angles mis en jeu pour le roll et le pitch sont très faibles, je me demande aussi l’amplitude des valeurs utilisées par les moteurs ( +- 3 sur un unsigned char ou bien +- 100 ? ).

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 ?

08/04 après midi

Aujourd’hui j’ai travaillé un peu plus sur l’ADC, mais il continue à ne pas marcher…

J’ai inclus les ids dans la communication par le CAN. J’ai crée 2 filtres pour cella, les messages envoiés directement à une vertèbres sont dans la FIFO0, les messages envoiés à tous dans la FIFO1.

Quand le gyro est phare

Mardi, j’ai travaillé sur le gyroscope. J’ai réussi à obtenir de bons relevés de valeur, notamment en intégrant pour obtenir l’inclinaison de la carte. Cependant, il y a une dérive, normal. J’ai donc implémenté  un filtre que Fabien a conçu, mais je fais face à des bugs mystérieux.

Je continue d’y travailler. Par ailleurs, nous avons préparé la soutenance de ce matin !

J – 31 : Welcome to the Matrix

Le code du simulateur a bien avancé, maintenant le double asservissement en altitude marche impeccablement.
De plus le simulateur peut maintenant sortir des « courbes » pour des paramètres choisis qui peuvent être affichées avec gnuplot (plot « nom du fichier »), c’est notamment comme ça que j’ai pu trouver plus rapidement les paramètres pour le PID et mettre le doigt sur certains bugs vicieux qui m’avaient bloqué pendant quelques centaines de minutes.
Petit avant goût ci-dessous :
Nous avons aussi discuté sur la façon dont nous nous répartissions les tâches d’ici samedi. Pour ma part je continue à améliorer l’asservissement (notamment en angle) et il faut que je demande à Alexis si il existe une façon de brancher un de nos télémètres sur une carte de TP pour adapter le code de l’ADC au périphérique en question.
Il faut également commencer à traduire le code d’asservissement en virgule fixe et inclure le modèle de réponse des moteurs dans le simulateur ( linéaire pour l’instant )

tp + projet (longtemps depuis le dernier post...)

30/03 jusqu’au 01/04 – projet et tp

30/03 matin : lecture du datasheet pour l’écriture de la configuration du CAN + écriture de la configuration du CAN. Problème pour compiler/linker le code écrit en utilisant la bibliothèque ST.

31/03 matin et après midi : j’ai travaillé pour trouver la solution du problème avec la bibliothèque ST. Pas beaucoup avancé ce jour là. J’ai aussi revu le code du tp.

01/04 après midi : lecture du datasheet pour l’écriture de la configuration de l’ADC + écriture de la configuration de l’ADC.

02/04 – communication challenge

06/04 – projet

J’ai travaillé sur le CAN et sur l’ADC. Apparemment l’ADC marche, mais les valeurs n’ont aucun rapport avec la position du potentiomètre. Pour le CAN, si j’active les interruptions, la carte se bloque.

Just easy as ADC

Bon, désolé pour ce jeu de mot loufoque. Tout ça pour dire que aujourd’hui j’ai continué à travailler sur les ADC. Après une première approche rapide non fructueuse, j’ai attentivement lu l’insider guide et la release note de ST sur les ADC. Ca m’a permis d’y voir plus clair.

Dans le cas de Wheely, vu qu’on veut décharger au maximum le CPU et avoir des mesures les plus à jour possible, le mieux est d’utiliser le continuous mode sur le regular group associé à un DMA qui va bien. Une fois cette configuration lancée, plus rien à gérer, et il suffit d’accéder à la zone de RAM visée par le DMA, lorsque l’on veut relever une valeur.

C’est donc ce que j’ai mis en oeuvre, et vérifié au potentiomètre.

J’ai ensuite récupéré une carte inertielle pour appliquer ça au gyroscope IDG500. Je n’ai pas réussi à recevoir de valeur non nulles. Affaire à suivre ;)

Wheely – accéléromètre

Je me suis penché sur l’accéléromètre de la carte IMU (LIS3LV02DL : le même que celui de notre projet).
Cet accéléromètre possède un circuit intégré qui gère entre autre la conversion analogique numérique. (Il nous faudra néanmoins implémenter l’ADC pour le gyroscope, et Arnaud s’en occupe actuellement).

Pour le moment j’ai fais l’initialisation, la routine d’interruption, une fonction pour lire et écrire dans les registres du circuit intégré de l’accéléromètre, ainsi qu’une fonction qui récupère les données suivant l’axe X. (Nous n’aurons pas besoin des axes Y et Z pour le projet). Je n’ai pas encore des résultats satisfaisants, mais je continue demain matin.