Récupérer le signal de chaque codeur et obtenir la distance parcourue par la roue.
Vous avez vérifié le bon fonctionnement des codeurs, tel que décrit dans la partie « Mise ne route d’un PAMI ».
Les codeurs relatifs sont des capteurs qui mesurent un déplacement. Ils émettent une impulsion à chaque fois qu’une distance connue est parcourue. En comptant les impulsions renvoyées, nous calculons la distance parcourue. C’est le premier principe de ces capteurs.
Le second principe consiste à doubler le dispositif de détection pour obtenir un second signal décalé par rapport au premier.
Voici en détail ce qui se passe au niveau des deux capteurs :
La combinaison des deux signaux permet de déduire le sens de rotation de déplacement.
Nous pouvons formuler ceci de deux façons :
Les deux formulations sont équivalentes. La première est peut-être plus intuitive, la seconde plus facile à coder.
C’est une tâche qu’il ne faut pas laisser au cœur de votre microcontrôleur. Celui-c aura plein d’autres tâches que de guetter ces impulsions.
Utilise des interruptions ? C’est peut-être la plus mauvaise des solutions acceptables. Si votre microcontrôleur est assez rapide…
Dans les bonnes solutions, vous utilisez un composant externe spécial, nommé parfois Quadrature Counter, qui décode ces signaux et qui communiquera en I2C ou SPI avec votre microcontrôleur. Ou mieux, vous avez un microcontrôleur qui intègre un module de décodage de signaux en quadrature (QEI), de la même manière qu’il intègre un module PWM.
Est-ce que le RP2040 intègre un tel module ? Non, mais il dispose de PIO – comme des mini-cœurs annexes – qui peuvent reproduire des modules QEI, sans impacter les performances du cœur principal. Nous utiliserons l’exemple fourni par la Raspberry Pi Fondation comme base pour notre code.
Et sinon ? Si vous utiliser des ESP32, ils sont presque tous équipés de modules Pulse Counter, certains rares PICs sont équipés de QEI (tel que le DSPIC33FJ128MC802).
Pour ce module, nous créerons ces trois fonctions :
C’est dans ce module que se trouve la constante de conversion des pas de l’encodeur en millimètres parcourus par la roue.
Envoyez, pour chaque codeur, la vitesse et la position, en unité arbitraire :
Plus vous appelez QEI_update() fréquemment, plus la résolution de votre vitesse sera faible. Dans un premier temps essayez d’appeler la fonction QEI_update() toutes les millisecondes. Puis refaite un essai avec un appel toutes les 10 millisecondes.
Note : envoyer les données du microcontrôleur à l’ordinateur prend du temps, parfois plus d’une milliseconde. Notre code en exemple montre les effets du temps d’acquisition sur la résolution, mais l’envoie des données nous empêche d’avoir un cycle constant à une milliseconde. Par la suite, nous chargerons le second cœur du microcontrôleur de gérer l’envoi au PC tandis que le cœur principal gérera les fonctions liées au déplacement.
Vous devriez obtenir ce type de graphique où le lien de dérivation entre la position et la vitesse est clairement identifiable.
L'exemple ci-dessus montrer une période d'acquisition à 1 milliseconde. La faible résolution de la mesure se fait sentir avec une vitesse crénelée. Ci-dessous, une acquisition similaire, mais avec une période de 20 millisecondes, nous observons une vitesse bien plus lisse…
C'est le moment de calibrer votre facteur de conversion entre les pas du codeur et la distance parcourue par la roue en millimètre !
Le code est disponible sur la branche « Codeurs ».
Avec le RP2040, vous devrez modifier votre fichier CMakeLists.txt pour que votre code compile !
Vous devez rajouter cette ligne pour générer le fichier d’initialisation du module PIO :
pico_generate_pio_header(PAMI_Cours_Codeurs ${CMAKE_CURRENT_LIST_DIR}/quadrature_encoder.pio)
Si vos valeurs restent à 0 :