2018 - Robotech Legends

[Riako]

Bonjour à tous,

J'inaugure cette partie du forum pour l'année 2018 ! (PREUMS )

Ici nous posterons l'avancement de notre travail, au cours de son avancement. Enfin, on va essayer !
J'avais ordonné à l'un de mes camarades de le faire plus tôt, apparemment je vais devoir investir dans un nouveau fouet

L'équipe
Nous sommes 5, d'âges différents et provenant de régions différentes.
Nous nous sommes rencontrés à l'école d'ingénieur Polytech Montpellier (située à... Montpellier !), plus exactement dans son club de robotique qui présente elle aussi une équipe, Robotech Montpellier.

Puis après quelques coupes, le monde professionnel nous a appelé les uns après les autres mais nous sommes tous restés travailler sur Montpellier, et nous avons continué d'aller au club.

On a créé une deuxième équipe nommé Robotech Legends d'abord pour le fun en 2015 -> http://www.robotech.univ-montp2.fr/wp-c ... OS5923.jpg http://www.robotech.univ-montp2.fr/wp-c ... OS6071.jpg !

Puis, après discussion et quelques soucis dus à une équipe trop grande et avec une trop grosse différence de niveau (les petits avaient du mal à suivre lorsque les grands fonçaient tête baissée #cdr2016), nous (les anciens) avons décidé de laisser les étudiants pour monter une vrai seconde équipe.

Avec Robotech Legends nous pouvions poursuivre sur notre lancé et laisser le club aux les étudiants pour la découverte.

On a le droit de squatter les locaux de Polytech et une partie de leur outillage, en échange de quoi on porte leurs couleurs.

L'organisation de l'équipe :
- Blabla - Electronique - Miss poster
- Drovah - Electronique - Trésorier
- Manta - Mécanique, électronique et informatique cette année - Communication (quand il veut bien travailler )
- Marmotton - Mécanique, électronique, informatique - Homme à tout faire
- Riako - Informatique, pas électronique cette année par fainéantise - Dictateur (et chef d'équipe optionnellement)

Le palmarès :
Robotech Legends :
- 2017 : 2ème - quarts de final
Robotech Montpellier :
- 2016 : 80ème
- 2015 : 3ème - huitièmes de final
- 2014 : 12ème - huitièmes de final
- 2013 : 53ème
- 2012 : 62ème
...et je n'ai pas trop de données pour l'avant 2012...

La coupe 2018
Pour cette année, on part sur un seul robot (la crise, toutçatoutça, on était déjà à un robot et demi l'an dernier https://pbs.twimg.com/media/DBlQccTWsAA1MhH.jpg:large), qui fera tout.

Donc un seul robot qui récupère les balles, qui les envoient / déposent dans les bacs, et des petits bras pour gérer les cubes (on commence à plutôt bien les gérer http://www.robotech.univ-montp2.fr/wp-c ... OS6126.jpg et https://pbs.twimg.com/media/DBlTWcYXYAAQo1y.jpg ). Les bras serviront très probablement à faire tout le reste (panneau domotique, abeille).

La mécanique
La motorisation de notre robot principal est très classique : les roues de propulsions et les roues codeuses libres sont sur axe central avec une bille porteuse à chaque coin.
Nos moteurs sont des moteurs de type brushless (Faulhaber 2444 024 B).
La structure en elle-même est composée d'un bâti de 4 mm en ALU avec des profilés de 15 mm qui nous servent à fixer nos actionneurs. Une dernière plaque d'ALU pour le toit et on a la base de notre robot.
C'est une structure "simple" mais on la recommande pour les nouveaux : les profilés peuvent s'acheter pré-découpés sur mesure, vous pouvez alors fixer ce que vous voulez dessus, et si vous faîtes des jolis yeux au pôle mécanique de votre université ils vous feront le bâti et le toit.

Une petite vu sous SolidWorks pour vous montrez l'av... euh... une face :


Et une photo de l'arr... de l'autre face en cours de réalisation :


Dans l'équipe, on a toujours eu des soucis avec l'avant, l'arrière, la gauche et la droite, ne rigolez pas on est ingénieurs

Une petite vidéo pour les curieux : https://twitter.com/robotech34/status/9 ... 1731795971

Pour la détection des adversaires, une balise munie d'un bande réfléchissante est positionnée sur les mâts robots opposants, et une tourelle rotative composée de 2 capteurs photoélectriques située sur notre mât permet de détecter ces balises :

Et puis ça nous sert aussi à justifier l'affichage POV https://pbs.twimg.com/media/C8qYZaMWsAAh1eB.jpg:large

L'électronique
Notre électronique est un poil plus perfectionnée que notre mécanique (on vient tous de la formation électronique...).
On fait le développement et on soude les cartes nous-même. Je n'ai pas de photos sous la main, j'en mettrai plus tard.

Comme chaque année depuis les mammouths, notre robot possède une architecture décentralisée sur bus CAN.
Nous avons notre propre protocole, qui nous permet l'échange de données, l'envoie d'ordre, l'adressage dynamique (un peu comme le dhcp, mais en trèèèèèèèèès simplifié), bootloader, messages textuels, et musique (sisi, ça en faisait parti !), et le tout en même temps avec les priorités .

Pour les curieux toujours, ça c'était l'an dernier : https://twitter.com/robotech34/status/8 ... 4990773248
Je le referai plus tard pour cette année, quand on en saura plus nous même

Le (très) gros avantage d'une telle architecture est qu'un problème est très facilement isolé, est qu'on peut travailler sur des cartes différentes sans se taper dessus. Et puis comme on aime bien les LED de débug (qu'on recommande FORTEMENT à tous le monde : une LED pour chaque tension, une LED de vie, une LED d’activité) ça fait sapin de Noël, c'est joli.
Un autre gros avantage est qu'on peut récupérer les cartes des années précédentes. On fait de la récup', on est en accord avec le thème !!!

L'informatique
Sur la carte principale on a FreeRTOS, autrement c'est du tout fait maison sur les autres cartes.

Si vous êtes sages, je posterai le protocole CAN de ces dernières années (on est à la version 3.1).

Pour les trajectoires, on utilise des courbes de Béziers... depuis les mammouths aussi (ils nous avaient bien inspirés ces mammifères !).

Pour ce qui est de l'algorithme de recherche de chemin et bien... heu... ben le responsable de la carte maître à fait un algo de test en se disant qu'il optimiserait le tout plus tard... c'était il y a trois ans... ça na pas trop bougé aux dernières nouvelles...


Voilà, c'est tout pour aujourd'hui !

Là où on est (un peu) plus actif : https://twitter.com/robotech34?lang=fr

Bisous !

[chtit_tom]

C'est super de voir ce que vous faites. Je suis presser de lire la suite !

[Manta]

Bonjour tout le monde,

On n'a pas trop posté ici depuis le post initial, je profite de la deadline passée pour présenter notre poster !
On a eux pas mal de problèmes pour la récupération des balles, alors on a revu complètement la mécanique de récupération.
À la place d'une simple rampe complètement passive, on est passé sur une récupération à base de barillet horizontal ce qui permet de traiter chaque balle unitairement.

Dès qu'on aura des vidéos potables je vous posterai tout ça, mais de ce que je peux vous dire, c'est que ça fonctionne et heureusement, car c'est la 5e version !
(Je pense que le mécano de cette partie commençait à dérailler )

Poster :

Poster Robotech Legends - 2018

Affiche_Robotech_Legend_2018.png (5.12 MiB) Viewed 8145 times

Bonne journée !

[Riako]

Bonjour tout le monde,

Désolé pour la mise à jour tardive.
Comme dit précédemment, on a eu pas mal de soucis pour récupérer les balles
Mais on a trouvé une solution qui semble ENFIN fonctionner. Une petite vidéo pour illustrer ça :


Les balles sont récupérées dans un barillet, où elles sont gérées et promenées une par une, donc normalement plus de blocage car ces satanées balles accrochent la moindre paroi fixe qu'elles trouvent...
Ensuite elles sont triées, puis envoyées dans un canon formé par 2 roues en rotation rapide (moteur brushless). La vitesse de rotation sera adaptée à la distance qui sépare le robot et l'objectif; on devrait être capable d'effectuer des tirs longue portée (ou pas ).
On peut précharger jusqu'à 4 balles dans le canon avant de les tirer (comme sur la vidéo). On aurait pu les tirer une par une mais on perdrait trop de temps, là le préchargement peut se faire en parallèle d'autres actions (et puis le tir en rafale c'est cool ).
Au final on mettra (théoriquement) plus de temps à récupérer les balles qu'à les tirer (en supposant que le tri ne bloque pas le robot).

Maintenant que ça fonctionne on va pouvoir tester et tenter de fiabiliser la récupération et la gestion des balles, en attendant que le gars chargé des bras (un certain Riako, il paraît) fasse son travail

Si vous avez des questions en attendant la suite

Bisous !

[Riako]

Nouvelle vidéo !

Les bras fonctionnent !


On me pose souvent les questions lors de la coupe, alors je vais donner directement les réponses ici :

Quels servomoteurs utilisez-vous ?

On utilise des Herkulex de Dongbu (qu'on qualifie d'"actionneur intelligent"). Il existe d'autres fabricants d'actionneurs de ce type, mais on a initialement pris ceux-là car ils étaient de petite taille.

Utilisez-vous la version plastique (moins chère) ou métal ?

On avait des plastiques. Je les ai presque tous grillés. La mécanique est trop fragile et le moteur ne supporte pas nos méthodes...

Les avez-vous modifiés ?

On a retiré l'électronique qu'ils avaient pour mettre la nôtre, avec bus CAN, asservissement courant (très utile dans certains cas, comme pour nos pinces de l'an dernier https://www.youtube.com/watch?v=5xckZuLVVYA) et d'autres fonctionnalités plus ou moins utiles (https://www.youtube.com/watch?v=ptDj29cdcdU) contrôlées par une STM32.
La carte en question :
https://pbs.twimg.com/media/DAYnhACWsAAiZtP.jpg

Mais... Pourquoi ?? Vous êtes fou !

On a jamais prétendu être sain d'esprit
Le contrôle courant manquait énormément, et puis la communication UART, berk

A la prochaine !

[Riako]

Bonjour tout le monde,

Au cas où vous l'auriez manqué, nous avons remporté la coupe cette année, et atteint la 3ème place à EUROBOT !!!



Nous remercions encore une fois celles et ceux qui nous ont aidés et supportés tout au long de cette coupe ! Nous avons grandement apprécié les encouragements lors des finales françaises et d'EUROBOT <3

Vu que nous n'avons pas été très actifs pour communiquer cette année, nous posterons durant l'été quelques éléments sur nos robots (parce que oui avant la coupe il n'y en avait qu'un, le petit robot surprise était une surprise pour nous aussi, mais j'en reparlerai plus tard ).

Comme l'an dernier, j'ai fait des schémas pour représenter l'architecture (point de vu logiciel) de notre robot :



Une grosse partie des cartes datent de l'an dernier voir d'il y a 2 ans pour les cartes ascenseurs. Les seuls nouvelles cartes sont la carte pompe, la carte alimentation (qui est une version simplifiée de celle de l'an dernier) et la carte lanceur (nommée ici carte divers v2, c'est une copie de la carte divers avec des entrées I²C pour les capteurs de couleur).

Au total :
- 23 actionneurs
- 14 microcontrôleurs (1 x STM32F7, 5 x STM32F405, 8 x STM32F042, et un gros merci à ST qui nous les a fournis gratuitement )
- 3 bus CAN : 1 principal et 2 secondaires, comme l'an dernier

Point de vue hiérarchique... C'est confus :
- La carte pompe est gérée par les 2 cartes ascenseurs des bras
- La carte divers (les servomoteurs pour le stockage des cubes) est aussi gérée par les 2 cartes ascenseurs des bras
- La carte divers v2 (le lanceur) est gérée par la carte ascenseur du barillet
- Les bras peuvent se donner des ordres entre eux
- La carte principale ne discute pas avec toutes les cartes en plein match

Je me suis amusé à faire la même chose pour le robot secondaire, je vous laisse constater la complexité de cette bête de technologie (#ironie) :



Si vous avez des questions, nous pouvons y répondre

[arno]

Jolie archi !
La gestion des versions du code source pour 14 microcontrôleurs dans le même robot doit bien occuper

Pour commencer avec les questions, j'en ai 2 qui me viennent comme ça:
* à quoi vous sert le magnétomètre de la carte pupitre de commande ?
* la vue du bus CAN principale est elle schématique ou conforme à la réalité ? La topologie en étoile n'est pas recommandée pour l'immunité des signaux, et une topologie en bus est recommandée (comme représenté sur les bus secondaires), même si dans la pratique c'est plutôt résistant. Je pense à ça suite aux discussions sur l'I2C d'il y a quelque temps sur ce forum.

Sinon, j'aime beaucoup les remarques comme "Les bras peuvent se donner des ordres entre eux"
J'ai un peu de mal à voir comment tout ça s'organise en pratique, mais on peut dire que ça marche du tonnerre vu les résultats !

[Riako]

Jolie archi !
La gestion des versions du code source pour 14 microcontrôleurs dans le même robot doit bien occuper

Merci !

En fait pas tant que ça :
-> Il y a effectivement 14 puces, mais les servomoteurs ont tous le même code, les bras ont le même code aussi, donc on tombe à 10 projets différents.
-> On utilise que 3 références de puces : STM32F042 pour les cartes à fonctions "simples", STM32F405 pour les cartes avec une gestion un peu plus complexe et/ou avec bus secondaire, et la STM32F7. Vu qu'on a les mêmes références, la base du code (communication série, communication CAN, gestion des périphériques) est quasiment identique sur les cartes usant le même microcontrôleur.
-> On a développé dans certains cas nos propres librairies bas niveau pour que la structure du code reste la même pour toute les cartes (et parce qu'on est pas fan des librairies mises à disposition pour les STM32 ). J'ai par exemple un code identique pour gérer le CAN quelque soit la carte, les seuls différences seront quand l'ordre envoyé est spécifique à la carte (et les filtres pour l'identifiant du message).
-> Certaines cartes ne sont pas de cette année, on a réutilisé ou adapté du code existant des années précédentes.

* à quoi vous sert le magnétomètre de la carte pupitre de commande ?

On a fait l'an dernier une tirette avec aimant + magnétomètre. Les années précédentes on avait utilisé un ILS puis un capteur effet hall mais on était dépendant du sens de magnétisation... Même en faisant attention si on devait changer l'aimant en urgence c'était compliqué. On est passé sur le magnétomètre pour être sur que ça marche, quelque soit la position de l'aimant, s'il est bien centré ou pas, sa force, si le tireur est sobre ou pas. Mais on a eu des soucis avec le capteur à quelques semaines de la coupe. On a fini par remettre une prise jack sur le toit, c'est pas le plus pratique mais ça marche...

* la vue du bus CAN principale est elle schématique ou conforme à la réalité ? La topologie en étoile n'est pas recommandée pour l'immunité des signaux, et une topologie en bus est recommandée (comme représenté sur les bus secondaires), même si dans la pratique c'est plutôt résistant. Je pense à ça suite aux discussions sur l'I2C d'il y a quelque temps sur ce forum.

C'est conforme à la réalité, oui tu as entièrement raison là dessus, et je faisais partie de la discussion sur l'I²C, étant le premier à râler
Mais le CAN autorise les segments qui s'éloignent de la paire principale. Il existe des tableaux / formules qui donnent la longueur max de ces segments et ça peut faire plusieurs mètres.
https://www.onsemi.com/pub/Collateral/A ... %20DWS.XLS
Si on a choisi de faire comme ça, c'est parce qu'on a voulu faire qu'un seul câble avec CAN et puissance et que c'est pas bon de chaîner la puissance entre les cartes.
Avant on séparait CAN et puissance, mais c'était un calvaire pour câbler les robots...
On a des idées de faire des cartes fond de panier qui, elles, seraient chaînées, puis connecter les cartes au fond de panier le plus proche. On réduirait les segments sans bouchon et simplifierait alors le câblage.
On fait attention à ce que les paires soient correctement torsadées. Jusque là ça marche sans problème, même si les câbles passent au dessus des moteurs et autres machines à bruit.

Sinon, j'aime beaucoup les remarques comme "Les bras peuvent se donner des ordres entre eux"
J'ai un peu de mal à voir comment tout ça s'organise en pratique, mais on peut dire que ça marche du tonnerre vu les résultats !

Je vais tenter d'expliquer pour les bras, mais je vais commencer un peu plus loin pour faire l'historique :
L'architecture décentralisée nous permet d'obtenir un grand niveau d'abstraction sur la carte maître.
Par exemple la carte maître demande à un bras de "pousser l'abeille", le bras lui répond " ok je vais le faire", le fait et l'informe "j'ai fini" ou "j'ai échoué".
C'est valable pour à peu près toutes les cartes.

Par exemple, l'an dernier, pour prendre les cylindres sur le terrain on avait une commande "prends le module qui est à la position {X,Y}". La carte de l'ascenseur récupérait la position du robot envoyée par la carte de déplacement et, par un algo tout simple, on calculait l'angle à donner au servomoteur et la distance entre la pince et le module. De ce fait même si le robot était décalé de quelques cm par rapport à la consigne le bras chopait le module, et la carte principale n'avait rien à gérer !
Petite vidéo vu de dessus, à 50m44 on voit le bras de notre robot (en jaune, à droite) qui cible le module : https://youtu.be/mgrqNQTBRLU?t=50m40s
Une autre, pareil mais côté bleu à 2h22m21 : https://youtu.be/7Ay44QFUPXk?t=2h22m4s

Pour reprendre la commande des bras de cette année, les voici :

Code: Select all

/// List of actions
typedef enum
{
	CarteAscenseur_Action_None,                 // Do nothing
	CarteAscenseur_Action_Fold,                 // Folded position, to use when the robot is moving
	CarteAscenseur_Action_SwitchDown,           // LeD PoWeR!!
	CarteAscenseur_Action_SwitchUp,             // Disable oponent's panel (Mouwahahahaha)
	CarteAscenseur_Action_HoneyBee,             // Help the Bee to reach the flower!!
	CarteAscenseur_Action_ReleaseTower,         // Open the door, will be closed after calling None action
	CarteAscenseur_Action_ReleaseGolden,        // Release golden cube in tower
	CarteAscenseur_Action_BuildTower,           // Take the cubes to build the tower
	CarteAscenseur_Action_SlaveBuild            // RESERVED - DO NOT USE
} CarteAscenseur_Action_e;

Là c'était un poil plus complexe : la carte principale demandait à un bras "vas-y, construit" (BuildTower), la carte ascenseur calculait quelle tas de cube du terrain il avait en face de lui, le décalage et l'orientation qui devait compenser (le robot pouvait arriver comme il veut par l'une des 4 diagonales ça marchait), quelles pièces il lui manquait en stock pour construire une pile en respectant le paterne et quelle bras devait commencer. Il donnait ensuite les instructions au deuxième bras (SlaveBuild, elle est marquée comme réservée car pas censée être appelée par la carte principale) pour que les bras prennent les pièces l'un après l'autre afin d'optimiser le temps.
Avec cette méthode on avait besoin de 2 tas de cubes pour monter 2 tours, un seul tas ne nous permettait pas de monter une tour (sauf si on utilise le golden cube, comme on l'a fait lors des finales).

Bon, vu que j'ai fini de programmer la dernière nuit et qu'on a du refaire une calibration rapide de l'odométrie cette même nuit, le fait de ne pas avoir beaucoup testé et d'être décalé de plusieurs cm après avoir fait 2 fois le tour du terrain faisait que c'était pas fiable...
Le robot était pourtant capable de trier les balles de couleur en faisant autre chose et de tirer de n'importe où quand il en avait l’opportunité. On pouvait donc paralléliser les actions et pas attendre comme on l'a fait durant les match de final, mais comme on avait trop de problèmes sur l'odométrie on a décidé de ce concentrer sur les balles et de ne faire les cubes qu'en bonus à la fin. D'après nos calculs, on aurait pu dépasser les 350 points si on avait fait 2 tours avec l'estimation juste (avec un seul robot ) et en étant pas trop perturbé sur le match...

Petite remarque au passage : si on ratait un cube on lâchait le golden à la place. J'ai peut-être mal vu, mais je n'ai pas vu beaucoup d'équipe le faire ? (C'est marqué "JOKER" en gros dessus dans le règlement)
(autre petite remarque : le robot pouvait désactiver le panneau de l'adversaire, mais on ne l'a jamais tenté)

Bon, après cette coupe, est-ce que c'était nécessaire de programmer une gestion des cubes aussi compliquée ? Je ne sais pas, mais ça m'a bien amusé et ça a grandement soulagé le programmeur qui s'occupait de la carte principale.

J'espère que c'était assez clair comme explication

[pioupiou]

Bonjour,

félicitations à vous.

Si c'est possible j'aimerais bien en savoir plus sur votre évitement/detection, car on a pu voir que votre gros robot était particulièrement bon à ce sujet. Il faisait preuve d'une grande finesse qui donne envie. Quelles sont les capteurs utilisés ? Est-ce qu'il y a des a des particularités dans vos algorithmes pour arriver à de telles performances ? Quelles sont les améliorations depuis l'an dernier (j'ai l'impression que le bond que vous avez fait entre les deux dernières éditions est surtout du à la qualité d'évitement ) ?

[Riako]

Bonjour et merci !

Je vais peut-être détruire quelques mythes à propos de notre évitement, qui est loin d'être parfait comme le laisse penser notre prestation de cette année...

Pour commencer, l'"évitement" d'un adversaire regroupe plusieurs éléments :
- détecter un obstacle
- estimer la position d'un adversaire
- générer un chemin
- gérer l'adversaire

En réalité, nous ne réalisons que 2 de ces points...

L'idéal serait de gérer l'adversaire : faire de la génération de "trajectoire" dynamiquement avec une prédiction des actions des opposants, mais c'est un travail de colosse...

Détecter un obstacle, beaucoup d'équipes le font avec des capteurs ultrason/optique/autre sur l'avant et l'arrière du robot. Nous ne le faisons pas (même s’il faudrait le faire, je reviendrai plus tard là-dessus).
Le problème avec la détection simple d'obstacle, c'est qu'on ne couvre pas bien l'environnent autour du robot et qu'il est difficile d'estimer la position de l'adversaire.
Estimer la position de l'adversaire, c'est ce que nous faisons avec notre système (cf. plus haut). Nous obtenons la position du robot adverse assez précisément, mais nous n'avons malheureusement pas sa forme.
Le problème avec l'estimation de la position seule, c'est qu'on n'a pas la forme du robot adverse, et donc on est pas sûr qu'on puisse passer à côté.
L'idéal serait d'avoir les deux solutions combinées, c'est du travail supplémentaire mais nous cherchons à le faire.
Les solutions lidar seraient géniales pour ça, certaines équipes les utilisent, mais ça coûte un peu notre budget annuel (qui vient en partie de notre poche) et ça demande du travail, des compétences et du temps supplémentaire (cette année on est arrivé avec un robot pas entièrement programmé...).
Actuellement ce qui fait notre force c'est la génération de chemin et la capacité à s'adapter à l'adversaire.

Pour générer un chemin proprement, on a besoin de la position des robots adverses et de leur forme. Pour générer un chemin un peu moins optimal mais avec moins de moyens, on se contente de la position en donnant une forme théorique à l'adversaire (un rond de diamètre variable, selon la vitesse et l’humeur du robot).
Notre robot estime la position des autres robots sur le terrain, génère une trajectoire qui les contournes, et c'est parti. Pendant le déplacement on vérifie si des obstacles non pris en compte dans le chemin apparaissent en projetant un robot virtuel vers l’avant (un carré) et en testant sa collision avec le robot adverse estimé (un rond). S'il faut s'arrêter, le robot s'arrête et génère une nouvelle trajectoire.
Dans l'idéal le robot évite les obstacles sur le terrain (cette année, les cubes). S'il ne peut pas passer, il retire virtuellement ces obstacles, réduit les marges d'évitement du terrain, réduit sa vitesse max et génère une nouvelle trajectoire (c'est pour ça qu'il avait tendance à passer au travers des tas cubes si on le perturbait...). S'il ne trouve toujours pas de solution, il change de mission.

(j'ai l'impression que le bond que vous avez fait entre les deux dernières éditions est surtout du à la qualité d'évitement )

Le système et les algorithmes d’évitement sont identiques à ceux de l'an dernier (on a juste rajouté 1cm de marge sur la taille des robots adverses) ! L'évolution de cette année c'est que la gestion des missions ne plantait plus quand il ne trouvait pas de chemin... C'est ce qui nous avait coûté chère aux quarts de finale...
Une évolution possible serait que le robot soit plus conscient de sa propre géométrie (et bien sûr de celle de l’adversaire, mais c’est dur) ... Il a plusieurs fois bien détecté qu'il ne pouvait pas bouger mais tourner sur lui-même là il ne calcul rien... (https://youtu.be/qMOzlV9TB9M?t=2h10m53s).

Il nous reste encore du travail pour améliorer tout ça !

[pioupiou]

Je vais peut-être détruire quelques mythes à propos de notre évitement, qui est loin d'être parfait comme le laisse penser notre prestation de cette année...

Effectivement, j'ai pu me faire leurrer par quelques coups de bol. Je suis surpris quand vous dite que vous ne détectez pas la forme du robot. D'après les vidéos que j'ai vu, vous évitez vraiment au plus juste comme ici : https://www.youtube.com/watch?v=qMOzlV9 ... t=3h25m26s . J'ai l'impression que votre trajectoire ne vous permettais pas d'éviter un gros robot ici, vous êtes déjà très près pour un petit robot. De plus, vous avez montré que quand il fallait éviter un gros robot comme celui de l'UNICT ou celui des 7 monsquetaires, vous saviez le faire, avec a peu près autant de finesse. Donc c'est vraiment rien de plus que des coups de bol ?

Quant à la gestion des cas d'erreur on est bien d'accord sur le fait que c'est souvent fatal en phase finale et AIGRIS a été très bon pour profiter de vos failles

[Riako]

D'après les vidéos que j'ai vu, vous évitez vraiment au plus juste comme ici : https://www.youtube.com/watch?v=qMOzlV9 ... t=3h25m26s . J'ai l'impression que votre trajectoire ne vous permettais pas d'éviter un gros robot ici, vous êtes déjà très près pour un petit robot.

Dans cette vidéo là, ce n'est pas notre robot qui passe près du petit d'ESEO, c'est actuellement leur petit robot qui s'arrête bien après le notre et c'est donc lui qui se rapproche ! Pour le contournement, le robot reste près du petit quand il se dirige vers le publique, mais là c'est dû au précédent rapprochement du petit. Enfin, lorsque le robot longe les stations, l'angle de la caméra est trompeur car il y a de l'espace entre les deux robots.

Donc c'est vraiment rien de plus que des coups de bol ?

Oui et non Le support de balise du robot italien est un peu vers l'avant du robot, ce qui nous aide pas, c'est pour ça qu'on le rase de près. Mais même avec une balise décentrée et un robot large, ça passe. Un peu avant il y a une collision car les robots arrivent côte à côte. Et ce problème de bras qui dépassent... Mais à la première rencontre entre les robots on s'arrête à une bonne distance avant de changer de direction.
Lors du match contre les belges, on s'arrête aussi très tôt. Le rapprochement des deux robots à la fin de la manœuvre est dû à une rotation du robot belge vers le notre.

Dans la très grande majorité des cas, les autres robots rentrent dans le gabarit utilisé pour l'évitement. Ce qu'on craint le plus, c'est que le support de balise des robots de l'adversaire ne soit pas centré. Le règlement autorise un décalage assez grand :

• le support de balise embarquée devra être situé le plus au centre possible du robot en projection verticale, et
  obligatoirement dans un cercle de diamètre 20 cm autour du centre du robot.

Comme dit plus haut, on va tenter d'améliorer tout ça !

Quant à la gestion des cas d'erreur on est bien d'accord sur le fait que c'est souvent fatal en phase finale et AIGRIS a été très bon pour profiter de vos failles

Je ne pense pas que c'était volontaire de leur part, ils sont surtout venus prendre les modules qu'on utilisait pas
De plus on était au courant de ce bug la veille, mais on a préféré boire au lieu de coder La coupe c'est aussi pour s'amuser

Effectivement, j'ai pu me faire leurrer par quelques coups de bol.

Alors, pas trop déçu ?

[pioupiou]

Alors, pas trop déçu ?

Ba si, je pensais que vous étiez des monstres avec une qualité de détection hors normes (je pensais que vous saviez au moins faire la différence entre un petit et un gros robot) pour en arriver à ces résultats exceptionnels .

Petites questions supplémentaires :
- Quelle est la solution que vous utilisez pour lâcher les cubes ventousé ? (Pompes réversibles, électrovannes, trou dans les tuyaux, ...) si vous avez une référence je la veux bien.
- Dans votre modélisation, j'ai l'impression que sur votre pompe vous avez 2 sorties pour un seul moteur. J'ai bien raison ? si oui je veux bien la référence aussi

[Riako]

Notre détection n'est pas parfaite, mais on la maîtrise bien, et le résultat est là ! Certaines équipes ont des systèmes mieux adaptés, parfois une plus grande expérience que nous, pourtant, des chocs frontaux en phase finale, on en voit toujours !

Je n'ai pas les références sous la main (matériel de récupération en partie), mais je peux répondre en partie en attendant :
Notre circuit pneumatique est réalisé avec des tubes normalement prévu pour des liquides et pas de l'air. C'est plus souple mais ça s'écrase plus facilement, il faut faire attention surtout qu'une partie est mobile (guide câble des ascenseurs).
Notre pompe a effectivement 2 blocs séparés, entraînés par un seul moteur, soit une entrée et une sortie d'air par bloc. Le moteur est suffisamment puissant pour créer un vide suffisant au maintient d'un cube même si l'autre entrée est bloquée.
Pour lâcher la pièce on avait initialement pensé à créer une fuite avec une électrovanne, pensant que la fuite serait suffisante pour que le cube tombe. Raté. Elle tourne plutôt bien cette pompe !
Nous avons des électrovannes 3/2, dont le "commun" est relié à la ventouse. Pour la suite, soit la ventouse est connecté à la pompe et ça aspire, soit elle est connectée au vide et le cube tombe directement.
(Nous avons également fait un test avec une électrovanne 2/2 entre la pompe et la ventouse, mais la ventouse ne se décollait pas assez vite)
Les ventouses nous ont été généreusement offertes par Piab (merci sponsor ).

[arno]

J'espère que c'était assez clair comme explication

Parfait !

Par exemple, l'an dernier, pour prendre les cylindres sur le terrain on avait une commande "prends le module qui est à la position {X,Y}". La carte de l'ascenseur récupérait la position du robot envoyée par la carte de déplacement et, par un algo tout simple, on calculait l'angle à donner au servomoteur et la distance entre la pince et le module. De ce fait même si le robot était décalé de quelques cm par rapport à la consigne le bras chopait le module, et la carte principale n'avait rien à gérer !

Donc vous faites tout en coordonnées prédéfinies, sans capteur pour vérifier si les blocs sont bien à cette position ?

On a des idées de faire des cartes fond de panier qui, elles, seraient chaînées, puis connecter les cartes au fond de panier le plus proche. On réduirait les segments sans bouchon et simplifierait alors le câblage.

Une technique habituelle pour garder un branchement en étoile des câbles (chaque carte se branche directement au fond de panier), mais conserver un bus en ligne, c'est d'avoir 2 paires CAN dans le câble pour que le bus parte à la carte et revienne avant d'aller à la carte suivante. Ça nécessite d'utiliser des bouchons sur le fond de panier pour les connecteurs non utilisés, et double le cuivre, mais c'est parfois plus simple à utiliser. Dans tous les cas, le bus reste bien résistant à l'échelle d'un robot. Merci pour la fiche de calcul, je ne connaissait pas, en général j'utilise les préconisations des specs CanOpen qui sont des valeurs parfois conservatives mais garantie de fonctionner.