Re: Simulateur d'entrepôt, script et BGE : comment faire bouger un objet ?

Posté par mcBlyver le 28/9/2011 17:17:12

Ponzouâhr !
Après quelques jours (semaines) d'absence et donc de mise en pause de ce projet, je me vlà qu'est de r'tour.

Bon, j'ai bien tout lu en détails tous vos conseils, mais j'ai quand-même pas les idées beaucoup plus claires.
Vous allez me prendre pour un demeuré, m’en fou, c’est gratuit

1) Je ne vois toujours pas comment faire concrètement pour mettre à jour la position de mon cube à chaque itération.
Avec une variable globale, je veux bien, mais si l'objet ne change pas de position aussi souvent que la variable change
de valeur, ça laisse le problème entier (en tout cas pour ce que j'y comprends).

2) Puisque ça paraît si compliqué de déplacer un objet de manière fluide en calculant sa position dans une boucle,
alors pourquoi ne pas essayé avec la méthode des F-Curves ? Si j’arrive à définir une F-Curve dont la première Key
est la position de départ, la seconde Key est la position d’arrivée, je peux ensuite sortir du script pour exécuter la F-Curve, non ?

3) Bobibou : oui j’ai (en quelque sorte) un cahier des charges précis et rigide.
En fait cet entrepôt existe et fonctionne. Le fichier texte contenant les positions et les ordres est bien "réel".
Je ne sais pas encore exactement tout ce qu’il contient, mais c’est du code, avec de la doc, et j’ai les collègues qui connaissent.
Mais en quoi est-ce important pour le problème qui me bloque ? Je fais des essais avec un fichier et des positions 100% factices.

4) Il n’y a pas et n’aura pas d’obstacles à éviter. Ce n’est pas un parcours miné.
La fourche (sorte de bras ou grue robotisé) se déplace à l’horizontale sur un rail (c’est mon axe X)
Sur ce socle est fixé un espèce d’ascenseur (axe Z) qui peut bouger en même temps de l’axe X.
Ensuite, fixé sur l’ascenseur, on trouve une sorte de tiroir qui permet de prendre et déposer des caisses (cubes pour les essais)
qui sont placés sur des rayons à plusieurs étages de part et d’autre du rail de base.
Cet axe Y ne peut donc bouger que lorsque X et Z sont à l'arrêt complet, et que le tiroir est en face d'un "casier".

Alors quand on en arrive là, oui, il y a obstacle possible, dans le cas d’une erreur de programme, si la fourche doit
déposer une caisse sur un emplacement déjà occupé. Mais la fourche ne peut pas contourner, elle doit simplement renvoyer
un message d’erreur. Idem dans le cas d’un ordre pour prendre une caisse qui ne serait pas présente.
Le message est ensuite reçu par un autre logiciel, qui va chercher un autre casier libre par exemple,
et informer un utilisateur qu'il y a une erreur en cours.

En fait, ce système (le vrai, pas mon imitation) est entièrement automatisé, et par conséquent la base de donnée du logiciel
contient en permanence l’image exacte du stock réel (et inversement bien sûr). Si la fourche ne peut pas exécuter les ordres
qu’elle reçoit, il s’agit d’une erreur système (et donc un programmeur va se faire passer un savon) ou alors d’un problème mécanique
(et donc l’entreprise responsable de la maintenance va devoir intervenir).

Dans l'idéal (d'ici quelques milions d'années), mon bidule pourrait par exemple permettre de tester le programme
qui génère les ordres pour la fourche ou servir de démonstration pour des présentations à des clients.

Bon, je fais quoi moi maintenant (après avoir consacré un moment à remplir mon estomac qui manifeste actuellement
son désaccord avec mes horaires) ?