From 556b38f41a63b320dc26061abb5dc7319c59f236 Mon Sep 17 00:00:00 2001 From: schodet Date: Mon, 11 Oct 2004 13:19:49 +0000 Subject: Précision des pécifications techniques, ajout de la couche capteurs/actionneurs. --- i/simulotron/doc/spec.txt | 100 ++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 96 insertions(+), 4 deletions(-) (limited to 'i/simulotron') 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 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 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 [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. -- cgit v1.2.3