Outils d'utilisateurs
informatique:hokuyo
Différences
Cette page vous donne les différences entre la révision choisie et la version actuelle de la page.
|
informatique:hokuyo [2017/08/10 18:50] michelme Maj des liens cassés, échos discrets, mise en place à la coupe, correction ortho |
informatique:hokuyo [2017/08/10 19:50] (Version actuelle) michelme Discution de la position des Hokuyos |
||
|---|---|---|---|
| Ligne 14: | Ligne 14: | ||
| - Un télémètre laser n'est pas TRES précis. J'entends par la que la précision est de quelques centimètres (plus ou moins 3% pour notre hokuyo - soit plus ou moins 9cm à 3 mètres). Certes en pratique les télémètres s'avèrent bien plus précis que ces valeurs extrêmes quand ils sont utilisés dans des conditions optimales mais cette précision reste tout de même de l'ordre du centimètre. C'est plus que suffisant pour détecter les adversaires mais pas assez pour remplacer l'odométrie. | - Un télémètre laser n'est pas TRES précis. J'entends par la que la précision est de quelques centimètres (plus ou moins 3% pour notre hokuyo - soit plus ou moins 9cm à 3 mètres). Certes en pratique les télémètres s'avèrent bien plus précis que ces valeurs extrêmes quand ils sont utilisés dans des conditions optimales mais cette précision reste tout de même de l'ordre du centimètre. C'est plus que suffisant pour détecter les adversaires mais pas assez pour remplacer l'odométrie. | ||
| - Un télémètre possèdes des angles morts. En effet comme disait Coluche "un train peut en cacher un autre" (quoi ya pas que lui qui le dit ?). Avec un seul hokuyo, si un robot se trouve juste devant la balise, un va masquer tout le reste de la carte et nous deviendrons alors aveugles. Le problème peut être résolu par l'ajout d'un deuxième hokuyo. | - Un télémètre possèdes des angles morts. En effet comme disait Coluche "un train peut en cacher un autre" (quoi ya pas que lui qui le dit ?). Avec un seul hokuyo, si un robot se trouve juste devant la balise, un va masquer tout le reste de la carte et nous deviendrons alors aveugles. Le problème peut être résolu par l'ajout d'un deuxième hokuyo. | ||
| - | - La nappe de distance est **discrète** : à une certaine distance, un obstacle peu large peut se retrouver entre deux tirs laser. Ça n'empêchera pas de détecter un robot mais on peut louper un élément de décor ou un de nos cylindres de PVC si le nombre d'échos retournés n'est pas suffisant (cf [[informatique:hokuyo#recherche_des_robots]]). Il suffit de calculer la largeur angulaire de l'objet à 3m divisée par la résolution angulaire du LiDar. | + | - La nappe de distance est **discrète** : à une certaine distance, un obstacle peu large peut se retrouver entre deux tirs laser. Ça n'empêchera pas de détecter un robot mais on peut louper un élément de décor ou un de nos cylindres de PVC si le nombre d'échos retournés n'est pas suffisant (cf [[informatique:hokuyo#recherche_des_robots]]). Il suffit de calculer la largeur angulaire de l'objet à 3m divisée par la résolution angulaire du LiDar. De ce fait, nous avons jusqu'ici affecté chacun des deux LiDar à environ une demi-table. |
| + | |||
| + | ===== Choix du positionnement des hokuyos ===== | ||
| + | |||
| + | Jusqu'en 2017, les Hokuyos étaient placés sur les tourelles en bord de table. Cela a posé les problèmes suivants :\\ | ||
| + | * on ne peut détecter que la position des adversaires | ||
| + | * cela peut demander beaucoup de temps de mise en place | ||
| + | * contrainte d'encombrement dans la tourelle | ||
| + | * contrainte d'autonomie/d'alimentation séparée | ||
| + | * contrainte de communication sans fils (cf [[informatique:communication#wifi]]) causant des latences | ||
| + | |||
| + | D'un autre côté, un hokuyo embarqué dans un robot permettrait les choses suivantes :\\ | ||
| + | * pas de contrainte d'alimentation (5V/750mA) | ||
| + | * communication câblée | ||
| + | * algorithme plus simple pour la détection d'obstacle basé sur la distance | ||
| + | * possibilité d'utiliser des algorithmes plus poussés (SLAM, recalage,...) | ||
| + | Les principaux problèmes sont l'angle de vue et l'encombrement : dans l'idéal, il faudrait positionner le lidar dans le bas du robot (pour "voir" le bord de la table) ce qui est possible dans le gros robot mais pas dans le petit. | ||
| + | |||
| + | L'idée actuelle et donc de positionner un hokuyo dans le bas du gros robot (la "tête" en bas si besoin) et un autre dans le pavé droit d'environ 8x8x10 sous la plateforme dans le haut du petit robot. | ||
| ===== Hokuyo et informatique ===== | ===== Hokuyo et informatique ===== | ||
| Ligne 28: | Ligne 46: | ||
| L'hokuyo renvoit simplement un tableau de //long//. Cela correspond à la distance des points. Nous avons donc des distance associées à des index. Il est facile de transformer index en angle à l'aide d'une fonction présente dans la librairie. On peut donc conclure que l'hokuyo nous renvoi des coordonnées radiales. Un simple cosinus/sinus les transformera en coordonnées cartésiennes. Je ne m'étend pas sur le sujet, les exemples de la documentation sont facile à comprendre. | L'hokuyo renvoit simplement un tableau de //long//. Cela correspond à la distance des points. Nous avons donc des distance associées à des index. Il est facile de transformer index en angle à l'aide d'une fonction présente dans la librairie. On peut donc conclure que l'hokuyo nous renvoi des coordonnées radiales. Un simple cosinus/sinus les transformera en coordonnées cartésiennes. Je ne m'étend pas sur le sujet, les exemples de la documentation sont facile à comprendre. | ||
| - | Voici une liste de ce que l'on peut faire : | + | Voici une liste de ce que l'on peut faire :\\ |
| * Récupérer un tableau de mesure | * Récupérer un tableau de mesure | ||
| * Demander à l'hokuyo de mesurer en continu ou juste un certain nombre de fois. | * Demander à l'hokuyo de mesurer en continu ou juste un certain nombre de fois. | ||
| Ligne 44: | Ligne 62: | ||
| Il existe trois manière de représenter l'angle d'une mesure : son angle (ce que l'on utilise), son index (son numéro de mesure) et sa step (son angle en représentation interne). Petit détail au passage : 0° est le point "en face" de l'hokuyo. | Il existe trois manière de représenter l'angle d'une mesure : son angle (ce que l'on utilise), son index (son numéro de mesure) et sa step (son angle en représentation interne). Petit détail au passage : 0° est le point "en face" de l'hokuyo. | ||
| - | En pratique voila ce qu'il faut retenir : | + | En pratique voila ce qu'il faut retenir :\\ |
| * Nous utilisons l'angle, on peut le récupérer à l'aide d'une fonction type index_to_angle. | * Nous utilisons l'angle, on peut le récupérer à l'aide d'une fonction type index_to_angle. | ||
| * L'index est, comme son nom l'indique, l'index de point dans le tableau de retour. | * L'index est, comme son nom l'indique, l'index de point dans le tableau de retour. | ||
| Ligne 55: | Ligne 73: | ||
| Un point bien angigu qui m'a vallu de bonnes prises de tête. Une fonction est disponibles pour connaitre le nombre maximal de points que renverra l'hokuyo. Cette fonction renvoit une donnée liée **au matériel** et non à la configuation de celui-ci. | Un point bien angigu qui m'a vallu de bonnes prises de tête. Une fonction est disponibles pour connaitre le nombre maximal de points que renverra l'hokuyo. Cette fonction renvoit une donnée liée **au matériel** et non à la configuation de celui-ci. | ||
| - | Ce qu'il faut comprendre est : | + | Ce qu'il faut comprendre est :\\ |
| * Si j'utilise l'hokuyo "par défaut", que je demande le nombre max de mesure, l'hokuyo me répondra par exemple 700. Je vais récupérer les données, je récupère 700 données. | * Si j'utilise l'hokuyo "par défaut", que je demande le nombre max de mesure, l'hokuyo me répondra par exemple 700. Je vais récupérer les données, je récupère 700 données. | ||
| * Si je paramètre l'hokuyo pour effectuer des mesures sur uniquement 120° (au lieu de 240) et que le lui demande le nombre max de mesure, il répondra AUSSI 700 mais lorsque je demande les données, je n'en recoit que 350. | * Si je paramètre l'hokuyo pour effectuer des mesures sur uniquement 120° (au lieu de 240) et que le lui demande le nombre max de mesure, il répondra AUSSI 700 mais lorsque je demande les données, je n'en recoit que 350. | ||
| * Ainsi si vous souhaitez connaitre le VRAI nombre de données que renvoit l'hokuyo, il faut faire une mesure, et l'hokuyo renverra le nombre de données qu'il a envoyé. Si le domaine de mesure ne change pas, le nombre de données renvoyées ne changera pas non plus. | * Ainsi si vous souhaitez connaitre le VRAI nombre de données que renvoit l'hokuyo, il faut faire une mesure, et l'hokuyo renverra le nombre de données qu'il a envoyé. Si le domaine de mesure ne change pas, le nombre de données renvoyées ne changera pas non plus. | ||
| - | **Multi-echo / Intensité :**\\ | + | **Multi-echo / Intensité :**\\ |
| Je me répète ici, mais inutile de chercher à récupérer les données de multi-echo et d'intensité. Bien que les fonction existent, le matériel ne le supporte pas. | Je me répète ici, mais inutile de chercher à récupérer les données de multi-echo et d'intensité. Bien que les fonction existent, le matériel ne le supporte pas. | ||
| Ligne 76: | Ligne 94: | ||
| ===== Algorithmes ===== | ===== Algorithmes ===== | ||
| - | ==== Clustering ==== | + | Voici les possibilités offertes par un LiDar, nous n'avons pour le moment utilisé que la première technique. |
| + | |||
| + | ==== Détection des robots adverses par groupement ==== | ||
| + | |||
| + | === Clustering === | ||
| L'hokuyo renvoi une liste d'entiers, chacun étant la distance de l’écho à un certain angle. Il faut alors traiter ces données. La première étape est de grouper ces points en cluster. | L'hokuyo renvoi une liste d'entiers, chacun étant la distance de l’écho à un certain angle. Il faut alors traiter ces données. La première étape est de grouper ces points en cluster. | ||
| Ligne 107: | Ligne 129: | ||
| Suite à cela, on dispose de groupes (clusters) de points. Le groupe ''point'' étant stocké dans le tableau ''cluster[]''. On peut alors filtrer les groupes ne comporte qu'un faible nombre de points, qui ont de fortes chances d'être des parasites. | Suite à cela, on dispose de groupes (clusters) de points. Le groupe ''point'' étant stocké dans le tableau ''cluster[]''. On peut alors filtrer les groupes ne comporte qu'un faible nombre de points, qui ont de fortes chances d'être des parasites. | ||
| - | ==== Changement de repère ==== | + | === Changement de repère === |
| Il faut ensuite convertir les coordonnées du repère polaire au repère cartésien. Chaque index correspond à un angle, que l'on peut récupérer par une fonction de la librairie. Selon la manière dont seront traités les points et les groupes, il peut être intéressant de précalculer les sinus/cosinus en fonction de l'angle. En effet, a chaque scan de l'hokuyo, un même index correspondra toujours au même angle. Ainsi il suffira d'initialiser l'hokuyo puis de calculer les tableaux d'équivalence index<->sin et index<->cosinus. | Il faut ensuite convertir les coordonnées du repère polaire au repère cartésien. Chaque index correspond à un angle, que l'on peut récupérer par une fonction de la librairie. Selon la manière dont seront traités les points et les groupes, il peut être intéressant de précalculer les sinus/cosinus en fonction de l'angle. En effet, a chaque scan de l'hokuyo, un même index correspondra toujours au même angle. Ainsi il suffira d'initialiser l'hokuyo puis de calculer les tableaux d'équivalence index<->sin et index<->cosinus. | ||
| Ligne 116: | Ligne 138: | ||
| au lieu d’appeler pour chaque point, à chaque scan, les fonction sinus et cosinus. | au lieu d’appeler pour chaque point, à chaque scan, les fonction sinus et cosinus. | ||
| - | ==== Recherche des robots ==== | + | === Recherche des robots === |
| - | === Ancienne version (<2017) === | + | == Ancienne version (<2017) == |
| Dans l'absolu, l'hokuyo devrait renvoyer un nombre de cluster égal au nombre de robots sur la carte. Or il peut arriver que l'on détecte un objet en trop (un arbitre qui passerait sa main au dessus de l'aire de jeu par exemple). On se propose donc de filtrer les cluster de la manière suivante : | Dans l'absolu, l'hokuyo devrait renvoyer un nombre de cluster égal au nombre de robots sur la carte. Or il peut arriver que l'on détecte un objet en trop (un arbitre qui passerait sa main au dessus de l'aire de jeu par exemple). On se propose donc de filtrer les cluster de la manière suivante : | ||
| Calculer la taille de chaque cluster (en millimètres, pas en nombre de points) | Calculer la taille de chaque cluster (en millimètres, pas en nombre de points) | ||
| Ligne 125: | Ligne 147: | ||
| Un autre avantage de ce tri est qu'il peut permettre de différencier les deux robots adverses en fonction de la taille de la balise. Par exemple, on peut mettre une balise plus petite sur le petit robot adverse afin de le reconnaitre. Le gros robot sera donc toujours avant le petit dans la liste des robots détectés. | Un autre avantage de ce tri est qu'il peut permettre de différencier les deux robots adverses en fonction de la taille de la balise. Par exemple, on peut mettre une balise plus petite sur le petit robot adverse afin de le reconnaitre. Le gros robot sera donc toujours avant le petit dans la liste des robots détectés. | ||
| - | === Version 2017 === | + | == Version 2017 == |
| On peut difficilement différencier les balises car elles ne représentent en pratique que quelques points, qu'une balise trop petite peut passer entre les mailles du filet et parce que le bruit et la précision ne permettent pas de différencier le diamètre de la balise. | On peut difficilement différencier les balises car elles ne représentent en pratique que quelques points, qu'une balise trop petite peut passer entre les mailles du filet et parce que le bruit et la précision ne permettent pas de différencier le diamètre de la balise. | ||
| En 2017, on a donc calculé le diamètre des clusters et on a supprimé ceux qui étaient trop grands (main, bras) ou trop petits (bruit). On a conservé tous les groupes restants. | En 2017, on a donc calculé le diamètre des clusters et on a supprimé ceux qui étaient trop grands (main, bras) ou trop petits (bruit). On a conservé tous les groupes restants. | ||
| + | |||
| + | ==== Tracking des adversaires ==== | ||
| + | Afin d'enrichir la technique précédente, il serait intéressant de tracker les robots adverses (s'ils en ont 2) pour différencier leur petit robot du gros. Des tests ont été faits en 2015 pour cela mais n'ont débouché sur rien. D'une époque à l'autre (notre Hokuyo tourne à 10 Hz), les robots ont le temps de beaucoup bouger, ralentir, se croiser, passer dans une zone d'ombre des LiDars. Un algo sur la distance par rapport à l'époque précédente ou une interpolation sur la vitesse ne sont pas vraiment suffisantes. | ||
| + | |||
| + | L'idée peut donc être d'utiliser un filtre de Kalman (vu en SY15). Il simule les systèmes à surveiller (les positions, vitesses, accélération des robots adverses ici) pour pouvoir estimer leur position à l'époque suivante. | ||
| + | |||
| + | ==== Simultaneous localization and mapping (SLAM) ==== | ||
| + | |||
| + | Cette technique, bien documentée sur le Net, permet -comme son nom l'indique- de créer/enrichir une carte de l'environnement et de se positionner sur celle-ci. Cela ne concerne que le cas où l'Hokuyo est placé dans le robot à une hauteur suffisamment basse pour percevoir des éléments de la table. | ||
| + | |||
| + | ==== Recalage ==== | ||
| + | |||
| + | Si l'hokuyo est suffisamment bas, il est possible de recaler l'[[informatique:odométrie]] sans aller taper les bords. C'est surtout intéressant pour le décalage en angle, car c'est ce qui arrive en premier (voir notre technique d'[[informatique:odométrie]]) et qui a pour conséquence la création d'un grand décalage en position. | ||
| + | |||
| + | On peut imaginer réaliser un recalage à chaque rotation du robot (éventuellement supérieur à un seuil) ou bien faire de la fusion de capteur : un filtre de Kalman (encore lui !) se sert de l'incertitude sur chaque capteur pour estimer une valeur plus proche du mesurande à partir de plusieurs mesures. Cette technique suppose deux choses : qu'on puisse considérer que la mesure de l'odométrie par roues codeuses et par LiDar soit simultanée (vrai à l'arrêt) et qu'on puisse estimer l'incertitude sur l'odométrie. | ||
informatique/hokuyo.1502383822.txt.gz · Dernière modification: 2017/08/10 18:50 par michelme
Outils de la Page
Sauf mention contraire, le contenu de ce wiki est placé sous la licence suivante : CC Attribution 3.0 Unported
