Bien calibrer un moteur encodeur.

Bonjour,

J’ai un probleme pour que mon moteur arrive exactement à 100 tours.
Il va un peu plus loin que demandé. Et donc au bout de 200 tours, il a 1/4 de tour en trop.

Je pense que j’ai une probleme pour bien connaitre et bien defenir dans le programe le nombre de tick pour un tour exactement de mon moteur. Voila ces caracteristiques:

GM4632-370 DC 12 V 30 RPM Moteur à Engrenages Engrenages
Caractéristiques:
Matériel: Métal
Tension: DC 12.0V
L’extrémité du moteur du codeur 11 signale
Tension d’entrée (V) 12
Ratio de réduction de retardateur 1: 200
Pas de vitesse de charge (RPM) 30
Pas de courant de charge (mA) ≤60
Couple nominal (kg.cm) 10.0 Kg.cm
Vitesse nominale (RPM) 21
Courant nominal (A) ≤0.4
décrochage Torque ≥ 32 Kg.cm
StallCurrent (A) ≤1.0
Résolution Hall 2200

Au debut, j’'ai reglé dans mon programme

const float  NBTICKSPARTOURSCODEURS = 11.0 ;//7;
const float GEARRATIO = 200;//
const float NBTICKSPARTOURSSORTIE = (float)  (NBTICKSPARTOURSCODEURS * GEARRATIO * 4);

Mais je me suis aperçu que le moteur ne faisait pas du tout le bon nombre de tour et le compte tour de mon programme ajoutait un tour alors que le moteur n’était pas revenu à son point d’origine.
J’ai donc fait faire 100 tour à mon moteur, en le faisant tourner à 24 tour/min, il faut 250sec, et en fait presque 104, et à l’oeil j’ai jugé qu’ il en a fait 103.875.

J’ai fait un produit en croix pour recalculer le geraratio
200 → 103.875. Alors pour avoir 100 tours, j’ai fait 100*200/103, 875 = 192.54.

En remplaçant 200 par 192.54, le moteur va un peu plus loin que prévu, mais le compte tour déclenche bien un tour en plus quand le moteur repasse par son point départ.

Pour être plus précis, j’ai fait mon test sur 200 tour en mettant 192 pour gearration et là, j’ai presque 1/4 de tour en trop.
Donc, j’ai refait un produit en croix et j’arrive à 191.78, mais là il me manque + de 3/4 de tour.

En tâtonnant sur le réglage du geraratio sur 100 tours (car 200 c’est trop long), j’arrive avec un gearratio de 191.9 à faire 99.5 tours au lieu de 100.

Donc sur des test pour 100 tour
Avec un gearrationde 191.95 ou 191.97 ou 191.98 ou 191.985 ou 191.987 , j’arrive 99.6 tour.
Alors qu’avec un gearratio de 191. 989 ou191. 99 ou 192, le moteur fait 100 tour + 1/8 de tour (ce qui est cohérent puisque sur 200 tours, il faisait 1/4 de tour en trop.)

Ce qui est bizarre c’est qu’en chantant le gear ratio comme ci dessus, j’obtiens le meme montre tour exactement et qu’il semble il y avoir un basculement autour de 191.98x.

Alors comment faire pour que le programme prenne en compte un gear ratio plus précisément.
J’ai multiplié par 10 le nombre de tick pour que le programme prenne en compte, plus de chiffre après la virgule.
Comme ceci

// Fonction timer
void timer3Interrupt() {
  for(uint8_t i = 0; i < NBMOTEURS; i++) {
    vitesse[i] = compteur[i];
    compteur[i] = 0;
    position[i] += vitesse[i]*10;//10
    positionAbsolue[i] += vitesse[i];
    
    while(position[i] >= NBTICKSPARTOURSSORTIE*10) {//10
      position[i] -= NBTICKSPARTOURSSORTIE*10; //10
       passeParZero = 1;
    }
    while(position[i] < 0) { 
      position[i] += NBTICKSPARTOURSSORTIE*10; //10
       passeParZero = 1;
    }

     if(passeParZero) { // Quand le moteur passe par 0 incrémenter les nombre de tour
      actionX(i);
      passeParZero = 0;
      
    }
    
  }

Mais là, mon compteur écrit 303 tour au lieu de 100 et mon moteur fait toujours 1/8 tour en trop avec un gear ratio de 191.989 et 99.6 tour avec un gearratio de 191.988.

Le moteur est controlé par un PID et il y a des fonctions de position ,recallage et autre qui n’a pas d’intérêt pour ce problème. Ce sont des fonction pour les moteurs tournent dans la même position, de manière synchronisé en vitesse et en phase.

Merci pour votre attention et vos idées :wink:

rpm_set_time_light.ino (15.3 KB)

Bonsoir
ton bloc motoreducteur/encodeur c'est çà ?

Si oui , il doit y avoir déjà "un jeu" bien fluctuant au niveau du transfert de la vis sans fin (propagation d'erreurs dues au glissement mecanique)

A priori le rapport de réduction mécanique serait de 1/200 et l'encodeur en quadrature sur l'axe primaire et basé sur des capteurs hall aurait une résolution de 2200 points par tour (çà me semble beaucoup comme résolution au vu de la photo )

Ce ne serait pas plutôt 2200 points par tour de l'axe de sortie ce qui "collerait" avec le 11 de la phrase un peu mystérieuse "L'extrémité du moteur du codeur 11 signale".
On aurait donc :

  • 11 impulsions par tour moteur
  • un rapport de démultiplication de 1:200
    et donc 2200 impulsions pour un tour de l'arbre de sortie.

fdufnews:
Ce ne serait pas plutôt 2200 points par tour de l'axe de sortie ce qui "collerait" avec le 11 de la phrase un peu mystérieuse "L'extrémité du moteur du codeur 11 signale".
On aurait donc :

  • 11 impulsions par tour moteur
  • un rapport de démultiplication de 1:200

et donc 2200 impulsions pour un tour de l'arbre de sortie.

Bonjour fdufnews
Avec ce genre de produit asia aux specifs... lcunaires , tout peut exister
Je ticke un peu sur le 11 pulses/tour de l'arbre primaire(moteur) , un nombre impair pour de l'encodeur en quadrature sur un canal A ou B çà me semble "un peu trop exotique" :grin:

Ceci etant

Sur ce genre d'encodeur en général les capteurs hall ne changent d'état qu'aprés inversion de l'etat magnétique presenté et comme les 2 encodeurs semblent décalés de 90° , dés lors que l'on ne se préoccupe que de la lecture d'un canal , le nombre de changement d'etat sur le canal considéré depend du nombre de pôles N/S alternés presents sur la circonférence

Sur les encodeurs les plus cheaps , c'est souvent seulement un N et un S sous forme de 2 demi segments circulaire collés.

Tout çà ajouté à de la mecanique de reduction surement sans vrai rattrapage de jeu (anti backslash) lors des inversion des sens moteur, ne sont pas des conditions vraiment idéales pour esperer faire du (re)positionnement précis en sortie.

Artouste:
Bonsoir
ton bloc motoreducteur/encodeur c'est çà ?

Si oui , il doit y avoir déjà "un jeu" bien fluctuant au niveau du transfert de la vis sans fin (propagation d'erreurs dues au glissement mecanique)

A priori le rapport de réduction mécanique serait de 1/200 et l'encodeur en quadrature sur l'axe primaire et basé sur des capteurs hall aurait une résolution de 2200 points par tour (çà me semble beaucoup comme résolution au vu de la photo )

Oui j'ai effectivement ce moteur. Mais là je travaille suri celui là qui a exactement les memes caracteristiques .

Le mien c'est le 30 rpm avec un ration 1/200 et 11 impulsion.

J'ai essayé 2200 en nombredetick par tour mais évidement tout est déréglé.
En testant sur 40 tour, mon compte tour me met 153 tour
J'ai dû multiplié par 3.84 la vitesse pour arriver vraiment aux alentours de 40 tour. (compté 153 par le programme).

J'ai donc remis un gear ratio de 192.
Donc 192114= 8448 ticks par tour.

Je trouve étrange qu'en multipliant*10 dans la fonction timer (sur mon post precedent) les positions et vitesses, il y a une difference du nombre de rotation avec des gear ratio de 191.988 et 191.989 soit 84474.72 et 84475.16 ticks par tour
Dans le premier cas, il manque 1/2 tour sur 100, dans le deuxième j'ai 1/8 tour en trop sur 100.

J'ai donc *100, et là j'observe une différence entre 191.9895 et 191.9887. Sauf que cette différence de rotation est là même que ci - dessus à savoir pas assez ou trop de tour.

Donc à moins de réinitialiser mon installation tous les 100 tours par exemple, je pense qu'il n'y pas de solutions.

Si vous connaissez des moteurs+ encodeurs qui ne se décale pas dans le temps et puisse faire tourner une barre en acier de 1.50 m où est accroché une boule creuse de 25 cm de rayon, je serai hyper content. :slight_smile:

Si vous connaissez des moteurs+ encodeurs qui ne se décale pas dans le temps

Je pense que tu prends le problème à l'envers.
Le nombre de dents des pignons ne change pas dans le temps.
Le nombre de pôles de l'aimant ne change pas dans le temps.

Il faudrait peut-être s'assurer que le logiciel est parfaitement fiable avant de continuer. En particulier il faudrait être certain que ton soft ne rate pas de temps en temps des impulsions de l'encodeur.

Ou alors la charge est trop lourde et la vis sans fin patine sur son axe (bien que cela me paraisse un peu surprenant). Ce n'est pas difficile à vérifier en faisant tourner le moteur à vide ou avec juste une aiguille montée sur l'axe pour avoir un repère de position précis.

bvking:
...
Donc à moins de réinitialiser mon installation tous les 100 tours par exemple, je pense qu'il n'y pas de solutions.

Si vous connaissez des moteurs+ encodeurs qui ne se décale pas dans le temps et puisse faire tourner une barre en acier de 1.50 m où est accroché une boule creuse de 25 cm de rayon, je serai hyper content. :slight_smile:

:grin:

Il faut déjà que tu dimensionne le plus precisement possible ton équipage mécanique

et là çà manque cruellement d'info primordiales

Par exemple une barre en acier de 1.50 m , je peux t'en trouver (au moins intellectuellement là :smiley: ) qui pèsent plusieurs tonnes :grin: selon la géométrie de la section :grin:

Une boule creuse de 25cm de rayon , ça n'est pas parlant non plus , densité de la matiére ? , volume du creux ? :smiling_imp:

tu veux faire quoi exactement "un élément" de planétarium ? :wink:

fdufnews:
Il faudrait peut-être s'assurer que le logiciel est parfaitement fiable avant de continuer. En particulier il faudrait être certain que ton soft ne rate pas de temps en temps des impulsions de l'encodeur.

Ou alors la charge est trop lourde et la vis sans fin patine sur son axe (bien que cela me paraisse un peu surprenant). Ce n'est pas difficile à vérifier en faisant tourner le moteur à vide ou avec juste une aiguille montée sur l'axe pour avoir un repère de position précis.

Là, je fais des tests avec une équerre plate de 100 grammes maximum. Donc tests quasi à vide.
Avec le nombre de test que j'ai fait, je me suis aperçu que les 2 moteurs se placent exactement au même endroit au bout de 100, 200 ou 50 tours selon le gear ratio.
Les encodeurs sont alimentés via la sortie 3.3V de ma carte Arduino Due, donc elle devrait être très stable.

Artouste:
:grin:

Il faut déjà que tu dimensionne le plus precisement possible ton équipage mécanique

et là çà manque cruellement d'info primordiales

Par exemple une barre en acier de 1.50 m , je peux t'en trouver (au moins intellectuellement là :smiley: ) qui pèsent plusieurs tonnes :grin: selon la géométrie de la section :grin:

Une boule creuse de 25cm de rayon , ça n'est pas parlant non plus , densité de la matiére ? , volume du creux ? :smiling_imp:

tu veux faire quoi exactement "un élément" de planétarium ? :wink:

En fait, j'aimerai faire tourner des boules les plus légères possibles ( creuse en acier, aluminium , bois, PVC ) qui sont accrochés à l'axe moteur avec une barre la plus fine et légère( acier, alu, bois, PVC possible) car c'est le mouvement des boules qui m'intéresse.
Je pense "léger" car j'imagine que la puissance du couple fait augmenter le prix du moteur..
Il pourrait y avoir une autre version ou la barre serait fixé au centre et il aurait une boule de chaque coté. Et dans ce cas la barre ferait trois mètres. (et le couple est le meme non?) :roll_eyes: