Poivron

News Présentation

Nos Articles

Balises 2012 Vision 2011 Vision 2010 Nos études Raspberry Pi Odométrie Portail des équipes

Nos Robots

Robot 2023 Robot 2022 Robot 2015 Robot 2014 Robot 2012 Robot 2011 Robot 2010

Thèmes

2010 2011 2012 2014

Ressources

Liens Contact

Sommaire

HEXA - Une expérience holonome

23 juillet 2023

HEXA, pour Holonome Experience Xylo Asservi.

Holonome Experience Xylo Asservi (HEXA)

 Contexte

A l’origine, ce robot est une sorte de défi. Pour se remettre dans le contexte, nous avions de nombreuses participations à la coupe de France de robotique derrière nous. L’année précédente, après 6 ans sans participation, nous partions sur un robot simple, grandement repris des années précédentes, visant les actions faciles.

A notre grande surprise, nous atteignions la 10e place.

Nos particularités : un robot intégralement construit avec des baguettes de bois carrées, une carte électronique qui avait déjà servi sur des anciens robots participants à la Coupe et une base roulante avec 2 roues motrices et une bille folle.

Cette année, nous voulions changer plusieurs choses. Tout d’abord, nous voulions un robot holonome, à trois roues. 3 roues, 3 moteurs, 3 codeurs, nous devions alors remplacer notre carte électronique, non adaptée, et les microcontrôleurs PICs nous avaient montrés ce qu’ils avaient dans le ventre. Monter en gamme dans la même marque ne nous tentait pas, et le Raspberry Pi Pico, le microcontrôleur de la fondation Raspberry Pi nous faisait de l’œil. Nous voici partis sur une nouvelle architecture électronique.

L’an dernier, un peu avant la compétition, nous avons fait l’acquisition d’une scie à chantourner. Celle-ci nous permettra une plus grande liberté dans la conception mécanique de notre robot, les baguettes en bois ayant, parfois, quelques limites.

Au niveau des actions, nous voulions un minimum de spectacle. Nous choisissons d’aspirer les petites balles en mousse qui se trouvent sur le bord du terrain et de les lancer, idéalement, tout ça avec une seule turbine !

Pouvons-nous dire que nous sommes partis de zéro pour concevoir ce robot ? Non, voici ce que nous gardons :

  • la localisation avec roues codeurs montées sur les moteurs et un gyroscope,
  • l’utilisation exclusive de microcontrôleurs,
  • la communication I2C entre nos microcontrôleurs.

 Les résultats

Sommes-nous satisfaits des résultats obtenus ? Jamais, ou rarement en tout cas. Pour H.E.X.A. un manque de fiabilité, malgré nos nombreux tests, nous rendra frileux et nous forcera à adopter des stratégies très prudentes. Surtout, nous travaillerons sur la résolution de ce souci plutôt que de tenter des stratégies plus ambitieuses.

Cela n’empêchera pas H.E.X.A de se hisser à la 8e place du classement général.

Si ce classement est au-delà de nos espérances, le spectacle offert par notre robot nous a un peu déçus...

Par contre, nous sommes satisfaits de la réalisation technique, en un an, d’étudier un robot holonome, de le réaliser et de l’asservir honnêtement et proprement. Voici en détail les principales étapes qui nous ont permis de le réaliser. Mais avant, le voici à l’œuvre !

 En match

Notre meilleur match est sans aucun doute celui de la 5ᵉ série, le voici :


Match 5 (480p - 14 Mo | 720p - 30 Mo).

 La localisation - théorie

Fin août, nous prenons une feuille et un crayon pour comprendre comment le robot peut, à partir des informations des codeurs montés sur les roues, connaître sa position. Dans cette partie, nous ne tenons pas compte du gyroscope (ce qui aurait grandement simplifié le problème).

Il nous faut deux semaines pour comprendre que l’outil adéquat est le tenseur cinématique associé avec la loi du transport des moments. Nous sortons des équations assez indigestes qui se simplifient énormément une fois pris en compte que :

  • Les trois roues sont à égale distance du centre du robot
  • Les angles entre les roues sont de 120°

Nommage des angles

Nous publions nos résultats sur le site, localisation d’un robot holonome (partie 1 et partie 2).

 La stratégie

Mi-septembre, le brouillon du règlement est publié. Nous dévoilons notre stratégie à deux robots.

Le robot des gâteaux sera imaginé et ré-imaginé, en fonction du temps qu’il nous restait pour ne rester qu’une chimère.

Par contre, toutes les tâches du robot des cerises seront réalisées (et même plus !).

Grâce à cette stratégie, nous identifions nos principaux capteurs et actionneurs et pouvons commencer à travailler sur notre carte électronique

 La base roulante

Nous voulons une base roulante tôt dans l’année, car c’est la clé pour avoir un robot qui fait du spectacle.

Mi-octobre, nous avons d’un côté la carte prête à être soudée, de l’autre, les moteurs montés avec les roues sur le châssis provisoire du robot.


Base roulante holonome

Carte Holonome 2023 nue

Malgré cela, il faudra attendre mi-novembre pour faire tourner une roue.

Et une roue qui tourne, ce n’est pas un robot qui se dirige. Codeurs, qui permettent de mesurer précisément les mouvements des moteurs ne seront montés que fin novembre.

Nous en profitons pour réaliser la première boucle d’asservissement : le contrôle en vitesse des moteurs. Cet asservissement marche vraiment bien et permet de faire des trajectoires relativement précises, telles que se déplacer suivant un rectangle :

Le code pour arriver à ce résultat est de l’ordre de 400 lignes. C’est peu !


Asservissement des moteurs

Une fois les codeurs montés, il s’agit de coder, tester, coder, tester et recommencer.

Nous intégrons ensuite les données du gyroscope dans la localisation du robot. Puis nous commençons à travailler sur le concept de trajectoire et de trajet.

Pour nous, une trajectoire est l’ensemble des positions que le centre du robot va occuper au cours du temps. Il s’agit de droites, d’arcs de cercle ou de courbes de Bézier.

Un trajet est le parcours d’une trajectoire en tenant compte de la vitesse que doit avoir le robot. Le trajet tient compte de :

  • la distance avant la fin de la trajectoire (pour freiner le robot)
  • la vitesse actuelle du robot (pour le faire freiner ou décélérer en douceur)
  • l’accélération maximale du robot pour le trajet
  • la vitesse maximale du robot pour le trajet

Découper ces deux concepts nous ont permis de vraiment faire des mouvements sympathiques en gardant un code clair.


Architecture logicielle des déplacements

Voici un exemple d’une translation circulaire avec accélération et décélération


Trajectroire circulaire avec accélération contrôlée (720p - 3,3 Mo).

 La détection de l’adversaire

Maintenant que le robot bouge, il faut qu’il s’arrête avant de rentrer dans le robot adverse.

La détection de l’adversaire est un sujet difficile pour deux raisons :

  1. L’adversaire n’a pas forcément la forme qu’on s’imagine
  2. Une partie des capteurs sont perturbés par l’environnement de la compétition

Sur les robots précédents, nous utilisions des capteurs à ultrason. Nous avions éprouvé cette solution et connaissions ses limites. Le temps de lecture d’un capteur est relativement long et nous avions cru comprendre que plusieurs capteurs pouvaient se perturber mutuellement. Ce n’est pas gênant avec deux capteurs qui mesurent alternativement. Mais avec le robot holonome, nous avions besoin de détecter tout autour du robot.

C’est donc en nous servant des retours et des conseils des autres équipes que nous partons sur les capteurs VL53L1X de STMicroelectronics pour détecter soit une balise que nous poserions sur l’adversaire, soit l’adversaire lui-même.

Sachant à quel point il peut être compliqué de différencier un problème de logique d’un problème de détection, nous associons à chaque capteur une DEL multicolore qui indique la distance vue par le capteur. Ainsi, un simple coup d’œil nous dit quel capteur détecte un obstacle.

Évidemment, qui dit DEL multicolore, dit arc-en-ciel !

Les capteurs ne nous ont pas déçus ! Nous les avons trouvés précis et fiables. Leur seul point noir est qu’ils partagent tous la même adresse I2C au démarrage et qu’ils sont amnésiques : dès qu’ils sont désactivés, ils perdent leur configuration...

 L’évitement

C’est vraiment la partie sur laquelle nous n’avons pas pu travailler sérieusement cette année. Pour être précis, la partie que nous n’avons pas pu intégrer. Car nous avions commencé à travailler l’évitement que sur le mois de la Coupe.

Nous envisagions plusieurs niveaux d’évitement :

  1. Le robot s’arrête, s’il détecte un obstacle, repart si l’obstacle disparaît.
  2. Le robot s’arrête et repart en sens inverse sur la même trajectoire.
  3. Le robot s’arrête et repart vers une autre cible
  4. Le robot contourne l’obstacle

Les trois premiers niveaux décrits ci-dessus étaient fonctionnels. Nous avions une idée assez précise de comment nous y prendre pour contourner l’obstacle mais faute de temps, nous ne l’avons pas implémenté.

 La programmation

La programmation de ce robot sera pour nous l’occasion de découvrir le microcontrôleur Rapsberry Pi Pico. Nous publions 4 articles, qui sont nos aide-mémoires, sur le développement pour ce microcontrôleur :

Nous publions également un fichier Readme avec notre dépôt de code qui détaille la structure du code.

Enfin, nous avons un article dédié au calcul de la consigne de vitesse du robot : Consigne de vitesse.

Globalement, la programmation a bien représenté 75% du travail sur ce robot...

 Les capteurs et actionneurs

 L’aspiration

Pour marquer des points, nous avions décidé d’aspirer et de lancer les balles (appelées cerises dans le règlement). Pendant plusieurs mois, nous avons cherché une conception de trompe qui permettrait d’aspirer les balles et les faire sortir du flux d’air sans arrêter la turbine. Après de nombreux échecs, nous nous sommes rabattus sur une trompe reliée à une chambre mise en dépression par une turbine.


Système d’aspiration des cerises

Aspiration cerises : démontée

La chambre de stockage est faite en medium et la trompe avec un tube de carton et une buse en papier mâché.

Prototype pour l’aspiration

La chambre, en aval, est fermée par une porte. Cette porte permet aussi au robot de "doser" les balles qui sortent.

 La rampe

En sortie de cette chambre, les balles sont guidées par une rampe faite en fil de fer soudé à l’étain. La réalisation a été non-conventionnelle mais pas particulièrement longue. Nous avons d’abord fixé deux grands morceaux de fil de fer sur le robot à l’aide de pâte-à-fixe ; qui a permis d’ajuster leur position. Ensuite, à l’aide de la troisième main, nous soudons les renforts.


Rampe pour les balles

Rampe montée
Cerises sur la rampe

 Le propulseur

Enfin, les balles sont éjectées par le propulseur : un ensemble de deux moteurs avec des petites roues et un guide imprimé en 3D. Théoriquement c’est beau ! Mais en pratique, les moteurs du propulseur ne sont pas très puissants et perdent beaucoup d’inertie à chaque envoi de balle. C’est pour cela que nous avions travaillé sur la porte doseuse. L’ensemble a bien fonctionné avec un taux de réussite d’envoi des balles en match de 100% ! Son inconvénient, c’est qu’avec le dosage des balles, il fallait près d’une seconde par balle, soit 26 secondes juste pour l’envoi des balles lors de notre 5ᵉ match (et nous avions l’ambition d’envoyer bien plus de balles...).


Moteurs du propulseur

Et la modélisation 3D du guide qui expédie les balles avec le bon angle :


Modélisation propulseur

Propulseur monté

 Le bras

Bricolé pendant la dernière nuit de la coupe de France de robotique, nous installons un bras qui nous permet de pousser 2 "gâteaux" sur une de nos assiettes. Ce petit accessoire, composé d’un servomoteur et d’une baguette de bois, nous rapportera 6 points lors du dernier match.

 Les contacteurs

Pour faire fonctionner tout ça, quasiment aucun capteur. Les seuls présents sont les contacteurs qui permettent au robot de détecter ou de longer une bordure ou de recaler la position du robot.


Contacteurs pour longer les murs
Recalage du robot

 L’affichage du score

Pour l’affichage du score, nous repartons comme l’an dernier sur un écran e-ink (ou écran à encre électronique).

Cette technologie présente deux avantages :

  • L’écran est très lisible
  • L’écran affiche une image même non-alimenté

L’an dernier, nous nous servions d’un ordinateur pour piloter cet écran à l’aide des scripts d’exemple en Python. Mais cette année, nous voulons nous passer de l’ordinateur. Nous essayons les codes de démo avec succès. Là où les choses se corsent, c’est qu’il n’y a pas de fonction de démo fournie pour charger une image partielle. Or nos beaux caractères d’affichage du score sont justement des images.

Il faut alors développer en parallèle :

  • la fonction pour charger une image
  • un système pour convertir une image bitmap en données binaires

Et quand le résultat n’est pas celui attendu, difficile de savoir d’où vient le problème.

Nous nous arrêtons dès que nous arrivons à afficher une image en noir et blanc. L’écran supporte 2 nuances de gris supplémentaires que nous ne prendrons pas en charge.


Affichage de 22 points !

 Le déguisement

Le déguisement n’est venu compléter le robot que dans les dernières semaines avant la coupe. Le but était de transformer notre robot en aubergine (cf le nom de notre équipe).

Un système de fils relié à un servomoteur pour faire dérouler les tissus.


Actionneur du déguisement

Déguisement déplié


Prototype déguisement (1080p - 2 Mo).

 Journal de développement

Commentaires

Il n'y a pas de commentaires

Ajouter un commentaire

Pseudo :
Mail :

Texte :

Copyright "POIVRON" 2011-2023, tous droits réservés
Administration du site