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.