Balises 2012

3 septembre 2012

Cette année, nous allons utiliser des balises afin d’aider le robot dans ses choix. Les balises rempliront deux fonctions :

• Donner au robot sa position approximative sur le terrain
• Donner au robot une position approximative du robot adverse

Ces balises se basent sur celles développées et décrites par Totofweb sur son site. Ce système permet d’avoir une orientation assez fiable des balises d’émission par rapport à la balise de réception ainsi qu’une information de distance qui risque de nécessiter un certain calibrage avant d’être exploitable.

Ces balises me semblent parmi les plus simples à réaliser. Il n’y a pas de pièces tournantes, pas de mécanique de précision, pas de circuits sensibles de traitement du signal. Bref, la seule partie délicate est réalisée par les composants TSOP. De plus, ces balises sont relativement bon marché.

 Présentation du système

La balise d’émission comporte seize récepteurs. Ces récepteurs ne font que convertir le signal reçu, le microcontrôleur doit donc les lire au moment où ils reçoivent le message. Notre microcontrôleur ne peut en lire qu’un seul à la fois.

Le microcontroleur doit donc écouter chaque récepteur les uns après les autre pour voir s’il reçoit un message. Il doit les écouter au moment où la balise d’émission émet un message. Il faut donc que la balise de réception soit synchronisée avec la balise d’émission.

Afin de lire tous les récepteurs les uns après les autres, il faut que chaque balise d’émission émettre une trame de messages comportant autant de messages que la balise de réception comporte de récepteur.

Il ne faut pas que les balises d’émission se perturbent. la seconde balise doit donc attendre que la première ait fini d’émettre. L’idée est de synchroniser la deuxième balise d’émission au début du match avec la première balise d’émission que nous appellerons balise maître.

Pour chaque message envoyé, la balise de réception écoute un récepteur différent. Elle voit donc quels récepteurs reçoivent le message et lesquels ne le reçoivent pas.

À partir de ces informations, la balise de réception en déduit 2 informations :

• Sa distance approximative par rapport à la balise d’émission (en fonction du nombre de capteur qui reçoivent un signal)
• La direction de la baliwse d’émission (en fonction de la position des récepteurs qui ont reçu le signal)

Une balise est posée sur le robot adverse afin de l’identifier et d’éviter les collisions. Une autre balise est posée sur un mât fixe au bord du terrain.

Le robot connaissant sa propre orientation sur le terrain, il devrait être capable se localiser sur le terrain à partir de sa distance et de son orientation par rapport à la balise. Si l’information de distance n’est vraiment pas exploitable, nous prévoyons d’installer une deuxième balise fixe. Le robot pourra déduire sa position à partir de son orientation et de celle des balises, sans se servir de l’information de distance.

 Message émis

Afin d’éviter les perturbations, le signal est transmis par des diodes infrarouges. Le signal est modulé à 36 kHz. Le signal n’est pas un simple « bip » mais un identifiant propre à chaque balise d’émission.

Emission des trames et des messages

Chaque identifiant balise est suivi d’un blanc de durée équivalente à celle de la transmission de l’identifiant. C’est ce qui est recommandé par les commentaires du code fourni par Totofweb.

L’identifiant balise est composé de 8 bits auxquels il faut ajouter un bit de début et un bit de fin requis pour les liaisons UART. Chaque bit est composé d’au moins 10 périodes de modulation (36 kHz) [1]. Afin d’avoir le meilleur débit possible, nous nous contentons de ce minimum. On en déduit les temps suivants :

transmission d’un bit : 0,28 ms
transmission d’un identifiant balise : 2,8 ms
transmission d’une trame : 89 ms
Temps entre deux actualisations : 178 ms (2 trames) ou 267 ms (3 trames).

 Synchronisation

Une balise d’émission, désignée comme balise maître émet sa trame à intervalles réguliers. La balise de réception écoute un seul de ses récepteurs. Lorsqu’elle lit une trame complète en provenance du récepteur, elle démarre son horloge. Les autres balises d’émission sont équipées d’un unique récepteur dédié à la synchronisation. Les balises d’émission se synchronisent de la même manière que la balise de réception.

 Modification du schéma électronique

Le schéma électronique a été revu afin d’utiliser un autre microcontrôleur. Ici, nous sommes plutôt familier des PIC 18F2550 et nous n’avons pas le matériel nécessaire pour programmer des microcontrôleurs d’autres marques. Ceci nous permet de garder les mêmes outils de développement.

Nous changeons le microcontrôleur, les connecteurs de programmation ainsi que ceux de communication avec le reste du robot.

Sur la carte de réception, le schéma initial se servait de deux entrées série du microcontrôleur. Le notre n’en a qu’une, nous rajoutons un multiplexeur afin de pouvoir lire tous les signaux sur cette entrée.

Afin de synchroniser les balises d’émission, nous leur rajoutons un récepteur infrarouge.

Les récepteurs d’origine ne sont malheureusement plus disponibles dans le commerce. C’est bien dommage, ils travaillaient à une fréquence plus élevée que celles utilisées par les composants actuels. Ceci ralentira notre système, mais permettra quand même au robot d’actualiser sa position toutes les 130 ms.

Sur la carte en elle-même, nous changeons systématiquement tous les composants CMS par des composants classiques.

Voici les schéma électroniques des cartes. Le routage de la carte de réception est à refaire, les fils d’adresse des mux ne sont pas reliés au PIC.

 Carte de réception

Carte réception : Schéma (brd)
Carte réception : Typon (brd)
Carte réception : Schéma (pdf)
Carte réception : Typon (pdf)

 Carte de d’émission

Carte d’émission : Schéma (brd)
Carte d’émission : Typon (brd)
Carte d’émission : Schéma (pdf)
Carte d’émission : Typon (pdf)

 Choix des batteries

L’acquisition de nouvelles batteries ainsi que d’un nouveau chargeur est inévitable. Dans le meilleur des cas, il faut deux jeux de batterie par balise, soit quatre packs de batterie. Ça devient vite ruineux. L’utilisation de batteries LiPo, technologie ayant un bon rapport prix/performance, n’est pas envisagée. Le règlement de la prochaine coupe n’est pas encore publié et nous ne savons pas si ces batteries seront acceptées.

La solution semble d’acheter des batterie 6LR61, semblables aux piles 9 V habituelle. Le montage était conçu pour 12 V mais il devrait parfaitement s’adapter à l’utilisation d’une tension un peu plus faible. Ces batterie sont d’un coût modeste, de l’ordre de 8 € l’unité. Leur principal inconvénient réside dans leur faible capacité, de l’ordre de 200 mAh

 Consommation (un peu au pif)

Se pose alors le problème de la consommation des balises d’émission. Le schéma présente six branches de LED pouvant consommer chacune 100 mA en continu, soit une consommation de 600 mA. L’autonomie ne serait alors que de vingt minutes avec une batterie neuve et pleine.

Certes, j’ai noirci le tableau. Avec la modulation d’émission, les LEDs ne seront allumées que la moitié du temps d’émission. De plus, les batteries n’émettent pas tout le temps, mais un quart du temps dans le pire des cas, ce qui nous permet d’envisager une autonomie huit fois plus longue.

Tout dépend de comment est positionné le potentiomètre en amont du TIP122, certaines diodes acceptent de fortes surcharges temporaires et le montage permet de faire varier l’intensité entre 8 mA et 3,2 A (voir l’étude détaillée). Alors, de quoi avons-nous besoin ?

 Consommation

Notre récepteur (TSOP34836) a besoin d’un signal qui soit au minimum de 0,25 mW/m² [2]. La plus grande distance à laquelle notre robot peut se trouver d’une balise est de 4,7 m. La puissance du signal émis par les diodes est donnée en mW/sr (milliwatt par stéradian).

Le stéradian est l’unité de mesure des angles solides. 1 stéradian représente un angle solide dont l’intersection avec une sphère est une surface égal au carré du rayon de la sphère. (Voir Wikipédia)

Il nous faut donc une diode qui émette 0,25*(4,7)² = 5,5 mW/sr. Ça, ça se trouve assez facilement chez les fournisseurs de composants habituels. Les diodes IR333C, par exemple, fournissent au minimum 7,5 mW/sr lorsqu’elles sont alimentées avec 20 mA [3].

Ce qui nous fait une consommation total de l’ordre de 120 mA en cas d’émission continue, soit une autonomie de plus de treize heures en fonctionnement normal (en théorie). On valide donc le choix des batteries et des diodes.

 Programmation

 Balise de réception

Balise d’émission maître

Le code est beaucoup plus simple ici. Il n’y a pas de synchronisation à réaliser.

Nous nous servons du module de MLI pour créer la modulation de base à 36kHz et du module de communication série pour émettre l’identifiant de la balise.

 Réalisation

Une fois les cartes livrées, on en profite pour les admirer puis les souder.

Balise d’émission

Balise de réception

La soudure de la carte d’émission ne pose pas trop de problèmes. Il suffit de souder les composants à partir du centre. Pour la carte de réception les choses sont un peu plus délicates. Les broches d’adresse des multiplexeurs n’étaient pas reliées au microcontrôleur sur le schéma électronique. Il faut donc rajouter 6 fils sous la carte.

Balise d’émission soudée

Balise de réception soudée

Sur la carte de réception nous avons du corrigé plus de cinq soudures qui créaient des courts-circuits.

 Essais

Les essais ont commencés avec la carte d’émission. À l’oscilloscope, nous vérifions la présence des signaux en entrée de la porte logique. Le signal provenant du port série est bien là, par contre, rien du coté de la modulation provenant du module de MLI (PWM pour les anglophiles).
Nous utilisons le module CCP2 pour obtenir notre MLI. Ce module peut être actif sur deux broches du microcontrôleur. Soit sur la broche RC1, soit sur la broche RB3, après vérification, la modulation est bien présente sur l’autre broche. Le choix de la broche allouée à CCP2 doit être configuré par un registre qui n’est pas modifiable lors de l’exécution du programme sur le PIC. Le bootloader étant un programme, il ne lui est pas possible de modifier le registre en question. Il faut donc utiliser un vrai programmateur de PIC pour changer le registre.

Ceci réglé, nous essayons d’ajuster le potentiomètre de manière à observer une variation de tension entre la masse et les résistances de 10 Ohm. Rapidement, nous nous apercevons que la carte redémarre, la batterie s’est vidée. Un court-circuit entre la résistance de 10 Ohm et la masse a eu raison de notre batterie. Ceci corrigé, nous ajustons le potentiomètre et obtenons une réponse de la part du récepteur monté sur notre carte, la led associé clignote.

Nous testons la carte de réception sans microcontrôleur. Les leds associées aux récepteurs s’allument lorsqu’elle sont face à la carte d’émission. Lorsque les deux cartes sont côte-à-côte, toutes les leds s’allument. En éloignant la carte et en faisant tourner la carte d’émission, nous observons que certaines LED infrarouges n’émettent pas. Le court-circuit détecté précédemment les a grillées.

Les essais avec le code sur la carte de réception révèleront quelques problèmes électriques. Notamment l’entrée pour désactiver un multiplexeur n’est pas connectée.

Quelques petites erreurs dans le code ont troublé ces essais. Celle qui nous a fait perdre le plus de temps venait de la configuration des broches donnant l’adresse à écouter à l’un des multiplexeur. Ces broches étaient configurées en entrée, le récepteur écouté était alors choisi au hasard par les perturbations électriques. De quoi avoir des résultats incohérents et surprenants.

Performances

Les mesures suivantes ont été réalisées avec le potentiomètre réglé sur 32 kOhm. La distance est celle entre les centres des deux balises.

Les informations d’angle sont précises à partir de moment où les balises sont éloignées de plus de 80 cm l’une de l’autre.

Dans cette configuration, le signal de la balise est capté jusqu’à 3 mètres.

 Tests

Programmes de tests

Pour tester nos balises, nous nous servons d’une carte Arduino qui sert d’interface I2C <=> Série. Nous avons utilisé 3 programmes :

• L’un renvoyant l’état de chacun des récepteurs
• L’un renvoyant les données "angle" et "nombre de récepteur"
• Un dernier envoyant directement la position en X/Y

Le premier code nous a permis de valider le traitement, et de rajouter un filtre transformant un récepteur muet en récepteur recevant si ses deux récepteurs voisins recevaient.

Le deuxième code a pu nous confirmer que la conversion en X/Y marchait bien mais que la balise de réception ne voyait pas les balises d’émission au bon endroit.

Le troisième code est celui qui nous sert à afficher la position de la balise.

Visualisation sur PC

Une fois qu’on récupère la sortie par l’Arduino, tout se passe comme si nous lisions un port série. Chose simple sous Linux et assez pénible sous Windows. La méthode universelle consistait à se faire un programme Java en exploitant une DLL piquée dans le code de l’interface de la CMUCam.

Maintenant, nous utilisons la puissance de la ligne de commande Linux. Voici nos codes qui affichent la position de la balise à l’écran. Celui-ci stocke la dernière valeur reçue par le port série dans un fichier :

lecturebalise.sh #!/bin/bash echo "" > fichier.plot i=1; while read data ponc a1 a2 ; do   echo "$a1 $a2" > fichier.plot;   i=$(($i+1)); done < /dev/ttyUSB0
Pour l’affichage, nous nous servons de GnuPlot, un logiciel assez puissant pour tracer des graphes :

Dans la console :
gnuplot script.plot
script.plot plot "./fichier.plot" using 1:2 with circles set xrange [-5:305] set yrange [-5:205] set xtics 50 set ytics 50 set mxtics 10 set mytics 10 replot pause 1 load "./scriptplot.plot"
Et c’est tout ! Nous doutons qu’on puisse faire aussi simple, que ce soit en Java ou en Processing..

Commentaires