Site ELEC344/ELEC381

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

Catégories

J-23 La note du banc

Aujourd’hui j’ai compilé réussi à bien compiler mon code et à l’exécuter sur la carte de l’Heliokter en RAM et en Flash ( XIP ). J’ai pu débugger ma plateforme de bench ( quelques problèmes avec le timer m’ont ralenti, en effet il faut  déclencher un event quelconque pour que le Prescaler soit bien pris en compte ce qui m’avait échappé, et qui passe inaperçu avec de l’autoreload ).

Après quoi on a benchmarké rapidement avec FX quelques fonctions de math.h : float cos(float) versus double cos ( double ) , sqrt , addition , mulitplication de double. Ce qui lui permettra d’évaluer la vitesse de son filtre de Kalman et de décider entre float et double. Il a noté les résultats je lui laisse le soin de les donner, et on fera peut être un rapport plus poussé plus tard pour mémoire.

Pour l’exécution in place (XIP) j’ai pu faire des tests extensifs avec des traces issues des capteurs dans le simulateur ( 180 mesures environ ).  J’ai obtenu un temps d’exécution de 755 µs en moyenne environ. Ci-dessous un schéma résumant les résultats ( avec en axe des ordonnées les µs et en abscisse le numéro de la mesure ). Il y a quelques petites choses bizarres sur la fin, je pense que je dois changer ma méthode de mesure pour prendre en charge le changement de contexte avec une macro de FreeRTOS exprès , à vérfier, ce que je ne fais absolument pas pour l’instant et donc les mesures ne sont pas pures …

Nous avons aussi regardé avec FX quelques bugs qu’il y avait sur les changements de bases entre les données des capteurs, la sortie de wahba / Kalman et le monde réel.

Il faut toujours que je définisse des symboles dans mon code pour réussir à mettre en ram la partie du code à benchmarker et laisser en flash les jeux de test.

J-27 Host in translation

Alors comme je n’ai pas posté depuis 3 jours, voici un petit récapitulatif.

Jeudi : j’ai regardé un peu le code qu’avaient fait les autres et j’ai réfléchi à une architecture plus propre pour notre PID, plus facilement portable sur STM.

Vendredi : Comme j’avais tout bien dans la tête après avoir rêvé de PID, j’ai refait bien proprement et de façon bien modulaire le code de l’aservissement. Un point important et que j’ai bien fait attention à n’utiliser que les données des capteurs que l’on aura réellement, parce qu’avant, le temps d’établir le modèle d’asservissement, je considérai toutes les données que je voulais en « trichant » avec le simulateur ( position, vitesse, acclération, angle, vitesse, vitesse angulaire, accélération angulaire ). Cette première phase nous avait permis de bien mettre le doigt sur l’intérêt d’un double asservissement. Dans ce nouveau asservissement tout est doublement asservi en position et vitesse ce qui donne de jolis résultats.

Samedi : Auujourd’hui j’ai amélioré le code d’asservissement pour les angles, en particulier en faisant en sorte que la poussée des moteurs lors des inclinaisons continue à compenser la gravité. J’ai également réfléchi aux cas limites pour l’asservissement, quand il fallait le désactiver pour passer en mode « exceptionnel ».

Sur le simulateur j’ai ajouté quelques sorties et scripts gnuplot pour représenter de façon pratique la réponse de notre engin aux différentes commandes. Je pense que cela pourra être utlie lorsqu’on fera voler l’heliokter au début pour analyser les données de vol.

J’ai aussi commencé à regarder l’article sur Kalman pour bien rester en phase avec les autres. J’ai lu la documentation de Free RTOS. Normalement demain je vais essayer de compiler et benchmarker mon code sur le STM de carte de TP ( pour avoir une idée de ce qu’il donnera sur notre carte ) .

PuLSE, bilan de la journée

Ce matin j’ai essayé de faire marcher FreeRtos sur la carte. Après application du patch de Samuel ca a marché (merci Efix !). Cet après midi j’ai pu avancer beaucoup plus vite. Suite à un conseil de Samuel j’ai réimplémenté la tâche d’affichage des points d’une image pour l’intégrer complètement dans les interruptions (deux timers génèrent des interruptions l’un à 20kHz pour les points, l’autre à 25Hz pour les images). Avec en plus des fréquences facilement réglables.

Ca s’est bien terminé puisque nous avons correctement affiché la mire ILDA à 12kHz en A405. Sam a pris des photos et une vidéo. Je mets ca en ligne dans le courant du week end.

Avancé ILDA

Depuis cette après-midi après 3h de travail, je suis capable à partir d’un fichier ILDA de remplir un buffer avec l’image courante. J’ai choisi comme buffer une queue FreeRTOS.

Je prévois de travailler de passer à trois buffers et de faire la bibliothèque de formes ce week-end. Puis le passage sur carte début de la semaine prochaine une fois que Thibaut aurait implémenter les fonctions nécessaires à l’utilisation de la bibliothèque Lib FatFS.

Romain

ILDA

Cette après-midi j’ai codé le parsage de l’ILDA. J’arrive à lire un fichier ILDA et à mettre chaque point dans un buffer, en lisant les headers correctement (les utiles et en sautant les autres) ainsi qu’en gérant les fichiers ILDA aussi bien 2D que 3D. J’ai un peu galéré du fait que l’ILDA est en big endian et non pas en little endian et que le code de l’année dernière n’était pas modulé de la même façon que je souhaitais le faire (notamment à cause de leur format spécifique). Cela a du me prendre environ 4h.

Il me reste à choisir quel forme aura le buffer (une queue? FreeRTOS facilite beaucoup le travail) puis à le remplir avec une image. Je compte faire ca demain après-midi.

Sinon il faut que je re-fasse le diagramme de Gantt pour ce soir.

Romain

Carte IMU : Bilan de la journée de lundi

Comme le titre indique, hier je me suis attelé à jouer avec la carte inertielle. J’ai eu du mal à la booter, mais c’est chose faite.

Ensuite, je n’arrivais pas, tout comme FX, à faire tourner FreeRTOS qui se retrouvait piégé dans l’ADC Handler. Suite au patch de Sam qui modifie le crt0 high density de ST pour repositionner le début de la pile et éviter d’écraser notre propre code, j’ai réussi à utiliser FreeRTOS pour faire clignoter la LED de la carte. Ce n’est pas très impressionnant, mais c’est un premier pas.

Tout comme FX, je pense que je vais bosser sur le bluetooth. Ca me parait vraiment une bonne chose d’avoir un moyen de recevoir des messages pour le debug. Ensuite, il faudra faire fonctionner le bus SPI et l’accéléromètre qui s’y trouve.

TP et Gyromètre

TP: Le buzzer semble marcher. Le code du zigbee a été déjà fait en utilisant des queues de FreeRTOS et interruptions. Après, il faudra le tester.

Gyromètre: j’ai lu 3 articles:

  • Un capteur, du début du gyromètre MEMS, qui utilise piézorésistance, force de Coriolis et Lorentz (ici).
  • Pour mieux comprendre le principe physique des erreurs du gyromètre (ici).
  • Avec filtre de Kalman (ici)(malheureusement je n’ai pas bien compris, j’ai doit étudier le Kalman tout seul avant).

Avancement TP et PuLSE

Concernant le TP : Le lcd, le bouton poussoir et le buzzer fonctionnent : il ne me manque plus « que » le ZigBee.

Coté projet, je me suis lancé à la recherche d’une pile TCP/IP qui pourrait nous convenir (notamment uIP et lwIP recommandées par FreeRTOS) et dans la lecture de la datasheet du contrôleur Ethernet.

STM32 : en avant la musique !

Voici mes avancées du jour sur le TP :

  • Fin de gestion des interruptions sur les boutons : les deux boutons sont utilisés pour régler l’intensité du backlight du LCD ; le premier diminue l’intensité, le deuxième allume ou éteint le backlight
  • Buzzer : le buzzer est capable de buzzer (!) et de jouer de la musique ; dans un premier temps j’ai juste émis un son, puis une musique, puis j’ai développé un peu une API pour jouer de la musique plus « proprement »
  • Retour sur le LCD : je me suis aussi repenché sur le LCD en retravaillant un peu son API ; au départ je voulais utiliser une file (queue de FreeRTOS) mais j’ai assez vite abandonné sans plus creuser la question (heureusement pour moi, il semblerait que je devrait m’y remettre pour Zigbee !) ; au final, tout reste fait à base de sémaphores
  • Zigbee : j’ai fait la configuration initiale de l’UART et je l’ai réglée pour qu’une interruption soit levée lors de la réception de messages ; sauf que rien ne se passe donc il doit y avoir quelques problèmes… A suivre demain !

TP : Le bout du tunnel

Ce matin, j’ai commencé à rédiger ma partie de l’article sur le problème de Wahba, principalement l’algorithme TRIAD  il a fallu se remettre un peu à LaTeX …

Cette après-midi, j’ai résolu les quelques problèmes qu’il y avait sur mon ZigBee (il en reste peut-être du genre non-déterministes) et j’ai fait marcher les interruptions avec les boutons : un bouton permet de modifier l’intensité d’éclairage du backlight et l’autre active/désactive le buzzer (très utile pour ne pas embêter toute la salle !).

D’avoir fait le ZigBee hier m’a permis de pouvoir aider un peu les autres qui pouvaient eux m’aider sur le traitement des interruptions.

En fin d’après-midi, j’ai refait la partie qui gérait l’affichage sur le LCD en quelque chose de plus simple et plus modulaire qui a pas mal aéré mon ‘main.c’.

Donc ben je crois que ça clot à peu près le TP d’initiation, c’est bien chouette :p

En ce qui concerne le projet, on a fait un point de situation avec l’équipe pour faire un petit diagramme en blocs de nos composants logiciels et se répartir l’étude de ces blocs. Je ferais surement un petit schéma sur le wiki.