summaryrefslogtreecommitdiff
path: root/i/simulotron/doc/conception.txt
diff options
context:
space:
mode:
authorhaller2005-11-04 00:36:13 +0000
committerhaller2005-11-04 00:36:13 +0000
commitbdc39b12b0f36b5fbf09dacc51b1c1e6ed3abe81 (patch)
treee2b74178ae9cc1af77979b2a83720fced436dfbb /i/simulotron/doc/conception.txt
parent11d695dd9c52d37a823481c926ae3289215c9768 (diff)
Ajout du projet simulotron dans le SVN
Ajout d'une doc aft issue de la conception du simulotron (rapide)
Diffstat (limited to 'i/simulotron/doc/conception.txt')
-rw-r--r--i/simulotron/doc/conception.txt52
1 files changed, 52 insertions, 0 deletions
diff --git a/i/simulotron/doc/conception.txt b/i/simulotron/doc/conception.txt
new file mode 100644
index 0000000..d83eff4
--- /dev/null
+++ b/i/simulotron/doc/conception.txt
@@ -0,0 +1,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.