ELECINF344/381

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

Catégories

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

TSV Safe Express: travail du Lundi

Aujourd’hui, nous avons avancé sur deux axes: l’implémentation du standard NMRA et celle du Bootloader CAN.

Concernant le NMRA, Théodor et Vaibahv ont fini l’implémentation du Network Manager ( Le code actuel se trouve dans leurs branches.)

Ils ont avancé ensuite dans la programmation du « Configuration Tool« .

Demain, ils vont finir la partie configuration pour entammer ensuite l’implémentation du protocole consumer/producer.

De ma part, je me suis fixée les idées sur l’implémentation du Bootloader. J’ai divisé mon travail en trois parties:

sendToUART    =>    UART_To_CAN   =>   CAN_To_MemoryAccess

La première partie est facile, il suffit d’initialiser l’UART et d’activer le Bootloader intégré .

Pour la deuxième partie, il faudra groupper les bytes provenant de UART pour envoyer des messages CAN correspondants avec un header de 29 bits et une partie data de 8bytes au maximum.

Pour la troisième partie, j’ai commencé à implémenter du code pour accéder à la mémoire Flash comme décrit dans les diagrammes du manuel, puis j’ai trouvé des fonctions toutes prêtes dans la bibliothèque. J’ai écrit du code qui reçoit une commande d’écriture après activation du Bootloader CAN, prend l’adresse sur 4 bytes et vérifie si elle est valide et commence à flasher les packets reçus.

Je finis bientôt l’implémentation de la partie qui flashe le code à partir de messages CAN. Il reste par exemple d’assurer l’alignement des adresses et d’envoyer des messages d’ ACK pour signaler le bon flashage du code.

 

Le schéma suivant représente les relations entre nos 3 types de cartes à travers le bus CAN et les différentes parties faites ou à faire:

 

RoseWheel : Simulateur et Testbench

Aujourd’hui nous avons travaillé sur plusieurs fronts à la fois en vue de préparer la présentation d’une part et d’autre part d’avancer sur les différentes PSSC en cours, notamment la finalisation du TestBench et du simulateur.

Nous avons complètement restructuré la mécanique du Testbench. En effet, en rapport avec le Post d’hier soir, nous observions trop de bruit lors des transitions du moteur entre les différents angles.
Afin de palier à ce problème, nous avons ajouté un potentiomètre sur l’axe du servomoteur afin de pouvoir mesurer en temps réel et de façon précise le mouvement exact du moteur. Nous sommes alors en mesure d’extraire la partie issue du moteur dans le bruit du signal mesuré.
Nous avons de plus ajouté un rapporteur centré sur l’axe du servomoteur afin d’avoir un moyen de plus pour nous permettre de valider la fiabilité de la mesure des angles issus de l’accéléromètre et du gyroscope.

Concernant le simulateur, nous observons toujours des problèmes vis-à-vis des paramètres physiques. En effet, avec les paramètres que nous utilisons pour le moment, nous obtenons toujours une valeur saugrenue de la tension de commande (aux alentours de 3000V au lieu des 24V prévus). Nous avons donc remis en question chacun des paramètres que nous avions initialement calculés et nous sommes arrivés à la conclusion que les valeurs de la constante de couple reliant le courant au couple moteur et la constante de force contre électromotrice reliant la tension contre électromotrice à la vitesse de rotation étaient peut-être faussées.
Nous nous sommes donc penchés à nouveau sur une doc (très sommaire) des moteurs utilisés dans le zzaag. De plus Alexis nous a conseillé de simuler à l’aide de Matlab/Octave les équations d’état des moteurs que nous avions injectées dans les équations d’état de RoseWheel afin d’observer directement les valeurs du couple et de la vitesse de rotation de l’axe pour différentes valeurs des 2 constantes précédemment citées. Ceci nous permettra de vérifier les valeurs que nous avons calculé.

Dans l’optique de la présentation de demain, nous nous sommes penchés à nouveau sur un certain nombre de choses :

Le schéma de l’architecture matérielle a été revu et corrigé :

 

Le schéma de l’architecture logique a  été lui aussi corrigé :

[CASPER] Un peu de mécanique

Schéma du prototype

Tout d’abord, pour compléter les vidéos postées sur un précédent billet, voici un schéma de notre prototype pour une vue plus claire du système.

 

Contrôle du système

Deuxième partie de ce billet, une description du comportement du robot. Nous considérons tout d’abord le cas d’un robot à un seul « étage » (une seule plateforme). Nous faisons de plus l’hypothèse que les fils latéraux sont assez souples pour prendre la forme de segments (et non d’arcs de cercle comme la tige centrale), et ne peuvent pas exercer de force de poussée (hypothèse expérimentalement réaliste).

Cas où un seul fil est tiré (les autres étant laissés libres)

Le schéma suivant donne la relation entre la longueur d’un fil latéral et l’angle d’inclinaison du système.

Les plus perspicaces remarqueront qu’un développement limité de cosinus en pi/2 permet de prolonger la fonction par continuité et d’éviter les problèmes…

On remarque de même que la longueur des autres fils laissés libres se calcule facilement avec le théorème de Thalès (en n’oubliant pas de projeter les fils dans le bon plan).

La formule précédente donne la longueur a en fonction de l’angle r. Nous l’avons tracée sur la figure suivante :

On remarque qu’au final, la courbe s’approxime plutôt bien par une droite, ce qui a l’avantage de donner sa fonction inverse beaucoup plus facilement que la formule initiale…

Cas où deux fils sont tirés (le troisième étant laissé libre)

Dans le cas où deux fils sont tirés, on peut se ramener à la figure précédente : en supposant que les fils mesurent a et b respectivement, on peut les remplacer par un unique fil de longueur ((L-a)b+a(L’-b))/(L-a+L’-b) et situé entre les deux fils à une distance d*(L-a)/(L-a+L’-b) du fil b, où L’ serait la longueur du fil b si seul le fil a était tiré.

Une fois de plus, le théorème de Thalès permet ensuite d’accéder à la longueur du troisième fil.

Passage à plusieurs étages

Pour passer à un robot à plusieurs étages, il suffit de changer de référentiel en considérant successivement chaque étage. Il faut alors considérer que chaque fil est tiré au niveau de chaque étage proportionnellement à la hauteur de l’étage au repos par rapport à la hauteur totale.

 

Tout ceci permet d’y voir plus clair dans le contrôle moteur (et surtout sur les contraintes que doivent respecter les longueurs de chaque fil). Il reste encore à exprimer toutes les formules suggérées ci-dessus, ce qui ne devrait pas poser de difficulté théorique…

RoseWheel fait des simulations

Cet article a été rédigé hier soir…

Nous avons terminé ce week-end le PCB de notre carte capteurs. Nous avons fait le schéma de notre carte principale mais Alexis va y ajouter la partie puissance et la router pour nous.

Carte Capteurs [avant]

Carte Capteurs [arrière]

Aujourd’hui nous avons travaillé en parallèle sur l’utilisation du banc de tests et sur le simulateur qui intègre le filtre de Kalman et l’asservissement.

Le simulateur commence à fournir des résultats mais nous avons encore des problèmes de valeurs numériques. Notre simulation fait intervenir des tensions de plusieurs milliers de Volts (alors que nos moteurs n’en acceptent que 24) pour réussir à redresser le gyropode. Cela est certainement dû à une mauvaise estimation de nos constantes km (constante de couple en N.m/A) et ke (constante force contre-électromotrice en V.s/rad).

Pour les calculer nous avons récupéré les caractéristiques du moteur sur le site du distributeur :

À charge nominale on a

  • Vitesse angulaire : VA = 3751 rpm
  • Couple : T = 0.88 N.m
  • Intensité : I = 18.36 A
  • Résistance : R = 0.66 Ohm
  • Tension : U = 24.09 V

Or

  • km = T / I = 0.048 N.m / A
  • ke = (U -- R * I) / VA = 0.030 V.s / rad

Mais avec ces valeurs nous rencontrons les problèmes mentionnés plus haut. Ces problèmes viendraient-il d’ailleurs ? Alexis nous a conseillé de faire un simulateur des moteurs seuls pour déterminer vérifier nos constantes. À suivre…

Par ailleurs, comme le montre la figure suivante, le filtre de Kalman se comporte bien. Même avec un rapport signal sur bruit médiocre nous arrivons à reconstituer assez fidèlement l’angle d’inclinaison. Pour l’asservissement nous avons testé deux techniques : PID puis LQR. Le PID s’avère être délicat à régler et ne nous a pas donné de résultat satisfaisant (divergence de l’erreur au bout d’un certain temps). Le LQR se comporte beaucoup mieux et propose un réglage moins empirique. Couplé au filtre de Kalman, et problèmes de valeurs numériques exclus, notre système se comporte vraiment comme nous le souhaitons. Reste donc à vérifier si nous observons le même comportement avec les bonnes valeurs numériques pour les moteurs. Notons que pour l’instant nous incluons le déplacement et la vitesse dans nos variable d’état ce que nous ne pourrons faire que si nous arrivons à monter des encodeurs sur la mécanique du projet zzaag.

Simulateur RoseWheelCliquez sur l’image pour voir l’animation.

Concernant le banc de tests nous avons terminé sa réalisation. Nous avons monté une vidéo tournée vendredi pour le montrer en action :

Cette première version du banc de tests fonctionne ainsi :

  • on communique avec la carte de TP en RS232
  • la carte de TP commande le servo qui incline la carte capteurs du projet Wheely
  • on récupère les données des capteurs via RS232 sur l’ordinateur
  • on affiche conjointement les courbes de la commande et de la mesure

Pour les mouvements lents, nous procédons par rotations successives. La précision du servomoteur étant assez faible, cela entraîne des mouvements saccadés et introduit un bruit non négligeable lors des transitions. Par ailleurs, la calibration du banc s’avère insuffisante ce qui se traduit par un offset sur les valeurs mesurées. Nous aurions aimé présenter des courbes (superposition commande / mesure du banc de test) mais nous avons été chassés d’A405 avant d’avoir pu les exporter… No comment. Nous travaillerons demain à l’amélioration de ces résultats.

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: PCB

Les schémas prêts, nous avons commencé à faire le placement et routage.

En faite, nous finissons ce soir cette partie et il ne reste demain que modifier éventuellement le PCB après sa vérification.

Nous allons poster ce soir un planning plus détaillé et plus réaliste de notre projet.

MB Led: Algorithmie

Après une journée très épuisante lundi avec le communication challenge, nous voilà reparti sur le projet. Hier, j’ai revu l’algorithmie de base avec l’aide de Cédric et Benjamin. Aujourd’hui, j’ai parlé avec Sam sur le zéro MQ. En effet, pour l’instant, ma simulation est uniquement en Python (une classe pour le module, une pour l’envoi de message, une pour la réception). Sam me dit qu’il serait préférable — quand l’algorithmie sera au point — de programmer les modules en C directement et d’utiliser zéro MQ pour simuler un scénario et envoyer les messages entre modules.

 

Le schéma algorithmique est le suivant :
PING -> ELECTION DE LEADER -> ORIENTATION -> POSITIONNEMENT.

  • PING

Les modules ping tout le temps leur 4 interfaces (disant « HELLO MY_ID »). Au bout d’un certain nombre de messages reçus sur une interface, il considère qu’il a un voisin.

  • ELECTION DE LEADER

A la fin de la phase d’identification, il y a « élection de leader » pour savoir qui décidera de l’orientation. Pour l’élection, on choisit le module Bluetooth en premier et sinon, c’est celui avec l’ID le plus grand.

Si un module arrive sur un réseau déjà orienté, il n’y a pas d’élection de leader, il « subit » la loi du nombre.

  • ORIENTATION

Le « leader » oriente les autres modules selon son orientation.

  • POSITIONNEMENT

Le but est de savoir à chaque instant qui est dans le réseau (et où exactement).

Nous avons opté pour la création d’un tableau de voisin stocké en RAM. Au centre de ce tableau est inscrit le numéro du module.Ensuite, les voisins « directs » (accessibles par IrDA) sont stockés selon l’UART avec laquelle ils communiquent.

Ex : Le module est en rouge ici, le voisin qui communique avec l’UART 1 est stocké en 1, etc.


Quand un module arrive sur un réseau, il n’est pas considéré comme faisant parti du réseau tant qu’il n’est pas orienté correctement. Quand il le devient, il envoie un message à ses voisins disant « coucou je fais parti du réseau », ce à quoi on lui répond « OK. Voici tous les modules connectés au réseau (avec leurs coordonnées) »

Quand l’algorithme de positionnement sera fini (d’ici peu j’espère), je passerai à la programmation en C des modules et je tenterai un affichage graphique de la simulation.

 

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.

 

RoseWheel : conception des cartes (II), Kalman

Depuis le début de la semaine, nous avons beaucoup travaillé sur nos cartes et sur le simulateur physique. Voici un petit résumé de nos réflexions et activités.

Carte logique et capteurs

Nous avons réalisé un premier placement-routage basé sur le schéma que nous avions publié sur le site dimanche. Le résultat, pourtant, n’a pas été satisfaisant : à cause des contraintes de placement (par exemple, mettre les boutons au dessous du LCD), le routage a été très difficile. Alexis nous a donc conseillé deux modifications :

  1. Passer au boitier 64 broches pour le microcontrôleur – cela permet une plus grande flexibilité au niveau du brochage, et nous donne la possibilité de brancher l’accéléromètre et le gyroscope sur deux bus différents ;
  2. Séparer l’interface utilisateur de la carte logique, ce que la simplifie et rend le système plus modulaire : nous pourrons, par exemple, choisir mettre la carte logique en bas – comme c’est fait dans pratiquement tous les Segway existants -, tout en gardant l’écran et les boutons en haut. La communication entre les deux modules se ferait par le bus CAN.

En outre, nous nous sommes aperçus qu’il y avait encore d’autres petits problèmes, comme l’alimentation des sonars et des Sharps qui était à 3,3 V sur notre schéma alors qu’elle devrait être 5V. Alors, nous avons commencé à appliquer les adaptations à notre schéma, et nous espérons avoir de nouveaux résultats dans les prochains jours.

Carte de puissance

Suite aux indications d’Alexis, nous avons modifié aussi notre carte de puissance. La partie qui serait responsable du contrôle brushless a été enlevé pour rendre le système plus modulaire, ce qui sera utile dans le cas où on n’aura pas le temps ou le budget pour utiliser ce type de moteur. Le contrôle des moteurs sera fait, donc, avec un seul paire de sorties PWM.

Nous avons aussi completé le schéma avec des entrées pour les sonars, pour rendre possible la connexion de n’importe quel capteur de distance à cette carte. Finalement, nous nous sommes lancés à la recherche d’une jauge de batterie compatible avec les batteries au plomb dont nous disposons, mais nous n’avons pas encore rencontré une solution viable. Il y a le BQ78412, mais nous ne l’avons trouvé chez aucun distributeur pour l’instant. Toute suggestion est donc la bienvenue.

Filtre de Kalman

En parallèle aux efforts dans la conception des cartes, nous avons avancé sur le simulateur en Octave de notre véhicule. Nous avons implémenté le filtre de Kalman et l’intégré à la simulation, et maintenant nous travaillons pour le faire fonctionner comme prévu.