ELECINF344/381

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

Catégories

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…

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.

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.

RoseWheel : simulation et drivers

Aujourd’hui nous avons enfin terminé la partie simulation du RoseWheel. Nous sommes donc maintenant capables de simuler avec précision la dynamique du système ainsi que le filtrage des données des capteurs.

Évidemment, la modélisation exacte des différents paramètres, notamment les bruits des capteurs n’est qu’approximative et il faudra passer un peu de temps lors de l’implémentation en réel afin de les déterminer de manière correcte.

Concernant plus particulièrement la simulation du filtrage de Kalman, nous avons implémenté dans la simulation deux filtres de Kalman linéaires, le premier chargé d’extraire le biais de la mesure du gyroscope, le second chargé d’éliminer les composantes en hautes fréquences présentes dans les données du gyroscope et de l’accéléromètre. Cependant, pour des questions d’optimisation de temps CPU, on sera certainement amenés à fusionner ces deux filtres en un seul filtre, on espère que cela ne posera pas trop de soucis.

Nous avons cependant constaté que le filtre avait quand même du mal à suivre les variations du biais que nous simulions et que sur le long terme il lui arrivait de décrocher. Toutefois, nous pensons qu’il s’agit plus d’un problème au niveau de la simulation et que nous nous pencherons de façon plus approfondie sur le problème lorsque nous implémenterons le filtre en réel, c’est à dire demain.

Nous avons aussi pensé que cela pouvait être causé par la nature non linéaire du biais présent dans les données issus du gyroscope et qu’il serait peut-être nécessaire d’implémenter une forme de Kalman étendue plutôt que la forme linéaire. Mais encore une fois, nous testerons demain en réel afin de décider de la nécessité, ou non, de passer à une forme étendue du filtre.
Clément et Joao ont de leur côté continué d’implémenter les drivers pour les cartes.

Bonne nouvelle ! Alexis a terminé de souder les composants sur notre carte capteur. La journée de demain sera donc consacré aux différents tests de cette carte.

L’arrivée de notre carte est d’autant plus une bonne nouvelle que nous avons constaté un problème récurrent sur le gyroscope de la carte de Wheely que nous utilisions sur le testbench. En effet celui-ci a la fâcheuse tendance de ne plus rien retourner du tout parfois. Nous espérons que ce ne sera pas le cas sur notre carte.

Copterix : communications & PCB

Voici nos avancées pour la journée :

De mon côté, j’ai enfin réussi à avoir des communications plutôt satisfaisantes entre ma carte de TP STM32 et mon PC. J’ai modifié légèrement le protocole afin que celui ci soit plus robuste :

- Avant, j’envoyais un octet qui servait d’octet de start et d’identifiant du paquet
- Maintenant, j’envoie un octet de start, puis un octet d’identifiant du paquet, ce qui réduit les probabilités d’avoir la même séquence au milieu d’un paquet (ce qui provoquerait des erreurs en chaîne dans le cas d’une première erreur)

Samuel vient d’intégrer ce code pour le STM32 de notre PCB, cela semble fonctionner pour le moment

De son côté, Axel a supprimé les angles d’indétermination du filtre de Kalman.

Comme nous avons reçu le PCB, avec les premiers composants soudés, nous avons voulu prendre en main le tout, et nous avons commencé par allumer une LED. Maintenant nous allons nous occuper du SPI, de l’I2C.

MB Led: Du hardware au software

LE PCB:

Nous avons terminé le PCB vendredi matin. Après avoir validé notre routage, Alexis nous a appris qu’il avait fait en parallèle sa propre version du PCB. Sa raison étant, non pas qu’il ne croyait pas en nous, mais que contraint par le temps il a préféré commencer un routage prenant directement en compte certaine contraintes (écartement des pistes, congestion des pistes etc.). En effet les commandes pour les PCB devaient être passé dimanche soir et cela laissé peu de temps à Alexis pour revoir les PCB de toute les équipes. Au final les différence entre nos deux PCB ne sont pas grandes (mis à part les contraintes évoquées plus haut). Nous avons même rajouté quelques composants par rapport à ceux prévus au départ, avant de finaliser le routage vendredi (merci Cédric). Alexis a donc vérifié et finalisé notre(son) PCB ce week-end avant de le placer dans notre dépot GIT.

Nouvelle perspective:

Alexis nous a aussi appris que ce seront non pas 16 mais 40 blocs qui seront commandés pour notre projet (et surement pour d’autres plus tard). Les possibilités de jeu et d’application s’en trouvent donc décuplées.

Algorithme:

Nous passons désormais au software. Guillaume continue sur sa lancée pour la simulation en python. Nous avons réfléchi à une nouvelle version pour notre algorithme, principalement pour le positionnement. Après une phase d’élection pour connaître le bloc qui sera utilisé comme référant pour connaître le nord, ce “leader” attribue aux autres blocs leur coordonnées. Il se définit en (0,0); les autres connaissent alors leur position relative par rapport au leader. Après cette phase, il est nécessaire de savoir quel est le plus grand rectangle sur lequel nous pouvons afficher quelque chose. Après une recherche d’algorithme tous très complexes, nous avons décidés d’un algorithme simple (que nous préciserons dans un prochain post). Désormais, nous cherchons un système pour acquitter tous les messages puisque nous ne sommes pas sûrs de la fiabilité de l’infrarouge.

IrDA:

Conformément à notre planning, Cédric commence à se renseigner plus en détail sur le protocole IrDA et sur l’échange de message entre les blocs. Il va dans un premier temps étudier le code de l’équipe GLiP pour comprendre leur façon de faire. A la suite de cela il établira un nouveau protocole d’échange de messages inter-bloc adapté à notre algorithme.

Driver de LED:

Pour ma part, j’ai imprimé la datasheet du nouveau driver de LED et l’ai compris à un niveau plus approfondi. Je commence maintenant à implémenter la gestion de l’affichage d’image via ce driver. Dans la précédente version chaque LED (rouge, vert bleu) pouvait varier entre 16 niveaux d’intensité. Avec ce nouveau driver, elles pourront varier sur 4096 niveaux. Les contraintes de place nous amèneront peut-être à revoir ce nombre à la baisse.
Guillaume, Cédric et Benjamin.

TSV Safe Express: Le Jour de Routage et le nouveau PSSC

Aujourdhui,  on a passé le jour avec routage des notre cartes. Aussi, alexis nous a donné quelque remarques sur le schéma. Nous avons corrigé notre schéma avec les remarques. On a appris deux nouveau choses

(i) le valeur de condensateur n’est pas exactement  le mémé lequel présent dans le datasheet. Le Datasheet contient le valeur minimum possible. Alors, il faut que changer le valeur de condensateur basé sur le contexte de utilisation.

(ii) Le « Test Circuit » mentionné dans le datasheet n’est que un « test circuit ». ça va dire, nous ne devons pas mettre quelque composants à partir de la Test Circuit. (Nous avons mis un condensateur sur le file CAN Rx aprés avoir regardé dans le test circuit de le datasheet).

Notre PCB schemas et routage disponible dan le dépot Git. Nous allons corriger notre schéma si il ya un conseil de la parte de  Alexis ou Samuel.

Pour le PSSC, on propose un nouveau agenda

1. On peut détecter l’etat des capteurs position avec CAN bus – 13/04/2011

2. On peut commander et transmettre l’état les feux avec CAN bus – 18/04/2011

3. Un Train sera commandé avec le protocole DCC – 20/04/2011

4. On peut commander les trains, feux avec des messages du logiciel ROCRAIL.

Nous avons deux hypothèses -

1. Nous allons recevoir le carte avant 08/04/2011

2. Il n’y aura pas de problème de faire le programmation de flash à partir de USART. (ça va dire, pas de problème du logiciel comme openocd ou quelque qutre chose)

Nous avons aussi partagé notre responsabilité pour du Logiciel.

Siwar – CAN

Theodoros – DCC Encoder et Vérification, Capteur Signaux

Vaibhav – Etherenet et SPI

La division basé sur le différent H/W module disponible dans notre projet.

TSV Safe Express: C’est parti

Nous sommes en train de faire les PCB de nos cartes. Nous avons lu aujourd’hui  les datasheets de nos composants afin de les connecter au stm32.  Theodor fait le schéma de la carte principale, Vaibhav la carte des capteurs, et moi la carte feu.

Nous allons finir les PCB dans deux jours puisque leur envoi et fabrication prend du temps.

 

MB Led et PCB

Aujourd’hui, fin du STM32 et continuation du projet. J’ai donc continuer à faire le PCB que Benjamin avait repris en l’adaptant à l’évolution des composants.
Il a donc fallu lire les Datasheets des composants qui avaient changé lors de la commande ce qui permet ce soir et après le TP une meilleur vision de leur utilisation.
Après les suggestions d’Alexis, nous avons cherché un nouveau driver de LED car l’ancien proposait une sortie en PWM ce qui aurait posé des problèmes avec le système d’affichage ligne par ligne. Nous resterons donc chez TI mais prendrons le TLC5951 dont les sorties sont à courant continu. L’avantage de ce driver est qu’il possède 24 sorties réparties en 3 groupes permettant de gérer ensemble des paramètres comme l’intensité maximale. Il prendra 5 pin pour le contrôler 2 timers et 3 des quatre fils du SPI (MISO,MOSI,SCK).

Pour le module bluetooth, nous aurons également besoin de 5 pin (2GPIO, 1UART, un reset) afin de pouvoir configurer le module.

Tout cela m’a permis de finaliser le brochage et demain je commencerai le routage.