summaryrefslogtreecommitdiff
path: root/i/simulotron/doc/conception.txt
blob: d83eff4b7baf3732319f318305159a292c6382a0 (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
*Title: Le simulotron
*Author: Nicolas Haller

*TOC

* Introduction

Pour pouvoir faire du code correct et �tablir des strat�gies efficaces, il faut pouvoir les tester. Pour l'instant, la seule possibilit� consiste � tester directement sur le robot. C'est effectivement la solution la plus r�aliste mais pas forc�ment la plus simple � mettre en oeuvre parce que:
	* Faut un robot
	* Faut �tre � cot� du robot
	* Faut avoir du temps
	* Faut savoir comment marche le robot
	* Faut que le robot ait des batteries
	* Faut que personne utilise le robot
	* Faut une table

Tout cela sans pour autant avoir la certitude d'avoir tout les outils pour debugger.
C'est de la qu'est parti l'id�e du simulotron: avoir un simulateur de robot permettant de pouvoir tester les strat�gies et le code du robot, simplement, de chez soi.

Ce document issue de la r�union de conception (r�union de deux personnes) est l� pour poser les bases. Celle-ci sont discutable et modifiable, le but �tant d'avoir un beau simulateur utilisable assez facilement, modulable et surtout surtout, r�utilisable d'une ann�e sur l'autre sans avoir � tout recoder.

* Le dedans du Simulotron

Nous devons simuler un robot et tout ce qui va avec. Pour cela, le simulotron est divis� en plusieurs parties.

** Le moteur physique
Le moteur physique est ce qui nous permet de voir o� est le robot et ses amis les balles et totems et lapin Duracell sur la table de jeu. Le Simulotron devant �tre modulaire, le moteur doit pouvoir �tre interchangeable sans trop de probl�me par rapport au reste. Le but pour l'instant est de r�aliser un moteur physique simple rapidement mais pourquoi par la suite, de r�aliser un moteur plus ... Newtonnien?
*** Le moteur simple
Le but est de faire abstraction des equations m�caniques et des forces. Le moteur est divis�e en deux, le monde et le moteur � proprement parler. Le monde est constituer d'objet (table, robot, balle) ayant chaqu'un leur info et leur algo necessaire � leur evolution sur la table. Le moteur coordonne tout cela.

Pour faire simple, tout les objets ont une fonction (membre) qui r�gissent (est un con) leur comportement selon les donn�es qu'elle dispose. Elle est cens� connaitre tout de l'environnement et faire d�placer l'objet � sa nouvelle position. Chaque objet � egalement sa fonction de collision. Lorsque qu'un objet est en collision, il appelle la fonction de collision de l'objet en face et si celle-ci ne r�sout pas le probl�me, effectue une r�solution de collision standard.

** La gestion des capteurs avec le monde

C'est dans ces classes que sont g�r� les info et les ordres du robot. Ils ont conscience du monde physique, ils recoivent les requ�tes et ordres des �l�ments du robots et r�cup�rent (en les calculant) l'�tat des capteurs du robot. Il est capable de changer les info sur le robot (du moteur physique) voire sa position.
Cela dit, cela ne se limite pas au robot, il pourrait tr�s bien s'agir d'un lapin Duracell, en fait chaque entit� ayant un minimum d'information � faire circuler entre des programmes(asserv, IO)  et des capteurs peuvent avoir leur classe distinct.

** Le hub

Le hub est une classe centrale par qui passent toutes les communications entres les programmes du robot(ou d'une autre entit�) et les capteurs. Il est �galement responsable du temps de la simulotion. Pour le temps, il est necessaire de modifier un peu les programmes des cartes elec pour pouvoir �tre compatible. En effet, le Hub doit router les donn�es vers les bonnes classes g�rant les capteurs (et vice versa) et le temps. Le temps passe plus vite si tout le monde attend. Le temps passe d'un coup pour l'utilisateur jusqu'� ce qu'un truc fasse quelque chose, que ce soit une carte d'asservissement qui recalcul l'asservissement, une carte io qui se demande se qui se passe ou d'un moteur physique qui doit recalculer les positions.

** Les cartes elec

Enfin, le programme des cartes elec comme les programmes avr ou de la pc104 qui seront testables sans robot. Il est necessaires de changer deux ou trois lignes dans le codes pour pouvoir communiquer avec le hub notamment pour les timeout et les communications.

** Les autres modules du futurs

Le simulotron est cens� �tre modulable et il sera certainement necessaire de faire des extentions selon les besoins. Pour le moment, il est envisag� de faire un modules d'arbitres pour noter les actions du robot pour utiliser cela dans un algorithme g�n�tiques. Pourquoi �galement avoir un rendu en openGL de la simulation.

* Conclusion

Voil� l'id�e g�n�ral du simulotron. Ce programme peut nous apprendre plein de chose et nous faire avancer � grande vitesse dans la conception et la fiabilisation du robot et des strat�gies. Si je n'ai pas �t� clair, posez vos questions et modifiez ce fichier si vous avez des pr�cisions � apporter.