ELECINF344/381

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

Catégories

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 : Test bench & Kalman

Aujourd’hui nous avons continué l’amélioration de notre test bench d’un coté et recommencé la modélisation physique de l’autre.

 

Le document de Rich Chi Ooi a été complètement abandonné, il y aurait apparemment des erreurs de calcul (au moins intermédiaire) et son implémentation complexe n’était vraiment pas pratique.

Les équations de BoRam seraient de loin bien plus simple à implémenter et les résultats sont beaucoup plus satisfaisants.

Il reste néanmoins un facteur 4 dans le sens où on obtient des commandes en tension au dessous de 100V au lieu de 24V (alors qu’on avait une erreur de l’ordre de 10 000V avec Rich Chi Ooi).

 

Les améliorations sur le test bench sont moins conséquentes puisqu’il ne s’agissait que d’optimisations.

Tout d’abord avons rendu le test asynchrone de façon à pouvoir changer d’inclinaison cible en cours de route sans avoir à attendre la fin de l’exécution d’une commande (ce qui peut être long si la vitesse demandée est faible). Pour ce faire, nous utilisons des queues que nous remplissons d’objets composés de commandes angulaire et de leur délai associé pour aller à la vitesse demandée.

Enfin, nous avons doublé la précision de calibration de la commande du moteur en mesurant de nombreuses fois chaque PWM associé à un angle et ce tous les 10°.

A l’origine, nous utilisions un tableau de valeurs à interpoler pour calculer les PWM à mettre dans le registre TIM1->CCR3 :

const static uint16_t PWM_list[] =
{
59840, 60130, 60400, 60700, 61010, 61310 // -60° -> -10
61580, // 0°
61900, 62190, 62500, 62780, 63050, 63430, // +10° -> +60°
};

Cette mesure expérimentale présentait une irrégularité non négligeable mais en considérant la linéarité du moteur nous avons fait une régression linéaire pour diminuer l’imprécision.

Voici l’approximation graphique obtenue avec open office (courbe de tendance) :

 

On peut voir en haut à gauche de l’image la fonction à utiliser dans notre code C.

Et pour finir, pour interpréter les données obtenues par l’ADC de façon à connaitre plus précisément notre inclinaison nous avions un tableau similaire :

const static uint16_t ADC_list[] =
{
663, 845, 1018, 1169, 1324, 1485, // -60° -> -10
1644, // 0°
1764, 1975, 2127, 2284, 2455, 2611, // +10° -> +60°
};

…et voici l’approximation graphique ainsi que la fonction linéaire associée que nous en avons extrait :

 

On peut voir que R², le coefficient de détermination, est très proche de 1 dans les 2 cas, donc notre linéarisation peut être considérée comme fiable.

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.

[CASPER] Dernières avancées…

Vendredi, nous avons avancé dans le projet sur trois fronts :

- Alain a commencé la modélisation physique de Casper. Le but étant de définir les contraintes pour le contrôle des moteurs. Après quelques expérimentations, nous avons déterminé que la meilleure solution à notre problème est d’utiliser des servomoteurs reliés à des bras mécaniques. D’après nos calculs, nous avons besoin d’un couple minimum de 35 Ncm pour un bras de 7 cm.

- Thibault a quant à lui travaillé sur le PCB et rédigera un billet détaillé à ce propos.

- Pour ma part, j’ai commencé à travailler sur la Beagleboard. Nous avons préparé une carte SD qui contient une partition de boot en fat32 et une partition contenant linux (en ext2). Pour l’instant, la carte boote depuis la carte SD sur Ubuntu (Maverick) 10.10. Nous communiquons par le port série avec la Beagleboard, avons activé la connexion filaire et sommes en train d’installer divers packages.

Copterix : vision et autres avancements

OS:

On a laissé tomber angström pour ubuntu et on l’a installé sur la carte.

Tracking:

La caméra a la mauvaise habitude de rendre des images en « fish eye », j’ai donc utilisé OpenCV pour arranger tout ça, et voici les résultats:

À gauche, l’image telle qu’elle est reçue par la caméra et à droite après application d’OpenCV.

On a aussi compilé mon code qui renvoie le vecteur déplacement détecté sur la Gumstix et on l’a testé, mais on tourne à une image par seconde…
Après test via Cheese, il s’avère que la résolution de la caméra est trop élevée, ce qui explique son si faible débit, je m’apprête donc à y remédier.

Physique:

On a continué à réfléchir, on a vu Wahba et Kalman. Samuel veut coder le FQA, qui résout le problème de Wahba. On aura un post sur la physique demain plus complet.

Copterix : les aventures commencent

Changement de planning :

Suite aux semaines mouvementées que nous avons eu, nous avons refait un planning plus réaliste :

20/03 : Design du PCB (peut dépendre des empreintes disponibles sous Mentor)
21/03 : Lukas & Kanade fonctionnel sur PC
24/03 : Communication Wifi avec la Gumstix pour le streaming video
28/03 : Fin de l’étude physique (Simulation, Kalman)
04/04 : Kalman fonctionnel sur l’IMU
15/04 : Vol stable
22/04 : Déplacement de coptérix

Gumstix :

Nous avons depuis hier deux Gumstix. La première (Tide) n’a pas de flash donc on ne peut pas la briquer…par contre elle n’a pas de Wifi intégré. On utilise donc au début la Tide pour bien prendre en main les Gumstix avant de passer sur la deuxième Gumstix (FE) qui elle supporte le Wifi.

La carte doit booter sur une micro SD. On a donc suivi un tutorial pour pouvoir faire une carte SD bootable à partir d’un noyau précompilé. On a pu aujourd’hui tester la carte et y installer ssh. Par contre, le noyau que nous utilisons ne reconnait pas la caméra. Il faudra soit utiliser un autre noyau pré-compilé soit compiler nous-même le noyau en y rajoutant le driver pour pouvoir utiliser la caméra.

Tracking :

Axel s’est intéressé à l’algorithme de Lucas and Kanade.  Il utilise OpenCV. Voici quelques résultats :
Il a implémenté un petit programme qui montre d’une image à l’autre les déplacements sous forme de traits rouges. L’idée à terme est de faire un filtre médian sur ces vecteurs pour en tirer un vecteur de déplacement fiable.

Rosewheel restructure son planning

Aujourd’hui nous avons pris le temps de réétudier un peu notre planning. Les travaux pratiques de l’UE ont, pour les premières semaines, un peu empiété sur le temps que nous voulions consacrer au projet et quelques modifications s’imposent. Nous pensons néanmoins être toujours dans les temps par rapport à nos objectifs finaux. Notre planning prévisionnel était :

  1. Étude : Kalman, composants, banc de test
  2. Conception PCB : logique, capteurs
  3. Contrôle en vitesse non asservi
  4. Fusion de capteurs & asservissement
  5. Tenir debout, tourner, s’arrêter
  6. Détection d’obstacles
  7. Conception & implémentation contrôle brushless
  8. Conception de l’application Android & video
  9. Soutenance finale

L’étude du filtre de Kalman en première semaine a été concluante. Nous disposons de tous les éléments théoriques pour concevoir le filtre optimal pour notre application. Afin d’assurer un bon équilibre entre robustesse du filtre et complexité des calculs, différentes approches, complémentaires, sont mises en place. Tout d’abord, afin d’assurer la robustesse du filtre aux erreurs numériques susceptibles de se produire du fait de l’utilisation de calculs en virgule fixe, nous comptons utiliser l’algorithme du square root filtering. Ensuite, nous séparerons bien les capteurs entrant dans l’équation d’évolution du système et les capteurs n’ayant un rôle que de « mesure », ceci afin d’alléger la taille des matrices utilisées dans le filtre. Enfin, nous nous placerons dans la situation, fictive, où RoseWheel est toujours immobile. Le mouvement de ce dernier sera vu comme un bruit que nous intégrerons dans les équations et qui, si le choix des différents paramètres est judicieux, nous permettra là aussi d’obtenir des résultats satisfaisant tout en garantissant la simplicité des calculs.

Une étude plus approfondie de la dynamique du système nous a également permis de définir plus précisément nos différentes unités de traitement : filtre Kalman pour supprimer le bruit des capteurs, LQR pour asservissement en inclinaison, LQR pour asservissement en vitesse des moteurs brushless. Il nous manque toujours certaines informations pour pouvoir établir des modèles notamment des informations sur les divers éléments mécaniques et les capteurs. Nous n’avons pas encore finalisé le choix des capteurs et autres composants que nous allons utiliser. Nous avons collecté suffisamment d’informations sur ces derniers mais nous devons maintenant trancher en fonction de plusieurs contraintes : coût, précision, bruit de mesure, disponibilité, délais de livraison, possibilités de collaboration… Par exemple, nous pourrions partager les efforts avec Copterix pour les accéléromètre (MMA7660FCR1), gyroscope (IMU-3000) et capteur sharp (GP2Y0D02YK0F) de façon à factoriser les développements. Mais nous pourrions aussi utiliser des composants plus appropriés comme ce qui a été proposé à la soutenance initiale (nous n’avons par exemple pas besoin de 3 axes pour le gyroscope). Nous allons affiner notre sélection durant les prochains jours pour converger vers un choix final au plus tard samedi prochain (justifications à l’appui) de façon à pouvoir finir les PCB logique et capteurs pour dimanche soir comme prévu..

La première semaine devait également faire l’objet d’une étude sur la réalisabilité d’un banc de tests pour nos capteurs. Suite à plusieurs fausses pistes nous avons finalement trouvé où nous procurer des servos et du bois/plexi. L’implémentation, assez triviale, a bien avancé. La réalisation du banc de test reste tout de même moins prioritaire que l’avancée sur les capteurs et le filtre de Kalman : il est inutile de tester quelque chose que l’on a pas encore conçu. Nous avons donc décidé de reporter la semaine 3, soit la semaine prochaine. Nous devrions avoir un prototype viable en fin de semaine.

Enfin nous avons pris un peu de temps pour développer un simulateur simple de la physique de notre système (pour l’instant tel que décrit dans la thèse de Rich Chi Ooi) à l’aide d’Octave. Cela nous permettra de faire des premiers tests sur le filtre de Kalman et le (les) LQR assez rapidement.

RoseWheel : le retour !

Après une semaine bien dense pendant laquelle certains ont pu travailler sur Kalman et d’autres sur LQR, nous avons aussi avancé dans notre recherche de composants mais il reste encore quelques incertitudes.
Sachant que nous allons partager nos efforts avec Copterix pour les tests des gyroscope et accéléromètre, nous allons prendre les mêmes qu’eux.
Un bon schéma vaut toujours mieux qu’un long discours, voilà donc l’architecture de notre système :
Schéma RoseWheel-AndroWheel

Architecture du projet

 

Pour télécommander notre RoseWheel Nous utiliseront probablement le bluetooth puisque c’est sur tous les téléphones. Nous avous estimé que du bluetooth 2.0 (~1.4MB/s) class2 (portée ~10m) devrait largement suffire pour une première version. De plus, nous aimerions vraiment implémenter un retour vidéo mais ça va dépendre du temps qu’il nous reste.

Si le temps se fait rare, nous pourrions envoyer la vidéo au téléphone sous android grâce à une « caméra wifi » de ce genre :

http://www.bewan.fr/entreprise.php?page=entreprise&parm1=presse&parm2=communique&id=47

=> Nous l’avons trouvé à 56€ ici :

www.cdiscount.com/informatique/materiel-reseau-wifi-internet-bluetooth/bewan-icam-100n-bwbc-100n/f-10715290802-bwbc100n.html

Si nous n’arrivons pas à connecter la caméra directement au téléphone, cette solution impliquerait de passer par un routeur, de streamer la vidéo sur un serveur et de s’y connecter avec l’android.
Si cette solution ne marche pas non plus, nous pensons utiliser une beaglebord ou une gumstix pour y brancher une caméra et envoyer la vidéo au téléphone sous android.

Nous avons plusieur solutions :

- par bluetooth 3.0 (24Mb/s) avec un dongle usb pour une vingtaine d’euros en plus (Nous pourrons utiliser le samsung galaxy S qui  a le bluetooth 3.0 mais sinon c’est rare)

- par wifi, plus démocratisé, mais c’est plus compliqué à utiliser.

La beaglebord a l’avantage d’embarquer un DSP et du wifi mais même si c’est moins cher, c’est bien plus gros qu’une gumstix.

Nous verrons plus tard les codecs de compression vidéo utilisables mais à priori ça suffit largement. Nous devrons donc faire tourner un petit linux dessus ce qui fera grand plaisir à certain d’entre nous ;)

Nous avons également étudié plus en détail la physique du système.
La thèse de Rich Chi Ooi présente un modèle physique assez complet décrivant un gyropode comme une combinaison de trois sous-systèmes : les moteurs, les roues et le chassis.
Nous avons donc refait les calculs pour être surs de les avoir compris et pour éclaircir les points sur lesquels l’auteur passe rapidement.
Par ailleurs ce dernier donne une modélisation intéressante des moteurs à courant continu mais le principe physique des moteurs brushless étant différant, nous devrons peut être réfléchir à un modèle plus approprié.
La modélisation de notre système sous la forme x’= Ax + Bu nous permettra prochainement de mettre en application le cours sur le LQR donné vendredi par nos collègues.

IRL : carte DMX

L’architecture du module DMX se précise…

La future carte DMX devra :
-recevoir les trames DMX
-les patcher avec un masque de 512 octets reçu par zigbee
-les renvoyer
-contenir tout ce qu’il faut pour être programmable…
Je me suis renseignée sur la norme EIA-485 (= RS-485) qui constitue la couche physique du protocole DMX512.
RS-485 utilise trois fils : GND, +, – .
GND sert à protéger la liaison des perturbations electromagnétiques. La liasion est différentielle,si (V+)-(V-) > 200mV on a un 1, si (V+)-(V-)<-200mV, on a un 0. Je me demande si une différence de potentiel inférieure à 200mV est interdite ou si elle constitue l’état IDLE…
Notons que Le RS-485 est half-duplex, mais que le protocole DMX ne l’utilise que dans un seul sens, les éclairages ne renvoient pas d’informations vers la console de commande.

 

Interface µP/DMX512

Notre carte DMX doit comporter deux liaisons RS-485, une pour la réception, une pour la transmission. Il me semble que l’on ne trouve pas facilement des cartes avec du RS-485 déjà fait. Je propose que l’on ne cherche pas et que l’on utilise une GPIO par liaision.

Les interfaces DMX/GPIO comporteraient côté réception:

  • Un connecteur XLR3 ou 5 mâle (à vérifier)
  • Un comparateur (impédance d’entrée supérieure à 12kOhms, qui supporte en entrée du -7 à +12 V et qui a une sensibilité qui permet de détecter une différence supérieure à 200mV)
  • Une résistance de terminaison de 120 Ohms

côté émission:

  • Un circuit pour générer un signal symétrique -U +U avec 1,5V<U<7V
  • Un connecteur XLR3 ou 5 femelle
  • Optionnellement : une résistance de terminaison de 120 Ohms. Elle n’est pas obligatoire sur une liaision RS-485 qui ne comporte qu’un seul émetteur. Sa présence augmente la consommation électrique du câble mais améliore l’intégrité du signal.

La norme DMX512 prévoit des connecteurs XLR 5 broches. Deux des broches ne servent à rien et sont réservées pour des évolutions ultérieures de la norme (retour des appareils). Pour cette raison beaucoup de constructeurs utilisent des connecteurs 3 broches. Il serait plus pratique d’avoir les même connecteurs que TSM. Cependant, le choix n’aura pas de conséquences graves, les adaptateurs XLR3/XLR5 se trouvent facilement.

Zigbee

Pour des raisons de facilité, il est probable que l’on utilise les mêmes modules que telecom robotics et qu’en TP. Ce module nécessite une UART pour la communication avec le µP .

Environnement de développement

Il serait pratique d’avoir une JTAG et une UART supplémentaire.

Récapitulation des connectiques pour le choix du microprocesseur :

  • 2 UARTs,
  • 2 GPIOs,
  • JTAG,
  • ….?

Cela devrait être trouvable…

Puissance de calcul
Il faut :

  • lire une GPIO à 250kHz
  • écrire une GPIO à 250kHz précisément (d’ailleurs il pourrait être intéressant de savoir à quel point il faut être précis…)
  • récupérer, vraiment pas souvent, 512 octets sur le zigbee
  • multi-tâche → il nous faut freeRTOS

Taille mémoire

Difficile à évaluer pour moi, par manque d’expérience. Il faudrait se faire une idée des tailles en RAM/ROM demandées par freeRTOS et zigbee. Notre programme ne va probablement pas être bien long, ni nécessiter beaucoup de RAM.

Kalman, encore du Kalman…

Aujourd’hui, avec Axel, nous nous sommes enfin penchés sur la théorie du filtre de Kalman. Ce qui était une bonne idée, puisque nous y voyons déjà beaucoup plus clair sur le fonctionnement théorique de celui-ci. Il n’empêche que beaucoup d’imprécisions restent encore à lever. Pour implémenter le filtre de Kalman, il faut être capable d’exprimer l’état prédit du système à l’instant k en fonction de l’état du système à l’instant k-1. Pour ce faire, il faudrait tenir compte de l’équation d’état du système (et donc considérer le système dans son ensemble, donc réfléchir d’ores et déjà à la physique du système, avec les hélices).

C’est un point que nous avons du mal à comprendre concernant le filtre de Kalman : dès lors que nous tenons compte de la physique du système, comment peut-on tester la centrale inertielle seule, non intégrée au système final? Pourtant, celle que nous avons déjà pu tester nous-mêmes semblait fonctionner plus ou moins correctement, seule.

 

Il nous reste également à déterminer ce qu’on veut filtrer exactement, si c’est tout le système, ou bien uniquement les gyroscopes. Et encore si on utilise un modèle physique réaliste et donc non linéaire, ou bien si on utilise des astuces pour le rendre linéaire, par exemple en introduisant les mesures et erreurs de mesure dans le résultat (solution proposée par Florian, mais qui reste encore un peu obscure pour moi).

Bref, nous avons avancé sur la compréhension de la théorie, maintenant nous nous heurtons au problème des hypothèses et de l’implémentation. Demain nous devrions essayer de préciser les équations physiques pour voir si nous arrivons à trouver une manière d’exprimer correctement l’algorithme.