Applications

Nous montrons deux scénarios de démonstration en simulation. Toutes les simulations ont été réalisées sur un ordinateur fonctionnant sous Windows avec un processeur à 2, 5GHz. Nous avons pris un pas de temps de 1ms et nous avons utilisé la méthode d’intégration explicite d’Euler. Nous avons pris le robot humanoïde HRP-2 de Kawada Industries comme personnage de nos simulations. Ici nous ne cherchons pas à comparer la simulation avec la réalité, parce que les simulations que nous présentons ici sont difficilement réalisables sur le robot réel pour des raisons de sécurité ; nous traiterons cette partie dans le dernier chapitre. Nous voulons montrer ici que nous pouvons traiter des cas multi- contacts et ainsi réaliser des simulations complexes mettant en scène des systèmes complexes dans des environnements complexes avec des scénarios réalistes.

3.1.6.1 Exemples de simulation

Le premier exemple consiste à attraper un objet posé loin du robot sur une table (voir figure 3.5). Pour ce faire, le robot se penche en avant vers la table. Il utilise une de ses mains comme support sur la table pour qu’il ne puisse pas glisser et tomber. Cet exemple est en fait inspiré de la thèse d’Adrien Es- cande qui consiste à planifier des points d’appuis pour faire des mouvements acycliques [Escande, 2008]. OpenHRP ne permet pas de simuler HRP-2 en mouvements acycliques en multicontacts avec ce type de scénarios. Le coefficient de frottement est de 0, 4 entre chaque objet de la scène.

figure 3.5: Le robot HRP-2 attrape un objet sur une table.

Comme le montre la figure 3.5, un des mouvements générés par le planificateur permet de se rendre compte que lorsque le robot se penche en avant, ses pieds décollent de l’estrade et glissent vers l’arrière. Ce glissement s’arrête lorsque les jambes du robot entrent en contact avec la table. Le robot est suffisamment proche de celle-ci pour que ses pieds ne puissent pas glisser davantage. Cependant, grâce aux points d’appui sur la table avec sa main, le robot reste globalement stable et ne pivote pas sur le côté. Notre simulateur a donc permis de se rendre compte que le mouvement généré peut être dangereux dans certaines étapes de l’exécution de cette tâche, et un autre mouvement plus satisfaisant a donc été généré, simulé, puis porté sur le robot.

Dans le second exemple de simulation, nous demandons au robot de transporter une grosse boîte posée en travers sur ses bras d’un endroit à un autre (voir figure 3.6). En cours de route, le robot perd l’équilibre et tombe sur le côté. La boîte tombe alors aussi sur le sol ; donc les modèles de marche générés ne sont pas corrects (évidemment, nous n’avons pas porté cette expérience sur le robot). 3.1.6.2 Temps de calcul

Nous avons réalisé des tests de performances en prenant un plus grand nombre de points de contact (plus de 50 points) et nous avons fait une comparaison entre différentes approches des méthodes par contraintes (LCP et itérative). En particulier, avec 67 points de contact, la dimension de la matrice Λ est de taille 67 × 3 = 201 avec une approche itérative, alors qu’en gardant une approche LCP, en discrétisant le cône avec huit facettes, nous obtenons une matrice de taille 67 × (1 + 8 + 1) = 670. Nous voyons bien l’écart important d’un facteur d’environ huit entre les différentes approches, ce qui induit une augmentation sensible du temps de calcul. L’intérêt d’utiliser une approche itérative de

figure 3.6: Le robot HRP-2 porte une boîte lourde en marchant et perd l’équilibre.

type Gauss-Seidel pour des simulations interactives est clair. Bien sûr, avec la discrétisation des cônes de frottement on garde une formulation linéaire du problème et on résoud un problème linéaire alors qu’avec la formulation conique analytique des frottements, on résout un problème de petite taille mais non linéaire. L’avantage du second, en réalité, tient plus à la possibilité de régler la précision et le temps consacré à la résolution du problème, qu’à sa taille. En effet, la condition d’arrêt de l’algorithme est lorsque la variation de la solution est plus petite qu’une borne que l’on se fixe, on peut donc sacrifier la précision de la solution vis-à-vis du temps d’exécution, notamment lorsque les aspects temps réels priment (simulation interactive).

Par ailleurs, nous montrons en figure 3.7 le temps moyen pris par le micro-processeur pour traiter un pas de temps de la simulation en fonction du nombre de points de contact (qui donne une tendance de la complexité algorithmique). 0 10 20 30 40 50 60 70 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.4 0.45 Number of contacts Computation time (s)

figure 3.7: Temps moyen de calcul d’un pas de temps en fonction du nombre de points de contact. Nous voyons que le temps de calcul augmente de manière quasi-quadratique avec le nombre de points de contact. Plus le nombre de points de contact augmente, moins nous pouvons être proches

du temps réel et par conséquent nous ne pouvons pas prétendre faire véritablement de l’interaction haptique. Il est donc nécessaire d’optimiser le calcul des forces de contact.

En particulier, lorsque nous regardons la répartition du temps de calcul des différents modules de simulation sur un pas de temps (voir figure 3.8), nous nous apercevons que la détection de collision est la partie la plus coûteuse, suivie du calcul des forces de contact. Le problème de la détection de collision est toujours d’actualité dans le domaine de l’animation graphique, des solutions orientées hardware sont prometteuses de solutions définitives à ce problème, dans un futur qui ne nous paraît pas si lointain.

figure 3.8: Répartition du temps de calcul des différents modules du simulateur.

En revanche nous pouvons améliorer le temps de calcul des forces de contact. En particulier, la majeure partie du temps est passée dans le calcul de la matrice Λ. Nous allons maintenant voir comment nous pouvons accélérer ce calcul.