Fressier Master 06

RAPPORT DE STAGE DE MASTER 2 RECHERCHE
Amlioration de la perception des contacts et des chocs entre solides

rigides par retour haptique
Amandine Fressier
Sous la direction de : Georges Dumont
Introduction
Un des enjeux essentiels de la ralit virtuelle est de permettre de manipuler des objets
virtuels comme s'ils taient rels. Cela implique de restituer les phnomnes naturels le plus
dlement possible. Pour ce faire, il faut tudier les modles mcaniques qui rgissent le
mouvement des objets, et notamment s'intresser aux interactions entre objets. En eet, le
traitement des chocs et des contacts est primordial pour avoir une sensation de manipulation
raliste avec un priphrique retour d'eort.
Des travaux concernant le traitement des chocs et des contacts ont dj t mens au
sein de l'quipe SIAMES. Ces travaux ont conduit dvelopper de nouveaux algorithmes
de rsolution. Ces algorithmes sont bass sur des paramtres mcaniques, ils sont donc
performants au niveau du ralisme des interactions. Ils sont galement performants au niveau
des temps de calcul puisqu'ils permettent de simuler les interactions entre 160 billes en temps
rel [Dum05].
D'autres travaux, au sein de l'quipe, ont permis l'intgration de priphriques retour
d'eort pour piloter des simulations de ralit virtuelle mais il reste encore des progrs
faire concernant la contrainte temps rel et la qualit de la perception.
Nous nous intresserons ici au couplage entre ces nouveaux algorithmes performants et
les priphriques haptiques dans le but d'amliorer la qualit de perception des chocs.
Dans ce rapport, nous commencerons par expliciter quelques notions utiles la comprhension du problme. Nous exposerons ensuite quelques mthodes de dtection de collision
puis nous nous intresserons aux mthodes de dtermination des eorts d'interaction que ce
soit pour des contacts ou pour des chocs, en nous appuyant sur les travaux de Jean-Marie
Souez [Sou02] et de Mathieu Renouf [RAD05]. Nous exposerons alors les enjeux propres
au couplage de ces algorithmes avec les priphriques haptiques. Dans la deuxime partie
qui concerne la conception et la mise en uvre du couplage, nous commencerons par expliquer le concept sous-jacent ce stage puis, aprs avoir prcis le cadre de notre travail,
nous dtaillerons l'implmentation des dirents modules. Nous conclurons en prsentant
les perspectives envisages.
Amandine Fressier
Table des matires

I tude bibliographique prliminaire
1 Quelques dnitions
1.1
1.2
Rappels . . . . . . . . . . . . . . . . . . . . .
1.1.1 Scne virtuelle . . . . . . . . . . . . .
1.1.2 Temps rel . . . . . . . . . . . . . . .
1.1.3 Retour haptique . . . . . . . . . . . .
Gnralits sur le traitement des interactions
2 Traitement des interactions

2.1
2.2
Dtection des interactions . . . . . . .

2.1.1 Enjeux . . . . . . . . . . . . . .
2.1.2 Quelques techniques . . . . . .
Dtermination des eorts d'interaction
2.2.1 Mise en quations . . . . . . .
2.2.2 Mthode de pnalisation . . . .
2.2.3 Dynamique non rgulire . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Couplage
3.1
3.2
7
7
7
8
8
11
11
11
12
14
14
15
15
22
Dnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Problmatique du couplage temps rel . . . . . . . . . . . . . . . . . . . . . . 23
II Conception et mise en uvre du couplage entre le simulateur

dynamique et le bras retour d'eort
27
4 Concept
4.1
4.2
4.3
4.4
Rappels sur la dtermination des eorts d'interaction

Le couplage virtuel . . . . . . . . . . . . . . . . . . .
Notre proposition . . . . . . . . . . . . . . . . . . . .
Les rsultats attendus . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
29
31
31
32
Irisa
5 L'environnement
5.1
5.2
OpenMASK . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Description gnrale . . . . . . . . . . . . . . .
5.1.2 La programmation dans OpenMASK . . . . . .
5.1.3 L'objet de simulation OpenMASK . . . . . . .
5.1.4 La visualisation dans OpenMASK . . . . . . .
ConF&TiS (Contacts, Frottements & Time Stepping)
5.2.1 Description . . . . . . . . . . . . . . . . . . . .
5.2.2 Utilisation . . . . . . . . . . . . . . . . . . . . .
5.2.3 Principe de fonctionnenemt . . . . . . . . . . .
5.2.4 Dtails de l'architecture . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
L'architecture choisie . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le simulateur dynamique . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Dtails de l'architecture . . . . . . . . . . . . . . . . . . . . .
6.2.2 Vers une plate-forme idale . . . . . . . . . . . . . . . . . . .
Le module d'interaction . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Quel type de picking ? . . . . . . . . . . . . . . . . . . . . . .
6.3.2 Les direntes solutions . . . . . . . . . . . . . . . . . . . . .
6.3.3 Bilan sur le module d'interaction . . . . . . . . . . . . . . . .
Le couplage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1 Prcisions concernant l'existant . . . . . . . . . . . . . . . . .
6.4.2 Modications eectues . . . . . . . . . . . . . . . . . . . . .
6.4.3 D'un point de vue OpenMASK . . . . . . . . . . . . . . . . .
6.4.4 Reprsentation OpenMASK du priphrique retour d'eort
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Conception des dirents modules

6.1
6.2
6.3
6.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
33
33
33
34
34
35
35
35
36
36
37
39
39
40
40
45
46
47
48
52
52
52
53
54
55
7 Synthse de la mise en uvre
57
8 Conclusion
60
Amandine Fressier
Irisa
Premire partie
tude bibliographique prliminaire
Stage de Master 2 Recherche
Chapitre 1
Quelques dnitions
Il y a quelques pr-requis ncessaires pour pouvoir aborder le reste de ce rapport. En
eet, notre sujet est assez large puisqu' il traite des interactions d'un utilisateur avec des
objets virtuels. Il faut donc avoir des notions concernant la modlisation du monde virtuel
mais aussi concernant les contraintes qu'imposent l'interaction avec un utilisateur. Ce sont
ces notions et quelques autres que nous allons dtailler dans les paragraphes suivants.
1.1 Rappels
1.1.1 Scne virtuelle
Une scne virtuelle est compose d'objets ayant des proprits spciques (forme, position, matriau, couleur...). Les traitements de la scne, quelqu'ils soient (calcul de rendu,
traitement des interactions...) se basent sur ces proprits.
Pour calculer une animation, on discrtise le temps en intervalles rguliers et on calcule
les nouvelles positions des objets pour chaque pas de temps. Plus le pas de temps est petit
meilleure est la qualit de l'animation, mais le nombre de calculs augmente considrablement,
ce qui pose problme lorsqu'on doit tenir compte de la contrainte temps rel.
1.1.2 Temps rel

La notion de temps rel est lie l'immersion de l'utilisateur dans l'environnement virtuel.
En eet, il faut que l'utilisateur puisse interagir de faon "naturelle" avec les constituants
du monde virtuel. Par exemple dans le cas de la restitution visuelle, si l'utilisateur bouge
un objet virtuel, il faut que le dplacement de cet objet s'ache "en temps rel". Cela pose
des contraintes fortes sur les temps de calcul des algorithmes. Pour que l'on puisse parler
de temps rel, il faut que le temps de calcul soit infrieur au temps simul, de manire
ce que les informations calcules soient prsentes l'utilisateur au bon moment. De faon
plus simple : il faut que le logiciel calcule assez vite pour que la simulation soit raliste.
Projet Siames
Amandine Fressier
Il y a plusieurs types de temps rels : le temps rel dur avec un noyau temps rel qui
assure que les entres/sorties se font dans un temps compatible avec la contrainte temps
rel. L'autre type est le temps rel souple qui assure simplement que si le temps de tous les
calculs est plus court que le temps simul alors la contrainte temps rel sera respecte.
Le temps rel pour une application visuelle ncessite un taux de rafrachissement de
l'ordre de 30Hz au minimum : une trentaine d'images par seconde, l'utilisateur l'impression que l'animation est continue. Mais pour une bonne immersion du sujet, la frquence
est plutt de l'ordre de 60Hz (pour les jeux vidos, ou bien pour la vision stroscopique
puisqu'on a deux images calculer). Par contre, pour ce qui est du retour haptique, ce taux
est plutt de l'ordre de 300Hz voire de 1000Hz pour certaines applications [HS04].
1.1.3 Retour haptique

Dans notre cas, l'utilisateur interagit avec les objets de la scne virtuelle par le biais
d'un priphrique haptique, on appelle cela le retour haptique. Le retour haptique concerne
tout ce qui est relatif au toucher. On distingue deux types de retour haptique qui ont des
fonctions direntes.
Le premier est le retour d'eort qui concerne la perception des forces de contact, de
poids et d'inertie d'un objet. C'est celui auquel nous nous intressons. Pour la manipulation
d'objets, sans collisions, une frquence de 300Hz sut, par contre pour restituer correctement
un choc, il faut une frquence de 1000Hz.
L'autre type de retour haptique est le retour tactile qui concerne la perception des
surfaces (texture, rugosit). Pour permettre de distinguer des textures nes, il faut des
frquences de l'ordre de 1000Hz alors que des textures plus grossires ne ncessitent que
quelques centaines de Hertz.
1.2 Gnralits sur le traitement des interactions

Le traitement des interactions ncessite de bien connatre les caractristiques des solides
interagissants puisqu'il s'appuie non seulement sur leur forme mais aussi sur leur mouvement.
Un solide virtuel est modlis par deux entits, un modle gomtrique qui est l'ensemble
de polygones dnissant la surface de l'objet et un modle physique (ou dynamique) qui
contient les proprits ncessaires au mouvement du solide. Le traitement des interactions
utilise donc ces deux modles.
Une des premires choses savoir pour pouvoir traiter les interactions est le type des
solides : rigide ou dformable ?
On ne s'intresse ici qu' la notion de "localement dformable", en eet, lors d'un choc
rel, les solides se dforment localement, l'endroit de l'impact, ce qui provoque leur rebond.
Irisa
Cette dformation locale et trs ponctuelle ne se modlise pas par un changement de frontire
mais plutt par des quations appropries au point de contact [PPG04].
On appelle solide rigide un solide qui a une forme constante dans le temps. Nous nous
intressons ici ce type de solide pour des raisons de temps de calcul. En eet, la prise en
compte de la dformation locale des solides lors du choc est plus coteuse (car on rajoute
des quations pour modliser cette dformation) mais pourtant, mme pour la modlisation
de solides rellement rigides, il serait intressant de les considrer comme partiellement
dformables car c'est ce qui se passe dans la ralit. On obtiendrait donc une plus grande
prcision dans le rendu des interactions.
Les interactions
Une interaction a lieu quand deux solides en mouvement se rencontrent. On peut tre
plus prcis en sparant les interactions en deux catgories : les chocs (impacts) caractriss
par leur brivet et qui provoquent le rebond des solides (liaison phmre) ; les contacts
qui durent dans le temps (liaison persistante).
Quelque soit le type des interactions, leur traitement se dcompose en deux parties : la
dtection gomtrique et le traitement des interactions lui mme c'est dire la rsolution des
quations de mouvement (ce que l'on appelle aussi, dans ce rapport, la dtermination des
eorts d'interaction). La dtection gomtrique sert dterminer quels sont les objets qui
entrent en collision et leurs points de contact. Lorsqu'un contact est dtect il faut modier
les quations de mouvement des solides de faon se qu'ils ne s'interpntrent pas.
La partie simulateur dynamique de la gure 1.1 reprsente le schma caractristique
d'un algorithme de traitement des interactions. Tout d'abord, les solides virtuels sont en
mouvement, la rsolution des quations de mouvement se situant dans une partie prcdant
le traitement des interactions, nous ne la dtaillerons pas dans ce rapport. On peut nanmoins
prciser qu'il s'agit de rsoudre des quations direntielles par une intgration temporelle
classique. Lors du mouvement des solides, tout moment, l'algorithme de dtection vrie
s'il y a des intersections. Si c'est le cas, il renvoie la liste des objets en contact et il faut
alors modier la rsolution des quations de mouvement pour prendre en compte l'eet de
l'interaction sur le mouvement des solides et assurer la non-pntration [Dum05].
La partie couplage de la gure 1.1 reprsente le coeur de notre sujet de stage et nous la
dtaillerons plus loin.
Projet Siames
10
Amandine Fressier
Fig.
1.1 Schma caractristique d'une simulation haptique
Irisa
11
Chapitre 2
Traitement des interactions

Aprs avoir expos les deux lments invoqus dans le problme des interactions, nous
allons maintenant envisager les direntes tapes du traitement des interactions, savoir la
dtection gomtrique et la dtermination des eorts d'interaction.
2.1 Dtection des interactions

Nous allons prsenter ici quelques mthodes de dtection gomtrique des interactions.
Nous commencerons par exposer les enjeux de la dtection de collision puis nous exposerons
direntes techniques de dtection.
2.1.1 Enjeux
Le but de la dtection de collision est de signaler automatiquement un contact gomtrique quand il va se produire ou quand il vient de se produire [LG98]. Ce problme tant trs
courant dans de nombreux domaines comme la robotique, l'animation, la synthse d'image
ou encore la ralit virtuelle, il est donc trs tudi et on trouve dans la littrature beaucoup d'outils spciques. On s'aperoit nanmoins que les exigences vis vis des dirents
dtecteurs sont semblables : ils doivent tre rapides et prcis.
rapides : pour pouvoir notamment tre intgrs des applications mettant en uvre
un environnement virtuel. En eet, l'interactivit avec l'utilisateur tant primordiale,
on cherche minimiser les temps de calcul et atteindre le temps rel. De plus, mme
sans avoir la contrainte temps rel, les scnes devenant de plus en plus complexes,
on doit tre capable de grer en un temps raisonnable un nombre toujours croissant
d'objets mme de provoquer de nombreuses collisions.
Projet Siames
12
Amandine Fressier
prcis : ils sont la base du traitement des interactions. Les algorithmes de restitution
des chocs ou des contacts s'appuient sur les rsultats des dtecteurs, une erreur ce
niveau aurait donc des rpercutions dans toute la chane de traitement des interactions.
En eet, l'algorithme de dtermination des eorts se base sur les rsultats fournis par
le dtecteur, si ces rsultats sont errons, alors le calcul des eorts ne sera pas pertinent
et la restitution haptique sera de mauvaise qualit.
L'enjeu lors du dveloppement d'un dtecteur est donc de trouver un compromis, adapt
l'application vise, entre le temps de calcul des intersections et la prcision demande. Nous
allons maintenant voir quelques mthodes qui se sont attaches optimiser ce compromis.
2.1.2 Quelques techniques

Nous avons vu que les applications utilisant un dtecteur n'ont pas toutes les mmes
besoins. C'est pour cela qu'il existe deux techniques de dtection des collisions, une technique
continue et une technique discrte.
Une mthode de dtection des collisions continue prvoit, en extrapolant, l'instant du
contact et sa gomtrie (l'interpntration est prvue et le pas de temps adapt en consquence). Une mthode dite discrte ne reportera le contact qu'une fois celui-ci eectif (ce qui
impose bien souvent un retour en arrire des simulations pour dterminer la conguration
acceptable du contact) [MAS03].
Techniques discrtes
Les techniques discrtes sont utilises par des applications de simulation raliste mais
sans contrainte de temps rel, le retour en arrire tant coteux en temps de calcul.
Pour dtecter les interactions dans une scne, une des premires ides est de tester les interactions entre chaque polygones de la scne. Cette mthode permet d'obtenir des rsultats
corrects mais le temps de calcul est loin d'tre minimis. On peut rduire le nombre de tests
en remarquant que deux polygones loigns dans la scne ne connatront pas d'interaction
au pas de temps suivant. Cela conduit structurer la scne en rassemblant les objets voisins
et en limitant les tests ces objets.
Il y a deux approches majeures qui permettent d'liminer rapidement les tests inutiles :
les volumes englobants et la dcomposition spatiale.
La technique des botes englobantes a plusieurs variantes. La technique des botes englobantes alignes sur les axes a notamment t utilise par Cohen et al. [CLMP95] pour
dterminer quelles sont les paires d'objets qui peuvent entrer en collision. Les botes sont
places dans des listes correspondant aux axes du repre et ces listes sont tries dynamiquement. Le test d'intersection n'est eectu que pour les botes se chevauchant. Un tel
Irisa
13
algorithme est appel "Sweep and Prune". Les auteurs ont amlior les performances en utilisant le fait que les objets ne bougent pas beaucoup d'un pas de temps l'autre (cohrence
spatiale et temporelle de la scne). Ils ont ainsi implment un algorithme en O(n + m), o
n est le nombre d'objets de la scne, et m est le nombre d'objets trs voisins.
Une autre variante des botes englobantes consiste orienter les botes, c'est dire qu'elles
ne sont plus alignes sur les axes de la scne mais sur les axes dnis par l'objet [GLM96]. On
parle alors de OBBTrees (Oriented Bounding Box Trees). Chaque noeud de l'arbre est une
bote englobante, la racine englobant un objet entier et les feuilles des primitives. L'intrt
de cette variante est que l'on peut ainsi reprsenter n'importe quelle forme d'objet et pas
seulement des objets connexes.
Le problme des hirarchies de volumes englobants est que les arbres peuvent tre trs
profonds pour des modles complexes et le parcours pour trouver le point de contact exact
prend du temps.
La subdivision spatiale consiste quant elle diviser l'espace par des cellules et placer
chaque objet (ou bote englobante) dans ces cellules. Pour dterminer s'il y a collision il faut
examiner les cellules occupes par chaque bote et vrier si ces cellules sont partages par
d'autres objets. Cette mthode est coteuse en mmoire et peut devenir trs coteuse en
temps de calcul si la taille des cellules n'est pas approprie la scne. Pour diminuer le cot
mmoire, certains auteurs utilisent des tables de hachage.
Conscients des limites de ces deux approches, Gregory et al. [GLGT00] ont propos un
algorithme hybride tirant parti des avantages respectifs de ces approches. Ils prcalculent
une hirarchie hybride des objets. L'espace virtuel est d'abord partitionn par une grille uniforme, puis pour chaque cellule non vide, ils calculent un OBBTree reprsentant le contenu
de la cellule et stockent un pointeur associ l'OBBTree dans une table de hashage. Lorsque
l'on veut dterminer s'il y a collision, on cherche d'abord la cellule puis on regarde quel(s)
OBBTree(s) de la cellule sont concerns. Les auteurs utilisent galement la cohrence temporelle et spatiale pour amliorer les performances de leur algorithme. Grce cette approche
ils arrivent un temps de calcul acceptable pour le temps rel haptique (frquence en kHz)
sur des scnes relativement complexes (plusieurs dizaines de milliers de polygones).
Une technique continue

Les mthodes de dtection continues sont connues pour tre plus lentes que les mthodes
discrtes et sont donc peu utilises. Pourtant, elles orent des avantages incontestables : elles
dtectent l'instant exact de la collision, il n'y a donc pas d'interpntration entre les objets.
Des travaux rcents par Redon et al. [RKC02] ont permis de prsenter un algorithme rapide
de dtection continue. Leur algorithme est capable de calculer des frquences leves (en
kHz) les intersections entre des objets complexes (dizaines de milliers de polygones). De
plus il n'impose aucune contrainte sur la topologie des objets. Leur mthode s'appuie sur
l'arithmtique des intervalles ainsi que sur les hirarchies de botes englobantes. Le principe
Projet Siames
14
Amandine Fressier
est de dterminer si deux botes englobantes orientes (OBB) se chevauchent sur un intervalle
de temps. L'arithmtique des intervalles est utilise pour dterminer l'instant de la collision
et la hirarchie de botes englobantes aide liminer des tests inutiles. Redon et al. utilisent
galement diverses heuristiques pour amliorer les temps de calcul.
Conclusion
Ce bref tat de l'art de la dtection de collision nous permet de noter qu'il y a

des algorithmes performants mme pour les contraintes poses par le retour haptique. Nous
retiendrons notamment ceux de Gregory et al. qui ont de bonnes performances en temps
de calcul. Par ailleurs, il serait peut tre souhaitable de travailler avec des algorithmes de
dtection continus (Redon et al.) car le fait qu'ils dterminent l'instant exact de la collision
vite les retours en arrire (qui peuvent poser des problmes pour le temps rel). Par contre,
de tels algorithmes adaptent le pas de temps pour que l'instant de la collision concide avec
un pas de temps de calcul, cela peut donc poser des problmes de synchronisation entre les
dirents processus du simulateur dynamique.
Nous venons donc voir qu'il existe des algorithmes adapts au temps rel haptique,
nous pouvons maintenant nous intresser l'tape suivante : la dtermination des eorts
d'interaction.
2.2 Dtermination des eorts d'interaction

Cette partie correspond aux vignettes gauche et droite de la gure 1.1 puisqu'elle expose
les quations de mouvement, que celui-ci soit libre (vignette gauche) ou contraint (vignette
droite). Nous allons commencer par formaliser le problme de la dtermination des eorts
d'interaction puis nous prsenterons les deux approches mises en uvre pour le rsoudre.
2.2.1 Mise en quations

quation de la dynamique
Quand on dcrit le problme du contact entre deux solides rigides en terme de vitesses,
on obtient l'quation suivante :
M (q) = Q(q, q, t) +
q
(2.1)
M (q) est la matrice d'inertie du systme, Q(q, q, t) est le terme qui exprime l'ensemble
des eorts externes (y compris les termes de Coriolis et d'entranement) et R est le

vecteur des forces globales de contact. Quand il n'y a pas de contact, le terme R est
nul et cette quation direntielle du second ordre se rsout normalement par intgration
temporelle classique. La rsolution de cette quation ne pose donc pas de problme dans le
cas de mouvement sans contact.
Irisa
15
2.2.2 Mthode de pnalisation

C'est la mthode la plus simple pour rsoudre l'quation 2.1 dans le cas o il y a des
contacts (vecteur des forces globales de contact non nul). Elle rgularise l'quation prcdente
en considrant qu'il n'y a pas de discontinuit dans la vitesse lors du contact. En eet,
cette mthode traite le terme R comme un terme fonction de q, q, t. Elle ne rajoute
donc pas d'inconnues supplmentaires. On rsout alors l'quation 2.1 comme une quation
direntielle du second ordre qu'il y ait contact ou pas.
C'est donc une mthode assez intuitive qui, quand une collision est dtecte, place un
ressort entre les deux objets [MW88]. La loi du ressort est choisie pour que quand la distance
entre les deux objets tend vers 0, la rpulsion soit forte (tende vers l'inni). On peut prendre
la loi habituelle K/d, K tant la raideur du ressort et d la distance entre les deux objets. La
force de rpulsion est alors applique dans la mme direction (mais en sens inverse) pour les
deux objets. Quand les objets s'loignent cette force devient nulle.
Cette mthode est facile comprendre et programmer et elle s'applique bien aux solides
rigides. Cependant, si le choc est trs violent, le coecient de raideur tend vers l'inni et il
faut alors diminuer le pas de temps pour pouvoir rsoudre correctement les quations. Cette
mthode peut alors devenir trs coteuse en temps de calcul. Par ailleurs cette approche
convient pour des contacts, par contre, le traitement des chocs est plus dlicat car il n'y a
aucun moyen de rgler la raideur du ressort par des paramtres mcaniques. Il a t montr
que le choix du coecient de raideur (ou de pnalisation) est parfois impossible [SH96]. Il
faut donc ajuster cette raideur en fonction des conditions de simulation.
Pourtant cette mthode est trs utilise car elle est facile implmenter et facilement
adaptable aux solides dformables. Par ailleurs certains travaux rcents [HS04] ont permis
d'amliorer les performances de cette approche notamment en regardant la distribution des
forces sur une zone de contact et non plus sur un seul point. De cette faon cet algorithme
peut traiter les contacts entre surfaces.
2.2.3 Dynamique non rgulire

Dans cette section nous allons prsenter deux approches bases sur la dynamique non
rgulire : nous allons commencer par l'approche "pilotage par vnement" (event-driven) en
nous basant sur des travaux de l'quipe SIAMES [Sou02]. Cette approche est base sur les
retours arrires comme nous allons le voir plus loin. Nous verrons ensuite l'approche "temps
contrl" (time-stepping) dveloppe par Mathieu Renouf [RAD05] base elle sur le calcul
de la moyenne des eorts sur un pas de temps. Mais pour commencer nous allons prsenter
les quations utilises dans la modlisation des chocs.
On parle de dynamique non rgulire car il y a une discontinuit de la vitesse, en eet,
lors du choc, la vitesse s'annule brusquement. On ne peut donc plus dnir l'acclration
comme la drive seconde de la vitesse. Il faut reformuler l'quation 2.1 pour modliser cette
discontinuit :
M (q)dq = Q(q, q, t)dt + dR
Projet Siames
(2.2)
16
Amandine Fressier
ou dt est la mesure de Lebesgue, dq reprsente l'acclration et dR est un rel non ngatif
qui peut se rcrire en :
dR = FR dt + JR
(2.3)
FR est une fonction continue qui reprsente les forces de contact dans le cas continu et
JR reprsente la partie discontinue.
Dans le cas de contact (sans impact) JR est nul, il n'intervient que lorsqu'il y a choc.
Dans l'quation 2.1 nous avons prsent R comme le vecteur des forces globales
de contact. Pour dterminer les R nous avons besoin d'informations complmentaires que
nous allons dtailler dans les paragraphes suivant.
La condition de Signorini
La condition de Signorini modlise le fait que deux solides ne doivent pas s'interpntrer
lors du contact. Soit g l'cartement entre deux solides et rn la force de rpulsion qu'exerce
un solide sur l'autre.
Il y a deux cas possibles : Soit les solides sont loigns,( g > 0 ), et donc la force de
rpulsion qu'exerce un solide sur l'autre est nulle (rn = 0). Soit les solides sont en contact
(g = 0) et la force de rpulsion est non nulle (rn > 0).
Plus formellement :
g 0 rn 0 g.rn = 0.
(2.4)
Loi de frottement de Coulomb
Cette loi modlise le fait que pour qu'un solide glisse sur un autre, il faut que leur vitesse
relative atteigne un certain seuil. Ce phnomne est traduit par le cne de Coulomb. Le
vecteur de force de frottement est spar en deux composantes : normale rn et tangentielle
rt . est le coecient de frottement.
S'il n'y a pas de glissement, on a la relation rt rn et on se trouve l'intrieur du
cne de Coulomb.
Si les solides glissent, on se trouve sur la frontire du cne : rt = rn .
En rsum :
si ut = 0,
si ut = 0,
rt rn
rt = rn
(2.5)
Loi d'impact de Newton
Cette loi sert modliser le rebond. Un rebond s'exprime par le fait que la vitesse normale
avant le choc est plus petite ou gale la vitesse normale aprs le choc. e est le coecient
de restitution. Sa valeur varie entre 0 (choc mou) et 1 (choc lastique).
En terme d'quation :
Irisa
17
un = eun+
(2.6)
Cette loi ne permet cependant pas de modliser le dcollement (par exemple pour un
parallpipde oscillant sur un plan). Pour modliser le rebond standard ainsi que le dcollement, on utilise l'quation suivante
un eun+
(2.7)
Nous allons maintenant prsenter les deux approches dont nous avons parl plus haut.
Toutes deux s'appuient sur les quations de la dynamique non rgulire que nous venons
d'noncer. Nous commenons par exposer l'approche pilotage par vnement (eventdriven).
Cette approche repart de l'quation 2.1. L'ide est de calculer la simulation avec un
pas de temps donn et de revenir en arrire pour dterminer l'instant exact de la collision.
En eet, avant la collision, l'quation 2.1 s'applique mais le vecteur des forces globales de
contact est nul. La rsolution ne pose donc pas de problme. Par contre au moment du choc,
le terme R reprsente une inconnue supplmentaire et le systme n'a plus de solution.
On rsout ce problme en dterminant l'instant exact de la collision et en appliquant aux
points en contact la loi d'impact de Newton qui modlise le rebond. On a donc une quation
supplmentaire qui permet de rsoudre le systme.
Nous allons maintenant prciser la notion de retour arrire. Il est courant, lors de la
simulation, que l'instant du choc ne corresponde pas un instant de calcul. On s'aperoit
donc "trop tard" qu'il y a eu collision. L'ide est de revenir en arrire et de recommencer
la simulation avec un pas de temps plus petit pour voir quand exactement s'est produite la
collision. Ces retours arrires tant coteux dans le cas o les collisions sont nombreuses, il
devient ncessaire de dissocier le traitement des contacts de celui des chocs. Cette discrimination se fait en comparant les vitesses relatives des solides un certain seuil : en dessous
de ce seuil c'est un contact et au dessus c'est un choc. Cette approche a t adapte aux collisions multiples, en commenant par traiter les chocs qui ont plus d'eet sur le mouvement
des solides, puis en traitant les contacts.
Cette approche pilotage par vnement dtermine avec prcision l'instant du choc, elle
donne donc de bons rsultats au niveau du ralisme des simulations. Le problme est qu'elle
devient trs coteuse lorsqu'il y a beaucoup d'interactions traiter. En eet, cette mthode
ncessite un ranement itratif du pas de temps pour rechercher l'instant de la collision, et
dans le cas o les interactions sont nombreuses, les temps de calcul semblent peu appropris
pour une simulation interactive [Dum05]. Par contre, on pourrait penser coupler cette approche avec un algorithme de dtection des interactions continu qui fait concider l'instant
de la collision avec un instant de calcul, on viterait ainsi les retours arrires. Il resterait
cependant un problme de synchronisation puisque l'algorithme de dtection continu modie
le pas de temps.
Projet Siames
18
Amandine Fressier
Nous allons maintenant illustrer cette approche avec les rsultats obtenus lors de simulations en trois dimensions [Sou02]. La gure 2.1 reprsente une planche en quilibre sur
un plan. La planche est pose de telle sorte que son centre de gravit se situe l'extrieur
du plan. L'algorithme dtecte que les points de gauche ont tendance dcoller du plan et
la planche bascule. Si au contraire on place le centre de gravit de la planche sur le plan
alors elle reste en quilibre. partir de la mme conguration, des exprimentations ont t
conduites avec succs pour s'assurer de la validit de l'quation 2.7 (loi d'impact de Newton
avec dcollement) en lchant la planche sur le support.
Fig.
2.1 La planche bascule puis tombe
Pour exprimenter le traitement des chocs et des contacts, un billard a t modlis. Cela
a permis de tester les algorithmes avec direntes situations initiales (nombre de boules,
vitesse, position). Lors du choc entre 2 boules, les rsultats obtenus sont ceux attendus :
les boules rebondissent symtriquement et la vitesse est amortie correctement. La gure 2.2
prsente le problme des interactions multiples. Une boule vient frapper une autre boule qui
est elle mme en contact avec une troisime boule. Ce contact initial est transform en choc
et engendre une impulsion lorsque les deux premires boules se rencontrent. Les deux boules
en contact initialement sont concernes par l'impact. Cette exprience permet de valider la
distinction faite entre les contacts et les chocs. La dicult vient du fait que lors du choc
par la troisime boule, les deux boules en contact peuvent soit s'entrechoquer, soit s'carter.
Si ces boules avaient t initialement cartes, alors le choc aurait transform l'cartement
en choc ou en contact.
Nous allons maintenant passer l'approche temps contrl (time-stepping) telle que
propose par exemple par Mathieu Renouf. Cette approche prend en compte la discontinuit
de la vitesse en repartant de l'quation 2.3. En cas de contact, le deuxime terme de la somme
de l'quation prcdente est calcul en faisant une moyenne des eorts d'interaction sur le
pas de temps.
Contrairement l'approche pilotage par vnement, le pas de temps est ici constant ce
qui est un atout pour la simulation temps rel et il n'y a pas de distinction entre les chocs et
les contacts. L'autre atout de cette mthode est qu'elle ne fait pas de retour arrire, en eet
Irisa
Fig.
19
2.2 Un exemple de traitement des interactions multiples avec contact initial
celui-ci est gnant dans le cas d'interaction avec un utilisateur humain : on ne peut alors pas
garantir l'coulement continu du temps simul et donc cela pnalise le temps rel souhait.
Par contre, on ne calcule qu'une moyenne et on ne dtermine pas l'instant exact de la
collision, la prcision est donc moins importante que dans l'approche pilotage par vnement.
On peut toujours augmenter la prcision des calculs en prenant un pas de temps plus petit
mais les temps de calcul s'en ressentent. Nanmoins, cette mthode ne modiant pas le
pas de temps, ne faisant pas de retour arrire, elle parait tout de mme plus adapte aux
simulations temps rel. Pour preuve, elle permet de simuler, en temps rel, l'empilement de
160 sphres en obtenant des rsultats cohrents.
Nous allons prsenter quelques rsultats obtenus avec cette approche temps contrl. Le
premier exemple concerne l'empilement de sphres (gure 2.3). C'est un exemple coteux en
temps de calcul car le nombre de contacts observs augmente fortement avec le nombre de
corps. Les simulations ont t eectues avec une nombre croissant de sphres (80,160, 320 et
800). Comme nous l'avons dit ci- dessus, jusqu' 160 sphres, la contrainte temps rel pour la
visualisation (30hz environ) a pu tre respecte. En diminuant le nombre de sphres on peut
atteindre une frquence de sortie d'une centaine de Hertz. La gure ci-dessous reprsente
la simulation avec 800 sphres. Dans ce cas, le temps de calcul est nettement suprieur au
temps simul (une quinzaine de fois).
Dans la simulation de la gure 2.4, une bille de diamtre important a t place dans
une bote parmi un ensemble de billes plus petites. La bote est soumise une vibration et
sous l'action de celle-ci, on observe le mme phnomne qu'en ralit, la bille la plus grosse
remonte.
Projet Siames
20
Amandine Fressier
Fig.
2.3 Empilement de billes (800 billes, le temps rel n'est pas atteint)
Fig.
2.4 mergence de la bille de grand diamtre
Conclusion
Dans le cadre de ce stage, la simulation ne contiendra que quelques solides,

nous pourrons donc utiliser l'approche temps contrl mme pour le temps rel haptique.
Obtenir une sortie de plusieurs centaines de Hertz ne devrait en eet pas poser de problme
Irisa
21
pour simuler le choc entre deux billes. On peut imaginer une simulation deux billes o une
bille est tenue par l'utilisateur via le priphrique retour d'eort et l'autre est libre dans
l'environnement virtuel par exemple.
Projet Siames
22
Amandine Fressier
Chapitre 3
Couplage
Aprs avoir vu les direntes tapes du traitement des interactions, nous allons maintenant nous intresser au couplage entre les algorithmes de rsolution des quations de
mouvement et le priphrique retour d'eort.
Nous allons commencer par dnir ce qu'est le couplage puis nous verrons quelques uns
des problmes qu'il nous faudra rsoudre.
3.1 Dnition
Nous allons d'abord rappeler le schma de principe d'un systme retour d'eort [LAC03].
Un systme retour d'eort est gnralement compos des lments suivants :
Un bras retour d'eort et son contrleur temps rel.
Un logiciel de simulation physique temps rel qui intgre des algorithmes de dtection
de collision et de simulation des quations de la dynamique.
Un logiciel qui assure la communication entre le contrleur de l'interface haptique et
le simulateur physique temps rel. Ce logiciel gre le couplage entre ces deux systmes
dynamiques.
Un systme de visualisation qui ache la position des objets calculs par le simulateur
physique temps rel.
Jusqu'ici, nous avons dtaill le deuxime point : le logiciel de simulation physique temps
rel comprenant la dtection de collision et la dtermination des eorts d'interaction. L'objet
de ce chapitre est de s'attacher au point suivant, le couplage.
Irisa
23
Le couplage fait le lien entre le monde virtuel et le monde rel dans le but de faire ressentir
l'utilisateur un vnement virtuel de manire raliste. Dans notre cas, le monde virtuel est
rgi par les algorithmes prsents dans le chapitre prcdent, notamment les algorithmes de
Mathieu Renouf. Les vnements virtuels sont des chocs ou des contacts.
Le couplage doit donc prendre en compte l'action de l'utilisateur sur le priphrique
haptique et agir sur le monde virtuel en consquence. Il doit aussi, partir des rsultats des
algorithmes de simulation, piloter le bras retour d'eort.
En prsentant le couplage de cette faon, on voit apparatre plusieurs niveaux de problmes notamment lis au fait de passer du monde virtuel au monde rel et l'interaction
avec l'utilisateur.
3.2 Problmatique du couplage temps rel

Nous allons commencer par dnir deux notions propres l'interaction haptique : la
stabilit et la transparence.
La transparence regroupe les techniques qui permettent l'utilisateur de ne pas ressentir
les perturbations dues au dispositif physique (le bras retour d'eort). Par exemple, l'utilisateur ne doit pas sentir le poids du bras quand il manipule un objet virtuel mais seulement
le poids de cet objet.
Pour dnir la stabilit, nous allons prendre un exemple d'interaction. Supposons qu'un
utilisateur entre en contact avec un mur virtuel. Avant le contact, il ne ressent rien. Aprs
le contact, en raison de la frquence de simulation, l'utilisateur a touch la surface mais a
srement dj pntr dans le mur. Le simulateur calcule alors une force trs importante.
Cette force fait reculer l'utilisateur et l'loigne du mur. Cependant, au pas suivant, il n'y a
plus contact et donc aucune force n'est renvoye l'utilisateur. L'utilisateur continuant son
mouvement pntre nouveau dans le mur car plus aucune force ne l'en empche d'o une
force importante qui est retourne et ainsi de suite. Ce problme aboutit des oscillations
haute frquences qui font vibrer le priphrique et soit l'utilisateur s'carte compltement
du mur soit il lche le priphrique...
L'tude de la stabilit du dispositif consiste pour la boucle de commande modier les
forces calcules par l'environnement de la simulation, an de les rendre compatibles avec les
forces maximales dlivrables par le dispositif et avec la frquence de simulation, dans toutes
les conditions d'utilisation possibles.
Nous venons d'exposer ce que l'on veut c'est dire un systme d'interaction haptique
stable et transparent. En pratique, le couplage haptique pose de nombreux problmes et
un tel systme n'existe pas, il y a toujours un compromis entre stabilit et transparence.
Hasegawa et Sato [HS04] ont fait le point sur les problmes du couplage.
Ils s'attachent tout d'abord la contrainte temps rel. Nous avons vu qu'il faut une
frquence leve pour restituer les forces de contact. Il faut donc que les algorithmes de
simulation respectent cette contrainte et que leur temps de calcul soit constant sinon, le
priphrique retour d'eort risque d'tre instable car il ne dispose pas des informations au
Projet Siames
24
Amandine Fressier
bon moment. La restitution n'est plus cohrente, le bras retour d'eort se met vibrer et
l'utilisateur n'a pas d'autre choix que de le lcher.
Le deuxime point concerne le couplage proprement parler. Dans [OHT], il est prcis
que le priphrique haptique envoie des positions au simulateur qui lui, retourne des forces.
Dans certains cas o les algorithmes de simulation ncessitent des forces en entre, il faut
alors traduire les positions en forces. Cela se fait gnralement en introduisant un ressort en
parallle avec un amortisseur entre le pointeur virtuel et une reprsentation de ce pointeur
(un proxy). Cette mthode d'indirection entre le priphrique et le simulateur dynamique est
appele "couplage virtuel". Le couplage virtuel sert aussi assurer la stabilit du systme
[LMCL01]. En eet, quand l'utilisateur dplace le pointeur, le proxy suit ce mouvement
mais "en souplesse" grce l'intermdiaire du ressort et de l'amortisseur. Pour reprendre
l'exemple du mur, avec un tel couplage l'utilisateur reste en contact avec le mur par le biais
du proxy.
Des observations ont mis en vidence l'inuence ngative du couplage virtuel sur la
transparence. Des travaux ont alors t mens[LML02] pour maximiser le ralisme de la
restitution tout en assurant la stabilit. Ceci est fait en adaptant les paramtres du couplage virtuel (rigidit, amortissement) fonction de la frquence d'interaction. Dans notre cas,
comme dans le cas de Hasegawa et Sato [HS04], les algorithmes de simulation prennent en
entre des positions et rendent des forces, on pourrait donc penser se passer de couplage
virtuel. Cependant, il faudra peut tre explorer une piste de ce genre pour assurer la stabilit
du systme.
Un autre point dur rside dans l'asymtrie de la boucle d'interaction entre l'utilisateur et
le systme de simulation. En eet, une des premires choses prendre en compte lors de la
ralisation d'un systme interactif, ce sont les caractristiques des sens que l'on veut stimuler.
Dans notre cas, une bonne perception des forces ncessite des frquences relativement leves
(1000Hz). Nous avons vu que cela ne devrait pas nous poser de problme si l'on utilise
l'approche temps contrl avec peu d'objets virtuels.
Le problme vient du fait que les gestes de l'utilisateur sont assez lents (autour de 10Hz),
il y a donc une asymtrie de la boucle d'interaction. Les forces appliques au bras retour
d'eort doivent tre rafrachies une frquence leve, mais comme elles sont directement
relies aux mouvement de l'utilisateur, elles vont voluer lentement [FAT03].
La plupart des systmes haptiques oprent l'aide d'une boucle d'interaction ferme, le
systme rend les forces calcules la frquence dtermine par le mouvement de l'utilisateur.
Une grande part de l'information est donc perdue et le rendu est de mauvaise qualit, le
systme est instable et il y a des vibrations. Plusieurs solutions ont t envisages pour
rduire ce phnomne, une approche consiste calculer les forces basse frquence (30Hz)
et estimer ce qui se passe entre deux calculs successifs.
Dans [HWN04] les auteurs ont abandonn l'approche boucle ferm et proposent de gnrer les signaux hautes frquences en boucle ouverte. Les forces correspondant un contact
donn sont prcalcules fonction des conditions de contact (vitesse, matriaux,...). Ensuite,
quand le contact virtuel est eectivement dtermin, le signal haute frquence enregistr
Irisa
25
vient se superposer au signal basse frquence dtermin par les algorithmes de simulation.
Contrairement aux systmes en boucle ferme, cette approche a l'avantage de ne plus relier
directement forces et positions. En eet, dans l'environnement virtuel, la masse du priphrique haptique pose problme, car il n'est pas possible de la rduire et la perception des
contacts est biais, la transparence du systme est mauvaise. Avec l'approche boucle ouverte,
comme le retour d'information n'est pas immdiat, on peut traiter ce problme.
La mme ide est traite dans [KFN05], o il est prcis que les forces peuvent tre
prcalcules partir d'observation bases sur un contact rel entre des objets de matriau
donns. Cela permet de travailler avec des bibliothques de forces prtes tre appliques.
Pour l'instant, l'approche boucle ouverte est l'oppos de notre problmatique puisqu'elle
fait intervenir des forces prcalcules alors que nous voulons mettre en place une restitution
des eorts uniquement base sur les donnes calcules par la simulation en ligne. Par contre,
il serait sans doute intressant d'appliquer cette mthode en calculant hors ligne les forces
grce aux algorithmes temps contrl.
Une autre mthode [CSC05], consiste sparer la boucle de contrle des forces de l'environnement virtuel de simulation. Cette sparation permet la simulation de tourner moins
vite et l'utilisateur peut donc manipuler des mondes virtuels plus complexes. Cela autorise
galement la restitution d'eort distance via internet.
Cependant, les utilisateurs n'ont une sensation raliste que si les forces fournies la
boucle de contrle durant un pas de temps de simulation correspondent celles qui agissent
sur le pointeur virtuel. Les auteurs introduisent alors la notion de modle local d'interaction.
Ce modle local tourne une frquence donne et inclus les caractristiques du monde virtuel
propres une interaction sur un pas de temps de la simulation. Plus simplement, l'ide est
de reprsenter le pointeur virtuel par un proxy dynamique et de travailler sur ce proxy. En
fait cela dplace la frontire du virtuel au rel et permet ainsi de dissocier les problmes.
Cette mthode a beaucoup d'avantages car elle permet notamment d'augmenter la stabilit
du systme en prvoyant les contacts dans l'environnement immdiat du proxy et de calculer
des interactions entre le proxy et des objets entre deux calculs de la simulation (ce qui ne
nous sera pas forcment utile vu que nos algorithmes sont rapides). Il parait donc intressant
de se pencher sur cette approche et de voir si elle permet d'orir un bon compromis entre
stabilit et transparence.
Projet Siames
26
Amandine Fressier
Conclusion partielle
Dans cette premire tude, nous nous sommes attachs prciser le problme pos et
le replacer dans son cadre. Aprs avoir prsent quelques notions prliminaires et gnralits
sur notre sujet, nous nous sommes penchs sur le traitement des interactions. Suite un bref
tat de l'art des techniques de dtection de collision, nous avons expos direntes approches
de la dtermination des eorts d'interaction pour nir par aborder le couplage et quelques
uns des problmes inhrents. Ces direntes parties nous ont permis de nous faire une ide
des contraintes et des dicults prendre en compte durant notre stage.
En eet, le but du stage est de raliser le couplage entre un bras retour d'eort et les
algorithmes de traitement des interactions bass sur l'approche temps contrl dvelopps
au sein de l'quipe SIAMES. Ce couplage est gnrique, nous ne nous attachons pas un
priphrique retour d'eort particulier. Dans le chapitre suivant, nous prsenterons le
concept de ce couplage qui se fera en utilisant la plate-forme OpenMASK dveloppe dans
l'quipe SIAMES.
Irisa
Deuxime partie
Conception et mise en uvre du

couplage entre le simulateur
dynamique et le bras retour
d'eort
27
29
Chapitre 4
Concept
Dans ce stage, nous avons propos une mise en uvre de rendu haptique avec des algorithmes de dynamique non rgulire. Nous allons dans ce chapitre justier ce choix de
la dynamique non rgulire et montrer comment notre stage s'insre dans les recherches
actuelles sur le rendu haptique.
4.1 Rappels sur la dtermination des eorts d'interaction

Habituellement, le traitement des interaction se fait par une mthode de pnalisation.
Cette mthode modlise le contact entre solides par un ressort et l'eort calcul est proportionnel l'interpntration des deux solides en contact. En rglant la raideur du ressort,
on rgle la raideur du contact, mais ce rglage reste empirique et nous avons vu dans la
partie bibliographique de ce rapport qu'il posait problme. De plus, le fait qu'il soit empirique oblige ajuster la raideur fonction des conditions de simulation. Ce qui fait que cette
mthode n'est pas du tout gnrique.
l'inverse, la dynamique non rgulire s'appuie sur des quations de la mcanique pour
rsoudre le problme de dtermination des eorts. La dynamique non rgulire met en quation le fait que lors du choc entre deux solides, leur vitesse relative s'annule brutalement.
partir de la mise en quation de ce phnomne, elle permet de calculer les forces de raction
subies par les solides en interaction. Contrairement la mthode de pnalisation qui se base
sur l'interpntration pour dterminer l'eort, la dynamique non rgulire permet de traiter
les vritables eorts.
Utiliser cette mthode pour le rendu haptique comporte plusieurs avantages. Au niveau du
traitement des contacts, l'avantage de cette mthode est qu'elle est gnrique, elle s'applique
n'importe quel type de choc ou contact, quelque soit sa raideur. De plus, elle est prcise
car elle est base sur des quations mcaniques modlisant une ralit (le fait que la vitesse
s'annule). L'autre avantage de cette mthode se situe au niveau du couplage avec le priphrique retour d'eort car elle permet de communiquer directement avec ce dernier. En eet,
Projet Siames
30
Amandine Fressier
le priphrique fourni au simulateur dynamique la position et la vitesse de son pointeur et

prend en entre une force. Si on veut connecter un priphrique retour d'eort un simulateur dynamique bas sur une mthode de pnalisation, il faut traduire les grandeurs car
la structure de ce simulateur dynamique bas sur la notion d'interpntration nous oblige
accepter des forces en entre pour pouvoir rendre des positions et des vitesses. On met alors
en place un couplage virtuel qui eectue cette traduction.
4.1 Couplage entre un bras retour d'eort et un simulateur dynamique bas sur
une mthode de pnalisation
Fig.
Or, dans le cas o le simulateur dynamique est bas sur des algorithmes de dynamique
non rgulire, sa structure nous permet de nous passer de cette traduction puisqu'il est
capable de calculer l'eort rendre directement avec les positions et les vitesses fournies.
4.2 Couplage entre un bras retour d'eort et un simulateur dynamique bas sur la
dynamique non rgulire
Fig.
La dynamique non rgulire possde donc des avantages par rapport aux mthodes de
pnalisation. Au niveau du traitement des contacts, elle devrait tre plus performante car
plus proche de la ralit, et au niveau du couplage, elle permet de s'aranchir du couplage
virtuel qui pose des problmes de qualit d'interaction.
Irisa
31
4.2 Le couplage virtuel

Ce couplage direct reprsente un intrt majeur d'utiliser la dynamique non rgulire
pour le rendu haptique. Pour comprendre l'intrt de s'aranchir du couplage virtuel, il
faut d'abord rappeler son principe. Le couplage virtuel consiste simuler un ressort et un
amortisseur entre le pointeur du priphrique haptique et l'objet qu'il pilote. Comme pour
la mthode de pnalisation, le rglage de ces paramtres reste empirique. Pour l'utilisateur,
l'introduction de ce couplage virtuel se traduit par une restitution des contacts "molle" et
il est alors dicile de faire la dirence entre deux contacts de caractristiques direntes.
Il existe beaucoup de travaux visant amliorer cet aspect du couplage virtuel.
4.3 Notre proposition

Pour notre part, il nous a sembl intressant de repenser compltement le problme en
se servant de la dynamique non rgulire. De cette faon, non seulement les problmes lis
la mthode de pnalisation sont vits mais aussi ceux lis au couplage virtuel.
L'ide est donc de raliser le couplage (au sens faire communiquer et non couplage virtuel)
entre un simulateur dynamique bas sur la dynamique non rgulire et un priphrique
retour d'eort. Un simulateur dynamique avait dj t dvelopp dans l'quipe SIAMES,
c'est ConF&TiS. Comme nous l'avons dcrit dans les chapitres prcdents, nous avons repris
ces travaux pour les intgrer dans un programme de rendu haptique. Dans notre solution,
le priphrique pilote directement l'objet virtuel, il n'y a pas de module de couplage virtuel.
Il reoit directement les forces calcules par le simulateur dynamique.
Fig.
4.3 Dans notre cas : couplage entre un bras retour d'eort et ConF&TiS
Projet Siames
32
Amandine Fressier
4.4 Les rsultats attendus

Avec notre solution, la perception des chocs devrait tre meilleure que dans le cas d'une
mthode de pnalisation avec couplage virtuel. D'une part parce que le calcul des forces de
contact par la dynamique non rgulire est plus rigoureux et d'autre part parce qu'il n'y a
pas d'indirection de type couplage virtuel entre le priphrique et l'objet pilot.
Cependant, il est possible que l'absence de couplage virtuel pose un problme de stabilit,
c'est dire que le priphrique se mette vibrer lors d'un contact. Le traitement de tels
artefacts peut tre gr indpendamment du calcul des forces, il est alors report au niveau
de la commande du priphrique. De plus, la dynamique non rgulire devrait rduire les
problmes de stabilit dus un retard dans la dtection de l'interpntration (comme dcrit
en 3.2) puisqu'elle ne se base pas sur cette notion pour dterminer les forces. En eet, elle
calcule une moyenne des eorts d'interaction sur le pas de temps de simulation, il ne devrait
donc pas y avoir de discontinuit menant une instabilit du priphrique.
Conclusion
Le but de ce stage est de voir si les avantages de la dynamique non rgulire

(rigueur de la modlisation et absence de couplage virtuel) permettent d'amliorer la perception des contacts et des chocs par retour haptique. Aprs avoir expos et justi l'ide
de ce stage, nous allons maintenant dcrire sa mise en uvre.
Irisa
33
Chapitre 5
L'environnement
L'environnement de programmation a videmment eu un impact direct sur la conception
de notre programme. Nous allons donc consacrer ce chapitre la description de cet environnement ainsi qu' la description des travaux que nous avons repris (ConF&TiS de Mathieu Renouf). Nous prsenterons donc la plate-forme OpenMASK et le programme ConF&TiS. Nous
ne rentrerons toutefois pas dans les dtails, nous nous contenterons d'exposer les concepts
fondamentaux. Cette premire approche doit nanmoins tre susante pour cerner les diffrents choix de conception que nous avons fait. Le lecteur dsireux de se renseigner plus
amplement pourra se reporter aux rfrences donnes.
5.1 OpenMASK
5.1.1 Description gnrale
OpenMASK1 est une plate-forme dveloppe en C++ au sein de l'quipe SIAMES de
l'IRISA.
C'est un outil gnrique ddi aux besoins de la programmation en ralit virtuelle.
Plus prcisment, la plate-forme OpenMASK est une bibliothque C++ utilise pour le
dveloppement et l'excution d'applications modulaires de ralit virtuelle. Elle ore des
fonctionnalits d'interaction, de visualisation et de distribution rseau. Elle permet ainsi de
dvelopper des applications de simulation et de ralit virtuelle complexes.
De plus, elle est oriente multi-processus et permet donc la distribution des calculs sur une
grappe de processeurs, ce qui est souvent ncessaire en ralit virtuelle tant les applications
sont gourmandes en ressources. Il serait judicieux de conserver cette proprit l'esprit pour
pouvoir ventuellement amliorer les performances de notre programme.
Pour l'instant, nous n'utilisons que les fonctionnalits d'interaction et de visualisation
qu'ore la plate-forme.
1 Modular
Animation and Simulation Kit, disponible sur
Projet Siames
www.openMASK.org
34
Amandine Fressier
5.1.2 La programmation dans OpenMASK

Dans OpenMASK, le bloc de base d'une application est l'objet de simulation. Dans le
code de chacun de ces objets est prcis son initialisation et son volution chaque pas de
temps ainsi que sa faon de communiquer avec d'autres objets. Lors de l'excution d'une
application OpenMASK, le noyau se charge de crer puis d'initialiser tous les objets de
simulation, et ensuite synchronise leur volution.
Le travail de tout utilisateur d'OpenMASK sera donc de concevoir son programme de
faon ce qu'il s'articule autour d'objets de simulation. L'utilisateur devra alors crire le
code de ses objets de simulation et dcrire leurs paramtres d'initialisation dans un chier
de conguration. Un des enjeux majeurs lors de la conception d'un programme OpenMASK
est de trouver la bonne granularit pour les objets simuls. En eet, OpenMASK n'impose
aucune granularit, un objet de simulation peut aussi bien reprsenter un humain virtuel
avec ses comportements complexes qu'un simple objet inerte.
5.1.3 L'objet de simulation OpenMASK

Nous exposons ici le principe2 d'un objet de simulation OpenMASK. OpenMASK permet
au programmeur de choisir le mode de fonctionnement des objets : synchrone (frquentiel)
ou asynchrone (ractif) ou encore mixte. Nous nous attachons ici au cas d'objets en mode
synchrone.
En dehors des fonctions habituelles d'un objet C++ (constructeur, destructeur..) un
objet de simulation OpenMASK comprend les fonctions suivantes :
init() : on y fait les initialisations qui n'ont pas pu tre faites dans le constructeur, elle
est appele aprs que tous les objets aient t construits.
compute() : le code de cette fonction reprsente ce que doit faire l'objet chaque pas
de temps, elle est appele la frquence de l'objet (passe en paramtre dans le chier
de conguration)
nish() : elle est appele avant que l'objet ne soit dtruit
processEvent() : on y traite les vnements reus, elle est appele avant l'appel la
mthode compute.
Un objet de simulation possde galement des attributs qui constituent son interface de
communication. Il y a dirents types d'attributs, nous n'en dtaillerons ici que deux :
les entres : une entre permet d'acqurir en continu les valeurs d'une sortie d'un
autre objet de simulation. Les entres ont une mthode get qui permet de rcuprer
leur valeur. Elles ont une mthode connect qui leur permet de se connecter une sortie
spcie en paramtre.
les sorties : une sortie est utilise pour rendre public une donne de l'objet de simulation
(position 3D de l'objet par exemple). Les sorties ont des mthodes get et set.
Les sorties, tout comme les entres, sont types.
2 tel
que prsent dans le Trait de la ralit Virtuelle dition 2006, volume 3 [FMT06], chapitre 12
Irisa
35
5.1.4 La visualisation dans OpenMASK

OpenMASK est fourni avec le module OpenMASK-3DVis qui regroupe des objets de
simulation servant la visualisation, la navigation et la dsignation dans des environnements virtuels anims.
OpenMASK-3DVis est bas soit sur la bibliothque Performer de SGI, soit sur OpenSG du
Fraunhofer Institute. Les travaux que nous avons repris dans ce stage ont t raliss avec
la version OpenSG, nous avons donc continu dans ce sens. Avec OpenSG, il faut fournir la
description de la gomtrie associe l'objet de la simulation en VRML. Le chier VRML est
pass en paramtre d'initialisation de l'objet de simulation via le champ geometryFileName
dans le chier de conguration.
OpenMASK-3DVis permet de charger, de visualiser et d'animer une scne 3D. Par ailleurs
il transmet les actions du clavier et de la souris au reste de la simulation, ce qui est utilis
pour la dsignation (picking).
Lorsque l'on veut rendre visualisable un objet de simulation, il faut le faire hriter d'une
classe gnrique fournissant l'API de communication avec le visualiseur, c'est la classe PsMechanismPartner. Le visualiseur quant lui, est un objet de simulation spcialis. Une
fois cet hritage mis en place, l'objet de simulation doit dclarer des sorties animables qui
serviront l'animation de sa gomtrie. Le visualiseur fera le lien entre les valeurs prsentes
sur ces sorties et l'animation de la gomtrie. Les types de ces sorties sont varis, certaines
contrlent la position, l'orientation, ou encore la taille de la gomtrie.
5.2 ConF&TiS (Contacts, Frottements & Time Stepping)

Nous avons repris les travaux antrieurs de l'quipe SIAMES sur la dynamique non rgulire. Ces travaux eectus par Mathieu Renouf ont permis le dveloppement d'un simulateur
dynamique : "ConF&TiS" (Contacts, Frottements & Time Stepping) mettant en uvre des
algorithmes de dynamique non rgulire et incluant la dtection de collisions. ConF&TiS a
t dvelopp en utilisant la plate-forme de l'quipe : OpenMASK.
5.2.1 Description
La partie gestion des chocs et des contacts de ConF&TiS est base sur une approche de
type time-stepping. ConF&TiS permet de visualiser une scne compose d'objets simples
(sphre, plan, bote). Il prend en entre des chiers dcrivant les paramtres de la simulation :
description des objets, description des paramtres du simulateur dynamique. Le simulateur
dynamique calcule les trajectoires des objets fonction des paramtres fournis. En sortie, il
fournit un rendu visuel de la scne. Mais ConF&TiS ne permet pas d'interagir avec les objets
de la scne. Son architecture est pense uniquement dans le cas d'objets non interactifs.
Projet Siames
36
Amandine Fressier
5.2.2 Utilisation
Le schma ci-dessous montre l'utilisation de ConF&TiS. En entre, on lui fourni des
chiers dcrivant la simulation et en sortie on obtient une visualisation de cette simulation.
Fig.
5.1 Utilisation de la version originale de ConF&TiS
Les chiers .in contiennent les paramtres ncessaires l'initialisation de ConF&TiS.

param.in contient les paramtres de simulation, data.in contient les paramtres des objets
simuls, dof.in contient pour chaque objet simul ses contraintes pour chaque degr de libert,
material.in contient plusieurs matriaux avec leurs paramtres et les chiers vrml correspondants pour la visualisation et tact.in contient les paramtres de contact. Des exemples comments de ces chiers sont prsents dans le guide de l'utilisateur de ConF&TiS (ConF&TiS :
Short User Guide, Mathieu Renouf).
5.2.3 Principe de fonctionnenemt

Dans ConF&TiS, il y a deux possibilits de comportement pour les objets. Soit ils sont
libres et les chocs et les contacts modient leur trajectoire, soit ils sont pilots par le simulateur via les paramtres contenus dans le chier dof.in et les chocs et contacts n'inuent pas
sur leur trajectoire. Le chier dof.in contient pour chaque objet un ensemble de 6 vecteurs
6 composantes. Les 6 vecteurs correspondent aux 6 degrs de libert (3 en translation
et 3 en rotation) : les 3 premiers vecteurs permettent de calculer la vitesse de l'objet en
translation sur les axes x, y et z et les 3 autres, sa vitesse en rotation par rapport aux axes.
La vitesse est calcule en utilisant les 6 composantes de chaque vecteur comme coecients
d'une quation linaire.
La simulation dynamique utilise une theta-mthode. chaque pas de temps de la simulation,
et pour chaque objet simul, ConF&TiS prdit les trajectoires des objets sans tenir compte
des contraintes. Puis il dtecte les contacts qui vont avoir lieu en se basant sur les trajectoires prdites et corrige ces trajectoires en consquence. La prdiction se fait sur la premire
Irisa
37
fraction du pas de temps (fraction dnie par le paramtre theta du chier param.in) et la
correction se fait dans ce qui reste du pas de temps simul.
5.2.4 Dtails de l'architecture

Les objets simuls (classe PsRigidBody) sont des objets au sens C++, qui ont des attributs reprsentant leurs proprits (type, matriau, vitesse et position initiales, ...) et des
mthodes pour lire/crire et eectuer des calculs sur ces attributs.
Le Manager (classe PsManager) est le seul objet de simulation du programme, c'est le
cur de ConF&TiS.
Le Manager :
initialise la dtection de collision, le simulateur dynamique et les objets ConF&TiS en
lisant les chiers .in fournis
gre la visualisation des objets simuls
calcule les nouvelles positions des objets simuls pour chaque pas de temps.
Pour calculer les trajectoires des objets simuls, le Manager a besoin d'accder au proprits de ces objets (PsRigidBody). Pour cela, il a un attribut qui est un vecteur de PsRigidBody. Il accde (en lecture/criture) aux proprits de ces objets par leurs mthodes et
eectue les calculs dans sa fonction OpenMask "compute".
Fig.
Projet Siames
5.2 Architecture de ConF&TiS
38
Amandine Fressier
Conclusion
La premire tape du stage a donc t de prendre en main en parallle OpenMASK et ConF&TiS. Il a fallu d'une part cerner l'architecture de ConF&TiS et d'autre part
comprendre le fonctionnement d'OpenMASK. L'enjeu tant de dterminer si l'architecture
de ConF&TiS tait adapte nos besoins en interaction et couplage, ou si au contraire nous
devions la modier en tenant compte des spcicits d'OpenMASK.
Irisa
39
Chapitre 6
Conception des dirents modules

Aprs avoir tudi l'environnement de programmation (la plate-forme OpenMASK) ainsi
que les travaux de SIAMES dans le domaine de l'haptique, nous avons dgag une architecture pour notre programme. Nous allons, dans ce chapitre, exposer cette architecture et
justier nos dirents choix de conception.
6.1 L'architecture choisie

La vocation de ce programme est de permettre de manipuler des objets virtuels l'aide
d'un bras retour d'eort an de ressentir les contacts et les chocs, la dynamique de la
simulation tant gre par ConF&TiS. Il nous faut pour cela implmenter un programme
avec OpenMASK qui permet de dsigner un objet virtuel l'aide du bras retour d'eort,
de le piloter et de ressentir les forces qui s'y appliquent.
La dsignation est un problme tudi dans SIAMES et OpenMASK est fourni avec des
fonctionnalits de dsignation. L'utilisation des ces fonctionnalits suppose que les objets
virtuels dsignables soient des objets de simulation. Par ailleurs, si l'objet virtuel est un
objet de simulation, le couplage avec le priphrique se fera en utilisant la commnunication
OpenMASK entre deux objets de simulation.
Il parait donc intressant de transformer les objets virtuels qui sont pour l'instant des objets
au sens C++ en objets de simulation OpenMASK.
Une fois cette dcision prise, le reste de l'architecture en dcoule et on voit apparatre
trois modules :
le simulateur dynamique (ConF&TiS et les objets)
le module d'interaction
le couplage
Ces trois modules doivent changer des informations mme s'ils sont relativement indpendants les uns des autres. Il convient donc de concevoir chaque module en vriant que
les choix eectus lors de la conception de l'un s'accordent avec les autres.
Projet Siames
40
Amandine Fressier
6.2 Le simulateur dynamique

Le simulateur dynamique est dj conu : c'est ConF&TiS et nous avons, dans la partie
prcdente, expos son architecture. Nous avons vu que les objets ConF&TiS (PsRigidBody)
ne sont pas des objets de simulation. De l'extrieur, on ne peut donc avoir accs ces objets
qu'au travers du Manager (le seul objet de simulation du programme). Or nous avons aussi
vu que pour pouvoir dsigner et piloter l'objet partir d'un priphrique, il faut que cet objet
soit capable d'changer des donnes avec ce dernier. D'un point de vue OpenMASK, cela se
traduit par un objet de simulation qui possde des entres/sorties capables de recevoir et de
transmettre les donnes voulues. Il nous a donc fallu adapter ConF&TiS l'interactivit.
Ide L'ide est donc que les objets ConF&TiS ne soient plus seulement des objets au
sens C++, mais qu'ils soient des objets de simulation OpenMASK. Cela leur permet de
communiquer avec les dirents modules (module d'interaction et de couplage).
6.2.1 Dtails de l'architecture

Les objets de la scne doivent donc devenir des objets de simulation, et le Manager
doit toujours pouvoir accder aux mthodes de ces objets pour pouvoir eectuer les calculs
ncessaires la simulation. Le problme est donc de grer une collection d'objets qui ont
besoin de mettre leurs donnes en commun.
Pour que les objets ConF&TiS soient des objets de simulation, il faut qu'ils incluent :
leur initialisation (qui ne se fera plus par la lecture de data.in et material.in mais dans
le chier de conguration OpenMASK)
la visualisation de leur gomtrie associe
la communication avec les autres objets de simulation (vnements, entres/sorties)
On pourrait modier la classe PsRigidBody en consquence mais pour des raisons de lisibilit, on cre une classe PsConfetiObject qui va servir d'interface OpenMASK aux PsRigidBody de faon sparer le code OpenMASK du code C++ des algorithmes.
L'initialisation et la visualisation ne posent pas de problme particulier. Par contre, il
faut que ces objets de simulation communiquent avec le Manager. Dans OpenMASK, cela
se fait par entres/sorties et/ou par vnements.
Communication par entres/sorties
Cela consiste faire dialoguer le Manager et les

par le systme standard d'entres/sorties d'OpenMASK. Il faut donc que
chaque PsConfetiObject ait une entre et une sortie (au minimum) et que le Manager ait
autant de paires entre/sortie qu'il y a de PsConfetiObject.
Cette conguration pose plusieurs problmes, d'abord les donnes changes entre le
Manager et le PsConfetiObject sont de plusieurs types, il faudrait donc beaucoup d'entres/sorties direntes. De plus, le Manager fait appel des mthodes du PsRigidBody,
il faudrait alors envoyer un vnement au PsConfetiObject pour lui dire d'appeler une mthode du PsRigidBody qui lui est associ et le PsConfetiObject devrait rendre le rsultat au
PsConfetiObject
Irisa
Fig.
41
6.1 Communication par entres/sorties OMK (OpenMASK)
Manager par retour d'vnements. De plus, ce n'est pas adapt aux scnes trs lourdes : il
faut que le Manager ait autant de paires d'entres/sorties qu'il y a d'objets dans la scne et
il faut aussi qu'il gre un grand nombre d'vnements, et ce, chaque pas de temps.
Par ailleurs, le Manager ne peut pas pas savoir a priori combien d'objets vont tre crs, il
faut donc que les entres/sorties du Manager se crent au fur et mesure de la cration des
PsConfetiObject, c'est dire en dynamique, or ce n'est pas possible pour les entres.
Enn, un autre problme se pose pour faire correspondre les entres/sorties du Manager
celle des objets ConF&TiS, il faudrait sans doute mettre en place un systme index, map
ou vecteur, dont le cot de parcours ne serait pas ngligeable.
On voit que cette solution est dicilement viable, sa mise en uvre est lourde et le
rsultat est loin d'tre acquis, surtout en terme de performances.
Nous avons donc rchis une solution moins coteuse en terme de temps de calcul.
La solution adopte
Nous avons vu que dans OpenMASK la communication entre objets

de simulation passe soit par des entres/sorties, soit par des vnements. Or dans les langages
de programmation objet, il est courant que cette communication s'tablisse grce un
pointeur. Ce n'est pas le cas dans OpenMASK car le systme de communication implment
permet de distribuer les dirents objets de simulation, or si l'on accde aux objets de
simulation par un pointeur, la distribution est alors la charge du programmeur.
Dans cette solution, chaque PsConfetiObject correspond un PsRigidBody. Les PsConfetiObject possdent chacun un pointeur sur un PsRigidBody (objet C++) et ils s'enregistrent
Projet Siames
42
Amandine Fressier
auprs du Manager leur cration, le Manager possdant un vecteur de pointeurs sur les
PsConfetiObject. De cette faon, quand le Manager veut accder aux proprits des PsRigidBody, il le fait par le biais d'une double indirection. Ce qui n'est pas du tout coteux en
temps de calcul et cela permet au Manager d'accder aussi bien des attributs publiques
qu' des mthodes du PsRigidBody ou ventuellement du PsConfetiObject.
Fig.
6.2 La solution adopte : communication par pointeurs
Multithreading
C'est donc cette solution que nous avons mis en place, certes, elle n'utilise
pas le systme standard de communication d'OpenMASK mais nous nous sommes assurs
que cela ne limitait pas notre programme. En eet, le fait d'utiliser des pointeurs nous fait
perdre les fonctionnalits de distribution des calculs et de rpartition de la plate-forme.
Dans notre cas, cela importe peu car les calculs les plus coteux ne se font pas dans les
PsConfetiObject ni mme dans les PsRigidBody, ils se situent au niveau de la dtection
de collision et des algorithmes de dynamique non rgulire, c'est dire dans le Manager.
C'est donc le Manager qu'il conviendrait de dcouper en threads, et cette programmation
relverait du multithreading au niveau C++ et non plus au niveau OpenMASK puisque le
Manager est un seul et unique objet de simulation.
remarque
Nous allons, dans les pages qui suivent dtailler l'implmentation des classes
mises en uvre. Pour des questions de lisibilit, nous avons prfr laisser les exemples de
code dans le texte plutt que de les mettre en annexe.
Irisa
43
Dtails de la classe PsConfetiObject
La classe PsConfetiObject est une sorte d'interface

pour les PsRigidBody. En eet, tous les attributs et mthodes ncessaires au
simulateur dynamique appartiennent toujours au PsRigidBody. La classe PsConfetiObject
sert l'initialisation, la communication et la visualisation.
Elle rcupre les paramtres d'initialisation et initialise le PsRigidBody avec.
Elle possde des sorties pour la visualisation des objets.
Elle a une fonction processEvent() qui rcupre la position et l'orientation que lui
fournit le Manager et met jour ses sorties de visualisation avec ces nouvelles valeurs.
OpenMASK
Nous allons dtailler ici l'implmentation de cette classe.

Le constructeur :
Le PsConfetiObject est un objet de simulation, il hrite donc de PsSimulatedObject, de plus,
le PsConfetiObject gre la visualisation, il hrite pour cela de PsvMechanismPartner.
la construction de l'objet, on cre ses sorties pour la visualisation :
_PosVisOuptut de type PsTranslation pour l'achage de la position de l'objet
_RotVisOutput de type PsQuaternion pour l'achage de l'orientation de l'objet
_ScaVisuOutput de type PsScale qui permet d'avoir une taille variable pour l'objet
On initialise ensuite l'attribut _body ( de type PsRigidBody *) en crant le PsRigidBody
correspondant au PsConfetiObject.
Projet Siames
44
Amandine Fressier
PsConfetiObject : : PsConfetiObject
( P s C o n t r o l l e r& c t r l , c o n s t P s O b j e c t D e s c r i p t o r& o b j e c t D e s c r i p t o r ) :
P s S i m u l a t e d O b j e c t ( c t r l , o b j e c t D e s c r i p t o r ) , / / o b j e t de s i m u l a t i o n
PsvMechanismPartner ( ) , / / pour l a v i s u a l i s a t i o n
// s o r t i e s v i s u a l i s a b l e s p o s i t i o n , o r i e n t a t i o n , c h e l l e
_PosVisOutput
( addOutput
( " PosVisu " , new PsPolator () ) ) ,
_RotVisOutput
( addOutput<PsQuaternion>
( " RotVisu " , new PsPolator <PsQuaternion >() ) ) ,
_ScaVisOutput
( addOutput
( " S c a v i s u " , new PsPolator () ) ) ,
// c r a t i o n du \ t e x t i t { PsRigidBody }
_body ( new PsRigidBody ( ) )
Dans le corps du constructeur, on passe au Manager un pointeur sur le
courant.
PsConfetiObject
// s i g n a l e DynaManager qu ' un o b j e t a t c r
PsDynaManager : : g e t I n s t a n c e ( ) . a d d C o n f e t i O b j e c t ( t h i s ) ;
Nous avons modi le Manager pour qu'il range ce pointeur dans un vecteur de pointeur de
PsConfetiObject vector <PsConfetiObject *> _VecObjects.
v o i d PsDynaManager : : a d d C o n f e t i O b j e c t ( P s C o n f e t i O b j e c t o b j )
{
// on v r i f i e que l ' o b j e t p a s s en paramtre e x i s t e
a s s e r t ( o b j != NULL ) ;
// on l ' a j o u t e au v e c t e u r de p o i n t e u r s s u r d e s P s C o n f e t i O b j e c t
_vecObjects . push_back ( o b j ) ;
}
La lecture des paramtres et l'initialisation du PsRigidBody :
ConF&TiS gre 4 types d'objets, sphre, cube, plan, bol (le cylindre reste implmenter).
Ces objets ont des paramtres d'initialisation dirents (la sphre a besoin d'un rayon, le
plan d'un largeur et d'un longueur) mais ont aussi des paramtres en communs (ils ont
tous une vitesse et une position initiale par exemple). Il faut donc lire d'abord le type
de l'objet et ensuite lire certains paramtres en fonction de ce type, ce qui est fait dans les
fonctions (ParseType Params). On lit ensuite les paramtres communs tous dans la fonction
ParseCommonParams. Avec chaque paramtre lu on initialise un attribut du PsRigidBody
auquel on accde en drfrenant _body.
Irisa
45
La fonction ProcessEvent :
Nous avons vu que c'est le Manager qui eectue tous les calculs de position et d'orientation
des objets partir des proprits des attributs des PsRigidBody auxquels il accde par une
double indirection : _vecObjects[i]->getRB()->mthodeDePsRigidBody avec getRB() une
mthode permettant d'accder l'attribut priv _body du PsConfetiObject. Or c'est le PsConfetiObject qui gre la visualisation. Il nous faut donc passer les informations de position
et d'orientation calcules chaque pas de temps par le Manager au PsConfetiObject. Comme
nous n'avons pas retenu la solution qui consistait communiquer par entre/sortie entre ces
deux objets, nous le faisons par envoi d'vnements. A chaque pas de temps, le Manager
envoie un vnement valu de nom PsDynaManager : : event_Id. Le PsConfetiObject rceptionne cet vnement dans son ProcessEvent() et met jour ses sorties visualisation avec les
valeurs contenues dans l'OutputPair.
b o o l P s C o n f e t i O b j e c t : : p r o c e s s E v e n t ( PsEvent e v e n t )
{
// vnement envoy par l e Manager
i f ( event >e v e n t I d == PsDynaManager : : _eventId )
{
PsValuedEvent<PsDynaManager : : OutputPair > vEvent =
dynamic_cast< PsValuedEvent<PsDynaManager : : OutputPair >>(e v e n t ) ;
i f ( vEvent )
{
// mise j o u r d e s s o r t i e s avec l e s v a l e u r s r e u e s du Manager
_PosVisOutput . s e t ( vEvent>v a l u e . f i r s t ) ;
_RotVisOutput . s e t ( vEvent>v a l u e . s e c o n d ) ;
}
}
}
6.2.2 Vers une plate-forme idale

Le problme que nous venons de soulever est propre aux applications qui grent une
collection d'objets indpendants mais qui doivent pouvoir interagir entre eux.
Nous pouvons envisager deux architectures pour ce type d'application.
Dans la premire, tous les objets sont indpendants et interconnects. Dans ce cas, chacun
des objets doit possder des mthodes de calcul permettant de dnir leur comportement en
fonction de celui des autres (calcul de leur trajectoire, des forces). Si l'on implmente cette
solution avec le systme de communication d'OpenMASK, cela permettrait de distribuer les
objets sur un rseau pour amliorer les performances de calcul. Cependant cette solution est
dicilement ralisable. Tout d'abord parce que la gestion de la communication serait trs
complexe. Pour une scne contenant n objets, chaque objet est connect n 1 partenaires
et possde donc n 1 paires d'entres/sorties, cela pose problme pour des scnes lourdes.
Projet Siames
46
Amandine Fressier
Ensuite il faudrait synchroniser tous ces objets de faon ce que l'action sur l'un d'eux
entrane une adaptation immdiate des autres ce qui pose des problmes de synchronisation.
L'autre solution consiste centraliser les calculs dans un objet de simulation (le Manager)
connu de tous les objets. C'est la solution que nous avons mis en place. Le Manager est
connect tous les objets et comme c'est lui qui eectue les calculs sa frquence grce
un algorithme itratif, il n'y a pas de problme de synchronisation. Dans cette solution les
objets n'ont plus grer de calculs, il n'y a donc pas besoin de les rpartir. On peut donc
se passer de la communication OpenMASK et les faire communiquer avec le Manager par
le biais de pointeurs. Par contre, il serait intressant de dcouper le Manager, qui eectue
tous les calculs, en plusieurs threads en utilisant par exemple la localisation gomtrique,
c'est dire en tablissant des zones d'inuence pour les objets. OpenMASK n'orant pas de
fonctionnalits pour dcouper un objet de simulation en threads, cela relverait donc de la
programmation C++. Cette solution nous parat la plus viable mais elle impose de ne pas
sparer les objets du Manager.
Actuellement, la communication entre objets de simulation telle qu'elle est implmente dans
OpenMASK ne fournit pas de solution adapte ce problme. En eet, OpenMASK permet
de faire communiquer des modules distincts (module de couplage avec module d'interaction
par exemple), ces modules ne comportant que quelques classes, mais ces classes pouvant
eectuer des calculs coteux. Dans ce cas, la communication OpenMASK permet de grer
facilement et avantageusement la distribution (sur plusieurs threads ou travers le rseau)
des modules.
Nous avons donc modi ConF&TiS pour l'adapter aux interactions. Nous avons pour
cela cr une classe PsConfetiObject qui permet de rendre les objets virtuels indpendants du
Manager, notamment en terme de visualisation, celui-ci ne grant plus que la partie calcul.
L'tape suivante est d'tre capable de slectionner l'objet que l'on veut piloter l'aide d'un
priphrique.
6.3 Le module d'interaction

Le "picking" concerne uniquement la slection ou la dsignation de l'objet que l'on veut
manipuler, le fait de le piloter c'est dire le fait qu'il soit coupl au priphrique n'est pas
inclut dans le "picking".
Si on excute le programme tel qu'il est implment jusqu' prsent, on a exactement le
mme rsultat que si on excutait la version originale de ConF&TiS. Nous avons test direntes simulations sur les deux versions et les rsultats des calculs eectus sur les attributs
de objets ont t exactement identiques. Ainsi, comme on peut le voir sur les gures 6.3
et 6.4, les modications apportes au niveau de l'architecture sont pour l'instant transparentes pour l'utilisateur (sauf que les initialisations des objets virtuels se font maintenant
par la chier de conguration OpenMASK et plus par le data.in ni material.in). Donc si l'on
excute ce programme, on obtient une visualisation de la scne.
On veut maintenant pouvoir slectionner un objet ach dans cette scne.
Irisa
Fig.
6.3 Utilisation de ConF&TiS avant modication
Fig.
47
6.4 Utilisation de ConF&TiS aprs modication
6.3.1 Quel type de picking ?

Le visualiseur OpenMASK propose deux sortes de dsignation :
La dsignation 2D : le visualiseur rend le nom des objets se trouvant un point donn
(dans les coordonnes de la fentre de visualisation). En clair, on peut dplacer le pointeur du priphrique dans la fentre de visualisation 2D et en cliquant (par exemple)
demander au module de visualisation d'OpenMASK quel est l'objet se trouvant sous le
pointeur. Le pointeur du priphrique se dplace dans deux dimensions et si un objet
en cache un autre, on ne peut slectionner que celui qui est visible.
la dsignation 3D : le visualiseur rend le nom des objets dont l'intersection avec la
gomtrie du curseur est non vide. Donc si un objet est cach par un autre, on peut
tout de mme le dsigner condition de faire s'intersecter la gomtrie du curseur avec
celle de l'objet cach.
Projet Siames
48
Amandine Fressier
Le priphrique que nous allons utiliser, c'est dire un bras retour d'eort, est capable
de se dplacer en 3D. Il serait donc intressant d'exploiter cette proprit au niveau de la
slection d'objets. Cela suppose la mise en place d'une dsignation 3D.
6.3.2 Les direntes solutions

solution1
De nombreux travaux sur l'interactivit ont t fait dans l'quipe. Ces travaux
ont permis de fournir un kit d'interactivit [DT04] pour OpenMASK. Ce kit est un ensemble
de classes C++ qui permettent de rendre un objet de simulation interactif et de fournir des
interacteurs (outils d'interaction) qui contrlent les objets interactifs. L'ide est d'apprendre
aux objets et aux outils d'interaction un protocole de communication qui leur permette
d'tablir des connections dynamiques entre eux, de manire ce que les outils d'interaction
puissent manipuler les objets interactifs. Ce kit d'interactivit se veut gnrique, on doit
pouvoir se servir n'importe quel priphrique pour peu que l'on puisse connatre sa position
et son orientation. Le problme qui se pose dans notre cas, c'est que la communication se
fait dans les deux sens. L'objet interactif doit recevoir la position et l'orientation de l'outil
d'interaction mais l'outil d'interaction doit galement recevoir la force qui s'applique sur
l'objet interactif. Or dans le protocole d'interaction propos dans ce kit, la communication
ne se fait que dans un sens, de l'outil d'interaction vers l'objet interactif.
Nous avons pens modier ce kit qui a l'intrt de fournir des fonctions gnriques de dsignation de faon ce qu'il autorise le renvoi d'information de l'objet vers l'outil d'interaction.
Nous n'avons pas retenu cette solution car le kit comprenant beaucoup de classes, nous avons
d'une part manqu de temps pour tudier la faisabilit d'une telle modication et d'autre
part, toujours dans un souci de simplication et de performance, nous avons prfr crer
notre propre implmentation de la dsignation.
Nanmoins, si au cours des tests, on venait s'apercevoir que le module que nous avons
implment orait des fonctionnalits insusantes, il serait possible de reconsidrer cette
solution.
solution2
Cette solution consiste implmenter un protocole d'interaction qui soit ddi

notre programme. L'intrt de concevoir un module ddi est de matriser directement la
complexit de l'architecture et de s'assurer de son ecacit.
Dans un souci de gnricit, on a prfr choisir une architecture permettant de connecter
d'autres types de priphriques que des priphriques haptiques. Pour cela, on cre une
classe Cursor3D qui permet d'associer un curseur au pointeur du priphrique mais qui sert
aussi d'intermdiaire entre le priphrique et l'objet virtuel comme on peut le voir sur la
gure 6.5. Cela permet de changer de priphrique sans modier le code de la connexion
entre le priphrique et l'objet puisque la connexion se fait en fait entre l'objet Cursor3D
et l'objet virtuel.
L'ide est donc d'associer un curseur 3D au pointeur du priphrique. Lorsque le curseur
intersecte un objet et que l'on clique pour le dsigner, le module de dsignation 3D est averti
et envoie un vnement au visualiseur pour lui demander le nom de l'objet dsign. Une fois
Irisa
49
6.5 L'objet de simulation

l'objet qu'il pilote
Fig.
Cursor3D
sert d'intermdiaire entre le priphrique et
que le module de dsignation a rcupr ce nom, il envoie une demande de connexion

l'objet dsign.
Le module de dsignation est mis en uvre dans la classe Cursor3D dont nous allons dtailler
l'implmentation.
Dtails de la classe Cursor3D Cursor3D doit pouvoir communiquer avec le visualiseur,

c'est donc un objet de simulation, de plus, il hrite de PsvMechanismPartner puisqu'il a une
gomtrie associe : celle du curseur.
Comme le curseur est associ au pointeur du priphrique, il faut que le curseur rcupre
la position, l'orientation et la vitesse de ce dernier : il a donc une entre de type PsPosition
et une entre vitesse qui sont connectes la sortie de mme type de l'interacteur (priphrique). Il doit galement fournir la force s'appliquant sur l'objet pilot au priphrique. Il
a donc une sortie force qui devra tre connecte au priphrique la cration de l'objet de
simulation reprsentant ce dernier. Par ailleurs, le curseur doit s'acher, on a donc deux
sorties visualisables une de type PsTranslation pour grer le dplacement du curseur et une
de type PsQuaternion pour grer son orientation.
Cursor3D doit communiquer par vnement avec le visualiseur pour connatre l'identit de
l'objet dsign. On lui passe le nom du visualiseur en paramtre dans le chier de conguration. Il est stock dans l'attribut _associatedPicker.
A l'initialisation, on peut aussi fournir une liste des objets virtuels non interactifs, le nom
de ces objets est stock dans un vecteur _disabled. La mthode isIn sert tester si le nom
de l'objet renvoy par le visualiseur est prsent dans ce vecteur ou non.
Dans le constructeur on cre les entres et les sorties puis on initialise les attributs avec les
valeurs passes en paramtre dans le chier de conguration. La fonction UpdateOutput()
sert mettre jour l'achage du curseur avec les valeurs rcuprs du priphrique. Elle
est appele chaque pas de temps par l'intermdiaire du compute().
La fonction ProcessEvent() traite plusieurs vnements.
Quand Cursor3D reoit un vnement Trigger du priphrique lui signalant que le clic
qui gre la dsignation a t actionn, si aucun objet n'est slectionn, il envoie un vnement
Projet Siames
50
Amandine Fressier
au visualiseur avec la position et l'orientation du curseur quand s'est produit le clic, si un

objet est dj slectionn alors il dconnecte son entre force et envoie une demande de
dconnection l'objet.
b o o l Cursor3D : : p r o c e s s E v e n t ( PsEvent e v e n t )
{
// g a r d e l a v a l e u r du d e r n i e r o b j e t p i c k pour s a v o i r
// s i on d o i t d c o n n e c t e r ou c o n n e c t e r
s t a t i c PsName partnerName ;
// s e n d e r : XMouseTrigger ,
// g o a l : t o s i g n a l a p i c k on t h i s o b j e c t ( Cursor3D )
i f ( event >e v e n t I d == " T r i g g e r " ) {
i f ( c o n n e c t e d==f a l s e ) / / i f c u r s o r i s f r e e
{
// t r a d u c t i o n de l a p o s i t i o n r e u e pour l ' e n v o y e r au v i s u a l i s e u r
...
...
...
// e n v o i au v i s u a l i s e u r
sendValuedEvent ( _ a s s o c i a t e d P i c k e r ,
" omniPick " ,
PsPair<PsTranslationHPRRotation , PsFloat >( a x e V i s e e , P s F l o a t ( 1 0 ) ) ) ;
}
else
{// p a r t n e r i s i n i t i a l i z e d b e c a u s e c o n n e c t e d = t r u e
sendEvent ( partnerName , " d i s c o n n e c t i o n " ) ;
}
}
Le visualiseur renvoie
dsign.
Cursor3D
un vnement
Picked
qui contient le nom de l'objet
// s e n d e r : a s s o c i a t e d P i c k e r ( v i s u )
// g o a l : g e t t h e PsName o f t h e p i c k e d o b j e c t
i f ( e v e n t > e v e n t I d == " p i c k e d " ) {
// PsValuedEvent<PsPair >
PsValuedEvent valuedEvent =
dynamic_cast< PsValuedEvent > ( e v e n t ) ;
// nom de l ' o b j e t d s i g n
partnerName = valuedEvent > v a l u e . getPartnerName ( ) ;
Irisa
51
Ensuite, s'il y a bien eu un objet dsign et si cet objet est autoris interagir, alors Cursor3D
envoie un vnement de demande de connexion cet objet, en lui fournissant son nom et le
nom des entres auxquelles l'objet doit se connecter.
// s i i l y a un o b j e t d s i g n
// e t s i c e t o b j e t e s t a u t o r i s i n t e r a g i r
i f ( ( partnerName not_eq ( PsName ( "NULL" ) ) ) and ( ! i s I n ( partnerName ) ) )
{
i f ( ( partnerName not_eq PsName ( " " ) )
{
// pour p i l o t a g e
c o n n e c t e d = t r u e ; / / un o b j e t e s t maintenant en i n t e r a c t i o n
// OutputNames : nom d e s s o r t i e s de \ t e x t i t { Cursor3D } a u x q u e l l e s
// l ' o b j e t d s i g n ( partnerName ) d o i t s e c o n n e c t e r
sendValuedEvent<EValue>
( partnerName , " ReadyForConnection ? " , OutputNames ) ;
}
e l s e { connected = f a l s e ; }
}
e l s e { connected = f a l s e ; }
Dtails des modications de la classe PsConfetiObject
Pour que l'objet se connecte,

il faut modier la classe PsConfetiObject : Pour que l'objet puisse tre pilot par le priphrique via Cursor3D, il faut que PsConfetiObject ait les entres appropries pour recevoir la
position, l'orientation et la vitesse. Il faut aussi qu'il dispose d'une sortie force pour pouvoir
la transmettre au priphrique via Cursor3D.
_PosInput ( addInput ( " p o s i t i o n " ) ) ,
_RotInput ( addInput<PsQuaternion> ( " o r i e n t a t i o n " ) ) ,
_SpeedInput ( addInput<PsArray<6>>) ( " v i t e s s e " ) ) ,
_ForceOutput ( addOuptut<PsArray<6>>) ( " Force " ) )
La fonction ProcessEvent() est modie. Quand l'objet reoit un vnement de demande

de connexion de Cursor3D, il connecte ses entres aux sorties du Cursor3D et renvoie un
vnement autorisant Cursor3D connecter son entre force la sortie correspondante
de l'objet. Quand il reoit un vnement de dconnection, il les dconnecte. Sa fonction
compute() change galement, si le PsConfetiObject est eectivement connect alors il ne
reoit plus ses informations de position via le Manager mais via Cursor3D, il faut donc que
dans sa fonction compute() il mette jour ses sorties visualisables. Par ailleurs pour que le
mouvement de l'objet soit uide il faut que cette mise jour se fasse une frquence l'ordre
d'une soixantaine de Hertz. Les PsConfetiObject sont donc crs avec une telle frquence.
Projet Siames
52
Amandine Fressier
i f ( _body>get_connected ( ) == t r u e )
{
// mise j o u r d e s s o r t i e s v i s u de l ' o b j e t c o u r a n t
// par l e s v a l e u r s f o u r n i e s par Cursor3D
_PosVisOutput . s e t ( _PosInput . g e t ( ) ) ;
_RotVisOutput . s e t ( _RotInput . g e t ( ) ) ;
}
6.3.3 Bilan sur le module d'interaction

Aprs avoir, dans un premier temps, modi ConF&TiS pour l'adapter aux interactions
nous avons implment la dsignation des objets. Nous avons pour cela cr une classe Cursor3D qui permet savoir quel objet on dsigne avec le curseur et de connecter l'objet dsign
n'importe quel type de priphrique. Il nous a fallu rajouter des fonctionnalits la classe
PsConfetiObject pour qu'elle sache rpondre aux demandes de connexion/dconnection de
Cursor3D.
L'tape suivante est celle du couplage, car pour l'instant mme si la connexion est tablie
entre le priphrique et le PsConfetiObject (via Cursor3D ), ce dernier ne transmet pas les
valeurs reues au Manager et ne renvoie pas non plus les forces au priphrique.
6.4 Le couplage
Jusqu'ici nous avons dtaill de quelle faon Cursor3D assure la connexion entre le priphrique et le PsConfetiObject. Dans ce chapitre, nous allons tudier l'tape suivante, c'est
dire comment les paramtres de vitesse et de position (et orientation) fournis par le priphrique passent du PsConfetiObject au Manager et inversement, autrement dit comment
la force calcule par le Manager est transmise au PsConfetiObject. Nous verrons galement
comment le priphrique est reprsent d'un point de vue OpenMASK.
6.4.1 Prcisions concernant l'existant

Nous avons vu qu' chaque pas de temps, le Manager applique un algorithme de prdiction/correction. Sur la premire partie du pas de temps, il prdit la position et l'orientation
des objets sans tenir compte des interactions. Il calcule ensuite les contacts qui vont avoir
lieu suivant cette prdiction. Sur la dernire partie du pas de temps, il corrige les trajectoires
fonction des contacts dtermins prcdemment. Nous avons aussi vu que les objets peuvent
tre pilots par la simulation en spciant la vitesse pour chaque degr de libert. Dans le
cas d'un objet pilot par un priphrique, c'est exactement la mme chose sauf que c'est le
priphrique qui fournit ces vitesses au lieu que ce soit le chier de conguration.
Nous allons dtailler le calcul des vitesses par le simulateur dynamique pour ensuite expliquer quelles sont les modications apporter ces calculs lorsqu'un objet est pilot par un
Irisa
53
priphrique.
A chaque pas de temps, pour chaque objet, le Manager :
1. calcule la vitesse libre c'est dire en ne prenant en compte que la gravit. Dans le cas
d'un objet pilot par la simulation cette vitesse est fournie l'initialisation.
2. prdit la position et l'orientation sans tenir compte des contacts.
3. dtermine les contacts
4. corrige la position, l'orientation et la vitesse eectives en tenant compte des contacts
calculs l'tape prcdente. Dans le cas d'un objet libre, la vitesse eective est calcule
partir de la vitesse libre et des contraintes de contacts. Dans le cas d'un objet pilot,
la vitesse eective est celle fournie l'initialisation, la mme qu'en 1. . Quant la
position et l'orientation, elles sont dtermines fonction des positions et orientations
prdites et de la vitesse eective que l'objet soit pilot ou pas.
5. met les valeurs de position, d'orientation et de vitesse jour pour le prochain pas de
temps.
Nous devons maintenant voir comment modier ces fonctions de calcul dans le cas d'un
objet pilot par un priphrique.
6.4.2 Modications eectues

Les modications eectues sont minimes puisque ConF&TiS orait dj la possibilit
de piloter des objets.
Si nous reprenons dans l'ordre les tapes des calculs du Manager, dans le cas d'un objet
pilot par un priphrique :
1. la vitesse libre est fournie par le priphrique
2. la position et l'orientation prdites sont celles fournies par le priphrique
3. les calculs concernant les contacts ne sont pas modis
4. la position, l'orientation et la vitesse calcules dans la fonction de correction sont celles
fournies par le priphrique.
5. la mise jour ne change pas, les valeurs tant modies dans les fonctions de prdiction
et de correction.
Ces modications tant eectues, il reste le problme de passer les valeurs du
au Manager.
PsConfe-
tiObject
Remarque
Une fois ces modications eectues, le Manager peut grer la visualisation

de l'objet pilot car il a accs toutes les donnes de position et d'orientation ncessaires. On
pourrait donc se passer de la fonction compute des PsConfetiObject qui ne contient que la
mise jour des sorties visualisables dans le cas o l'objet est pilot. Le fait de supprimer
cette fonction permet aux PsConfetiObject d'avoir une frquence nulle, ils peuvent donc tre
nombreux sans que cela ne soit trop coteux. Cette solution reste tester.
Projet Siames
54
Amandine Fressier
6.4.3 D'un point de vue OpenMASK

Il convient de rappeler que les fonctions de calculs cites au dessus sont des mthodes
des objets C++ PsRigidBody. Le PsConfetiObject reoit position, orientation et vitesse du
priphrique via Cursor3D qu'il doit transmettre son PsRigidBody associ. Il doit galement fournir Cursor3D le force calcule par le Manager et disponible comme attribut du
PsRigidBody. Pour cela, nous implmentons des fonctions d'criture et de lecture sous forme
de mthodes de PsRigidBody : set_Vitesse, set_Position, set_Orientation, get_Force.
Il nous reste dterminer quand appeler ces fonctions. Dans le cas d'un objet libre ou pilot
par le simulateur dynamique, la mise jour des valeurs est la charge du Manager, elle se
fait donc la frquence de ce dernier. Pour que le calcul de l'interaction entre l'objet pilot
et les autres objets soit prcis, il faut qu' chaque pas de temps du Manager, l'objet pilot
fournisse des nouvelles donnes.
Il y a deux solutions pour ce faire.
solution1
La premire solution consiste appeler ces fonctions dans la fonction compute()

du PsConfetiObject s'il est pilot.
Cette mise jour des valeurs dans la fonction compute() du PsConfetiObject impose que
celui-ci ait une frquence suprieure celle du Manager. En eet, comme nous l'avons vu,
c'est le Manager qui appelle les mthodes de calculs des PsRigidBody sa propre frquence.
Il faut donc que quand il fasse ces appels, les valeurs du PsRigidBody soient jour. C'est
pour cela qu'il faut que la frquence des PsConfetiObject soit suprieure celle du Manager.
En pratique cela impose une frquence de minimum une centaine de Hertz pour tous les
PsConfetiObject puisqu'ils sont tous potentiellement pilotables par un priphrique. Si la
simulation contient beaucoup d'objets (plusieurs milliers) cela peut devenir coteux en temps
de calcul, mme si les calculs appels chaque pas de temps sont minimes.
La volont de rduire les temps de calcul au maximum nous amne la seconde solution.
solution2 La solution prcdente est coteuse car elle implique une frquence leve pour
tous les objets de la simulation. Or on ne peut en piloter qu'un la fois. L'ide est donc
d'augmenter uniquement la frquence de l'objet pilot.
Le problme est que la frquence d'un objet de simulation est un paramtre xe donn
l'initialisation par le biais du chier de conguration. Si on ne voulait pas avoir la possibilit
de changer d'objet pilot en cours de simulation, on pourrait penser choisir un seul PsConfetiObject pilotable pour toute la simulation et lui xer une frquence adquate. Mais nous
souhaitons pouvoir changer d'objet piloter en cours de simulation, il faut donc trouver un
moyen de le distinguer des autres dynamiquement.
Pour cela, il sut de remarquer que ce qui caractrise un objet pilot c'est qu'il est connect
Cursor3D. La solution consiste donc augmenter la frquence de l'objet de simulation
Cursor3D de faon ce qu'elle soit suprieure celle du Manager. De cette faon, chaque
pas de temps, Cursor3D peut envoyer un vnement au PsConfetiObject qui lui est connect
pour lui signaler qu'il doit mettre les valeurs de son PsRigidBody jour.
Irisa
55
Cette solution est moins coteuse en temps de calcul que la solution prcdente car quelque
soit le nombre d'objets simuler, il n'y a que Cursor3D qui a une frquence leve.
Remarque
Cette solution implique de choisir celle propose dans la remarque prcdente.

En eet, si un objet a une frquence impose alors le traitement des vnements ce fera
cette frquence or dans la solution propose la remarque prcdente, la fonction compute()
des PsConfetiObject est vide et donc leur frquence nulle, les vnements seront donc traits
la frquence o ils sont reus. Il faut cependant remarquer que puisque la fonction compute() des objets est vide, ils ne peuvent plus transmettre la force Cursor3D. Il faut donc
que ce soit le Manager qui chaque pas de temps envoie un vnement l'objet pilot pour
lui signaler de mettre sa sortie force jour.
Cette implmentation parat tre la plus performante en terme de temps de calcul. Le problme de cette solution est une ventuelle dsynchronisation entre la visualisation de l'objet
pilot et celle du curseur. En eet, les sorties visualisables du curseur sont mises jours
la frquence de Cursor3D et celles de l'objet pilot sont mises jour la frquence du
Manager. Mme si ces deux objets de simulation ont la mme frquence, il n'est pas garantit
qu'ils soient synchroniss. Si cette dsynchronisation est vrie, alors le rendu visuel sera
approximatif, le curseur risquant d'tre lgrement dcal par rapport l'objet pilot ce qui
induit une mauvaise qualit d'interaction pour l'utilisateur.
Nous n'avons mis en uvre aucune de ces solutions par manque de temps, nanmoins
elles nous semblent toutes intressantes tester, en commenant par celle nonce dans la
dernire remarque car c'est la plus conome en temps de calcul.
6.4.4 Reprsentation OpenMASK du priphrique retour d'eort

Une fois une des ces solutions implmente, il ne reste qu' concevoir l'objet de simulation
correspondant au priphrique retour d'eort. La gure suivante rappelle de quelle faon
nous avons choisi de concevoir la communication entre le priphrique et l'objet manipuler.
Fig.
6.6 Rappel de l'architecture de la dsignation
Ce schma rsume ce qu'il faut implmenter pour que le priphrique puisse communiquer avec le reste de notre programme.
Pour communiquer avec le PsConfetiObject via Cursor3D, la classe reprsentant le bras doit
Projet Siames
56
Amandine Fressier
avoir une entre pour rcuprer la force qui s'applique sur l'objet qu'il pilote, une sortie
position/orientation et une sortie vitesse pour fournir ces donnes l'objet pilot.
La connexion avec Cursor3D se fait ds la cration des entres/sorties puisque Cursor3D
contient la gomtrie associe au pointeur du priphrique. Ces deux objets sont donc connects en permanence.
La frquence de cet objet doit tre 1000Hz, or il peu probable que cette frquence soit atteinte
par le simulateur dynamique. Une solution habituelle consiste mettre les valeurs fournies
par le simulateur dynamique dans un tampon et tant que ces valeurs ne sont pas mises
jour, on fournit au bras la dernire valeur connue. Dans notre cas, vu que la connexion avec
Cursor3D est permanente, il n'y a pas besoin de mettre en place un mcanisme de ce genre,
les entres/sorties OpenMASK le font automatiquement. Sur la sortie force de Cursor3D, la
dernire valeur fournie reste disponible et donc le priphrique peut la relire la frquence
voulue.
Mme en fournissant au bras des valeurs une frquence de 1000Hz, il est frquent de rencontrer des problmes de vibration ou d'instabilit. Il est alors possible de mettre en place
un systme de ltrage des valeurs reues directement dans la classe de l'objet de simulation.
Irisa
57
Chapitre 7
Synthse de la mise en uvre

Comme nous l'avons dj prcis, nous n'avons pas eu le temps de nir l'implmentation
du module d'interaction, ni du module de couplage. Nanmoins, la version du simulateur dynamique compatible avec l'interaction a t implmente, ainsi que la slection et le contrle
d'un objet avec la souris.
Dans le module d'interaction, au niveau de la classe Cursor3D, il reste mettre en place
la gestion de la vitesse et de la force (entres/sorties et vnements) puisque pour l'instant seules la position et l'orientation de l'objet pilot sont prises en compte. Le module
de couplage reste implmenter. Si on choisit la solution o les PsConfetiObject ont une
frquence nulle, il faut modier la classe du Manager pour qu'il transmette la force calcule,
il faut galement modier les PsRigidBody et les PsConfetiObject en consquence. La classe
reprsentant le priphrique retour d'eort doit aussi tre cre.
Nous avons deux dmonstrations de nos travaux en cours. Nous avons vu que la premire
tape de notre travail a t de modier le simulateur dynamique ConF&TiS pour qu'il soit
adapt l'interaction avec l'utilisateur. Il a fallu vrier que les modications eectues
ne remettaient pas en cause les rsultats du simulateur dynamique. Nous avons excut les
mmes simulations sur les deux versions de ConF&TiS et nous avons vri que les positions,
les vitesses et les eorts calculs tait identiques. La gure 7.1 montre une des simulations
teste. Trois billes de mme rayon et une balle plus grosse tombent dans un bol.
Projet Siames
58
Amandine Fressier
Fig.
7.1 Test du simulateur dynamique modi pour l'interaction
La deuxime dmonstration disponible concerne la slection d'un objet avec la souris.

En eet, nous avons implment le module d'interaction avant d'implmenter l'objet de
simulation reprsentant le priphrique retour d'eort. Nous avons donc test ce module
avec la souris. Cette dmonstration permet l'utilisateur de slectionner un objet virtuel
l'aide d'un curseur et une fois cette objet slectionn, il peut le manipuler et bien sur le
dslectionner et en choisir un autre. Dans la premire vignette de la gure 7.2, le curseur
est libre, il ne slectionne aucun objet. Puis l'utilisateur fait s'intersecter la gomtrie du
curseur avec celle d'un objet virtuel et en cliquant, il slectionne cet objet. Il peut alors le
piloter et le relcher en cliquant nouveau. Sur la gure 7.2 la gomtrie du curseur peut
paratre encombrante, mais elle est facilement remplaable, il sut de modier le chier
vrml la dcrivant.
Dans cette dmonstration, la position et la vitesse de l'objet pilot ne sont pas communiques au simulateur dynamique, cette partie reste faire.
Irisa
Fig.
Projet Siames
7.2 Interaction avec un objet virtuel l'aide de la souris
59
60
Amandine Fressier
Chapitre 8
Conclusion
Dans ce rapport, nous avons prsent une tude bibliographique qui nous a amen
proposer une solution pour amliorer le rendu haptique des chocs et des contacts. Cette proposition met en uvre la dynamique non rgulire. Nous pensons d'un part qu'un simulateur
dynamique bas sur la dynamique non rgulire propose un meilleur rendu des forces qu'un
simulateur classique bas sur une mthode de pnalisation car contrairement ce dernier,
la dynamique non rgulire modlise une ralit. D'autre part, nous avons vu qu'elle nous
permet de nous aranchir du couplage virtuel comme le montre la gure 8.1, ce qui doit
nous permettre d'avoir une meilleure qualit de restitution des eorts pour l'utilisateur.
8.1 Le couplage entre un bras retour d'eort et ConF&TiS ne ncessite pas de

couplage virtuel
Fig.
Notre proposition se dcline en trois modules pour lesquels nous avons dni une mise en
uvre en utilisant la plate-forme OpenMASK du projet SIAMES, mise en uvre que l'on
peut voir en partie sur la gure 8.2. Le module de simulation dynamique issu des travaux
Irisa
61
de Mathieu Renouf a t adapt nos besoins en interaction en utilisant les fonctionnalits

de la plate-forme. Nous avons ensuite conu les modules d'interaction et de couplage.
Fig.
8.2 Couplage entre le priphrique et l'objet virtuel
Pour nir, nous avons propos deux dmonstrations. La premire concerne les modications du simulateur dynamique. Cette dmonstration nous a permis de nous assurer que les
changements apports au simulateur n'ont pas modi les rsultats des calculs. La deuxime
dmonstration rete l'avancement de notre travail. Elle concerne l'interaction avec l'utilisateur, elle lui permet de slectionner et de piloter un objet de la simulation la souris. Pour
que la mise en uvre soit termine, il reste nir d'implmenter la communication entre le
simulateur dynamique et le priphrique.
Une fois l'implmentation acheve, pour dterminer si notre proposition permet d'amliorer sensiblement la qualit d'interaction, il sera ncessaire de se confronter des modles
existants. Nous avons pens par exemple l'API de ReachIn qui permet une qualit d'interaction trs concluante avec les bras retour d'eort de Sensable, la comparaison avec
notre proposition se fera donc en utilisant le priphrique OmniPhantom. Cependant, il sera
galement souhaitable de tester notre proposition avec un priphrique retour d'eort
six degrs de libert (comme le Virtuose d'Haption) pour pouvoir tester la restitution du
couple. Pour exploiter pleinement le couplage avec un tel priphrique il faudra modier le
module d'interaction pour pouvoir autoriser la slection d'objet par des points autre que
leur centre de gravit. De cette manire, le couple pourra rellement tre test.
Par ailleurs, dans le but d'amliorer les rsultats des tests, on peut d'ores et dj envisager plusieurs axes de travail. Dans notre rapport, nous avons propos plusieurs solutions
de mise en uvre qui diraient essentiellement par la frquence des objets de simulation
reprsentant les objets virtuels. Dans un cas, cette frquence tait nulle et dans l'autre elle
tait plus leve que celle du simulateur dynamique. Il faudrait tester ces deux solutions
pour dterminer laquelle est la plus performante au niveau des temps de calcul mais aussi
au niveau de la qualit d'interaction. Puis, toujours dans un souci de performance, il serait
intressant d'tudier la rpartition du simulateur dynamique sur plusieurs threads.
Projet Siames
62
Amandine Fressier
Bibliographie
[CLMP95] J. Cohen, M. Lin, D. Manocha, and K. Ponamgi. I-collide : An interactive
and exact collision detection system for large-scale environments. Proceedings of
ACM Int. 3D Graphics Conference, pages 189196, 1995.
[CSC05]
Daniela Constantinescu, Septimiu E. Salcudean, and Elizabeth A. Croft. Local

model of interaction for haptic manipulation of rigid virtual worlds. Int. J. Rob.
Res., 24(10) :789804, 2005.
[DT04]
T. Duval and C. Le Tenier. Interactions 3d coopratives en environnements

virtuels avec openmask pour l'exploitation d'objets techniques. In Mcanimes et
Industries, pages 129137, 2004.
[Dum05]
Georges Dumont. Simulation mcanique et ralit virtuelle : outils d'aide la

comprhension et la conception des systmes, November 2005. Habilitation
Diriger des Recherches, prsente le 23 novembre 2005.
[FAT03]
Philippe Fuchs, Bruno Arnaldi, and Jacques Tisseau. Le trait de la ralit

virtuelle, 2me dition, chapter La ralit virtuelle et ses applications, pages
351. Presses de l'Ecoles de Mines de Paris, October 2003.
[FMT06]
Philippe Fuchs, Guillaume Moreau, and Jacques Tisseau. Le trait de la ralit

, chapter Les outils et modles informatiques
des environnements virtuels. Presses de l'Ecoles de Mines de Paris, March 2006.
virtuelle, 3me dition, Volume 3
[GLGT00] A. Gregory, M.C Lin, S. Gottschalk, and R. Taylor. Fast and accurate collision
detection for haptic interaction using a three degree-of-freedom force-feedback
device. Comput. Geom. Theory Appl., 15(1-3) :6989, 2000.
[GLM96]
S. Gottschalk, M. C. Lin, and D. Manocha. Obbtree : a hierarchical structure for

rapid interference detection. In SIGGRAPH '96 : Proceedings of the 23rd annual
conference on Computer graphics and interactive techniques, pages 171180, New
York, NY, USA, 1996. ACM Press.
[HS04]
S. Hasegawa and M. Sato. Real time rigid body simulation for haptic interactions based on contact volume of polygonal objects. Comput. Graphic. Forum,
23(3) :529538, 2004.
Irisa
63
[HWN04] Jesse D. Hwang, Michael D. Williams, and Gnter Niemeyer. Toward eventbased haptics : Rendering contact using open-loop force pulses. In HAPTICS,
pages 2431, 2004.
[KFN05] Katherine J. Kuchenbecker, Jonathan Fiene, and Gnter Niemeyer. Event-based
haptics and acceleration matching : Portraying and assessing the realism of
contact. In WHC, pages 381387, 2005.
[LAC03] A. Lcuyer, C. Andriot, and A. Crosnier. Interfaces haptiques et pseudohaptiques. In Proceedings of JNRR'03 (4me Journes Nationales de la Recherche en Robotique), 2003.
[LG98]
Ming C. Lin and Stefan Gottschalk. Collision detection between geometric models : a survey. Proc. of IMA Conference on Mathematics of Surfaces, 1998,
1998.
[LMCL01] Sompong Lertpolpairoj, Thavida Maneewarn, Siam Charoenseang, and Djitt
Laowattana. The eect of static virtual couplings on realistic performance of
haptic systems. Prooceedings of the 4th Asian Conference on Robotics and its
Applications, Singapore, 2001.
[LML02] S. Lertpolpairoj, T. Maneewarn, and S. Laowattana. Realistic and stability performances of haptic system with adaptive virtual coupling. Industrial Technology,
2002. IEEE ICIT '02. 2002 IEEE International Conference, 11-14 Dec. 2002,
1 :382 387, December 2002. 11-14.
[MAS03] T. Meyer, G. Andrade, and J.-M Souez. Un tat de l'art sur les logiciels de
dtection de collision. GTAS Brest, 2003.
[MW88]
M. Moore and J. Wilhelms. Collision detection and response for computer animation. In Proceedings of SIGGRAPH '88, pages 289298. ACM Press, 1988.
[OHT]
OpenHaptics Toolkit Programmer's Guide version 1.0.
[PPG04] M. Pauly, D. K. Pai, and L. J. Guibas. Quasi-rigid objects in contact. In
Proceedings of SCA '04, pages 109119. ACM Press, 2004.
[RAD05] Mathieu Renouf, Vincent Acary, and Georges Dumont. Comparison of algorithms for collisions, contact and friction in view of real-time applications. In
Multibody Dynamics 2005 : International Conference on Advances in Computa-
. ECCOMAS, June 2005.

S. Redon, A. Kheddar, and S. Coquillart. Fast continuous collision detection
between rigid bodies. S. Redon. A. Kheddar and S. Coquillart. Fast continuous
tional Multibody Dynamics
[RKC02]
collision detection between rigid bodies. In Proceedings of Eurographics, Septem-
[SH96]
[Sou02]
ber 2002., 2002.

D. Stoianovici and Y. Hurmuzlu. A critical study of the applicability of rigid
body collision theory. ASME J. Appl. Mech., 63, 1996.
J. M. Souez. Optimisation d'algorithmes de traitement de contact et de chocs
entre solides rigides. Master's thesis, Universit de Rennes 1, June 2002. Stage
de DEA.
Projet Siames
64
Amandine Fressier
Irisa

Fressier Master 06

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fressier Master 06

Uploaded by

Copyright:

Available Formats

RAPPORT DE STAGE DE MASTER 2 RECHERCHE

Amlioration de la perception des contacts et des chocs entre solides

Table des matires

2 Traitement des interactions

Dtection des interactions . . . . . . .

II Conception et mise en uvre du couplage entre le simulateur

Rappels sur la dtermination des eorts d'interaction

6 Conception des dirents modules

7 Synthse de la mise en uvre

tude bibliographique prliminaire

Stage de Master 2 Recherche

1.1.2 Temps rel

1.1.3 Retour haptique

1.2 Gnralits sur le traitement des interactions

Stage de Master 2 Recherche

1.1  Schma caractristique d'une simulation haptique

Stage de Master 2 Recherche

Traitement des interactions

2.1 Dtection des interactions

2.1.2 Quelques techniques

Stage de Master 2 Recherche

Une technique continue

Ce bref tat de l'art de la dtection de collision nous permet de noter qu'il y a

2.2 Dtermination des eorts d'interaction

2.2.1 Mise en quations

des eorts externes (y compris les termes de Coriolis et d'entranement) et R est le

Stage de Master 2 Recherche

2.2.2 Mthode de pnalisation

2.2.3 Dynamique non rgulire

M (q)dq = Q(q, q, t)dt + dR

ou dt est la mesure de Lebesgue, dq reprsente l'acclration et dR est un rel non ngatif

qui peut se rcrire en :

Loi de frottement de Coulomb

Loi d'impact de Newton

Stage de Master 2 Recherche

2.1  La planche bascule puis tombe

Stage de Master 2 Recherche

2.2  Un exemple de traitement des interactions multiples avec contact initial

2.4  mergence de la bille de grand diamtre

Dans le cadre de ce stage, la simulation ne contiendra que quelques solides,

Stage de Master 2 Recherche

Stage de Master 2 Recherche

3.2 Problmatique du couplage temps rel

Stage de Master 2 Recherche

Conception et mise en uvre du

Stage de Master 2 Recherche

4.1 Rappels sur la dtermination des eorts d'interaction

le priphrique fourni au simulateur dynamique la position et la vitesse de son pointeur et

Stage de Master 2 Recherche

4.2 Le couplage virtuel

4.3 Notre proposition

4.4 Les rsultats attendus

Le but de ce stage est de voir si les avantages de la dynamique non rgulire

Stage de Master 2 Recherche

Animation and Simulation Kit, disponible sur

5.1.2 La programmation dans OpenMASK

5.1.3 L'objet de simulation OpenMASK

Stage de Master 2 Recherche

5.1.4 La visualisation dans OpenMASK

5.2 ConF&TiS (Contacts, Frottements & Time Stepping)

5.1  Utilisation de la version originale de ConF&TiS

Les chiers .in contiennent les paramtres ncessaires l'initialisation de ConF&TiS.

5.2.3 Principe de fonctionnenemt

Stage de Master 2 Recherche

Rappels sur la dtermination des eorts d'interaction

6 Conception des dirents modules

1.1 Schma caractristique d'une simulation haptique

2.2 Dtermination des eorts d'interaction

des eorts externes (y compris les termes de Coriolis et d'entranement) et R est le

2.1 La planche bascule puis tombe

2.2 Un exemple de traitement des interactions multiples avec contact initial

2.4 mergence de la bille de grand diamtre

4.1 Rappels sur la dtermination des eorts d'interaction

5.1 Utilisation de la version originale de ConF&TiS

Les chiers .in contiennent les paramtres ncessaires l'initialisation de ConF&TiS.

5.2 Architecture de ConF&TiS

Conception des dirents modules

6.1 Communication par entres/sorties OMK (OpenMASK)

6.2 La solution adopte : communication par pointeurs

6.3 Utilisation de ConF&TiS avant modication

6.4 Utilisation de ConF&TiS aprs modication

6.3.2 Les direntes solutions

6.5 L'objet de simulation

Dtails des modications de la classe PsConfetiObject

La fonction ProcessEvent() est modie. Quand l'objet reoit un vnement de demande

6.4.2 Modications eectues

Une fois ces modications eectues, le Manager peut grer la visualisation

6.4.4 Reprsentation OpenMASK du priphrique retour d'eort

6.6 Rappel de l'architecture de la dsignation

7.1 Test du simulateur dynamique modi pour l'interaction

7.2 Interaction avec un objet virtuel l'aide de la souris

8.1 Le couplage entre un bras retour d'eort et ConF&TiS ne ncessite pas de

8.2 Couplage entre le priphrique et l'objet virtuel