Compte rendu de la réunion du 17/12/2003 |
Date : 06/01/2003 |
1ere version planning, nouvelle version SIMULTAOM |
Groupe D, Projet 14 |
Pour Michel Dubois et Yann le Guyadec |
Questions et réponses
|
Qu'apporte la nouvelle version? |
Des bugs ont été corrigés. Il est maintenant possible de lier les pattes d'une “chenille”. La fonctionnalitée de détection des pattes touchant le sol a été implentée( fonction isOnGround() ). |
|---|---|
|
Le plug-in pour Eclipse est-il opérationnel? |
Il fonctionne mais quelques problèmes restes à régler avec SIMULATOM. |
I/ Nouvelles arborescence.
La mise en place d'une 'nouvelle arborescence' a été faite, ce qui permet l'utilisation de classe dans des .h et .cpp dans différents dossiers. Cette fonctionnalitée nous permettrait de créer de nouvelles classes personnalisées.
Pour être sur qu'il n'y est pas de probleme, une compilation à la racine est préferable.
II/ Molécules à réaliser.
1)Processus de création:
Nous envisageons de mettre en place les algorithmes de créations des molécules dans un premier temps. Puis de nous occuper de leur déplacement.
2)Formes de molécules:
Nous avons choisis de prendre comme molécules:
L'atome seul.(marcheur ou glisseur)
La ligne d'atomes.
La roue d'atomes.
Le tapis d'atomes.
Le cube d'atomes.
III/ Fonctionnement des moteurs.
Les pattes d'un atomes peuvent se positionner dans un cone d'angle 45° par rapport à l'axe central.

Un problème est apparu lors des tests de l'API. Il est impossible de faire comprendre a une patte de continuer les commandes stockées dans leur file d'attente respective seulement lorsque la patte est à une certaine position.
*Exemple :
La patte de l'atome est en 0,0. On envoie les commandes suivantes (mode KEEP) :
allez en 127 pour moteur 0
allez en 0 pour moteur 1
allez en 255 pour moteur 0
allez en 255 pour moteur 1
Nous voulons absolument que la pattes passent par les position 127,0 et 255,255. Le problème est que pour l'instant la patte ne passera pas par le point 127,0. En effet, dès le début le moteur 1 verra qu'il est déjà en 0 et donc il ira directement à la position 255 alors que l'autre moteur sera toujour a la première commande qu'il lui avait été assigné. Ce comportement peut être un avantage mais aussi un inconvénient, cela dépend du résultat que l'on souhaite obtenir. Mais il serait très utile de pouvoir envoyer une suite de commandes dont nous sommes sur du resultat qu'elles produiraient quelques soit les 'distances' parcouru par la patte.

Une question se pose alors : ceci doit-il être la source d'une nouvelle fonctionnalitée de l'atome ou alors la mise en place d'une attente active en dehors de l'atome?
Exemple de fonctionnalitée de l'atome qui pourrait être implentées (avec l'exemple précedent) :
*code sans la fonctionnalitée (mais problème d'ordonnancement) :
atoms[k]->getLeg(2)->getServoMotor(0)->setTargetPosition(127,KEEP);
atoms[k]->getLeg(2)->getServoMotor(1)->setTargetPosition(0,KEEP);
atoms[k]->getLeg(2)->getServoMotor(0)->setTargetPosition(255,KEEP);
atoms[k]->getLeg(2)->getServoMotor(1)->setTargetPosition(255,KEEP);
*code avec la fonctionnalité :
atoms[k]->getLeg(2)->getServoMotor(0)->setTargetPosition(127,KEEP);
atoms[k]->getLeg(2)->getServoMotor(1)->setTargetPosition(0,KEEP);
atoms[k]->getLeg(2)->setWaitingPoint(); //nouvelle
fonctionnalité
atoms[k]->getLeg(2)->getServoMotor(0)->setTargetPosition(255,KEEP);
atoms[k]->getLeg(2)->getServoMotor(1)->setTargetPosition(255,KEEP);
La fonction setWaitingPoint() permettrait à la patte n°2 de l'atome k (dans ce cas ci) d'attendre que toutes les commandes lancées précedement pour les moteur 0 et 1 de cette même pattes soit terminer. Ensuite, les commande suivante pourrait être executée.