*Title: Spécifications du Simulotron *Author: Nicolas Schodet *TOC * Historique $Log: spec.txt,v $ Revision 1.5 2004/12/02 08:46:38 schodet fotes d'aurtografe, encore... Revision 1.4 2004/10/20 08:40:18 galmes correction de quelques fautes d'orthographe ! Revision 1.3 2004/10/11 13:19:49 schodet Précision des pécifications techniques, ajout de la couche capteurs/actionneurs. * 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'apprentissage (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 intérê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 plusieurs 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 caméra. 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 faudra 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 communautaire du style Savanah. ** Quelle licence ? La GPL. Car elle nous permet de faire un développement 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 collisions, de la gravité, etc... On doit pouvoir aussi simuler du bruit dans les capteurs afin de refléter des vrais capteurs. On peut représenter le monde par un ensemble de formes simples (boules, parallépipèdes, cylindres/cônes). On devrait pouvoir créer des objets comme une compositions de ces formes simples. Chaque objet a une masse et quelques propriétés comme la fixation (on ne veut pas que la table tombe), l'élasticité (pour gérer les collisions), le mode de collision (par exemple, un objet peut représenter la zone d'action d'un capteur et ne doit donc pas provoquer de chocs, il ne sert que pour détecter un obstacle). À chaque mise à jour du monde, le simulateur prend en compte les forces, accélérations, vitesses et positions des objets et calcules les nouvelles valeurs de ces paramètres. Toutes les informations ne serons peut-être pas disponible. Par exemple, un modèle de déplacement de robot ne simulera peut âtre pas la force exercée par les roues, mais directement le déplacement supposé. Il faut donc trouver un moyen de faire marcher tout ça ensemble (par exemple en recalculant l'accélération qui aurait provoqué ce mouvement, mais ce n'est pas forcément possible). On doit aussi gérer quelque choses pour les actionneurs du robot. On doit par exemple pouvoir embarquer des objets dans un autre (dans ce cas, l'objet est fixé dans le référentiel d'un autre) ou représenter un actionneur de type bras (par exemple qui pousse un autre objet alors que le robot ne bouge pas, le bras peut être alors un objet embarqué dans l'objet robot). En fait, on peut dire que chaque objets est embarqué dans un autre, ou dans le monde. Quand un objets est embarqué dans un autre, on peut simplifier et dire que cet objet reste solidaire de l'objet qu'il embarque, cela joue pour les collisions par exemple. Cette partie est aussi responsable de fournir les fonctions de "lecture" du monde pour un capteur. On doit par exemple avoir des fonctions de détections de collision Je pense que cette partie demande pas mal de réflexion sur le plan physique et mathématique. Il faudra donc prévoir un document là dessus. ** Affichage / interface 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 d'affichage : sorties fichiers, sortie 2D, sortie OpenGL. Il faut aussi prévoir de réinjecter la sortie OpenGL dans un capteur de caméra. L'affichage peut choisir d'utiliser les formes de bases définies dans les objets, mais ce sont des informations qui ne sont pas prévus pour l'affichage. La plupart du temps, l'afficheur utilise donc une représentation graphique pour chaque objet. Cette information n'est pas présente dans l'objet, c'est à lui d'associer l'objet (par son nom par exemple) à sa représentation graphique. 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). L'interface et la sortie sont à priori séparées, l'utilisation d'une interface ne doit pas forcer l'utilisation d'une sortie particulière. Toutefois, on pourrais imaginer vouloir cliquer sur une vue en 2D pour déplacer un objet. On peut aussi imaginer qu'un programme qui pilote la simulation veuille récupérer les résultats. Dans le cas d'un apprentissage, on veut aussi pouvoir visualiser la simulation en temps réel. Peut être que l'on peut fusionner interface et affichage dans un seul concept interface, qui peut faire des entrés et des sorties. Donc un peu de réflexion s'impose. ** Couche capteurs et actionneurs Il faudra trouver un joli nom pour cette partie. Cette partie héberge du code de conversion entre les donnés du robot et le simulateur. Coté actionneur, elle reçoit les messages du robot, chaque code actionneur reçoit le message et si il l'intéresse, l'interprète et converti les donnés en une action à effectuer sur un objet (embarquer un objet, déplacer, changer l'accélération, la vitesse...). Coté capteur, le code doit pouvoir utiliser les fonctions du simulateur pour calculer des distances, détecter les collisions, avoir la liste des objets embarqué dans un autre... ** 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'épargner de faire deux fois 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 paquets, chaque paquet comporte un nom et une liste de variables avec un nom et un type. En bonus, le système devrais accepter n'importe quel paquet afin de s'en servir aussi pour du débugage. ** 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éveloppement ** 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 documents. 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éfaut 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 coûteux. ** Coding standards Ne pas oublier d'aller les lire dans |d/dev/standards|. * Lexique Ne pas hésiter à changer si les termes sont ambiguës. [Monde] Ensemble des objets. [Forme simple] Élément de base permettant de représenter la forme des objets pour le simulateur physique. [Représentation graphique] Dessin 2D ou forme 3D utilisé pour l'affichage. C'est à dire, pas pour la simulation. [Interface] Permet de rentrer les paramètres de la simulation. [Affichage] Affiche, ou enregistre les résultats.