wix

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   0 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   0 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   0 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   0 téléchargement(s)

Pour la paire de robots:
 Homol paire.jpg   106,72 Ko   0 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   0 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   0 téléchargement(s)
 Draft_Depart.png   507,82 Ko   0 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   0 téléchargement(s)

 FrontFace_èold_design.jpg   63,15 Ko   0 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   0 téléchargement(s)
 Avant groupie.jpg   76,43 Ko   0 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   0 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.



 

 MotorBoard_annoted.png   663,91 Ko   0 téléchargement(s)

 MotorBoard_annoted_bottom.png   468,22 Ko   0 téléchargement(s)

On a soudé les fils directement sur les boards VL53L0x parce que ça fait qque chose de supper compact.
 VL53L0x.jpg   134,56 Ko   0 téléchargement(s)

Overview carte HMI:
 Carte HMI.png   473,66 Ko   0 téléchargement(s)

En retex sur les pico:

• le SDK et la doc sont dingue, ENFIN des uC fait pour les softeux avec un vrai kit autour
• le debug au debugger c'est un peu compliqué parce qu'on peut pas vraiment gèrer les arrêts de timers/clocks c'est la limite d'un M0 pour un projet comme ça. Tant qu'on débug des trucs simples c'est ok, dès que le SW complet est là on peut plus vraiment s'en servir (et debugger au log des systèmes temps réels c'est mal !)
• on voudrait pendre le mec de raspi qui a fait des boards géniales mais sans bouton reset qui fait qu'on doit brancher/débrancher l'USB pour prog
• on a eu des soucis de stabilité des flashages. Ca nous est arrivé plusieurs fois à la coupe de rater des flash.
• y'a vraiment trop peu d'IO pour en faire qque chose de sérieux
• le sdk n'est pas précompilé et n'est pas packagé, donc c'est pénible de devoir tout rebuild à chaque fois (oui on pourrait faire notre lib mais bon, c'est un truc qui devrait venir avec, au moins un guide pour le faire)
• si la doc de l'API du BSP est top, la doc de leur build system est vraiment légère.
• la prog par UF2 (copie de fichier comme une clef USB) est vraiment pratique quand on a pas le matos/toolchain en place au début.
• pour les 5€ qu'on paye les boards ça reste incroyable. 
• je comprends pas comment on l'a pas fait explosé en mémoire, il est quand même vaste parce qu'on en a mis du bazar sans faire attention (genre les stacks des threads c'est 8K pour tout le monde même pour la tâche IDLE ... oui on a honte mais ça passe)

Dans la série des pendaison, si on choppe le mec qui a décidé de ne pas permettre de persister l'adresse I2C des VL53 pour nous forcer à mettre des IO expander à gogo et une feature soft au boot pour tout reset un par un, on le brûle sur 7 générations. A part ça les capteurs sont incroyables. Le L0x est pas toujours bien documenté si on veut une utilisation advanced, mais en lisant les docs des versions plus récentes on trouve des infos pour lui aussi par similitude. 

Les TMC2209 (contrôle moteur pap) sont dingo, mais alors faut être patient pour lire la datasheet, y'en a pour qques semaines/mois pour tout mettre en place et faut connaitre les emmerdes des steppers que ça résout pour comprendre. La conf par défaut marche bien, mais nous on pousse les limites à Eurobot donc on a vite besoin d'un peu toutes les features advanced. On regrette d'avoir oublié (ou pu de place) de mettre des LED d'erreur sur les contrôllers.

L'écran ça change la vie. Y'a pas besoin de grand chose pour passer d'un robot abscon à une truc facile à vivre avec qques dizaines de caractères (genre le tension batterie ! Alleluia). Surtout vrai pour afficher les erreur plutôt que la LED rouge qui dit "Ca marche pas mais je te dis pas quoi comme ça tu vas passer mille an à chercher). 

Le buzzer je trouve ça vraiment important pour marquer certains moments clefs de la phase de boot, ça accélère des séquences de flash/debug, ça rassure les gens, et ça attire l'attention quand il y a un prob (plutôt que de continuer à bruler tranquillement pendant que qqun se demande si ça sent effectivement le cramé ou pas dans la cuisine... ah non c'était le robot).