wix

Quelques mots sur nos méthodes d'implémentation et mise au point. 

Un robot de ce type (même pour un PAMI) c'est un concentré de technologies, de métiers et de périphériques. On est en pratique peu des les équipes pour gérer beaucoup de choses. Pour éviter que tout nous pète à la figure nous construisons la maison progressivement par le bas en assurant la solidité des bases avant de passer aux étages supérieurs. Ca peut paraitre trivial mais face un un planning contraint c'est pas toujours aussi facile de se donner le temps de bien construire. Prendre des raccourcis et ne pas traiter les problèmes c'est se constituer une dette technique et comme toute dette il faudra la payer, et Murphy oblige, ce sera à la coupe. Ca devient très difficile de débugger un système de cette complexité si on ne fait confiance à rien. 

La présentation est séquentielle par étapes arbitraires pour le besoin de l'explication la vraie vie est plus entremêlée que ça, si ça marche on laisse glisser, si c'est le bordel on revient sur un truc un peu bête et méchant bottom up. Dans une année Eurobot y'a en gros 7 mois, on passe 1 mois en brainstorming, création/commande de table/élément de jeu, 3 mois simu et designs, 1 mois breadboard, 1 mois intégration et 1 mois sur le robot. C'est déjà très court parce que si un truc merde, l'itération est difficile à placer (alors si ça merde 2 fois vous imaginez ?...).

Etape 1: Simu (3 mois)

Réalisation des logiciels en simulation (en pratique les périphériques sont simulés de sorte par exemple que la commande d'un moteur est envoyée dans sa mesure odo). On met au point l'infrastructure, notamment env de dev et outils de débug (gdb, logs, télémétrie, ...). Permettez d'insister sur le fait que tout se joue à la coupe quand on découvre les vraies emmerdes des tables/objets finaux, et là il faudra être réactif. Pour être réactif il faut de bon outils de confiance et des membres entrainés à les utiliser.

On s'assure également que quand on suit une trajectoire en simu, le robot la suit en simu SANS GAINS ! Sinon c'est qu'il y a des bugs dans les maths et il faut les chercher sinon c'est le PID qui va le porter et ça enlève de la marge de stabilité et performance. Ca permet de vérifier les timings des stratégies et de se rendre compte si un robot est trop chargé ou pas (et donc impact sur le nombre/répartition actionneurs).

La simu ça permet aussi de travailler sans les cartes élecs qui sont en général pas là (dit autrement on découple les plannings du SW de celui des autres métiers et donc on prapage pas les emmerdes de l'un à l'autre). En parrallèle méca et élec font leur designs. Egalement quand on intègrera plus tard et que ça coince, on pourra retourner vérifier si le problème existe en simu ou pas et ainsi trouver rapidement le métier en cause. Pour chercher une aiguille dans une motte de foin: on fait des tas de foins plus petits.

Etape 2: Breadboard (1 mois)

Essais sur une carte de dev, avec des cartes d'adaptations ou de l'élec sur carte à trous avec les périphériques. Ca permet au SW de dev les drivers de la carte (driver GPIO, I2C, CAN, UART,...) et les controlleurs de périphériques (Moteur, odo, lidar, ...). Souvent on va détecter des trucs bêtes genre les pullup/down manquantes et les difficultés des datasheets (sujets pas expliqués, erreurs/bug, siouxeries introduisant des contraintes). De ça on voit si on peut rattraper le coup ou s'il faut changer le périphérique ou son élec de commande.

Cette étape est importante, nécessaire et fait gagner du temps. Je ne compte les projets pro et perso autour de moi qui se disent "on a qu'à le faire sur le robot directement ça ira plus vite on gagne une étape". NOOOON ! Ca finit toujours mal, c'est plus long de travailler sur une machine complète (ex: gestion du power ou de la safety à faire avant d'utiliser les périphs, séquences de boot machine, ...).

Ca permet souvent de travailler en sécurité parce qu'il n'y a pas de charges utiles (genre un bras manipulateur), c'est plus pratique pratique à bricoler et si vous faite une bétise vous évitez de cramer des périphériques non concernés par vos tests (chers en général) qui sont là et qui n'ont rien demandé. Et puis si on se rend compte que ça marche pas, faut refaire le robot (parce qu'en général le nouveau périph a le bon gout d'avoir des tensions différentes et une taille qui passe pas dans le chassis). On évite aussi de se prendre tous les problèmes liés à la cohabitation parce qu'on va démarrer les périphériques un par un.

 Breadboard.jpg   105,28 Ko   8 téléchargement(s)

Etape 3:  intégration robot (1 mois)

Le robot est monté pour la première fois complètement et on va commencer à l'utiliser en douceur (vitesses et accélérations faibles). On met au point les séquences de démarre/homing/safety/configuration. On identifie les problèmes liés à la cohabitation (han, ça marchait avec un moteur et pas avec 2 en fait).

On règle les timing. Là aussi étape importante il faut vérifier dans le détail que les temps sont respectés (valeur d'une seconde, fréquence des clocks, bagotage d'une GPIO sur oscillo, durée des boucles périodiques et temps utilisé/restant). C'est hyper important pour les précisions des boucles ouvertes et tant que la boucle ouverte n'est pas bonne, ça ne sert à rien de démarrer l'asserv. En général ça s'entend à l'oreille sur des consignes de rampe d'actionneur si ça "vibre"/"grésille". C'est aussi important que quand vous demandez d'attendre 200ms bah c'est pas 600. Je vois souvent des devs confiants là dessus sans vérifier, et je vois souvent dans les projets des problèmes qui viennent de ces tests pas faits. 

En gros on va commencer à faire des trapèzes de vitesses et là le robot il doit faire à qque poullième près une ligne droite de la bonne longueur (sur 30cm moins d'1cm d'erreur et droit à l'oeil). En général sans calibrer sur une méca propre, une élec en place et un SW bien piloté ça va bien se passer. Suivant les capteurs dispo on peut tracer des courbes et comparer, sinon à l'oreille ça fait beaucoup de choses.
 Rampe_1.2m_2000mm.s_3500mm.s2.png   15,5 Ko   9 téléchargement(s)

On roule doucement pendant ces phases, tout le monde a eu du mal à arriver à l'heure donc on éviter de tout péter tout de suite. L'objectif c'est que tous les métiers lèvent leurs risques. La bête doit être docile et vous devez avoir confiance en elle à l'issue de cette étape. Exemple ici elle est sans crainte sur mon bureau sans risque de partir à fond par terre. Sur la vidéo qui suit on voit que le robot dépasse et revient en arrière, c'est pas normal sur une boucle ouverte donc débug:

On règle les différentes parties du contrôle en augmentant progressivement les performances en poussant plus loin que ce qui est prévu. Ca peut être destructif mais vaut mieux le savoir tout de suite. Normalement tous les métiers auront pris des marges (heiiiiiiin) et donc ça devrait bien se passer. 
De façon générale on traite TOUS les problèmes qu'on voit (au moins on identifie clairement le prob et on choisit de vivre avec, ce qui est différent de le subir quand on a rien compris ;-p).

Sur la vidéo suivante on voit un petit mouvement à très fortes accélérations. De fait je suis passé sur une table de test avec des bords parce que ça peut partir très vite à tout moment sans que je puisse l'attraper (d'autant plus vrai quand on est tout seul). Les accélérations sont déraisonnables et on conmme à entendre à l'oreille que ça va pas (d'où l'importance d'avoir déjà enlevé les autres parasites auditifs). On entend le "clac" du chassis qui se repose violemment après un wheeling. On sait qu'on atteint les limites ça donne une idée du max et on a vérifié (entre autre) que les contrôlleurs moteurs n'explosent pas et ne sont pas à 200°C. On voit aussi que le robot fait pas des aller retours de la même distance, il faut chercher et débugger ça. 

Comme expliqué plus haut dans le post, avoir plusieurs robot identique ça permet des tests comparatifs, notamment pour les perfs: course entre version A et B des réglages:


Etape 4:  Utilisation robot (1 mois)

Le robot est mature, les membres de l'équipe et leur design aussi, on peut commencer à vraiment utiliser le robot et mettre au point des stratégies. Sur la video qui suit le rush de la superstar.

Ca a nécessité au préalable des essais avec les robots voisins pour mettre au point la séquence de sortie de la zone PAMI. On utilisait les capteurs sur les côtés initialement prévu pour le suivi de mur pour voir quand le Dragster était parti (avec BIEN SUR un timeout au cas où il ne parte pas HEIIIIN, ce qui n'arrive JAMAIIIS n'est ce pas ?). J'imaginais pas en arriver là mais en pratique ça nous a fait gagner énormément de temps/fiabilité sur les séquence de départ. 

On voit aussi une idée qui consiste à "rebondir" contre le mur. C'était efficace mais pas reproductible. En haut de la pente on se recale parce que pour les premiers matchs en l'absence de retours sur les vraies table on joue la carte de la sécurité. Comme on avait pas de capteur de contact on doit meuler la table pendant un moment pour s'assurer d'être dans le mur. Comme c'est pas top on a implémenté plus tard une détection de bordure avec les capteurs sous le robot pour ne plus avoir à se recaler (et là encore avec des sécurité pour que si on détecte jamais de bordure on s'arrête quand même).



L'oeil aguerit aura vu qu'il y a des délais inter ordre un peu longs c'est volontaire c'est pour s'assurer que le robot est effectivement arrêté, on n'a pas eu le temps d'enlever ça mais l'année prochaine ça enchainera plus vite. A noter qu'on a vérifié bien sûr qu'on empilait pas les délais entre les 12 couches d'architecture logicielle qui donne un ordre. 

Le règlement impose de faire un gros robot, donc on échappe pas à la règle. Sauf qu'on n'avait pas les moyens de le faire cette année, donc on a fait un "Dragster" de plus et on y a ajouté une lame de buldo pour pousser péniblement des éléments de jeu.  Au départ on voulait juste aller marquer les 10pts dans la zone à la fin, mais limite pour l'homologation donc on a quand même maqué un gradin.

En pratique on a transpiré sévère parce que pousser un gradin de 2kg avec un robot d'1.5kg sans odomètre et une lame de 40cm de long qui fait gîter ... bah c'est touchy. En pratique on a tout essayé pour faire en sorte que le robot tourne tout le match, j'ai passé des heures et des heures à mettre au point mais ça marchait sur la table d'essai et pas sur les autres. 

En dehors du patinage quand on pousse 2kg avec 1.5, la gîte introduite par l'inertie laterale de la lame ça décollait les roues arrière alternativement. Ce qu'il aurait fallut faire c'est un pivot entre la lame de buldo qu'on aurait mis sur patins et le corps du robot pour assurer que les roues sont toujours en contact avec le sol (et puis avoir des odomètres aussi ^^).

J'ai pas beaucoup de photos de celui là parce qu'on l'a fait au dernier moment et c'était pas notre priorité. Un proto quand même pour la route:
 Blade prototype.jpg   71,86 Ko   7 téléchargement(s)

Et quelques videos des runs:


 

(oui les PAMI se sont un peu fail sur le dernier vid' ^^)

Petit bétisier.

On a aussi été surpris par le centrage des groupies, ça se jouait à 40g (c'est à dire pas grand chose) entre ça marche bien ou pas. Pour le plaisir je vous partage le premier essai avec un mauvais centrage... surprenant:


Comme le deal c'est de partager les fails, malgré toutes nos bonnes pratiques (et avoir fait attention à ça sur les robots précédents) on a quand même réussit à se fail sur le passage du cable de prog:
 IMG20250515134850.jpg   105,03 Ko   9 téléchargement(s)

Les ventilos ont les a intégrés un peu tard dans l'année les cartes étaient faites (enfin on a changé la tête du capot et la solution initiale convenait plus). On a cherché des petits ventilos et on a trouvé que des trucs 24V. Du coup bah fallait reprendre sur le VBat délivré au moteur... donc on s'est repris sur les condo de filtrage (oui c'est porky x 1000):
 IMG20250515181046.jpg   91,84 Ko   8 téléchargement(s)
 

Je profite de l'occasion pour partager un tips: c'est toujours des débats interminables avec les arbitres qui pensent mesurer mieux avec un mètre ruban tordu de biais que de la CAO imprimé au 10ième pour valider qu'on tient dans le périmètre/la hauteur. Du coup on a eu l'idée de faire un cube d'homologation dont on peut vérifier facilement la dimension avec un reglet, et si on arrive à l'empiler sur le robot (ou les 2 groupies) ça veut dire que tout est ok:


Pour les Superstar/Dragster:
 Homol dragster.jpg   127,93 Ko   8 téléchargement(s)

Pour la paire de robots:
 Homol paire.jpg   106,72 Ko   7 téléchargement(s)

Une fois les 2 "gros" PAMI réalisés (dragster et superstar) il nous reste à faire 2 Groupies dans la place ... d'une superstar. L'idée initiale dans l'année c'était celle du "robot Q" (c'est à dire 2 robots "verticaux" l'un devant l'autre de 150mm large par 75mm de long). Mais en pratique les performances de déplacement étaient très mauvaises. On visait une roue maison sur joint torique de 40mm de diamètre sur des Nema14 (puisque moins besoin d'aller hyper vite). La ref: 14HM08-0504S

Là on a un moment d'égarement on imagine éventuellement mettre des robots sur la tranche pour faire un seul chassis, et avec un servo d'essayer de faire basculer pour revenir à plat:
 CrazyStart.png   112,53 Ko   9 téléchargement(s)
Sauf que ça marche pas du tout, le robot de devant glisse et s'écarte de celui de derrière sans tomber. En faisant tomber à la main on se rend compte qu'on est complètement paumés donc faudrait faire 2 recalges. Bref idée sympa mais nulle en pratique (ça aurait été très classe cela dit).

Par un hasard de discussion, on s'est mal compris avec le mécano et lui avait compris dans l'autre sens (2 "saucisses" côtes côtes). Mais pas de place pour nos moteurs/roues. Et à un moment on se dit "bah faudrait faire un peu des 2" et du coup hop on tente des robots "fromage" en forme de triangle:
 Draft_Depart.png   954,95 Ko   7 téléchargement(s)
 Draft_Depart.png   507,82 Ko   9 téléchargement(s)

Là on tient un truc, en plus on peut remettre des roues mousses RC et garder nos hubs (pour le détails parce que je retrouve des roues 1/10 AV avec hexagone, donc 26mm de large au lieu de 31, sur les 2 côtés c'est énorme comme gain). Au départ on voulait des roues par joint odo ça marche mieux en rotation, mais pour faire ça, ça faisait la même largeur que les roues mousses alors on s'est dit qu'on ferait qu'un seul moyen de propo pour tous les robots. Bon en pratique c'était une erreur, sans odométrie on galérait vraiment sur la répétabilité des rotations.

Un premier proto sort, on rentre tout mais y'a pas la place pour les têtes de girafes (et le mécano est fatigué):

 CacheBatterie_old_design.jpg   114,64 Ko   9 téléchargement(s)

 FrontFace_èold_design.jpg   63,15 Ko   8 téléchargement(s)

Maintenant qu'on a un thème, c'est vraiment pas acceptable de pas mettre la tête (et en plus je suis chiant je la veux en haut et projetable comme pour les "gros" PAMI). Du coup je me chauffe à faire un tétris de l'enfer (en vrai on a rentré 2 VL de plus après). Pour arriver à ça c'est plusieurs itérations de design (5 ou 6 je pense), mais le résultat en vaut la peine, on va probablement garder ce bloc pour plusieurs années. C'est chaud pour les batteries qui passent tout juste sous le VL pour la mise en place/retrait

 Passage batteries.jpg   63,09 Ko   9 téléchargement(s)
 Avant groupie.jpg   76,43 Ko   8 téléchargement(s)

Ce qui était bien c'est qu'on pouvait lester dans le petit capot devant (et ça se joue à 40g près entre ça marche bien ou pas!):
 Lest.jpg   63,34 Ko   9 téléchargement(s)
 

Une vue de l'ensemble:


En pratique on a eu un truc assez surprenant sur la conso des moteurs. On s'attendait à ce que les petits robots tirent moins de courant que les gros, et en fait c'était l'inverse (probablement que le bobinage plus petit nécessite plus de courant pour obtenir le couple). Du coup on a brûlé qques fusibles avant de bien comprendre. En pratique on était un peu juste en couple. On avait prévu de monter les 4 PAMI sur la scene et ça marchait pas de façon fiable et on rate le dernier match.