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.

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.


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:


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:


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):

 

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:


Pour la paire de robots:

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:

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:



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é):

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




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!):

 

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.



 

On a soudé les fils directement sur les boards VL53L0x parce que ça fait qque chose de supper compact.


Overview carte HMI:


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).

Quelques photos du setup là bas. On prend un gîte pour le confort parce qu'à la coupe l'accès au table est pas dingue (même si c'est 1000x mieux qu'il y a qques années). Et même la nuit quand on y accède facile les tables sont assez vite bourrinées (surtout quand il y a Eurobot). On prend 2 imprimantes pour les mêmes raisons qu'on fait 2 robots à chaque fois: c'est important d'avoir du spare pour la buse bouchée au mauvais moment (ou autre). Petite photo des caisses de rangements parce que c'est important de trouver rapidement ce qu'on cherche surtout quand on est plusieurs, pas forcément avec l'occasion de se parler avec les dodo décalés, ou qu'on est fatigués et qu'on voit pas un arbre dans un plaine. Dans la même lignée pour éviter le boulet qui se mélange entre les piles et qui met des piles vides pour le match on a des belles boites pour dire ce qui est plein ou vide.

A noter que comme toujours y'a qques pièces qui sont arrivées hors délais (genre les batteries et le poster !), ça va qu'un des membres partait plus tard et il s'est rajouté 2h de route sur les 7h initiales (il était refait). Je dis ça parce que même en pro j'ai toujours des gens trop optimistes dans les équipes qui pensent que tout va bien se passer, mais la vraie vie c'est qu'il faut prévoir 1 bon mois d'avance pour tous les cas "oui mais ça aurait pas du se passer comme ça" ("ok mais c'est la vraie vie bro, après la compèt c'est trop tard", en pro on peut décaler les dates mais là non).

Y'a un truc qui nous a beaucoup aidé (et que j'impose en pro aussi) c'est d'avoir 2 versions du même robot (par opposition au gros). Parce que:
- quand il est en panne y'a un 2ième
- quand on sait pas si c'est normal que ça merde on teste sur l'autre pour voir si ça fait pareil (debug differentiel, des fois sans ça on peut juste pas s'en sortir)
- quand on teste des améliorations (typiquement performance motion) on met l'ancien et le nouveau code en concurrence sur les 2 robots.
- quand on veut faire une amélioration on peut retrofit un robot pendant que l'équipe bosse sur l'autre stable.
- quand on a oublié de commander du spare, y'a toujours un autre robot
- quand il y a des choses à faire manuellement (les câbles) qu'on fait jamais d'avance, on est content d'avoir un spare/modèle pour dépanner vite.

Ca a l'air de rien, mais je compte plus les semaines de délais dans les projets auxquel je participe qui sont liés à ça. On nous objecte souvent que ça coute cher, au prix de l'heure c'est souvent vite rentable sans compter qu'il y a des choses qu'on peut éventuellement pas deviner sans (debug differentiel) et que certaines dates pour des essais dans l'environnement réel/certification sont pas déplaçables facilement. 

Bref faites toujours 2x le même robot, votre vie va changer.

On reprend tout de zéro et le mécano pour les PAMI a fait peu de CAO. On part sur FreeCad et l'objectif dans l'année au fond c'est surtout de mettre au point des méthodes de travail, et d'être efficace sur les outils. Parce qu'on le sait tous, à la fin on pète tout avant la coupe de toutes façons donc ce qui est important c'est que le jour où on décide de tout péter, ça se fait vite avec des gens/outils efficaces et robustes.

Dans les méthodes au départ on vise un chassis "monobloc" en une seule pièce de PLA parce qu'une PAMI ça tient sur un plateau. L'objectif c'est de ne pas passer sa vie à monter des pièces dans le robot, à les chercher partout parce que qq'un a démonté le robot à 4h du mat et est tombé de fatigue sans dire où il a mis ces p***n de pièces et parce que les inserts ça nous fait peur. En pratique ça rend les choses hyper complexes dans Freecad (qui il faut le dire transpire assez sévèrement avec les pièces complexes) et avec mes gros doigts j'arrive plus à monter le robot, donc on fait qques concessions. Et après quelques essais les inserts c'est vraiment pas si mal tant qu'on n'est pas en traction dessus. Le robot tient en 9 pièces, 3 plateau pour 24h d'impression (important de pouvoir refaire un chassis en une nuit si on pète un robot à la coupe).



Après quelques essais côté couleur on part sur un beige sable (Ref PLA mat de Bambulab)



Voici la préparation pour le montage des 2 premiers "release candidates" (après 8 versions de chassis je pense ^^):


Vue monté.


Sur le côté on vient un VL53 à l'avant initialement fait pour faire du suivi de mur, sauf que ces nouilles ils ne voient pas à moins de 4cm (contre 1 dans la datasheet NDLR), donc on a mis un patin téflon parce qu'en fait bourriner en longeant le mur ça marchait mieux que le suivi de mur propre... déception mais bon faut être pragmatique. Du coup le VL était vachement bien pour l'anticollision en tournant parce qu'on a les roues à l'arrière donc on balaye, et comme on allait chatouiller la superstar adverse on se devait d'être nikels. On voit aussi à la verticale au milieu en haut un ventilo  pour extraire l'air chaud des controlleurs steppers (TMC2209). En vrai c'était pas nécessaire mais ça fait jamais de mal à l'elec, le gain entre passif et souffler même léger est hyper grand, et la coupe était tard cette année (fin mai) donc il faut chaud (et le PLA accessoirement ça fond, on a tordu des chassis dans les essais)(oui bon on est des gorets on sait).

Les VL c'est sympa parce que ça prend vraiment  pas de place:


La tête doit se rétracter pour tenir la hauteur max. Au départ y'avait que les têtes, mais on avait mal lu le règlement si la tête fait la funny action (mise en mouvement) elle ne marque plus la zone projetée au sol à la verticale, et le but initial c'est bien de pouvoir scorer par dessus les PAMI qui gênerait le mouvement (gniark gniark). Du coup on a ajoutée une queue, avec une belle sérigraphie pour rappeler notre historique (quand même on ferait pas un robot sans un "8=>" dessus).



 

Vue dessous:

A l'intérieur il y a une carte moteur avec les piles dessous, le chassis a une ouverture avec un couvercle pour le changement rapide. On peut aussi accéder aux fusibles (et oui on en a cramés) et les ports débug/bootlog, la LED d'erreur fatale et de heartbeat pour le debug grave. Les moteurs sont à l'air pour respirer et parce qu'on tire tous les demi-mm possibles. On voit aussi les positions des VL53 qui regardent le sol pour détecter la bordure et pas tomber.

Côté performance on découvrira après qu'on est limité par la perte de couple des steppers à haute vitesse et on n'a pas le temps de regarder si on peut bricoler le stepping (je crois que les TMC2209 le font déjà en vrai), mais on a des perfs solides sur le plat (et donc dans la pente): 3.5m/s² et 2m/s de vmax, pour une PAMI je pense qu'on est déjà LARGEMENT au delà de ce qui se fait en moyenne.

Le chassis final:


Pour rappel on était parti de ça:


Arriver à un moment où on peut tout monter/démonter avec la place pour les doigts/le tournevis, où on peut récupérer les écrous tombés, où on case tout, où on passe les câbles, où les jeux/ajustements sont bons, ça fonctionne, ... Il a fallaut un paquet d'itérations (au moins 8 grandes versions).
 

On montre souvent les projets fini et les réussite, mais j'aimerai montrer aussi le point de départ, les râtés et les stupidités. On me demande souvent "Comment on fait un beau robot ?", "Bah on en fait plein de moches avant qu'on montre pas ^^".

L'année Eurobot c'est en gros 7 mois de dev de Oct à fin Avril. Même avec une équipe de pro entrainés c'est pas dit qu'on y arrive dans le temps imparti. Du coup, faut commencer avant. Donc notre plan c'était d'avoir un robot qui roule avant la sortie du règlement, d'ou la naissance de "Robot Q" (video dans le lien), un proto pour tester la montée de la rampe et l'intégration dans l'espace disponible:


Sauf que ça c'était après un peu de règlages !



Les premiers hubs en PLA:


En tous cas y'en a un à qui ça plaisait d'avoir une rampe: 


Les problèmes:
- les plots imprimés comme patins antibasculement ça frottait trop => dérapages => perdu (parce qu'on est en boucle ouverte complète). On a remplacé par des patins téflons
- les plots trop près des roues, pour monter et passer la cassure on a besoin de plus de distance => on a rallongé le chassis. Le patin teflon est aussi monté avec un peu d'angle (il est pas horizontal, il a le nez un peu relevé pour faciliter la marche).
- besoin d'un capteur pour trouver le bord => ajout des vieux Omron EZ qui trainaient
- besoin de descendre le centre de gravité (l'augmentation de la longueur va aider).
- les roues "dures" ça marche pas pour passer la pente. Ca adhére ok le joint torique mais c'est pas dingue => passage aux roues mousses RC 1/10 => et hop le dragster est né

Le premier chassis moins vertical:

• Montée de la pente sur le bureau
• Accel à plat
• Montée pente complete
• Le mini mécano <3
• Premier rush zone adverse

Une petite video du fonctionnement du premier proto.



Du coup on essaye des choses:
- la vraie table est noire (et le vinyle de test est blanc) et en fait les Omron ils sont sensibles à la couleur donc ça marche plus.
- en marche arrière c'est le drame: 

A force d'essais on arrive à monter vite :

en réalité même mieux qu'on l'imaginait, et de là est née une idée (certe clivante mais bon on est comme ça): on peut monter le PAMI qui va dans la zone la plus éloignée. Faut juste être le premier => "On fait un dragster".  La superstar et le dragster monterons donc tous les 2 en haut de la pente avec le même chassis. Il restera peu de place pour les autres PAMI (les groupies) mais tant pis.

Pour le montage sur les moteurs on avait essayé de faire des hub en impression 3D ou des roues avec méplat et en fait le PLA se mattait très vite (faut dire on n'est pas dans l'économie de puissance nous ^^). On a essayé de monter un insert pour tenir mais on a pas réussit, on ne maitrisait peut être pas bien, on avait peut être pas les bons inserts, du coup on a fait tout en alu (l'usineur est un malade de l'économie de poids en aéronautique donc voilà 2g le hub ^^):



Quelques références:
- Moteurs pap 17HE12-1204S
- VL53L0x pour la détection de bordure (et aussi d'anticollision) y'en a de partout sur amazon ou autre.
- Batteries Keenpower 18650 avec BMS intégré

C'est fort de ce succès (et seulement après !) qu'on décide de tout refondre pour de bon et on part sur une nouvelle élec.

Petite astuce qui me parait utile à partager: on fait toujours un support "anti-évasion" pour éviter que les robots partent à balle du bureau sur lequel on programme. Bien sûr c'est pas sensé arrivé (notamment parce qu'il faut une action manuelle dessus avant départ, hyper important dans tous vos projets IMO), MAIS la vraie vie c'est que ça fini toujours par arriver et là on envoit un robot par terre et on pète le port USB du PC (dites que ça vous est jamais arrivé ?!).




Dans la série des astuces, pour lester les robots quand on veut faire ça bien on fond des plombs dans des gabarits imprimés en 3D, mais comme on avait pas la foi de faire tout ça, on a pris des masselotes d'équilibrages de jantes, c'est hyper pratique. 30€ les 6kg et avec ça on peut en caler partout c'est autocollant. Dans le robot on les voit bien empilés sous le ventilo, on a mis dans les 300g au total (alors par contre celui qui s'est tapé le montage, moi, en a chié comme un russe avec ses gros doigts)



Dans les  "astuces" de l'année on a trouvé un truc golden pour les batteries : https://www.nkon.nl/fr/keeppower-18650-3500-li-ion.html. C'estun peu cher par rapport à d'autres solutions mais vu les contraintes du règlement pour s'affranchir du sac lipo c'est le confort. Ce sont des blocs avec "BMS" intégré pour éviter les conneries et après ça se charge une par une donc pas de soucis d'équilibrage. Ca marche parce qu'il y a que 1 à 2 piles par PAMI, sur un gros robot pas sûr qu'on adore l'idée de changer une demi douzaine de pile à chaque fois.

Ce que je trouve important pour tous les projets logiciels embarqué c'est de faire une petite station sol qui permet de téléopérer les actionneurs. C'est hyper utile (pour pas dire obligatoire) pour tester les périphériques.

Hello,

Participant à la coupe de robotique depuis 2007, suite à une pause en 2016 pour tout un tas de raisons et un appel du pieds d'autres équipes dites "légendes" (les vieux quoi) et il faut le dire de gros changements sur l'intérêt portés aux équipes expérimentées, j'ai rempilé. Du coup j'ai embarqué d'autres fous/victimes (selon le point de vue). 

Au départ on avait dit "oui oui on change rien, on fait avec l'élec/soft 2017" (oui on avait bien tout rangé et documenté quasi 10 ans après c'est reparti sans trop de heurts, le plus dur c'était de retrouver une version de Atmel Studio qui s'est fait mangé par un concurrent). Dans les "fous" de l'équipe j'ai un électronicien compétent qui me dit "t'inquiètes je te fais une carte", et voilà c'est le drame de "on y va en diletante, nous voilà à fond avec tout le soft à refaire (faire dire Atmel Studio ça m'enchentait pas de ouf). L'arrivée des lidar pas cher (avant c'était 3k€ mini, là 100€ en 10ans...), des imprimantes 3D qui marchent (oui on en avait une mais bon si t'éternuais à côté fallait tout rerégler et y'a que celui qui l'a construite qui savait la faire marcher, maintenant j'ai une Bambu mini qui tient sur un tabouret et qui marche sans qu'on lui dise rien en silence), des VL53Lxx, TMC2209, bref pleins de choses qui vont que ça vaut le coup de tout refaire. 

Bien sûr on se dit qu'on va séparer la carte de contrôle moteur de la carte avec le motion contrôle à 30ms et y mettre une com fiable entre les deux parce que sinon on allait s'ennuyer en SW (oui bon c'était pour la mise au point de la stack de com, l'année pro on remet bien tout ensemble). Le règlement tombe et favorise les PAMI (petits robots qui font rien à par se déplacer et se paumer) du coup on fait juste les PAMI (moteurs PAP, pas de loc tout en boucle ouverte YOLO, VL53L0x pour l'anticol et qques mini servo pour les clowneries décoratives). On fera un gros robot parce que c'est obligatoire mais c'est en fait une PAMI déguisée. 

Cette année il faut monter la pente, nous on aime les robots rapides, donc on a fait un dragster qui monte le plus vite possible (je pense qu'on a le record). Le reste c'est de la "broderie" autour de cet objectif qui ne rapporte pas de points mais qui nous fait marrer. J'ai plus les vidéos mais au début on arrivait à "sauter" arrivé en haut de la marche, mais bon en boucle ouverte c'était tendu à rendre robuste.

Comme avant on devait attendre 2 mois des plaques métal à l'usinage, avoir une imprimante 3D... bah ça pousse au (very) fast itératif: on dessinait les changes "n" et amélio du design n-2, pendant que le n-1 était en impression et on itérait dans la journée. Alors à la fin ça donne ça:

Oui... bon, on est peut être allé un peu loin, mais c'est tellement le kiff de plus avoir à limer des heures !   

Comme il fallait un actionneur à secouer à la fin du match pour marquer des points et que stratégiquement c'était malin d'être haut et loin, les délires (oui il était tard) ont mené à un design qui ressemble à une tête de girafe et là le délire est parti, on avait un thème, des couleurs, un logo, un objectif cosmétique clair ! (LE plus important)


Du coup nos gueules (je suis au milieu et oui je ressemble plus à la photo du forum qui est trop vieille ^^)


Chaque girafe avait sa petite tête custom. Ces images et le logo ça sort direct de ChatGpt (c'est sidérant). On avait fait une plaque pour transporter tout ça au milieu de la foule sans rien abimer (et dans la voiture aussi c'est pratique).

Un match:

https://www.youtube....e=shared&t=3594

On a beaucoup souffert pour arriver au premier match avec le setup complet. Résultat 8ième à la première ronde  (là c'est surtout le fait d'être fiable et d'avoir le match complet qui passe du premier coup, merci les bonnes pratiques/méthodes de tests/investissement/et un peu de chance). A la fin on fini 20ième parce que les autres finissent quand même par marcher et vont pas nous laisser en haut avec notre "arnaque" à jouer sans gros robot (alors l'arnaque c'est parce qu'on avait pas les moyens humains, c'était pas pour gruger heiiiiiin). On est au final dans le top des légendes et ça doit se jouer à pas grand chose pour qu'on soit sélectionnable pour les finales (ce qu'on aurait refusé parce qu'on avait pas de gros robot c'est moche pour le public ET on avait déjà sorti les bieres).
 

Hello  ,

Je suis tombé dans la robotique à l'école d'ingé (aéronautique). Au départ pour l'avionique au final j'ai ouvert le placard dans lequel il y avait un robot de la compèt E=M6 des années 2000, aujourd'hui Coupe de France de Robotique / Eurobot. De là j'ai participé depuis 2007 au concours juqu'en 2016 où on s'est arrêté à cause de changements de règlements qui ont disloqué l'équipe. 

Un projet pro avec création de startup pour faire des véhicules de transport de bagages a pris la suite de 2017 à ... Mr Covid (2022). On a quand même tourné des centaines de km à Charles de Gaules sur les routes de service avec un prototype (c'est presque plus impressionnant qu'on ait réussit à se faire autoriser/assurer que de faire la technique ^^). Si y'a bien un truc qu'on s'attendait pas dans un monde de croissance à 5% stable annuel avec des masters plan projet à 20 ans ... c'était une juste de 80% du traffic associé à un choc moral pour les intervenants du secteurs qui n'avaient jamais connu de crise. Bref c'était déjà pas facile d'innover dans un monde comme ça (On m'a quand même dit "nous on innove, on prend les solutions qu'on a vu marcher ailleurs" ...) et avec des délais de décision ... (loooooong  ;-D) bah on en est mort. 

Depuis on a monté avec un des employés devenu associé une petite structure de conseil pour le dev logiciel en embarqué (notamment médical et robotique mobile), voire aussi archi système, risques, projet, gestion R&D et conseil aux codir. Je profite je fais ma pub (https://www.oroksw.com/ le site est immonde mais on est full rien qu'en bouche à oreille, faut regarder le flyer quoi) et en parallèle on est dans un super projet de médical pour sauver les gens des sepsis dans une startup toute jeune. 

Côté pro j'ai travaillé chez BA Systèmes vers les années 2010 (AGV manutention), puis dans le médical. Souvent sur des projets safety critical (ça veut dire qu'on tue les gens si on fait n'importe quoi   ). J'ai bossé aussi sur des enjambeurs viticoles automatisés (ça, c'était vraiment sympa :-D) et des robots de tri de colis. Bref pas mal de choses en systèmes embarqué. Je vais pas m'étaler plus au besoin: https://www.linkedin.com/in/william-lambert-orok/ 

Comme ça suffisait pas (en plus des 2 enfants arrivés depuis et de compétition à très haut niveau de jeux de figurines qu'il faut peindre w40k), j'ai repris la compétition Eurobot cette année (oui c'était pas malin mais bon quand on aime ...). Le tout sans café parce que je suis réactif aux énergisants (un verre de jus d'orange et je dors plus ^^). Je sais pas comment je case tout ça, mais bon on se débrouille. 

Je mettrai plus tard des pages dédiés de présentation de nos différents projets passés pour Eurobot. On était connus pour notre machine à 3 tourelles motrices et directrices (28kg, 6.5m/s² et 3 m/s). Maintenant on décore nos robot sur le thème girafe (délire sorti de nulle part mais très sympa à voir). Comme on vient de reprendre on essaye de diggérer 10 ans de progrès (y'a vraiment bcp de choses qui sont allées vite), et on reconstruit un club avec un local toussa toussa. 

De mon côté je suis au départ ingé système avec des solides compétences côté logiciel, puis avec les années un peu de méca/élec sur des projets solo de maker (c'est surtout là où je vais appeler au secours  ) et de la gestion technique au boulot. Dans le cadre des projets Eurobot on veut faire des beaux robots rapides, bien rangés, bien finis qui à y mettre le temps et le prix. Côté pro on a fait 5 ans de recherche en architecture logicielle/gestion de projet (oui oui) parce qu'on en a marre de voir des projets se planter royalement sur le dev logiciel. J'ai une valise d'exemples réels sur comment planter un projet très très très garnie !! Du coup on se dit que si on fait déjà pas ça, ça a des fortes chances de pas trop mal se passer. Plus sérieusement on a mis au point une méthode qui est de l'ordre de la silver bullet. Attention c'est dingue ça repose sur ... travailler correctement ! Eh oui c'est au fond pas si dur (en vrai ça l'est pour négocier avec les managers/cdp, mais c'est là qu'on a travaillé pour mieux communiquer). Je fais le clown en vrai y'a quand même des pratiques de dev logiciel et d'architecture au fond de tout ça. La grande force c'est que ça plait aux manager sans faire chier les dev et ça c'est une sacré réussite  .
Bref du coup on utilise Eurobot comme laboratoire (et certains clients aussi, chuuut, mais même si on fait pas tout bien du premier coup on fait pas pire que l'existant), et on a une stack de com embarquée safe qu'on va probablement vendre dans le domaine du médical (ça permet par ex d'avoir de l'UDP avec une session et de la fragmentation, sans avoir les emmerdements du TCP qui fait du streaming au lieu de faire du framing). On peut probablement partager les binaires dans le cadre de projets non lucratifs. 

J'ai 39 ans, je suis à Bourgoin Jallieu, ancien rugbyman (maintenant bièroman seulement cause blessures et la récupération qui se passe moins bien). J'ai vu qu'il y avait des sumo à la Tour du pin, je suis deg d'avoir râté ça, j'essayerai de passer la prochaine fois (non non resister à l'envie de faire aussi un robot sumo en plus du reste... non non non).