411 réponses à ce sujet

[Oracid]

il est conseillé de ne pas les utiliser à plus de 50% de leur tension annoncée. 

Pas de souci, je les utilise en 5V et ils sont donnés pour 25V.

J'en ai trouvé en céramique, mais ce sont des cms, et plus compliqué a utiliser, pour moi.

[Oracid]

                  ça marche ! ! !

 

 

Merci Sandro, merci Mike.

 

J'ai enfin vu mon robot tourner sur place, à gauche et à droite.

Avec la manette droite de ma radiocommande, vers l'avant j'avance, vers l'arrière je recule, vers la gauche je tourne à gauche sur place, et vers la droite je tourne à droite sur place.

Quand je tourne à gauche ou à droite, rien ne se passe.

Alors, j'ai eu l'idée d'augmenter le PWM avec la manette gauche, la manette des gaz, du bas vers le haut.

Et, surprise, il n'est pas nécessaire d'augmenter beaucoup le PWM pour que le robot tourne.

 

J'ai fait le test dans mon garage, 3 fois à gauche, puis à droite. Puis soudain, le robot s'est mis à aller tout droit au lieu de tourner.

Et comme le battant du garage était ouvert et la sortie de garage étant légèrement en pente, il a finit sa course dans les rosiers.

 

A ce moment, j'ai essayé de le ramener en marche avant vers le garage. Et bien, il n'a pas pu remonter la pente qui est pourtant très légère.

Du coup, je me suis dit qu'une petite pente était peut-être un bon moyen de tester un PID.

 

Après un bon nettoyage, car les roues étaient pleines de boue, je l'ai remis sur mon établi pour faire un test en roues libres. Pas de problème, tout fonctionne bien.

Je pensais avoir cramé un contrôleur lorsqu'il est parti tout droit, mais non. Bizarre !

 

Pour moi, ce test est très important. Je ne mettais pas en doute les conseils de Sandro et de Mike, mais je ne me doutais pas que cela allait être aussi facile à mettre en œuvre. 

 

Bien, maintenant, je vais refaire le filtre RC avec les valeurs que Sandro m'a conseillées. Ce n'est pas absolument nécessaire, car il ne faut pas beaucoup augmenter le PWM pour que le robot tourne, mais pour monter des escaliers, j'imagine que ce sera une autre affaire.

 

En tout cas, une chose est sûr, il faut vraiment que le robot aille très doucement. De plus, quand on lâche les manettes, il faut qu'il s'arrête avec un freinage efficace. Chose que je n'ai pas encore mis en œuvre.

 

C'est quand même un engin de 15kg qui se balade. Si mon portail était ouvert, il aurait pu sortir dans la rue . . .

[Sandro]

Super!

Je me disais bien que vu la puissance de tes moteurs, il y avait largement de quoi tourner sur place.

 

Et pour le PID, c'est bien ça l'intérêt : pouvoir choisir ta vitesse (par exemple 10cm/s), et la maintenir quel que soit la pente. Et au passage, tu peux aussi définir la vitesse à 0, et même si ton robot est dans la pente, il ne bougera pas

[Oracid]

Bonne nouvelle !

J'ai réussi à visualiser les signaux des 3 capteurs à effet Hall d'un moteur avec mon oscilloscope 4 voies.

C'est un signal carré de 5V, avec les niveaux haut et bas d'égale longeur.

A ma vitesse maximum (PWM=130), la fréquence indiqué par l'oscilloscope est d'environ 16Hz avec un signal de 60ms, ce qui me semble cohérent.

Les 3 signaux sont déphasés de 20ms. Ce qui me semble cohérent avec un positionnement des capteurs à 120°.

Avec ma radiocommande, je modifie la fréquence du signal à volonté, et tout reste cohérent.

Il me semble donc que je vais pouvoir mesurer la vitesse du robot.

[Sandro]

Je penses que ça devrait être exploitable si on mesure la durée des impulsions.

Est-ce que par hasard tu as fait une photo/capture de l'oscillo? (ma question est comment sont placé les fronts montants et descendants les uns par rapport aux autres, pour voir si en pratique on a 3 timings intéressants ou 6)

[Oracid]

Cliquez moi.

 

Super, je peux sauvegarder une image de mon oscilloscope sur une clé USB.

 

Je pense que la fonction pulseInLong(), va me donner la durée d'une impulsion et donc, la vitesse. https://reference.ar...io/pulseinlong/

 

Le premier signal, c'est le jaune, puis le rouge, puis le bleu.

En haut, vers la gauche, on peut voir la base de temps à 10ms la division, et en haut, à droite, la fréquence, ici à environ 16Hz.

[Sandro]

Super, merci.

Et est-ce que tu as une idée à quelle vitesse ta roue tournait (le but, c'est de savoir à quel angle de rotation correspond une impulsion).

 

Sinon, pulseinlong n'est malheureusement pas la bonne solution, vu que c'est une fonction bloquante, donc il ne sera pas possible de traiter les 2 roues en même temps.

 

Je penses qu'il vas falloir se baser sur les interruptions pour détecter en "tâche de fond" la vitesse.

 

Autre question : ton but c'est quoi : réguler en vitesse uniquement, ou aussi en position (ie dire de tourner de X degrés, et que le robot tourne d'environ X degrés)? Dans le premier cas, on peut probablement se contenter d'utiliser un seul signal. Dans le second cas, je penses qu'il vaut mieux utiliser les 3 signaux en même temps (ce qui complique un peu les choses, mais reste faisable)

 

 

EDIT : et rappelles moi, ton niveau d'anglais est suffisent pour que je puisse te rediriger vers des articles en anglais, ou tu préfères que j'en trouve en français?

[Oracid]

Non, je n'ai aucune idée de la vitesse de la roue, mais j'ai un tachymètre quelque part. Demain je vais voir ça.

Intuitivement, je dirais qu'entre chaque impulsion la roue tourne de 120°.

Mon but, c'est de faire rouler le robot à vitesse constante (très lentement), de le faire tourner avec un rayon plus ou moins grand et de le faire tourner sur place.

Le défis majeur serait de lui faire monter les escaliers de ma terrasse.

Sinon pulseIn() normal ?

[Sandro]

Pour la vitesse, à priori, pas besoin de tachimètre : tu mets ton robot sur un support, avec un autocolant ou un bout de scotch sur une roue, et tu mets la vitesse au minimum : et tu regardes le nombre de pulses pendant que tu faits un tour.

 

Quand tu dis 120° entre chaque impulsion, tu parles d'impulsions sur la même couleur ou toutes confondues. Si c'est toutes confondues, ie tu as une impulsion par couleur par tour, alors il vas falloir utiliser tous les signaux.

 

 

Pour pulseIn, c'est la même chose que pour pulseInLong : c'est des fonctions bloquantes : ça peut être utile pour un appui sur un bouton si le reste du code ne doit rien faire pendant ce temps, mais ça bloque le code pendant ce temps (donc tu ne peux pas mesurer les 2 moteurs en même temps, ni lire la télécommande pendant ce temps, ...)

 

Je ne connais que 2 solutions de traiter des encodeurs (ou tes 3 capteurs à effet hall) sur une arduino :

- la méthode bourrin, consistant à lire très souvent la valeur des pins depuis loop pour détecter les changements : c'est peu précis, et ça consomme plein de ressources

- la méthode propre en utilisant les intéruptions. En gros, tu écris une fonction qui est appelé automatiquement lorsqu'un pin donné change de valeur. De manière simple, tu peux mettre des interruptions sur les pins 2 et 3, et de manière un poil plus compliqué sur n'importe quel pin.

 

Je te conseille la méthode avec les intéruptions

[Oracid]

- ok, je vais tester ta méthode pour voir la vitesse. Mais j'ai un tachymètre . . .

 

- je pense que c'est 120° entre 2 couleurs différentes. Il y a 3 capteurs à effet Hall. Fils jaune, vert et bleu qui correspondent respectivement aux fils jaune, vert et bleu du moteur.

  Sur l'image de l'oscilloscope, le signal jaune, puis le rouge(vert) 20ms après, puis le bleu 20ms après, puis jaune 20ms après. Soit 60ms en tout.

  Je suppose donc que les capteurs Hall sont décalées de 60°. Demain, je démonte un autre moteur pour en être certain, mais ce ne sera pas strictement le même moteur.

 

- ok, je veux bien tenter les interruptions, mais pour info, voici comment je lis les signaux de ma radiocommande.

 

  c1  = pulseIn(A1,HIGH,25000); delay(30);  // receiver channel 1 getting value turn Left and Right 
  c2  = pulseIn(A2,HIGH,25000); delay(30);  // receiver channel 2 getting value Forward and Backward
  c3  = pulseIn(A3,HIGH,25000); delay(30);  // receiver channel 3 getting value Forward and Backward

[Sandro]

Pour tester, pas besoin de démonter le moteur (surtout que c'est pas forcément pareil selon le modèle de moteur, et qu'une éventuelle réduction modifie encore le résultat) : si tu mesures la vitesse (avec ma méthode ou avec le tachymètre, comme tu veux), et que tu compares avec ce que tu as à l'oscilloscope, ça te donne toutes les infos dont tu as besoin.

.

Pour ta lecture de la télécommande, ta méthode ne pose pas problème (en tout cas actuellement), car tu n'est pas pressé. Tu es donc en train de lire les 3 durées les unes après les autres. Vu que ta télécommande doit envoyer les données "en permanence" sur chaque canal, si tu rates une impulsion, tu lis la suivante, et c'est pas graphe. Si tu faits la même chose avec les capteurs hall, alors pendant que tu lis un signal, tu ne peux pas lire l'autre. Et imagine tu fais un cercle assez serré, où la roue gauche est quasi-immobile, et la roue droite avance : si si tu es en train de lire la roue gauche, le temps de lire le pulse, sur la roue droite tu aura raté 10 pulses!

[Oracid]

Ok, aujourd'hui, je vais essayer de déterminer le nombre de pulses pour un tour.

Si je n'y arrive pas, je filme la scène de manière à pouvoir analyser le film tranquillement, éventuellement au ralenti.

 

Et imagine tu fais un cercle assez serré, où la roue gauche est quasi-immobile, et la roue droite avance : si si tu es en train de lire la roue gauche, le temps de lire le pulse, sur la roue droite tu aura raté 10 pulses!

Je ne sais pas quelle est ton idée. Chaque moteur possède 3 capteur Hall. Cela nous fait donc 3x4=12 capteurs Hall. Soit 12 inputs sur mon Nano.

Je n'ai pas ce nombre d'E/S de disponible, et encore je n'ai pas mis en œuvre les freins qui vont me prendre au minimum une sortie.

Actuellement, j'ai :

- 1 bouton STOP/START, pin A0

- 2 entrées radiocommande, pin A1, A2, +A3(GAZ)

- 2 sorties PWM (filtres RC), pin 5 et 6 

- 2 sorties direction (avant/arrière), pin 2 et 3

- 1 sortie BRAKE, pin 4

Total 8 E/S

 

Je pense qu'il faudra donc se limiter à 1 capteur Hall par roue. Qu'en penses-tu ?

[Mike118]

Je glisse ça ici si ça peut être utile : 
 

https://www.robot-maker.com/forum/topic/12032-lire-les-signaux-dune-radiocommande-rc-avec-arduino/ 

Le principe peut également être utilisé pour la lecture des codeurs ... 
( Mais si tu as 2 codeurs et que tu es sur un arduino uno / nano autant utiliser les interruptions sur les pins 2 et 3 ... et si possible utiliser un xor ... et si tu veux tout faire en même temps il faut être un peu malin pour faire un joli code optimisé )

[bubu17]

Bonjour à tous

je bricole un robot tondeuse avec des moteurs d'hoverboard.

le moteur envoie 90 impulsions par tour (haute et basse )

je les compte avec des interruptions et régule la vitesse par un pid

code en pièce-jointe

Fichier(s) joint(s)

•  lecture_vitesse_moteur_hoverboard.ino   3,91 Ko   96 téléchargement(s)

[Oracid]

 il faut être un peu malin pour faire un joli code optimisé )

Je vais essayer . . .

 

Depuis longtemps, mon code pour la radiocommande est directement inspiré de cette page. https://www.robot-ma...de-arduino.html

Je vais revoir tous tes liens, mais ça m'étonnerait que je ne les connaisse pas, mais sait-on jamais.

 

Bonjour bubu17, bienvenue ici, merci pour ton intérêt et pour ton code que je vais regarder de près. Dis nous en, un peu plus.

 

Je me prépare pour la vidéo, j'espère avoir le temps de la tourner cet après-midi.

[Oracid]

Voici la vidéo.

Sandro, si tu veux quelque chose de spécifique, un ralenti par exemple, dis le moi, et je tacherai de te faire ça.

J'ai mis des stickers jaune, vert et bleu à 120° et l'oscilloscope avec les même couleur.

 

Remarques:

- à  0'48", le sticker bleu est en haut et sa tension est à 5V.

- à  2'19" et à 2'27", le sticker vert est en haut et sa tension est à 5V.

 

[Oracid]

je bricole un robot tondeuse avec des moteurs d'hoverboard.

Pourrais tu nous dire quel type de contrôleur moteur, tu utilises ?

[bubu17]

j'utilise le ZS-X11-V2 ,

j'ai souder un fil à travers la pastille marquer P pour envoyer ma commande en pwm.

j'utilise le pin marquer S pour lire les impulsions (ticks) et calculer le nombre de tour par minute (Rpmd pour le moteur droit)

idem pour le gauche, ensuite je le compare à la consigne moteur.

[Oracid]

j'utilise le ZS-X11-V2 

C'est très intéressant !

 

J'ai également proposé ce contrôleur dans ce fil, https://www.robot-ma...board/?p=116760, j'ai même fait une vidéo le concernant, https://www.robot-maker.com/forum/topic/13733-ugv-a-base-delements-de-trottinette-ou-dhoverboard/?p=116963 , mais avec l'utilisation d'un filtre RC.

Dakota l'utilise également, et il sera certainement très intéressé par ton expérience. 

Personnellement, après l'avoir utilisé, je l'ai remplacé par des contrôleurs e-Bike qui semblent disposer de plus de puissance.

 

J'espère que tu nous en diras plus sur ton expérience. N'hésite pas à nous en parler sur ce fil ou à débuter ton propre sujet, c'est comme tu veux, mais ici, tu ne déranges pas.

Une petite vidéo, peut-être ?

[Sandro]

Salut,

 

Dans la vidéo, entre le début de la seconde 1'01 et le débu de la seconde 1'09 (soit une durée de 8 secondes), j'ai compté environ 8.3 tours, soit un petit peu plus de 1 tour/s

L'oscilloscipe indique une fréquence de presque 16Hz, donc un petit peu moins de 16 periodes par seconde.

 

Donc je dirais que probablement, on a 15 pulses/tour sur chaque capteur (nb : par pulse, j'entends monter à l'état haut puis redescendre : il y a donc 30 transistions/tour). Ce nombre de 15 pulses par tour est coherent avec l'exemple donné https://www.digikey....encoders-part-1 (en anglais).

 

Si tu veux en être absolument sur, il faudrait une vidéo avec une longue durée (ex : 1 minute) avec un PWM constant. Mais je penses que pour l'instant on peut avancer avec ça (au pire, si on s'est tropé, le robot sera juste 7% plus vite ou moins vite que prévu).

 

 

Pour les pins, je dois avoué avoir oublié que tu avais 4 moteurs et pas 2 (récupérer 6 pins aurait probablement été possible, 12 sur la nano ça fait trop avec ce que tu as déjà).

 

Utiliser un seul pin/moteur est possible (ça te donnerait 30 signaux par tour), avec pour inconvéniant que tu ne connais pas le sens de la roue (ça peut te jouer des tours si le moteur est quasi à l'arrêt, en particulier si tu fais des cercles assez serrés tels qu'un moteur est quasi arrêté et seul l'autre tourne).

 

Si tu veux 3 fois plus de résolution (mais toujours pas d'information de direction), tu peux utiliser des portes logiques Xor (par moteur, il te faut soit une porte xor à 3 entrées, ou 2 portes Xor classiques à 2 entrées)

 

Si tu veux la direction, il te faut au moins 2 entrées par moteur.

 

Un autre point : si tu veux réguler chaque moteur individuellement en vitesse, alors il faut aussi les commander individuellement en vitesse (ie il te faut une sortie PWM et un filtre RC pour chaque moteur). Mais tu peux aussi faire l'hypothèse que si tu donnes le même PWM aux deux moteurs du même coté, alors ils tourneront à la même vitesse. Cette hypothèse est normalement assez réaliste tant que c'est les mêmes moteurs et que les roues ne patinent pas.

Si tu décides de faire cette hypothèse, alors ça ne sert pas à grand chose de mesurer la vitesse des 2 moteurs : mesurer la vitesse d'un moteur par coté est alors suffisent.

 

Sinon, si tu veux avoir un contôle en vitesse complet, une solution "sympas" pourrait être d'utiliser 2 arduinos nano : un pour le "robot", et un comme controleur moteurs, avec une communication (en lisaison serie ou UART) entre les deux. L'arduino "robot" envoit juste une commande en vitesse linéaire et vitesse angulaire à l'arduino moteurs. L'arduino moteurs récupère cette commande, et fait le control en vitesse des 4 moteurs (du coup, tu as assez de pins pour tout faire : 4*3 pins pour lire les capteurs hall + 4 pins de PWM pour les filtres RC + 2 pins de communication (serie ou I2C) = 18 pins). Un autre avantage de cette solution est que du coup le control des moteurs se fait en "tache de fond", et que tu as donc le droit de faire des taches bloquantes sur l'arduino robot