10 réponses à ce sujet

[dakota99]

Bonjour

Je souhaiterais avoir votre avis sur la précision nécessaire pour des encodeurs sur un mobile à 2 roues motrices: 

L'objectif est de faire des virages à angle précis : exemple faire un demi tour précis seulement en tenant compte des encodeurs ou avancer en suivant une trajectoire "parfaitement" rectiligne.

 

Roues de 100mm de diamètre

Vitesse d'avancement : 10 m / min

Encodeurs : 400 pulse par rotation  https://www.gotronic...n0230-26819.htm

L'encodeur est monté avec une roulette de 20mm qui frotte sur la roue motrice de 100mm

Une distance de 4568 mm correspond à 30000 pulse.

1 pulse = 0.15mm

1 mm = 6.5 pulse²

 

Quelle précision utilisez-vous dans vos projets ?

Est-il préférable de placer l'encodeur sur une roue libre qui frotte au sol ?

Ou sur une petite roue qui frotte sur la roue motrice ? Dans ce cas si la roue patine, > erreur.

 

Merci 

 

 

[Sandro]

Bonsoir,

 

il manque une information fondamentale pour te répondre correctement : le terrain sur lequel tu navigues : béton plat ou graviers, ça change tout.

 

Globalement, ce qui fait l'erreur, c'est bien plus le glissement des roues que la résolution des encodeurs (nb : tu peux "gratuitement" multiplier par 4 la résolution des encodeurs en utilisant chaque front de chacun des deux signaux (ie 400 pulse/tour -> 1600 signaux par tour).

 

Sinon, l'idéal, c'est les encodeurs sur roues libres plaquée au sol (via un système de ressorts ou gravité), idéalement au niveau de l'axe de rotation du robot.

 

Avec encodeurs sur roues libres sur "suspensions" par gravité, sur de la moquette, à environ la même vitesse que toi, on avait 1m d'erreur au bout de 2-3 minutes à se déplacer dans tous les sens.

[dakota99]

Merci pour ta réponse.

Oui effectivement je n'ai pas précisé que c'est sur du sol bien plat

[Sandro]

Sur du sol bien plat, tu devrais avoir moins de patiemment.

 

Après, il reste le glissement latéral des roues si elles ne sont pas alignées avec le centre de rotation du robot.

 

 

Globalement, je penses que faire un virage individuel "précis" (au sens que si du dis 180°, tu ne vois pas l'erreur à l'oeil nu) devrait pas poser trop de problème si tes encodeurs sont environ sur l'axe de rotation du robot (qu'ils soient liés aux roues (si elles accrochent pas trop mal) ou indépendants). En revanche, quel que soit la qualité de tes encodeurs et de leur montage, il est impossible d'espérer garder une orientation absolue sur le long terme sans recalage extérieur.

 

Pour la ligne droite, tout dépend de la longueur que tu veux faire en ligne droite et de l'erreur que tu accepte.

 

 

Globalement, sur le très court termes les encodeurs marchent très bien tant que les roues des encodeurs ne patinent pas (ce à quoi aident des roues indépendantes pour les encodeurs s'il y a un risque de patinement). A moyen terme (de l'ordre de la minute), la précision peut aller d'acceptable à catastrophique selon la précision des encodeurs, leur montage, les patinages/dérapages, la planéité du terrain, ... Au delà de quelques minutes, les encodeurs sont inexploitables pour garder une position absolue.

 

En revanche, il suffit de combiner les encodeurs avec de temps à autre une information (même partielle) de position absolue (qui peut être moins précise), pour obtenir en permanence une position absolue relativement précise. Cette information supplémentaire peut être une position GPS, la distance aux murs de la pièce quand tu passes pas trop loin, un scan LIDAR, une boussole en extérieur pour l'orientation uniquement, ...

[Oracid]

il est impossible d'espérer garder une orientation absolue sur le long terme sans recalage extérieur.

Si j'avais un roulant à faire, à chaque déplacement, je choisirais 2 obstacles quelconques qui se présentent à moi, et je me déplacerais en fonction de leur distance.

Ce principe serait valable, quel que soit le terrain. Et même comme ça, je ne suis pas certain d'avoir une grande précision.

[dakota99]

Merci pour vos réponses très instructives.

Je vais essayer d'affiner la précision des encodeurs surtout pour les virages à un angle précis.

Ensuite sur le roulant il y a 2 lidar dont un sur  servo et une camera Huskylens. Ce sont donc surtout eux qui vont fournir la précision.

 

Encor merci pour votre temps

[dakota99]

J'ai plus ou moins élucidé le problème que je rencontre avec les encodeurs : en fait j'utilise un smartphone et un Arduino connectés en Bluetooth.

L'Arduino envoie au smartphone les données des Lidar, des encodeurs, de la camera, ... et c'est l'appli du smartphone qui s'occupe du guidage.

Concrètement le problème que je rencontre quand je souhaite faire des changements précis de direction, (par exemple un virage à 90°) c'est que l'angle n'est jamais de 90°. Parfois 92° 95° 100°.  ..

Apparemment le problème vient du transfert de données de l'Arduino Mega vers le téléphone. La communication se fait à 9600 bauds et dans certains cas le téléphone reçoit trop tard la valeur des encodeurs et donc arrête les moteurs trop tard. L'angle est donc dépassé.

2 solutions :

- c'est l'Arduino qui stoppe les moteurs quand les valeurs des encodeurs sont dépassés. Mais il faut alors que le téléphone ait cette information.

- augmenter la vitesse de transmission en utilisant une connexion filaire du smartphone vers l'Arduino avec une communication série qui serait plus rapide.

Avez-vous déjà essayé cela ? Avec un convertisseur micro sub série ?

Merci

[Mike118]

J'ai plus ou moins élucidé le problème que je rencontre avec les encodeurs : en fait j'utilise un smartphone et un Arduino connectés en Bluetooth.

L'Arduino envoie au smartphone les données des Lidar, des encodeurs, de la camera, ... et c'est l'appli du smartphone qui s'occupe du guidage.

Concrètement le problème que je rencontre quand je souhaite faire des changements précis de direction, (par exemple un virage à 90°) c'est que l'angle n'est jamais de 90°. Parfois 92° 95° 100°.  ..

Apparemment le problème vient du transfert de données de l'Arduino Mega vers le téléphone. La communication se fait à 9600 bauds et dans certains cas le téléphone reçoit trop tard la valeur des encodeurs et donc arrête les moteurs trop tard. L'angle est donc dépassé.

2 solutions :

- c'est l'Arduino qui stoppe les moteurs quand les valeurs des encodeurs sont dépassés. Mais il faut alors que le téléphone ait cette information.

- augmenter la vitesse de transmission en utilisant une connexion filaire du smartphone vers l'Arduino avec une communication série qui serait plus rapide.

Avez-vous déjà essayé cela ? Avec un convertisseur micro sub série ?

Merci

 

Le plus logique est que l'arduino arrête les moteurs. 

Dans l'idéal tu es censé avoir des commandes " haut niveau " sur le téléphone, avec des retours d'informations " non critique ". 
Toutes les décisions critiques sont censé être dans le "bas niveau" . 

Exemples : 

Le téléphone peut piloter le robot en continue ( mode télécommande )
Le téléphone peut choisir d'activer ou non la détection d'obstacle, Afficher des données de capteurs etc...
Le téléphone peut envoyer une consigne du genre ' met toi à 90° ' et afficher la position en " temps réel" du robot

Mais c'est le robot qui s'arrête tout seul si il est à la bonne position ou si un obstacle est présent ( décision de l'arduino)
Le robot gère lui même son asservissement. ( traitement et utilisation des données codeurs etc... )

Si tu veux on peut faire un point sur ce qui pourrait se gérer directement sur l'arduino / ce qui ne devrait pas se gérer sur le téléphone et inversement ... 

[dakota99]

Merci Mike118

 

D'accord il faut que ce soit l'Arduino qui stoppe les moteurs quand :

- la limite des encodeurs est dépassée.

- la distance devant le robot est < que la distance minimum

- la taille de l'image de la cible renvoyée par la camera est plus petite que la taille minimum

- ...

et si je comprends bien, il est préférable que le guidage se fasse par le robot lui-même. Pour ma part je préfère que l'Arduino ss'occupe de renvoyer les données des capteurs et que tout le traitement se fasse dans le téléphone. Mais apparemment ce n'est pas l'idéal..

 

Dans le cas présent, il faut que j'adapte le code dans ce sens mais aussi il faut que l'Arduino communique au téléphone qu'il a stoppé les moteurs. Pour que le téléphone passe à la ligne de programme suivante exemple quand on arrive à la fin d'une ligne droite on fait un virage à gauche de 90°.

[Mike118]

 

Dans le cas présent, il faut que j'adapte le code dans ce sens mais aussi il faut que l'Arduino communique au téléphone qu'il a stoppé les moteurs. Pour que le téléphone passe à la ligne de programme suivante exemple quand on arrive à la fin d'une ligne droite on fait un virage à gauche de 90°.

 

En effet c'est le but, le téléphone contient toutes les séquences et l'ordre dans lequel les faire, 

le robot lui est capable de bêtement réaliser les séquences tout seul et de dire où il en est. 

Le téléphone est une " télécommande" / " un plannificateur " , mais ce n'est pas le cerveau du robot.
Le cerveau du robot est dans le robot, il est un peu "bête" mais fait exactement ce qu'on lui demande de faire et il le fait " rapidement ", et il peut notifier au fur et à mesure où il en est à son " superviseur " le téléphone.

[dakota99]

Bon j'ai pigé mais j'ai du taf alors

Merci