18 réponses à ce sujet

[FPI]

Bonsoir,

 

Dans le cadre de mon chariot autonome roulant, je n'ai que deux sonars SRF08 à l'avant et un à l'arrière.

Cela permet d'éviter les chocs, et cela donne une petite informations de position de l'obstacle en utilisant la géolocalisation du robot (GPS) , son cap (magnétomètre), et la distance à l'obstacle détecté.

Mais c'est très basique vu la précision angulaire d'un tel sonar. Je me contente de m'arrêter avant l'obstacle, de calculer un trajet d'évitement, puis de parcourir la suite du trajet (voir capture "trajectoire d'évitement)

 

J'ai développé l'interface avec un YLIDAR-X4 en NodeJs sur RasPi4, et le résultat de l'acquisition est affiché sur la capture jointe (l'interface Web de supervision du chariot).

Je dispose en temps réel (environs 10 fois par seconde) de la cartographie "angulaire" (une collection des couples {angle, première distance de collision}.

 

Comment exploiter intelligemment ces données pour naviguer suivant un trajet prédéfini, tout en découvrant progressivement la cartographie des "accidents" via le Lidar ?

 

Plus généralement, quelles sont les techniques/algorithmes implémentables, sans basculer tout de suite sur une Jetson Xavier et l'IA ?

 

Merci de vos suggestions.

Image(s) jointe(s)

• 
• 

[Sandro]

Bonsoir,

je dirais que la première question est quel est le type d'obstacles que tu es susceptible de rencontrer (petits ou gros obstacles? Garantie de pouvoir passer entre les obstacles ou pas? présence de "pièges" (endroits où il faut s'éloigner de la cible pour pouvoir l'atteindre)? ...)

 

Pour une situation simple (obstacles ponctuels et isolés, pas de pièges), tu peux tenter l'approche suivante :

- si dans la direction de la cible, sur une largeur L1 (= largeur du robot+ sécurité), il n'y a aucun obstacle à une distance inférieurs à D (à toi de choisir, 2-3 fois la taille de ton robot me semble raisonnable), alors tu avances tout droit vers la destination

- s'il y a un obstacle dans la largeur L1 à moins de D mètres sur le chemin vers la destination, alors tu calcules les azimuts correspondant au bord de l'obstacle. tu choisis le coté où l'erreur d'azimut est le plus petit, et tu vises cet azimut +- l'angle nécessaire pour passer à une distance L1 de l'obstacle

 

Si tu as des obstacles plus nombreux/proches, tu peux fusionner les obstacles trop proches pour passer entre.

 

 

 

Si tu es sur ces cas plus complexes, tu veux envisager des stratégies du type :

- s'il n'y a pas d'obstacle, j'avance droit vers la cible

- s'il y a un/des obstacle(s), je le suis toujours par la gauche jusqu'à arriver à un endroit d'où je peux quitter l'obstacle vers la cible. Nb : il faut faire attention à ne pas retourner dans le même creux, par exemple si ton obstacle est un G et que tu veux aller à gauche, tu peux entrer par la droite, suivre le G jusqu'au bout du trait horizontal, et repartir vers le milieu du G en pensant que tu es sorti de l'obstacle. Tu peux améliorer un peu les choses en autorisant de quitter l'obstacle seulement si tu es plus proche de la cible que lorsque tu l'a rencontré. Mais même comme ça, je penses qu'il existe encore des pièges

 

Enfin, si tu veux pouvoir gérer n'importe quelle situation (beaucoup d'obstacles dont des "pièges"), alors je penses que tu sera obligé de passer par une planification globale, ce qui nécessite de créer une carte (soit fixe, soit via du SLAM)

[FPI]

Merci.

Comme je crains d'avoir beaucoup d'obstacle (comme c'est un Lidar 2D, je vais forcément ne pas "voir" ce qui est bas, pour éviter de se faire arracher le lidar), et que je lis l'acronyme SLAM un peu partout, existe t'il des tutoriels, ou du moins des présentations du principes ?

Cordialement. 

[Mike118]

Le SLAM : Simultaneous localisation and mapping. 

Tu peux déjà le séparer en deux problème distinct : 

Localisation : Le fait de se repérer dans un carte existant. ( repérer le robot dans un repère fixe et invariant / connu )
Mapping : Le fait de créer une carte avec les données que tu as. ( Transformer les points lidar en " obstacles localisés  " )

Si tu arrives déjà à faire les deux séparément il ne te restera plus qu'à redoubler d'astuces pour résoudre le 3ème problème 

" Simultaneous " ( mais de la même façon qu'un microcontrôleur ne fait pas deux choses en même temps, il te suffit d'alterner entre localisation et mapping ... )

 

Après tu n'es pas obligé de faire du slam pour faire du " path planning" / " de l'évitement d'obstacle" . 

Tu peux te contenter de la partie mapping. Et d'avoir une carte non pas fixe par exemple mais liée au repère du robot.  

Dans cette "carte " tu peux avoir suffisamment de donnée pour éviter un obstacle comme un buisson dans un jardin, ce qui est bien ton cas non ?
Dans ce genre de cas c'est essentiellement des calculs de géométrie : Est ce que mon chemin coupe un obstacle ? Calcul d'intersection de deux segments   entre le segment [ (0,0) = le robot, (ciblex, cibley)] et le segment [ (MurA.x,MurA.y) , (MurB.x,MurB.y)] décrit par les deux extrémités du mur. 
Savoir si il y a un point lidar obstacle sur le chemin en prenant en compte la largeur du robot ? Regarder si un point est inclus dans le rectable formé par la surface que va parcourir le robot en allant de là où il est à sa cible ... 
Savoir si deux morceaux de murs sont en fait un seul et même mur ? Calculer l'angle entre  les droites des deux segments de ces murs et vérifier si le point d'intersection est suffisamment proche et deux trois petit autres détails etc ...
( par contre ce genre de solution c'est pas le meilleur choix pour la sortie d'un labyrinthe ... ) 

Pour la partie localisation avec un lidar il faut " suffisamment de données " pour le faire . En indoor ça se fait. En extérieur c'est plus compliqué. Généralement il n'y a pas assez d'obstacles, sur lesquels se repérer et le robot se perd avant de réussir à se relocaliser sur des repères connus ... Par contre tu peux toujours faire ton mapping avec du lidar, et faire ta localisation avec une ou plusieurs technologies. ( balise uwb, gps rtk etc ... )
 

[FPI]

Merci pour ces suggestions.

Voilà déjà du grain à moudre pour ces bonnes soirées d'hiver.

Si quelqu'un a déjà une expérience pour pré-traiter les points disparates et les interpréter en fonction de leurs caractéristiques géométriques...

Cordialement.

Image(s) jointe(s)

• 

[Sandro]

Qu'est-ce que tu veux faire de ces points exactement?

Déterminer est-ce que c'est le même objet?

Savoir s'il y a un passage pour le robot?

Déterminer la forme de l'objet?

Pouvoir utiliser l'objet pour de la localisation?

 

 

Si le but est de savoir si tu peux passer, alors tu peux utiliser la règle suivante (L étant largeur minimale pour que le robot puisse passer "en sécurité"):

1) si deux points sont à une distance inférieure à L, alors tu es sur que tu ne peux pas passer (tu peux considérer qu'ils font parti du même obstacle pour simplifier la navigation)

2) si deux poins sont a une distance supérieurs à L, alors tu peux PEUT-ÊTRE passer : il y a 2 sous cas

2.1) si tu ramène le point le plus loin à la même distance que le plus proche (en gardant le même angle), et que tu peux encore passer, alors tu es sur de pouvoir passer

2.2) sinon, il n'existe aucun moyen de savoir si ça passe ou pas avec l'information dont tu dispose : au choix, soit tu choisis dessuite un autre chemin, soit tu te diriges vers le passage en espérant qu'il soit assez large, et tu changes de chemin si besoin

[FPI]

Ok.

Tu entends, par" distance", la grandeur du vecteur V3 ?

Cordialement.

Image(s) jointe(s)

• 

[Mike118]

Oui  la distance entre tes deux points est égale à la norme du vecteur v3. Pour ce faire le plus simple est de passer en coordonnées carthésienne (x,y) pour faire des calculs.

 

Merci pour ces suggestions.

Voilà déjà du grain à moudre pour ces bonnes soirées d'hiver.

Si quelqu'un a déjà une expérience pour pré-traiter les points disparates et les interpréter en fonction de leurs caractéristiques géométriques...

Cordialement.

 

En tout cas là tu rentres justement dans la problématique de base du mapping vectoriel ( qui se base uniquement sur des définitions géométrique et qui s'oppose au mapping en grille ) . Mais tu peux bien utiliser l'un ou l'autre, voir même les deux.

Dans mes remarques 

 

 

Dans ce genre de cas c'est essentiellement des calculs de géométrie : Est ce que mon chemin coupe un obstacle ? Calcul d'intersection de deux segments   entre le segment [ (0,0) = le robot, (ciblex, cibley)] et le segment [ (MurA.x,MurA.y) , (MurB.x,MurB.y)] décrit par les deux extrémités du mur. 
Savoir si il y a un point lidar obstacle sur le chemin en prenant en compte la largeur du robot ? Regarder si un point est inclus dans le rectangle formé par la surface que va parcourir le robot en allant de là où il est à sa cible ... 
Savoir si deux morceaux de murs sont en fait un seul et même mur ? Calculer l'angle entre  les droites des deux segments de ces murs et vérifier si le point d'intersection est suffisamment proche et deux trois petit autres détails etc ...
 

 

 

j'ai uniquement parlé de notions géométrique en partant du principe qu'on était dans une map " vectorielle " générée par les points obstacles, mais il y a aussi l'approche en grille qui est celle le plus souvent utilisée. Tu poses tes points obstacles dans ta gridmap et tu vérifier si les grilles sont libres d'obstacles ou pas
Les calculs sont alors moins "géométrique". 

Mais c'est le plus souvent la démarche utilisée dans la littérature...( Mais c'est pas l'approche que j'ai personnellement prise pour mon SLAM vectoriel )

 

Si tu veux faire du vectoriel à toi de voir quels sont les règles que tu vas appliquer pour voir si les points font parti du même obstacle ou non, est ce qu'il forme une ligne etc ... Personnellement j'ai choisis de " diviser pour mieux régner, en agissant tâche par tache, en prenant un peu le même principe que les différents noeuds d'un réseau de neurones. 

Un scan => Isoler des îlots de points à traiter ensemble grâce à leur proximité  => Filtrer si il y a des groupes d'un seul point =>  Vérifier si il y a des droites à extraire des groupes et redécouper si besoin les groupes de points en sous groupes  si besoin ... 


 

[Atmos]

Très intéressant, malgré que je peine un peu.

 

Est-ce que vous pouvez m'éclairer concernant deux questions ?

 

Comment créer une grille ?

Comment la dessiner ? Sur écran du PC après ou sur un écran LCD.

Et plus tard comment la superposer sur une map Google ou autres ?

 

Salutations

[FPI]

Très intéressant, malgré que je peine un peu.

 

Est-ce que vous pouvez m'éclairer concernant deux questions ?

 

Comment créer une grille ?

Comment la dessiner ? Sur écran du PC après ou sur un écran LCD.

Et plus tard comment la superposer sur une map Google ou autres ?

 

Salutations

 

Sauf si je n'ai pas compris la question, je dirais qu'il y a plusieurs aspects:

- le coeur du logiciel gère une matrice à deux dimensions (x,y), avec une résolution au cm, dm, m... et à chaque détection on remplit les cases.

- si on a une interface http pour afficher des pages et dialoguer avec le coeur, on peut intégrer un objet "canvas", et dessiner des points, des traits, du texte, pivoter, translater, etc... Le coeur transmet en T.R. soit l'intégralité de la matrice, soit des mises-à-jour avec la cellule modifiée (coordonnées, contenu).

- si on veut visualiser sur une carte, on peut intégrer une carte OpenStreetMap, et y ajouter des marqueurs, des formes, du texte... Mais il faut convertir les coordonnées X,Y en latitude/longitude. Mais cela suppose par exemple que le PC soit connecté sur le hotspot wifi du coeur pour échanger les données, et connecté en USB sur un smartphone pour recevoir les "tuiles" des cartes OpenStreetMap.

[FPI]

En ce qui concerne le SLAM, autant j'imagine bien utiliser les angle/distance pour construire une vue à un instant donné, autant je ne comprend pas comment prendre en compte le déplacement du robot une itération plus tard lorsqu'il se déplace.

Car en intérieur, sauf d'utiliser des balises et de la triangulation (je sais qu'il y a des travaux avec du bluetooth, mais si vous utilisez d'autres techniques, ça m'intéresse), soit d'utiliser des Odomètres très précis, comment savez-vous où vous étiez, et où vous êtes ?

A moins de chercher d'abord le "contact" avec  un obstacle significatif et bien statique, et d'évoluer par rapport à lui...

[Mike118]

En ce qui concerne le SLAM, autant j'imagine bien utiliser les angle/distance pour construire une vue à un instant donné, autant je ne comprend pas comment prendre en compte le déplacement du robot une itération plus tard lorsqu'il se déplace.

 

 

 

ça c'est le problème de "localisation". 

Les données sont les suivantes : Tu as une carte connue en mémoire.  Tu voies un peu de la carte autour de toi, le but est de trouver l'opération de translation / rotation, qui permet de faire matcher les obstacle que tu vois dans ton repère de robot de sorte à ce que ça se superpose nickel sur la carte que tu as en mémoire. 

Imagine que tu as une pièce d'un puzzle ( ça représente ce que tu vois comme obstacle  autour de toi ), et que tu as l'image du puzzle à côté, tu cherches à repérer les motifs que tu as sur ta pièces de puzzle, pour chercher où est ce qu'il se place sur l'image du puzzle. 

Maintenant le SLAM, au début du commence par une seul pièce du puzzle, tu ne sais pas à quoi ressemble l'image finale, mais tu la construit au fur et à mesure en te basant sur les formes des pièces que tu assembles au fur et à mesure.

[Mike118]

Très intéressant, malgré que je peine un peu.

 

Est-ce que vous pouvez m'éclairer concernant deux questions ?

 

Comment créer une grille ?

Comment la dessiner ? Sur écran du PC après ou sur un écran LCD.

Et plus tard comment la superposer sur une map Google ou autres ?

 

Salutations

 

Oui une gilles c'est juste un tableau 2D. 

Pour l'afficher sur un écran de PC tu peux faire une communication entre ta arduino et ton pc et faire un petit logiciel qui va t'afficher des carré de différentes couleurs en fonctions des données que tu envois par exemplent. 

Sinon si tu as un écran " graphique " tu peux aussi déssiner des rectangles ou autre ...

[Atmos]

Actuellement, j'ai (en fin de parcours) une carte SD avec un tableau contenant une struct (distanceFDroite, distanceFG, distanceD, distanceG, compas, latitude, longitude, distanceversWp, azimut, degres, fonctions)

 

Ce que j'aimerai c'est retranscrire sur une carte (grille) afin de dessiner les informations à ma disposition afin de visualiser le parcours. Après, on verra ensuite pour le faire en direct.

 

Existe t'il une library ou un logiciel qui permette ceci car je bien incapable de l'écrire.

 

Salutations

[FPI]

Bonjour,

Je vais essayer de te fournir de quoi faire, mais il faudra que tu te penches un peu sur le code.

Je ne sais pas ce que tu connais en programmation, donc j'espère ne pas t'offenser avec des évidences si tu connais déjà la suite ...

 

1) je te fourni un ensemble de sources en html/js que j'ai en partie écrit (vite fait) pour des ballades avec des amis. Le but était de décrire des points d'intérêt (POI) sur une carte, sans la complexité de Google Map.

On choisit le type de carte, on clique pour ajouter des POI, on peut les commenter (clic droit) et les supprimer, et sauvegarder l'ensemble dans un fichier que l'on peut recharger.

J'ai juste ajouter pour toi le "tracé" d'un polygone reliant les POI.

Le principe des données manipulée est toujours le format JSON. Le contenu du fichier est chargé comme une chaine, la fonction JSON.parse le convertit en une structure json. On le sauvegarde en convertissant le json en chaine avec la fonction JSON.stringify.

Il te faudra donc que ton tableau de structure soit plutôt au format JSON. Si tu ne connais pas, c'est vraiment simple à faire :

- accolade-ouvrante,

- mot-clé, deux-point,

--> soit valeur-chaine (entre double quote), soit numérique telle-quelle,

--> soit une sous-structure (accolade, etc...), soit un tableau ( crochet ouvrant, valeur, virgule, valeur... crocher-fermant)

--> soit un tableau

- accolade-fermante.

 

2) Pour utiliser le tout, il faut :

- dezipper MapWalker dans un répertoire

- lancer le mini serveur http depuis une fenêtre console et contenu dans ce même répertoire (maintSmallHttpServer.cmd , qui lance lui-même miniweb.exe avec les bons paramètres)

- lancer ensuite, depuis chrome, "http://127.0.0.1:8000/MapWalker.html"(en 127.0.0.1 puisque le serveur web vient d'être lancé sur ta machine).

- tu peux tester l'outil en chargeant le fichier "MapWalker\MapWalker-2021-12-19 11_06_24.json" donné en exemple.

 

Ensuite, à toi d'adapter le code pour tes propres données.

- la fonction "processLoadParcoursFile()",

- elle même appelant MWParcours.loadFromData pour ajouter tous les points à l'objet parcours

- qui lui-meme crée des MWPoint "accroché à la carte (this.marker = L.marker( this.pos, ... ).addTo( this.mapView)

 

Si tu ne sais pas comment debugger du js :

- tu modifies le code avec un éditeur de texte quelconque. 

- sous chrome, tu appuie sur F12 pour afficher le debugger

- tu sélectionne l'onglet "Sources" pour choisir le fichier à inspecter (le html principal ou un sous-module en .js)

- tu accède au fichier, 

- tu pose un point d'arrêt en cliquant à gauche du n° de ligne

- tu recharges la page avec F5

- tu avance pas-à-pas avec F0, tu entres dans une fonction avec F11

- tu poursuis l'exécution avec F8.

 

Ce code est utilisable pour analyser tes données.

Tu pourrais utiliser quasiment le même si tu étais connecté en Websocket à ton robot, et que celui-ci t'envoyais en temps-réel les nouveaux points découvert.

 

NB : Pour indication, le mini serveur web est : MiniWeb (build 300, built on Feb 28 2013) ©2005-2013 Written by Stanley Huang <stanleyhuangyc@gmail.com>

 

J'espère ne pas avoir été trop à côté de la plaque.

 

Bonsoir.

Fichier(s) joint(s)

•  MapWalker.zip   858,67 Ko   95 téléchargement(s)

[Atmos]

Salut FPI,

 

Je viens de voir ton message et je te remercie, et j'ai de suite essayer.

 

J'entrevois d'immenses possibilités.

 

Salutations

[FPI]

Bonjour,

Toujours sur mon sujet de "mapping" de l'environnement, j'essaie la méthode suivante.

Le principe est de "voir" l'ensemble des points détectés comme une image en N&B. 

Lorsque le robot se déplace (translation et rotation), la nouvelle "image" instantanée des obstacles a subit une transformation affine (celle du mouvement du robot).

Mais je n'ai pas de capteurs me permettant d'estimer cette transformation.

La librairie OpenCv fournit une fonction permettant de discerner si éventuellement une transformation affine existe entre deux images (est-ce que c'est la même image mais avec une transformation affine). Elle retourne alors les éléments de la matrice de transformation.

Mon raisonnement est décrit dans l'image jointe.

La fonction calcule bien des coefficients (ce qui est encourageant car il y a surement certains points en plus et en moins sur les deux captures consécutives).

Mais le résultat n'est pas une carte statique, plutôt la carte en rotation ... J'ai peut-être bogué sur mon implémentation NodeJs, mais est-ce que de prime abord, mon raisonnement vous semble louche ?

Cordialement.

 

Image(s) jointe(s)

• 

[quadmean]

Bonjour,

moi j'utilise Hector Slam et ROS

[Mike118]

Bonjour,

Toujours sur mon sujet de "mapping" de l'environnement, j'essaie la méthode suivante.

Le principe est de "voir" l'ensemble des points détectés comme une image en N&B. 

Lorsque le robot se déplace (translation et rotation), la nouvelle "image" instantanée des obstacles a subit une transformation affine (celle du mouvement du robot).

Mais je n'ai pas de capteurs me permettant d'estimer cette transformation.

La librairie OpenCv fournit une fonction permettant de discerner si éventuellement une transformation affine existe entre deux images (est-ce que c'est la même image mais avec une transformation affine). Elle retourne alors les éléments de la matrice de transformation.

Mon raisonnement est décrit dans l'image jointe.

La fonction calcule bien des coefficients (ce qui est encourageant car il y a surement certains points en plus et en moins sur les deux captures consécutives).

Mais le résultat n'est pas une carte statique, plutôt la carte en rotation ... J'ai peut-être bogué sur mon implémentation NodeJs, mais est-ce que de prime abord, mon raisonnement vous semble louche ?

Cordialement.

 

 

Je n'ai pas compris ce que tu veux dire par " la carte en rotation ". 

En tout cas de ce que j'ai compris de ton raisonnement il me semble que tu es sur la bonne voix. 
Mais histoire d'en être sûr je peux reformuler. 

Etape 0 : Le robot est en coordonnée [0,0] dans le repère R0 et il voit deux obstacles  A ( 0, 1)  B (1, 1) . 

Le robot se déplace un peut et il tourne. Et on se retrouve à l'étape 1. 
Etape 1 : Le robot est désormais en coordonnées [0,0] dans le repère R1. Il voit toujours deux obstacles. Mais cette fois ci ils sont en coordonées
X ( 1.4, -1 ) et Y( 0.7 , -1.7). et un autre un peu plus loin Z en  (0 , 1) .

Il faut alors définir qui de X et Y ( et Z) est A et B. ( Dans mon exemple, B = X et A = Y )  ( Phase d'association) 

Une fois cela défini il faut en déduire la transformation entre R0 et R1. ( Au pire si on est pas capable de discriminer A et B on fait les différentes hypothèses possible, ( Z etant trop loin de X et Y il ne peut être ni A ni B ... ) on fait les calculs et on choisi ensuite le résultat le plus cohérent ( le déplacement le plus petit ) . )
(Phase de calcul de transformée )

Dans mon exemple le robot a tourné de 45° dans le sens trigo et  s'est déplacé de 1 sur l'axe y dans le repère R1.

Une fois cette transformation calculée, on en déduit que le robot est désormais au coordonnées -0.7, 0,7 dans le repère R0 ... = Relocalisation terminée )
On en déduis alors que Z = ( -1.4, 1.4) dans le repère R0. Ainsi on a complété notre carte R0. ( mapping)

Bref, l'objectif c'est de toujours se relocaliser sur la même map, et d'ajouter les nouveaux points rencontrés sur cette map ...