31 réponses à ce sujet

[dakota99]

La vitesse de déplacement est impressionnante !

[Oracid]

La vitesse de déplacement est impressionnante !

Oui, ça décoiffe ! Mais tu remarqueras que dans le monde des suiveurs de ligne, les angles droits sont assez rares.

J'aimerais bien tordre le coup à ce problème avec l'HuskyLens qui a l'inconvénient de pas voir les lignes horizontales. Ce qui est très dommage.

Mon programme fonctionne, mais à condition de relever la caméra, et là, du coup il suit la ligne, mais en l'optimisant.

Je veux dire, sans suivre toutes les méandres à la perfection. Et ça, Sandro, il aime pas. 

[Sandro]

Et ça, Sandro, il aime pas. 

Tu fais ce que tu veux!

Si tu veux suivre parfaitement la ligne, alors non, tu n'as pas le droit de couper les virages.

Si ton objectif c'est de rester à moins de X cm de la ligne, et d'optimiser la vitesse, alors libre à toi (tant que tu sorts pas de la route, tu es libre de couper les virages (tant que tu es certain qu'il n'y a personne en face))

[Oracid]

Tu fais ce que tu veux!

Bien sûr !

Chaque remarque, chaque critique que l'on me fait, est pour moi un moteur pour aller plus loin . . . 

 

Il y a deux manières de faire, suivre la ligne ou "optimiser" la trajectoire.

Pour avoir le choix, il faut être capable de faire les deux. 

[Mike118]

Puisque tu t'intéresse au PID Oracid ce lien peut t'intéresser : https://www.pm-robotix.eu/2022/02/02/asservissement-et-pilotage-de-robot-autonome/ 

De manière générale les articles présentés par pm-robotix sont sympas et méritent un coup d'oeil

[Oracid]

Merci Mike, je vais regarder ça de très près.

[pat92fr]

Bonjour,

 

Ils vont vite ces suiveurs de ligne ! Je me suis intéressé à ce genre de compétition, mais sans aller au bout.

 

Est-ce que tu peux avoir une valeur proportionnelle de la position de la ligne à partir de la caméra ?

Est-ce que tu sais afficher la position de la ligne renvoyée par la caméra ? Notamment dans les situations suivantes :

1) la valeur de position en présence d'une ligne partant à 90°,

2) la valeur de position en l'absence de ligne,

3) la dernière valeur de position avant perte de vue de la ligne.

 

Sur un suiveur de ligne rapide, l'implémentation d'un ou plusieurs PID est avantageuse pour contrôler la position par rapport à la ligne et l'allure du robot (accélération, vitesse dans les virages, vitesse max en ligne droite, décélération, anti-wheeling au départ..).

 

Pour le code, la base Arduino : Cf. https://playground.a...ode/PIDLibrary/

 

Ma petite expérience est que le terme 'I' du PID n'est pas indispensable pour ce genre de robot. Difficile à régler, surtout avec les implémentations naïves des PID (c-a-d sans anti-windup). En revanche, il y a un réel apport du 'D' sur la commande de direction, pour stabiliser le robot en ligne droite et en sortie de virage, et pour mieux négocier les virages serrés. De mémoire, j'avais une valeur de Kd sur la direction très élevée. La branche D du PID peut nécessiter un filtrage ('passe bas') pour éviter d'amplifier l'éventuel bruit dans l'estimation de la position de ligne (cf. https://controlguru....n-our-pid-loop/). Ce filtrage  peut s'implémenter avec un EWMA (cf. https://www.arduino....libraries/ewma/ ) et en réglant le coefficient Alpha manuellement (ex. : une valeur initiale de 0.5 et on diminue jusqu'à obtenir un bon filtrage faute de pouvoir l'estimer mathématiquement). 

 

Si tu es motivé, tu peux tester les choses suivantes :

1) implémenter un asservissement de type PD (juste Kp et Kd, avec Ki = 0) qui prend en entrée la position de la ligne et qui commande la direction (différentiel entre moteur droit et gauche sur le tank). 

2) implémenter un asservissement basique de type P qui prend en entrée la position de la ligne et qui commande la vitesse d'avance :  vitesse_courante = vitesse_max * ( 1.0 - K * |erreur_position|). Vitesse max étant ta consigne de vitesse constante dans le code.

3) implémenter un asservissement en boucle ouverte (sans PID) qui se substitue aux asservissements (1) + (2) lorsque la ligne disparait. Il faut pouvoir mémoriser la dernière position valide de la ligne  :

        - si la ligne a disparu à droite => tourner à droite à fond, sur-place,

        - si la ligne a disparu à gauche => tourner à gauche à fond, sur-place.

 

En termes de réglages :

A) Tout mettre à 0 (Kp, Kd, K...).

B ) choisir une vitesse croisière faible pour commencer

C) Régler Kp position du (1) pour suivre la ligne

D) Régler Kd position du (1) pour supprimer toute oscillation en ligne droite et sortie de virage

E) Augmenter la vitesse, régler K du (2) pour ralentir le robot dans les virages serrés, ajuster Kp pour suivre la ligne et Kd pour supprimer les oscillations

F) Augmenter encore vitesse et tester (3) et vérifier que le robot récupère la ligne, ajuster Kp, Kd, K. 

 

Tout ca est plus facile à régler avec une connexion Wifi ou BT avec le robot.

 

Si jamais, ca commence à aller vite, il faut savoir piloter la direction et l'allure plus finement. Par exemple, j'obtenais de bons résultats en 'dupliquant' le PID du (1) :

- un PID pour gérer les virages avec un Kp assez élevé

- un PID pour gérer les longues lignes droites, avec un KP très faible (le robot ne corrige pratiquement plus sa position par rapport à la ligne et il atteint sa vitesse max). 

Ca demande un petit automate pour basculer entre deux jeux de paramètres (Kp, Ki, Kd) en fonction de la situation. Il y a peut-être une façon de faire plus subtile... mais c'est ce que j'avais implémenté à la dernière TRR sur Neunoeil. Le buggy passait à 40km/h sous le portique d'arrivée, donc ca marche. 

 

Bon courage.

 

 

PS : un suiveur de ligne datant de 2016, les premiers essais ! Ca n'allait pas très vite. En fait, c'était la première mise en route de la turbine électrique, pour coller le robot au sol. 

https://youtu.be/8_x53j2HSG8

[Oracid]

Merci Patrick pour toutes ces informations. J'aimerais bien aller un peu plus loin dans le PID, mais je crains de me lasser. En tout cas j'essaye.

Voici mon dernier essai avec un robot à roues et non à chenilles. Il va moins vite que le tien, mais il n'est pas du tout ridicule.

La bonne idée, bizarrement, ça été de surélever la caméra pour ne pas perdre la ligne tout en gardant la caméra la plus parallèle au sol pour suivre la ligne au plus près.

Mais oui, on peut afficher pas mal de choses, mais pas sûr quand on perd la ligne à 90°. C'est un défaut connu du HusyLens.

La ligne est représentée par une flèche plus ou moins longue, en fonction de la qualité de la vison de la ligne. On peut avoir la longueur de la flèche car on a la position des 2 extrémités de la flèche.

Là, je suis au Mexique et je ne peux pas répondre à toutes tes questions. 

 

                                                         

[Oracid]

Bonjour tout le monde, me revoilà.

De retour du Mexique et des sports d'hivers.

Du coup, je suis "cas contact", mais pas de souci, je vais très bien. Je vais aller me faire tester, dès ce matin.

 

En tout cas, bien content de revoir mes Lego et ma cave.

Je vais relire vos commentaires et essayer de répondre à vos questions.

[Oracid]

Voici mes réponses aux interrogations de Patrick.

 

En configuration suiveur de ligne, l'HuskyLens affiche une flèche de taille variable à l'écran. Cette flèche se superpose à la ligne, dès qu'elle est détectée.

Les coordonnées X et Y de la tête de la flèche et de la queue de la flèche sont accessibles. 

Ces valeurs font référence aux coordonnées de l'écran, pour X de 0 à 320 et pour Y de 0 à 240; La coordonnée (0,0) étant en haut à gauche de l'écran.

 

"1) la valeur de position en présence d'une ligne partant à 90°". 

Malheureusement, dès que la ligne part à 90°, l'HuskyLens perd les coordonnées de la flèche, alors que la flèche est visible. Néanmoins, en positionnant la caméra à l'avant du robot, en hauteur et avec un léger angle par rapport au sol, cela aide beaucoup à la perception de la ligne par anticipation, mais le suivi de la ligne n'est pas parfait. Je dirais qu'il "optimise" la trajectoire.

 

"2) la valeur de position en l'absence de ligne" et "3) la dernière valeur de position avant perte de vue de la ligne."

On peut se baser sur la dernière position valide. Par ailleurs, avec les coordonnées des deux extrémités de la flèche, on peut savoir dans qu'elle direction la ligne allait, gauche ou droite.

 

J'ai choisi de ne pas utilisé de bibliothèque PID. Les calculs ne me semblent pas très compliqués, mais je pourrais changer d'avis.

 

"Ma petite expérience est que le terme 'I' du PID n'est pas indispensable "

C'est bien ce qui me semblait. Pour l'instant, je l'ai mis à 0, mais j'ai vu un exemple avec une valeur à 0,0001. Est que cette valeur est pertinente, je l'ignore.

 

Les anti-windup ou anti-wheeling ? Etant sur un roulant, je ne m'en suis pas préoccupé.

 

Les coordonnées des extrémités de la flèche et le positionnement de la caméra en hauteur et en angle, devraient permettre d'aller au delà des traditionnels rampes de capteurs. J'ai l'intuition que c'est plutôt dans cette direction que l'HuskyLens se positionnera, dans la discipline du suiveur de ligne.

 

Pour ma part, je ne suis pas sûr d'aller au delà d'une mise en œuvre minimaliste. J'ai déjà écrit mon code que je vous soumettrai, bientôt.

En cherchant des exemples, je me suis rendu compte que malgré un très grand nombre de vidéos, les codes accessibles et courts n'étaient, au final, pas très nombreux.

Avec un code très simple, si je compare mon robot roulant avec les suiveurs de ligne dotés d'un HuksyLens, je pense être, malgré tout, le plus rapide. Que demander de plus ?

 

Mon objectif est de mettre l'HuskyLens sur mon quadrupède, pour lui faire courir la piste des roulants à la prochaine TRR.

Je n'arriverai sans doute pas le premier, mais je serai le premier à l'avoir fait . . .  

[Oracid]

Comme promis, je vous soumets donc le code de mon petit chariot que vous pouvez voir quelques posts plus haut.

Ce code est très similaire au code précédent, à ceci près que le map() de la fonction loop() centre les coordonnées de l'écran.

Suivi d'une unique ligne dans laquelle tous les calculs du PID sont réunis.

Notez qu'avec Kp=0.5625, la position de l'écran est converti en degrés. La valeur de Kd=0.055 a été déterminé par les tests, quand à Ki=0.001, j'ai un très gros doute sur sa nécessité.

 

Avec moins de 30 lignes, ce code est très minimaliste. C'est volontaire, mon objectif n'étant pas d'approfondir le PID avec des calculs hors de ma portée.

 

Voilà, sauf erreur grossière dans mon code, je vais sans doute faire une petite vidéo, puis le tester sur mon quadrupède.

 

// 15/03/2022 - Chariot robot with PID
#include <HUSKYLENS.h>
#include <Servo.h>
void(* resetFunc) (void) = 0;       // soft reset function
Servo sR,sL;                        // right servo and left servo
int R, L;                           // right servo value, left servo value
HUSKYLENS huskylens; int ID1=1;     // HuskyLens objet
HUSKYLENSResult result;             // HuskyLens values
float Kp = 0.5625, Ki = 0.001, Kd = 0.055;  // PID constants
int pid, p=0, i=0, d=0, err=0, lastErr=0;   // PID variables
 
void setup() {
  delay(400);                       // for soft reset consideration
  Serial.begin(9600);               // Serial initialization
  pinMode(6,INPUT_PULLUP);          // start/stop/reset button attachment
  sL.attach(2);sL.write(90);        // left   servo, 0->FW, 90->stop, 180->BW
  sR.attach(3);sR.write(90);        // right  servo, 0->FW, 90->stop, 180->BW
  Wire.begin();                     // I2C initialization
  while (!huskylens.begin(Wire)) {Serial.print("\n Check I2C"); delay(100);}
  huskylens.writeAlgorithm(ALGORITHM_LINE_TRACKING); //Switch to line tracking.
  Serial.print("\n\t To start, click on the Start button"); while( digitalRead(6) ); delay(400);
}
 
void loop() {
  if (! digitalRead(6)) resetFunc();
  huskylens.request(ID1);  result = huskylens.read();
  err = map(result.xTarget,0,320,-160,160); //Serial.print(String()+("\n err=")+err);  // getting and maping err
  p = Kp*err;  i = Ki*(i+err);  d = Kd*(err-lastErr);  pid = p+i+d;  lastErr = err;
  if ( pid < 0) { L=-pid; R=0; }  else  { L=0; R=pid; } // error makes turning left or right
  sL.write(L);  sR.write(R);                            // left and right servos order
}

[Oracid]

Et voilà la vidéo !

Bon, je vais arrêter sur ce sujet qui m'a pris beaucoup de temps, pour me remettre à mes chers quadrupèdes.