*Title: Spécifications du simulateur de robot *Author: Nicolas Schodet *TOC * Introduction ** Pourquoi un simulateur de robot ? Pour simuler le fonctionnement d'un robot. La programmation d'une intelligence artificielle demande la réalisation de nombreux essais. Ces essais ne sont pas toujours réalisable avec un robot réel car il peut ne pas exister, ne pas être terminé, ne pas être disponible, être démonté, avoir les batteries vides, prendre de la place, prendre beaucoup de temps, nécessiter un opérateur, être dangereux, s'user... bref on peut trouver un tas de raisons. Pourquoi de nombreux essais ? Parce qu'ils nous permettent de prendre en compte un maximum de possibilités et de situations. Les essais permettent aussi de mettre en oeuvre des techniques moderne d'intelligence artificielle comme l'aprentissage (algorithmes génétiques, réseaux de neurones, renforcement...). En effet, il faut souvent un bon nombre de tests, avec une évaluation de la réussite par un programme, ce qui n'est pas réalisable sans simulation. Un interrêt consiste aussi à utiliser l'affichage du simulateur pour afficher en temps réel les données provenant du robot. Dans ce cas on désactive le simulateur, ou mieux, on ne l'active pas. ** Quel simulateur de robot ? Il faut un système réutilisable, parce qu'on ne veut pas travailler pour rien. Il faut donc qu'il soit facile à adapter à n'importe quel type de robot. Bien sûr il faut se fixer des limites, donc on va prendre un robot du type que l'on rencontre dans la compétition Eurobot. Idéalement il faudrait pouvoir prendre en compte plusieur types de déplacements (roues, chenilles, pattes...), de capteurs (distance, contact, information sur un élément...), d'actionneurs (tapis roulant, pince...). Il faudrait aussi prévoir une génération d'image pour l'utilisateur, ou même pour une camera. Naturellement le système doit pouvoir être connecté au vrai programme qui fait tourner le robot. ** Quel modèle de développement ? Libre bien sur ! Il faudrat d'abord faire une première version de base et ensuite l'idéal serait de créer un projet sur un site de développement comunautaire du style Savanah. ** Quelle licence ? La GPL. Car elle nous permet de faire un developpement utile au plus de monde possible, auquel tout le monde peut participer. Elle permet aussi de s'assurer que notre simulateur continuera d'être libre. * Spécifications techniques ** Simulation du monde Il faut faire un simulateur générique, c'est à dire qu'il doit être facile de redéfinir des comportements. Le noyau du simulateur doit inclure les primitives qui permettent de définir ce comportement, la gestion des colisions, de la gravité, etc... On doit pouvoir aussi simuler du bruit dans les capteurs afin de refleter des vrais capteurs. ** Affichage L'affichage doit être bien séparé du reste. Idéalement on doit pouvoir changer le code d'affichage sans altérer les capacités du programme. On pourrait faire plusieurs types de sorties : sorties fichiers, sortie 2D, sortie OpenGL. Il faut aussi prévoir de réinjecter la sortie OpenGL dans un capteur de camera. Il faut aussi prévoir plusieurs type d'interfaces : GTK, ligne de commande, fichiers de paramètres, mais aussi C++ si l'on veut faire un programme qui contrôle la simulation (pour apprentissage par exemple). ** Communication avec le programme du robot Les communications se limitent en gros à de l'échange d'informations sur les capteurs et les actionneurs. Il faut aussi prévoir une communication de l'horloge afin de faire des simulations en accéléré. Je pense qu'une communication de type réseau, c'est pas mal. On en aura besoin si on veut utiliser le simulateur comme moniteur temps réel, alors autant s'epargner de faire deux foit le travail. De plus il n'y a pratiquement aucune pénalité lorsqu'on fait du réseau sur une même machine. Ça permet aussi de laisse au programme du robot une entière liberté dans le séquencement des instructions, le simulateur limite les interférences dans le programme final au minimum. On choisira le TCP pour sa simplicité et parcequ'on ne veux pas réinventer la roue. De préférence un protocole texte. On peut baser les communications sur un échange de packets, chaque packet comporte un nom et une liste de variables avec un nom et un type. ** Séparation des modules Il faut que les modules soit le plus séparé possible, mais aussi le plus séparable possible. C'est à dire que l'on doit pouvoir facilement utiliser un module sans l'autre. * Méthodes de dévellopement ** Documents Pour le format des documents, je préconises les suivants : [AFT] c'est presque du texte et ça permet de générer du joli HTML. http://www.maplefish.com/todd/aft.html [DocBook] pour les plus gros doccuments. C'est structuré, c'est facile, on ne se prend pas la tête avec la mise en page, on peut sortir du HTML, du PDF, et d'autre encore, c'est un standard dans la documentation de projets libres. Je ne préconise _pas_ les formats suivant : [LaTeX] pas assez simple, c'est très bien pour un rapport mais ça ne convient pas si on fait de la documentation qui sera la plupart du temps lue en ligne (même si des convertisseur HTML existent). [OpenOffice.org] le meilleur moyen de ce prendre la tête avec les détails de mise en forme. De plus le format par défault n'est pas un format texte, donc inadapté à un stockage dans un CVS ou à un traitement automatique. [Microsoft Word] c'est mal. Il partage les inconvénients d'OpenOffice.org avec en plus un format propriétaire, un logiciel non libre et de plus couteux.