summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorschodet2004-10-11 13:19:49 +0000
committerschodet2004-10-11 13:19:49 +0000
commit556b38f41a63b320dc26061abb5dc7319c59f236 (patch)
treed99eb547c0f8fef01e032eaa50e22929b389d03e
parentf3dc7fc419e9b6581b223309a98f62e25ce46599 (diff)
Précision des pécifications techniques, ajout de la couche
capteurs/actionneurs.
-rw-r--r--i/simulotron/doc/spec.txt100
1 files changed, 96 insertions, 4 deletions
diff --git a/i/simulotron/doc/spec.txt b/i/simulotron/doc/spec.txt
index 7e5037b..dd3f5e1 100644
--- a/i/simulotron/doc/spec.txt
+++ b/i/simulotron/doc/spec.txt
@@ -1,8 +1,16 @@
-*Title: Spécifications du simulateur de robot
+*Title: Spécifications du Simulotron
*Author: Nicolas Schodet
*TOC
+* Historique
+
+ $Log: spec.txt,v $
+ 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 ?
@@ -69,19 +77,84 @@ colisions, de la gravité, etc...
On doit pouvoir aussi simuler du bruit dans les capteurs afin de refleter des
vrais capteurs.
-** Affichage
+On peut représenter le monde par un ensemble de formes simples (boules,
+parallépipèdes, cylindres/cones). 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
+suposé. Il faut donc trouver un moyen de faire marcher tout cas 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é dan 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 reflexion 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 de sorties : sorties fichiers, sortie 2D,
+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 camera.
+capteur de camera. 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 aprentissage, 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 sorites. 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 recoit les messages du robot, chaque code actionneur
+recoit le message et si il l'interresse, l'interprète et converti les donnés
+en une action à effectuer sur un objet (embarquer un objet, déplacer, changer
+l'accéleration, 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
@@ -102,6 +175,9 @@ 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.
+En bonus, le système devrais accepter n'importe quel packet 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
@@ -133,3 +209,19 @@ Je ne préconise _pas_ les formats suivant :
[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.
+
+** Coding standards
+
+Ne pas oublier d'aller les lire dans |d/dev/standards|.
+
+* Lexique
+
+Ne pas hésiter à changer si les termes sont ambigues.
+
+ [Monde] Ensemble des objets.
+ [Forme simple] Élément de base permettant de représenter la forme des
+ objets pour le simulateur phisique.
+ [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.