Vous l'avez surement remarqué, mais le code actuel n'est presque pas commenté, j'espère que les nom de variables assez explicite permettront malgré tout de rendre l'ensemble compréhensible. Je vais tâcher de vous expliquer dans les grandes lignes la façon dont le code a été structuré à travers les différents dossier.

Ce code n'a pratiquement pas évoluée depuis l'année 2012. Regroupe le code pour la construction du graph de recherche et la recherche de chemin pour le robot, en prenant en compte les parties de la table qui son inaccessible. Le graph possède une fonction de mise à jour permettant de prendre en compte le déplacement des obstacles. Deux stratégies sont fournies pour la construction du graph : un découpage par tiles et un découpage par polygones convexes (polygones qui n'ont pas d'angle rentrant).

Le découpage le plus intuitif, on demande à l'ia de découper la carte en carré de x*x, puis de noircir les carrés non accessibles. Avec cette implémentation on est partagé entre precision et performance, dans un environement complexe avec beaucoup d'obstacles on voudra avoir un bonne précision, mais qui dit bonne précision dit plus de carré et donc plus de temps de calcul (aussi bien pour le calcul du chemin que pour le noirciment dynamique des cases).

Découpage plus complexe à réaliser, le but est de découper la zone accessible en un minimum de polygones convexes. Avec cette implémentation le calcul du plus court chemin est fortement accéléré car le nombre de noeud est très faible, la taille du graphe ne dépend plus de la taille de la carte mais de la complexité de celle-ci (nombre d'obstacles et formes de ces obstacles). Le calcul des polygones convexes est réalisé à l'aide un petit programme en c++ qui utilise la libCGAL, une librairie mathématique de haute voltige.

Une seule classe permet de calculer le chemin à partir de l'un ou l'autre des découpages ci-dessus, l'algorithm utilisé est A* (ou A star). À noter que le nabgraph “soomth” le chemin renvoyé par A* pour le rendre plus droit si possible, c'est l'algorithme de funnel qui s'en charge.

Dans le dossier vizgraph il y a les outils nécessaire pour observer le découpage réalisé selon l'un ou l'autre des algorithmes, on peut aussi déplacer un objet fictif pour forcer la mise à jour du graph pui demander le calcul d'un chemin. Pour chaque opération on peut voir le temps d'execution.

Dans ce dossier il y a toutes les classes necessaires au chargement de la map. Deux formats sont possibles : le format matrice de collision (image black & white) et le format descriptif en xml (qui pourrait être passé en json ca ferait du bien).

/!\ format adapté pour la génération d'un tile graph seulement /!\

L'image doit être en noir et blanc, toute zone noir est inaccessible.

Le ficier doit décrire les zones inaccessibles à partir de formes géométriques.

Le fichier window.py permet de voir comment le decoupage a été fait. Il ne gère actuellement que le navgraph avec fichier descriptif mais libre à vous d'étendre son comportement.

• ia_base.py : Regroupe les méthodes de base d'une ia (setup des connections, setup de l'état interne, etc…), cette class implémente une ia basic qui ne fait rien à part demander les informations de l'hokyo et de l'asservissement puis de mettre à jour son état interne. La class doit être surchargée.Regroupe les méthodes de base de contrôle de l'IA, à savoir start/stop, la détection du jack, les boucles et quelques autres méthodes relatives aux actionneurs (la classe risque d'être éclatée pour en avoir une dédiée aux actionneurs).

• ia_utcoupe.py : L'ia d'utcoupe, c'est la classe qui surcharge IaBase, elle implémente tooutes les spécificités de l'IA de cette année, elle pourrait être renommé en IAUtcoupe20XX pour avoir une trace d'année en année.

• action.py : Super classe de actions.py. Cette classe regroupe l'ensemble des méthodes relatives à toutes les actions. A savoir principalement les calculs de chemins, de score et de priorité.

• actions.py : Fichier qui regroupe toutes les classes d'actions. Cette architecture là sera amenée à évoluer.

• gamestate.py : Classe représentant la connaissance de l'IA, toutes les infos récupérées et filtrées des différents drivers (hokuyo, asservissement, visio, …). La classe possède une méthode pour mettre à jour ses informations au fil du match.

• robot.py : Classe représentant la connaissance de l'ia sur un robot. La classe fournit aussi quelques méthodes utilitaires sur les calculs de chemins.

• smartasserv.py : Ne fonctionne pas actuellement, mais permet de gérer l'asserv d'une façon “intelligente”. C'est un module qu'il faudra absolument rendre fonctionnel pour la coupe 2014 afin de passer par celui-ci et non d'interroger directement l'asserv à partir de l'IA (ce qui est actuellement fait).

gateau.py, ia_test.py et verre.py ne sont plus utilisés (gateau et verre étaient des classes séparées pour els actions sur le gateau et avec les verres durant la coupe 2013).

• Main
• IA_base
• Robot
• Gamestate
• Action
• Actions