Détection de l’adversaire et affichage du score

25 avril 2023

 Après le retour de la CARAR 2023

La CARAR nous avait laissé un petit goût amer. Nous avions perdu du temps sur la gestion de la tirette, la détection de l’adversaire était dans sa forme la plus primitive et nous avions pris en défaut notre précieuse carte de détection. Et après tout ce temps passé sur le robot, l’un des membres souhaitait faire une petite pause. S’en suivi donc une semaine qui fut plutôt passée sur le panier que sur le robot...

Ensuite, il fallait savoir si la carte de détection pouvait poser problème... Au bout de deux séances d’essais, et la correction d’un bug potentiel, il fallut nous rendre à l’évidence. Dans certaines conditions, certes assez précises, un capteur VL53L1X peut détecter un obstacle à 35 cm alors qu’il n’y a rien à moins de 2 mètres devant lui. C’est quelque chose que nous avons pu reproduire, mais uniquement dans certains lieux.

C’est assez embêtant, mais en penchant les capteurs vers le bas, on devrait pouvoir contourner le problème, au moins partiellement...

 Détection de l’adversaire

Nous avons accepté ce défaut, pour continuer de travailler sur la détection de l’adversaire. Le code utilisé lors de la CARAR stoppe net le robot dès qu’un objet est détecté à proximité. D’un côté, le robot risquait de basculer, de l’autre, une fois au contact d’un obstacle, il n’est pas possible de repartir.

Nous avons dessiné des cônes de détection où nous souhaitons prendre en compte la présence d’un obstacle en fonction de la direction d’avancement du robot.

Zone de détection Zones de détection en fonction de la direction d’avancement du robot.

Chaque zone de détection d’un capteur est comparée avec le cône. Si les deux zones ne s’intersectent pas, le capteur est ignoré.

Selection des capteurs

Pour vérifier le bon fonctionnement du code, nous créons une fonction permettant d’éteindre les LEDs associées aux capteurs de la carte de détection. Ces indications nous seront précieuses pour le débogage du code.

Les LEDs, qui en s’éteignant, aident au debug.

 Intégration avec les fonctions Trajets

Les fonctions Trajets nous permettent de suivre une trajectoire avec un contrôle fin de l’accélération et de la décélération. Une trajectoire peut être une droite, un arc de cercle ou une courbe de Bézier. La solution que nous avons trouvée pour coupler élégamment la détection avec les fonctions Trajets a été de tout piloter au niveau de la stratégie. Le principe est le suivant : la fonction Stratégie appelle successivement :

• Trajet_get_orientation_avance() : qui renvoie la direction dans laquelle avance le robot.
• Balise_VL53L1X_get_distance obstacle_mm(angle) : qui renvoie l’obstacle le plus proche en tenant compte de la direction d’avancement du robot.
• Trajet_set_obstacle_mm (distance_obstacle) : qui définit la distance pour laquelle la fonction Trajet_avance() calculera la courbe de décélération liée à cette distance lors du calcul de la consigne de vitesse.

De cette manière l’impact sur les fonctions Trajets est minime et le résultat est fonctionnel.

 Affichage du score

Comme l’an dernier, nous utilisons un écran E-Ink pour afficher le score. Cette année, il est plus grand et nous souhaitons le piloter directement avec les microcontrôleurs Raspberry Pi Pico. S’il ne nous a pas fallu très longtemps pour afficher le test sur l’écran, charger des images s’est avéré bien plus compliqué.

Le code proposé n’est fait que pour charger des images faisant exactement la taille de l’écran. Le seul format pris en charge étant celui - non standard, mais compréhensible - du programme, un format binaire brut. Notre image étant bicolore, chaque octet code 8 pixels. Nous avons réutilisé des bouts de code du vendeur (Waveshare) en C fournis pour Linux pour convertir nos images sur le PC avant de copier les données dans le code en C. Un printf bien placé aurait fait l’affaire, mais nous avons voulu être intelligents et nous avons perdu beaucoup de temps...

Le processus était même plus complexe :

• Création de l’image dans Inkscape (ça, c’est facile), export en PNG
• Import de l’image dans GIMP, conversion de l’image en couleur indexée, 2 couleurs. Enregistrement en BMP.
• Utilisation de notre programme pour obtenir les valeurs en C
• Insertion des données dans le code C.

Mais à la fin, nous avons ce que nous voulions : un écran lisible de loin !

Intégration de l’écran

Affichage de 22 points !

 Avancement

• Améliorer la détection de l’adversaire
  • Tester la perturbation par un capteur en face : Fait
  • Éliminer les obstacles hors du terrain : Fait
• Supervision
  • Mesurer la tension de la batterie et détecter une batterie faible
  • Être capable de récupérer des "logs" en fin de match
• Stratégie
  • Intégrer la détection de l’adversaire dans la stratégie :
    • Code fait et globalement fonctionnel : A valider
  • Enchaîner sur la prise des cerises proches du panier
  • Enchaîner sur la prise des cerises au milieu de la grande bordure.
  • Stratégies d’évitement à implémenter
• Fiabiliser la dépose des cerises : bien avancé, mais ce sera pour un autre article
• Écran :
  • Coder l’affichage du score : Fait !
  • passer la liaison SPI de 100 kHz à 4 MHz comme dans l’exemple

0 commentaire

Le robot se structure + détection de l’adversaire

15 janvier 2023

À force de faire des essais et de laisser traîner la carte sur le bureau, une patte de résistance qui traînait a arqué et ça nous a motivé à faire un support propre pour la carte électronique.

Support carte électronique

Support carte électronique

Nous avons profité de l’arrivée d’un jeune nouveau membre pour commencer la carte de détection de l’adversaire. Si tout se passe comme prévu, nous utiliserons des capteurs VL53L1X :

• Côté électronique, nous sommes proches d’avoir fini le schéma
• Côté programmation, nous arrivons à lire un capteur, notre code est sur github.

Enfin, nous avons fini notre article sur les astuces pour utiliser VS Code pour le Raspberry Pi Pico.

Du côté de nos tâches :

• Écrire notre mémo sur l’utilisation de VSCode avec le Raspberry Pi Pico : Fini à l’instant.
• Finaliser le code i2c non bloquant : Fait !
• Reprendre les tests avec la turbine
  • Aspiration : nous avons enfin un prototype concluant
  • Soufflage : les premiers essais donnent une bonne piste pour le prototype
• Placer des contacteurs sur le robot pour détecter les bordures
• Longer les bordures
• Transformer la base roulante en robot :
  • Fixer la carte électronique : Fait !
  • Installer le mat balise
  • Intégrer la turbine : conception ok
• Améliorer la détection de l’adversaire
  • Électronique : schéma à 90%
  • Programmation : lecture du capteur ok

0 commentaire

Raspberry Pi Pico : de la documentation !

1er janvier 2023

Bonne année à vous tous, chères lectrices, chers lecteurs !

Quoi de neuf depuis le 11 décembre de l’an dernier ?

Globalement, pas grand chose sur le robot.

Nous avons séparé le code de test du fichier principal.

Nous avons commencé les travaux sur l’I2C et perdu beaucoup de temps car notre puce TCA9535 ne répond pas. Nous avons vérifier les connexions électriques, vérifié les tensions, changé la puce, rien n’y fait. La seconde puce est-elle grillée ? La carte était-elle mal conçue ? Pour l’instant, nous ne le savons pas !

Du coup, nous nous sommes rabattus sur le 2e Raspberry Pi Pico pour travailler l’I2C. Ça a été l’occasion de mettre au propre nos notes sur la création d’un projet pour le Raspberry Pi Pico :

• Où trouver la documentation
• Installer l’environnement de développement (sur Debian)
• Créer son projet

Et de découvrir cette librairie pico_i2c_slave qui fait exactement ce que nous voulions côté esclave.

Enfin, nous avons recommencé nos moulages en papier mâché, pour l’aspiration des balles.

Lors de notre dernière news, nous avons présenté des courbes avec des accélérations et des décélérations. C’est le résultat d’un article écrit en septembre dernier que vous trouverez ici.

La suite :

• Ecrire notre mémo sur l’utilisation de VSCode avec le Raspberry Pi Pico
• Finaliser le code i2c non bloquant
• Reprendre les tests avec la turbine
• Placer des contacteurs sur le robot pour détecter les bordures
• Longer les bordures
• Transformer la base roulante en robot :
  • Fixer la carte électronique
  • Installer le mat balise
  • Intégrer la turbine
• Améliorer la détection de l’adversaire

0 commentaire

Avancées logicielles - Le déplacement avance !

11 décembre 2022

Par rapport à nos nouvelles du 2 décembre 2022, nous avons bien avancé sur la programmation des déplacements ! À ce niveau, le dernier point encore non maîtrisé est l’utilisation du gyroscope pour se positionner.

Nous avons publié notre code sur Github avec un Readme qui explique la structure du code.

Architecture logicielle des déplacements

Pour l’instant, nous n’avons pas de belle vidéo à présenter, mais ça ne saurait tarder... Pour patienter, un test "en boucle ouverte", seuls les moteurs sont asservis en vitesse, il n’y a pas de retour sur la position du robot !

Et voici les courbes obtenues lors des essais de contrôle en vitesse avec une accélération et une décélération - ce sont bien des courbes expérimentales :

Le code supporte les trajectoires droites, circulaires ou suivant les courbes de Bézier.

Donc nous sommes - presque - prêts à nous déplacer avec classe et précision !

0 commentaire

Avancement début décembre 2021

6 décembre 2021

Quoi de neuf après ce week-end ?

Principalement les capteurs infrarouge. Comme capteurs de détection de l’opposant, nous utilisons des SFR04, un devant, un derrière, qui nous ont fidèlement servis durant des années.

Cette année, nous allons vouloir longer la bordure et nous savons que notre odométrie n’est pas précise au millimètre après plusieurs déplacements. Nous installons donc des capteurs Sharp de type GP2Y0A41Y2 sur les côtés de notre robot.

Capteur IR à côté de la roue

Après avoir testé les capteurs sur notre petite carte de développement, nous rallongeons les câbles et les raccordons sur la carte du robot.

Nous adaptons le code de la carte pour renvoyer les valeurs des capteurs infrarouge à l’interface de supervision puis adaptons le code de l’interface de supervision.

Ça marche bien... pour le capteur branché en IR_1. IR_2 refuse de donner des valeurs cohérentes. Les mesures de tension sont 10 fois plus faibles qu’attendues. Est-ce que la broche du PIC est grillée ?

Non ! Après une heure de recherche, il s’avère que le problème était logiciel. Le code des servomoteurs tentait de piloter un servomoteur branché sur IR_2. Ceci car nous avions eu un soucis avec U3, le régulateur de tension 7805 des servomoteurs 1, 2 et 3. Nous avions réaffecté IR_2 (dont nous ne nous servions pas) à Servo3. Le prix à payer pour réutiliser une carte et un code vieux de 5 ans...

(Pour visualiser ça, utilisez le plan interactif de notre carte.)

Après réaffectation des broches comme initialement prévu, les valeurs retournées sont parfaitement cohérentes.

Un dernier doute m’habite, ces capteurs ne riquent-ils pas d’être aveuglés par l’éclairage de la Coupe ?

0 commentaire