robocupulaval / strategyai Goto Github PK

Plusieurs hack ont été écris rapidement pour pouvoir faire une démonstration à Beenox.
Ces hacks doivent maintenant être formalisé et structuré proprement.

La gestion des commandes de débogages de l'UI-Debug doivent être passé dans le DebugManager et un Executor spécifique à ça.

• Retirer les hack de coach.py
• Étoffer DebugManager pour interpréter correctement les commandes de l'UI
• Envoyer les informations au UI lors de la première connexion
• Retirer les FIXME: hack du code

(1er juin)

La communication entre le UI-Debug et l'IA doit être en place du côté de l'IA.
Ceci implique la capacité d'envoyer selon le protocol des informations de débogages et de pouvoir reçevoir des commandes de débogages.

• Envoie des informations
• Réception des commandes
• Activer le contrôle humain

Lors des tests d'intégration, le robot peut commencer à avoir des comportements erratiques ou anormaux. Il est donc important de pouvoir rapidement faire terminer l'exécution de l'IA et ce en envoyant des commandes d'arrêts aux robots.

Idéalement, le bouton «Stop» de l'UI devrait être utilisé à ce fin et la séquence C-c devrait être capturée et traitée correctement.

L'utilisation d'une seule séquence de tactiques pour tous les robots doit être bonifié:

• Ajouter une séquence par robot
• Employer les drapeaux d'états pour effectuer une transition
• Ajouter un object TacticNode permettant une sélection multiple

Le dernier point est intéressant et probablement nécessaire pour faire fonctionner les tactiques de passes correctements. Cet objet doit permettre de sélectionner différente tactique selon des sélecteurs ou ne choisir aucune tactique et attendre une future itération de l'IA.

Il serait bien que le pathfinder considère l'équipe adverse et la balle lors du calcul du path.
Surtout concernant la balle, un élément de démonstration important dans les prochaines semaines va être la tactique GoGetBall.

Du code modifié était présent et doit être rappatrié dans la branche dev.
De façon général, l'ordinateur d'intégration ne devrait pas contenir de développement, mais simplement des correctifs. Ces derniers devraient autant que possible être effectué sur un poste de développeur.

Une influence map a été développée par @MaximeGLegault et doit être intégré pour fournir une analyse de haute stratégie au behavior tree de la demande #11.

[ ] Intégration du code
[ ] Analyse de l'architecture
[ ] Obtention des métriques

Actuellement nous avons hardcode la valeur que nous sommes l'équipe bleu.
Cette considération devrait être gérée de façon plus générale

• Modifiable par le UI
• Modifiable par le referee (lorsqu'implémenté)

Il faudrait donc en faire la discussion d'architecture et minimiser les impacts.

Ajouter un pathfinder implémentant l'algorithme RRT.

Dans le but d'implémenter les premières stratégies d'attaque et de défense pour l'issue #23, une série d'actions de base est requise. Les premières actions à créer sont :

• move_to
• kick
• go_between
• grab_ball
• move_with_ball
• idle

D'autres actions pourront être ajouter à mesure qu'on développe les stratégies.

Le UI-Debug envoie correctement la nouvelle stratégie à adopter.

Cette stratégie devrait être assigné et le contrôle humain devrait être désactivé.

• Mettre par défaut une stratégie inactive.
• Assigner la stratégie sélectionner.
• Assigner la stratégie d'arrêt si "Stop" est envoyé.

La commande semble vouloir répondre (état des robots et fenêtre IA), mais rien ne bouge, ni dans grsim ni dans le uidebug.

Ajouter les pathfinder dans le pipeline comme module intelligent présente plusieurs problèmes.

Après des conversations pour trouver une meilleure architecture:

• Modifier le RRT pour qu'il puisse être utilisé par une Tactique
• Modifier la tactique GoTo pour correctement consommer un chemin complet
• Retirer l'executor pour le pathfinder et l'échafaudage pour soutenir les pathfinder comme modules intelligents

10 août 2016

Pour les tests, la simulation et certaines démonstrations, un pathfinder déterministe serait bien.

Une implémentation du A* est probablement l'idéal, mais un Dijkstra est aussi envisageable.

Il faut ajouter un nouveau module pour se charger de la gestion des mouvements après que le côté STA/pathfinder à déterminer c'est choses. Il faut implémenter le module pour englober l'évitement dynamique (issue #84), smoother les transitions entre les points, intégrer les contraintes des moteurs.

Le code actuel doit être refactor pour appliquer le nouveau nom du cadre.

Le niveau tactique devra aussi utilisé la FSM développé dans le cadre de l'issue #9.
Cette FSM doit être une entité qui vit à travers plusieurs itérations de la boucle de l'intelligence.

L'objectif est d'implémenter plus proprement le cadre STP original.

Lors du démarrage de l'IA, un heartbeat devrait être en place.
Ceci permettrait de savoir quand envoyer ou ne pas envoyer les informations au UI-Debug et de renvoyer les informations d'initialisation au besoin.

Ajouter un sélecteur qui permet de retourner une stratégie différente selon des éléments ou des considérations simple, e.g: est-ce que notre équipe est en possession de la balle.

Lors des tests d'intégrations il a été remarqué que le terrain a un facteur d'échelle (réduit, ~3X).
Ceci fait en sorte que les deadzone et autres variables utilisés pour éviter les collisions ne sont plus adéquate.

Il faut modifier l'architecture pour prendre en compte ce facteur.

• Modifier les grandeurs du terrains en fonction de l'échelle
• Modifier les constantes selon le facteur d'échelle
• Reçevoir le facteur à partir du UI-Debug
• Déterminer un facteur par défaut et pouvoir démarrer l'IA en mode intégration

L'InfoManager et le BlackBoard dans leur état actuel présentes des faiblesses ou des choix d'architectures qui porte à confusion.

• Le GameState est répliqué et devrait être proprement centralisé au niveau du RULEngine
• Le BlackBoard devrait être un véritable tableau blanc qui permet l'échange d'information par message entre différentes composantes -> #11 en aura besoin d'un
• L'InfoManager devrait plutôt être une collection de méthode qui obtient l'information: une facade

[ ] Refactor du BlackBoard
[ ] Extraire le GameState vers le RULEngine
[ ] Uniformiser l'InfoManager

(22 juin)
Des stratégies fondamentales pour la défense et l'attaque doivent être ajoutées.

Elles seront les débuts du livre de stratégie du cadre STA.

• Une stratégie d'attaque
• Une stratégie de défense
• Exploiter les outils de #9 #11 et #22 pour s'exécuter
• Être bâti à l'aide de primitives

[] Attaque
[] Défense
[] Sélection automatique selon le contexte

(modification ultérieur à la demande possible)

• Set player_skill_target_goal, à séparer en 3
• Refléter refactor STA (skill -> action, play -> strategy)
• Utiliser des objet/namedtuple pertinent pour représenter le gamestate.
  Actuellement des dictionnaires, qui utilise des strings comme clef quand un int ferait l'affaire, sont utilisés, leur manipulation directe est moins aisé quand l'API de l'info_manager ne suffit pas

Le UI peut afficher l'état des robots.

• Envoyer l'état des robots
• Rafraichir cette information à chaque exécution de l'IA

Dans le nouvel executor pour le movement, ajouté les calculs nécessaires pour forcer l'asservissement à produire un mouvement fluide lorsqu'on suit un chemin.

Ceci peut-être obtenu en modifiant la cible de déplacement dynamiquement lorsqu'on arrive proche d'un point du chemin et qu'un autre point reste à atteindre. L'asservissement n'a aucune notion de "chemin" et ne devrait pas non plus en acquérir.

Le UI-Debug aura bientôt la capacité d'envoyer un état passé du jeu pour "reculer" la simulation.
GrSim permet aussi de modifier l'état du jeu (position des robots et ball).

Cette fonctionnalité doit être implémenté dans l'IA pour pouvoir être utilisé.

• Mise à jour de l'état du jeu par le UI-Debug
• Mise à jour de GrSim à l'aide de l'IA
• Mise à jour de STA pour récupérer le même état stratégique

Actuellement l'IA est mise à jour à chaque frame de vision (60 fps).
Pour faciliter les tests d'intégrations et le débogage, cette fréquence devrait pouvoir être paramétrable. Minimalement l'IA une option de temps minimale entre 2 itérations de l'IA devrait pouvoir être précisé.

Plusieurs méthodes sont possible pour préciser ce paramètre:

• Par constante
• Par option ligne de commande
• Par le UI-Debug

Des travaux de @felixpelletier vont permettre d'influencer GrSim à l'aide des paquets d'informations envoyés.

Une interface du style de celle de l'UI-Debug doit être implémenté dans l'objectif de faciliter l'écriture de test fonctionnel et d'intégration.

Actuellement les robots sont gérés par id.
Une meilleure architecture devrait être produite.
Les robots disponibles ne suivront pas nécessairement un ordre logique dans les ids.
L'architecture actuelle est aussi relativement fragile pour la gestion d'une stratégie avec plusieurs ids.

Ces considérations doivent être évalués et des solutions envisagés pour améliorer la situation.
Éventuellement, des tests devraient produits pour évaluer le système dans son entiereté.

Pouvoir assigner des tactiques et une stratégie à l'équipe adverse et envoyer les commandes au simulateur.

Une machine à état finie doit être implémentée.

• Cette machine représentera une tactique à terme
• Le basculement doit être contrôlé par le programmeur
• Effectuer des opérations en entrant et sortant d'un état doit être facile et conviviale

Les bases de l'implémentation de la FSM de la compétition peuvent servir d'inspiration, mais plusieurs éléments important tel le concept d'effectuer le basculement explicitement doivent être ajoutés.

[ ] Implémentation de base
[ ] Basculement set_state
[ ] @on_before, @on_after

Il faudrait enlever les magic numbers concernant le nombre de robots par équipe dans le code.

Par Exemple, sur certains loops, on itère de 1 à 6 mais il faudrait plutôt itérer de 1 à une variable NumberOfPlayers.

Aussi, il faut que les IDs puissent dépasser 6 car dans le futur, nous voudrions pouvoir mettre un robot #7 si jamais un des robots sur le terrain brise, par exemple.

La tâche serait adéquate pour initier un nouveau au code.

(8 juin)
Actuellement, une section importante de code est dans la méthode principale de UltimateStrategy et s'occupe d'envoyer les commandes vers le module de communication avec les systèmes embarqués.

Les changements introduits par #9 vont aussi exiger un traitement un peu plus intelligents des données du robot dans l'InfoManager.

L'objectif est d'extraire le code source pertinent et de le modifier pour que la nouvelle implémentation fonctionne.

Problème d'intégration du code du RRT.

Pour faciliter et simplifier l'utilisation de l'interface de débogage, une façade de débogage doit être écrite. Celle-ci doit se comporter similairement à l'InfoManager et cette dernière façade doit y donner accès à l'aide d'un InfoManager.get_debug_manager.

• Accès par InfoManager à DebugManager
• Gestion des structures de données
• Interface claire et donnant accès aux commandes utiles du protocol de l'UI-Debug

Lors du calcul d'un chemin, les chemins déjà calculés des autres robots devraient être pris en compte.

Intégrer le code de Yassine, un pathfinder qui s'emploie à travers le cadre STA.
TODO: corriger le pathfinder
TODO: intégrer avec un executor plutôt que STA.

@etibuteau a commencé un behavior tree qui peut servir de fondement pour une stratégie (S de STA).
Il doit parler à @MaitreMenard pour voir comment adapter le code.

Actuellement, certaines Tactique seraient utile si elles pouvaient être utilisées comme une action, e.g: GoToPosition.

Le retour des différents niveaux et le mode de fonctionnement s'y prête correctement, il suffirait de modifier les appels pour pouvoir le faire.

• Ne pas utiliser l'InfoManager pour les AICommands
• Modifier GoGetBall pour utiliser GoToPosition

Actuellement, la gestion de l'assignation des tactiques par le UI-Debug nécessite de modifier le code à deux endroits: le TacticBook (module sous le package Tactic) et de modifier un arbre de if/else dans le DebugExecutor. La fonction dans le DebugExecutor devrait être généralisée pour pouvoir prendre automatiquement les nouveaux types de Tactic.

Ceci nécessite que le UI-Debug envoie des informations plus intéressantes par défaut associé à chaque Tactique. Une demande va être ouverte en ce sens dans le dépôt du UI-Debug. Il est possible aussi que l'API de Tactique nécessite des meilleurs valeurs par défaut. Ceci est dans le but de simplifier l'ajout de nouvelles tactiques et que l'outil de debug soit à jour automatiquement.

Le pipeline executor actuel doit être modifié.
Les données devraient préférablement être passé en entrée et les traitements des executor devraient produire des données de sortie (aspect fonctionnel).

La dépendance sur des effets de bords dans l'InfoManager doit être minimisé.

• Interface fonctionnel pour les éléments du pipeline
• Réduction au minimum des dépendances sur l'InfoManager
• Restructuration du DebugExecutor
• Ajout de unit test pour les cas simple

En testant la tactique GoGetBall avec le pathfinder d'intégrer (utilise GoToPosition), si la balle change de position avant que le robot l'atteigne, il tentera de compléter son trajet.

Une solution simple serait d'ajouter un time to live (ttl) aux tactiques.

Proposition initiale: on ajoute un membre ttl qui par défaut prend la valeur d'une constante, à chaque changement d'état (on passe d'un état à un autre état différent), on prend en note le timestamp, si jamais la différence entre le timestamp actuel et le timestamp du dernier changement d'état dépasse le ttl, on transitionne dans un état pour réévaluer la tactique. Par défaut, halt pourrait avoir la logique nécessaire à ce sujet. Dans le cas de GoToPosition un nouveau path pourrait être calculé et pour GoGetBall, la nouvelle position à atteindre serait calculée. Le ttl pourrait être très rapide (~300 ms). Ces transitions et check s'effectueraient en 2 itérations (~30 ms) de l'IA.

@MaitreMenard: puisque je n'ai pas encore vu le nouveau code de Stratégie, est-ce pertinent ou ce cas va être réglé par les modifications à l'architecture?

Lors du traitement des messages de débogage pour assigner une Tactique, la considération pour valider un pid devrait être prise par une classe autre que celle qui parse. Par exemple: PlayState.

Le code source existant devrait:

• Être documenté inline (doc string)
• Posséder un filet de test unitaire
• Répondre au standard de code (entre temps utiliser PEP8)

Au besoin, relever et ouvrir une issue si un segment du code est vraiment inacceptable ou pas assez modulaire pour répondre à ces critères qu'il soit refactor.

En plus d'un pathfinder, de la logique pour diriger les robots de proche est nécessaire.
Cette logique doit être général et permettre de modifier les commandes des robots pour qu'ils évitent les obstacles rapprochés et ce de façon dynamique (préférablement de manière déterministe aussi).

Les travaux de Yassine peuvent être une base et son PR pourrait être réutilisé pour implémenter un tel module ou un executor.

L'architecture est encore à définir.

Le fait de pouvoir assigner une zone rectangulaire en définissant un rectangle est bien.
Cependant, il serait utile de pouvoir assigner cette tactique avec une Target et un paramètre pour déterminer la forme de la zone (circulaire vs rectangle, avec paramètre de rayon optionnel).

Le lancement de l'IA devrait permettre de passer des paramètres diverses:

• --test_bench : lance un test_bench pour la simulation/vrai vie
• --no_debug : coupe les fonctionnalités de debug

Le point est d'avoir le code en place (pas très lourd puisque dans la stdlib) et de pouvoir par la suite ajouter rapidement et facilement d'autres options qui seraient utile.

Dernier clean up du PC du local 0108 (aka TrumpSation)

Make this PC great again !

Lorsqu'on augmente la charge sur l'IA (e.g: Tactique assigner rapidement à plusieurs robots, régulièrement dans un cours délais et calcul fréquent de path), l'IA cesse de fonctionner. Il n'y a pas d'arrêt ou de message d'erreur dans la console.
Un tick dans la boucle principal a été ajouté et est log dans le UI-Debug. Ce tick contient le timestamp et on peut constater qu'il cesse d'augmenter.

Pour reproduire: démarrer l'IA et assigner à l'aide du UI-Debug la stratégie SimpleOffense
(code de la branche agingrasc/feature/71-api-tactique-action). L'IA meurt en quelques secondes.

Il faut solidier l'IA pour qu'il soit plus robuste. Le phénomène semble plus accentué sur la trump_station selon l'expérience personnelle. Le bogue est possiblement lié au matériel, à valider avec un ordinateur plus puissant (je mettrai à jour).