summaryrefslogtreecommitdiff
path: root/i/simulotron/doc/spec.txt
blob: 7e5037b1d491c320cdcf705ca3646fa166356a41 (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
*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 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.

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