Balises goniométriques 2013 (1ère partie)

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 :

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.

A suivre...