Rapport LI260 Projet Ludovic Audibert

Transcription

1 Rapport LI260 Projet Ludovic Audibert

2 Introduction Lors de mon premier semestre en Licence d'informatique j'ai suivi des cours théoriques et d'apprentissage de langages dont le JAVA. Ce passage nécessaire a néanmoins été frustrant pour moi, les codes écrits dans les différentes matière ne répondaient que rarement à la résolution d'un problème concret et n'avait que peu d'utilité. C'est donc naturellement que j'ai choisi de prendre ce module «LI260 Projet». Les différents projets proposés était tous intéressant, mais celuici m'a particulièrement attiré. L'implémentation d'un simulateur de courses pour ensuite développer des algorithme d'intelligence artificielle était enthousiasment. J'avais de plus de bonnes bases de JAVA. Le but de ce projet était donc de développer des stratégies permettant de finir les circuits proposés en faisant des scores performants. La recherche personnelle a apporter était importante et très intéressante. Dans ce rapport, je parlerai d'abord des bases du projet que le professeur nous a fait mettre en place puis j'expliquerai quelles ont été mes recherches personnelles en racontant comment j'ai pensé aux différents algorithme que j'ai développé pour ensuite les décrire. I. Les bases du projet 1. Présentation de la structure et des packages Lors des premières semaines, nous avons tous mis en place les bases du projet. Le but étant d'avoir le plus rapidement possible un code permettant d'afficher la représentation graphique d'une simulation d'une course. Très vite, il a fallu définir la structure globale pour le projet, diviser les classes en packages et bien séparer la simulation de la représentation graphique pour éviter que cette dernière soit une source de bugs. Ainsi on peut présenter les différents packages pour donner une vue d'ensemble sur le projet : car : classes gérants le modèle physique de la voiture car.factory : classes de gestions de construction de la voiture, elle contient des constantes imposées à tout le groupe. car.driver : classes gérants les commandes qui vont êtres envoyées à la voiture, modèle d'une commande, algorithmes utilisés pour les différentes stratégies et les stratégies elles même appelées aussi drivers. track : classes de chargement et traitement des circuits. geometrie : classes de gestions des objets géométriques utilisés que sont le point et le vecteur. simulation : classes de gestion de la simulation, transmission des commandes à la voiture, transmission des mise à jour aux classes qui s'occupe de l'interface graphique, ce package comprend toutes les classes nécessaires pour aiguiller l'ensemble.

3 graphics : classes gérant l'interface graphique et la représentations de chaque objets comme le circuit ou la voiture. tools : classes utilitaires contenant des fonctions de traitements d' "ArrayList" ou de gestion sauvegarde de fichiers. mains : enfin, les classes de lancements du programme. On peut en venir à présenter la structure général de ce projet par un schéma simpliste et approximatif parce que dessiné à partir des packages mais qui permet néanmoins de bien comprendre comment il fonctionne. 2. Radar Après avoir effectué des tests en créant manuellement des listes de commandes à envoyé à la voiture, nous avons rapidement implémenté le Radar. Son principe est simple, rechercher devant la voiture quelle la direction où la distance de route est la plus longue et transmettre cette direction au driver pour qu'il fasse la voiture s'y diriger. Pour cela, le «DriverRadar» va envoyer une liste de d'angles choisis arbitrairement au Radar. Ce dernier va rechercher à partir de la position de la voiture, de sa direction et de ces angles lequel correspond à la direction qui mène "le plus loin". Une fois cette information renvoyée au driver, celuici renvoi donc une commande afin que la voiture se dirige dans la direction correspondant à l'angle renvoyé. Ainsi sur un circuit "classique" et avec des angles bien choisis on peut terminer ce dernier. 1_safe lancée avec la stratégie Radar

4 On peut vite s apercevoir que les trajectoires ne sont pas idéales et le score non plus... De plus, cette stratégie ne marche qu'avec peu de circuits. Le principe d'aller "là où la route mène le plus loin" permet donc de finir un circuit classique, cependant lorsque l'on prend un circuit "labyrinthe" où plusieurs chemins se croises par exemple, cette méthode va mener la voiture tourner en ronds. Cette méthode basique est donc très loin d'être optimale mais pouvait être rapidement mis en place. Et surtout, la structure de son algorithme sera utile par la suite. 6_safe lancée avec la stratégie Radar 3. Dijkstra Dijkstra est le nom d'un algorithme qui permet de calculer le chemin le plus court à partir de distances entre des points. On voit facilement en quoi cet algorithme nous intéresse. Ici nous avons appliqué cet algorithme à la matrice terrain correspondant à un circuit. Cette dernière matrice contient pour chaque case du circuit le type de terrain associée à celleci (route, herbe, eau, points d'arrivé,...). On créé un matrice de même taille que la matrice terrain, on initialise chaque valeur de la matrice à l'infini. Notre but sera que chaque case ai une valeur associé qui soit sa distance à l'arrivée. Ainsi on laissera comme valeur l'infini pour toutes cases qui ne sont pas franchissable par la voiture (herbe et eau). Les case associées à la ligne d'arrivée seront mise à zéro, elles sont bien les cases à atteindre. On déroule ensuite l'algorithme sur les cases adjacentes à la ligne d'arrivée et dans le sens inverse de son franchissement. Toute case franchissable aura une distance associée qui sera égale au minimum des distances des cases qui l'entourent plus une distance que l'on a prédéfinie. On différencie la distance entre deux cases adjacentes en diagonales et côte à côte. Son calcul est long et se fait à chaque début de courses, j'ai donc mis en place une fonction de sauvegarde et une de chargement d'une matrice Dijkstra afin à l'enregistrer une fois pour la charger directement les simulations suivantes. La matrice Dijkstra, une fois calculée, reste à être exploitée. Pour cela, nous réutilisons le

5 principe du Radar en développant une autre classe «RadarDijkstra» qui prendra elle aussi une liste d'angles donné par le driver et qui cherchera grâce à la matrice Dijkstra la direction vers laquelle la distance à l'arrivée est la plus petite. Cette méthode permet donc à la voiture de prendre des trajectoires bien plus efficaces que pour la stratégie Radar, de plus, la voiture termine une grande majorité des circuit. Notons qu'ici la liste des angles est encore définie arbitrairement. Pour faire en sorte que l'angle soit un angle idéal et non un des angles choisis, j'ai mis en place un algorithme qui le calcul à partir de l'angle choisi retourner par le radar. Une fois que le radar a renvoyé le meilleur angle parmi ceux définis arbitrairement (il y en aura 5), on redéfinis tous les angles autour de l'angle renvoyé (ce dernier sera placé au milieu de la liste). On redemande au radar quelle est le meilleur angle parmi ceuxla, si il nous renvoi l'angle du milieu, donc le même, c'est l'angle final choisi, sinon on redéfini les angle autour du nouvel angle trouvé, et ainsi de suite jusqu'à ce que le meilleur angle trouvé soit celui du milieu. Ainsi, en prenant des angles allant dans 5 directions bien opposées, la voiture ca dans une direction idéale par la méthode du «RadarDijkstra». 1_safe lancée avec la stratégie Dijkstra Cependant, il existe plusieurs défauts à cette stratégie. Le premier qu'on peut rapidement constater est que le «RadarDijkstra» peut faire amener la voiture à franchir la ligne dans le mauvais sens selon les circuits et les angles choisis. En effet, ce problème qui existait déjà dans avec la stratégie Radar est du au fait que si un faisceau passe par la ligne d'arrivé il ne fait pas la distinction des sens de franchissement de la ligne d'arrivée. Ce problème peut facilement être régler dans la classe «RadarDijkstra» en ajoutant des tests permettant d'arrêter la propagation d'un faisceau lorsque celuici franchi la ligne d'arrivée dans le mauvais sens. Un autre défaut non négligeable et plus compliqué à régler est que la voiture ne prend pas toujours le chemin le plus court malgré l'accès à la matrice Dijkstra.

6 5_safe lancée avec la stratégie Dijkstra En effet, la méthode du «RadarDijkstra» fait la voiture se diriger là où elle détecte qu'il existe un point A où la distance à l'arrivée est minimale. Le problème étant que les faisceaux partent de la voiture et s arrêtent bien entendu lorsqu ils rencontrent de l'herbe. En d'autres termes, si l'on se situait dans un monde réel, on peut dire que le champ de vision du pilote s'en retrouve réduit. L'herbe est comme un mur, il ne voit pas au delà. Il ne voit que les chemins accessibles directement et se dirige vers celui amenant à une distance minimale à l'arrivée. Le pilote ne peut pas voir certains chemins "cachés" derrières des virages et qui sont peut être des chemins plus courts. Ainsi dans l'illustration, on voit bien qu'après le premier virage, la voiture se dirige vers ce qu'elle croit alors le chemin le plus court, s'appercoit plus tard en se dirigeant vers ce dernier qu'il en existe un meilleur et tourne vers celuici. La voiture a alors pris un détour..nous verrons plus tard les modifications que j'ai apporté pour faire prendre à la voiture le chemin le plus court possible. La trajectoire de la voiture est également mauvaise au niveau des arrivées, la voiture se dirige vers un extrême de la ligne d'arrivée. La solution que j'ai mis en place pour éviter ce problème est relativement simple, il suffit d'appeler un autre radar lorsque le driver détecte la la ligne d'arrivée (c'est à dire une case ayant 0 pour distance). Ce nouveau radar renverra alors l'angle qui correspond à la direction par laquelle la ligne d'arrivée est la plus proche.

7 Un dernier problème est mis en avant par le circuit "bond_safe". Ce circuit a pour particularité d'être très irrégulier, autrement dit la route est truffé de petites portions d'herbe et la voiture fonce dans l'une d'entre elles. La matrice Dijkstra est définie telle que un chemin peut se propager en diagonal entre les cases de celleci, par conséquent les "chemins" traversent les diagonales d'herbes et la voiture a beaucoup de chance de rentrer de traverser l'herbe en passant par ces chemins. Pour éviter cela j'ai modifié l'algorithme de calcul de la matrice Dijkstra en ajoutant des test sur les distances de passages, ainsi lorsqu'un passage est trop étroit, les cases le composant sont considérées comme non franchissables. En plus de la résolution de ce type de problèmes, l'objectif était de trouver de nouvelles stratégies pour améliorer les scores. II.Recherches personnelles 1. Premières approches, mise en place du ghost Dans ma réflexion d'approche sur le développement d'une stratégie idéale et performante je me suis très vite ramener aux correspondances avec la réalité. Comment font les pilotes de F1 ou de rallye pour faire les meilleurs temps possibles sur leurs parcours? Un pilote de F1 connait le circuit qu'il parcours par cœur et un pilote de rallye a un copilote qui lui indique à l'avance le type de virages qu'ils s'apprêtent à prendre. J'ai donc voulu que mon driver ai un moyen de savoir à l'avance les trajectoires qu'il allait prendre, les endroits où il allait devoir freiner. J'ai d'abord pris le problème à l'envers, j'ai pensé à implémenter une sorte de machine à remonter

8 dans le temps de sorte que la voiture puisse revenir en arrière après s'être crashé, après avoir pris un rallongement ou après avoir mal pris un virage. Il fallait donc d'abord mettre en place une méthode permettant à la voiture de remonter dans le temps sans que cela perturbe les autres paramètres de la simulation puis trouver un moyen d'analyser les cas où il faudrait remonter dans le temps. Très vite, je me suis aperçu que la mise ne place d'une telle stratégie était complexe. Tout d'abord parce que faire remonter la voiture dans le temps sans qu'il n'y ai de problèmes n'est pas trivial : problèmes de pointeurs, bien sauvegarder les données de la voiture au fur et à mesure de la course, effacer les commandes précédentes... Mais surtout, plus j'avançais plus je me rendais compte qu'il serait très compliqué de bien définir les moments où la voiture devrait remonter dans le temps. Autant il est facile de définir qu'en cas d'échec elle devrait le faire, mais de combien de coups? De plus, comment définir ce qu'est un bon ou un mauvais virage? J'ai fini par considérer que cette méthode n'était pas idéale en plus d'être difficile à mettre en place. Je l'ai donc abandonné. J'ai ensuite pensé à une analyse en temps réel par projection dans l'avenir. C'est à dire, implémenter une fonction qui pourrait renvoyer les commandes que renverrait la voiture si elle était à une certaine distance (qui reste à définir) de sa position actuelle dans direction qu'elle prend. La voiture pourrait être «averti» d'un virage imminent et l'anticiper. Reste à savoir comment l'on défini à quelle distance l'on se projette, c'est un paramètre que l'on doit poser arbitrairement. J'ai pensé qu'il serait judicieux de prendre trois distances pour ensuite définir les comportements de la voiture en fonction du virage qui était à venir et de sa distance. On peut faire correspondre ces distances à trois radars qui sont en devant de la voiture. On peut ensuite définir que si le radar le plus proche détecte un virage à venir la voiture doit freiner. Par contre, un virage détecté par le radar le plus éloigné peut être synonyme que la voiture doit se décaler dans la direction opposée pour prendre le virage à la corde avec une vitesse maximale à la manière d'un véritable pilote de F1. Ce dernier principe fut une des bases de ma réflexion sur ces systèmes, nous y reviendrons plus tard. Bien que la méthode me paraissait plus efficace que l'idée de la machine à remonter dans le temps, le traitement de chaque radar était complexe, et définir de bonnes distances pour ceuxci également. Mes premiers tests furent décourageants, la voiture se décalait trop jusqu'à parfois rouler sur l'herbe. Après avoir parlé avec Mr. Guigue de ma stratégie, il m'a conseillé de plus simplement de lancer une première fois la voiture normalement pour ensuite traiter les données que l'on pouvait récupérer. Nous verrons plus loin de quelle manière sera utilisé ce premier passage mais intéressons nous ici à ce que j'ai appelé le ghost. Le «ghost» est donc une première voiture qui parcourra un circuit avant la voiture en stockant des informations sur son parcours. Le ghost utilise une stratégie dijkstra avec quelques améliorations que nous verrons plus tard. 2. Optimisation de trajectoire On a vu auparavant que la stratégie Dijkstra de base ne fasait pas toujours prendre à la voitue le chemin le plus court. Sur certains circuits, la voiture rallonge assez largement sa trajectoire. Avant d'avoir mis le ghost en place, j'avais essayé d'implémenter une fonction de

9 recherche qui faisait avancer un radar sur la trajectoire de la voiture à chaque coup. Ainsi si la future destination de la voiture pouvait être atteinte directement, la voiture s'y rendrait. Le problème est que cette méthode est difficile à mettre en place, mais surtout que mes calculs à effectué par coup sont important et par conséquent la simulation était fortement ralentit au point que la voiture mettait près d'une minute à parcourir un circuit. J'ai donc mis en place une autre méthode utilisant le ghost. Ce dernier stockera une ArrayList de points le long de sa trajectoire (on utilise un modulo pour ne pas en stoker trop). On peut ensuite traiter cette liste de manière à la réduire à des points «clés» vers lesquels la voiture devra se diriger lorsqu'elle les aura dans «son champs de vision». En effet, pour chaque point A de cette liste, en partant du premier, on parcourt le reste des points B de la liste à l'envers, en partant cette fois ci du dernier qui peut être considéré comme le point d'arrivé de la voiture. On test si le segment AB est un chemin valide pour la voiture et ne passe pas par la ligne d'arrivée (pour éviter de franchir celleci à l'envers). Si c'est le cas, cela veut dire que la voiture peut prendre ce chemin AB qui est plus court (ou de même longueur) que le chemin emprunté normalement. Dans ce cas on supprime tous les points entre A et B et on réitère sur le suivant (qui sera donc le point B dans ce cas). Si AB n'était pas un chemin valide on prend un nouveau point B, le précédent à B dans la liste. Ainsi, en reliant les points restant on obtient le chemin le plus court possible. La driver peut exploiter facilement ces points clés. Il suffit de les rechercher à chaque coup, si la voiture en «voit» un, le driver la dirige vers celuici. Lorsqu'elle est très proche de ce dernier, on le supprime de la liste. Cependant cette méthode peut pour certain circuits faire augmenter le score d'un ou deux coups. En effet, lorsque les chemins trouvés sont à peine plus court, la voiture abandonne inutilement sa stratégie initiale pour se diriger vers eux. J'ai donc ajouté une algorithme qui élimine les points qui ne raccourcisse que très peu le chemin en comparant les segments trouvés avec la distance du chemin de départ (il faut définir arbitrairement une valeur minimal). Cette méthode fait gagner de nombreux coups sur certains circuits, passons maintenant à la description de ma stratégie principale.

10 3. Zones de virages Lorsque que j'ai mis en place la méthode d'anticipation par projection dans le future de la voiture, mon principal but était de faire en sorte que la voiture prenne chaque virage avec une vitesse maximale en la faisant se déporter dans la direction opposée à ce virage d'abord pour qu'elle puisse prendre le virage à la corde. C'est là que Mr. Guigue me proposait d'abandonner la méthode de projection et de plus simplement faire parcourir une première fois la voiture avec une stratégie simple. En plus de cela l'idée était que le ghost enregistra les points où elle freinait au delà d'un certain seuil que l'on définirait arbitrairement et également d'associer à chacun de ces points un vecteur. En effet, le principe est que pour chaque virage, la voiture est un point où elle se rend qui se trouve déporté et qu'une fois atteint elle puisse entamer le virage. Il faut donc déplacer le point dans la direction opposé que la voiture a au moment où elle freine. De plus on définit un rayon pour dessiner une zone autour de chaque point pour qu'une fois cette zone atteinte, la voiture repasse à une stratégie classique (ici Dijkstra). Ainsi, une fois la liste de point stocké par le ghost avec leurs vecteur correspondant, on traite cette liste dans le DriverTurningZones. On épure la liste en transformant les points très rapprochés en un unique point issue d'une moyenne des originaux et on déplace les points à partir de leur vecteur associé. Une troisième donnée importante est aussi présente dans cette liste, une taille pour la zone qui est aussi utilisé pour la taille du vecteur. Elle est proportionnelle au taux de freinage du ghost à ce point. Enfin, on redéfinit le comportement du driver, celuici recherche s'il voit un point de la liste, si oui il s'y dirige, sinon il utilise une stratégie Dijkstra qui impose un seuil de freinage maximal pour la voiture de sorte qu'elle prenne bien les virages à grande vitesse. Une fois qu'il a atteint la zone d'un de ces points, il l'efface pour passer aux suivants. Cette stratégie possèdent de nombreux problèmes. Beaucoup de variables sont à définir correctement, la taille des zones, la taille des vecteurs, direction des vecteurs, vitesse minimale... Mes premiers essais ont révélé que les ajustements étaient soit optimal pour des virages larges soit optimal pour des virages serrés. Je ne parvenais pas à trouver de définitions cohérente pour tous les virages à la fois. Le problème vient en fait du premier passage du ghost. En effet, ce dernier ayant une stratégie Dijkstra simple qui l empêche de déraper (il ne tourne pas plus que sa limite), il parcoure le circuit en prenant les virages les plus serrés possible et en se déportant donc légèrement le temps de freiner. Cela fausse considérablement les données stockées pour chaque virage, entre la trajectoire prise par le ghost et le virage lui même il y a une différence non négligeable et la voiture se comporte en fonction de la trajectoire du ghost mais elle roule bien sur le circuit. J'ai donc décidé «d'idéaliser» le ghost. J'ai modifié la classe «Car» pour mettre en option la possibilité que la voiture ne dérape jamais et tourne autant qu'elle le souhaite. Ainsi le ghost prend des trajectoires à la corde des virages. Évidement ses scores ne sont pas valides. J'ai aussi redéfini les conditions de sauvegarde des points par le ghost pour passer d'un seuil de freinage à un seuil de changement de direction. On obtient des

11 zones cohérentes pour tout type de virage. Mais il reste d'autres problèmes. 1_safe lancée avec la stratégie TurningZones L'intérêt de cette stratégie est de pouvoir prendre les virages à grande vitesse tout en prenant des trajectoires optimales. Deux paramètres essentiels sont le seuil de freinage que la voiture ne peut dépasser et la taille des zones. J'ai inséré dans mon interface graphique de quoi modifier ces deux variables et ai effectué de nombreux tests sur tous les circuits. J'ai pu constater grâce aux configurations prises pour chaque meilleurs temps que le seuil de freinage idéal est contenu entre 0% et 100% mais approche le plus souvent 100%. Par contre, la taille idéal des zones variait plus (entre 20 et 70), même en gardant un même seuil de freinage pour chaque circuit, la taille optimal variait de manière significative. Je pouvais donc conclure que la taille des zones (qui est aussi la taille de déplacement du vecteur), devait être propre à chaque virage. J'ai longtemps chercher à redéfinir cellesci pour chaque virage par différentes méthodes, moyenne des tailles des points rapprochés, sommes,... J'ai fini par me résoudre à mettre en place une simulation lançant plusieurs configurations en changeant à chaque itération le paramètre de taille d'une zone. Je trouve ainsi une taille optimale pour chaque zone en les traitant de la dernière à la première. Pour éviter que cette simulation soit trop longue j'ai optimisé le temps de recherche pour chaque zone en découpant le tableau des valeurs possible en 4 valeurs qu'on teste, on réitère pour les tableau situé entre les les deux meilleures valeurs jusqu'à obtenir une seule et unique valeur. Cependant cette simulation reste longue et peut prendre plusieurs heures pour les circuits les plus longs.

12 1_safe lancée avec une simulation complète du driver TurningZones Il existe des risques d'échec selon les paramètres choisis. Il est possible de s'assurer de la réussite d'une course en relançant la voiture lors d'un échec en s'appuyant sur un traitement postéchec. De sorte que lorsque la classe de simulation détecte que la course a été un échec, elle fait appelle à une fonction du driver qui gère l'échec et la simulation relance la course. Dans cette fonction, on identifie la dernière zone de freinage où la voiture est passé et on l'ajoute dans une autre liste. Lorsque la voiture demandera une commande au driver, le driver vérifiera s'il se trouve dans la zone du point d'échec du tour précédent, si oui il baissera le seuil de freinage pour que la voiture y roule moins vite. 4. Anticipation, alternative La dernière stratégie que j'ai développé est une autre méthode d'anticipation qui vise cette fois à suivre le chemin tracé par le ghost en freinant juste avant un virage pour ne pas être déporté. Le ghost sera différent que celui utilisé précédemment, il stockera tous les points où il a tourné avec la commande de virage associée. Le driver de la voiture aura encore une stratégie dijkstra avec une vitesse maximale imposée comme précédemment. Cette vitesse maximale ne sera en fait que relativement imposée puisqu'une autre variable imposera en priorité à la voiture de freiner à certains moments. Cette variable sera initialisé à 100% et sera changé uniquement lorsque la voiture sera à proximité d'un des points enregistré. On testera aussi que le point est bien en devant de la voiture et non pas derrière (il ne faut pas freiner après le virage) grâce à un produit scalaire entre le vecteur direction de la voiture et le vecteur formé par la position de la voiture et le point de freinage. Le principe est assez simple donc, lorsque on arrive devant un point qui indique que la voiture va devoir tourner, on freine. Il est par contre plus compliqué de définir à partir de

13 quand l'on freine et avec quelle intensité. Pour réussir à trouver la bonne formule j'ai étudié de plus près les variables définies lors de la construction de la voiture ainsi que les méthodes de déplacement de la voiture. On peut déterminer que pour un virage qui demanderait à la voiture de tourner au maximum par exemple, il faudra freiner un peu moins d'une dizaine de fois pour que la voiture arrive à une vitesse suffisamment faible. J'ai donc mis en relation le pourcentage de braquage que la voiture voudra passer en commande et à quelle distance du point elle devrait commencer à freiner. Le résultat était très décevant, la voiture freinait beaucoup trop. J'ai très vite imposé que la stratégie ne prenne en compte que les virage qui demanderaient de braquer au maximum. On peut en effet négligé les petits virage, la voiture met très peu de coups à vitesse maximum pour faire un petit virage et ne dévie pratiquement pas de la trajectoire tracée par le ghost. Cela n'a pas changé que la voiture freinait trop devant les gros virages et ce tout simplement parce que j'avais surestimé le besoin de freiner pour effectué un virage serré. En fait, lorsque la voiture freine, elle se déplace de moins d'une case unitaire (représenté par un pixel), si elle cumule plusieurs commandes qui la font ralentir dans une même zone elle la recevra bien plus de fois que la distance entre la point et la voiture. Au départ mon but était de calculer une approximation du cumul de ralentissement nécessaire pour atteindre une certaine vitesse à partir de la vitesse actuelle. Mon approximation était donc fausse. Après quelques test, la bonne distance à définir ne varie que très peu, elle tourne atour de la valeur unitaire. Cette stratégie ne bat pas les scores de la précédente mais s'en rapproche relativement, sa mise en place fut plus rapide et simple. 1_safe 2_safe 3_safe 4_safe 5_safe 6_safe 7_safe 8_safe Radar Dijkstra Zones Anticip bond 260_safe Een2 aufeu labperso labmod Radar Dijkstra Zones Anticip

14 Conclusion Ce projet a été une bonne expérience qui m'a permis de mieux comprendre les différentes étapes dans l'élaboration d'un programme de ce type. J'ai pu mieux rapprocher ce que j'ai appris dans les autres matières avec les problèmes concrets qu'on pouvait rencontrer. J'ai rencontré de multiples difficultés tout au long du projet, j'ai pu acquérir un peu d expérience dans le développement de programmes plus complexes. Le développement d'intelligences artificielles m'a plu et intéressé, j'envisage d'orienter mes études dans ce sens aujourd'hui. En fin de compte, je n'ai pas réussi à battre les meilleurs scores du groupe de l'année dernière. Le fait d'avoir mené ce projet seul m'a permis d'être plus efficace dans la mise en place des bases du projet mais j'ai été limité dans le développement par rapport aux autres groupes. Avoir un point de vue extérieur sur ses idées d algorithmes est bénéfique de même que les idées sont plus nombreuses lorsque l'on est deux. C'est pourquoi j'espère avoir d'autres occasions de mener à bien des projets comme celuici et choisir de travailler en équipe.