Un robot de compétition impose une forme de vérité que le logiciel masque parfois. Une pièce qui rentre presque dans le châssis n’y rentre pas. Un mécanisme ne fonctionne pas parce qu’il est convaincant en CAO. Une décision prise trop vite revient au moment de l’usinage, du montage ou du match. Robo’Lyon m’a appris cette contrainte-là : construire en équipe, avec de la matière, des délais, des arbitrages et un robot qui finit par devoir rouler devant d’autres équipes.
J’y ai participé à la conception et à la fabrication d’un robot FRC (FIRST Robotics Competition), dans un cadre collectif où la mécanique, l’usinage, la donnée et l’organisation se croisent en permanence. C’est une expérience à part dans mon parcours : elle n’est pas centrée sur l’IA, mais elle explique une partie de ma manière de construire. Avant de chercher à livrer des produits logiciels, j’ai appris à faire évoluer une idée jusqu’à une forme concrète, testable, critiquable, et parfois simplement trop encombrante pour rentrer dans le robot.
Concevoir sous contrainte
La contribution que je peux raconter le plus précisément concerne l’intake Side Roller. L’objectif était de faire entrer un élément de jeu dans le robot, avec un mécanisme capable de l’attraper, de le guider et de rester compatible avec le reste de la base. Sur le papier, le problème semblait mécanique. En pratique, il obligeait à coordonner plusieurs contraintes : la fixation sur la drivetrain, l’orientation du moteur, l’axe des roues, l’encombrement avec les bumpers (les pare-chocs réglementaires), la distance au sol et le rangement du mécanisme au début des matchs.
Nous avons avancé par versions successives. Une première piste utilisait des roues sur axe vertical pour agripper la pièce et la ramener vers l’intérieur du robot. Après plusieurs variantes CAO, nous avons compris que le mécanisme n’était pas assez pensé pour son intégration réelle sur la base roulante. Les roues disponibles ne convenaient pas non plus directement à notre besoin, notamment à cause de leur orientation. Le travail n’était donc pas seulement de dessiner une forme, mais de reformuler le problème autour de ce que le robot pouvait effectivement accepter.
Le moment le plus formateur est arrivé lorsque nous avons dû revenir de la 3D vers l’étude. Nous avions commencé à modéliser trop vite. Un point CAO nous a forcés à reprendre le raisonnement : répartition des masses, position du moteur, axe de rotation, moment autour de la plaque. Nous avons tenté d’équilibrer le mécanisme par des calculs de forces et de couples, puis nous avons fini par arbitrer avec des valeurs approchées après discussion avec l’équipe et les alumni. Ce n’était pas un renoncement à la rigueur ; c’était une décision d’ingénierie à l’échelle de l’expérience.
La suite a consisté à déplacer le moteur, à rapprocher le mécanisme d’une implantation plus réaliste et à reprendre la conception autour de ce compromis. J’en retiens une règle simple : une solution élégante isolée ne vaut pas grand-chose si elle ne respecte pas le système dans lequel elle doit vivre.
Passer du modèle à la pièce
Robo’Lyon m’a aussi fait apprendre la chaîne qui relie une intention mécanique à une pièce fabriquée. Les dossiers CAO gardent des versions, des assemblages, des plaques, des supports, des pièces d’intake, des exports de fabrication et des anciennes itérations. La saison 2024 conserve notamment un travail d’intake mené en binôme, avec plusieurs versions et des pièces de test. Je le présente comme un travail de binôme et d’équipe, pas comme une réalisation individuelle complète.
La fabrication ajoutait une autre couche de contraintes. Une pièce pensée dans Inventor ou Fusion devait devenir un plan, un export, une trajectoire CNC, parfois une pièce imprimée en 3D. J’ai appris à utiliser la CAO, à préparer des plaques pour l’usinage et à bricoler autour des limites du matériel. Les scripts Python autour du G-code racontent bien cet état d’esprit : automatiser de petits gestes répétitifs, vérifier des séquences, sécuriser une hauteur de déplacement, remettre une machine dans un état attendu.
Cette partie de l’expérience est importante parce qu’elle m’a sorti d’une logique où le travail s’arrête au fichier. Un modèle peut être propre et rester inutilisable. Une trajectoire peut être générée et demander encore des contrôles. Une pièce peut être usinée et révéler que le problème était ailleurs. Ce rapport direct au résultat m’a donné un réflexe que je garde dans mes réalisations logicielles : regarder tôt ce que la solution devient quand elle rencontre son environnement réel.
Relier le terrain et les données
Robo’Lyon a aussi ouvert un terrain plus proche de l’informatique avec Scoutmate. Autour d’une compétition FRC, le scouting sert à capter ce qui se passe pendant les matchs : actions, scores, comportements d’équipes, éléments utiles pour préparer les décisions suivantes. L’application que j’ai travaillée reposait sur une logique simple : saisir les événements d’un match, enregistrer les scores, produire des statistiques et exporter les données pour les exploiter ensuite.
Ce n’était pas un produit sophistiqué, mais le besoin était réel. Il fallait une interface assez rapide pour être utilisée dans le rythme d’une compétition, une structure de données cohérente avec le jeu, et une restitution qui aide l’équipe à regarder autre chose que des impressions. Les évolutions se sont concentrées sur l’interface, les statistiques, les scripts et l’organisation de l’outil.
Cette brique m’intéresse parce qu’elle relie deux dimensions de l’expérience. D’un côté, le robot physique, ses mécanismes et ses contraintes. De l’autre, l’information qui circule autour des matchs et qui aide l’équipe à décider. Même dans une expérience de robotique, le logiciel devient utile lorsqu’il s’ancre dans un usage précis.
Ce que l’expérience m’a appris
Le recul que je garde de Robo’Lyon n’est pas seulement technique. J’y ai appris le travail d’équipe, la nécessité d’aller au bout d’une réalisation et l’importance de réfléchir avant d’agir. J’y ai aussi vu ce qui fragilise une réalisation collective : une communication insuffisante entre mécanismes, une répartition de charge parfois déséquilibrée, ou une envie d’avancer vite qui peut faire sauter l’étape de cadrage.
Ces limites font partie de l’intérêt de l’expérience. Sur l’intake, l’erreur n’était pas d’avoir essayé plusieurs versions ; elle était de comprendre trop tard que certaines contraintes auraient dû guider la conception dès le départ. Sur Scoutmate, l’enjeu n’était pas d’empiler des écrans ; il était de donner à l’équipe une donnée exploitable dans le contexte d’une compétition.
C’est aussi une expérience où la collaboration reste visible dans le travail lui-même : points CAO, retours de mentors, discussions avec des alumni, intégration avec les autres mécanismes et arbitrages collectifs.