11 réponses à ce sujet

[wix]

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

[wix]

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.

[wix]

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.

[wix]

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

[wix]

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.

[wix]

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.

[wix]

Cette année on a refait toute l'élec et l'un de nous voulait tester les raspi pico (et notamment leur SDK). Mais comme il y a pas assez de pin (et qu'il faut l'IHM en haut et les piles/trucs lourds en bas) on a fait 2 cartes avec une carte "moteur" qui gère les actionneurs/capteurs et une carte IHM qui a les boutons/leds/écrans/buzzer. En vrai on aurait pu mais y'avait plus de spare (et les gens sérieux vont pas au combat sans le spare). On voulait aussi 2 cartes pour tester notre Framework de com donc on a fait une distribution logicielle un peu nulle mais qui servait à tester la com (multiplexer IO d'un côté et motion control de l'autre, à 30ms de cycle sur UART 115200, ça marche mais faut être propre).

Pour faire 5 robots (en fait 7 parce qu'on fait 1 de spare sur chaque type) on a fait 10 cartes moteurs et 10 cartes HMI. Quite a challenge. Et en vrai on en a pas eu de trop parce pendant un temps y'en avait plusieurs en panne.

 

Le buzzer c'est hyper utile pour le débug (et pour jouer Star Wars on va pas se mentir c'était le premier dev sur la carte HMI ^^). Avoir une LED rouge "fatal fault" pour les asserts sur chaque carte c'est utile aussi (en gpio directe hein, pas derrière 12 expanders qui vont pas marcher quand le uC est en vrac). Avoir une LED de "vie" c'est bien pour savoir que le SW est vivant quand c'est la merde intégrale et que le reste marche pas pour débugger. On a gardé les logs à part sur les ports USB des pico en "printf" (bootlog, console, whatever you call it). Et le reste on le débug à la station sol sur la com reportée sur l'outil de téléopértion sur le pc de dev.

 

Overview de la carte moteur (c'est la v1, sur la v2 on a jouter les LED fatal, de vie et le report de l'UART qui est dans la nappe pour pas avoir à bricoler le robot pour faire du standalone sur la carte moteur. Le uC c'est le contenu d'une carte pico1 qu'on a remis sur notre carte (MAIS avec un bouton reset pour éviter de se faire c****r à déco/reconnecter le cable USB pour prog en UF2).

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

[Mike118]

Premier seroe.jpg
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), 

 

Il te faudrait le VL53L4 à la place spécialement prévu pour les courtes portées =) 

En tout cas je plussoie un grand nombre de tes remarques  

[wix]

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.



 

[wix]

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:

[wix]

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

 

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


Et quelques videos des runs:


 

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