410 réponses à ce sujet

[dakota99]

Bonjour,

 

 

 

- Le moteur peut tourner très très lentement mais aussi relativement vite. Donc plage de vitesse étendue.

- Très peu de bruit

- Très fluide

 

Batterie 12V, potentiomètre 10k

Je sais les raccords de lustre font mal aux yeux, mais je n'avais rien d'autre.

 

Etape suivante : Arduino avec marche avant/arrière et récupération des de la valeur de l'encodeur.

 

Avec ça on va faire des robots de ouf.

 

 

[Oracid]

Avec ça on va faire des robots de ouf.

Bien sûr !

 

Tu as fait mieux que moi ! Tes connections sont cohérentes (couleurs des phases moteur et des capteurs Hall). Ce qui n'est pas le cas dans mon montage.

Tu peux prendre la batterie 36V de l'hoverboard, ainsi tu auras plus de puissance.

Mais attention, en pleine charge, elle monte à 42V.

Et là, tu crame ton circuit qui parait-il est très sensible à la tension.

Par ailleurs, il me semble que ce contrôleur n'a pas de frein.

 

Tu n'envisages pas de faire un filtre passe bas ?

[dakota99]

Pour l'instant je vais continuer avec une batterie 12V, il a du couple à revendre ce moteur.

 

Si si j'ai fait le filtre passe bas comme tu l'as décrit et ça fonctionne.

 

 

Et le code est monstrueusement simple

int spd=2;   // VR 
int pwm = 80;

void setup()
{
pinMode(spd, OUTPUT); 
speed1=80;analogWrite(spd,pwm);
}

void loop()
{

}

Faut maintenant récupérer la valeur de l'encodeur...

Encore merci pour ton aide

Je ne me lasse pas de voir tourner cette roue.
 

 

[Oracid]

 

 

 

Faut maintenant récupérer la valeur de l'encodeur...

De quoi parles-tu ?

 

C'est quoi, le Shield que tu utilises ?

[dakota99]

Je souhaiterais récupérer le nombre de rotations faites par la roue. Actuellement avec les moteurs DC j'utilise une roue codeuse mais il me semble dans dans le moteur de l'hoverboard il y a ce qu'il faut sur la borne signal....

 

Le shield : https://www.gotronic...20027-19065.htm

[Oracid]

il me semble dans dans le moteur de l'hoverboard il y a ce qu'il faut sur la borne signal....

C'est possible.

 

Dans la vidéo qui me sert de référence, ici https://www.robot-ma...board/?p=116760, à 8'17",  Mad-EE explique que pour 1 tour de roue, le signal SC apparait 90 fois.

Malheureusement, sur mon contrôleur, ce signal n'est ni sur le connecteur Hall, ni sur le connecteur du potentiomètre. Il se situe sur le connecteur qui est difficile d'accès.

Donc, si tu as un analyseur logique, tu pourrais faire la même manip que lui. Sur mon oscilloscope, cela devrait être possible, mais je ne suis pas sûr d'y parvenir.

 

En tout cas, s'il s'agit de la même chose, cela devrait être faisable.

 

Super, ton Shield !

[dakota99]

J'ai connecté la borne Signal (sur le driver moteur) à la pin 2 de l'Arduino Mega.

Et j'obtiens 45 pulse par tour de roue. Ce qui est très peu.

Si je n'arrive pas à mieux, je continuerai à utiliser un encodeur rotatif qui frotte sur la roue ou qui est en contact avec le sol.

#include <SoftwareSerial.h>// import the serial library

int hal=2;   // Signal - Hall sensor
int spd=4;   // VR 
int speed1=0;
// =============== Encoder ==============================
#define  ECLFT 2
unsigned int erg = 0;  // encodeur roue gauche

void setup()
{
Serial.begin(9600);
Serial.println("Setup start"); 

// ======= Encoder =====================================
attachInterrupt(digitalPinToInterrupt(ECLFT), interrupt1, RISING);
pinMode(spd, OUTPUT); 
pinMode(hal, INPUT); 
speed1=60;
analogWrite(spd,speed1);

}

void loop()
{
Serial.println(erg); 
delay(2000);
}

void interrupt1()
   {erg += 1;
   }

 

 

[Oracid]

Bizarre, 45, c'est la moitié de 90 ?! 

Pourquoi dis-tu que 45, ce n'est pas suffisant ? Tu es sur du tout terrain !

Même si tu as une plus grande précision, ce n'est pas ça qui va beaucoup t'aider à faire des lignes droites ou à tourner.

Ce serait vraiment dommage de se passer ce cette fonctionnalité.

 

Super, ton code ! Là, je ne peux pas, mais dès que je peux, je le teste avec mon moteur.

[Sandro]

Bonjour,

tu as une solution très simple pour doubler la résolution : pour l'instant, tu ne regardes que les fronts montant de ton signal : tu peux aussi lire les fronts descendants :

il suffit de remplacer

attachInterrupt(digitalPinToInterrupt(ECLFT), interrupt1, RISING);

par

attachInterrupt(digitalPinToInterrupt(ECLFT), interrupt1, CHANGE);

A noter qu'avec le type de signal que tu as (ie un seul signal de sortie d'encodeur), tu n'as pas d'information de direction : tant que tu vas uniquement vers l'avant (ou virages assez peu serrés pour que deux roues continuent à tourner vers l'avant) tout vas bien. Mais si tu vas en arrière (ou que tu tournes quasi sur place avec une roue qui vas en arrière), tu ne le sauras pas (tu peux te baser sur la commande à priori pour déterminer le sens, mais ça t'oblige à un arrêt total avant changement de sens si tu ne veux pas d'erreurs dues à l'inertie).

 

 

 

@Oracid : Pour la résolution, si le but est uniquement de connaître ta vitesse ou de tourner de X degrés, 90 signaux/tour peut suffire. En revanche, si tu veux utiliser les encodeurs pour connaître ta position pendant une durée d'une/quelques minutes (sur un sol plat), alors il te faut un encodeur beaucoup plus précis, et une mécanique garantissant que l'encodeur ait un signal représentatif du vrai déplacement (ie la roue ne glisse pas, ne dérape pas, et ne quitte jamais le sol)
 

[dakota99]

Merci Sandro.

Oui effectivement j'obtiens bien 90 pulses par tour de roue. J'étais habitué à beaucoup plus mais je vais tester de cette manière.

Voici le code plus complet avec le start/stop, le sens de rotation.

 

Je ne me lasse pas de regarder cette roue tourner... :)

#include <SoftwareSerial.h>// import the serial library
int els=5;   // EL start - stop
int hal=2;   // Signal - Hall sensor
int dir=6;   // ZF direction
int spd=4;   // VR speed
int speed1;
// =============== Encoder ==============================
#define  ECLFT 2       // Encodeur gauche sur D2
unsigned int erg = 0;  // compteur pulses rouge gauche

void setup()
{
Serial.begin(9600);
Serial.println("Setup start"); 
delay(1000);
// ======= Encoder =====================================
attachInterrupt(digitalPinToInterrupt(ECLFT), interrupt1, CHANGE);

pinMode(els, OUTPUT); // EL start - stop
pinMode(dir, OUTPUT); // ZF direction
pinMode(spd, OUTPUT); // VR speed
pinMode(hal, INPUT);  // Signal - Hall sensor

speed1=40;
analogWrite(spd,speed1);
digitalWrite(dir,HIGH); // direction
delay(200);
digitalWrite(els,HIGH); // démarrage 

}

void loop()
{
   Serial.println(erg); 
   delay(2000);
}

void interrupt1()
   {erg += 1;
   }

 

 

[dakota99]

Bonjour,

 

J'a installé 2 moteurs d'hoverboard sur une simple planche afin de tester le guidage par Lidar, par camera Husky, par encodeurs et le constat c'est que les moteurs d'hoverboard conviennent très bien pour ce job.

 

Très silencieux, très "coupleux", vitesse très lente /rapide. Fonctionnent correctement même avec du 12v

Juste un bémol le nombre de pulses par tour de roue qui ne me semple pas suffisant. Mais il suffit d'ajouter des encodeurs séparés.

Je vais fabriquer un châssis en acier afin de pouvoir transporter des charges.

 

[Oracid]

Juste un bémol le nombre de pulses par tour de roue qui ne me semple pas suffisant. 

Que veux-tu dire ?

Si tu réussis à lire les signaux des capteurs Hall, tu sais exactement de combien ta roue a tourné.

 

Là, tu utilises la batterie de l'HoverBoard, non ?

Perso, j'aurais tendance à rester en 36V, voire plus, pour rester en phase avec la techno e-Byke, et ainsi pouvoir utiliser tous les éléments dédiés à un cout raisonnable.

[Oracid]

Mon projet avance tout doucement.

J'ai commandé des pneus qui malheureusement ne s'adaptent pas directement sur mes roues alors, j'ai dû les découper. Si, si . . .

Pour cela, il suffit de suivre un cerclage en acier à environ 5mm du bord. 

A l'intérieur, impossible de mettre la chambre à air, alors j'ai mis des fourreau d'isolation de tube, en polyuréthane.

Tout ceci n'est pas très orthodoxe, mais ça devrait aller.

Le diamètre de la roue est d'environ 27cm, soit 11".

 

Cliquez moi.

[Melmet]

Courage

[dakota99]

Que veux-tu dire ?

Si tu réussis à lire les signaux des capteurs Hall, tu sais exactement de combien ta roue a tourné.

 

Là, tu utilises la batterie de l'HoverBoard, non ?

Perso, j'aurais tendance à rester en 36V, voire plus, pour rester en phase avec la techno e-Byke, et ainsi pouvoir utiliser tous les éléments dédiés à un cout raisonnable.

Oui je sais lire les signaux des capteurs hall des 2 roues. Mais 90 pulses pour une rotation, ce n'est n'est pas une très haute résolution. Mais bon cela pourra peut-être suffire. Je le saurai très vite. Le châssis en acier prend forme.

Pour l'instant j'utilise des batteries Kärcher en 18V car j'en ai plusieurs et elles sont très pratiques.

 

Mais c'est vrai que ce serait bien d'utiliser les batteries 36V. D'après un post d'Oracid, je peux utiliser directement le chargeur original de l'hoverboard via le connecteur xt60. Le circuit de charge se trouve dans la batterie. C'est correct ?

[Oracid]

Mais c'est vrai que ce serait bien d'utiliser les batteries 36V. D'après un post d'Oracid, je peux utiliser directement le chargeur original de l'hoverboard via le connecteur xt60. Le circuit de charge se trouve dans la batterie. C'est correct ?

Oui, c'est correct ! Enfin, c'est ce que j'ai fait. Ce sont des batteries Li-ion, mais il faut toujours faire attention lorsque l'on charge des batteries.

Je n'ai jamais vraiment compris l'intérêt de connaitre le nombre de tours des roues.

 

J'ai remplacé les fourreaux d'isolation à l'intérieur de mon pneu par une frite de piscine, acheté chez Decathlon. https://www.decathlo...0006?mc=8612794

Maintenant, le pneu est vraiment dur.

[dakota99]

J'ai fait le montage chargeur hoverboard directement sur la batterie via connecteur xt60 et apparemment ça charge... je n'osais pas trop faire cela car je me disais qu'un circuit de charge était nécessaire mais ça a l'air de fonctionner...  je vais quand même laisser l'engin dehors au cas où cela prendrait feu

 

Concernant le nombre de tours de roues : c'est une info super utile.

- Pour que le mobile avance tout droit, il faut que le nombre de tours de chaque roue soit le même. Les 2 moteurs ne tournent pas parfaitement à la même vitesse et doc il ne file jamais tout droit.

- Pour faire un virage à 90° à gauche : la roue gauche est bloquée et on compte le nombre de tours de la roue droite. Si ce nombre = 500 c'est que le demi-tour est effectué ....

- Pour que le mobile avance toujours à la même vitesse quelle que soit sa charge ou la pente sur laquelle il roule, on mesure le nombre de pulses par unité de temps et on ajuste le PWM en conséquence.

 

C'est super d'avoir des grandes roues et increvables en plus...

[Oracid]

- Pour que le mobile avance tout droit, il faut que le nombre de tours de chaque roue soit le même. 

J'espère que tu ne seras pas déçu.

En intérieur, sur un sol bien plat, cela ne me semble déjà pas évident, mais là, en tout terrain, je demande à voir.

Je n'en suis pas là, mais perso, à chaque mouvement, je chercherai un point de référence qui me servira de guide.

Plus simplement, si en ligne droite, le robot dévie, je mettrai une pondération sur la vitesse d'un train de moteurs. (en principe, j'en aurai 4)

Mais c'est bien de te tester plusieurs options.

 

Dans un premier temps, je vais peut-être me diriger vers un suiveur de personne, comme ceci :

 

[dakota99]

Oui plusieurs techniques sont nécessaires Mais les encodeurs me semblent indispensables. . J'utilise un lidar rotatif et une camera Husky qui reconnaît des codes barres.

Mais qui peut aussi reconnaître les couleurs.

Ce qui me pose problème c'est que la cible doit être à max 4-5 mètres du robot. J'aimerais trouver un système simple qui permet de le guider sur de plus longues distances.

Une camera du genre Pixy2 ou Husky qui permettrait de renvoyer les coordonnées d'un point très lumineux

 

 

Quand tu écris "à chaque mouvement, je chercherai un point de référence qui me servira de guide."

Comment le robot va-t-il se diriger sur ce point de référence ?

 

Merci pour la vidéo. Beau projet.

[Oracid]

J'aimerais trouver un système simple qui permet de le guider sur de plus longues distances.

Un GPS. Je suppose que tu y as pensé.

 

 

Quand tu écris "à chaque mouvement, je chercherai un point de référence qui me servira de guide."

Comment le robot va-t-il se diriger sur ce point de référence ?

A vrai dire, je n'y ai pas encore beaucoup réfléchi, mais réfléchissons.

- Le robot a un émetteur à ultrasons sur ses 4 cotés.

- Il se trouve sur ma terrasse et détecte les parois qui entourent la terrasse.

- à chaque fois qu'il se déplace, les distances aux parois se modifient.

- avec un minimum de calculs, on peut déterminer la position du robot sur la terrasse.

C'est peut-être simpliste comme raisonnement, mais je partirais de là.