RicE wrote:OK, c'est la nostalgie de notre première participation
J'avoue, mais moi c'était même l'année précédente avec les palets.
Les réglements de l'époque avaient un avantage : pas besoin de roues de codeuses. Tout était un peu aléatoire, et il était donc plus intéressant d'avoir un capteur qui dis qu'on est devant un palet en se balladant chaotiquement, plutôt que de savoir où on était. Les roues codeuses donnaient cependant l'avantage de pouvoir de mieux se positionner pour viser les palets en hauteur ou le fond du filet du rugby. J'ai l'impression que les derniers réglements sans aléatoire ont imposé les roues codeuses comme solution de facto pour avoir un robot performant ?
Sinon, pour en revenir au coconut rugby, c'est à ma connaissance le premier reglement à avoir autorisé 2 vrais robots ("vrai" au sens robot complet et pas petit PMI comme avant), cependant ça avait été fait de façon différentes des réglements suivants : le petit robot était seulement dans la zone d'enbut pour faire le role de gardien, et dégager les points marqué par l'autre équipe. Donc 4 robots sur la table, mais seulement 2 pouvant entrer en collision au centre.
Par contre, la coopération était limitée, car les 2 robots d'une même équipe étaient chacun dans leur zone, a réaliser des actions différentes. En ça les réglements avec les deux robot "a égalité" sur la table donne plus de possibilitées.
RicE wrote:C'est devenu plus compliqué pour les équipes de construire des robots, ça a eu tendance à disperser l'énergie (on essaye de faire un maximum d'actions et du coup aucune n'est fiable la plupart du temps)
Après les moyens techniques ont aussi évolué depuis 2004. On n'avais ni raspberry pi, ni imprimante 3D. La moindre carte electronique était en composant traversant, avec souvent un PIC16F84 au mileu (ça change du STM32

) voire en PC104 avec des cartes maison sur bus ISA. On se faisait nos ponts en H en composants discret (et perdait des nuits à remplacer les transistors qu'on avait fumé...). Il fallait acheter une CMUCam pour tenter de la reconnaissance d'images. Etc...
Il est donc plus facile maintenant de faire une IA qui va pouvoir choisir entre 2 actions de jeu lorsque l'on rencontre l'adversaire, d'integrer des minuscules cartes de controle moteur un peu partout pour intéragir avec les différents élements, faire des chaines d'AX12 avec les supports fournis, faire du traitement d'image en OpenCV avec une raspberry pi, ou simplement le faire complétement en légo !
Il n'est donc pas inconcevable que la complexité du réglement ait suivi cette évolution.
Après, quand on n'est pas mécano dans l'âme, et ben avec ou sans imprimante 3D, ... on n'est pas mécano
RicE wrote:Bien entendu, tout ceci est purement subjectif.
Totalement
