summaryrefslogtreecommitdiff
path: root/i/simulotron/doc/spec.txt
diff options
context:
space:
mode:
authorschodet2004-10-01 22:46:16 +0000
committerschodet2004-10-01 22:46:16 +0000
commit50ec61cbe0695d0325de9063fe31a3e4a463e9df (patch)
treebc51b134fa079d744cd82b1770dd168401504b7c /i/simulotron/doc/spec.txt
parent55b33a20a69479219745172575c4504acd52730d (diff)
Initial revision
Diffstat (limited to 'i/simulotron/doc/spec.txt')
-rw-r--r--i/simulotron/doc/spec.txt135
1 files changed, 135 insertions, 0 deletions
diff --git a/i/simulotron/doc/spec.txt b/i/simulotron/doc/spec.txt
new file mode 100644
index 0000000..3503eb2
--- /dev/null
+++ b/i/simulotron/doc/spec.txt
@@ -0,0 +1,135 @@
+*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 intéligence 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 beaucoups de
+temps, nécessiter un opérateur, être dangereux, s'user... bref on peut trouver
+un tas de raisons.
+
+Pourquoi de nombreux essais ? Parcequ'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 interret consiste aussi à utilise 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 systeme réutilisable, parcequ'on ne veut pas travailler pour rien.
+Il faut donc qu'il soit facile à adapter à n'importe quel type de robot.
+Biensur 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évellopement ?
+
+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évellopement
+comunautaire du style Savanah.
+
+** Quelle licence ?
+
+La GPL. Car elle nous permet de faire un devellopement 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 pourrais 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.