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

Commentaires

• Suivez les commentaires de cet article par flux RSS

Ajouter un commentaire