Bonjour,

parcourir une surface délimitée par un polygone
#1
Posté 10 décembre 2021 - 02:14
- Biacuup aime ceci
#2
Posté 10 décembre 2021 - 02:41
Bonjour,
sans prétendre être optimal, j'ai deux solutions assez simples et relativement optimisées à te proposer, à condition que ton polygone soit convexe (ie toutes les diagonales restent dans l'intérieur du polygone).
Solution 1 :
tu fais un tour complet en longeant le bord. Si tu exclus la zone traitée, tu obtiens un nouveau polygone plus petit : tu continue ainsi jusqu'à ce qu'il ne reste plus rien à traiter. Je penses que la distance parcourue sera en général très près du minimum. Par contre, à la fin, on tourne beaucoup (je sais pas si ton robot à besoin de beaucoup de temps ou pas pour tourner).
Si tu veux traiter le cas non convexe, je vois deux pistes :
A) tu fais de la même manière jusqu'à ce que la surface restante soit en deux parties : tu traites alors les deux parties l'une après l'autre
tu découpes dès le départ le polygone en 2 (ou plus) polygones convexes, que tu traites succéssivement
Solution 2 : tu commence en longeant un coté, puis tu fais des trajets toujours parallèles à ce trajet, en t'écartant progressivement du coté initial.
Si le polygone est non convexe, tu peux parfois t'en sortir en choisissant le bon coté auquel rester parallèle, de manière à pouvoir faire pareil. Dans le cas le plus défavorable, tu vas finir par couper la surface restante en 2 ou plus : dans ce cas, tu traites d'abord une partie, puis le reste
Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...
Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.
#3
Posté 10 décembre 2021 - 02:50
Merci pour ces deux intéressantes suggestions.
Le suivi des bords avec détermination d'un polygone me plait bien, car j'ai déjà codé le suivi de trajectoire en m'inspirant de "https://www.a1k0n.ne...ollowing.html".
Oui, le robot peut tourner sur lui même en pilotant les deux moteurs avec des vitesses opposées (positive/négative).
Au travail donc.
(sachant qu'il peut y avoir des obstacles ponctuels à l'intérieur de la surface, et donc des évitement intempestifs à traiter).
#5
Posté 11 décembre 2021 - 06:02
Oui, c'est ça. C'est juste à la fin qu'on tourne beaucoup (si ton robot est lent à tourner, alors ça ralentit pas mal)
Aidez-nous à vous aider : partagez toutes les informations pertinentes : description précise du problème, contexte, schéma de câblage, liens vers la documentation des composants, votre code (ou encore mieux un code minimal reproduisant le bug), ...
Vous recevrez ainsi plus de réponses, et elles seront plus pertinentes.
#6
Posté 12 décembre 2021 - 02:53
Bonjour à tous,
Sujet passionnant, qui m'a beaucoup intéressé. Car j'y réfléchis (très fort) ces temps...
Il y a beaucoup de chose que je ne comprends pas encore, si vous pourriez m'aider.
Actuellement, mes robots arrive juste à s'arrêter lorsqu'ils ont atteint un points GPS avec une précision de 1 m ou 2. alors pour la suite, je suis encore trop ignorant.
(J'ai lu le lien fournis) mais surtout, pas très à l'aise avec les math "κ′=−Kp(ye+Kdsinψe)+κ"
Comment construire le polygone ?
Les angles du polygone sont des points GPS ?
Les lignes entre les points des distances ?
Les angles entre les lignes sont connus ?
Le robot est assez rapide pour s'arrêter ou tourner avant des dépasser ?
Vous allez me dire pourquoi tu construit des robots !!!!
Bonne après-midi
#7
Posté 12 décembre 2021 - 03:16
Bonjour,
"Comment construire le polygone ?" :
et
"Les angles du polygone sont des points GPS ?"
==> mon robot propose une interface web, sur laquelle je gère une carte (basée sur openstreetmap).
En cliquant, je sélectionne des points (avec leurs coordonnées GPS). Cela constitue le polygone que je transmet au robot.
"Les lignes entre les points des distances ?"
==> Pour manipuler plus facilement les coordonnées pour des opérations de géométrie, je réalise une conversion { latitude, longitude} en coordonnée UTM { x, y }
On peut ainsi calculer des distances enter les points en mètres.
"Les angles entre les lignes sont connus ?"
==> A partir des coordonnées converties e,n {x, y}, on obtient des vecteurs. De là les angles si on le souhaite.
"Le robot est assez rapide pour s'arrêter ou tourner avant des dépasser ?"
==> c'est là qu'il faut ajuster les paramètres "K" pour corriger la trajectoire.
Mais j'ai travaillé sur ce sujet du suivi de trajectoire depuis quasiment un an. Mon robot n'étant pas disponible souvent pour les tests (robot à la campagne, résidence en appartement), j'ai dû réaliser un simulateur de moteur.
En bref :
- le robot connait sa position et son cap (sa direction). Attention, on oscille entre des coordonnées planétaires { latitude, longitude, cap par rapport au nord }, et les coordonnées utm { x, y, dans un repère orthonormé classique où l'angle 0 est l'axe des x}
- l'interface web transmet le polygone à suivre ;
- le robot ajoute un premier point au polygone qui est la position courante du robot ;
- le robot calcule une SPline qui passe par les sommets ; A partir de, par exemple, des 10 sommets du polygone, on définit 1000 points qui forment une courbe lisse.
On dispose des fonctions permettant de calculer, en tout point de la spline, la normale, la tangente, le rayon de courbure.
- le robot s'aligne sur la tangente du premier point de la "spline" (le vecteur reliant le premier point et le point suivant)
- le robot applique la même vitesse angulaire sur les deux moteurs;
- l'interface web intègre un simulateur qui calcule quelle va être la nouvelle position du robot après un petit écart de temps (100 ms) (calcul en coordonnées UTM, conversion ensuite en { lat, lon }), ainsi que son nouveau cap.
Chaque moteur tourne à sa vitesse propre (% de la vitesse max en tours par minute [RPM]), je connais le diamètre de la roue et donc le nombre de mètres parcourus par chaque par seconde, et donc la vitesse de chaque point correspondant aux roues).
Si les vitesses sont différentes, le robot aura légèrement pivoté, et donc son cap aura changé.
- on transmet cette nouvelle position et ce nouveau cap au robot.
A partir de ces nouvelles coordonnées, le correcteur de courbe (l'article ci-dessus) détermine quel est l'écart de cap, et l'éloignement par rapport à la courbe au point le plus proche sur cette courbe.
Ce n'est que de la géométrie, mais quand on est étourdit comme moi, quand il faut respecter les unités, quand il faut le coder en traitant les erreurs et les cas limite (rayon de courbure infini...), ça occupe bien les week-end.
- Mike118 aime ceci
#8
Posté 12 décembre 2021 - 03:46
Merci de ta réponse,
Je vais devoir relire plusieurs fois tes informations.. et j'aurai d'autres questions.
J'avais essayé d'utiliser un Pixhawk, mais lorsque j'ai vu qu'il fallait pointé sur une carte pour définir un champs, puis il se guidait tout seul, j'avais abandonné.
Je voulais plutôt que le robot construise lui même sa carte en patrouillant dans le terrain et ça je ne sais toujours pas le faire. (créer une carte) je ne fais que stocker les coordonnées, GPS COMPAS et les distances.
Mais je vais étudier et chercher selon tes infos.
.
#9
Posté 12 décembre 2021 - 04:43
Bonsoir,
Cela fait parti de mes sujets.
- suivre un polygone définit par des coordonnées GPS
- parcourir l'intérieur d'un polygone (le sujet ci-dessus)
- le suivi de ma personne : J'ai développé une petite application sur Android qui transmet ma géolocalisation sur mon robot via son hotspot wifi. Le robot me suit, et s'arrête à distance de sécurité. En fait, il cherche à rejoindre ma position courante, qui change par ailleurs en permanence puisque j'avance.
Le plus difficile est le suivi d'un trajet, surtout avec des courbures toujours dans le même sens (exemple de la spirale ci-dessus), car la divergence ne peut jamais se corriger.
J'ai essayé de faire de la reconnaissance de zone simplement, mais il faut s'arrêter souvent, reculer, tourner aléatoirement dans un sens ou dans l'autre, et cela semble peu optimum.
#12
Posté 12 décembre 2021 - 06:45
Oui.
- Application en NodeJs sur Raspberry Pi 4; éventuellement une deuxième Raspberry pour sous-traiter du traitement d'image (2 WebCam) avec opencv4. Mais je n'ai pas encore exploité cette détection
- L'application en NodeJs pilote tous les périphériques (2 moteurs en PWM, servos moteurs ou 2 vrai moteurs de 300 w avec une carte SaberBooth et deux batteries de 35 A), 3 sonars, 1 GPS, 1 magnétomètre.
- L'application fait aussi serveur http et serveur Websocket
- L'interface graphique est composée de plusieurs "fenêtres" pour chaque fonctionnalité, servi par le serveur http;
- la cartographie est basée sur OpenstreetMap, avec possibilité de sauvegarder les tuiles sur une petite base de donnée sur la Raspberry quand on est connecté à un internet, et les restituer en mode offline.
- je suis aussi en cours d'intégration d'un petit Lidar YX4, mais j'ai encore beaucoup de bruit.
NodeJs me propose beaucoup de modules pour piloter les périphériques, et s'ils n'existent pas, on peut facilement porter du code python (ou même exploiter le résultat d'une exécution de code en python).
L'intérêt de ce langage est, comme il est écrit dans un tutoriel du site, quasi identique côté "moteur" et coté "interface utilisateur". On s'échange des données en json.
Ci-joint une petite présentation du projet (histoire de documenter un peu).
Fichier(s) joint(s)
- Melmet aime ceci
#13
Posté 12 décembre 2021 - 07:00
Chapeau félicitations pour tes travaux,
J'ai de la lecture et de quoi améliorer mes robots pendant un moment...
Pour ma part, je débute tranquillement avec un Raspberry Pi4, un Jetson Nano et un LidarRP et caméra depuis peu, sur banc d'essai,pas du tout intégrer au robot, mais je ne peux pas tout assimiler en même temps.
J'essaye actuellement de changer mon Arduino Mega (5 capteurs, un Gps, une boussole et le Sabertooth) par un Teensy 4.1.
#17
Posté 13 décembre 2021 - 02:16
Bonjour,
Pour rappel, J'utilise un "SparkFun GPS Breakout - NEO-M9N"
Je pense être au environ du mètre, mais je ne sais comment l'évaluer avec précision.
Ci joint également les caractéristiques de cette carte qui évoque 1.5 m.
Il doit exister dans les différents types de trames une information sur l'erreur, mais je n'ai pas encore fouillé cet aspect.
J'ai juste utilisé l'utilitaire de U-BLOX (photo ci-joint) pour modifier la fréquence de capture et passer à 333 ms au lieu de la seconde standard.
Il y a des log abondant pour étudier ce qui se passe, mais navigant dans la campagne (avec de petits arbres), je n'ai pas encore besoin de plus de précision.
Il faut dire (voir la pres. de mon engin), que j'ai ajouté une bonne antenne, car celle de mon GPS précédent (GY-NEO6MV2) était minimaliste.
Cordialement.
Répondre à ce sujet

1 utilisateur(s) li(sen)t ce sujet
0 members, 1 guests, 0 anonymous users