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…

[CASPER] Demo de vendredi et API RS232

Voici dans ce post un bilan de la démonstration de Vendredi, ainsi qu’un bref état des lieux des avancées d’aujourd’hui concernant la programmation série en C sous linux.

 

Démonstration de vendredi

Nous avons Vendredi fait état de nos dernières avancées.

Nous avons débuté la démonstration par la présentation du PCB que nous avions réalisé et qu’Alexis nous avait remis il y a peu. Alain a, comme il l’a montré dans un post précédent, réussi à piloter l’écran LCD et afficher une animation simple comportant des rectangles de couleur et du texte.
Reste maintenant à réaliser l’interface série entre la carte et un ordinateur, puis programmer la mémoire flash embarquée.

Nous avons poursuivi par la démonstration de Thomas qui a piloté par l’intermédiaire de la carte de TP STM32 l’un des servomoteurs que nous allons utiliser. Grâce à son programme, nous sommes capables de piloter ces moteurs en leur fournissant une consigne angulaire.
Reste désormais à piloter le prototype en installant trois servomoteurs dans sa base.

Nous avons ensuite effectué une démonstration logicielle qui rassemblait les « helloworlds » que nous avions réalisés avec les différentes bibliothèques. Nous avons ainsi pu piloter à la voix l’ordinateur, lui demander de faire l’apprentissage de deux visages, puis de passer en mode reconnaissance. Une fois en mode reconnaissance, le moteur de synthèse vocale interfacé pour le moment avec pulseaudio a salué les visages connus en les nommant par leurs prénoms.

 

Comme Thomas l’a signalé dans son billet, nous avons pour le moment mis de côté le développement de drivers, pour nous concentrer essentiellement sur la mécanique, la programmation du PCB, et le port de nos applications sur la beagleboard.

Afin de préciser notre démarche, nous publierons bientôt sur ce site une liste actualisée de nos PSCC et des responsables associés.

 

Avancées de la journée : API RS232

De mon côté, je me suis penché sur la programmation du port série en C sous linux. J’ai trouvé à ce sujet une excellente source de documentation, qui m’a permis de comprendre rapidement l’interface posix permettant d’en effectuer la configuration. Vous retrouverez ce guide ici.

J’ai créé une interface de plus haut niveau permettant de lire et d’écrire sur un nombre indéfini de ports série, et de rentre transparente la gestion des lectures et écritures avec tampon.

Il suffit en effet pour utiliser un port série d’en demander l’ouverture en précisant le fichier /dev/tty* associé, et de donner en argument la fonction que l’on souhaite être appelée pour traiter les données.

L’API se charge ensuite d’appeler cette fonction lorsque de nouvelles données sont disponibles, ainsi que d’écrire les données stockées dans des tampons chainés lorsque le matériel est prêt.

L’utilisateur peut donc utiliser des fonctions non bloquantes pour écrire, et utiliser ses propres fonctions pour lire.

Pour finir, bien que cela ne soit pas encore implémenté, il est possible d’ajouter à cette API les sockets en plus des ports série. Cela permettrait de gérer par le biais d’une interface unique toutes les transmissions de la beagleboard, que ce soit par réseau ou avec le PCB.

Copterix : PSSC

Voici nos PSSC avec la date et le responsable :

  • Récupération des données des capteurs du STM32 – Date : 13/04Responsable : Samuel
  • Filtrage de Kalman fonctionnel sur la Gumstix – Date : 13/04 – Responsable : Axel
  • Communication entre la Gumstix et le stm32 avec un protocole permettant de récupérer l’ensemble des valeurs des capteurs et d’envoyer les consignes moteurs – Date : 13/04 – Responsable : Loïc
  • Piloter chaque moteur à la vitesse voulue (i2c) – Date : 15/04 – Responsable : Bertrand
  • Lucas et Kanade opérationnel sur la Gumstix – Date : 20/04 – Responsable : Samuel
  • Contrôler les moteurs en fonction des données des capteurs pour atteindre un vol stationnaire – Date : 20/04 – Responsable : Loïc
  • Gestion des déplacements – Date : 25/04 – Responsable : Bertrand
  • Contrôle avec une télécommande – Date : 25/04 – Responsable : Axel

Copterix : PSSC

Voici la mise à jour de nos PSSC

  • Réalisation d’une carte d’extension fonctionnelle (design PCB)  – Fait
  • Récupérer la vitesse de translation grâce à la caméra  – Fait avec openCV
  • Communication Wifi avec le Copterix  – Statut : Ok en ad-hoc reste à tester avec un routeur wi-fi sécurisé – Date : 08/04
  • Récupération des données des capteurs du STM32 - Statut  : En cours, non testé – Date : 10/04
  • Filtrage de Kalman fonctionnel – Statut : Ok avec l’IMU, modulo un léger bruit,  reste à le tester sur notre PCB – Date : 13/04
  • Piloter chaque moteur à la vitesse voulue (i2c) – Statut : Non commencé – Date : 13/04
  • Communication entre la gumstix et le stm32 avec un protocole permettant de récupérer l’ensemble des valeurs des capteurs et d’envoyer les consignes moteurs – Statut : En cours de debug – Date : 13/04
  • Contrôler les moteurs en fonction des données des capteurs pour atteindre un vol stationnaire – Statut : Non commencé – Date : 20/04
  • Gestion des déplacements - Statut : Non commencé – Date : 25/04
  • Contrôle avec une télécommande – Statut : Non commencé – Date : 25/04

RoseWheel : Avancées de ce lundi

Joao et moi avons passé la journée de Lundi à chercher ce qui ne fonctionnait pas dans le modèle utilisé dans la simulation. En effet, même avec une inclinaison initiale de 5° et avec une tension de commande des moteurs à sa valeur maximale (24V) sans asservissement, le système n’arrivait pas à redresser le RoseWheel pour le ramener à sa position d’équilibre de 0° et il chutait.

Nous avons donc revu tour à tour tous les paramètres de la simulation (Voir ici un récapitulatif des paramètres que nous utilisons : parameters), que nous avons fait varier, nous avons ainsi pu observer leur influence sur l’évolution du système. Il s’est avéré que le seul paramètre critique était la constante de couple des moteurs.  A peu près tous les autres n’ayant qu’un effet sur le temps de chute. Nous avons mesuré rapidement cette constante de couple directement sur le moteur. Nous avons ainsi pu vérifier que la valeur qui était fournie dans la datasheet du moteur correspondait bien avec celle mesurée.

Il s’est finalement avéré que le problème venait des équations que nous utilisions. Nous avons repris toutes les équations et nous nous sommes rendu compte qu’il manquait un facteur 2 au niveau de celles décrivant l’effet de la commande sur les moteurs. Avec ce facteur 2 en plus, tout fonctionne parfaitement et le système est bien asservi avec une tension de commande maximale de 24V.

Nous consacrons donc cette journée de Mardi à peaufiner la simulation, notamment à choisir un set de coefficients optimum pour le LQR. De plus, jusqu’à présent nous utilisions des équations « complètes » pour le filtre de Kalman, c’est à dire que nous prenions pour hypothèse que nous avions accès à la mesure de tous les paramètres du système. Ce qui ne sera pas le cas dans la réalité. Nous allons ainsi choisir ce matin la forme définitive pour le filtre de Kalman et tester en simulation ces performances.

Cet après-midi, nous implémenterons en C cette forme du filtre de Kalman, que nous adapterons au Testbench que Drix a quasiment terminé hier et nous pourrons ainsi tester en réel le filtrage.

Clément a continué d’avancer sur l’implémentation de drivers génériques pour les deux cartes. Nous vous donnerons très bientôt plus de nouvelles à ce propos.

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