Balise scanner infra-rouge
En 2005, nous avions réalisé un système de balises goniométriques à laser dont l’objectif était de localiser par triangulation un mobile équipé d’un rétro-réflecteur.
Comme mentionné dans l’article en référence, ce dispositif n’a en fait pas été utilisé lors de la compétition, mais a ensuite servi de support pédagogique dans le cadre de diverses manifestations (Fête de la Science, conférences en lycée,...). Le matériel ayant mal vieilli (les lasers issus de porte-clés pointeurs supportent mal un allumage prolongé), la question s’est posée de les reconstruire.
Ceci étant, outre la partie optique, l’ensemble est relativement complexe : les têtes optiques sont mues des moteurs pas à pas, pilotés par un micro-contrôleur relié au PC qui fait le calcul de triangulation pour restitution graphique.
Or bien des choses ont été inventées depuis ces temps reculés, et une version plus simple à réaliser est possible maintenant.
Exit le laser
Le problème posé par le laser est multiple :
- nécessité de le moduler pour rendre la détection immune aux conditions lumineuses ambiantes
- utilisation d’un capteur de lumière synchronisé
- nécessité d’une optique pour intensifier la lumière renvoyée par le réflecteur
On peut faire plus simple en tirant parti de ce qui est considéré comme une calamité par bon nombre de concurrents de la Coupe de France de Robotique : les bandes réfléchissantes collées sur des éléments de jeu et/ou de terrain, qui rendent totalement inopérants les capteurs de distance infra-rouge de type SHARP GP2xxx. En effet, ces capteurs ne reçoivent pas la lumière réfléchie selon la direction habituelle d’un rayon renvoyé par une surface plane, mais au contraire selon la même direction (au sens près) que celle de la lumière émise, du fait même des propriétés d’un catadioptre. Le principe de détermination de distance utilisé par ce type de capteur étant basé sur la géométrie d’une réflexion plane, le résultat est donc totalement faux, et est en fait similaire à celui obtenu avec un obstacle très proche.
Ce défaut va pouvoir tourner à notre avantage car de ce fait, un capteur réglé pour une détection à courte distance va "voir" un réflecteur situé au-delà de la limite de son champ vision et émettre un signal de détection malgré cela. En d’autre termes il détectera les réflecteurs alors qu’il ne réagira pas aux autres objets situés dans la même zone.
Nous utiliserons donc un simple détecteur d’obstacle infra-rouge tel que celui-ci. Pour quelques euros nous avons un capteur fournissant un signal de détection tout ou rien, et dont la portée est réglable finement au moyen d’un potentiomètre multi-tours. La vérification de fonctionnement en est en outre simplifiée par la présence d’une LED de signalisation en face arrière, très pratique pour régler la sensibilité du capteur.
On peut vérifier que notre hypothèse est valide en réglant la distance de détection à une valeur très faible, et en observant qu’un rouleau d’adhésif rétro-réfléchissant (ex : bande de sécurité pour casque moto) placé plusieurs dizaines de centimètres devant le capteur provoque l’allumage de la LED, synonyme de détection effectuée.
Exit le moteur pas à pas
Les moteurs pas à pas c’est très bien, mais même avec l’aide de drivers évolués (comme le dSpin de STMicroelectronics par exemple, testé précédemment dans nos colonnes), cela reste un peu lourd à gérer.
Nos expérimentations récentes autour des servos à commande numérique de type AX12 ont montré que ceux-ci sont très simples à gérer, tout en disposant d’une précision très appréciable d’une part, mais surtout du retour d’informations de nombreux paramètres, dont la position angulaire. Plus besoin par conséquent de compter des pulses, de gérer une remise à zéro, et toutes ces tracasseries habituelles avec les moteurs habituels. Le contrôle des mouvements des têtes optiques va donc s’en trouver très simplifié, ainsi que la mesure de l’azimut de détection de la cible.
Exit les micro-contrôleurs
Maintenant que des cartes comme la Raspberry Pi existent, on peut se payer le luxe pour pas beaucoup plus cher de développer le code embarqué dans des langages plus rapides à mettre en pratique comme Python, le tout sous un Linux comme à la maison (ie sur le PC de bureau). Alors pourquoi s’en priver.
La balise scanner 2.0
Elle se compose donc d’un détecteur d’obstacle monté sur le palonnier d’un AX12 au moyen d’un bête morceau de cornière alu. L’AX12 est contrôlé par un code Python tournant sur une RasPi, équipée d’une interface USB comme l’USB2AX de Xevel, sur laquelle est relié le bus Dynamixel. Pour terminer le dispositif, le signal fourni par le détecteur est relié à la RasPI via la carte 32 I/O de ABElectronics.
Pourquoi cette carte :
- elle permet de gérer le problème posé par le niveau 5V du signal capteur
- elle fournit une pléthore d’I/O via les seuls signaux de l’I2C.
Il est vrai qu’un simple diviseur de tension résistif aurait suffit pour connecter directement le signal sur les GPIO de la RasPi, mais c’était aussi l’occasion d’en tester la mise en oeuvre.
Quelques images pour illustrer tout cela :
|
|
Et pour finir une vidéo du mode tracker simple :
I/R based target scanner demonstration from Eric PASCUAL on Vimeo.
On peut suivre la détection de la cible via l’allumage de la LED en face arrière du capteur.
Le mode de fonctionnement qui a été développé optimise un scan basique de type radar, dans lequel on parcourt systématiquement la totalité de secteur angulaire surveillé. S’il n’y a qu’une seule cible à suivre comme c’est le cas dans cette démo, il est possible d’optimiser en inversant la course dès qu’on la quitte. Cela se traduit par un mouvement de balayage de petite envergure, dont le débattement correspond à sa taille angulaire vue du capteur.
Accessoirement, si on connait la taille de la cible, cet angle donne également une indication de distance, grâce à l’aide de M. Thales (le mathématicien-géomètre, pas le fabriquant d’électronique ;).
Amélioration du dispositif
Le fonctionnement oscillatoire du suivi peut être supprimé par un suivi à l’aide de deux capteurs jumeaux. Cette disposition donne l’indication de la direction dans laquelle la cible a été perdue, et la stratégie est donc de :
- rester en place tant que les deux capteurs ont une réponse
- pivoter dans la direction opposé du capteur qui perd la détection.
En fait, ce n’est ni plus ni moins que la logique utilisée pour un suivi de ligne au sol à l’aide de deux capteurs.
Cette nouvelle version est illustrée par les photos suivantes, ainsi que par la vidéo de son fonctionnement.
|
Au passage, nous avons fait appel ici à certaines des multiples possibilités de réglage des servos AX12, de manière à optimiser leur comportement selon que le dispositif est en phase de balayage ou en phase de tracking de la cible. Nous ne les détaillons pas ici pour ne pas nous disperser sur plusieurs sujets, mais tout cela sera exposé dans un futur article.
La configuration à deux capteurs semble être supérieure à celle à un seul capteur [1]. C’est exact au niveau de la rapidité du suivi car le fait de disposer directement de l’information de la direction dans laquelle la cible a été perdue permet de la retrouver très rapidement. Par contre le mode de suivi utilisé alors (sans balayage) nous fait perdre l’information de taille angulaire de la cible, et donc de la position de son centre. La conséquence en est que le pointage résultant ne sera pas au centre de la cible, et que l’erreur commise va croître avec la largeur angulaire de la cible. Nous allons donc dans tous les cas perdre en précision lorsque nous allons nous en rapprocher.
Que choisir ?
En fait, tout dépend de l’objectif recherché.
- si on cherche à localiser le plus précisément possible une cible, le balayage permanent est nécessaire afin d’en localiser le centre correctement quelle qu’en soit la taille. Par conséquent la configuration à double capteur ne nous apporte rien, et la solution mono-capteur lui est même préférable
- si on recherche par contre la rapidité du suivi de la direction approximative de la cible (par exemple dans le cas où il s’agit d’un réflecteur équipant un robot plus volumineux), la solution à double capteur est meilleure car elle fournit directement la direction de fuite de la cible
Les limites de ces capteurs
Une première limitation est la topologie particulière du lobe de détection du capteur. En effet il ne s’agit pas d’un cône symétrique, mais d’un cône très écrasé (à base fortement elliptique), formant une sorte de pinceau. En mode détection d’obstacle, ce pinceau est orienté horizontalement pour fournir un angle de vue latéral élargi, et ici nous l’orientons verticalement, car on cherche au contraire à réduire l’ouverture horizontale afin de gagner en précision d’azimut.
Rien de tout cela n’est vraiment gênant, si ce n’est que l’axe principal du lobe n’est pas celui du capteur comme on aurait pu s’y attendre. Il y a fort à parier que le positionnement des éléments actifs derrière les lentilles frontales est approximatif et provoque cette altération de direction. Reste à voir si la même orientation est observée sur tous les capteurs, ou si c’est selon chacun.
L’autre problème est la portée, beaucoup plus faible qu’avec un laser du fait de la dispersion du faisceau des LEDs servant de sources.
Conclusion
Malgré les défauts et limites constatés, cette version de tracker optique est intéressante par sa simplicité de réalisation et de mise en oeuvre. Elle est de plus suffisante si la portée requise n’est pas très grande. En tout cas, pour un démonstrateur pédagogique, c’est amplement suffisant, d’autant que la mise en oeuvre de deux balises de ce type est simplifiée par le fait de la connexion par bus des AX12.
Codes sources
Ils sont sur notre GitHub.
Vos commentaires
# Le 28 décembre 2013 à 12:28, par cho En réponse à : Balises goniométriques 2013 (1ère partie)
Effectivement, j’avais compris que les balises étaient sur le robot lui-même et non sur les supports sur la table.
Dans ce cas, il n’y a plus de problème, à part ajouter une communication sans fil avec le robot principal.
Cho.
# Le 8 janvier 2014 à 22:57, par Eric P. En réponse à : Balises goniométriques 2013 (1ère partie)
>>
à part ajouter une communication sans fil avec le robot principal
<<
Tout à fait. Et ce n’est pas bien différent de la communication avec le PC utilisée par le démonstrateur.
Répondre à ce message
# Le 12 décembre 2013 à 22:24, par cho En réponse à : Balises goniométriques 2013 (1ère partie)
Merci pour la confirmation.
En plus, il n’est pas simple de placer 2 systèmes sous le mat de balise, pour trianguler. Du coup il faudrait mettre le système plus bas au 35cm (hauteur max du robot) pour mettre les 2 systèmes de chaque côté du robot. Mais on aura des angles morts.
Bref pas simple de trouver un système fiable avec peu de moyen...Je continue de chercher pour trouver une solution pour ajouter la distance.
Cho.
# Le 12 décembre 2013 à 23:58, par Eric P. En réponse à : Balises goniométriques 2013 (1ère partie)
Je ne suis pas certain de comprendre quand tu dis : placer 2 systèmes sous le mat de balise.
Les balises sont placées sur les supports des angles de la table, et le réflecteur est sur le robot. Il n’y a aucun problème pour les faire rentrer dans le volume maxi autorisé.
C’est d’ailleurs expliqué dans l’article sur le système original fait en 2005.
Répondre à ce message
# Le 12 août 2013 à 20:19, par Alban M. En réponse à : Balises goniométriques à base de détecteurs d’obstacle à infra-rouge
Astucieux les capteurs jumelés ...Est ce qu’en les mettant sur un support legerement convexe et en rajoutant un 3eme capteur(au centre) on pourrait gagner en precision de detection ?
En mettant ce systeme sur un robot qui se deplace comment ferait le robot pour ne pas heurter cette balise ?....Faudrait il ajouter un capteur style gp12 qui calcule la distance ?
En tout cas Tres bonne presentation ....il me reste a me renseigner sur les AX 12 ....
# Le 12 août 2013 à 23:18, par Eric P. En réponse à : Balises goniométriques à base de détecteurs d’obstacle à infra-rouge
Pas vraiment, car le défaut de principe de tracking utilisé est qu’on ne connait pas la taille angulaire de la cible (puisqu’on ne la balaye plus) et donc qu’on n’est jamais assuré de pointer sur son centre.
On peut avoir une estimation de distance par triangulation avec deux balises de ce type (pouvant être disposées de part et d’autre du robot). Ce sera là également à l’erreur causée par le fait de ne pas tenir compte de la largeur angulaire de la cible.
Le dispositif doit être embarqué sur un Create (Romba modifié pour l’enseignement), pour localiser des objets à saisir. Il est prévu de tester si l’indication de distance fournie peut suffir pour gérer le bras manipulateur chargé de la capture.
La stratégie envisagée pour essayer de concilier les avantages des deux types de balises est de continuer à balayer la cible avec le modèle à deux capteurs.
# Le 12 décembre 2013 à 01:17, par cho En réponse à : Balises goniométriques à base de détecteurs d’obstacle à infra-rouge
Bonjour,
J’aime bien votre système, et il reste très simple. Je suis preneur pour le code source, si ca peut nous faire gagner un peu de temps étant donné que notre équipe n’est pas très nombreuse ;)
Je reviens sur le fait de connaitre la distance, afin de ne pas mettre 2 systèmes, et de rester sous le support de balise. Si l’on utilise de l’US (module standard), il sera potentiellement brouillé par la balise de certaine équipes (emission 360°), si on utilise un GP2 avec détection de 1,5m pour détecter la distance avec le catadioptre lorsque votre système a détecté, est-ce le GP2 interférerait avec ce système ?
# Le 12 décembre 2013 à 11:33, par Eric P. En réponse à : Balises goniométriques à base de détecteurs d’obstacle à infra-rouge
Bonjour,
(Je suis obligé de répondre en plusieurs parties, du fait des limitations de système de commentaire :/)
Je déconseille l’usage des U/S pour une mesure de distance précise pour plusieurs raisons :
– la perturbation par le bruit ambiant : le public qui trépigne sur les gradins métalliques génère des hautes fréquences à un niveau très élevé (j’utilisais des atténuateurs pour me protéger les oreilles les années où j’ai fait partie de l’équipe d’arbitrage) qui perturbent facilement les dispositifs U/S
– l’incidence de la température, qui dans la salle Olympe peut varier dans une amplitude d’environ 20 degrés en fonction de la météo du jour, de l’heure de la journée et du taux de remplissage de la salle
– la précision de mesure très dépendante de la géométrie de la cible : un cylindre par exemple va renvoyer peu d’énergie et la mesure sera donc assez aléatoire
(à suivre)
# Le 12 décembre 2013 à 11:36, par Eric P. En réponse à : Balises goniométriques à base de détecteurs d’obstacle à infra-rouge
(suite)
Pour en revenir à notre système, pour obtenir un repérage précis de la position il faut remplacer les dispositifs I/R par des lasers, comme nous l’avions fait sur le modèle original en 2005. La raison en est double :
– taille et forme imprécise du lobe de détection des capteurs I/R
– portée bcp plus faible. Pour info, les balises McGyver 2005 détectaient une bande réfléchissante de type gilet de sécurité à plus de 7m. Une catadioptre tel que ceux utilisés pour la coupe était détecté à plus de 15 mètres
Quant à l’utilisation des GPxx pour cela, il faut l’oublier également. Le principe de la mesure de distance faite par ces capteurs et de repérer où le rayon retour vient frapper un détecteur multi-sites linéaire. Le rayon incident ne part pas selon la normale du capteur mais en biais (il suffit de les regarder de près ou d’en autopsier un pour le vérifier). Quelques calculs élémentaires basés sur la géométrie du triangle font le reste. Le pb avec un réflecteur catadioptrique est que le rayon réfléchi repart dans la même direction que le rayon incident, et non selon une direction symétrique à la normale comme dans le cas d’une surface réfléchissante. Cela invalide le principe même de fonctionnement des GPxx, et du coup un catadioptre génèrera une mesure identique à celle d’un obstacle très proche, et ce quelle que soit la distance à laquelle il se trouve.
(à suivre)
# Le 12 décembre 2013 à 11:37, par Eric P. En réponse à : Balises goniométriques à base de détecteurs d’obstacle à infra-rouge
(suite et fin)
Concernant la question sur la perturbation par les émissions du GPxx du capteur I/R utilisé, la réponse est oui. Ce capteur n’est pas du tout modulé (à l’inverse des GPxx) et il recevra donc les I/R émis pas le GP. D’ailleurs les capteurs se perturbent mutuellement si on ne fait pas attention à leur disposition. Mais comme de toute façon il ne sont pas adaptés à une application nécessitant la précision dont vous avez besoin, la question ne se pose plus.
Comme j’ai dû le dire quelque part dans l’article (ou un autre sur le même projet), j’ai utilisé ces capteurs pour leur plus grande facilité de mise en oeuvre par rapport à refaire un système optique analogue au modèle original, et parce que leurs défauts n’avaient pas d’incidence préjudiciable à l’objectif du démonstrateur qui les utilise.
Voilà, j’espère avoir répondu aux questions.
Quant au code source, il est sur notre GitHub.
Cordialement
Eric
Répondre à ce message