411 réponses à ce sujet

[Sandro]

Super.

 

Autre petit point : est-ce qu'il y a une raison pourquoi la variable Hall_Hz_L est de type (valatile) unsigned int? En particulier, je trouve ça dommage de faire une mesure de la période, pour ensuite avoir une fréquence arrondie à l'unité (donc ne garder qu'un chiffre significatif)

- si tu veux juste quelque chose d'aproximatif, un unsgned int (ou même un char/uint8_t), vue que je penses pas que tu puisses dépasser 255HZ

- si tu accèptes une (petite) perte de performance, tu peux juste utiliser le type float à la place

- si tu veux gagner en précision sans passer par les flotants (qui sont plus lents que les entiers), alors tu peux garder un unsigned int / unsigned long, et juste changer d'unité : tu peux par exemple enregistrer la fréquence en mHz pour gagner 3 chifres significatifs (il suffit de faite 1000000000/Period au lieu de 1000000/Period.

[Oracid]

"Volatile", c'est parce que c'est obligatoire quand ont utilise une variable globale dans une fonction ISR.

Pour commencer, je vais me contenter d'un entier. J'ai l'habitude d'utiliser int ou unsigned int, mais c'est vrai que je ne pense pas dépasser 255Hz.

Le "unsigned long", c'est parce que je me suis inspiré d'un code que j'ai trouvé, mais c'est vrai que ce n'est pas approprié.

 

Je pense que dans ta première phrase tu voulais dire "unsigned long".

 

Merci.

[Sandro]

Pardon, je voulais bien dire unsigned long dans ma première phrase.

 

Pour "volatile", c'est en effet obligatoire ici. Ça permet de dire au compilateur "attention, cette variable peut changer à tout instant", et oblige donc le compilateur à ce que le programme ailles lire la variable depuis la RAM à chaque accès (autrement, le compilateur se contente souvent de garder la variable dans un registre entre plusieurs utilisations successives). "volatile" est donc nécessaire pour toute variable globale partagée entre le programme principal et quelque chose qui l'interrompt (interruption hardware, fonction appelée avec un timer, ...).

 

Pour stocker "micros", le type unsigned long est en effet le type "normal" (ie la fonction micros renvoit un unsigned long, donc si tu stockes dans un format plus petit, tu limites la durée max (ce qui n'est pas un problème tant que tu traivailles avec des différences, et que la différence ne dépasse pas la taille max de tes variables). Donc pour stocker tes timings, rester sur du unsigned long est une bonne idée.

 

Pour le fait de rester sur un entier pour stocker une fréquence en Hz, tant que tu fais de l'affichage, tu fais comme tu veux. Par contre, quand tu voudra faire du contrôle, je te conseilles vivement de passer sur du float (sinon une fréquence de 0.99 Hz sera tronquée à 0Hz)

[Oracid]

Merci Sandro.

Donc, si j'ai bien compris, je récupère les TimesStamp de micros() en unsigned long et je calcule la fréquence en float.

 

Je vais essayer de tester la fonction ISR avec ton code, ce matin.

[Sandro]

c'est ça.

Juste, j'oubliais de préciser un détail : il faudra écrire 1000000.0/Periode : si tu ne mets pas le ".0" (ou juste "."), le calcul se fera avec des entiers (donc sera tronqué), et seulement le résultat sera converti en float (donc tu ne gagnes rien). Par contre, dès qu'un des deux membres de l'opération est un float, l'entier est automatiquement converti en flotant, et l'opération est faite en float : tu ne tronquera donc pas le résultat.

 

NB : si tu as deux variables de types entiers, et que tu veux faire une opération (typiquement la division) en flotant, tu peux écrire :

float resultat_float = (float) mon_int_1 / mon_int_2;
float resultat_float = mon_int_1 / (float) mon_int_2;
float resultat_float = (float) mon_int_1 / (float) mon_int_2;

 

[Oracid]

Cela fonctionne parfaitement. J'espère ne pas m'être trompé.

 

Voici le résultat.

 RC brk Order Hz: L 8  R 8 ISR:   Period 135432 Hall Hz: L 7.38  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 134368 Hall Hz: L 7.44  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 134368 Hall Hz: L 7.44  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 133000 Hall Hz: L 7.52  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 133000 Hall Hz: L 7.52  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 136536 Hall Hz: L 7.32  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 136536 Hall Hz: L 7.47  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 133812 Hall Hz: L 7.47  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 133604 Hall Hz: L 7.48  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 133604 Hall Hz: L 7.48  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 136468 Hall Hz: L 7.33  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 136468 Hall Hz: L 7.33  R 0.00
 RC brk Order Hz: L 8  R 8 ISR:   Period 137012 Hall Hz: L 7.30  R 0.00

Et le code.

Spoiler

// BigRoverIRQ-V4 - 06/02/2023
void(* resetFunc) (void) = 0;                                 // soft reset function
int pb = A0;                                                  // Start pgm button
int PWM_OUT_L = 5, PWM_OUT_R = 6;                             // Pins PWM 976Hz Output
int DIR_OUT_L = 10, DIR_OUT_R = 11;                           // Pins Direction Output
int Hall_L_pin = 2, Hall_R_pin = 3;                           // interrupt left and right 
volatile float Hall_Hz_L, Hall_Hz_R;                          // Hall sensors frequency left and right
volatile unsigned long Period;                                // Hall sensors period 
int SPEED = 122;                                              // speed state (PWM value) about 8Hz
int c1=0, c2=0;                                               // Radio Control channels
int Order_L=0, Order_R=0;                                     // left and right PWM orders
int Order_Hz_L, Order_Hz_R;                                   // left and right Hz orders
 
void setup() {
  delay(500);                                                 // for reset consideration
  Serial.begin(9600);
  pinMode(pb,INPUT_PULLUP);                                   // Stop/Start button
  pinMode(A1,INPUT);  pinMode(A2,INPUT);                      // channels 1 and 2 receiver input
  pinMode(Hall_L_pin, INPUT);                                 // Hall sensor Left wheels
  pinMode(Hall_R_pin, INPUT);                                 // Hall sensor Right wheels
  pinMode(DIR_OUT_R, OUTPUT); digitalWrite(DIR_OUT_R, HIGH);  // Direction order forward or backward, right wheels
  pinMode(DIR_OUT_L, OUTPUT); digitalWrite(DIR_OUT_L, HIGH);  // Direction order forward or backward, left wheels
  pinMode(PWM_OUT_R, OUTPUT); analogWrite(PWM_OUT_R, 0);      // PWM order right wheels
  pinMode(PWM_OUT_L, OUTPUT); analogWrite(PWM_OUT_L, 0);      // PWM order right wheels
  attachInterrupt(digitalPinToInterrupt(Hall_L_pin), ISR_Hz_Hall_L, RISING);    // Attach Interrupt for Hall sensor left wheel
  Serial.print("\n To start pgm, click on the Start button"); while(digitalRead(pb)); delay(400); Serial.print("\n Started"); delay(100);
}
 
void loop() {
  if (! digitalRead(pb)) { Serial.print("\n Operator Application Interrupt !!!"); delay(400); resetFunc(); }
  RC();
  DBG();
}
 
void RC() {   // Radio Control
  static int old_Order_L;
  c1  = pulseIn(A1,HIGH,30000);       // receiver channel 1 getting value turn Left and Right 
  c2  = pulseIn(A2,HIGH,30000);       // receiver channel 2 getting value Forward and Backward
 
  if (c1==0 || c2==0) { Serial.print("\n RC off !!!"); DBG(); delay(500); resetFunc(); } // if RC off then reset
  
  if (c2 >= 1600) Forward();
  if (c2 <  1400) Backward();
  if (c2 >= 1400 && c2 < 1600) Stop();
 
  if (Order_L == old_Order_L){ Serial.print("\n RC brk"); return;}    // if same order, return
  else {old_Order_L = Order_L; Serial.print("\n RC newVal #############################\n");}
  analogWrite(PWM_OUT_R,Order_R);       // write PWM value to output with LowPass Filter
  analogWrite(PWM_OUT_L,Order_L);       // write PWM value to output with LowPass Filter 
}
 
void Stop(){
  Order_L = 0;    Order_R = 0;
  Order_Hz_L = 0; Order_Hz_R = 0;
  digitalWrite(DIR_OUT_L, HIGH);
  digitalWrite(DIR_OUT_R, HIGH);  
}
 
void Forward(){
  Order_L = SPEED;    Order_R = Order_L;
  Order_Hz_L = map(Order_L,115,130,0,18); Order_Hz_R = Order_Hz_L;
  digitalWrite(DIR_OUT_L, HIGH);
  digitalWrite(DIR_OUT_R, HIGH);
}
 
void Backward(){
  Order_L = SPEED;    Order_R = Order_L;
  Order_Hz_L = map(Order_L,115,130,0,18); Order_Hz_R = Order_Hz_L;
  digitalWrite(DIR_OUT_L, LOW);
  digitalWrite(DIR_OUT_R, LOW);
}
 
void DBG(){
  Serial.print("\tOrder Hz: L ");Serial.print(Order_Hz_L); Serial.print("  R ");Serial.print(Order_Hz_R);
  Serial.print("\tISR: "); Serial.print("  Period ");Serial.print(Period);
  Serial.print("\tHall Hz: L ");Serial.print(Hall_Hz_L); Serial.print("  R ");Serial.print(Hall_Hz_R);
}
 
void ISR_Hz_Hall_L(){     //  Sandro Interrupt Service Routine
  static unsigned long prev_tick = micros();
  unsigned long new_tick = micros();
  Period = new_tick - prev_tick;
  Hall_Hz_L = 1000000.0 / Period;
  prev_tick = new_tick ;
}
 

 

Merci Sandro.

[Sandro]

La fonction ISR m'a l'air correcte

[Oracid]

La fonction ISR m'a l'air correcte

Super !

 

Bon, et bien, comme je n'ai pas encore reçu les composants pour modifier les filtres RC, je vais m'attaquer au PID . . .

J'ai gardé le meilleur pour la fin.  

[dakota99]

Bonjour, j'ai fait de nombreux essais avec cet engin.

 

 

Ma conclusion actuelle est que cet engin est très difficile à guider en charge et sur terrain en pente.

C'est dû au fait que ce sont des roues qui tournent librement quand il n'y a pas de tension.

Bien sûr il faut un asservissement en vitesse et donc freiner les roues qui s'emballent mais cela devient fort compliqué à mon niveau.

Je vais laisser au frigo pour un moment et revenir vers des motoréducteurs. Cela me paraît nettement plus facile à guider avec précision.

 

 

[Oracid]

Bien sûr il faut un asservissement en vitesse et donc freiner les roues qui s'emballent mais cela devient fort compliqué à mon niveau.

Tu as la possibilité de freiner.

Par exemple, après chaque tour de roue, tu freines. Cela devrait fortement supprimer l'inertie.

[Oracid]

Voici une magnifique réalisation qui montre, une fois de plus, le bien fondé de l'utilisation de la techno e-Bike.

 

[pat92fr]

Bonsoir,

 

Premiers tours de roue, piloté au gamepad en Bluetooth. La propulsion réutilise les moteurs, la carte de puissance et la batterie d'un hoverboard 6.5 pouces. La carte est flashée avec le firmware hack FOC, en variante UART+TANK. Cette carte est pilotée via une liaison série par un NUC Intel (i3) sur lequel tourne Ubuntu 22.04 LTS et ROS2 (Humble). Le NUC dispose de sa propre alimentation, réutilisant également une batterie d'hoverboard et un DC/DC. Pour l'instant, il y a les nœuds standards 'joystick', 'teleop', un nœud LIDAR développé par Hokuyo pour mon UST-10LX et un nœud "fait maison" permettant de contrôler les moteurs (PID avance et PID rotation). Pour ce nœud, j'ai réutilisé le code du ROS2-hoverboard-driver, qui permet de communiquer avec la carte de puissance hoverboard. La communication est bidirectionnelle (commande 'PWM" moteurs droit et gauche dans un sens, tension batterie, température du contrôleur et la vitesse des roues RPM dans l'autre) et cadencée à 100Hz. Bizarrement, mon PID utilise une grosse valeur de Ki pour réguler la vitesse des roues et du robot. Le robot communique également en Wifi avec mon PC bureau sur lequel j'ai installé Ubuntu WSL (linux sans VM sur windows 10). Ca me permet d'installer ROS2 sur mon PC et de pouvoir lancer RVIZ2 et récupérer la télémétrie du robot (odométrie, scan).

 

 

 

Coté design HW, il y a du boulot ! J'attends des profilés de chez Dold pour fermer le robot. Le NUC Intel consomme 65W et mon DC/DC 36V=>19V 5A est un peu juste (il chauffe beaucoup). J'attends un DC/DC 36V=>19V 10A.

 

La suite : installation de ROS Navigation 2 et SLAM.

 

A suivre.

[Atmos]

Premier tours de roues réussi, bravo,cela fait très envie, mais là pour moi, c'est vraiment très compliqué.

 

Merci pour les infos.

[Oracid]

là pour moi, c'est vraiment très compliqué.

Et encore, il n'a pas parlé du châssis. T'inquiète, je suis comme toi, mais une pierre après l'autre et on y arrivera, avant d'emménager en EPAD, j'espère. 

 

Vraiment bien le châssis ! Tu as été bien inspiré . . .     Le reste est pas mal aussi. 

 

Là, je suis à Acapulco. Si, si.  

Fait chaud, très chaud ! 

[dakota99]

Super ! beau travail.

Je ne comprends pas tout ce que tu as fait ... mais apparemment c'est bien fait.

 

Tu as un asservissement en vitesse ? Si tu mets le robot sur un plan incliné il va freiner les roues pour garder sa trajectoire ?µ

Pour ma part c'est ce qui me paraît le plus difficile à faire...

 

@Oracid : pas trop dur de ne pas être dans ton atelier ?

[pat92fr]

Merci dakota,

 

J'avais deux soucis avec mon robot :

- la liaison série entre le NUC Intel et la carte d'hoverboard avait des erreurs de transmission. C'était certainement un problème de pilote Ubuntu. J'ai changé de cordon convertisseur USB/Série et ca fonctionne.

- le NUC s'alimente en 19V4A. Mais, il semble possible de l'alimenter en 12V seulement. Ca simplifie le câblage à bord ! Un seul DC/DC 12V 30A (500gr!) permet de toute alimenter (Nuc Intel, LIDAR, etc), et le DC/DC est assez puissant pour ne plus chauffer. J'avais prévu un ventilateur 12V (genre PC) au cas où...

 

Oui, j'ai programmé un asservissement en vitesse d'avance et en vitesse de rotation. L'erreur est calculée à partir des consignes de vitesses données par le gamepad et le feedback de la carte hoverboard (RPM moteurs droit et gauche). Il y a donc deux PID en parallèle, un pour la vitesse d'avance et un pour la vitesse de rotation. La sortie des PID donne les consignes moteur droit et gauche (une valeur entre -1000 et +1000) envoyées à la carte hoverboard. Le tout est cadencé à 100Hz.

 

Le principe est le même qu'une micromouse :

 

Je vais faire le test sur un plan incliné et je fais une vidéo ! Je pense qu'il va reculer tout en se freinant un peu, si je lâche le gamepad. C'est un asservissement en vitesse, pas en position. Et puis les roues d'hoverboard sont lisses, pour peu que le revêtement soit lisse, en l'absence de poids (le robot ne pèse pas 80kg), ca risque de déraper aussi.

 

A suivre...

Patrick.

 

[Oracid]

@Oracid : pas trop dur de ne pas être dans ton atelier ?

C'est la misère !

D'autant que j'ai 3 monstres dans les pattes.      

[TNERA]

Hi all!

 

It has been an almost a year since this thread what was started!!  What are your current thoughts on using hoverboard motors for UGV robots???

 

I have read through all the messages, there was significant effort given to decode the wires, get the right motor controllers, low pass filters, PID controllers, breaking, etc.  Lots of unusual issues around torque, slopes, stairs, turns, etc.  A lot of great discussions!

 

Now, it seems Patrick has joined the club, Dakota99 might be going back to geared motors. Oracid ran off to Mexico?!? 

 

What are your thoughts?  If I were to invest in the technology, what would your current advice be?  (Because they look really cool)

 

Do these motors have the performance to be good for robotics? Is it worth the effort to engineer them, does this offset the cost?

 

I am very curious of your opinions! 

[pat92fr]

Hello,

 

Good performance for value. You can buy a used hoverboard at a low price (30€). One hoverboard (two wheels hub motors and a controller) is enough for a diff drive robot. Motors are silent., with a quite high torque for an heavy UGV. As long as you know how to use a ST Link programmer to flash the hack firmware for the controller (gen1 single board or gen2 side boards), probably one of the best solution so far.

 

Patrick.

[pat92fr]

Le mini-gang des robots à moteur d'Hoverboard !

 

 

Patrick.

 

NB: J'échange le gros 4x4 contre un chapeau mexicain, un grand, authentique !