Robotique Compteur en quadrature : besoin d'aide

gassiune
Nouveau
9 Avril 2015
26
  • Auteur de la discussion
  • #1
Bonjour,

J'ai un petit souci de compréhension concernant l'avantage évident qu'on ces circuits (type ls7366): décharger le micro-contrôleur. Je n'arrive pas à me convaincre qu'il y a un gain important.

Exemple pratique avec une boucle d'asservissement PID:
- Sans compteur dédié, les codeurs sont reliés aux broches d'interruptions du micro et, à un interval de temps régulier, la fonction de calcul du PID est exécutée.

-Avec compteur dédié, les codeurs sont reliés au compteur qui lui même est relié au micro. Le micro est libéré des interruptions mais je présume qu'il doit interroger très régulièrement le compteur avant d'exécuter sa fonction de calcul.

Du coup il est où le gain ?
 
xavierblond
Nouveau
29 Octobre 2016
3
Sans compteur dédié, ton micro-contrôleur va sans-cesse être interrompu dans son programme, alors qu'avec un compteur dédié, c'est le programme de ton micro-contrôleur qui décide quand lire les compteurs.

Dans le cas où tu as peu d'impulsions lentes, tu peux avoir intérêt à utiliser directement des pins d'interruption pour simplifier le matériel.

Si par contre tu as besoin de précision (asservissement numérique), l'intervalle entre les échantillons importe aussi. Dans le cas d'un compteur hardware, la durée et l'intervalle de lecture est constant et ne devrait pas être perturbé par d'autres interruptions. Sans compteur matériel, tu peux arriver aux limites des performances du MCU et du coup ne pas avoir un intervalle constant entre chaque lecture (et du coup avoir un asservissement imprécis voir instable).

Pour un ordre de grandeur, avec un MCU 8-bit à 16MHz (Arduino) et des codeurs à 500ppr, on arrivait aux limites à 150tr/min et un asservissement à 100Hz.
 
gassiune
Nouveau
9 Avril 2015
26
  • Auteur de la discussion
  • #3
Tu veux dire que c'est simplement le fait de "gaver" le micro avec trop d'interruption qui cause l'instabilité?

Dans mon cas j'ai 4 codeurs à 480ppr et un micro 32bits à 83Mhz (vitesse maxi des moteurs 350 tr/min). J'aimerais savoir comment tu fais ton calcul de limite pour que je puisse l'appliquer à mon cas perso.
 
xavierblond
Nouveau
29 Octobre 2016
3
Oui, dans le cas que j'avais testé (sans aucun calcul), le MCU était à une charge de 100%, et du coup prenait plus de temps pour executer sa boucle d'asservissement.

Avec un MCU 32bits à 83MHz, je ne pense pas que tu aies trop de problèmes. Une solution assez fiable pour mesurer la charge d'un MCU est de changer l'état d'un GPIO en début et en fin de cycle. Le rapport cyclique donne la charge sans trop changer la vitesse d'execution du programme (contrairement à du debug sur port série).
 
syoctax
Apprenti
26 Janvier 2012
221
Chartreuse
Tu veux dire que c'est simplement le fait de "gaver" le micro avec trop d'interruption qui cause l'instabilité?

Dans mon cas j'ai 4 codeurs à 480ppr et un micro 32bits à 83Mhz (vitesse maxi des moteurs 350 tr/min). J'aimerais savoir comment tu fais ton calcul de limite pour que je puisse l'appliquer à mon cas perso.
Salut gassiune,

Quel est la référence de ton microcontrôleur? Certains embarquent l'équivalent du ls7366 comme périphérique, ainsi tu économises le composant et le temps de traitement lié à la communication avec celui-ci.

Par exemple, nous utilisons des STM32 dont certains peuvent avoir les 4 interfaces pour les codeurs dont tu aurais besoin. Une fois configurés, la gestion des codeurs ne prend pas de ressource CPU et il suffit de lire l'état de chacun des compteurs qui sont stockés dans des registres indépendants.
A noter cependant que la plupart ont des compteurs 16bits, ce qui peut être limitant dans certaines applications (mais une fonction peut s'occuper de scruter ce compteur et le stocker régulièrement dans un compteur 32bits).
 
Dernière édition:
pwet
Nouveau
6 Juin 2014
30
Je ne vois effectivement pas ou est le gain significatif de déporter le comptage sur un composant dédié plutôt que d'utiliser les compteurs internes du micro-contrôleur.

Exemple chez nous pour la coupe de france :

Microcontrôleur dsPIC 16 bits @40 MIPS
Compteur QEI 16 bits en hard (gérés en 32bits en soft)
Double asservissement PID @ 1ms
Codeurs 500 pts

J'ai eu un peu de mal à gérer correctement les overflow/underflow, il y a une interruption qui apparaît à chaque fois qu'un tel événement se produit, mais c'est tout.

Ca fait plusieurs année qu'on utilise ça sans problème.
 
gassiune
Nouveau
9 Avril 2015
26
  • Auteur de la discussion
  • #7
Quel est la référence de ton microcontrôleur?
C'est un module ROVIN basé sur un processeur ARM 32 bits ARM7TDMI.

J'ai beaucoup galéré mais j'ai fini par trouver un fournisseur (Omni Pro Electronics) qui vend des LS7366R en boitier DIP à un prix raisonnable (dans les 3$). Quand je les auraient je ferais l'essai avec pour voir.
 
louloute30
Compagnon
5 Juillet 2010
1 594
Il y a qq années en coupe de france, sur l'ascenseur du robot, j'avais un moto-réducteur avec encodeur placé sur le moteur (et non après le réducteur), cela me donnait qqch comme 18000 impl pour 1 tour de l'arbre après réducteur, donc, un déplacement de 2cm sur la visse à bille. Là, avoir un composant dédié était nécessaire...
 
gassiune
Nouveau
9 Avril 2015
26
  • Auteur de la discussion
  • #9
Merci à tous pour vos contributions j'y vois un peu plus clair, je vais voir maintenant ce que les tests pratique me disent.
 
pwet
Nouveau
6 Juin 2014
30
Il y a qq années en coupe de france, sur l'ascenseur du robot, j'avais un moto-réducteur avec encodeur placé sur le moteur (et non après le réducteur), cela me donnait qqch comme 18000 impl pour 1 tour de l'arbre après réducteur, donc, un déplacement de 2cm sur la visse à bille. Là, avoir un composant dédié était nécessaire...
Je dois surement passer a coté de qqchose mais je ne vois pas ou est le problème pour faire encaisser cette vitesse de comptage à un compteur QEI interne de microcontrôleur.
 
louloute30
Compagnon
5 Juillet 2010
1 594
Je dois surement passer a coté de qqchose mais je ne vois pas ou est le problème pour faire encaisser cette vitesse de comptage à un compteur QEI interne de microcontrôleur.
J'avais une arduino... la mega 2560 ou sur une nano (328)... Pas de QEI dessus, que je sache. Donc, j'utilisais les interrupts, je perdais à vitesse lente quelques milliers d'impul, et à grande vitesse, plus de la moitié ne passait pas.

Sur un QEI interne de µcontroleur, c'était autre chose... avec le même moteur:
 
gassiune
Nouveau
9 Avril 2015
26
J'ai pu faire quelques essais tout à l'heure et c'est pas brillant :cry:

L'essai consistait simplement à faire un tour de roue (soit 30 tours moteur qui représentent 480 impl) sans asserv à seulement 2 moteurs et afficher sur mon écran LCD le nombre d'impulsions comptées par les codeurs montés en interruption sur le module. Le truc de base quoi.

Avec mes moteurs pilotés à une vitesse <=40% (soit <=70tr/s) tout fonctionne comme prévu. Si par contre je monte au dessus alors là c'est le merdier, les moteurs continuent à tourner au delà d'un tour. J'ai remarqué qu'en débranchant le 2éme codeur les moteurs continuaient à tourner moins longtemps. Pire encore la valeur affichée ne correspond pas au nombre de tours fait, il en manque plein... mais vraiment plein.
Constat amer : ce module n'est pas capable de gérer correctement une freq d'interruption égale au Khz. Dans la doc il n'y a rien à ce propos d'ailleurs.
Là pour le coup je suis :eek::eek::eek: .J'ai pas le choix de passer par des compteurs dédiés si je veux conserver ce module (ce qui m'intéresse c'est la solution multitâche qu'il fourni).
 
pwet
Nouveau
6 Juin 2014
30
Ha oui d'accord, c'est clair que compter des signaux en quadrature avec des interruptions sur changement d'état, faut pas s'attendre à grand chose de glorieux !

J'avais découvert sur le web une astuce qui consiste à utiliser (si tu as) deux entrées compteurs normales, et avec une simple bascule D tu transforme les signaux A et B en signaux CLK et CCLK.
Le principe en gros c'est de n'avoir plus qu'un signal qui transporte les fronts qui correspondent à un sens de rotation, et un autre signal qui transporte les fronts qui correspondent à l'autre sens de rotation.

Ensuite l'opération est simple, il suffit de soustraire les deux registres de comptage.
 
gassiune
Nouveau
9 Avril 2015
26
J'avais découvert sur le web une astuce qui consiste à utiliser (si tu as) deux entrées compteurs normales, et avec une simple bascule D tu transforme les signaux A et B en signaux CLK et CCLK.
Le principe en gros c'est de n'avoir plus qu'un signal qui transporte les fronts qui correspondent à un sens de rotation, et un autre signal qui transporte les fronts qui correspondent à l'autre sens de rotation.
Oui j'avais oublié de préciser que mon test n'incluait qu'un seul canal par capteur. J'avais effectivement prévu d'utiliser une bascule (hef4013 dans mon cas) pour déterminer le sens.
 
romain_cvra
Ouvrier
30 Juin 2011
476
Suisse
Salut,

Je rejoint ce qu'on dit les autre intervenant.

Sans compteur codeur hardware, c'est rapidement limité pour le nombre de puls/s malheureusement...

Si tu veux continué avec le Rovin, un compteur codeur hardware externe comme celui que tu proposes est la solution.
Si non, l'autre solution est de changer de microcontrôleur et d'en choisir un avec suffisamment de compteur codeur hardware interne pour ton application.
Pour info, suivant le fabriquant, le nom de compteur codeur hardware peuvent changer...

Par exemple, dans nos robots nous utilisons une carte d'évaluation de chez ST, la Nucléo-144 .
http://www.st.com/en/evaluation-tools/stm32-mcu-nucleo.html?querycriteria=productId=LN1847

A+
 
La dernière réponse à ce sujet date de plus de 6 mois
Haut