Go Down

Topic: Encodeur rotatif (Read 12671 times) previous topic - next topic

jpjcb66

Bonne nuit, merci pour le coup de main.  ;)

john_lenfr


çà permet de quadrupler la resolution , ce n'est pas tres utile avec de l'encodeur basique pour entrée d'info equipé de detente (le click  8) ) , mais avec de l'encodeur de moteur c'est au contraire tres utile.

Pourrais tu préciser pourquoi?

jpjcb66

Pratique ta modif  +1  -1 pour menu  john_lenfr. 
Que des bons sur ce forum. Sympa aussi ton site.
@+

Artouste



La librairie est plutôténorme. Tout ça pour ça.......

Bon je vais pouvoir m'attaquer enfin au menu de ma nouvelle régulation solaire.



Clair que la lib est énorme mais elle est super efficace et prend en charge quasi toutes les cartes

Bonjour
Tant mieux si ça vous convient , si la lib est assez imposante en elle meme, la taille du code généré est en revanche plutot compact e.



çà permet de quadrupler la resolution , ce n'est pas tres utile avec de l'encodeur basique pour entrée d'info equipé de detente (le click  8) ) , mais avec de l'encodeur de moteur c'est au contraire tres utile.

Pourrais tu préciser pourquoi?

pourquoi quoi ?  :smiley-mr-green:
le quadruplement de resolution n'est pas utile avec des petits encodeurs "d'entrée de valeur" , en general ils emportent par construction mecanique "une detente" (encliquetage) , ça ne sert à rien (ou à pas grand chose)  de quadrupler le nombre d'impulsions, ce qui est important c'est de faire +1 ou -1 entre 2 clicks.

en revanche pour faire de l'asservissement de motorisation (vitesse et/ou position) cela revient à quadrupler la resolution.

là je teste un asservissement de position avec un encodeur 2000 imp/tours
la resolution angulaire theorique est donc de 360/2000 = 0.18°
si pour positionnement j'utilise une tige filetée standard metrique ? 16 (pas de 2) , j'ai une resolution theorique de deplacement lineaire au µ .
(evidemment la theorie, c'est sans tenir compte des "lutins sournois" des jeux mecaniques  8) )

john_lenfr

#34
Apr 09, 2014, 01:46 pm Last Edit: Apr 09, 2014, 01:57 pm by john_lenfr Reason: 1
Je ne saisi quand meme pas trop le principe car "click" ou pas "click" quand on bouge d'un pas on bouge d'un pas.
En quoi le fait d'avoir 4 fois la meme valeur pour un pas change?

Artouste

#35
Apr 09, 2014, 02:00 pm Last Edit: Apr 09, 2014, 02:12 pm by Artouste Reason: 1

Je ne saisi quand meme pas trop le principe car "click" ou pas "click" quand on bouge d'un pas on bouge d'un pas.
En quoi le faire d'avoir 4 fois la meme valeur pour un pas change?

8)
oui et non  :smiley-mr-green:
le crantage,detente (click) impose un maintien mecanique, ce maintien mecanique impose la position du dephasage des canaux A/B.
Si tu teste les sorties de ton encodeur 20 pas/click  (20  pour la demo, mais ça vaut pour d'autres valeurs) et que tu releve à l'ohmetre la table de verité A/B à chaque cran, tu va recupérer une table qui va boucler toutes les 20 positions etablies.
Si tu supprime ce "crantage" (en general une bille ou un cliquet)  ton encodeur est en mesure de te fournir 4 fois plus de positions .
Tu n'a pas 4 fois la meme valeur si tu ne divise pas par 4 , tu a des valeurs uniques , mais masquée par l'etat stable
un encodeur "20 clicks" renvoi 80 imp/tours ou plus exactement 80 changements d'etats combinés 2 à 2  par tour


john_lenfr

Ok, tout dépend de la résolution de l'encodeur alors.
On ne peux quand même pas aller au delà de la résolution de l'encodeur, même quand il est débridé?
Donc si je débride mon encodeur en enlevant le système à bille, normalement je me retrouve avec un encodeur classique 'libre" pour lequel les 4 positions veulent dire quelque chose, bien que les doigts humains ne puisse pas les déceler c'est bien ça? (sauf à mettre un bras de levier important pour pouvoir tourner tout doucement au niveau angulaire).

En revanche pour du positionnement de moteurs pas à pas où le µm compte cela a un intéret.

Artouste


Ok, tout dépend de la résolution de l'encodeur alors.
On ne peux quand même pas aller au delà de la résolution de l'encodeur, même quand il est débridé?
...

8)
evidemment
il faut que tu raisonne en changement d'etat/dephasage
pour demo : si tu te fous comme de ta premiere chemise du sens dce rotation
ce n'est In fine que du comptage de changement d'etat

si tu prend un disque avec 4 secteurs alternés noirs et blancs
tu peux detecter facilement l'etat actuel d'un secteur (noir ou blanc )
mais aussi detecter le nombre de transitions d'un etat à un autre,  qui lui est de 2 par secteur = une transition en entrée , une transition en sortie , et si tu dephase physiquement de 90 ° (ou plus exactement là une demi distance de secteur)  2 capteurs
tu recupere 4 signaux differenciés et de quoi en determiner le sens de rotation.

john_lenfr

Ok, je comprends mieux pourquoi ça s'apelle un "quad"encoder  :smiley-mr-green:

Et donc l'encodeur à bille avec environ 20pas a une résolution très mauvaise du coup.

Artouste


Ok, je comprends mieux pourquoi ça s'apelle un "quad"encoder  :smiley-mr-green:

Et donc l'encodeur à bille avec environ 20pas a une résolution très mauvaise du coup.

non , il est prevu pour etablir mecaniquement  toujours un etat stable toujours déphasé  :smiley-mr-green:
ça existe depuis longtemps,  simplement aujourd'hui il est devenu aussi  interessant (puissance de calcul) de ne pas/plus simplement verifier un etat fini, mais aussi de regarder la relations de transitions  :smiley-mr-green:

une bonne et didactique explication est sur la page de PJRC
http://www.pjrc.com/teensy/td_libs_Encoder.html
voir l'animation sous Understanding Quadrature Encoded Signals


john_lenfr


Artouste

ou comment oublier d'avoir des certitudes  :smiley-mr-green:
Un petit retour avec des encodeurs "etrangers" = pas de datasheet dispo
comme expliqué plus haut , je fais un systeme de positionnement X/Y en utilsant de l'encodeur derriere un moteur CC
Apres une rapide verif (lib encoder) , je determine un disque 500 secteurs = super une belle valeur entiere
mais en situation , je derive,  faiblement mais je derive sur le positionnement.
Apres un test sur plusieurs tours , je m'aperçois que l'erreur de derive est constante, le retour à zero sur le nombre d'impulsion se fait bien.
Je determine facilement que je n'ai pas 2000 imp/tour mais 2016 , ce qui correspondrait à un disque de 504 secteurs.
500 ou 512 je n'aurais pas été "perturbé"  :smiley-mr-green: , mais 504 ? (ça ne vient pas de chez peugeot , mais de chez HP  :smiley-mr-green: )

Idée : ça doit etre un 512 et je  dois avoir des decoupes/gravures  bouchées/empoussiérée sur le disque (déjà vu)
passage à l'analyseur logique (à rotation constante) pour voir si je detecte de l'anomalie de creneaux = nada
Je me decide donc à regret d'ouvrir l'encodeur pour verifier l'etat du disque et là gros comme un nez au milieu d'une figure
un beau 504 gravé sur le disque.  :smiley-mr-green:
Il y a surement une bonne raison de conception initiale pour ce choix de 504 , le principal c'est que maintenant je ne derive plus  :smiley-mr-green:




s1der

Salut ,
Je profite de ce topic pour poser une question bien bête j'imagine (je suis très débutant  :smiley-sad-blue: ) ...
Je voudrais utiliser un codeur rotatif pour naviguer dans un menu et pour dimmer des leds en PWM.
J'ai essayé plusieures lib mais je ne parviens pas à incrémenter ou décrémenter de +1/-1 de manière stable.
J'utilise les pins 6 et 7 sur mon arduino uno R3 et le codeur est un KY040 (5 pins avec switch).

Dans la lib de PJRC, je ne comprends pas les lignes :
Code: [Select]
Encoder knobLeft(5, 6);
Encoder knobRight(7, 8);


Dans le moniteur série voilà ce que j'ai en tournant 1 cran à droite :
Code: [Select]
TwoKnobs Encoder Test:
Left = 0, Right = 0
Left = 1, Right = 0
Left = 0, Right = 0
Left = 1, Right = 0
Left = 0, Right = 0
Left = 1, Right = 0
Left = 1, Right = -1
Left = 1, Right = 0
Left = 1, Right = -1
Left = 0, Right = -1
Left = 1, Right = -1
Left = 0, Right = -1
Left = 0, Right = 0

et un cran à gauche :
Code: [Select]
TwoKnobs Encoder Test:
Left = 0, Right = 0
Left = 0, Right = -1
Left = 1, Right = -1
Left = 0, Right = -1
Left = 1, Right = -1
Left = 1, Right = 0
Left = 1, Right = -1
Left = 1, Right = 0
Left = 0, Right = 0

Ce n'est jamais 2 fois pareil et right est toujours en -1 et left en +1...

Ma question est donc quel est le moyen le plus simple d'incrémenter une variable de +1 ou -1, avec quelle lib etc ...

Merci de votre aide  :smiley-sweat:

john_lenfr

#43
Apr 20, 2014, 07:10 pm Last Edit: Apr 20, 2014, 07:14 pm by john_lenfr Reason: 1
Si tu remontes un peu plus haut dans ce topic:
http://forum.arduino.cc/index.php?PHPSESSID=tmrjm8rn0brqrv3hgnhffmls36&topic=231757.msg1671603#msg1671603

Tu verras que j'avais justement donné la solution concernant le+1 -1 avec la lib encoder.h dont Artouste a donné le lien

Depuis la réponse que j'avais fait j'ai légèrement modifié la routine en:
Code: [Select]
// returns 1 for right, -1 for left, or 0 for no movement
int readEncoder() {
 // if 'int' is not enough, use 'long' instead (int: -32768 to +32767 and long: -2147483648 to +2147483647)
 // for a lcd menu 'int' is OK
 moved = true;
 int newPosition = encoder.read()/4; // the lib is so accurate that it provides 4X counting mode and is highly optimized code when running on Teensy or Arduino boards
 int pos=0;
 if (newPosition != oldPosition) {
   pos = oldPosition-newPosition;
   oldPosition = newPosition;
   return pos;
 }
 moved = false;
 return pos;
 
}


Le lien pour la librairie est celui ci:
http://www.pjrc.com/teensy/td_libs_Encoder.html

s1der

Merci john_lenfr
mais je ne saisis pas bien ce que tu veux dire par modifier la routine.
J'ai essayé le code que tu as mis en page 2 mais je ne comprends pas quoi remplacer par ton code page 3 ...
le code page 2 fonctionne à peu près (j'ai changé les numéros de pins).
encoder devient myEnc dans ta nouvelle routine je pense et après...  :smiley-roll-sweat:

Go Up