2019 - Robotech Legends

Partagez votre expérience en expliquant comment vous travailler sur votre robot.
Share your experience by explaining how you work on your robot.
User avatar
Manta
Posts: 55
Joined: Sat 03 Oct 2015, 10:37
Contact:

Re: 2019 - Robotech Legends

Post by Manta » Mon 20 May 2019, 13:59

Bonjour tout le monde,

Je vous parlais précédemment de la modification de nos codeurs pour augmenter la fiabilité de notre odométrie donc voici notre nouvelle réalisation :

La modélisation 3D :
Image

Une animation pour avoir une vue en éclatée :
Image
Bon l'animation ne sert pas a grand-chose, mais je trouve ça classe ^^

La photo pour voir le tout en vrai :
Image

Si vous avez des questions, n'hésitez pas !
Manta et toute l'équipe de Robotech Legends !
Champions de France 2018, 3ème à EUROBOT 2018 :D

2017 à 2018 : Robotech Legends
2012 à 2016 : Robotech Montpellier

Suivez l'actualité de Robotech Legends :

Image Image Image Image

User avatar
Nirgal
Posts: 271
Joined: Mon 25 Oct 2010, 20:05
Contact:

Re: 2019 - Robotech Legends

Post by Nirgal » Mon 20 May 2019, 18:15

C'est assez proche de notre design, au détail près qu'on a préféré un système rotatif plutôt que linéaire.. en assumant l'imperfection. (le rappel au sol est effectué par un ressort).
Image

Mais ma question est ailleurs.
Nous observons des irrégularités au niveau du joint torique, qui s'avère difficile à positionner. Le collage semble irréversible, et on à parfois l'impression que le joint subit un glissement.
Vu ce que dit la théorie de ces irrégularité sur l'impact en odométrie, il va sans dire que c'est un impératif majeur.

Vous le collez ? Comment assurer un montage régulier ?
Nirgal
Robot-ESEO

User avatar
Manta
Posts: 55
Joined: Sat 03 Oct 2015, 10:37
Contact:

Re: 2019 - Robotech Legends

Post by Manta » Tue 21 May 2019, 10:11

Nirgal,

Nous n'avons jamais fait de comparatif pour savoir si le rotatif avait vraiment un impact négatif, mais on a toujours persévéré dans le vertical.
Pour ce qui est du joint torique, il n'est pas collé, il est juste mis dans une rainure à sa taille sans plus. Légèrement contraint en diamètre et en épaisseur. On aurait voulu tester une roue codeuse tout en aluminium comme nous l'a conseiller une autre équipe (j'ai un trou de mémoire, alors désolé pour "l'autre équipe", si elle passe par là n'hésitez pas à me rafraîchir la mémoire...), mais on a plus vraiment le temps et finalement avec le joint torique ça passe.

Manta
Champions de France 2018, 3ème à EUROBOT 2018 :D

2017 à 2018 : Robotech Legends
2012 à 2016 : Robotech Montpellier

Suivez l'actualité de Robotech Legends :

Image Image Image Image

User avatar
Nirgal
Posts: 271
Joined: Mon 25 Oct 2010, 20:05
Contact:

Re: 2019 - Robotech Legends

Post by Nirgal » Tue 21 May 2019, 10:17

ok merci.

Concernant la roue en alu, on m'en également dit le plus grand bien dans un autre contexte (où le sol est également en alu). Avec le vinyle, on a un peu peur d'usiner la table...
Mais cela fait partie des pistes de R&D.

Bonne dernière ligne droite et à très bientôt !
Nirgal
Robot-ESEO

User avatar
romain_cvra
PMI
Posts: 1234
Joined: Sat 30 Jun 2007, 16:17
Location: suisse
Contact:

Re: 2019 - Robotech Legends

Post by romain_cvra » Tue 21 May 2019, 11:49

Manta wrote:
Tue 21 May 2019, 10:11
On aurait voulu tester une roue codeuse tout en aluminium comme nous l'a conseiller une autre équipe (j'ai un trou de mémoire, alors désolé pour "l'autre équipe", si elle passe par là n'hésitez pas à me rafraîchir la mémoire...)
C'était surement nous :wink:
On utilise des roues codeuses tout en aluminium depuis quelques années maintenant. Cela fonctionne bien!
Nos roues codeuses on une zone d'appuis très fine, elles ont un petit rayon de 0.5mm qui appuie sur le sol.
Site web : http://www.cvra.ch.
Le code source : GitHub
Visualisation CAO 3D de nos robots : GrabCAD

User avatar
Augustin.B
Posts: 29
Joined: Thu 15 Nov 2018, 16:00

Re: 2019 - Robotech Legends

Post by Augustin.B » Tue 21 May 2019, 14:49

romain_cvra wrote:
Tue 21 May 2019, 11:49
Manta wrote:
Tue 21 May 2019, 10:11
On aurait voulu tester une roue codeuse tout en aluminium comme nous l'a conseiller une autre équipe (j'ai un trou de mémoire, alors désolé pour "l'autre équipe", si elle passe par là n'hésitez pas à me rafraîchir la mémoire...)
C'était surement nous :wink:
On utilise des roues codeuses tout en aluminium depuis quelques années maintenant. Cela fonctionne bien!
Nos roues codeuses on une zone d'appuis très fine, elles ont un petit rayon de 0.5mm qui appuie sur le sol.
Sur vos conseils on teste également cette méthode cette année, on fera un retour suite à la coupe, mais pour l'instant ça à l'air de bien fonctionner!

RCToulon
Posts: 73
Joined: Thu 05 Nov 2015, 13:04

Re: 2019 - Robotech Legends

Post by RCToulon » Sat 25 May 2019, 22:40

Magnifique petits blocs roue codeuse en tous les cas ! Bravo, on a hâte de voir vos robots :)
Valentin - Robot Club Toulon
http://rct.univ-tln.fr

User avatar
Manta
Posts: 55
Joined: Sat 03 Oct 2015, 10:37
Contact:

Re: 2019 - Robotech Legends

Post by Manta » Tue 28 May 2019, 17:07

romain_cvra wrote:
Tue 21 May 2019, 11:49
Manta a écrit : ↑mar. 21 mai 2019, 10:11
On aurait voulu tester une roue codeuse tout en aluminium comme nous l'a conseiller une autre équipe (j'ai un trou de mémoire, alors désolé pour "l'autre équipe", si elle passe par là n'hésitez pas à me rafraîchir la mémoire...)
C'était surement nous
Oui je pense que c'est vous ! Encore merci pour ce genre de tuyau !
RCToulon wrote:
Sat 25 May 2019, 22:40
Magnifique petits blocs roue codeuse en tous les cas ! Bravo, on a hâte de voir vos robots
Merci et une petite photo !

Image
Champions de France 2018, 3ème à EUROBOT 2018 :D

2017 à 2018 : Robotech Legends
2012 à 2016 : Robotech Montpellier

Suivez l'actualité de Robotech Legends :

Image Image Image Image

Riako
Posts: 89
Joined: Tue 05 May 2015, 18:07

Re: 2019 - Robotech Legends

Post by Riako » Fri 20 Sep 2019, 13:42

Bonjour à toutes et à tous,

Voici une mise à jour (trop) tardive, histoire de clôturer notre année 2019.
La communication a été délaissé lors de la coupe, et inexistante après cette dernière. Ça aura été une année un peu trop surchargée pour nous :o

Petit retour en arrière pour résumer notre année.

Suite à nos résultats de 2018, nous avons voulu prendre quelques risques pour se faire plaisir :D Voici la liste :
  • réaliser deux robots complexes ;
  • faire communiquer les robots ;
  • revoir l'algorithme de décision ;
  • revoir l'algorithme de recherche de chemin ;
  • (re)faire des servomoteurs personnalisés.
------------------------------------------------------------
Deux robots

Depuis 2017, première année où nous avons commencé (sérieusement) Robotech Legends suite à nos activités au sein de Robotech Montpellier, nous sommes venus à la coupe avec deux robots.
En 2017, le rebot secondaire était un robot fixe, dont les principales fonctions étaient de lancer la fusée et de faire basculer le minerai dans la soute (minerai apporté par le robot principale). Robot secondaire qui n'étaient pas prévu au début de l'année, mais dont l'idée n’a été validée qu’au milieu de celle-ci, durant l'hiver.
En 2018, le robot secondaire a été prévu... Lors des qualifications ! Initialement, nous avions amené une ancienne base d'un robot de 2014 pour nous occuper durant la coupe (et éventuellement en faire un robot pour la coupe-off). Composé de deux moteurs pas-à-pas, d'un capteur ultrason et d'une STM32 il a été présenté lors des finales, et ses uniques fonctions étaient d'appuyer sur l'interrupteur et de rester devant.

Toujours deux robots, certes, mais jamais deux robots complexes. C'était une volonté pour nous que de réaliser deux robots complexes, mais la taille de notre équipe (5 !) limite un peu. Pour simplifier la réalisation, nous étions partis sur deux robots identiques. Nous pensions réduire le temps de travail, mais ce n'est que la conception et qu'une partie du développement qui ont été réduites. Pas que nous n'avions pas prévu le temps de fabriquer deux robots, mais augmenter la charge "pénible" (de notre point de vue) a été un peu brise-moral...

------------------------------------------------------------
Communication et prise de décision

Faire communiquer deux robots, nous l'avions déjà fait.
En 2017, le robot principal informait le secondaire que son bac était plein, et ce dernier informait le premier qu'il était prêt, pas prêt ou bloqué. En cas de blocage, le robot principal allait donner un "coup d'aspirateur" pour nettoyer l'espace qui servait au robot secondaire pour déposer son bac.
En 2018, une caméra placée sur le support de balise au coin de la table transmettait le schéma de couleur à respecter pour les constructions. Il y avait également une communication avec le panneau domotique, pour détecter si quelqu’un avait ouvert l'interrupteur (puisqu'il n'y avait pas de robot secondaire de prévu).
Une communication assez "simple" au final (avec CRC, relance et acquittement).

Cette année, nous avons ajouté de la complexité dans la communication radio (et pas qu'un peu) :
  • échange de position ;
  • attribution des tâches (missions) dynamiquement ;
  • gestion des ressources (liste complète des palets, zones de récolte, zones de dépose et zone de départ).
Les tâches sont distribuées dynamiquement entre les robots, en fonction des ressources disponibles, aussi bien les ressources du terrain (les zones, les palets) que celles du robot (réservoirs, pièces disponibles) et de leurs besoins.

Petit explication rapide du fonctionnement :
  • L'un des deux robots est déclaré comme robot principal. Les deux robots ont des mâts de couleurs différentes.
  • Les robots communiquent leurs positions en permanence. Il était prévu qu'ils communiquent aussi la position des adversaires (la redondance est gérée depuis quelques années pour des raisons de fiabilité).
  • Le robot secondaire dispose d'une copie de la liste des tâches à faire et celle des ressources. Il détermine quelle tâche il veut prendre, et demande gentiment au robot principal s'il peut la réaliser.
  • Le robot principal répond positivement ou négativement, selon ce qu'il a prévu de faire.
  • Le robot principal n'a, en théorie, pas de problème pour s’entendre avec lui-même et décider de sa propre prochaine mission :lol:
  • Le code est identique sur chaque robot. C'est une seule condition, "principal" ou "secondaire", qui détermine son rôle.
  • En cas de problème, il est possible de ne laisser qu'un seul robot sur la table. Cette décision peut être prise lors des 3 minutes de préparation (et ça a été le cas). Un robot, même seul, est capable de réaliser toutes les actions.
  • Toutes les tâches sont accessibles pour le robot secondaire, à l'exception des conteneurs à six palets car ils demandent un déploiement trop grand pour un robot secondaire.
  • Le robot principal est donc "bridé" pour ne jamais dépasser le périmètre déployé d'un petit robot, sauf dans des tâches particulières. Bien que cela aurait pu être optimisé, ça commencerait à devenir une perte de temps, autant réaliser deux robots différents pour se passer des contraintes mécaniques.
  • Seul le robot principal compte les points indirects, tel que l'électron, l'expérience, l'activation de l'accélérateur et la récupération du goldenium.
En cas de perte de communication au cours de la rencontre... Et bien c'était un peu la roulette... Le robot secondaire avait pour ordre de se figer sur place, le robot principal connaissant la dernière position transmise pouvait l'éviter, en priant pour qu'il ne s'arrête pas devant une ressource importante... Ne disposant que de très peu de capteurs sur ces robots, nous n'avions pas la possibilité de détecter notre propre compagnon, donc pas de retour à la base possible. Le découpage en zone de travail n'avait que peu d'intérêt car on ne pouvait pas réellement optimiser les points de cette manière cette année, nous avons donc préférer nous concentrer sur le reste. Sur ce point ils nous restent beaucoup à faire.

Pour ce problème de perte de communication, je vous invite à aller voir ce que font les autres équipes (découpage en zone, détecteur de proximité par exemple). Tout ce que je peux vous dire c'est que nous n'avons pas eu de problème de communication (du moins pas lié directement à la radio en elle-même :lol: ).

------------------------------------------------------------
Recherche de chemin

L'algorithme de génération de trajectoire, ça faisait un moment que nous voulions le remplacer. Jusque-là nous avion un découpage du terrain en carrés de 2 cm de côté, soit une grille de 100x150, et nous utilisions une simple méthode itérative. La position des adversaires, comme déjà expliqué, est obtenue grâce à la tourelle et uniquement celle-ci.
Cette année nous avons utilisé une autre méthode, en passant en absolue plutôt qu'en discret. Tout obstacle est représenté par un polygone, même le bord du terrain.

Image

On commence d'abord par générer les objets à éviter : (1) les obstacles fixes (par exemple, les bords du terrain) ; (2) les robots ; (3) les autres obstacles (les éléments de jeu).
Note : les éléments de jeu sont pris en compte dans l'évitement en temps normal, mais si aucune solution n'est trouvée, ils sont retirés et le robot ne les évite plus (c'était déjà le cas avec l'ancienne méthode).
On procède ensuite à une fusion des objets en collision. Cela permet de réduire les calculs et d'éviter les erreurs du type "je passe au travers de deux objets".
Ensuite, on teste si entre le point de départ et le point d'arrivé il y a collision avec un objet, si oui on le contourne en suivant le bord, puis on teste les nouvelles possibilités jusqu'à obtenir une liste de trajectoires qui passent au plus près des objets, mais toujours en ligne droite dans les grands espaces. On prend la plus courte et on la transforme en liste de courbes de Bézier, liste qui est transmise à la carte gérant les déplacements du robot.

L'avantage de cette méthode par rapport à l'ancienne, c'est qu'elle prend beaucoup moins de place mémoire et est plus précise : en discret, l'espace mémoire limite la taille du tableau, et donc la précision (bien que 2 cm c'est suffisant et que notre implémentation aurait pu être améliorée). De plus, elle est plus rapide car même si les formules sont plus complexes, le nombre d'itérations est assez faible et la mise à jour de la carte est plus simple (c'est dépendant du nombre et de la complexité des polygones, et de l'optimisation :roll: ).

------------------------------------------------------------
De nouveaux servomoteurs

12 servomoteurs par robot, soit 24 servomoteurs au total. Nous n'avions pas assez d'herkulex modifiés, et la mécanique trop fragile de ces derniers ne nous convenait pas. Le prix de la version métal étant trop important, nous avons décidé de changer de base, en prenant des servomoteurs à commande classique (on change l'électronique, donc la commande ne nous intéresse pas).
Vu qu'il y a pas mal de choses à dire sur ces servomoteurs et sur les bras, nous ferons une présentation plus détaillée un peu plus tard.

Je vous laisse quand même ces vidéos pour vous montrer le résultat "vue de près" :
https://twitter.com/robotech34/status/1 ... 4091023360
https://twitter.com/robotech34/status/1 ... 5397854208
https://twitter.com/robotech34/status/1 ... 1869646849

Et en dynamique :
https://twitter.com/robotech34/status/1 ... 1473184769
https://twitter.com/robotech34/status/1 ... 1371160581
https://twitter.com/robotech34/status/1 ... 1629094912

------------------------------------------------------------
Les points à améliorer

Nous avons un gros défaut et ce depuis un bon nombre d'années déjà : nous avons un manque flagrant de capteurs sur le robot.
  • Bien que nous avions des caméras sur les robots cette année, et que l'algorithme implanté était fonctionnel, nous n'avons pas eu le temps d'intégrer leurs informations dans l'algorithme principal. Elles devaient être utilisées pour repérer les palets de la zone de chaos, détecter des palets bloquant les zones de dépose, de recalage et de récolte, et, selon le temps restant, de patrouiller sur le terrain pour récupérer les palets qui traînent. Les caméras étaient les seuls capteurs présents sur les robots pour détecter la présence de pièces à distance.
  • Aucun capteur n'a été prévu pour se recaler sur le terrain, ni de manière absolue, ni de manière relative (lors de la prise ou dépose d'éléments). L'odométrie n'étant pas parfaite, ça donne des situations délicates.
  • Les servomoteurs étaient clairement trop puissants. Ils poussaient le robot à chaque prise de pièce, et donc le décalait. Et si l'un d'eux forçait trop, les axes des pignons sortaient de leurs emplacements et le démontage du servomoteur était obligatoire...
  • Nous n'avons pas d'autres capteurs que la tourelle pour détecter les autres robots. Elle est très efficace pour obtenir la position relative de l'adversaire, mais elle ne permet pas de détecter notre second robot. Les robots ne peuvent pas s'éviter entre eux, nous devons compter sur la fiabilité de la communication et la justesse de l'odométrie.
  • La communication lors de la coupe. Clairement, ce n'était pas ça cette année :oops:
------------------------------------------------------------
Retour sur la coupe

Vous avez compris, beaucoup de changements cette année, donc beaucoup de choses à développer et beaucoup d'erreurs à corriger. Nous avons passé énormément de temps sur ces robots (comme beaucoup d'équipe c'est vrai) mais je pense sincèrement que nous avons passé trop de temps dessus et que nous avons perdu de vu l'ambiance de la coupe. Là où les années précédentes nous faisions notre petit tour des stands, cette année nous n'avons pratiquement pas bougé. Heureusement que vous êtes nombreux à être passé nous voir, merci, ça fait plaisir :wink:
Les deux premiers tours des qualifications ont été à l'image de notre préparation à cette coupe : heureusement que l'électron et l'expérience fonctionnent bien ! :lol:
Les rencontres suivantes se sont un peu mieux passées. Je ne ferai aucun commentaire sur les phases finales de notre côté. Notre meilleure performance aura été contre les robots (très efficaces, il faut le dire) d'ESEO en petite finale.
Nous avons fini 4ème, ce qui reste une très, très belle place et est en quelque sorte une récompense pour l'effort fournit ! Toutefois nous aurions aimé en montrer un peu plus, la capacité des robots est loin d’être pleinement exploitée :-?

BREF !
Nous avons pris des risques, totalement pas assez mesurés, et nous sommes tombés dans l'erreur débutante de trop vouloir changer. Mais au final on a eu deux robots composés de quatre bras (beaucoup trop puissants) qui évoluent sur l'aire de jeu, s'échangent leur position et leur rôle de manière dynamique et autonome. Ce n'est peut-être pas parfait, mais il y a eu beaucoup de fait, et puis la prise de risque était un peu désirée en début d’année !

Comme d'habitude nous restons ouverts aux questions, même si c'est un peu tard ça peut aider à l'arrivée du nouveau règlement.

Pour finir, une photo prise par Planète Sciences lors de la première série :
Image

------------------------------------------------------------
Note : je prévois toujours de rédiger un document sur nos protocoles de communication et quelques petits conseils, trucs et astuces :wink:

antoine_cvra
Posts: 455
Joined: Mon 27 Aug 2007, 18:05
Location: Suisse

Re: 2019 - Robotech Legends

Post by antoine_cvra » Fri 20 Sep 2019, 18:51

Niiiice :) Vous avez eu de l'ambition les gars c'est magnifique !
Nous avons pris des risques, totalement pas assez mesurés, et nous sommes tombés dans l'erreur débutante de trop vouloir changer.
Bienvenue au club :wink:
Le code est identique sur chaque robot. C'est une seule condition, "principal" ou "secondaire", qui détermine son rôle.
C'est ce qu'on fait, et je pense que c'est le mieux pour se simplifier la vie. Chez nous la condition est juste réalisée via un jumper sur la carte (présent = robot 1, absent = robot 0) et on flashe le même code sur les deux. Avant on avait un binaire par robot avec des #ifdef et c'était galère.
Il détermine quelle tâche il veut prendre, et demande gentiment au robot principal s'il peut la réaliser.
Comment il détermine la tâche qu'il veut prendre ? Et j'imagine aussi que vous avez un système de lock pour éviter que les deux robots ne prennent en même temps une tâche. Comment vous faite si le robot "secondaire" ne relâche pas le lock, par exemple à cause d'un bug ou d'un crash ou whatever ?

Et aussi vous utilisez quel solution pour la communication ? Pas du wifi / bluetooth j'imagine, vu les déboires de certains à la coupe avec.

Riako
Posts: 89
Joined: Tue 05 May 2015, 18:07

Re: 2019 - Robotech Legends

Post by Riako » Fri 20 Sep 2019, 21:00

antoine_cvra wrote:
Fri 20 Sep 2019, 18:51
Niiiice :) Vous avez eu de l'ambition les gars c'est magnifique !
Merci :D
antoine_cvra wrote:
Fri 20 Sep 2019, 18:51
C'est ce qu'on fait, et je pense que c'est le mieux pour se simplifier la vie. Chez nous la condition est juste réalisée via un jumper sur la carte (présent = robot 1, absent = robot 0) et on flashe le même code sur les deux. Avant on avait un binaire par robot avec des #ifdef et c'était galère.
Lorsque les robots sont identiques, oui c'est clairement plus simple !
Nous avons mis un commutateur (comme vous, 0 ou 1), pour changer rapidement la fonction du robot. Il est atteignable sans démontage. (Et ça évite surtout de perdre le cavalier :lol: )
antoine_cvra wrote:
Fri 20 Sep 2019, 18:51
Comment il détermine la tâche qu'il veut prendre ? Et j'imagine aussi que vous avez un système de lock pour éviter que les deux robots ne prennent en même temps une tâche.
En fait, chaque robot possède :
  • la liste des emplacements internes, avec une valeur associée ;
  • la liste des palets du terrain ;
  • la liste des ressources du terrain (zones de dépose et de collecte, qui peuvent être réservées par un robot pour éviter que le second tente d'y aller) ;
  • la position de son compagnon et de ses adversaires.
À partir de ça il fait la liste des actions possible. Il existe différents types d'actions :
  • récupérer un palet au sol (existe autant de fois qu'il y a de palets actuellement au sol) ;
  • récupérer les palets du petit distributeur côté équipe (x1) ;
  • récupérer des palets des grands distributeurs (x6, on prend les palets 2 par 2 et il y a 2 distributeurs) ;
  • récupérer le palet en haut de l'accélérateur (x1) ;
  • récupérer le goldenium (x1) ;
  • déposer un palet dans la balance (avec limite de 6 palets et priorité aux bleus) ;
  • déposer le goldenium dans la balance (x1) ;
  • déposer un palet dans l'accélérateur ;
  • déposer un palet dans la zone de départ ;
  • se recaler.
(Je précise que nous n'avons pas eu le temps de tout intégrer)
Pour les récupérations de palet, chaque action est réalisable s'il y a un ou plusieurs palets à prendre (ben oui :lol: ), il y a suffisamment d'emplacements libre dans le robot (condition dépendant de l'exécution de l'action et du nombre de palets à récupérer), si la ressource associée est libre (zone de collecte libre) et qu'il n'y a pas d'obstacle empêchant la réalisation de l'action.
Pour les déposes, chaque action est réalisable si le robot possède le(s) bon(s) palet(s) (blanc et bleu dans la balance, le reste dans l'accélérateur), si la ressource associée est libre (zone de dépose libre) et qu'il n'y a pas d'obstacle empêchant la réalisation de l'action. Petite condition particulière pour l'accélérateur car il y a une récupération à effectuer avant la dépose.
En cas d'échec d'une action de récupération, elle peut être réintégrée dans la liste avec une pénalité de poids pour ne pas la choisir à nouveau juste après l'échec et de boucler au même endroit (dans l'idéal il faudrait instaurer une limite de tentatives, je ne sais plus si nous l'avions intégrée).

Une fois qu'un robot a déterminé se qu'il peut faire, il y a un calcul tout bête pour déterminer laquelle réaliser (dans l'idéal il y a un ratio temps / distance / poids ajustable à calculer, mais nous avons simplifié le calcul par manque de temps).
Le robot principal verrouille la ressource dont il a besoin s'il elle est disponible, puis la relâche à la fin de son action.
Le robot secondaire demande le verrouillage au principal, qui verrouille la ressource pour lui et lui répond positivement ou négativement.
Si une ressource n'a pas pu être verrouillée, l'action est considérée comme non réalisable et subit une pénalité de poids temporaire. Dans ce cas, le robot relance l'algorithme de décision.
Le robot secondaire informe le robot principal quand il veut libérer une ressource.

Le poids d'une action permet de définir sa priorité, par exemple le recalage à la priorité la plus basse (mais ce serait intéressant de faire grandir cette priorité dans le temps).
Certaines actions sont inexistantes au démarrage, et sont créées sous certaines conditions (par exemple, le goldenium).
antoine_cvra wrote:
Fri 20 Sep 2019, 18:51
Comment vous faite si le robot "secondaire" ne relâche pas le lock, par exemple à cause d'un bug ou d'un crash ou whatever ?
Si ça plante, il y a deux solutions possible : soit nous le savons à l'avance, et nous retirons un robot, soit nous pleurons ! :lol:
En tous cas il n'y a jamais eu de problème de libération d'un verrou (sauf en cas de plantage complet de la carte), le système de contrôle et d'acquittement entre les robots est robuste.
antoine_cvra wrote:
Fri 20 Sep 2019, 18:51
Et aussi vous utilisez quel solution pour la communication ? Pas du wifi / bluetooth j'imagine, vu les déboires de certains à la coupe avec.
(Il faudrait enquêter, j'ai entendu dire que les bandes en 5GHz ça passe.)
Nous utilisons des modules radio 868 MHz. Des modules que nous avons fait autour d'une puce du commerce (nRF905), mais je pense que des modules tout fait dans ces gammes de fréquences c'est suffisant.
En dehors de ce que propose le composant radio, notre protocole entre les robots est robuste : réémissions, acquittement, CRC, numérotation des messages... Je ferai un document là-dessus :wink:

User avatar
romain_cvra
PMI
Posts: 1234
Joined: Sat 30 Jun 2007, 16:17
Location: suisse
Contact:

Re: 2019 - Robotech Legends

Post by romain_cvra » Tue 24 Sep 2019, 10:03

Merci pour toutes ces infos! Vraiment chouette, c'est la classe! Bravo! 8)

De notre coté, pour la planification des actions nous utilisions GOAP (Goal-Oriented Action Planning). GOAP semble assez similaire a votre solution.
Grossièrement, pour chaque action, il faut donner une liste de contrainte. Ensuite GOAP construit le graph des actions en fonction des contraintes.

Un exemple assez parlant de ce que fait GOAP :
En 2018, les robots devait aller chercher des groupe de 5 cubes afin de construire des tours de cube.
Notre robot était muni de deux "main" (une de chaque coté du robot) qui prenaient les 5 bloc d'un groupe en une fois.
Notre robot allait prendre un des groupe de 5 blocs puis il allait chercher l'autre groupe de 5 blocs.
Ensuite retour à la zone de départ et construction des 2 tours de cubes (une pas groupe de 5 blocs)

Sauf que nous avons malheureusement cassé une des "main" juste avant le début d'un match.
Nous avons uniquement désactivé la main cassée dans le soft(désactivé l'action "main droit" dans GOAP). On c'est dit, tempi une tour c'est déjà bien.

Début du match, le robot est parti comme d'habitude chercher le premier groupe de 5 bloc.
Comme nous avons désactivé l'autre "main" il n'a pas essayé de ramasser le 2ème tas de bloc.
Le robot est retourné a la zone de construction pour y déposer le groupe de 5 blocs.

Et là, à notre grand étonnement... le robot ne construit pas la tour et repart sur le terrain... :o
Le robot va chercher le seconde groupe de 5 blocs avec sa "main" valide.
Pour finir par construire les 2 tour.
Les contraintes et le découpage des actions de GOAP on permit cela. A notre grand étonnement. :D

Pour plus d'info sur GOAP :
http://alumni.media.mit.edu/~jorkin/goap.html
https://gamedevelopment.tutsplus.com/tu ... -cms-20793

Romain
Site web : http://www.cvra.ch.
Le code source : GitHub
Visualisation CAO 3D de nos robots : GrabCAD

User avatar
kmikaz
Posts: 11
Joined: Wed 19 Sep 2018, 09:38

Re: 2019 - Robotech Legends

Post by kmikaz » Sat 12 Oct 2019, 19:39

Petite question pour la recherche de chemin:

De quelle façon vous déterminez qu'il n'y a pas de chemin accessible ?

Merci.
--
EPITA 2020
Président Evolutek<<

User avatar
baptiste_c
Posts: 154
Joined: Mon 20 May 2013, 15:09

Re: 2019 - Robotech Legends

Post by baptiste_c » Sun 13 Oct 2019, 11:04

Je les laisserai confirmer ma réponse : pas de chemin = le start et le goal ne sont pas dans des espaces connexes. Dans ton algo de recherche, ça se traduit par vider la liste des choses à explorer dans ton A* sans jamais arriver au goal.
Baptiste
Supaero 2011 - 2014
A.I.G.R.I.S. 2015 - ...
Prix de l'innovation 2016
Vice-champion de France et 3ème à Eurobot 2017
Vice-champion de France 2019

Riako
Posts: 89
Joined: Tue 05 May 2015, 18:07

Re: 2019 - Robotech Legends

Post by Riako » Sun 13 Oct 2019, 12:50

+1 ! Merci Baptiste :wink:

Dans notre implémentation (qui est en continue), on fusionne les objets se chevauchant, y compris les bords du terrain. Si la table est "coupée en deux", on jette le morceau où le robot n'est pas présent. Si le point d'arrivé était dans ce morceau, il se retrouve en dehors de la zone exploitable par le robot. Il n'y a pas de solution si le point d'arrivé est à l'extérieur de cette zone ou dans un objet (obstacle, adversaire). On a aussi aucune solution si le point de départ est dans un obstacle, ce qui arrive lorsque le robot est trop proche du bord ou d'un adversaire (c'est bien de prendre un peu de marge pour les mouvements calculés à la volé). Il faut alors s'éloigner de l'obstacle puis relancer l'algo.

Dans une implémentation discrète, on s'arrête quand il n'y a plus de nœud à explorer et que le point d'arrivé n'a pas été atteint. Comme l'a dit Baptiste, dans le cas du A* c'est une liste de points ouverts vide qui indique l'absence de solution.

Post Reply