14 réponses à ce sujet

[pat92fr]

Voici quelques informations au sujet de la voiture "Blizzard" qui a participée à la Tiny TRR 2023 dans les catégories Roulant et DLVV. Elle a obtenu les meilleurs chronos dans les deux épreuves.

 

Ce robot est une évolution à la fois de :

- la mini-traction rouge de l'année 2022 (voir https://www.robot-ma...-tiny-trr-2022/),

- le "Phoenix" de cette année (voir https://www.robot-ma...-2023/?p=118676).

 

Avant la course :

 

Pendant la course :

 

Apres la course :

 

***

 

Ce robot trouve son inspiration dans les courses internationales de F1teenth, sur de grands circuits, avec des roulants de grande taille, bardés de capteurs (LIDAR, caméra stéréo, etc),.

 

Certains de ces robots mettent en œuvre des algorithmes de navigation qui dérivent de VFH ou encore Follow the Gap..

https://youtu.be/5asfD-_Z9x8

 

A quelques semaines de la Tiny TRR, mon premier robot "Phoenix" était prêt pour la course. Je me suis lancé dans la réalisation d'un second robot "Blizzard", permettant d'évaluer le potentiel des solutions techniques adoptées en F1theenth. En faisant courir deux robots, similaires sur le plan mécanique (même châssis, même motorisation, mêmes réglages, masse proche) mais embarquant des capteurs et des algorithmes différents, j'allai pouvoir évaluer et comparer objectivement ces différentes solutions.

 

Sincèrement, je n'étais pas convaincu par les solutions F1theenth. Le robot doit embarquer une Rpi ou une Jetson, avec son systeme alimentation (5v et 12 ou 24v), et un capteur plutôt lourd et fragile et très lent.

 

Le "Phoenix" avec plusieurs télémètres TF Mini Plus permettant jusqu'à 1000 mesures par seconde, et un algorithme "maison" cadencé à 333Hz environ tournant sur Arduino  (= fréquence PWM du servo de direction), la réactivité de l'asservissement est excellente et largement supérieure à ce qui est possible d'implémenter dans une F1teenth, à cause de la  limite de vitesse de rotation d'un LIDAR (typiquement de 10Hz à 40Hz selon le modèle) et des caméra (30 à 60fps). Et je ne parle même pas du temps de traitement de toutes ces données et de la latence que cela induit. A la vitesse de 4m/s, un délai d'acquisition et de traitement de l'ordre de 50 ms correspond à une distance parcourue de 20cm lorsque le robot est à pleine vitesse dans la ligne droite de la Tiny TRR (et ne parlons pas de la TRR normale, là ca ferait 50 cm). Ca signifie une consigne de direction et de gaz tous les 20 cm... les bordures sont toujours à moins de 50 cm du robot... je n'y croyais pas du tout.

 

Bon, j'ai changé d'avis après cette édition de la Tiny TRR ! Je comprends mieux à quel point nous (Carré92) avions du retard technologique par rapport au champion de 2019 de la dernière (maxi) TRR.. Non seulement, "Blizzard" équipé d'un LIDAR prend une seconde au tour sur "Phoenix" (même moteur, même châssis, mêmes réglages...), mais surtout il réalise la DLVV avec rigoureusement le même algorithme et les mêmes réglages, à l'exception d'une légère diminution de la vitesse maximale (75%).

 

Course 'roulant" :

https://youtu.be/N2dzRxfxbAg

 

Course "DLVV":

https://youtu.be/n84_0HI7zw4

 

A suivre !

[pat92fr]

Pour le châssis, comme "Phoenix", il s'agit d'un kit 1/10eme piste semi compétition "Schumacher Mission FT S2", traction avant, équipé d'un moteur à charbons "Tamiya Torque Tuned". L'objectif est toujours de maximiser l'agilité dans les virages et lacets de la Tiny TRR.

 

 

La garde au sol est réduite au maximum (quelques millimètres) :

 

 

La direction est réglée pour avoir le maximum de braquage, et encore des pneus à picots pour l'adhérence :

 

 

Le train arrière est équipé en odométrie, avec un capteur à effet Hall et des aimants à l'intérieur de la jante :

 

 

Le servo de direction est un SRT Servo BH615S Brushless HV Low-Profile 13Kg 0.05sec branché directement à la batterie de propulsion en 7.4V. Autant dire que c'est très réactif sur cette voiture de piste 1/10ème. Il vaut mieux éviter de brancher un tel servo sur le BEC de son ESC, car les appels de courant sont très forts (j'ai grillé un ESC) et ce serait dommage de l'alimenter en seulement 5 ou 6V.

 

 

Le variateur de vitesse est un Hobbywing Variateur Charbon Quicrun WP 1080 Crawler configuré marche AV / frein, sans marche arrière. C'est du luxe. Les options de programmation de ce variateur sont intéressantes, notamment la fonction de "drag brake" qui freine le robot lorsque l'accélérateur est relâché.

 

[pat92fr]

Le LIDAR rotatif est un Hokuyo UST-10LX tournant à 40Hz avec une résolution de 0.25° et une portée de 10m et plus.

 

 

Il est raccordé en ETHERNET/IP à une RPi4 installée sous Linux Ubuntu 22.04 LTS server 64 bits et ROS2 Humble. Le logiciel applicatif de la RPi se compose des nœuds ROS suivants :

- un nœud open-source URG_NODE2 pour l'interface avec le LIDAR (https://github.com/H...o-aut/urg_node2) ,

- un nœud "maison" implémentant un algorithme de type VFH+ et Follow the Gap,

- un nœud "maison" pour transmettre sur une liaison série, les consignes de vitesse et de direction, vers l'ESP32 en charge des asservissements.

 

Aucune information ne remonte de l'ESP32 vers la RPi. C'est l'ESP32 qui gère la course, du départ au feu ou au bouton, jusqu'à au nombre de passages sur la ligne d'arrivée, en passant par les PID vitesse et direction.

 

J'admets que le choix du LIDAR est un peu luxe, et le challenge pour l'année prochaine serait d'opter pour un LIDAR moins couteux tout en maintenant le même niveau de performance en DLVV. Je pense notamment au LD-06 disponible chez Robot Maker (https://www.robot-ma...r-ld06-468.html) et utilisé par au moins un concurrent cette année (mini pupper).

[pat92fr]

Pour l'algorithme de navigation, j'ai tout implémenté d'abord en simulation sur PC, puis j'ai porté le code sur la RPi4 dans un nœud ROS2, toujours en C/C++.

 

Bon, ca a fonctionné du premier coup ! J'ai eu de la chance. Les réglages ont été réalisés à Toulouse pendant les essais libres de la TRR, le vendredi.

 

Pour la simulation, la première étape est d'utiliser une carte du circuit, facilement manipulable. Voici le bitmap que j'ai utilisé, chaque pixel représente 1cm. 

 

 map005.bmp   11,44 Mo   59 téléchargement(s)

 

[pmdd]

Pour l'algorithme de navigation, j'ai tout implémenté d'abord en simulation sur PC, puis j'ai porté le code sur la RPi4 dans un nœud ROS2, toujours en C/C++.

 

Bon, ca a fonctionné du premier coup ! J'ai eu de la chance. Les réglages ont été réalisés à Toulouse pendant les essais libres de la TRR, le vendredi.

 

Pour la simulation, la première étape est d'utiliser une carte du circuit, facilement manipulable. Voici le bitmap que j'ai utilisé, chaque pixel représente 1cm. 

 

map005.bmp

 

Ca pèse combien cette bête ?

[pat92fr]

Sa masse est pratiquement de 2kg.

 

[pat92fr]

L’algorithme de navigation que j'ai implémenté pour la Tiny TRR comprend 4 phases, largement inspirées de VFH+ :

1. Construire un histogramme,
2. Identifier les ‘gaps’,
3. Sélectionner le meilleur ‘gap’,
4. Mettre à jour la consigne de direction (angle).

Ces phases sont exécutées à chaque "tour" de LIDAR, typiquement à la cadence de 10 à 40Hz selon le modèle de LIDAR.

 

A l'issue de chaque itération (i.e. chaque tour de LIDAR), on obtient une consigne de direction. Cette consigne est passée à l’asservissement du robot en direction, qui tentera de faire virer le robot conformément à cette consigne (ex. : asservissement en boucle-ouverte, régulateur PID…).

 

Je vais tenter de vulgariser, tout en précisant les détails qui m'ont semblés importants.

 

***

 

Plaçons le robot sur la ligne de départ, sans obstacle, pour l’exemple et l’illustration.

 

 

Etape 1 : Construire un histogramme

 

Avec un LIDAR rotatif, l’histogramme consiste en une simple mise en forme des données envoyées par ce capteur. En abscisse, l’angle de mesure (-135° à gauche à +135° à droite dans mon cas). En ordonnée, la distance mesurée (de 0m en bas à 12m en haut, dans mon cas). Pour faciliter le traitement de l’histogramme, on peut appliquer un filtrage des mesures basique (moyenne glissante sur un bloc de quatre mesures voisines).

 

 

Note : L’histogramme montre la présence des bordures et le virage en bout de ligne droite, avec un décoché correspondant au virage à droite.

 

 

Etape 2 : Identifier les ‘gaps’

 

A partir de l’histogramme, on se fixe un seuil en distance (ex. : 50cm) et on cherche tous les passages possibles. Un passage valide correspond à un groupe de mesures voisines, dont les distances sont toutes supérieures au seuil de distance fixé. Il est possible de se fixer plusieurs seuils de distance pour identifier les gaps à proximité et les gaps plus lointains. Dans mon cas, je me suis fixé 4 seuils :

• 50 cm (rouge), pour l’évitement des piétons,
• 1m (orange) pour négocier les lacets,
• 2m (vert) pour négocier les virages et une succession de virages,
• 4m (bleu) pour avoir une belle trajectoire, bien rectiligne, dans la ligne droite.

 

La recherche des ‘gaps’ se fait dans le secteur avant du robot entre -90° et +90°, matérialisé par les lignes verticales rouges dans l’histogramme. L’axe du robot (angle 0°) est matérialisé par la ligne verticale blanche dans l’histogramme.

 

Les ’gaps’ sont exprimés comme des secteurs angulaires, avec un angle de début et un angle de fin.

Pour éliminer les ‘gaps’ trop étroits, on tient compte des dimensions du robot. On prendra la demi-largeur de son robot (ex. : 12cm dans mon cas) et on réduit la largeur du gap, des deux côtés, en tenant compte de l’éloignement du gap. On retranche quelques degrés au début et à la fin du secteur angulaire en utilisant la formule : atan(demi-largeur/distance).

 

A chaque gap est associée une direction, qui se trouve, tout simplement au centre du secteur angulaire. Si on reporte les gaps sur la carte, on comprend mieux le résultat de ces calculs :

 

 

Le robot est visiblement posé légèrement à gauche de la ligne centrale. La direction à court terme est de tourner à droite (gap rouge à 50cm), et la direction (gap bleu à 4m) à long terme vise le centre de la piste.

 

Etape 3 : Sélection du meilleur gap

 

Pour chaque seuil de distance, on prend le meilleur gap en choisissant une fonction de cout pour départager les éventuels candidats. Cette fonction de cout va prendre en compte :

• la direction du gap candidat par rapport à l’axe du robot. Le gap candidat nécessitant le moins d’angle de braquage sera privilégié,
• la direction du gap candidat par rapport à la direction du robot retenue à l’itération précédente. Le gap candidat dont la direction est la plus proche de la direction des roues courante sera privilégié.

Dans cet exemple, il n’y a qu’un seul gap candidat par seuil de distance. La résolution est donc triviale (étape 4). Comme le gap le plus lointain est visible au travers des gaps successifs de plus en plus proches, la direction finale retenue pour contrôler le robot est la direction du gap le plus loin (bleu). Ainsi, malgré un placement légèrement désaxé du robot sur la ligne de départ, il va viser pratiquement tout droit et revenir en douceur au centre de la piste à l’entrée du premier virage.

 

 

En comparaison avec un PID direction basé sur deux télémètres, un à droite et un à gauche, on commence à percevoir le gain de performance apporté par cet algorithme. Strictement aucune oscillation en ligne droite.

 

Voila pour un premier post sur le sujet !

 

A suivre : un exemple plus complexe permettant d'illustrer le fonctionnement de cet algorithme. Je parlerai également de l’estimation de la consigne de vitesse qui exploite également l’histogramme.

[pat92fr]

Autre exemple, le robot prend le premier virage assez large :

 

 

Pas de visibilité à 4m (pas de gap bleu), mais un gap intéressant proche de la corde à 2m (vert).

 

 

Si on déroule deux secondes de simulation à partir de cet instant :

 

 

La trajectoire n'est certainement pas optimale dans l'ensemble, mais à chaque instant, le calcul de la direction (et de l'allure) s'avère correct, sans effet parasite (oscillations, changement de direction brusque, etc).

[pat92fr]

Simulation en départ lancé à 3m/s, pendant 9 secondes :

 

 

Aux glissades prés, c'est la trajectoire suivie par le robot le week-end dernier en épreuve roulant.

 

Note : Au dessus de cet algorithme de pilotage, il manque une stratégie basée sur la connaissance ou l'apprentissage du circuit, mais c'est un autre probleme.

[pat92fr]

Passons aux cas relatifs à la DLVV, et commençons par une map venue de l'enfer :

 

 map005obs.bmp   11,44 Mo   68 téléchargement(s)

 

Et faisons mouliner la simulation sur 12 secondes, départ arrêté :

 

[pat92fr]

A hauteur du second piéton, le scan donne l'histogramme suivant :

 

 

On a deux gaps à 50 cm et un enchainement de gaps plutôt dans l'axe.

 

Le gap rouge sélectionné est le candidat se trouvant dans l'axe du robot. Et la direction choisie au final, est celle qui correspond au gap le plus éloignée de la série.

 

 

Ainsi, la trajectoire du robot est pratiquement en ligne droite, avec juste assez de décalage sur la gauche pour ne pas rouler sur les pieds du piéton. 

 

 

Une fois le piéton passé, on voit que le robot cible le gap au dessus de la tête du chat.

 

 

L'histogramme redevient trivial :

 

 

Voila.... l'algorithme est assez efficace et demande peu de calculs pour trouver une solution acceptable. 

 

 

 

[pat92fr]

Il reste un dernier détail auquel VFH ne répond pas de manière théorique. 

 

Que faire lorsque le robot se trouve en difficulté, c'est à dire lorsque l'algorithme ne trouve aucun gap et donc ne produit aucune consigne de direction ?

 

Dans une situation "impossible", la réponse a été donnée par le robot lui-même vendredi après-midi pendant les essais libres, en coupant à travers les piétons situés au milieu de la piste, lorsque l'espace entre ces piétons et les bordures est faible ou insuffisant pour faire passer le robot !

 

Mais, si on écarte les solutions impossibles, il reste les situations où le robot a glissé et s'est trop rapproché d'un obstacle, dans la zone de distance inférieure aux 50 cm dans mon cas. L'histogramme ne donne aucun gap et l'algorithme se termine sans donner de direction.

 

Mon astuce est tirée de mes robots suiveurs de ligne. Dans ces robots, lorsqu'on perd la ligne, on braque la direction du coté où on a détecté la ligne pour la dernière fois... et on patiente ! Le plus souvent, on récupère la ligne et la course continue.

 

Sur "Blizzard", j'applique la même technique. Il braque les roues à fond du coté de la dernière consigne de direction calculée..... et pour tout le reste, il y a le parechoc à roulettes ! :-)

 

Patrick.

[Mike118]

Que faire lorsque le robot se trouve en difficulté, c'est à dire lorsque l'algorithme ne trouve aucun gap et donc ne produit aucune consigne de direction ?

 

 

 

C'est pas ouf mais au pire des cas, tu peux toujours passer la marche arrière en contre braquant ... ( Mais ton robot à toi est suffisamment performant pour ne pas avoir besoin de cette solution de secours )

[TNERA]

Again a super nice build!

 

J'admets que le choix du LIDAR est un peu luxe, et le challenge pour l'année prochaine serait d'opter pour un LIDAR moins couteux tout en maintenant le même niveau de performance en DLVV. Je pense notamment au LD-06 disponible chez Robot Maker (https://www.robot-ma...r-ld06-468.html) et utilisé par au moins un concurrent cette année (mini pupper).

 

 

This is an interesting topic, and I would like to inquire more on the choice of 'inexpensive' LIDAR and the options for the controller/navigation (and SLAM).  @mike is there a discussion board for this? has it been discussed in the past?

[Mike118]

Again a super nice build!

 

 

This is an interesting topic, and I would like to inquire more on the choice of 'inexpensive' LIDAR and the options for the controller/navigation (and SLAM).  @mike is there a discussion board for this? has it been discussed in the past?

There are some discussions about lidar and some example of SLAM on the forum but you can open a new one