ELECINF344/381

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

Catégories

MB Led: Working IrDA and colored LEDs.

Algorithm on GLiP block:

Today Guillaume has worked with 9 GLiP blocks, trying our algorithm in order to elect the leader among the network and give positions to each block. He succeed in this when the network is slowly increasing but when all the blocks come in a random way, it is still difficult to have a consistent network. There is still no acknowledge with the IrDA and when some packet is corrupted, the algorithm fails. We have to fix this soon.

IrDA:

Cédric has resolved his problem with UART4&5 for emitting packet. After some tests with Alexis, he found a good value for the resistance(4.7KOhms) to control emission power so that the blocks would communicate only to the neighbors. All potentiometers will be replaced by classical resistances.

LED matrix:

Now I can drive the LED matrix using the new driver TLC5951. I can display a 8×8 pixel on the matrix but I have to fix some problems of intensity. We knew that blue is more powerful than red and green and we try to avoid this problem. For the moment, we can’t obtain a perfect white but I’m in a good way to fix this problem.

 

RoseWheel : CAN & Kalman

Today, we finished and/or improved some of the micro tasks we assigned to each other at the beginning of this week.

We tested a lighter version of the Kalman Filter that will be used in RoseWheel on the testbench we made a few weeks earlier. We used a light version because the full one needed to know the state equations of the system to be accurate. As we didn’t want to loose time trying to find out the state equations of the testbench (even if they are really similar to the ones of RoseWheel), we decided to test a version that was only able to track the drift of the gyroscope and make some minor corrections on the signal from the accelerometer during x axis translation. The light Kalman filter worked well and did what we expected, he tracked the drift and thus corrected the gyroscope noise and also filtered the signal from the accelerometer thanks to the sensor fusion.

During the experiments, we could observe that the noise from both the accelerometer and the gyroscope weren’t as high as we expected, that is a good news. However, even if the drift problem is correct by the Kalman filter, the measurements from the accelerometer are still not accurate during movements because of the noise induced by the other accelerations components. These other acceleration components are only dependents on the angle and its derivatives. We thought of a way to subtract those noisy components at each step by using the estimation of this values at the previous step. We will test it tomorrow on the testbench if we have time to do it.

We also finished the implementation of the CAN drivers and we tested it on our laboratory boards as we didn’t receive yet our mainboard. The tests were satisfaying. But as at the time we performed the tests we hadn’t decided yet the final version of the CAN protocol we were going to use for the communication between our 3 board (mainboard, sensorboard, HI board ), we didn’t use any filters. Hopefully tomorrow we will be able to test the CAN protocol as we will receive our mainboard.

 

MB Led : First test with MB Led blocks

Yesterday, Alexis gave us 3 MB Led so that we could check the IrDA of the blocks. So far, Cédric achieved to communicate through UART 2 and 3 without any problem. For UART 4 and 5, he encountered problems to receive messages due to missing characters in the UART data register.

Benjamin started to check the  LED driver so that we could light the MB Leds soon.

Both of them used the oscilloscope to understand signals from the component.

Meanwhile, I fixed some bugs in the algorithm and my tests were successful on the GLiP blocks. Thoses blocks can only communicate through UART 2 & 3 so my job is now to test the algorithm on fully operating GLiP blocks (with their 4 IrDA transceivers), waiting for Cédric to test on our MB Led blocks. It seems that FreeRTOS scheduler is blocked when I tried to launch 16 tasks at once. I would try to fix this without reducing the numbers of tasks, cause each one is important…

RoseWheel : préambules de propulsion

Pour contrôler nos moteurs correctement, nous avons dû estimer la fréquence minimale de la PWM qu’on leur fournira.

En effet, les hautes fréquences sont à éviter pour des raisons de consommation mais une trop basse fréquence provoquerait une rotation saccadée des moteurs.

Nous avons donc utilisé la relation suivante pour notre estimation :

Fmin = R / [ -2 . L . ln (1 - P / 100) ] (source : cliquer ici)

 

Nous avions déjà une estimation de la résistance interne R ≈ 0,6 Ω mais nous n’avons pas été en mesure de trouver de datasheet spécifiant L, l’inductance propre de notre moteur.

Nous avons donc décidé de mesurer L de façon expérimentale en utilisant le matériel des salles de TP d’électronique analogique (merci Chadi!) :

Mesure de l'inductance de notre moteur

Mesure de l'inductance de notre moteur

 

Le principe est assez simple, si on modélise un moteur comme une bobine et une résistance en série, on a l’égalité suivante :

tan(φ) = ω . L / R

=> Avec un déphasage de φ = 45°:

L = R / ω (avec ω = 2 . π . f)

 

Nous avons effectués plusieurs mesures car nous étions à des fréquences assez élevées et le bruit était assez important donc il était difficile d’obtenir précisément 45°.

Voici ce que l’on obtient avec la dernière mesure :

f = 14,3 MHz (fréquence avec un déphasage de 45°)

R = 10 kΩ (résistance utilisée pour observer le courant, on néglige la résistance interne)

 

=> Nous obtenons donc une inductance de:

L = 10 000 / ( 2 * π * 14 300 000) ≈ 0,1 mH

 

Il nous reste donc à estimer en précision le pourcentage de stabilité P, qui parait avoisiner raisonnablement les 5% d’après le site évoquée précédemment.

Ça implique une PWM à une fréquence en dessous de 10 KHz, donc audible mais ça ne pose pas de problème à priori.

Nous ferons de vrai tests sur notre carte très bientôt puisque quelques composants sont encore en cours de route mais ils devraient arriver dans la semaine si tout va bien.

…à suivre…

MB Led : Avancées du début des vacances.

Actuellement, je m’occupe de fusionner mon code d’algorithmie avec le code de Cédric concernant l’IrDA. Nous avions quelques différences sur des fonctions d’envoi et de réception de données. J’ai du réécrire certaines fonctions pour que cela marche. Désormais, nous testons les résultats en utilisant la sonde JTAG qui nous pose certains problèmes (hier, on a passé pas mal de temps à ressouder des fils qui s’étaient déssoudés).

L’IrDA est désormais fonctionnel avec des envois à haute vitesse. Cédric a utilisé un ordonnanceur pour gérer cela. En attendant, j’ai réfléchi à une façon de détecter qu’un bloc a tourné. Les tests avec FreeRTOS et zmq sont concluants et il faut juste l’appliquer au code avec IrDA.

Hier, Alexis avec l’aide de Benjamin a soudé un bon nombre des MBLeds. Nous espérons les avoir bientôt pour que Benjamin puisse tester son code sur le driver LED. Benjamin a aussi réfléchi à deux jeux que nous voudrions implanter : un morpion et un snake. Il attend que la fusion soit finie pour tester cela.

Copterix : on passe entièrement sur la Gumstix !

Aujourd’hui, avec Bertrand, puis rejoins par Samuel et Axel, nous nous sommes concentrés sur la communication Gumstix/STM32. Nous avons enfin réussi à connecter comme nous le voulions les deux cartes.

Nous avons d’abord dû activer le GPIO 10, le pin correspondant n’étant pas configuré par défaut en tant que GPIO. Nous avons donc choisi de le configurer à chaque démarrage par l’intermédiaire d’un script shell, exécuté automatiquement, réalisant l’accès en mémoire nécessaire à la configuration, à l’aide de l’utilitaire memdev2.

Après avoir débugué notre carte à l’oscilloscope, et résolu un problème de soudure, nous avons donc enfin pu communiquer entre nos deux cartes. Les premiers essais ne furent malheureusement pas très fructueux : alors que les échanges de paquets se faisaient sans soucis entre PC et carte de TP STM32, avec le même protocole, nous avons à présent plus de 10% de perte de paquets (parfois 25%), et surtout, de longs moments (se décomptant en secondes) qui s’écoulent avec presqu’aucun paquet de valide. Les cartes sont donc inutilisables dans ces conditions.

Après analyse des données échangées, il semblerait que de nombreux octets ne sont pas reçus par la Gumstix, ceux-ci se perdant, à un niveau qu’il nous reste encore à déterminer. Exemple : sur des paquets qui devraient être de 21 octets, nous avons parfois observé plus de la moitié des octets perdus. Et ce, malgré le fait que nous avons redescendu la vitesse de l’UART à 115200 bps.

Les différentes pistes que nous avons à explorer demain, pour essayer de résoudre ce problème, sont les suivantes:

- Alexis nous a suggéré d’essayer de modifier le préscalaire de l’horloge concernée. Les quartzs n’étant pas forcément très fiables, il se peut que le souci vienne d’une vitesse de communication approximative, qu’on pourrait essayer de compenser de cette manière.
- Axel m’a suggéré de modifier légèrement le protocole. En effet, si on perd un octet, on perd au minimum deux paquets. Je rappelle le protocole :
On envoie un octet de start : 0xfe. Puis un octet identifiant le paquet : 0x4b. Ensuite on lit le nombre d’octets correspondant. Si on perd un octet, on va déborder sur le paquet suivant dans la lecture, et on ne le lira donc pas non plus. La solution proposée par Axel serait d’enregistrer la position de tout octet 0xfe croisé dans le contenu d’un paquet, et si le paquet est invalide, revenir à cette position pour « récupérer » ce paquet. Toutefois cela ne résoudra pas le problème, il s’agit juste de perdre moins de données à cause du protocole.

 

D’autre part, nous allons abandonner l’altimètre. Il semblerait que celui-ci soit trop peu précis, et trop complexe à utiliser. Nous allons donc plutôt faire des tests avec un détecteur à ultrasons ou un sharp, pour voir si nous obtenons quelque chose de plus satisfaisant.

Nous avons également été chercher l’hélicoptère, afin de pouvoir tester les commandes des moteurs très bientôt.

RoseWheel : à pleine vitesse

Voici un compte rendu des avancées que nous avons fait pour la démonstration de vendredi et pendant le weekend :

Carte capteurs

Côté accéléromètre, nous avons réussi à communiquer proprement avec accéléromètre en utilisant une interruption externe liée au signal RDY ; cela nous a permis plusieurs démonstrations intéressantes : contrôle d’une LED suivant l’angle, envoi des valeurs mesurées par le port série, affichage de l’angle mesurée avec Matlab.

Pour le gyroscope, nous avons eu plus de difficultés, notamment pour bien gérer l’implémentation du protocole I2C dans le STM32. Après quelques heures de debug, nous sommes arrivés à une implémentation minimale du driver pour la démonstration, les données lues étant transmises par le port série et affichées dans le même graphique que celles en provenance de l’accéléromètre ; cependant, le capteur parfois s’arrêtait sans explication.

Dans un premier temps, nous avions attribué ce problème à des micro-coupures d’alimentation. Néanmoins, nous ne sommes toujours pas satisfaits de cette explication, puisque une telle fragilité n’est pas désirable pour une partie si vitale de notre projet ; alors, nous avons travaillé sur le code pendant le weekend pour essayer de trouver la source des instabilités, mais nous n’avons pas encore trouvé la réponse. À suivre donc…

Filtre de Kalman

Nous avons implémenté en C notre filtre de Kalman dans la journée du vendredi. Afin de procéder aux tests « définitifs », nous attendons d’avoir des drivers plus fiables pour le gyroscope et la partie mécanique monté, étant donné qu’il est indispensable de tester le filtre dans les conditions prévues sur le système pour lequel il a été conçu.

Entre-temps, nous envisageons d’utiliser une version un peu modifié qui ne traquerait que la dérive du gyroscope sur notre banc de test. Pendant la démonstration, nous avons montré nos performances en simulation, dont nous avions parlé dans notre dernier post.

Banc de test

Nous avons également montré au jury le fonctionnement de notre banc de test, notamment le graphique de variation d’angle et de vitesse angulaire, que nous avons détaillé dans des posts précédents.

CAN

Nous avons aussi avancé sur le bus CAN, et nous pensons à le tester demain avec les drivers que nous avons écrit ce week-end.

Moteurs

Nous commençons à implémenter les des moteurs et l’utilisation de PWM pour contrôler les ponts en H.
Sur notre PCB, nous utilisons des « pilotes de demi ponts en H » (IRS2184SPBF) qui permettent (entre autres) d’éviter les court circuits.
Dans le schéma suivant, ces composants se brancheraient à droite et à gauche de façon à ne jamais avoir A et B à la même valeur :


Pour pouvoir changer le sens de rotation, on pense utiliser la broche enable disponible sur le « pilote » (IRS2184SPBF).
Le chronogramme suivant illustre ce que l’on croit nécessaire au moment de la transition d’un sens de rotation à l’autre :

 

De façon à éviter d’entendre le signal de contrôle, on pense utiliser une fréquence de l’ordre de 20KHz mais on ne sait pas encore si cela ne sera pas trop élevé pour « limiter les pertes lors de la commutation des transistors du pont en H ».
Un certain nombre d’incertitudes persistent donc toute suggestion serait la bienvenue !

Planning pour la semaine – « micro-tâches »

Envisageant pouvoir asservir correctement le segway avant dimanche prochain, nous nous sommes attribués les « micro-tâches » suivantes pour la suite :

Drivers carte capteurs

- I2C / Gyroscope -> João 12/04
- SPI / Accéléromètre -> Clément 11/04

Drivers carte principale

- Drivers Ponts en H -> Cédric 13/04
- Contrôle moteurs -> Cédric 14/04
- Drivers CAN -> Florian 11/04
- Tests Drivers CAN -> Florian 11/04
- Protocole CAN -> João 13/04
- Tests protocole CAN -> João 14/04
- Drivers encodeurs -> Clément 14/04

Tests filtre de Kalman

- Intégration filtre TestBench -> Florian 13/04
- Réglage filtre -> Florian 17/04

Intégration logicielle carte capteurs

- Implémentation asservissement en C -> Clément 12/04
- Réglage de l’asservissement -> Clément 17/04
- Réglage direction -> João 17/04

Divers

- Montage RoseWheel -> Cédric 12/04
- Montage encodeurs RoseWheel -> Cédric 13/04

Copterix : mécanique & oscilloscope

PID

Ce week-end, j’ai complètement modifié le PID. Avant, je mettais à jour à chaque itération les commandes moteurs. Maintenant, j’applique un delta aux commandes d’équilibre (à déterminer en pratique). Un testbench minimaliste montre que ce PID asservit correctement les trois angles (lacet, tangage et roulis) ainsi que l’altitude.

Après des tests sur l’hélico, il restera en l’englober dans un PID asservissant X et Y.

Capteurs

Samuel a terminé de récupérer les données des capteurs de notre PCB, Alexis ayant soudé les composants manquants. Il reste cependant à améliorer le calcul de l’altitude. Il faut en effet récupérer une dizaine de valeur sur l’altimètre pour calculer la pression. Pour l’instant la précision ne nous permet pas d’avoir un Δz exploitable.

Communication PCB/Gumstix

Loïc a terminé ses programmes pour communiquer entre PC et carte de TP que l’on doit porter sur Gumstix/PCB.

Nous avons donc branché le PCB sur la Gumstix. Les deux cartes sont connectées par une barrette 40 broches. On se sert de cinq d’entre elles: deux pour l’uart, une pour transmettre le VCC gumstix et deux en tant que GPIO. Il faudra écrire des modules pour la Gumstix pour contrôler les GPIO, c’est-à-dire l’enable du level-shifter (nécessaire, car la Gumstix est en 1.8V et notre PCB en 3.3V) et le reset du PCB.

Un debug à l’oscilloscope nous a montré que l’uart fonctionne en partie : on transmet de la Gumstix à notre PCB, mais cela ne fonctionne pas dans l’autre sens. En effet, les masses des deux cartes n’étant pas reliées, la différence de potentiel entre GND du PCB et VCC de la Gumstix est quasi nulle. Les sorties du level-shifter côté Gumstix sont ainsi inexploitables. Il faudra donc patcher la carte pour relier les deux masses.

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.

MB Led: Firmware, Bluetooth, bibliothèque graphique.

Depuis dimanche j’ai eu l’occasion d’avancer sur différentes parties:

Firmware:

Comme je l’explique dans mon précédent article nous mettons en place un système de mise à jour de firmware via IrDA. Mon travail a été d’implémenter, en utilisant les bibliothèques ST, les fonctions de déplacement de secteur de la flash depuis un bootloader situé en début de flash. J’ai effectué mes tests sur la carte de TP et utilisé objdump et openocd, ainsi que deux versions du « firmware » pour mes tests (un qui éclaire la LED en bleu et l’autre en vert). Une phase de débugage assez longue: des pages qui sont effacées sans le vouloir, la raison étant que la ligne de commande openocd faisait un « reset halt »  qui relancé l’ancien bootloader pour un nombre indétrerminé d’instructions, effaçant ainsi des mauvaises pages. Désormais on peut manipuler la flash à notre guise depuis le bootloader et effectuer la phase de recopie du nouveau firmware avant de l’exécuter sans problème.

Bluetooth:

J’ai commencer à implémenter réception/émission de commandes/réponses coté MB Led. Dès que je récupère un module bluetooth F2M03GLA, je pourrais faire des premiers tests de communication avec un client bluetooth sur mon pc.

Bibliothèque graphique:

Ecriture de premières fonction de manipulation des images, inspirées du code GLiP et d’autres plus adaptées au mode jeu (affichage de sprites, de lettres …).

A faire:

Nous devrions bientôt récupérer quelques unes de nos cartes avec les composants soudés. Je pourrais alors tester mon code pour le driver LED. En attendant je continue d’avancer sur les trois points précédents.