Site ELEC344/ELEC381

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

Catégories

Serpentina : jeudi et vendredi

Jeudi et vendredi derniers, moi et Flavia, on a travaillé sur la communication can de la carte du serpent (entre deux cartes du Tp, le can marchait bien). On ne savait pas la raison (on pensait aux interruptions), mais toujours il y avait quelque chose qui bloquait son exécution. Peu à peu, on a trouvé des morceux de code qui ne nous posaient pas de problème et enfin on a fini par bien transmettre des trames. Juste l’interruption pour la transmission ne marche pas mais on peu envoyer des données quand même.

Ensuite, on s’est lancé à la réception des trames can. Toujours, quand on activait toutes nos tâches, la carte se bloquait. Donc, on a essaie d’utiliser juste une tâche de réception. Après mettre beaucoup de temps pour bien configurer notre carte du Tp et faire des tests, la réception a bien marché avec des interruptions et des masques.

Pendant cette recherche des solutions pour la communication can, on a trouvé un autre problème (peut-être celui qui nous posait des problèmes pour le can) qui ne nous semble pas être simple : on est limité à lancer juste trois ou quatre tâches maximum (cela dépend de ce qu’on configure/initialise). On ne connait pas la raison (on a parlé à Sam, mais il ne le sait pas non plus), et on est maintenant bloqué dans cette partie.

J’ai essayé d’utiliser le code de l’année dernière (juste la configuration des clocks et des leds pour savoir si la carte se bloque ou pas) avec notre bibliothèque STM32 et notre linker, et le blocage continue.

Demain, je continue à chercher une solution pour ce blocage.

GLIP : Programme d’affichage et soudage de cartes

Lundi 12 :

J’ai passé la matin dans le nettoyage du code et j’ai commencé avec la modification de la premier version du programme pour l’affichage d’animations, le travail avec une table de couleurs et la reconnaissance du format envoyé par le programme de Micka (gif2glip). Mon travail dans cette étape a été plutôt de conception (comment allait se comporter le programme).

Étant donné que je ne connait pas python, j’ai passé l’après midi en train de me documenter. Avec l’utilisation d’un éditeur hexadécimal, j’ai pu voir les octets qui conforment le fichier GLIP. Cependant, comme dans cette étape du projet la copie des octets qui conformaient la table de couleurs, les images à montrer, etc; allait être fait directement dans le code à programmer dans le STM32, à la main, j’ai considéré que cela serait mieux de les avoir dans un fichier de type .txt. De cette façon, vers la fin de la journée, et avec l’aide du programme de Julie (une petite explication de Julie inclut), j’ai créé un programme qui me permettait voir en code ascii les octets envoyés.

Mardi 13 :

La matin, j’ai finalisé avec l’implémentation du code de la premier version du programme d’affichage avec une table de couleurs.

L’après midi j’ai parlé avec SAM pour qu’il m’aide avec quelques doutes que j’avais, mais il m’a fait noter que ma solution d’affichage était trop compliqué (beaucoup de pontiers, pas de sémaphores, etc) et il m’a expliqué de manière général l’idée de fonctionnement de son propre programme de test. Alors, j’ai passé l’après midi dans la création d’un deuxième version du programme d’affichage. Mon idée était d’intégrer dans le comportement certains aspects de la premier version du programme. Vers la fin de la journée j’ai eu cette deuxième version finalisé (affichage d’images statiques et dynamiques, sans table de couleurs).

Mercredi 14:

Je suis passé la toute la journée (littéralement) avec Alexis, Florent, Micka et Julie en train de souder les nouvelles cartes GLIP.

Vers 20h j’ai crée un programme qui permettait tester les LEDS des nouvelles cartes. Moins d’une heure après la deuxième version du programme, avec l’inclusion d’une table de couleurs était finalisé: Une animation à été créé pour tester que cette version marche correctement.

J-24 Le fichier de fabrication

Aujourd’hui j’ai organisé mon code de PID pour qu’il puisse compiler sur la carte de TP, j’ai écrit une petite fonction pour mesurer le temps avec le timer 1, j’ai mis en place le test de la vitesse d’exécution de mon code et je me suis un peu débattu pour réussir à compiler tout ça.

Je ne comprends pas encore le Makefile de Sam en entier, mais ça avance par petits bouts, j’ai encore quelques problèmes parce que mes fichiers sources ne sont pas tous dans le même dossier et que le Makefile à parfois du mal à trouver les objets générés ( il faut que je relise le cours sur les Makefile … ).  J’ai aussi eu besoin d’un peu d’aide pour comprendre que le mode de compilation c99 était à la source problèmes avec la libmath.

Comme mon programme ne tient pas dans la RAM, demain il va falloir que je modifie le linkscript et que je charge une partie du programme en Flash, ce qui me permettra de tester l’asservissement sur la carte et de tenir mes délais j’espère :-)

Résumé des jours précédents

Celà fait quelques temps que je n’ai pas posté, je vais donc résumer ce que j’ai fait ces derniers jours :

  • Vendredi : j’ai testé (toujours avec le simulateur en python à base de threads, queues, etc…) les derniers algorithmes pour l’initialisation de GLiP (choix de l’orientation, …) ; j’ai commencé à intégrer les différents algos, qui étaient testés indépendamment, dans un simulateur « global » pour voir les éventuels problèmes de transition entre les différentes étapes (temps d’attente, critère de passage à l’étape suivante)
  • Lundi : j’ai continué et fini la simulation globale, j’ai réfléchi à une façon de détecter les « faux voisins » (blocs séparés d’un vide, qui captent leurs signaux réciproques, cf post de Julie) mais ma solution n’a pas été retenue au final !…
  • Mardi : j’ai implémenté en C les mêmes algorithmes afin de les mettre sur les cartes mais de nombreuses questions sont encore en suspens (API pour l’envoi/réception de messages IrDA notamment)… Je me suis aussi renseigné sur la façon de générer un ID unique pour les blocs sans avoir à les programmer un par un : Alexis avait évoqué un identifiant unique pour chaque STM32 (décrit section 28.2 du manuel de référence) que j’ai essayé d’exploiter sur ma carte de TP. Ce fut un échec puisque je n’ai réussi à lire que des « 1″ dans le registre concerné. Après quelques recherches, je suis tombé sur ce post sur le forum de ST qui explique que seuls les micro-contrôleurs produits après 2008 exploitent ce registre. Sans être sur de moi, je pense avoir lu sur le chip que les notres ont été produits en 2009 donc on devrait pouvoir accéder à cet ID… À confirmer et, le cas échéant, ça serait une bonne façon de déterminer les ID de chaque bloc GLiP.

IrDA fonctionnel !

Aujourd’hui je me suis attaqué à la configuration de l’IrDA. Après quelques déboires avec le port série de debug, l’IrDA fonctionne très bien à la vitesse maximale supportée par les LEDs infrarouges : 115,2Kbps. Le transfert s’effectue très bien et on s’est aperçu que l’angle d’ouverture du signal transmis est assez faible et donc peut-être qu’on n’aura pas besoin de mettre des caches …

Le transfert de paquet est juste à adapter à l’IrDA donc d’ici demain cela devrait fonctionner correctement.

J’ai fini par rechercher une manière de calculer le CRC16 d’un paquet et j’ai trouvé une bibliothèque qui le calcule et que je pourrais implémenter au stm32.

Premier test du usart GLip

Hier soir (Dimanche 11) j’ai fait un petit test sur les périphériques de communication de la carte de LEDS.

J’ai ajouté à mon programme d’affichage une routine d’interruption par uart 3 (et après pour le uart 1 et 4 aussi), pour qu’il change l’image montré à chaque fois que le module recevait quelque chose dans le porte serial: J’envoyais un caractère depuis une porte et le recevait par une autre (en utilisant une feuille blanche), et après j’envoyai et recevait dans le même porte en utilisant un miroir. Dans le deux cas, il à commencé à interrompe correctement.

Par contre quand j’ai voulu ajouter une condition et voir si effectivement je recevait  ce que j’envoyais, je trouvé qu’il y avait un problème.

En utilisant un multimètre je constaté que le PIN de réception du STM32 était toujours à zéro. Je n’ai pas continué avec le test parce que j’ai pensé qu’il serait mieux de voir qu’est-ce qui se passait avec un oscilloscope.

Mes routines d’affichage d’une image, et ceux du test ont était ajoutés au dépôt du groupe.

Bilan du week end

Ce week end j’ai principalement aidé Etienne à faire marcher la pile lwip. Actuellement on a une implémentation pour le stm32, mais on n’arrive pas encore à la faire compiler (c’est une sacré usine à gaz car les différentes versions ne sont pas rétro-compatibles, et on a adapté du code fait pour une ancienne version à une version récente de lwip). On a quand même pas mal progressé, et on espère que demain matin on aura un résultat. Pour plus de détails (notemment techniques :) ) Etienne est mieux placé que moi pour en parler.

J’ai aussi cherché différents serveurs webs embarqués pour le stm32. Après quelques faux pas hier j’ai trouvé un serveur : miniweb, et Etienne en a un autre. On verra lequel des deux on choisit, ce sera probablement le sien qui est écrit pour lwip.

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 ) .

Algorithme sur le STM32

Jusqu’à hier, je faisais des simulations de l’algorithme sur mon ordinateur, pour évaluer si les positions encontrées à partir des calculs mappeaient le serpent dans une sinusoïde.

Aujourd’hui, j’ai ajouté ce code dans le code de la carte du TP pour faire la même simulation, mais sur le STM32. J’ai dû changer quelques details, surtout par rapport à la déclaration des constantes, mais à la fin, apparament les calculs en virgule fixe sont bien faits.

Ensuite, j’ai commencé à regarder la configuration du timer pour avoir une sortie PWM et à penser au déroulement de la tâche de contrôle du moteur principal (qui tourne up/down) d’une vertèbre : une queue blocke la tâche jusqu’à l’instant où la vertèbre reçoit sa position x0 calculée par la vertèbre précedente. Ensuite, elle calcule le prochain point (x1), et envoie ce résultat à celle d’après. Les calculs de l’angle et du pulse de sortie sont faits et le moteur est mis en marche.

IrDA

Aujourd’hui j’ai continué à coder la configuration du stm32 pour utiliser l’USART1 en mode irda et tester les communications entre deux cartes de TPs.

J’ai de plus commencé mes recherches sur le CRC16 pour calculer le checksum des paquets à transmettre.