PoBot
De la dynamique dans la simulationObjectifs
Le simulateur réalisé en 2004 (voir l’article précédent) ne prenait en compte que l’aspect géométrique de l’environnement et des interactions entre les objets. C’est suffisant dans des contextes simples tel que celui dans lequel nous l’avions utilisé (Coupe de France 2004 - Coconut Rugby) L’environnement du scénario 2005 (le bowling) introduisait différents aspects que cette version ne prend pas en compte, tels que :
– un terrain non uniforme (fossé, ponts, socles des quilles)
– des objets à manipuler (les balles de GRS) et à bousculer (les quilles)
Il était donc temps de revoir la copie pour prendre en compte ces nouvelles exigences, et introduire la simulation de la dynamique des corps .
Travaux effectués
Soyons honnêtes : à la date de rédaction de cet article, cette nouvelle version n’est pas terminée. Plusieurs de ses composants sont par contre fonctionnels, chacun d’entre eux ayant servi à expérimenter les solutions aux divers problèmes à traiter.
L’environnement
Le format du descripteur d’environnement de la version précédente était insuffisant pour les nouveaux besoins. En effet, il fallait être capable de décrire des hiérarchies d’objets, pour l’assemblage des différents volumes élémentaires des ponts et de la table de jeu par exemple. Il fallait également introduire les définitions des matériaux, afin d’obtenir les couleurs les plus proches de la réalité, les teintes RAL étant converties en leur équivalents RGB dans ce but. Le robot 2005 intégrant une caméra embarquée pour la détection des ponts, quilles à abattre, quilles à relever, nous voulions aussi que le simulateur puisse nous fournir des images proches de ce que verrait la caméra réelle.
Conclusion : un nouveau format, basé sur XML, a été défini pour décrire l’environnement.
La dynamique
L’introduction d’un moteur de dynamique devenait nécessaire pour deux raisons :
– gérer correctement les collisions entre les objets (et non de manière simpliste et au cas par cas comme jusqu’alors)
– animer les objets de manière réaliste, en fonction de leurs interactions respectives (collisions, lancer,...)
Une première expérimentation a été faite avec ODE (Open Dynamics Engine), moteur open-source disponible sur le site ode.org. Bien que de bon niveau, il a posé quelques soucis, notamment par des comportements erratiques des cylindres : impossible de faire tenir debout les pyramides de quilles posées sur les socles (eux aussi cylindriques), car elles explosaient sans raison, comme si des ressorts comprimés avaient été placés entre elles. Après moult recherches, il semble que les cylindres à faces plates ne sont pas des objets faciles à vivre, et qu’ils font preuve d’instabilité selon l’ordre de grandeur de leurs dimensions. De plus, les bordures des ponts avaient parfois tendance à pénétrer les flancs des cylindres qui entraient en collision avec.
Bon, ben on cherche autre chose. Et c’est là que ma pomme est tombée sur Newton (d’habitude c’est l’inverse !!). Newton est un autre moteur de dynamique gratuit et libre d’utilisation (ses sources ne sont pas disponibles cependant), initialement écrit pour le développement de jeux. Il est disponible sur le site www.newtondynamics.com, et existe actuellement pour Windows, Linux et Mac OS-X. Il repose sur une approche un peu différente de la dynamique par rapport à la plupart des autres moteurs, qui le rend d’une part très efficace, mais surtout très réaliste. Sans entrer dans les détails, la différence de comportement peut être mise en évidence en construisant un pile de cubes, et en appliquant une impulsion horizontale à l’un des cubes pour le chasser de la pile. La plupart des moteurs donneront un comportement identique quel que soit le cube. Avec Newton, l’influence de l’ensemble des objects de la pile sitéus au-dessus du cube chassé est prise en compte (au travers des forces de frottements notamment), et celui-ci ne se comportera pas de la même manière selon qu’il sera tout en bas, au mileu ou vers le haut de la pile.
En conclusion, et comme beaucoup de ses utilisateurs le disent dans le forum qui lui est dédié : Newton rocks.
Ca a donc donné ceci :
Cette version intègre les possibilités suivantes :
– description de l’environnement statique et des objets via un fichier XML
– intégration du moteur de dynamique
– caméras multiples
Elle n’a pour finalité que de tester ce premier niveau d’intégration, en permettant à l’utilisateur de shooter l’une des balles de GRS pour aller culbuter les empilements de quilles. Et ça marche nickel 🙂
Remarque : le développement a été fait en Delphi et la 3D est gérée par GLScene comme précédemment (on ne change pas une équipe qui gagne)
La dynamique du robot
OK. Maintenant qu’on peut disposer d’un environnement de jeu vivant, il faut s’attaque au robot. Plus question en effet de se contenter de déplacer l’objet graphique représentant le robot comme dans la version précédente. Celui-ci va donc avoir une forme géométrique quelconque, des roues motrices, des stabilisateurs (ball-casters) et des moteurs. Il va se déplacer par application de couples sur les roues motrices, et va donc simuler les éventuels patinages ou glissements selon les accélérations ou les obstacles rencontrés.
Une deuxième application d’expérimentation a été développée, avec les mêmes outils de base : GLScene pour la 3D et Newton pour la dynamique. Là encore, c’est bluffant de réalisme, et en changeant les caractéristiques des matériaux (coeeficents d’élasticité, de friction statique, de friction dynamique,...), on peut s’amuser à toutes les variantes, y compris le Trophée Andros (courses auto sur glace pour ceux qui ne connaissent pas) avec un robot !
Et voilà le travail :
On peut constater que le robot a une forme complexe, la cavité contenant le releveur de quilles de la version réelle (ok, il n’a pas servi lors de la Coupe, comme beaucoup d’autres...)
Les modèles géométriques complexes
Now entering le terrain de golf de la Coupe 2006. Impossible à modéliser par assemblage de primitives géométriques simples, à cause des trous. En plus, il y a les distributeurs de balles.
Qu’à cela ne tienne : le terrain sera modélisé sous forme d’un maillage, chargé par le simulateur afin de définir un collider (forme géométrique utilisée pour la détection de collision) complexe. Ca encore, Newton sait le faire. Le format retenu pour le maillage est celui de 3D Studio Max car très répandu et directement reconnu par GLScene. Qui plus est, il est possible d’assigner des matériaux différents pour chaque facette, ce qui permet de définir simplement la couleur des trous et d’exploiter ensuite cette information pour le décompte des points.
Le nouveau bébé est ici :
Il permet de jouer au golf (ou plutôt au billard américain) avec les balles de ping pong (dont le comportement physique a été reconstitué via la définition de leur matériau). De plus, les distributeurs sont actifs, et on peut en libérer le contenu à volonté.
Et maintenant
Et bien, il faut assembler tout cela, et y ajouter la couche de gestion du contrôleur de robot de la version 2004. Il y a encore pas mal de boulot, mais je reste confiant 🙂
Vos commentaires
# Le 26 mars 2006 à 10:44, par lemerle pierre
En réponse à : De la dynamique dans la simulation
Bonjour,
ODE est assez simple à utiliser avec glscene, du fait de son intégration via les composants ODEmanager, ODEjoints et autres.
J’ai lu, et votre article très intéressant en est un autre témoignage, que Newton est plus rigoureux et réaliste qu’ODE ; En revanche, il semble + hermétique.
Les exemples disponibles sur http://newton.delphigl.de/ ont été développés avec la bibliothèque dglopengl et non pas glscene.
Est il possible d’avoir qq sources de programmes réalisés en combinant glscene et Newton. Cela m’aiderait à comprendre +rapidement les principes du moteur physique. Je n’ai pas trouvé de sources exemples réalisés avec glscene sur le web.
Merci de votre aide et encore bravo pour votre travail.
# Le 26 mars 2006 à 23:38, par Eric P.
En réponse à : De la dynamique dans la simulation
Bonjour,
ODE est effectivement simple à utiliser, même sans recourir aux composants d’interface avec GLScene. Personnellement, je l’avais utilisé directement, et gérais moi-même la connexion avec GLScene, ce qui est assez simple.
Par contre, j’ai recontré quelques problèmes de comportement physique, notamment lorsque je travaillais au simulateur du bowling 2005. En effet, pas moyen de faire tenir en place les pyramides de quilles posées sur un socle : l’ensemble "explosait" comme s’il y avait des ressorts entre les quilles du bas, et cela semblait très sensible aux ordres de grandeur des dimensions des objets. En échangeant avec un des ardents défenseurs d’ODE (Koom, aka Dave Gravel), j’ai fini par constater qu’il devait y avoir un réel problème, car les seuls exemples qu’il m’avait passés à l’époque pour me montrer que ça devait marcher ne fonctionnaient plus dès lors que j’utilisais la configuration problématique (pyramide de 4 quilles posée sur un socle lui-même cylindrique) et des dimensions dans les ordres de grandeur de mon pb (de l’ordre de la dizaine de cm). Il avait quand même reconnu que les cylindres à extrémités plates posaient pb.
Ne trouvant pas de solution satisfaisante, j’ai commuté sur Newton qui s’est lui comporté parfaitement.
Quant à la connexion entre Newton et GLScene, elle est assez facile (de même nature que celle avec ODE), et je trouve qu’il est plus simple de la faire soi-même que d’en passer par les composants TGLBehaviour (des composants de connexion GLScene/Newton avaient été développés par un des membres du forum il y a un peu plus d’un an, basés sur le behaviours comme dans le cas d’ODE).
Pour faire en sorte que les objets graphiques "suivent" les objets physiques, coder un set-transform callback ressemblant à ceci :
procedure SetTransformCallback(const Body : PNewtonBody ; const Matrix : NewtonImport.PFloat) ; cdecl ; var GLObject : TGLBaseSceneObject ; begin // récupération de l'objet graphique associé au body (lien préalablement stocké dans les user data du body // par un NewtonSetUserData lors de la création du body et de l'objet graphique associé GLObject := TGLBaseSceneObject(NewtonBodyGetUserData(Body)) ; if (Assigned(GLObject)) then // mise à jour de la position de l'objet graphique avec celle calculée par Newton GLObject.Matrix := pMatrix(Matrix)^ ; end ;Ce callback est "activé" via une instruction du style :
lors de la création des body. A noter qu’on peut avoir des callbacks différents si besoin est (si on veut faire autre chose que la mise à jour de la position de l’objet GLScene, ou faire quelque chose en plus)
L’autre callback important est celui qui définit la force et le couple à appliquer à un body, et qui peut ressembler à ceci :
dans le cas où seule la gravité intervient sur un objet par exemple. la connexion entre un body et ce callback se fait par :
que l’on fait en général au moment de la création du body, souvent au même endroit que le NewtonBodySetTransformCallback vu précédemment.
Bon, OK, je reconnais que c’est un peu succint comme explication, mais c’est pour te montrer que la connexion Newton/GLScene est du même ordre de complexité que celle de ODE/GLScene.
Encore un truc : en plus de la meilleure exactitude physique de Newton que tu mentionnes d’ailleurs, ODE semble un peut mort depuis quelques temps. Je n’ai pas vu le site bouger depuis longtemps et n’ai pas non plus vu de mise à jour de la lib depuis bien longtemps. Newton de son côté évolue constamment, et son auteur Julio Jerez est très accessible et réactif. De plus, le forum Newton est plutôt vivant.
Question sources, je n’ai malheureusement pas d’appli simple sous la main, et si je te balances les sources de mes simulateurs, ça risque d’être indigeste 🙂 Je vais essayer de coder un petit truc rapide et te l’envoyer. Passe-moi ton adresse email en m’écrivant à eric at pobot dot org.
Cordialement
Eric
Répondre à ce message