Résultats Expérimentaux

Toutes les expérimentations ont été réalisées sur un robot mobile réel. Lina (figure 6.25) est un robot mobile circulaire (55 cm de diamètre) à deux roues. Ses vitesses maximales (linéaire et rotation) sont respectivement de 1, 2 ms⁻¹ et 4 rds⁻¹. Les codeurs optiques des moteurs sont utilisés pour l’odométrie (calcul local de la trajectoire). Par ailleurs, Lina est équipé de 12 capteurs ultrason déphasés de 30^◦. Dans le cadre des présentes implémenta-tions, nous n’avons utilisé que les 7 capteurs frontaux. Les indices x0à x6, représentent les distances récupérées par les capteurs de gauche à droite. Du coté utilisateur, nous avons utilisé un bras Phantom Omni de la société Sensable.

(a) _(b) (c)

Figure 6.26 – Situations classiques rencontrées au sein d’un environnement d’intérieur.

Nous avons validé notre modèle de commande et la stratégie du retour d’effort dans diverses situations que l’on peut rencontrer dans les environnements intérieurs : suivi d’un mur, déplacement vers un obstacle et franchissement des portes (passage entre deux obstacles), Figure 6.26. Pour chacune de ces expérimentations, 4 situations de rendu hap-tique ont été testées. Dans la première situation “SE”, aucune force n’est rendue à l’opé-rateur. Cette situation constitue une base de comparaison avec les différents cas restants. Dans la seconde situation “SR”, nous avons accompli des expérimentations classiques avec rendu d’effort et sans retard de transmission (Figure 6.27). Dans la troisième si-tuation “RNC”, un retard de communication est introduit sans commande stabilisante (Figure 6.28). La dernière situation “RC”, correspond à une compensation du retard par des approches prédictives (Figure 6.29).

Quatre sujets, âgés de vingt-cinq à trente ans, ont pris part aux expérimentations. Ils sont doctorants au laboratoire, donc familiers avec les robots mobiles et la téléopération, mais pas avec un joystick type Phantom Omni. Les sujets ont une vingtaine de minutes pour se familiariser avec le rendu haptique. Cet apprentissage a été mené sans retard de transmission.

0 50 100 150 200 250 300 350 400 −1.6 −1.4 −1.2 −1 −0.8 −0.6 −0.4 −0.2 0 0.2 0.4 Points (10 msec) Rendu de Force (N) Force/X Force/Y Obstacle Effet du Joystick 0 50 100 150 200 250 300 350 400 −60 −40 −20 0 20 40 60 80 Points (10 msec)

Déplacements du Dispositif Haptique (mm) _{Déplacement/Y}

Déplacement/X 0 50 100 150 200 250 300 350 400 −0.1 0 0.1 0.2 0.3 0.4 0.5 0.6 Points (10 msec)

Vitesses Linéaire (m/s) et angulaire (rad/sec) du Robot Mobile

Vit. Linéaire Vit. Angulaire

Figure 6.27 – Robot Mobile face à un mur τ_i =0 : (a) Rendu de forces, (b) Déplacements du dispositif and

(c) Vitesses linéaire et angulaire du Robot Mobile

Les Figures 6.27 illustrent le comportement de l’interaction haptique dans des condi-tions idéales (sans retard). L’opérateur humain commande le robot mobile pour se rappro-cher d’un mur. Nous constatons au début de l’expérience une faible force correspondant à l’effet joystick, nécessaire pour la remise à la position neutre du dispositif haptique. Nous remarquons également que le retour de force est modulé en fonction de la distance entre le robot et l’obstacle (selon xi, xspringet xwall).

0 10 20 30 40 50 60 −0.4 −0.2 0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 Temps (sec) Retour de Forces (N) Force/X Force/Y

Dans la Figure 6.28, on peut remarquer un comportement instable du rendu haptique au cours d’une même expérience que la précédente. Mais, les retards sont ici de 100msec (aller-retour). Du fait des vibrations transitoires, l’opérateur ne peut pas se constituer une idée claire sur l’évolution du robot mobile.

0 10 20 30 40 50 60 −1 −0.5 0 0.5 1 1.5 2 Temps (sec) Forces de retour (N) Force/X Force/Y 0 10 20 30 40 50 60 −60 −40 −20 0 20 40 60 80 Temps (sec)

Déplacements du dispositif Haptic (mm)

Déplacement/X Déplacement/Y 0 10 20 30 40 50 60 −0.02 0 0.02 0.04 0.06 0.08 0.1 0.12 0.14 Temps (sec)

Vitesses linéaire (m/sec) et angulaire (rad/sec) du Robot

Vit. linéaire Vit. angulaire

Figure 6.29 – Robot Mobile se faufilant entre deux obstacles sous un retard de τ_i=200msec : (a) Rendu

de forces, (b) Déplacements du disposotif and (c) Vitesses linéaire et angulaire du Robot Mobile

Les Figures 6.29 présentent l’évolution du robot mobile naviguant dans un environ-nement complexe. L’objectif est de pouvoir faire se faufiler le robot mobile entre deux obstacles. L’expérience est réalisée avec un retard τi =200msec. Les courbes montrent un rendu de force stable. Mais du fait d’un retard important et une commande en vitesse du robot mobile, les opérateurs se sentent obligés de ralentir ou adapter leur commande pour passer entre les obstacles sans les heurter. Cette difficulté décroit avec un apprentis-sage de 15 minutes. Pour cette raison, nous souhaitons définir des paramètres pertinents (temps de réalisation de la tâche, complexité de la tâche, etc.) pour la bonne exécution d’une quelconque opération.

6.4.5.1 Analyses et Discussions

Nous avons pris en compte trois critères statistiques pour analyser ces expériences du point de vue de l’opérateur :

1. Temps de réalisation de la tâche ; 2. Variation de la force ;

Considérant ces trois critères statistiques, on peut constater qu’il n’est pas très facile de conclure sur l’aide apportée par le rendu haptique dans la téléopération du robot mobile. En effet, le temps d’exécution d’une mission n’est pas sensiblement meilleur avec ou sans rendu haptique, même en l’absence des retards de transmission. Le même constat est fait pour les forces rendues. Ceci peut être expliqué par le schéma de commande utilisé (vitesse-force utilisant la position du dispositif haptic en tant que consigne) considéré comme peu intuitif pour la plupart des utilisateurs. Par exemple, si l’opérateur fixe la position du dispositif, le robot mobile peut toujours avancer. En revanche, le troisième critère “variation de la commande”, montre une différence significative du comportement de l’utilisateur donnant un avantage clair pour l’utilisation du rendu d’effort.

Par ailleurs, nous avons demandé aux utilisateurs de donner leur sentiment sur les expérimentations (un protocole de questions très simple). Dans le cas où le robot mobile approche un mur, le rendu de force n’est pas jugé très utile puisque la vision (si elle est optimale) donne de bons résultats. Dans les autres situations, le retour haptique semble être très apprécié puisqu’il permet de percevoir des informations de l’environnement que l’on ne voir à travers le flux vidéo. Dans ces cas, les délais de transmission perturbent gradement les utilisateurs s’ils ne sont pas corrigées.

6.5 Application : Rendu haptique distribué

6.5.1 Problématique

Le sens haptique devient de plus en plus populaire dans les applications de réalité virtuelle suite à l’arrivée de dispositifs à retour d’effort variés, pas chers, compacts et faciles d’usage. Par le biais de ces dispositifs, les utilisateurs peuvent manipuler des ob-jets virtuels et coopérer avec d’autres opérateurs au sein d’un même environnement de synthèse. Relier les applications de RV par l’intermédiaire de réseaux de communication permet ainsi des collaborations à distance dans des domaines d’applications très variés :

– Prototypage virtuel

⋄ Ingénierie concourante

⋄ Montage/démontage d’éléments mécaniques

⋄ Télémaintenance industrielle

– Entraînement et perfectionnement du geste dans le domaine médical

⋄ Téléchirugie

⋄ Télé-échographie

⋄ Entraînement à l’accouchement (i.e. manipulation des Forceps)

⋄ Endoscopie

La collaboration haptique s’avère très utile pour le gain de temps (réalisation, étude, essais) ou plus généralement pour la réduction des coûts de développements et/ou d’ap-prentissage sur maquettes virtuelles, etc.

Par ailleurs et afin de garantir une stabilité optimale et une transparence acceptable, les simulations à retour kinesthésique nécessitent une bande passante relativement élevée, idéalement 1 kHz.

Dans ce cadre, je me suis intéressé à l’étude des interactions haptiques collaboratives en utilisant des techniques de réalité virtuelle (RV) et le développement de technologies permettant la transmission de données multi-sensorielles. Pour se faire, nous avons étu-dié ce que peut engendrer l’augmentation du déploiement de ce type d’applications. Le

premier défi à relever réside dans la question suivante : Comment peut-on fournir une connexion adéquate entre les applications haptiques distribuées sachant que les diverses données sensorielles (sonores, visuelles, tactile, kinesthésique, ...) ainsi que les commandes doivent être envoyées de manière synchrone au travers du média de transfert ? Si nous pre-nons l’exemple d’Internet, il constitue un moyen très adapté pour "relier" l’ensemble des sites distants du fait de sa popularité et de sa rentabilité. Même si les actuels protocoles de communication (i.e. TCP/IP) sont les plus utilisés, ils ne sont pas conçus pour des applications temps réel et par conséquent les transferts de données souffrent de retards, de pertes d’informations et de congestions imprévisibles de réseaux, etc.

Nous avons donc posé la problématique qui est celle de l’économie et de la gestion "op-timale" des ressources disponibles une application distribuée. Cette problématique s’arti-culera autour de deux axes principaux :

– Etude de la fidélité du rendu haptique : l’objectif de cet axe est de permettre une meilleure définition du retour haptique pour que ce dernier soit ;

⋄ Significatif : avoir une cohérence entre les informations vues et ressenties ;

⋄ Utilisable : proposer des schémas de commande suffisamment stables, quelques soient les informations sensorielles rendues. Une même scène peut en effet trans-mettre des informations visuelles, de température, de texture ou d’effort ayant des spécificités matérielles (hétérogénéité des interfaces) ou sensorielles (bandes passantes différentes).

– Architecture logicielle de collaboration

⋄ L’objectif de cet axe est d’étudier l’organisation logicielle des communications ainsi que de proposer des architectures adaptées à la problématique posée. Le défi le plus important réside dans la gestion des ressources disponibles aux niveaux des postes-opérateurs [83].

La plate-forme que nous voulons développer se voulait générique et pouvant être partagée. Nous avons donc développé des outils tels que l’enveloppe de latence qui aide à la création d’un serveur intelligent et la sphère de proximité dont le rôle principal sera l’économie de la ressource en local, résultats publiés dans [14].

Dans la suite, j’aborderai la démarche que j’ai entreprise et les approches développées.

6.5.2 Etat de l’art

Dans la littérature, on retrouve de multiples simulations haptique partageant des en-vironnements virtuels entre plusieurs opérateurs, généralement, au sein d’un réseau local. Ce dernier type de liaison induit un retard de communication très faible n’affectant pas la stabilité de la simulation. Le principal but de ces recherches est de quantifier l’impact des caractéristiques des lignes de transmission ou l’impact des délais sur la cohérence visio-haptique. Des études ont montrés qu’à partir d’un certain seuil (40 ms), le retard affecte la perception de l’utilisateur [124].

Par ailleurs, des chercheurs ont exploré l’apport du rendu haptique dans une simula-tion qui améliore sensiblement les performances de la tâche à accomplir et augmente la présence de l’opérateur au sein des environnements synthétiques. Les résultats sont posi-tifs et attestent de l’importance du rendu haptique dans les environnements collaboraposi-tifs [125].

Un autre groupe de chercheurs se sont intéressés à l’architecture de communication en introduisant les problèmes dus à une telle technologie, à savoir le délai qui affecte

la stabilité de la simulation. Ils ont exploré plusieurs scénarios d’environnement virtuel distribué : statique où les clients ne peuvent pas modifier l’environnement virtuel, mais seulement une personne à la fois, où les clients font une tâche l’un après l’autre comme dans un jeu de tennis par exemple et enfin collaboratif simultané où les clients peuvent simultanément exercer une tâche donnée, comme le déplacement d’un objet. Le dernier scénario a posé de nombreuses contraintes techniques ce qui a conduit à plusieurs travaux de recherches encore naissants [126, 82]. D’autres nouvelles pistes basées sur l’améliora-tion de l’infrastructure et la Qualité de service “QoS” ont vu récemment le jour. Pour plus de détails, le lecteur peut se référer à mes deux chapitres de livres, [11, 13].

Figure 6.30 – Organigramme de la plate-forme de simulation.

6.5.3 Présentation de la plate-forme de simulation

Une plate-forme de simulation a été développée, durant le stage de M. Karim Tourbah (étudiant en DEA RVMSC), en langage C++ sur le framework .NET. Elle s’articule sur trois grands axes :

a) la simulation dynamique des objets virtuels : Cette partie est composée de trois prin-cipaux modules :

– Le moteur dynamique ou physique : faisant appel aux principes de la dynamique connus pour animer de manière intuitive et rapide la scène virtuelle figure 6.31. Il met en place un environnement virtuel, créé les objets virtuels et s’occupe du

comportement dynamique des objets qui évoluent au sein de cet environnement. Il a en charge aussi la détection de collisions entre les objets et la résolution du contact (notamment le renvoi de la force à l’opérateur). Par souci de réduction de temps et aussi la simplicité de mise en œuvre, les librairies ODE³ (Open Dynamics Engine) ont été sélectionnées pour l’implantation du moteur dynamique. Elles sont disponibles librement sur le site http ://www.ode.org/.

– L’interface graphique est l’organe visuel de la simulation haptique. Elle affiche les objets créés par le moteur dynamique et s’occupe du rafraîchissement graphique de la scène virtuelle. La librairie "OpenGL" a été utilisée pour mettre en place cette interface graphique. Cette partie est scindée en deux principales parties :

⋄ L’interface Client/Serveur est un protocole de communication et de transfert de données de et vers la simulation. Il représente l’architecture réseau du système et prend en charge la gestion des nouveaux clients ou collaborateurs. Il est aussi le "centre de commandement" du serveur intelligent.

⋄ Le module XML. Ce langage a été choisi pour le format des informations trans-mises entre les différentes machines clientes du système. L’objectif initial de XML était de faciliter le partage de textes et d’informations structurés, par exemple au travers de l’Internet, en séparant le contenu (les données) du contenant (la présen-tation des données). Il a été établi avec l’intention d’être un format compréhensible par l’homme et la machine. Par exemple, le serveur enverra ainsi à tous les clients, un fichier unique duquel chaque client pourra extraire les informations le concer-nant qu’il trouvera sous la balise donconcer-nant son identité unique. De plus, il pourra, avec un même fichier, se renseigner sur la situation des autres clients.

– L’interface mécatronique : son rôle a été abordé précédemment. b) l’architecture de réseau de communication ;

c) l’automatique du rendu haptique.

Chacun de ces trois axes se divise en plusieurs modules indépendants comme illustré par la figure 6.30.

6.5.4 Architecture de communication et gestion de ressources

6.5.4.1 Serveur Intelligent

Une architecture de réseau adaptée doit être choisie de façon à mieux gérer les res-sources disponibles lors de la simulation dynamique. Plusieurs cas de figures se pré-sentent à nous dans le cadre de cette architecture réseau pour une simulation haptique collaborative distante. Nous avons investigué plusieurs architectures faisant appel au pro-tocole client/serveur où les deux "postes" jouent un rôle plus ou moins important, à sa-voir :

1. Client/Serveur où le serveur joue le rôle d’un centre de calcul et donne les priorités ;

3. ODE est un ensemble de sources "open librairies" très performant pour simuler la dynamique des objets virtuels rigides. Elles sont indépendantes des différentes plates-formes utilisées et intègrent une API (Application Program Interface) en C/C++, ensemble d’outils utile à la conception des programmes sous C/C++. Ces librairies comportent des systèmes de détections de collisions avec ou sans frottement. A chaque pas de temps, les objets en collision sont détectés et les points de contacts renvoyés à l’utilisateur. Un algo-rithme personnalisé de détection de collisions peut être implémenté tant que les sorties sont conformes aux spécifications de ODE. ODE est utilisée dans la simulation de véhicules, d’objets ou de créatures virtuelles dans des environnements de synthèse.

Figure 6.31 – Environnement de la plate-forme de simulation.

2. Client/Serveur avec un maximum de traitement qui se fait au niveau du client ; 3. Client/Client : architecture point à point (P2P). Chaque poste peut être considéré

comme client et/ou serveur.

4. Client/Serveur : une architecture mixte où le rôle du serveur pouvant éventuelle-ment être joué par un client si besoin est.

Cette dernière mise en œuvre a été choisie du fait de sa capacité à surmonter les dégradations de performances (manque de ressources) de l’un ou l’autre.

Dans cette architecture, le moteur dynamique est présent au niveau des clients et du serveur où ce dernier gère les ressources disponible. Il constitue, au même temps, un médiateur entre les clients, ayant pour tâche, entre autres, d’optimiser au maximum la communication entre les clients, quelque soit la situation. Le serveur renseigne notamment les clients des mises à jour des états des différents clients et décide des ressources à allouer à chaque poste distant.

Ce type de scénario peut sembler idéal à condition de se doter d’un serveur capable de gérer et d’optimiser au mieux les ressources présentes. Pour cela, plusieurs outils ont été développés afin d’aider le serveur ayant une meilleure connaissance de la scène virtuelle et ainsi prendre les meilleures décisions possibles.

6.5.5 Architecture Techniques basées sur le principe de l’enveloppe englobante

6.5.5.1 Gestion des ressources informatiques

Dans une scène virtuelle où plusieurs opérateurs clients coopèrent, deux cas distincts de délais peuvent apparaître : (1) le délai de communication et (2) le délai dû au traitement propre de l’information (animation graphique, etc.). Dans le premier cas, les problèmes causés sont la stabilité et la fidélité du rendu visio-haptique. Des approches de commande classique sont un "remède" efficace pour surmonter ces difficultés. Pour le deuxième cas, les problèmes qui en découlent sont liés au "gaspillage" des ressources disponibles. Un client pourrait avoir beaucoup de ressources et n’en utiliser que peu alors qu’un autre

Figure 6.32 – L’architecture Client/Serveur mixte.

pourrait avoir moins de ressources qu’il n’en a besoin. Ceci pourrait engendrer des ralen-tissements au niveau local, risquant de compromettre le bon déroulement de la simula-tion. Le serveur doit être capable à distinguer ces dégradations et décider, en conséquence, d’apporter plus de ressources au client qui "pêche !"

L’enveloppe englobante est un outil pouvant renseigner le serveur sur les ressources disponibles chez un client.

6.5.5.2 Propriétés de l’enveloppe englobante

La taille de l’enveloppe de l’objet virtuel dépend principalement du délai de commu-nication entre les différents clients et le serveur. D’autres paramètres sont à prendre en compte tels que la nature du lien entre le serveur et le client, la nature du réseau utilisé, la position, la vitesse et la direction de l’enveloppe, figures 6.33 et 6.34. Dans ces cas de figure, l’enveloppe sert d’indicateur de nature/qualité de la communication entre le ser-veur et un utilisateur particulier. En d’autres termes, le système d’interaction a, à chaque instant, des informations sur le délai que pourrait mettre une commande à être traitées par le système, [14].

La taille de l’enveloppe pourra être calculée à partir de la relation empirique suivante : Taille de l’enveloppe=Délaix(1+vitesse de l’objet client)/K (6.39)

K étant un coefficient positif, à synthétiser en fonction des paramètres physiques de la

simulation. Ainsi, si le délai est nul, l’enveloppe est nulle et si la vitesse de l’objet est nulle, la taille de l’enveloppe est égale au délai total. En effet, si la vitesse est nulle, cela signifie que l’objet client est immobile et ainsi si un autre objet vient interagir avec ce dernier, l’objet client est tout de même soumis au délai de traitement de l’information. Mais, si le délai est nul alors l’enveloppe n’a plus lieu d’être puisque l’information est traitée instantanément par le client. Par conséquent, le serveur entreprend les actions suivantes, à savoir :

– Partage de Ressources entre client/serveur et entre client/client. Fusion de plusieurs objets pour en former virtuellement un seul (si contact il y a entre les trois compo-santes).

Figure 6.33 – Un client et un objet statique dans une même scène virtuelle sans contact.

– Prédiction du mouvement pour le rendu haptique basé sur la vitesse et l’accélération des objets manipulés ainsi que sur le retard de communication.

– Système de priorités, le client avec la plus grande enveloppe a besoin de plus de temps pour le traitement de l’information à cause d’une communication trop lente ou à cause de ressources peu suffisantes sur sa machine locale. Dans ce cas là, le serveur peut donner la priorité au client qui mettra le plus de temps à traiter l’in-formation.

6.5.5.3 Description du fonctionnement avec l’enveloppe et présentation de cas typiques

Seuls les objets clients ont, par défaut, une enveloppe de tailles variables suivant les critères expliqués précédemment. Les objets statiques n’ont jamais d’enveloppe et les ob-jets dynamiques prennent la plus grande enveloppe du client avec qui ils interagissent.