ELECINF344/381

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

Catégories

[CASPER] Prototype fonctionnel

Hier, nous avons finalisé le prototype mécanique.

Nous avons installé les trois servomoteurs sous le plan du socle. Nous les contrôlons grâce à un signal PWM de la carte de TP STM32.

Nous avons changé nos anciens câbles de carbone par des câbles en plastique. Il est apparu que bien que leurs propriétés mécaniques en poussée/traction étaient bonnes, celles-ci ne sont pas assez flexible pour supporter les mouvements au niveau des bras motorisés.

Nous avons implémenté un programme de commandes qui fait effectuer un 360° à Casper que nous contrôlons par le potentiomètre (relié à l’ADC) de la carte de TP.

Nous allons maintenant travailler sur des fonctions qui permettent un contrôle précis de la direction et de l’inclinaison de Casper et en parallèle peaufiner le prototype afin qu’il soit plus robuste.

Voilà la vidéo du programme de démonstration (360° contrôlé par ADC) :

 

Parallèlement, l’UART sur le PCB est fonctionnel et on peut pour l’instant afficher les chaînes de caractères reçues sur l’écran LCD.

RoseWheel : développement carte capteurs

Hier,

Cédric a terminé le banc de tests. Après quelques ajustements au niveau communication (les deux cartes n’envoyaient pas leurs données à la même vitesse) nous sommes en mesure d’afficher :

  • la valeur de l’ADC donnant la position du potentiomètre et donc l’inclinaison
  • l’angle d’inclinaison calculé à partir de l’acceleromètre
  • la vitesse angulaire donnée par le gyroscope
  • la vitesse angulaire calculée à partir des données de l’ADC

Voici un exemple de graphe affichant en rouge ADC, en bleu calcul de l’angle à partir de l’accéléromètre, en vert la mesure du gyroscope et en noir la vitesse angulaire calculée à partir de l’ADC :

La prochaine étape est donc de confronter la simulation de notre filtre de Kalman au banc de tests…

Florian a travaillé à ajuster notre filtre de Kalman pour qu’il ne tienne compte que des données que nous récupérons sur le banc de tests. En effet jusqu’ici nos simulations faisaient l’hypothèse de la présence d’encodeurs. En simulation nous éstimons connaître parfaitement notre déplacement et notre vitesse de déplacement. Le montage du Zzaag nous dira si il est possible ou non d’inclure des encodeurs dans notre version finale. Florian et João ont également travaillé à l’amélioration du simulateur et de l’asservissement LQR.

João et moi-même avons bien avancé sur les drivers. Nous avons développé ces derniers en utilisant la bibliothèque STM32F10x_StdPeriph_Driver ce qui nous permet d’avoir un peu plus de flexibilité qu’en configurant directement les registres. Nous essayons d’implémenter les drivers pour nos différents périphériques aussi indépendemment que possible du brochage. Ainsi, pour chacune de nos cartes, nous aurons juste à « instancier » nos périphériques en indiquant la patte sur laquelle ils sont branchés. Nous avons nommé cette bibliothèque libperiph et en générons une version statique (.a) que nous lierons avec les objets de nos différentes cartes. Nous disposons dores et déjà de drivers pour :

  • Adcin (tout périphérique nécessitant des conversion ADC en « single conversion »)
  • Button
  • Buzzer
  • Leds
  • Sharps (utilisation de l’ADC en « continuous conversion » et du DMA)
  • Switch

Nous allons aujourd’hui tester ces drivers sur la carte de TP et implémenter les autres :

  • CAN
  • Accéléromètre (SPI)
  • Gyroscope (I2C)
  • UART
  • Bluetooth
  • Sonar
  • Encodeurs
  • Moteurs

RoseWheel : banc de tests, la fin approche…

Notre banc de tests étant particulièrement sensible au niveau de la référence (le potentiomètre dans l’axe du moteur), nous avons persévéré jusqu’à obtenir une précision satisfaisante, les résultats de nos prochaines expériences ne serait pas significatifs sinon.

Le potentiomètre est connecté à un ADC, sa précision étant parfois aléatoire, nous avons refait une régression linéaire mais les valeurs utilisées sont maintenant les moyennes de chaque borne max et min. Nous avons effectué de nouvelles mesures pour des angles proches de 0 pour plus de précision sur cette zone dans laquelle le système se trouvera le plus fréquemment :

 

De plus, nous corrigeons l’angle de référence (colonne E) en fonction de la commande (G) en compensant l’erreur mesurée (F).

On obtient un résultat plus satisfaisant mais probablement encore améliorable :

Comparaison de la commande angulaire envoyée avec la référence obtenue grâce à un potentiomètre placé dans l’axe du moteur.

 

On peut voir qu’il y a un certain délai pour afficher une valeur stable mais le calibrage est raisonnable (nous pensons savoir où l’on est ralenti mais nous n’avons pas encore commencé à investiguer sérieusement).

Demain, nous allons donc recommencer la confrontation « commande VS référence » sous Matlab, un aperçu sera normalement disponible très bientôt.

RoseWheel : avancées post-soutenance

Depuis la soutenance de mercredi matin, nous avons essayé d’avancer sur trois aspects de notre projet :
- Simulateur : nous avons commencé à écrire un nouveau module pour tester seulement la modélisation des moteurs, étant donné que nous avons toujours des résultats inacceptables au niveau de la tension requise pour l’équilibre. En parallèle, nous vérifions les équations du modèle physique général, pour essayer de trouver les erreurs « cachées » ;
- Banc de test : après avoir mis une référence plus visible pour lire le rapporteur, nous avons calibré à nouveau le moteur. Désormais, il reste intégrer ce nouveau calibrage au potentiomètre pour pouvoir savoir exactement la position où se trouve le moteur, et ainsi reprendre nos tests avec une meilleure précision. Voici l’état actuel de notre dispositif :
- Cartes : nous avons commencé à réflechir à la l’implémentation des drivers pour les divers périphériques. Nous voudrions utiliser une architecture plus générique que celle que nous utilisions pour le TP STM32. Suite à quelques essais il semble difficile de faire des fonctions génériques de configuration de périphériques sans faire trop compliqué (fonctions longues, bricolage sur les masques et les offsets…) ; peut-être que des macros préprocesseur seraient plus adaptées… nous explorerons d’autres pistes demain. Nous allons tout de même essayer de faire simple et ne pas implémenter plus de généricité que nécéssaire pour nos deux cartes.

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

Communication challenge 2011

Cette année, le communication challenge repose sur la possibilité d’exécuter des commandes en tâche de fond et de stocker des commandes pour usage futur.

Communication avec le serveur

Le serveur communique en 802.15.4. Son identité est « CC » (0×43 0×43). Chaque client doit être configuré avec les initiales du participant sur deux caractères comme c’était le cas pour la mise en œuvre il y a deux semaines. Les messages envoyés en broadcast seront rejetés et pourront conduire à l’élimination de la personne fautive. Toute tentative, réussie ou non, de se faire passer pour le serveur, pour un autre client ou de perturber un autre participant sera sanctionnée.

Toutes les communications utilisent un protocole découpé en lignes, chaque ligne étant terminée par le caractère ‘\r’ (line feed). Aucune ligne, émise par le serveur ou par les cartes, ne peut contenir plus de 50 caractères (y compris le caractère de fin de ligne).

Lorsque des valeurs doivent être échangées entre le serveur et le client en hexadécimal ou en base 33, celles-ci utiliseront les chiffres de 0 à 9 puis les lettres majuscules, de ‘A’ jusqu’à, respectivement, ‘F’ ou ‘W’. Les valeurs transmises par le serveur contiendront systématiquement deux chiffres lorsqu’elles sont en hexadécimal ou un seul chiffre lorsqu’elles sont en base 33. Les valeurs transmises en hexadécimal par le client contiendront autant de chiffres que nécessaire (jusqu’à 3).

Les paquets envoyés par le serveur auront systématiquement la forme suivante :

SLOTID [CMD] EOL

où :

  1. SLOTID est un caractère en base 33. Il vaut soit ’0′, pour signifier une exécution immédiate, soit une valeur entre ’1′ et ‘W’ indiquant qu’il faut stocker les commandes dans le slot correspondant (il faut donc prévoir 32 slots) pour une exécution future (voir, plus bas, la commande ‘X’).
  2. [CMD] représente 0, 1 ou plusieurs commandes, concaténées sans séparateur intermédiaire.
  3. EOL représente le caractère de fin de ligne ‘\r’.

La réponse à la réception d’une commande doit être envoyée immédiatement (avant exécution éventuelle) sous la forme d’un paquet de deux caractères :

SLOTID EOL

Ensuite, si SLOTID vaut 0, la commande doit être exécutée (ce qui peut provoquer l’envoi de paquets supplémentaires comme indiqué dans la description individuelle des commandes.

Les exemples donnés le sont à titre d’illustration et ne sont pas contractuels (ils peuvent contenir des erreurs, même si un effort particulier a été fait pour qu’ils soient corrects). Le préfixe « > » représente une ligne envoyée par le serveur à la carte et le préfixe « < » un envoi d’une ligne de la carte vers le serveur.

Pour initier le dialogue avec le serveur, la carte doit, après avoir configuré son adresse correctement, envoyer une ligne « START », et le serveur enverra alors sa première commande. À tout moment, en cas de réponse incorrecte, le serveur peut arrêter d’envoyer des commandes à la carte, et ne recommencera que lorsqu’un nouveau « START » sera renvoyé. L’envoi de « START » par le client est permis à tout moment et redémarrera la séquence.

Commandes

Ping

La commande Ping est constituée d’un unique caractère ‘P’. L’effet de son exécution est l’envoi d’un paquet contenant le caractère ‘P’ suivi d’un caractère de fin de ligne (l’envoi de ce caractère de fin de ligne est valable pour toutes les commandes qui envoient quelque chose, son utilisation ne sera pas rappelée par la suite).

Exemple d’exécution de la commande Ping

> 0P
< 0
< P

Leds

La commande Leds est constituée du caractère ‘L’ suivi de trois valeurs hexadécimales comprises entre 00 et FF représentant, respectivement, l’éclairage des leds rouge, verte et bleue composant la led tricolore équipant la carte. Elle ne donne lieu à aucune réponse.

Exemple d’allumage de la LED tricolore à environ 50% de vert et 0% de rouge et bleu

> 0L007F00
< 0

Execute

La commande Execute est constituée du caractère ‘X’ suivi d’un numéro de slot en base 33 entre ’1′ et ‘W’. Elle ne donne lieu à aucune réponse directe, mais l’exécution des commandes stockées dans le slot correspondant peut donner lieu à l’envoi de paquets si ces commandes le prévoient.

Attention : l’exécution d’une commande dans un slot particulier peut contenir des ordres d’exécution d’autres commandes. Il est donc important que l’exécution de commandes imbriquées soit possible.

La carte ne doit pas traiter de nouvelles commandes entrantes tant que la commande en cours n’a pas terminé son exécution. Par exemple, le traitement de la commande « 0X1″ (exécuter immédiatement le contenu du slot 1) doit effectuer les commandes du slot 1 avant d’accepter une nouvelle commande entrante.

Exemple de stockage d’une commande (double ping) dans le slot 1 suivi de son exécution

> 1PP
< 1
> 0X1
< 0
< P
< P

Exemple de stockage et d’exécutions multiples

> 1X2X2
< 1
> 2PP
< 2
> 0PX1X2
< 0
< P
< P
< P
< P
< P
< P
< P

Upper LCD line

Cette commande permet d’afficher un message sur la ligne supérieure du LCD. Si le message contient 16 caractères ou moins, le message doit être simplement affiché en l’alignant à gauche. Si le message contient plus de 16 caractères, il doit défiler continuement en tâche de fond jusqu’à ce qu’un nouvel affichage sur cette ligne ait lieu lors de l’exécution d’une nouvelle commande du même type.

La commande est constituée du caractère ‘U’, de la longueur du message en hexadécimal puis des caractères individuels à afficher. L’exécution de cette commande ne renvoie rien.

Exemple d’affichage du mot « PING » sur la ligne supérieure et de la réponse à un Ping

> 0U04PINGP
< 0
< P

Lower LCD line

La commande ‘D’ est à traiter comme la commande ‘U’ à la différence qu’elle affiche le message sur la ligne inférieure de l’écran LCD.

Exemple d’affichage du message « Hello world » sur les deux lignes

> 0U05HelloD05world
< 0

Switch

La commande Switch est constituée de l’unique caractère ‘S’. Son exécution doit, dans l’ordre :

  1. attendre que les deux boutons soit relâchés ;
  2. envoyer, selon le bouton pressé, respectivement ‘L’ pour le bouton de gauche (left) ou ‘R’ pour le bouton de droite.

Exemple d’appui sur le bouton gauche puis le bouton droit

> 0U0EPresser gaucheD0Apuis droitSS
< 0
< L
< R

Analog sensor

La commande Analog est constituée de l’unique caractère ‘A’. Son exécution renvoie la valeur, en hexadécimal, du potentiomètre tel que lu sur 12 bits sur le convertisseur analogique-numérique. Cette valeur sera comprise entre 0 et FFF.

Afin de pallier les problèmes liés aux légères variations du convertisseur analogique-numérique dans les poids faibles de la valeur retournée, il est permis (et conseillé) de lisser la valeur retenue en procédant ainsi : si la valeur est éloignée de moins de 50 (décimal) de la valeur précédemment lue, cette valeur précédente peut être conservée. Par exemple, si la valeur « 7F8″ (hexadécimal) a été précédemment utilisée, elle peut être retournée tant que la valeur lue dans le convertisseur est comprise entre « 7C6″ (hexadécimal) et « 82A » (hexadécimal).

Exemple de lecture du capteur analogique positionné approximativement à mi-course

> 0A
< 0
< 7F8

Connect analog sensor to stored commands

Cette commande permet d’exécuter, en tâche de fond, la valeur lue sur le convertisseur analogique-numérique à des commandes préalablement stockée. La plage de sensibilité du capteur (entre « 0″ et « FFF ») doit être divisée en zones de taille égale et ordonnées, et la commande correspondante doit être exécutée.

La commande est constituée du caractère ‘C’ suivi d’une valeur hexadécimale indiquant le nombre de zones à utiliser, puis la liste ordonnée des slots correspondant à ces zones. Un nombre de zones égal à « 00″ désactive cette fonctionalité. La commande ne renvoie rien.

Cette commande doit alors s’exécuter en tâche de fond. Vous avez la garantie que le serveur n’enverra pas de commandes perturbant l’exécution de cette commande avant d’avoir stoppé son exécution.

Si vous avez opté pour la procédure de lissage conseillée pour l’implémentation de la commande ‘A’, vous devez également utiliser ce lissage pour l’implémentation de cette commande.

Exemples de séparation en trois zones (rouge, vert, bleu)

> RLFF0000
< R
> GL00FF00
< G
> BL0000FF
< B
> 0C03RGB
< 0

Rendu du code

Le code du challenge devra se trouver dans un répertoire appelé « challenge2011″ dans la branche « master » de votre dépôt personnel. Il ne doit y avoir qu’un seul répertoire portant ce nom, et il peut se trouver où vous le souhaitez dans l’arborescence de votre dépôt.

MB Led: PCB et algorithmique

Aujourd’hui, nous avons terminé le routage du PCB le TP stm32 et après une semaine nous avons pu reprendre activement l’avancement de notre projet.

Guillaume a continué à voir l’algorithme de notre système réparti avec la première et difficile question pour un bloc qui est de savoir où il est et où est son nord et cela qu’il soit seul ou dans un réseau de bloc. Ici se posent les problèmes de savoir quel bloc prendre comme base pour l’orientation dans le cas d’une modification importante du réseau de blocs (ex: on disperse tout et on reconstruit ou on colle brusquement deux réseaux de blocs). Nous sommes d’abord partis du principe que chaque bloc est une entité indépendante, mais nous envisageons maintenant de considérer le problème par réseau de blocs (un bloc seul étant un réseau d’un bloc) afin de coller à l’idée de système réparti et de permettre de traiter plus globalement les différents cas possibles. Par exemple lorsque l’on fait la jonction de deux réseaux, les deux réseaux échangent leurs états pour construire l’état du nouveau réseau. Se pose la question de la réactivité de ce système dans le cas d’une jonction simultanée de plusieurs réseaux. Il a également mis en place les bases et défini les différents types d’envois d’information en cas de transmissions extérieures (Via Bluetooth, port série) ainsi que la gestion des échanges et mise à jour de la liste des programmes et du firmware des blocs.

Benjamin a repris le schéma de GLIP comme base pour notre PCB pendant que je me penchais sur la question de l’achat des composants et des divèrses transformations que cela entraine dans le circuit. Nous nous sommes posés le problème de modulation de l’intensité d’émission des transceivers IrDA qui se fera grâce à un petit potentiomètre ainsi que celui l’intégration de la SD avec la recherche d’un connecteur (nous hésitons encore entre des cartes SD ou microSD) interfacé par le mode SDIO du STM32F103RET6 en 64 pins (48 ne seraient pas suffisants). Tout ceci nous a permis de commencer à évaluer le coût des composants des blocs pour un total d’environ 60€ (sans compter le PCB).