ELECINF344/381

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

Catégories

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.

Sur le même sujet :

  1. RoseWheel: banc de test (capteurs et Kalman)
  2. Kalman, encore du Kalman…
  3. RoseWheel : Simulation filtre de Kalman
  4. [RoseWheel] Implémentation du filtre de Kalman
  5. RoseWheel : banc de tests et filtre de Kalman

Commentaires fermés.