summaryrefslogtreecommitdiff
path: root/i/simulotron/doc/spec.txt
blob: dd3f5e1007cd7f7a9c43647719171eaac671c331 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
*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 ?

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'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 interr�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 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�veloppement ?

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�veloppement
comunautaire du style Savanah.

** Quelle licence ?

La GPL. Car elle nous permet de faire un developpement 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.

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 d'affichage : sorties fichiers, sortie 2D,
sortie OpenGL. Il faut aussi pr�voir de r�injecter la sortie OpenGL dans un
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
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.

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
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.

** 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.