summaryrefslogtreecommitdiff
path: root/i/simulotron
diff options
context:
space:
mode:
authorschodet2004-12-02 08:46:38 +0000
committerschodet2004-12-02 08:46:38 +0000
commit45ad90e1f9bacf53cc0a0e484ffa96044221633a (patch)
tree830d1ac6c45aac6c0a54c0e9d345c779dd38fa45 /i/simulotron
parentdc5e9a8ab529223d5c32e5d803b4516a28da9586 (diff)
fotes d'aurtografe, encore...
Diffstat (limited to 'i/simulotron')
-rw-r--r--i/simulotron/doc/spec.txt55
1 files changed, 29 insertions, 26 deletions
diff --git a/i/simulotron/doc/spec.txt b/i/simulotron/doc/spec.txt
index 5038897..ce5479b 100644
--- a/i/simulotron/doc/spec.txt
+++ b/i/simulotron/doc/spec.txt
@@ -6,9 +6,12 @@
* 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.
@@ -31,12 +34,12 @@ 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,
+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 interrêt consiste aussi à utiliser l'affichage du simulateur pour afficher
+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.
@@ -47,7 +50,7 @@ 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
+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
@@ -58,13 +61,13 @@ tourner le robot.
** Quel modèle de développement ?
-Libre bien sur ! Il faudrat d'abord faire une première version de base et
+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
-comunautaire du style Savanah.
+communautaire du style Savanah.
** Quelle licence ?
-La GPL. Car elle nous permet de faire un developpement utile au plus de monde
+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.
@@ -75,13 +78,13 @@ que notre simulateur continuera d'être libre.
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...
+collisions, de la gravité, etc...
-On doit pouvoir aussi simuler du bruit dans les capteurs afin de refleter des
+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/cones). On devrait pouvoir créer des objets comme
+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
@@ -92,8 +95,8 @@ chocs, il ne sert que pour détecter un obstacle).
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 ça ensemble (par
+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).
@@ -103,7 +106,7 @@ 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
+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.
@@ -137,10 +140,10 @@ 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
+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 sorites. Donc un peu de réflexion s'impose.
+entrés et des sorties. Donc un peu de réflexion s'impose.
** Couche capteurs et actionneurs
@@ -149,10 +152,10 @@ 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
+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éleration, la vitesse...).
+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
@@ -166,7 +169,7 @@ 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
+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
@@ -175,10 +178,10 @@ 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
+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 packet afin de s'en
+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
@@ -195,7 +198,7 @@ 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
+ [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.
@@ -206,12 +209,12 @@ Je ne préconise _pas_ les formats suivant :
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
+ 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 couteux.
+ non libre et de plus coûteux.
** Coding standards
@@ -219,11 +222,11 @@ Ne pas oublier d'aller les lire dans |d/dev/standards|.
* Lexique
-Ne pas hésiter à changer si les termes sont ambigues.
+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 phisique.
+ 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.