Otmane00

Télétravail Robotisé et Réalité Augmentée : Application
à la Téléopération via Internet

Samir Otmane
To cite this version:

Samir Otmane. Télétravail Robotisé et Réalité Augmentée : Application à la Téléopération via Inter-
net. Traitement du signal et de l’image [eess.SP]. Université d’Evry-Val d’Essonne, 2000. Français.
�NNT : �. �tel-00682240�
HAL Id: tel-00682240

https://theses.hal.science/tel-00682240
Submitted on 26 Mar 2012
HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
N˚ d’identification : 00EVRY0017
UNIVERSITE D’EVRY-VAL D’ESSONNE

CEMIF : Centre d’Etude de Mécanique d’Ile de France.
Laboratoire Systèmes Complexes du CEMIF
THÈSE
pour l’obtention du titre de
Docteur de l’Université d’Evry-Val d’Essonne
Spécialité :
SCIENCES DE L’INGENIEUR
Télétravail Robotisé et Réalité Augmentée :

Application à la Téléopération via Internet
Samir OTMANE
Soutenance le : 13 décembre 2000
JURY
M. P. Coiffet : Directeur de Recherches au CNRS, Rapporteur

M. P. Fuchs : MA, HDR, ENSMP Paris, Rapporteur
M. M. Soto : MCF, HDR, Université de Paris VI, Rapporteur
M. N. Agoulmine : Professeur, Université d’Evry, Rapporteur
M. F. Chavand : Professeur, Université d’Evry, Examinateur
M. A. Kheddar : MCF, Université d’Evry , Examinateur
M. P. Even : MCF, Université de Versailles, Examinateur
M. M. Mallem : Professeur, Université d’Evry, Directeur de Thèse
Remerciements
Qu’il me soit permis de remercier ici Messieurs :

– Philippe COIFET, Directeur de recherches au CNRS,
– Philippe FUCHS, Maı̂tre-assistant (HDR) à l’Ecole des Mines de Paris,
– Michel SOTO, Maı̂tre de Conférences (HDR) à l’Université Pierre et Marie Curie,
– Nazim AGOULMINE, Professeur à l’Université d’Evry Val d’Essonne
pour l’attention qu’ils ont portée à mon travail par la lecture de ce mémoire et
témoignant ainsi de leurs intérêts pour ce domaine de recherche ; soyez remerciés d’avoir
accepté de rapporter cette thèse dans les meilleurs délais.
Je remercie vivement monsieur Florent CHAVAND, Professeur à l’Université d’Evry

Val d’Essonne, pour m’avoir accueilli au sein du Laboratoire CEMIF Systèmes Complexes
et m’avoir ainsi donné les moyens de mener à bien ce travail de recherche ; veuillez accep-
ter toute ma reconnaissance.
Mes sincères remerciements vont à monsieur Malik MALLEM, Professeur à l’Univer-

sité d’Evry Val d’Essonne, en tant que directeur de thèse, vous avez accueilli et suivi avec
intérêt mon sujet de recherche ; pour votre disponibilité, votre ouverture d’esprit, vos cri-
tiques constructives et vos suggestions clairvoyantes ; je suis heureux de l’opportunité qui
m’est donnée de vous témoigner ma reconnaissance pour cet enseignement tout au long
de cette thèse.
Que monsieur Philippe EVEN, Maı̂tre de Conférences à l’Université de Versailles, soit

remercié pour l’intérêt qu’il porte à ce travail en examinant ce mémoire.
Je remercie également monsieur Abderahmane KHEDDAR, Maı̂tre de Conférences
à l’Université d’Evry Val d’Essonne, pour ses conseils, ses critiques constructives et sa
collaboration.
Je remercie également toutes les personnes qui ont pris part à l’établissement des
données :
– A Monsieur Dave LAVERY, le webmaster du site de la NASA et son équipe qui ont
testé le système ARITI et accepté de le rajouter sur leur site web.
– Aux trente sujets novices (étudiants IUP, stagiaires et thésards) qui ont accepté de
se prêter aux différentes expériences, je suis redevable du temps qu’ils ont bien voulu
me consacrer.
– Aux sujets télé-présents du monde entier qui ont utilisé notre système et téléopéré
notre robot.
Je tiens tout particulièrement à remercier Messieurs Nicolas BRODU, Stéphane MA-
VEL, Sylvain LENESTOUR, Jean François VINCENT et Anthony JOBIN de l’Institut
REMERCIEMENTS
d’Informatique d’Entreprise (IIE-CNAM) lors de leur stage au CEMIF, pour leurs contri-
butions à cette thèse.
Mes salutations vont à Etienne COLLE, Hichem MAAREF, Philippe HOPPENOT,

Jean TRIBOULET, Christian BARRAT pour leur soutien.
A Frédéric DAVESNE et à tous les thèsards du Laboratoire Systèmes Complexes, pour

l’ambiance de travail qu’ils ont su créer et je leur souhaite bonne continuation et un avenir
prospère.
Mes reconnaissances vont aux secrétaires Murielle BOURGOIS, Sylviane RAT et au

technicien Richard PESCARI pour leur gentillesse et leurs services rendus.
Enfin, que toute ma famille, trouve ici le témoignage de ma reconnaissance pour leurs
encouragements et leur soutien.
Science sans conscience n’est

que ruine de l’âme.
Rabelais 1532
Table des matières
Remerciements
Table des matières
Introduction 1
1 Le Télétravail : Etat de l’art 5

1.1 Bref historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Les tendances technologiques pour le télétravail et le travail coopératif . . 7
1.2.1 Les tendances technologiques . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Le travail coopératif . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.3 Les Interfaces Homme-Machine avancées . . . . . . . . . . . . . . 9
1.3 Télétravail : Téléopération et Télérobotique . . . . . . . . . . . . . . . . 10
1.3.1 La Téléopération . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.1.1 Le problème de délai de transmission . . . . . . . . . . . 11
1.3.1.2 Evolution des systèmes de téléopération . . . . . . . . . 12
1.3.2 La Télérobotique . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2.1 Quelques domaines d’application . . . . . . . . . . . . . 14
1.3.3 La réalité virtuelle et la réalité augmentée : Outils indispensables
pour le télétravail . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3.3.1 La réalité virtuelle : Bref Etat de l’art . . . . . . . . . . 16
1.3.3.2 Quelques domaines d’application de la RV . . . . . . . . 19
1.3.3.3 La réalité augmentée : . . . . . . . . . . . . . . . . . . . 20
1.3.3.4 Quelques domaines d’application de la RA . . . . . . . . 21
1.3.3.5 Quelques exemples de systèmes de téléopération utilisant
la RV et/ou la RA . . . . . . . . . . . . . . . . . . . . . 23
1.4 Internet et les environnements télérobotiques : Bref état de l’art . . . . . 25
1.4.1 Australia’s Telerobot on the Web . . . . . . . . . . . . . . . . . . 26
1.4.2 Mercury Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4.3 KhepOnTheWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4.4 Xavier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
TABLE DES MATIERES
1.4.5 RHINO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4.6 PumaPaint project . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2 L’assistance graphique pour le Télétravail 31

2.1 Les métaphores graphiques : Bref état de l’art . . . . . . . . . . . . . . . 31
2.1.1 La métaphore des mécanismes virtuels . . . . . . . . . . . . . . . 32
2.1.2 La métaphore des guides virtuels . . . . . . . . . . . . . . . . . . 33
2.2 Les guides virtuels pour l’assistance au télétravail via Internet . . . . . . 39
2.2.1 Les méthodes de construction des guides virtuels . . . . . . . . . . 39
2.2.1.1 Les Coniques et les superconiques . . . . . . . . . . . . 40
2.2.1.2 Les superquadriques . . . . . . . . . . . . . . . . . . . . 42
2.2.1.3 Les B-Splines . . . . . . . . . . . . . . . . . . . . . . . . 44
2.2.2 Représentation et manipulation des guides virtuels sur écran . . . 46
2.2.2.1 Le modèle de la caméra graphique . . . . . . . . . . . . 47
2.2.2.2 Sélection d’un objet de l’espace sur l’écran . . . . . . . . 47
2.2.2.3 Détection des collisions . . . . . . . . . . . . . . . . . . . 50
2.3 Les propriétés des guides virtuels . . . . . . . . . . . . . . . . . . . . . . 54
2.3.1 La notion de guide virtuel simple et composé . . . . . . . . . . . . 55
2.3.1.1 Guide virtuel simple . . . . . . . . . . . . . . . . . . . . 55
2.3.1.2 Guide virtuel composé . . . . . . . . . . . . . . . . . . . 55
2.3.2 Notion de guide virtuel passif ou actif . . . . . . . . . . . . . . . 56
2.3.2.1 Guide virtuel passif . . . . . . . . . . . . . . . . . . . . . 56
2.3.2.2 Guide virtuel actif . . . . . . . . . . . . . . . . . . . . . 56
2.3.3 Formalisme proposé pour les guides virtuels . . . . . . . . . . . . 58
2.3.3.1 Structures de données proposées pour les guides virtuels 58
2.3.3.2 Les cas d’utilisation . . . . . . . . . . . . . . . . . . . . 60
2.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3 Le système expérimental de télétravail proposé 63

3.1 Caractéristiques d’un système de télétravail idéal . . . . . . . . . . . . . 64
3.2 Modèlisation géométrique d’environnement pour le contrôle en Réalitée
Augmentée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.1 Modélisation géométrique de la scène . . . . . . . . . . . . . . . . 64
3.2.1.1 Représentation filaire . . . . . . . . . . . . . . . . . . . 65
3.2.1.2 Représentations surfaciques . . . . . . . . . . . . . . . . 65
3.2.1.3 Représentations volumiques . . . . . . . . . . . . . . . . 65
3.2.1.4 La représentation choisie pour le télétravail via Internet 67
3.2.2 Modélisation et calibration de la caméra . . . . . . . . . . . . . . 68
3.2.2.1 Modèle interne de la caméra . . . . . . . . . . . . . . . 69
3.2.2.2 Modèle externe de la caméra . . . . . . . . . . . . . . . 70
TABLE DES MATIERES
3.2.2.3 Modèle global de la caméra . . . . . . . . . . . . . . . . 70

3.2.2.4 Modèle géométrique direct de la caméra (MGD) . . . . . 71
3.2.2.5 Modèle géométrique inverse de la caméra (MGI) . . . . . 71
3.2.2.6 Calibration de la caméra . . . . . . . . . . . . . . . . . . 72
3.2.3 Modélisation et calibration du robot . . . . . . . . . . . . . . . . 72
3.2.3.1 Modèle Géométrique Direct du robot (MGD) . . . . . . 74
3.2.3.2 Modèle Géométrique Inverse du robot (MGI) . . . . . . 74
3.2.3.3 Calibration de la tige du robot . . . . . . . . . . . . . . 75
3.3 Description du système ARITI . . . . . . . . . . . . . . . . . . . . . . . . 76
3.3.1 Description du materiel . . . . . . . . . . . . . . . . . . . . . . . . 76
3.3.2 Description du logiciel . . . . . . . . . . . . . . . . . . . . . . . . 77
3.3.2.1 Site distant (esclave) . . . . . . . . . . . . . . . . . . . 77
3.3.2.2 Site opérateur (maı̂tre) . . . . . . . . . . . . . . . . . . 77
3.3.3 Module de Réalité Mixée (RM) . . . . . . . . . . . . . . . . . . . 78
3.3.3.1 Les Données . . . . . . . . . . . . . . . . . . . . . . . . 79
3.3.3.2 Les fonctions d’assistance . . . . . . . . . . . . . . . . . 80
3.3.4 Module de Téléopération . . . . . . . . . . . . . . . . . . . . . . . 81
3.3.5 Module de Téléprogrammation . . . . . . . . . . . . . . . . . . . 82
3.3.6 Module de Télésupervision et Télécoopération . . . . . . . . . . . 84
3.3.6.1 Mission avec un seul opérateur . . . . . . . . . . . . . . 85
3.3.6.2 Mission avec quatre opérateurs en télécoopération . . . . 85
3.4 Architecture réseau du système ARITI . . . . . . . . . . . . . . . . . . . 86
3.4.1 Protocole de communication client/serveur image . . . . . . . . . 87
3.4.1.1 Demande d’une image vidéo . . . . . . . . . . . . . . . . 88
3.4.1.2 Schéma fonctionnel du serveur image . . . . . . . . . . . 88
3.4.2 Protocole de communication client/serveur commande . . . . . . 90
3.4.2.1 Protocole de connexion pour la commande du robot réel 90
3.4.2.2 Protocole de télésupervision . . . . . . . . . . . . . . . . 91
3.4.2.3 Schéma fonctionnel du serveur commande . . . . . . . . 91
3.4.3 Limites et Sécurité du protocole . . . . . . . . . . . . . . . . . . . 93
3.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4 Applications 95
4.1 Télétravail avec un robot à 4 ddl . . . . . . . . . . . . . . . . . . . . . . 95
4.1.1 Description du site esclave . . . . . . . . . . . . . . . . . . . . . . 95
4.1.2 Description du site client . . . . . . . . . . . . . . . . . . . . . . . 97
4.1.2.1 IHM administrateur . . . . . . . . . . . . . . . . . . . . 97
4.1.2.2 IHM utilisateur . . . . . . . . . . . . . . . . . . . . . . . 100
4.1.2.3 Description de l’outil de création et de manipulation des
guides virtuels . . . . . . . . . . . . . . . . . . . . . . . 100
4.1.3 Mode Téléopération . . . . . . . . . . . . . . . . . . . . . . . . . 102
TABLE DES MATIERES
4.1.3.1 Tâche d’atteinte de cible . . . . . . . . . . . . . . . . . . 103

4.1.3.2 Tâche de suivi de cible mobile . . . . . . . . . . . . . . . 105
4.1.3.3 Tâche de suivi de contour d’un objet . . . . . . . . . . . 106
4.1.3.4 Tâche de saisie et dépôt d’un objet . . . . . . . . . . . . 108
4.1.4 Mode Téléprogrammation de tâches . . . . . . . . . . . . . . . . . 112
4.1.5 Mode Télésupervision et Télécoopération . . . . . . . . . . . . . . 113
4.2 Télétravail avec un robot mobile . . . . . . . . . . . . . . . . . . . . . . . 114
4.2.1 Description des robots mobiles . . . . . . . . . . . . . . . . . . . . 115
4.2.2 Description de l’IHM . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.2.3 Guides virtuels pour traverser une porte . . . . . . . . . . . . . . 116
4.2.3.1 Tâche avec deux plans répulsifs . . . . . . . . . . . . . . 117
4.2.3.2 Tâche avec une courbe B-Spline attractive . . . . . . . . 117
4.3 Autres applications potentielles . . . . . . . . . . . . . . . . . . . . . . . 119
4.3.1 Nucléaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.3.2 Médical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.3.3 Enseignement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5 Evaluation et Expérimentation 123

5.1 Evaluation des performances des tâches avec l’interface de ARITI . . . . 124
5.1.1 Conditions expérimentales . . . . . . . . . . . . . . . . . . . . . . 124
5.1.2 Atteinte d’une cible . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.1.2.1 Tests sans guide virtuel . . . . . . . . . . . . . . . . . . 126
5.1.2.2 Tests avec guide virtuel répulsif . . . . . . . . . . . . . . 129
5.1.2.3 Tests avec guide virtuel attractif . . . . . . . . . . . . . 130
5.1.3 Saisie et dépôt d’un objet . . . . . . . . . . . . . . . . . . . . . . 131
5.1.3.1 Saisie du cylindre numéro 1 . . . . . . . . . . . . . . . . 131
5.1.3.2 Dépôt du cylindre numéro 1 sur le support numéro 3 . . 132
5.2 Evaluation des algorithmes de compression d’images vidéo . . . . . . . . 134
5.2.1 Conditions expérimentales . . . . . . . . . . . . . . . . . . . . . . 134
5.2.1.1 Evaluation des taux de compression d’image . . . . . . . 135
5.2.1.2 Evaluation des temps de compression d’image . . . . . . 135
5.3 Evaluation des performances de l’architecture client/serveur de ARITI . . 137
5.3.1 Connexion avec un seul opérateur . . . . . . . . . . . . . . . . . . 139
5.3.1.1 Connexion locale . . . . . . . . . . . . . . . . . . . . . . 139
5.3.1.2 Connexion moyenne distance . . . . . . . . . . . . . . . 141
5.3.1.3 Connexion longue distance . . . . . . . . . . . . . . . . . 143
5.3.2 Connexion avec plusieurs opérateurs avec retour prédictif distribué 145
5.3.2.1 Connexion locale . . . . . . . . . . . . . . . . . . . . . . 145
5.3.2.2 Connexion moyenne et longue distance . . . . . . . . . . 148
5.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
TABLE DES MATIERES
Conclusions 151
Bibliographie 159
Table des figures
Liste des tableaux
Annexes i
A Les méthodes de compression Gzip et Huffman . . . . . . . . . . . . . . . i
A.1 Codage de Huffman . . . . . . . . . . . . . . . . . . . . . . . . . . i
A.1.1 Avantage de la compression d’Huffman . . . . . . . . . . ii
A.1.2 Exemple de compression . . . . . . . . . . . . . . . . . . ii
A.2 Codage de Gzip . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
A.2.1 Avantage de la compression GZip . . . . . . . . . . . . . iii
B Schémas de fonctionnement des tâches de téléprogrammation . . . . . . . v
B.1 Atteindre un point cible . . . . . . . . . . . . . . . . . . . . . . . v
B.2 Atteindre une cible mobile . . . . . . . . . . . . . . . . . . . . . . v
B.3 Suivre le contour du cylindre 1 . . . . . . . . . . . . . . . . . . . v
B.4 Prendre/déposer un objet . . . . . . . . . . . . . . . . . . . . . . v
B.5 Tour de Hanoı̈ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
C Les sites clients ayant utilisé ARITI . . . . . . . . . . . . . . . . . . . . . ix
C.1 En Europe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
C.2 Dans le monde . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
D Les différents systèmes utilisant Internet comme moyen de contrôle . . . xiii
TABLE DES MATIERES
Introduction
Amorcée dans les années 1970, l’informatisation professionnelle a récemment élargi son
empire du poste de travail isolé à la prise en charge des tâches communicant par réseau.
Les instruments de communication asynchrones tels que les messageries, le transfert de
fichiers, les forums de discussions ou les serveurs de données ont aujourd’hui conquis une
place de plus en plus importante dans les organisations. Cependant, la diffusion de ces ou-
tils reste pour l’heure très inégale et l’appréciation de leurs effets sociaux et économiques
est sujette à controverse.
L’architecture des futures organisations “virtuelles” reposerait toute entière sur un

réseau de machines à coopérer dotées du pouvoir d’abolir les distances et de faire naı̂tre
entre ses membres une connectivité généralisée. Ces outils de communication, promettent
aussi de créer un espace de travail commun permettant de partager des applications,
d’échanger des documents animés ou sonores, d’écrire sur un même texte, d’élaborer un
diagnostic médical sur un même cliché, et de faire circuler dans les réseaux des conférences,
des cours ou des diagnostics, etc.
Enfin la perspective d’une mise à disposition de tels outils sur des réseaux non nécessair-
ement professionnels (via la téléphonie large bande ou le réseau internet) ouvre des pers-
pectives d’usages d’applications coopératives.
La téléprésence, ou la présence virtuelle, qui devient de plus en plus courante grâce à

l’évolution technologique, implique une ouverture du potentiel du télétravail. En effet, on
peut imaginer que certaines actions pourront un jour être effectuées à distance, comme par
exemple des opérations chirurgicales accomplies par l’intermédiaire d’un robot piloté par le
chirurgien se trouvant loin du patient. On voit que le potentiel du télétravail est fortement
lié à la virtualité et à la téléprésence, donc aussi à la robotique et à l’informatique, autant
qu’aux communications.
Cette thèse propose donc la l’étude et la réalisation d’un système permettant le
télétravail via Internet.
Le chapitre 1 est dédié à une analyse bibliographique sur le télétravail et une synthèse
des problématiques auxquelles nous nous attacherons dans cette thèse. En effet, nous
présentons au début de ce chapitre, un petit historique qui résume les origines du télétravail
et comment cette nouvelle forme de travail est perçue dans le monde. Dans la seconde
partie, nous présentons quelques tendances technologiques qui ont contribué à l’évolution
du télétravail et du travail coopératif, en décrivant les principes et les concepts des nou-
velles générations d’interfaces homme-machine avancées. Dans la troisième partie, nous
présentons une autre forme de télétravail, celle liée au contrôle à distance de systèmes
robotisés, nous parlerons alors de la télérobotique et de la téléopération et nous verrons
comment les techniques de la réalité virtuelle et augmentée ont contribué à percer certains
INTRODUCTION
verrous liés généralement à la distance qui sépare l’opérateur du robot à contrôler. Dans la
quatrième partie, nous présentons brièvement quelques systèmes robotiques qui utilisent
Internet comme moyen de communication et nous présentons aussi les performances et
les limites de ces sytèmes. Nous terminons ce chapitre, par un bilan à partir duquel nous
dégagerons quelques problématiques, essentiellement pour la téléopération de robots sur
Internet.
Dans le chapitre 2 nous présentons quelques solutions apportées aux problèmes d’assis-
tance à l’opérateur pour le télétravail, en particulier d’assistance graphique à la téléopérati-
on d’un robot. En effet, dans la première partie, nous présentons un bref état de l’art sur
les métaphores graphiques. Nous verrons comment elles sont utilisées suivant les auteurs
et suivant les champs d’application, bien qu’elles soient issues d’une même technologie, à
savoir la réalité virtuelle. Dans la seconde partie, nous présentons les différentes méthodes,
géométriques et analytiques utilisées pour la construction, la représentation et la mani-
pulation des objets virtuels en général. D’autre part, nous verrons comment ces objets
virtuels sont transformés en de véritables outils d’assistance pour la téléopération. Afin
de rendre ces outils facilement configurables par un opérateur, un formalisme est proposé
et implanté. La structure générale de ce formalisme est représentée à la fin de ce chapitre.
Le chapitre 3 présente une étude à la mise en œuvre d’un système de télétravail. Nous
présentons les outils logiciels et matériels nécessaires à la réalisation d’un système de
télétravail, comment intégrer les nouveaux concepts et les solutions déjà apportées aux
problèmes liés à la télérobotique, sur une plate-forme universelle et à moindre coût. Nous
verrons, comment rendre l’utilisation des systèmes de télétravail suffisamment souple et
intuitive pour l’opérateur, comment les outils d’assistance présentés dans le chapitre 2
peuvent être utilisés pour améliorer les performances de l’opérateur lors du télétravail.
Dans la première partie de ce chapitre, nous présentons les caractéristiques d’un système
de télétravail idéal. Ensuite, nous présentons les méthodes nécessaires pour le contrôle en
réalité augmentée. Il s’agit des méthodes de modélisation géométrique de l’environnement,
de calibration de la caméra et du robot. Dans la troisième partie, nous présentons notre
système expérimental de télétravail, baptisé ARITI “Augmented Reality Interface for tele-
robotic applications via Internet”. Il s’agit d’un système de télétravail dont la conception
et la mise en œuvre sont basées d’un côté sur des techniques de la réalité virtuelle et
augmentée et de l’autre coté sur l’exploitation des techniques de développement réseaux
et en particulier sur Internet. Dans la quatrième partie, nous présentons l’architecture
réseau et les différents protocoles de communication de l’architecture client/serveur du
système ARITI.
Le chapitre 4 présente deux applications réalisées, une de télémanipulation et l’autre

de téléopération d’un robot mobile. Nous présentons aussi quelques applications poten-
tielles pouvant bénéficier du système de télétravail décrit dans le chapitre 3.
La première partie de ce chapitre, présente une application réalisée avec un banc d’essai à
4 degrés de libertés transformé en robot téléopérable via Internet grâce au système ARITI.
Nous décrirons les tâches réalisées suivant les différents modes de télétravail ainsi que les
guides virtuels que nous avons utilisé pour réaliser quelques tâches en téléopération. Nous
présentons ensuite, l’interface homme-machine pour cette application ainsi que le mode-
leur 3D que nous avons réalisé pour créer et manipuler ces guides virtuels. La seconde
partie, présente une application d’un projet en cours de réalisation pour l’assistance aux
2
INTRODUCTION
personnes handicapées (un projet en collaboration avec l’Association Française contre la

Myopathie (AFM)) utilisant un robot mobile. Dans la troisième partie de ce chapitre, nous
présentons d’autres domaines d’applications où l’utilisation d’un tel système de télétravail
peut être intéressante.
Le chapitre 5 présente les différentes expérimentations réalisées avec le système ARITI

utilisant un robot esclave à 4 ddl. Dans la première partie, nous évaluons les performances
de certaines tâches avec le mode de téléopération en utilisant l’interface de ARITI ; Pour
cela, plusieurs opérateurs humains ont participé aux expérimentations. Il s’agit de réaliser
des missions de téléopération d’une part, sans assistance de guides virtuels et d’autre part,
avec assistance de guides virtuels répulsifs ou attractifs.
Dans la seconde partie, nous évaluons les différents algorithmes de compression d’images
vidéo. Il s’agit d’étudier d’une part, les taux de compression fournis par les différentes
méthodes de compression d’images et les temps de compression d’images pour chaque
méthode utilisée. Ces évaluations vont nous permettre de déterminer un algorithme de
compression implanté dans le serveur d’images permettant ainsi de choisir automatique-
ment la méthode à utiliser suivant la dynamique des images. Dans la troisième partie, Nous
étudions le comportement du système et les performances de l’architecture client/serveur
du système ARITI à la fois, en fonction de la distance séparant le site maı̂tre (client)
du site esclave et en fonction du nombre d’opérateurs utilisant simultanément le système
pour un travail coopératif avec un retour prédictif distribué.
3
INTRODUCTION
4
Chapitre 1
Le Télétravail : Etat de l’art
Souvent considéré comme une conséquence du progrès technique, le télétravail n’est

pas si nouveau qu’on voudrait nous le faire croire. Au 18ème siècle, dans la période pré-
industrielle, les travaux manufacturés se faisaient à domicile. A l’époque, les échanges avec
l’entrepreneur obligeaient ce dernier à parcourir les foyers pour distribuer les matériaux
et récupérer l’ouvrage terminé. C’est l’industrialisation qui, au 19e siècle a nécessité des
moyens de productions capitalistique. Il a alors fallu regrouper les travailleurs dans un
lieu de production centralisé et unique, appelé alors “usine”.
Les technologies de l’information ont simplement permis d’un côté, pour les activités
du tertiaire de ne plus concentrer la production du service dans un lieu unique. D’un
autre côté, ces technologies ont permis de dispenser la présence de l’homme dans des
milieux dangereux (milieu nucléaire, haute température, etc.) ou tout simplement pour
des missions d’exploration (milieu spatial etc.).
Nous commençons ce chapitre par un petit historique qui rappel les origines du
télétravail et comment cette nouvelle forme de travail est perçue dans le monde, comme
porteuse d’espoir pour certains et spectre effrayant pour d’autres. Dans la deuxième sec-
tion, nous présentons quelques tendances technologiques qui ont contribué considérableme-
nt à l’évolution du télétravail et du travail coopératif. Nous décrivons ensuite, les prin-
cipes et les concepts des nouvelles générations d’interfaces homme-machine avancées.
Dans la troisième section, nous présentons une autre forme de télétravail, celle liée au
contrôle à distance de systèmes robotisés, nous parlerons alors de la télérobotique et de
la téléopération et nous verrons comment les techniques de la réalité virtuelle et aug-
mentée ont contribué à percer certains verrous liés généralement à la distance qui sépare
l’opérateur du robot à contrôler. Dans la quatrième section, nous présentons brièvement
quelques systèmes robotiques qui utilisent Internet comme moyen de communication et
nous présentons aussi les performances et les limites de ces systèmes. Nous concluons ce
chapitre, par un bilan dans lequel nous dégagerons quelques problématiques, essentielle-
ment pour la téléopération de robots sur Internet.
5
CHAPITRE 1. LE TELETRAVAIL : ETAT DE L ART
1.1 Bref historique

Durant les crises pétrolières des années 1970, le concept de déplacer le travail plutôt
que le travailleur qui consomme de l’essence avait commencé à séduire. Mais il a fallu
du temps pour que l’idée prenne forme, car certains facteurs devaient être en place pour
qu’elle puisse réussir (existence de technologies bon marché et fiables, réduction des coûts
des télécommunications, etc.). De l’autre côté, une autre forme de travail à distance est
apparue en 1971, lorsque l’Union Soviétique a réussi à commander à distance un robot
mobile sur la Lune (cette forme de télétravail est appelée “téléopération” voir la section
1.3).
La période de crise, entre la fin des années 80 et le début des années 90, n’a guère aidé
l’évolution du télétravail. Aux Etats-Unis comme au Royaume-Uni, des prédictions ambi-
tieuses avaient été avancées très tôt sur le potentiel du télétravail, prédictions qui se sont
avérées erronées. Par exemple, en 1985, le “Institute for the future” de Palo Alto avait
prédit que 40% (Béréziat et al., 2000) des employés américains seraient des télétravailleurs
en l’an 2000.
Le rapport Telefutures1 de 1996 résume l’histoire : “Malgré un démarrage assez lent,
l’Union Européenne (UE) a placé, en 1994, l’adoption du télétravail au sommet de la
liste d’actions du rapport Bangemann pour rendre l’Europe plus compétitive.” L’UE s’est
même donnée comme objectif d’atteindre les 10 millions de télétravailleurs en Europe pour
l’an 2000. Le rapport Telework 99 de la Commission Européenne présente deux chiffres
de sources différentes qui estiment le nombre de télétravailleurs en Europe entre 6 et 9
millions à ce jour.
Des études récentes suggèrent que vue les nombreux changements induits par la “société de
l’information”, l’Amérique du Nord a pris une longueur d’avance sur l’Europe et connaı̂t
aujourd’hui une évolution rapide du nombre de ses télétravailleurs. Jack Nilles2 (Nilles,
1998) pense qu’il y avait peut être 2000 télétravailleurs en 1970, qui seraient passés à une
centaine de milliers en 1980, bien qu’il reconnaisse qu’aucune enquête adéquate n’était
faite à l’époque. Ses estimations pour 1990 étaient de 2.4 millions. En 1994 elles s’élevaient
à 7.8 millions et 12.7 millions pour 1996. Nilles prédit que ce chiffre doublera presque pour
atteindre 24.7 million en l’an 2000.
Cependant, le télétravail continue à se développer très rapidement en Europe, bien qu’il

y a dix ans, le télétravail était une façon particulière de travailler, concernant seulement
une élite technologique. Mais il s’est depuis transformé en une forme d’organisation du
travail de plus en plus banale dans certains Etats-membres et/ou secteurs économiques
importants. En 1999, il y a suivant les études (Béréziat et al., 2000), de 6.5 à 9 mil-
lions d’Européens engagés dans ces nouvelles pratiques de travail impliquant directement
l’utilisation des Nouvelles technologies d’Information et de Communication (NTIC). La
répartition est inégale entre les Etats-membres comme le montre le tableau 1.1.
Comme il existe encore une variété de termes utilisés pour décrire les nouvelles formes
de travail, le travail à distance étant une appellation générique, les chercheurs ne sont pas
systématiquement d’accord sur ce que constitue le télétravail. Ceci explique la disparité
entre les différentes estimations du nombre de télétravailleurs. Ces données permettent
1
Telefutures : A study on teleworking in Ireland (voir http ://www.forbairt.ie/telefutures)
2
Jack Nilles est généralement considéré comme “le pére du télétravail” avec des publications régulières
qui font référence sur le sujet depuis 1973.
6
TRAVAIL COOPÉRATIF
Nbr. télétrav.(∗1000) % télétrav. % Progres.97 − 98
Allemagne 1 800 5.1 +53
Autriche 67 2.0 +33
Belgique et Luxembourg 250 6.2 +25
Danemark 300 11.6 +20
Espagne 120 0.9 +50
Finlande 220 10.0 +59
France 420 1.8 +67
Grèce 50 1.3 +160
Irlande 58 7.1 +16
Italie 350 1.7 +40
Pays-Bas 1 200 18.2 +100
Portugal 100 2.2 +67
R.U 1 455 5.5 +13
Suède 300 9.0 +67
Total UE 6 690 4.5 +45
USA3 14 700 12.9 +42
Tab. 1.1 – Développement du télétravail en Europe, 1998-1999. d’aprés (Béréziat et al.,

2000)
seulement de tracer les grandes tendances, et de donner une idée sur la manière dont
des conditions sociales et/ou légales différentes favorisent ou non le développement du
télétravail.
1.2 Les tendances technologiques pour le télétravail

et le travail coopératif
1.2.1 Les tendances technologiques
Les développements considérables et extrêmement rapides de la technologie et la large
diffusion des micro-ordinateurs performants à des prix abordables ainsi que la baisse des
coûts des services de télécommunications, ont rendu le télétravail possible.
Les lignes RNIS4 (ou Numéris, nom commercial du service proposé par France Télécom)
offrent aux télétravailleurs la possibilité de transférer des fichiers très rapidement et d’avoir
accès à des outils de travail coopératifs synchrones comme les visioconférences. La diffu-
sion du RNIS permet aux télétravailleurs d’échanger voix, images et données avec un débit
élevé. Il est probable que la technologie RNIS sera fortement concurrencée par la nouvelle
technologie ADSL (Asymmetric Digital Subscriber Line), fournissant des débits encore
plus élevés que le RNIS et ceci sur une simple ligne téléphonique.
D’autres technologies liées aux réseaux câblés et à la diffusion par satellite, peuvent cha-
4
RNIS : Réseaux Numérique à Intégration de service
7
cune procurer un accès rapide à Internet.
Les progrès techniques considérables dans le domaine de la compression et décompres-

sion de la voix ou d’images pour la visioconférence, permettent actuellement le déplacement
de nouvelles applications sur Internet. Bien que la qualité ne soit pas aussi bonne que celle
des lignes téléphoniques classiques ou Numéris, et qu’il subsiste des problèmes de compa-
tibilité et de normalisation entre systèmes, ainsi que les phénomènes d’encombrement du
réseau mondial, cet usage est acceptable essentiellement pour des utilisateurs non profes-
sionnels à l’heure actuelle.
1.2.2 Le travail coopératif

On appelle “travail coopératif”, le travail en équipe (“Teamwork”) (Bannon et Schmidt,
1989), (Schal et Zeller, 1990), (Greenberg, 1991), tout ce qui entraı̂ne des besoins de com-
munication et de coordination entre personnes afin d’assurer conjointement un travail.
Le “Computer Supported Cooperative Work” (CSCW), traduit en français sous le terme

”Activités multi-participantes informatisées”, est le domaine de recherche répondant aux
questions suivantes : quelles sont les caractéristiques du travail coopératif comme op-
posé au travail effectué par des individus isolés ? Comment l’informatique peut-elle être
appliquée pour résoudre les problèmes logistiques du travail coopératif ? Comment les
concepteurs abordent-ils les délicats et complexes problèmes de conception des systèmes
qui façonnent les relations sociales ?
Le CSCW est un domaine de recherche multi-disciplinaire intéressant, les sociologues, les
psychologues, les ergonomes et les informaticiens. Bien que le CSCW comporte le terme
“Computer”, les outils mis en jeu dans cette discipline dépassent de loin l’ordinateur
en incluant la téléphonie, les messageries, la vidéo et les systèmes d’imagerie. En tant
que domaine scientifique, le “Travail Coopératif” est encore immature et les problèmes
théoriques sont nombreux.
Les verrous existant sont d’une manière générale à la fois d’ordre :

– Informatique ou communicationnel : Transmettre avec une bande passante
suffisante, développer des systèmes d’installation et de maintenance commodes pour
des utilisateurs qui ne sont souvent pas les prescripteurs et,
– Ergonomiques et d’usage : Développer des interfaces coopératives multimédia
conviviales et d’un apprentissage aisé.
De manière plus précise et non nécessairement exhaustive, on peut noter les problèmes
ergonomiques liés à l’existence même d’une interface pour les systèmes de vidéo-conférence :
lorsque deux individus entrent en communication en face à face, il n’y a pas d’interface, pas
de boutons à cliquer ou de numéro à composer. La complexité des interfaces des systèmes
de communication actuels est telle qu’elle est un obstacle à l’utilisation de ces systèmes
(sans parler des manipulations a réaliser pendant la session elle-même, par exemple lorsque
que l’on veut ajouter un participant, partager un document ou segmenter les participants
en sous-sessions de travail disjointes). Il est donc nécessaire d’inventer de nouvelles inter-
faces pour ces systèmes, plus “transparentes” sinon invisibles.
8
TRAVAIL COOPÉRATIF
Un autre verrou d’utilisabilité des outils CSCW réside dans leur manque d’intégration.
Alors que les activités de groupes sont “à géométrie variable”, les outils existants ne
couvrent en général qu’un mode de coopération : synchrone/asynchrone (ou bien temps
réel/temps différé). La réalisation de tels environnements CSCW remet en question une
bonne partie des infrastructures logicielles existantes (systèmes d’exploitation, protocoles
réseau, etc.).
Une autre difficulté du même ordre réside dans la disponibilité d’outils qui s’exécutent
de façon transparente dans des environnements hétérogènes en adoptant le “look and
feel” de chaque plate-forme. La question est donc de simplifier les tâches cognitives de
l’utilisateur en déléguant le plus possible de celles-ci aux applications. Il s’agira donc ici
de rendre cette hétérogénéité transparente aux utilisateurs tout en exploitant au mieux
les capacités de chaque plate-forme (i.e. sans s’en remettre au plus grand dénominateur
commun, comme le fait par exemple JAVA5 ).
1.2.3 Les Interfaces Homme-Machine avancées

Il convient de faciliter l’accès de l’utilisateur au “monde”, incluant l’information et la
connaissance mais allant au delà. L’enjeu des Interfaces Homme-Machine (IHM) avancées
est de proposer de nouveaux moyens d’accès à l’information afin que, quels que soient les
changements d’environnement, ces informations et ces connaissances soient accessibles.
Ces contraintes d’accès sont mises en évidence dans des conditions liées aux transports,
à la mobilité, à l’internationalisation et au handicap.
Les IHM avancées vont permettre la création de services fédérateurs, comme l’accès à l’en-
semble de la messagerie asynchrone (vocal, mail, fax). La reconnaissance et la synthèse de
la parole viennent compléter ou remplacer clavier et écran. Le poste informatique person-
nel et/ou la base de données commune deviennent télé-opérables. Internet et téléphonie
mobile, le mariage est séduisant. Il devient détonnant lorsque l’on y ajoute les possibilités
des IHM avancées.
Il convient aussi de réaliser des systèmes de communication plus naturels, ce qui en-
traı̂ne bien sûr une plus grande complexité dans leur fonctionnement. Combien de per-
sonnes n’utilisent qu’une faible partie des fonctions de leur traitement de texte ou de leur
téléphone d’entreprise ? Combien de personnes sont également hermétiques aux concepts
du monde informatique, principalement ceux du PC ? Il faut donc arriver à des interfaces
d’apparence simples, permettant au plus grand nombre de communiquer en utilisant les
nouvelles technologies disponibles, mais l’effort pour y arriver ne saurait être sous-estimé.
La communication homme-machine qui faisait apparaı̂tre ces deux acteurs face à face
évolue à présent vers un partenariat homme-machine qui les place côte à côte pour résoudre
ensemble, et en coopération, un problème commun. Les domaines couverts par ce thème
concernent les différentes modalités nouvelles de communication : langages (le vocal ou
l’écrit), visuelles et graphiques, gestuelles (dans les aspects d’analyse et de synthèse/retour
d’efforts), ainsi que leur combinaison dans des systèmes de communication multimodales,
ou dans des systèmes de réalité virtuelle ou augmentée. Dans tous ces cas, les aspects
télématiques et communication à distance doivent être présents, voir essentiels.
5
Un langage de programmation objet de chez “Sun Microsystems”, il génère un code exécutable
universel
9
1.3 Télétravail : Téléopération et Télérobotique

Nous proposons ici un bref historique et une synthèse ainsi qu’un classement rapide
des systèmes robotiques sur la base du mode de contrôle utilisé. Le terme contrôle désigne
ici aussi bien la commande au sens de l’automatique que les interactions entre l’homme
et la machine. Généralement le mode de contrôle est choisi en fonction de l’application
suivant plusieurs critères (La complexité de la tâche à accomplir, la nature des moyens de
transmission, la charge acceptable par l’opérateur, la puissance de calcul et les algorithmes
embarqués à bord, les capteurs disponibles, etc.).
Bref historique
Vers l’année 1770, la construction de machines simples, ainsi que leur mécanisation a
marqué le départ de la révolution industrielle. Au début du 20ème siècle, les machines
automatiques fixes et les chaı̂nes de montage permettent le développement de la produc-
tion de masse. Le travail à la chaı̂ne favorise l’accroissement des taux de production en
réduisant les temps de fabrication. Les cycles d’usinage et de montage sont simples et
répétitifs, à cadence fixe. Apparaissent alors des machines-outils munies de commandes
automatiques rudimentaires, telles que les matrices de programmation par fiches qui per-
mettent d’effectuer des séquences d’opérations prédéterminées. Les machines à copier
permettent d’usiner des pièces par copie des déplacements d’un palpeur sur un gabarit
modèle au moyen de moteurs asservis qui commandent les mouvements de l’outil d’usi-
nage sur l’ébauche (Koren, 1985). En 1953, des recherches menées au MIT conduisent
au développement d’une nouvelle technologie de machines numériques adaptées à des
opérations précises et répétées. Le concept du robot industriel est breveté en 1954 (bre-
vet US n˚ 2988237). Ce brevet décrit la réalisation d’un bras mécanique asservi capable
d’effectuer des tâches à caractère industriel. En 1958, Planet Corporation (USA) com-
bine avec succès cette technologie avec la technologie des télémanipulateurs développée
pour l’industrie nucléaire américaine et crée le premier robot manipulateur industriel. La
société Unimation voit le jour peu après, et livre le premier Unimate à General Motors en
1961. Vers la fin des années 70, ces robots dits “de première génération” se généralisent
à l’ensemble de la production industrielle. Pendant que se développe ce nouveau concept
“d’usine automatique”, la robotique aborde d’autres domaines. Ainsi, l’Union Soviétique
réussit à téléopérer un robot mobile sur la Lune en 1971. En 1976, la sonde Viking I de
la NASA6 se pose sur la planète Mars, équipée d’un bras manipulateur téléopéré depuis
la terre afin de prélever des échantillons de sol et de rochers (Freedman, 1993) ou encore
la mission du robot sojourner en 1997.
1.3.1 La Téléopération
Dans cette partie, nous présentons quelques concepts de base et quelques problèmes
de fond liés à la téléopération. Pour un état de l’art sur la technologie de la téléopération
nous conseillons les références suivantes, (Vertut et Coiffet, 1984) et (Sheridan, 1992).
La Téléopération désigne les principes et les techniques qui permettent à l’opérateur
humain d’accomplir une tâche à distance, à l’aide d’un système robotique d’intervention
(dispositif esclave), commandé à partir d’une station de contrôle (dispositif maı̂tre) (figure
1.1), par l’intermédiaire d’un canal de télécommunication. Elle a pris ses origines dans le
6
National Aeronautics and Space Agency
10
1.3. TELETRAVAIL : TELEOPERATION ET TELEROBOTIQUE
besoin de prolonger le geste de l’homme au delà de la main, et se poursuit par l’ambition

de se trouver là ou on ne se trouve pas (Téléprésence) (figure 1.2).
Fig. 1.1 – Illustration de l’architecture générale d’un système de Téléopération
Fig. 1.2 – Exemples de système : A gauche, le système de téléopération du CEA/CEREM ;

A droite, le système de téléprésence avec un robot mobile du groupe de recherche en
téléprésence “California Corporation Telepresence Research”
De nos jours, la téléopération s’applique aussi bien aux bras redondants, aux préhenseu-
rs mécaniques polyarticulés, et à diverses sortes de robot mobiles à roues (Clement et al.,
1988), (Causse et Crowley, 1993), et à pattes (Kheddar et al., 1996) . Cependant, un
certain nombre de problèmes de fond et complexes existent encore. Nous citerons par
exemple, l’inévitable problème de délai dû au canal de transmission entre les deux sites,
maı̂tre et esclave qui implique un retard de transmission d’informations sensorielles utiles à
l’opérateur. En effet tout retard de transmission entraı̂ne des instabilités difficilement com-
pensables (Ferell, 1965), (Ferell, 1966), (Bejczy et al., 1990) et (Sheridan, 1993). d’Autres
problèmes qui ne cessent de préoccuper l’esprit de nombreux chercheurs dans ce do-
maine concernent le choix d’un système de commande universel (Bejczy, 1992) ainsi que
la compréhension de nos propres sous-systèmes sensoriels (Brooks, 1990) et (Lederman et
Klatzky, 1994).
1.3.1.1 Le problème de délai de transmission
De nombreuses recherches ont été réalisées pour l’étude et l’analyse du problème de

délai (retard) de transmission en téléopération. Deux approches ont été utilisées afin d’ana-
11
lyser ce problème (Kheddar, 1997). La première est basée sur l’automatique classique et
la seconde est basée sur la théorie des lignes et de la passivité.
La première approche, est de nature compensatoire, l’idée était d’introduire des cor-
recteurs dans la boucle d’asservissement afin de compenser les systèmes à retards (De-
Larminat, 1993).
La seconde approche, considère le retard comme subi, c’est à dire comme partie intégrante
du système (Niemeyer et Slotine, 1991), (Leung et Francis, 1992), (Spong, 1993) et (Law-
rence, 1993) et (Andriot, 1997).
Malheureusement, ces deux approches exigent que le délai de transmission soit connu,
alors que la majorité des protocoles publiques actuels de transmission de données informa-
tique ne garantissent pas la constance des délais de transmission. En effet indépendamment
de la taille des données transmises, le délai peut varier d’une manière très aléatoire pour
certains protocoles de transmission (par exemple Internet). Les travaux de Kosuge et son
équipe ont montré (Kosuge et al., 1996) que ce problème entraı̂ne une instabilité même si
les variations de délai sont relativement petites.
Dans les systèmes de téléopération originels, l’opérateur doit impérativement subire

un apprentissage qui peut être long avant d’obtenir une bonne adaptation et une bonne
maı̂trise du système de téléopération (Zak et Das, 1995). En plus l’adaptation obtenue
peut ne pas être adéquate pour une autre architecture. La sophistication et le nombre im-
portant d’applications téléopérées engendre une augmentation de la charge de travail de
l’opérateur, sa fatigue et ce qui entraı̂ne une diminution de ses performances et augmente
ainsi les risques d’erreurs de téléopération.
1.3.1.2 Evolution des systèmes de téléopération
L’évolution de l’informatique et des supports de télécommunication numérique est à

l’origine de l’évolution de la téléopération. Grâce à eux, les robots esclaves ont pu être
déportés à des distance considérables (Vertut et Coiffet, 1984). En effet, initialement
l’opérateur commandait le robot esclave dans un niveau assez bas, les trajectoires issues
des actions désirées sont envoyées directement via le dispositif maı̂tre. Le retour d’infor-
mation (Images, force de contact, etc) se fait directement vers l’opérateur. Mais malheu-
reusement, cette approche originelle n’a pas duré très longtemps, car les chercheurs se
sont vite rendu compte de la nécessité d’exploiter les possibilités que peuvent offrir des
ordinateurs pour apporter une assistance à l’opérateur. Depuis, plusieurs approches et
concepts ont été proposés pour améliorer et faire évoluer les systèmes de téléopération.
Nous résumons ici un classement des différentes approches représentants les modes d’in-
teraction Homme-Machine que l’on retrouve généralement dans la plupart des systèmes
de téléopération.
La Téléopération Assistée par Ordinateur - TAO
La TAO (Vertut et Coiffet, 1984), est vue comme une voie intermédiaire entre la
téléopération originelle bas niveau et la supervision. L’objectif de la TAO est de
réaliser à chaque instant et pour toute étape de la tâche, une exploitation optimale
des ressources d’un ordinateur. Tout se fait dans la partie maı̂tre, le robot reste
12
esclave des actions de l’opérateur aidé par des programmes informatiques. La TAO
s’oriente de plus en plus vers le développement des interfaces homme-machines pour
la programmation hors ligne, l’entraı̂nement de l’opérateur à la désignation de mis-
sions téléopérées etc. Depuis peu, la TAO bénéficie d’un atout nouveau qui est la
Réalité Virtuelle (RV) (Burdea et al., 1992). Un paragraphe concernant l’utilisation
de cette technologie est présenté dans la suite de ce chapitre.
La Téléopération à Désignation d’Objectif (supervisée) - TDO
Dans ce mode, l’opérateur est plutôt vu comme un superviseur (Sheridan, 1992).

L’intervention de l’opérateur se limite dans ce cas à la désignation d’objectifs qui
seront réalisés par le robot. Par exemple, l’opérateur peut désigner sur écran un
objet à atteindre par le robot. Un autre exemple consiste à désigner dans un haut
niveau une tâche que doit réaliser le robot (saisir objet, déposer objet, etc.). Ce
concept vise une exploitation optimale du côté du robot.
La Téléopération Semi autonome - TSA
La plupart des systèmes de téléopération actuels, s’orientent vers l’utilisation des

deux concepts précédents (TAO et TDO). En effet ils tentent de moderniser la
téléopération par une meilleure exploitation simultanée de l’autonomie du robot et
des capacités de l’opérateur. Certains auteurs parlent de la Téléopération à com-
mande partagée (Sheridan, 1992), (Hayati et Venkataraman, 1989), (Bejczy et al.,
1990), (Kim et al., 1992) et (Michelman et Allen, 1994). La commande partagée
(shared control) est référencée dans un bon nombre de schémas de commande des
systèmes de téléopération. La plupart des travaux se dirigent vers une approche
plutôt unifiée (Conway et al., 1990), (Graves et Volz, 1995), (Tarn et al., 1995) ou
encore (Spenny et Schneider, 1997). Ces derniers proposent des méthodes que l’on
peut modifier dynamiquement afin de générer une variété de modes de commandes.
Nous pouvons résumer dans la figure 1.3, le classement de ces trois concepts selon le
degré d’autonomie du dispositif esclave .
Pas autonome Semi autonome Complètement autonome
TAO TDO
TSA
Fig. 1.3 – Classement de la TAO, TDO et TSA selon le degré d’autonomie du dispositif
esclave.
1.3.2 La Télérobotique
La télérobotique est une forme de téléopération lorsque l’opérateur réalise des tâches
à distance en utilisant un robot. Ce dernier peut fonctionner d’une façon autonome.
13
La télérobotique résulte en fait de la fusion des deux domaines originellement séparés

qui sont la téléopération et la robotique. En effet, la robotique autonome n’étant pas encore
tout à fait au point, le robot doit présentement être opéré à distance par un opérateur
humain. On doit donc tenir compte des principes développés en téléopération. Cependant,
comme le robot peut exécuter des tâches élémentaires de façon autonome, on parle de
télérobotique plutôt que de téléopération.
La télérobotique trouve des applications partout où l’homme a des difficultés à tra-
vailler directement (milieu hostile, lointain, trop grand ou trop petit) et où les tâches
sont suffisamment complexes ou imprévisibles pour rendre difficile une automatisation
complète. La condition principale de développement de la télérobotique est sa capacité à
concurrencer l’intervention directe d’un homme ou l’utilisation d’un système automatique
très spécialisé. Dans le premier cas, l’atout de la télérobotique est tout d’abord le rempla-
cement d’un travail humain pénible ou dangereux par un autre, plus sûr et confortable.
Dans le second cas il faut montrer l’intérêt d’un matériel plus versatile que le système
automatique dédié à l’application envisagée.
Pour répondre à la question pourquoi la télérobotique, Sheridan du MIT (Sheridan,
1992) fournit les raisons suivantes :
{ Pour améliorer la performance et la fiabilité dans l’accomplissement des tâches,
| Pour améliorer la sécurité de l’opérateur,
} Pour réduire le travail humain.
1.3.2.1 Quelques domaines d’application
Le domaine nucléaire
Le nucléaire a été le premier domaine à stimuler le développement de systèmes de
télérobotique. L’industrie nucléaire s’intéresse généralement aux applications sui-
vantes :
Æ La manipulation de produits radioactifs : Elle se fait en cellule spécialisée,
dans laquelle des télémanipulateurs mécaniques sont utilisés pour amener et
retirer le produit. L’opérateur travaille en vision directe et il n’y a pas de
problèmes d’éloignement (figure 1.4). L’introduction de la télérobotique n’est
pas encore envisagée dans ce type d’application.
Æ La maintenance des installations : Ce type de tâche est essentiellement
réalisée par des machines spécialisées. Ces dernières offrent l’avantage d’être
parfaitement adaptées à la tâche. Par contre leur mise en oeuvre est longue
et elles ne sont pas adaptées aux changements de situation et ne peuvent être
réutilisées dans d’autres tâches. La télérobotique est en train de trouver sa
place suite aux recherches menées ces dernières années.
Æ Le démantèlement d’installation et l’intervention suite à un incident :
L’utilisation des systèmes télérobotiques est une voie en cours de recherche
concernant ces deux domaines. L’exploitation des nouvelles technologies comme
la Réalité Virtuelle / Augmentée est un atout favorable pour la poursuite de
ces recherches.
14
Fig. 1.4 – Exemple du système Poste de Travail Mobile (PTM) du CEA piloté par un
contrôleur TAO 2000
Le domaine spatial
Les principales applications de la télérobotique dans ce domaine sont l’exploration
et la maintenance de satellites (figure 1.5). L’éloignement du site de travail et l’im-
portant temps de transmission des informations, impliquent l’utilisation de robots
ayant une grande autonomie (basée sur une architecture complexe et intégrant de
nombreux capteurs) sans pour autant exclure la possibilité de les téléopérer (la mis-
sion du sojourner en 1997 sur la planète mars en est un exemple).
Fig. 1.5 – Exemples de robots : A gauche, l’exploration de Mars par “sojourner”, à droite
, la maintenance de satellites
Le domaine sous-marin
A l’exception des applications militaires, les applications civiles sont principale-
ment liées à l’industrie de l’offshore, l’inspection, la construction et la maintenance
de conduites, structures, câbles sous-marins voire aussi des investigations scienti-
fiques (épaves, espèces marines, etc.). Des bras manipulateurs embarqués à bord de
véhicules peuvent être autonomes ou même téléopérés (figure 1.6). Ce domaine conti-
nue à être le principal domaine d’activité en nombre de systèmes de télérobotique.
Le domaine militaire
La télérobotique intervient pour la désactivation de mines, l’observation de terri-
toires ennemis ainsi que la télécommande d’engins tels que les chars, les avions et
les hélicoptèrs.
15
Fig. 1.6 – Exemple d’utilisation d’un robot embarqué sur un véhicule sous marin JASON
((Sayers et al., 1995))
L’aide aux handicapés

Ce domaine est extrêmement riche de possibilités. De nombreux projets ont été
étudiés et mis en œuvre afin d’aider des handicapés à mieux vivre. On peut ci-
ter par exemple le projets SPARTACUS (Galerne, 1989) et le projet MASTER du
CEA (Cammoun et al., 1994) ont permis l’automatisation de quelques tâches quo-
tidiennes à partir d’une commande utilisant les mobilités disponibles de l’handicapé.
Le domaine médical
Les médecins et les chirurgiens, utilisent de plus en plus de robots afin de les assister
ou même de les remplacer dans certaines tâches. La téléchirurgie (figure 1.7) semble
avoir un avenir prometteur, en particulier dans la chirurgie oculaire, qui réclame une
grande précision et une sécurité extrême (Grace et al., 1993) (Hunter et al., 1994).
D’autres applications peuvent être trouvées en chirurgie mini invasive (Laparoscopie
et coelioscopie).
Nous noterons que l’évolution des systèmes de téléopération est étroitement liée à
l’évolution des technologies d’interactions homme-machine. Nous nous intéressons tout
particulièrement aux technologies de la Réalité Virtuelle (RV) et de la Réalité Augmentée
(RA) qui ont été rapidement adoptées au profit de la téléopération. Bien que le terme de
RA est considéré comme une méthode de la RV, nous avons préféré les séparer afin de
montrer les similitudes et les différences qui existent entre ces deux concepts. Ce sont des
techniques qui ont permis d’une part, de faire face au problème de délai de transmission,
et d’autre part de fournir une meilleure interaction homme-machine.
1.3.3 La réalité virtuelle et la réalité augmentée : Outils indis-

pensables pour le télétravail
1.3.3.1 La réalité virtuelle : Bref Etat de l’art
Bien que ce mot ne soit à la mode que depuis quelques années, la réalité virtuelle
est née de recherches qui ont débuté dans les années cinquante dans des milieux aussi
divers que les laboratoires de la NASA ou les studios d’Hollywood. Les pionniers de ce
16
Fig. 1.7 – Illustration de la téléchirurgie
monde artificiel furent des visionnaires qui empruntèrent des techniques aussi variées que
le cinéma, l’informatique, l’automatique et l’électronique, les briques de ce qui fût appelé
la Réalité Virtuelle (RV).
Il existe autant de définitions qu’il y a de champs d’application à cette technologie, en
plus, cette technologie est plutôt vue comme quelque chose de magique, aux possibilités
quasi illimitées, la réalité étant tout autre chose. Les contraintes auxquelles doit faire
face cette technologie sont nombreuses. Ce qui a provoqué de multiples définitions de
la RV. Nous avons retenu deux définitions qui à nos yeux semblent plus explicites. La
première est donnée par Burdea et Coiffet (Burdea, 1993) concernant le terme RV et la
deuxième est plus générale, elle introduit la notion d’Environnement Virtuel (EV) retenu
notamment par Thibout (Thibout, 1996) et dont la RV constitue une partie. Pour ce qui
est des interfaces de la réalité virtuelle, nous recommandons la référence (Fuchs, 1996).
Définition de la RV :
Un système de réalité virtuelle est une interface qui implique la simulation en temps
réel et des interactions via de multiples canaux sensoriels. Ces canaux sensoriels sont
ceux de l’homme, vision, audition, toucher odorat et le goût.
17
Définition de l’EV :
L’environnement virtuel est constitué d’un ensemble de techniques permettant de
reproduire le plus fidèlement, par calcul, le comportement d’entités 3D. Ces techniques
se décomposent en deux classes :
L’interface homme-machine (interaction avec l’EV)
Perception visuelle, sonore, tactile.
Acquisition de données (gant, souris 6D, etc.)
Communication accrue entre l’homme et la machine (multimodalité)
Le comportement des entités de l’EV
Modèles cinématique, dynamique
Gestion des collisions
Modèles d’éclairement
etc...
Si l’on regarde les types d’applications utilisant la réalité virtuelle, on se rend compte
que le divertissement, les arts et l’éducation dominent ce marché. L’autre secteur impor-
tant concerne la haute technologie comme l’aérospatial, la robotique, la médecine , les
sciences ou le domaine militaire. On peut considérer que tous les domaines de la vie cou-
rante peuvent et pourront un jour être touché par la RV.
Heslsel et Doherty7 , ont classé les domaines en fonction du nombre possible d’applications.
Domaine Nombre d’application

Simulation 73
Visualisation 67
Education 66
Apprentissage 65
Divertissement 65
Art graphique 65
Armement 52
Aérospatial 50
Téléprésence 50
Médecine 49
Architecture 46
Audio-visuel 41
Affaires 40
Télérobotique 39
Communications 38
Tab. 1.2 – Etude marketing des applications de RV
7
http ://brahma.imag.fr/Multimedia/DESSGI/Realite-Virtuelle/html/applications.html
18
1.3.3.2 Quelques domaines d’application de la RV
L’Architecture : On peut créer des plans, imaginer des architectures de construc-

tion de cités, de villes, enfin grâce au virtuel on peut faire visiter une maison avant
qu’elle ne soit construite. Ce procédé est surtout utilisé pour les handicapés. A
l’aide d’une chaı̂se roulante virtuelle, on peut vérifier s’il y aura un problème lors
des déplacements à l’intérieur du bâtiment en question.
L’armée : Les militaires utilisent la RV pour plusieurs raisons comme : la si-

mulation. Grâce à la RV, l’armée peut entraı̂ner ses régiments pour des missions
spécifiques ou bien pour les entraı̂ner de façon générale. Nous avons eu la preuve de
l’efficacité de la RV lors de la Guerre du Golf. Son efficacité a été clairement mise
en évidence, puisque les pilotes ont pu s’entraı̂ner durant des mois sur des simu-
lateurs virtuels avec des données qui provenaient directement des satellites espions
américains. A leur arrivée sur le champs de bataille, ils en connaissaient déjà tous
les recoins.
Le divertissement : C’est sans doute dans ce secteur que la RV est la plus exploitée
à son état pur. Des jeux très réels dans un monde imaginaire où tout est permis. Les
rêves les plus fous y sont autorisés. La majorité des jeux virtuels qui existent sont
basés sur le principe de la simulation. Être dans un véhicule et le diriger au travers
de différents environnements, en ressentir toutes les secousses. Les jeux virtuels font
de plus en plus fureur.
L’enseignement : L’apprentissage à l’aide des hypermédia entraı̂ne une navigation

non linéaire et interactive par l’usage d’un matériel éducatif qui atteint les sens de
l’étudiant : vision, audition, toucher, odorat. Les ordinateurs pour les hypermédia,
connectés aux réseaux internationaux à large bande, réalisent la plupart de l’en-
seignement interactif, plus spécialement l’enseignement des détails techniques dans
les domaines de l’art, des affaires, de l’histoire, des langues, de la médecine, de la
musique, des sciences. Les instructeurs donneront moins d’explications, parce que
les meilleurs matériaux des meilleurs enseignants du monde sur presque n’importe
quel sujet seront ajoutés aux présentations hypermédia de son propre professeur et
sont disponibles sur simple appel à n’importe quel moment du jour et de la nuit
quand les étudiants veulent apprendre.
La télérobotique : Utilisée pour des interventions dans des milieux hostiles tels
que : l’intérieur d’une centrale nucléaire, les fonds sous-marin, l’intérieur d’un vol-
can... c’est d’ailleurs ce principe qui a été utilisé lors des récentes missions spatiales
sur la planète Mars. Grâce à la RV les techniciens peuvent s’entraı̂ner à manipuler
le robot, améliorer leurs réflexes en causant des fausses situations d’urgence ou de
faux problèmes techniques. Ils peuvent aussi enregistrer une série de mouvements
ou de tâches, que le robot devra faire, avant de les faire faire par le robot dans
une situation réelle. Dans une opération de télérobotique la plupart des actions du
robot sont préprogrammées. Lorsque le robot effectue ces phases préprogrammées,
l’opérateur ne croise pas les doigts. Il doit superviser le robot durant l’accomplis-
sement de sa tâche ou, dans certains cas, il doit assister le robot (téléassistance).
Les techniques de RV en robotique sont susceptibles de remplir deux fonctions. La
19
première est la simulation, qui permet à l’opérateur de s’entraı̂ner (à manipuler le

robot) et de programmer des tâches qui seront ensuite exécutées par le robot. La
deuxième fonction est de servir d’interface entre l’opérateur et le robot au cours
d’une mission, par laquelle l’opérateur peut manipuler le robot et l’assister.
La chirurgie : En chirurgie, la tendance est de réduire la taille de l’accès à la

zone à opérer. L’objectif de cette tendance est de réduire le risque d’infection, la
morbidité postopératoire et bien sûr le temps d’hospitalisation. Ces techniques se
nomment vidéoscopie et endoscopie. Ces deux techniques fonctionnent très bien,
mais la visibilité du chirurgien et l’accessibilité à la zone à opérer sont fortement
réduites. Grâce à la RV, ce problème peut être enfin résolu. Ces techniques consistent
à introduire une micro-caméra, qui transmet les images à un écran installé près de
la table d’opération, par une petite incision et par une autre, introduire les ins-
truments de chirurgie. Tout ceci pour effectuer l’acte chirurgical. La visibilité étant
restreinte et le chirurgien étant privé du contact avec les organes, l’opération devient
très difficile. À l’aide d’échographie, de scanographie ou d’imagerie par résonance
magnétique nucléaire, il est possible de reconstituer la zone à opérer en une image
tridimensionnelle visible à l’aide d’un système de RV. Le chirurgien a donc une
meilleure visibilité et puisqu’il peut grossir l’image qu’il reçoit, il est même plus
précis. Il faut comprendre que ce procédé est à un stade peu développé. Par ce fait,
il ne peut pas être utilisé en pratique, il faut attendre encore quelques années avant
que ce procédé n’atteigne sa maturité. Cette technique ne servira pas seulement à
réduire le risque d’infection, la morbidité postopératoire, le temps d’hospitalisation
et à augmenter la précision de l’acte chirurgical et la visibilité. Mais elle permettra
à de jeunes chirurgiens de s’entraı̂ner sur des modèles virtuels avant de pratiquer
des opérations sur de vrais sujets.
La NASA s’intéresse à la téléchirurgie, pour permettre l’opération de quelqu’un
dans l’espace. Le chirurgien opérerait sur un modèle virtuel, et un robot assistant
opérerait réellement le patient. Les capteurs d’efforts devraient, dans ce cas, four-
nir et faire ressentir, les plus légers efforts appliqués par les outils chirurgicaux du
robot. Nous ne sommes pas encore rendu à faire de la téléchirurgie à l’aide de la
télérobotique, mais ce procédé est en cours de conception et de développement.
Il faut noter qu’au début de l’apparition de la réalité virtuelle, on pensait que tous
les domaines allaient être touchés et que beaucoup d’applications basées sur ce principe
verraient le jour. Aujourd’hui, la tendance est de ne pas réaliser des applications purement
virtuelles, mais, avec les méthodes de ces dernières, d’augmenter la perception des utilisa-
teurs. Ce nouveau concept se nomme la réalité augmentée. Dans ce cas, l’utilisateur n’est
plus complètement immergé dans un monde non réel, mais des informations virtuelles,
viennent renforcer sa perception de la réalité. La définition de la réalité virtuelle n’étant
pas encore unanime, il est difficile de dire si la réalité augmentée est ou non de la réalité
virtuelle.
1.3.3.3 La réalité augmentée :
La Réalité Augmentée (RA) peut être définie comme une combinaison de la vraie
scène visualisée par l’utilisateur et d’une scène virtuelle produite par l’ordinateur. D’une
manière générale cette technique consiste à augmenter la scène réelle avec des informations
virtuelles supplémentaires. Cette augmentation peut prendre différentes formes selon les
20
domaines d’application comme nous allons le voir par la suite. Par exemple dans le do-
maine de la télérobotique, généralement cette opération consiste à superposer un modèle
virtuel sur une image réelle grâce à un mécanisme appelé la calibration (cf. § 3.2.2). On
parlera alors de la visualisation prédictive ou encore des prédicteurs graphiques utilisés
généralement en téléopération soit pour pallier le problème de délai (Noyes et Sheridan,
1984), (Bejczy et al., 1990) et (Bejczy et Kim, 1990), soit pour rehausser l’image vidéo
pour compenser ses défauts ( (Mallem et al., 1992), figure 1.8) et (Oyama et al., 1992).
Des exemples de systèmes à base de cette technologie sont présentés à la fin de cette
partie.
Superposition par un modèle fil de fer
Bras esclave Objet
Fig. 1.8 – Rehaussement d’images vidéo dégradées par superposition d’une image
synthétique “fil de fer” à une image caméra
1.3.3.4 Quelques domaines d’application de la RA
L’évolution de la technologie d’affichage et des systèmes informatiques, ainsi que le

traitement temps réel d’images vidéo a rendu possible l’affichage d’images virtuelles cor-
rectement appariées aux images vidéo. La réalité augmentée a trouvé sa place et a apporté
des solutions à des problèmes rencontrés dans de nombreux domaines.
Médical : L’utilisation des systèmes de la RA dans ce domaine est une voie très
encouragée par de nombreux chercheurs. Généralement ce sont les opérations chi-
rurgicales qui en profitent le plus. Par exemple, un robot est utilisé pour assister
le neurochirurgien lors d’une opération chirurgicale sur un patient atteint d’une tu-
meur au cerveau. Des images sont transmises à l’ordinateur qui les traduit en 3D et
durant l’opération, le cerveau virtuel est en permanence superposé à l’image du cer-
veau réel du patient. Cette superposition permet au système de guider le chirurgien
jusqu’à la tumeur moyennant un rayon laser. Quatre systèmes de ce genre existent
aux Etats Unis et deux en France dont un à l’hôpital Necker (Paris).
Divertissement : Une forme simple de la RA est utilisée pendant le journal de

télévision. La plupart du temps le journaliste se trouve devant un fond bleu ou vert
et cette image réelle est augmentée avec des images générées par ordinateur.
Formation militaire : Les militaires utilisent aussi des systèmes de RA où des
informations s’affichent sur leur écran de pilotage, ou bien un viseur indiquant la
21
cible à atteindre. On trouve un système distribué de simulation de guerre SIMNET

qui utilise aussi des techniques de la RA (Urban, 1995).
Conception, fabrication, entretien et réparation : Quand les techniciens de

maintenance se trouvent en face d’une nouvelle pièce qui ne leur est pas familière,
au lieu de consulter de nombreux manuels, il peuvent utiliser un système de RA où
l’affichage de l’équipement (pièce) peut être augmenté avec des informations perti-
nentes pour la réparation. Par exemple les composantes qui sont défectueuses vont
clignoter sur l’écran facilitant ainsi la localisation donc la réparation (Feiner et al.,
1993), (Uenohara et Kanade, 1995). Les chercheurs de chez Boeing développent un
système de RA permettant de remplacer le gros travail destiné à la réalisation des
installations électriques pour leur avion (Caudell, 1994). En utilisant ce système
expérimental les techniciens sont guidés par l’affichage augmenté qui leur montre
l’acheminement des câbles.
Robotique et Télérobotique : Comme nous l’avons mentionné au début de

cette section, la RA est utilisée pour améliorer la perception visuelle ou encore
anticiper une situation réelle et prévenir des cas dangereux. En effet, la superposition
d’un modèle virtuel sur une image réelle est très utilisée en Téléopération. Le fait
d’augmenter l’image vidéo avec un modèle en fil de fer par exemple, facilite la
visualisation du monde 3D distant (généralement lorsque le site distant est visualisé
par une seule caméra). Si l’opérateur désire effectuer un déplacement sur le robot
réel, il peut le réaliser sur le robot virtuel (fil de fer) qui n’est rien d’autre qu’un
rehaussement graphique du vrai robot. L’opérateur peut alors décider de l’exécution
de la tâche après avoir vu le résultat de la simulation, ainsi les problèmes d’une
opération de télérobotique liés à la distance séparant les deux sites sont éliminés
(problème de délai, image bruitée, etc ...). La téléopération via un système de RA
offre plusieurs avantages :
Avantage des systèmes de RA :

Délai invariant : L’opérateur reçoit un contrôle visuel depuis l’image gra-
phique et non pas du site distant. Ainsi, les performances de l’opérateur ne
sont pas affectées par le temps de réponse incertain (délai).
Affichage rehaussé : l’image vidéo est augmentée par la présence d’infor-
mations abstraites comme les distances entre objets du site distant, l’environ-
nement du robot et l’affichage des trajectoires générées.
Erreurs de manipulation réduites : La tâche de simulation réduit les
erreurs de collision, les erreurs d’inattention et prévient aussi de certaines
configurations indésirables.
Niveau de contrôle très élevé : L’opérateur se trouve à l’extérieur de la
boucle spatio-temporelle. Il contrôle le robot virtuel sur la machine locale, qui
envoie ensuite des instructions de haut niveau à la machine distante.
Modélisation partielle de l’environnement de la tâche : Des modèles
partiels d’objets qui ont un rapport avec la tâche à exécuter peuvent être
construits interactivement, on peut donc utiliser certaines procédures comme
la détection de collisions par exemple.
22
1.3.3.5 Quelques exemples de systèmes de téléopération utilisant la RV et/ou

la RA
Jet Propulsion Laboratory (JPL USA)

Cette équipe travaille sur un système permettant à l’opérateur de ne plus être tri-
butaire du temps de propagation entre le site esclave et le site maı̂tre (Fiorini et al.,
1992), (Kim, 1993). L’opérateur dispose dans le site maı̂tre d’une interface lui per-
mettant de configurer le système, de gérer l’acquisition des données pertinentes et
de visualiser en temps réel les forces et couples s’exerçant sur le bras. Une interface
vidéo permet de gérer le retour d’information des caméras ainsi que la superposition
à ces dernières des images synthétiques (prédicteurs graphiques Figure 1.9), dont
certaines issues d’une base de données géométriques mise à jour en temps réel. Pour
s’affranchir des temps de transfert des informations, l’image prédite du déroulement
de la tâche est présentée à l’opérateur et recalée sur l’image réelle. La principale
aide apportée à l’opérateur est visuelle et lui permet d’avoir une estimation de la
distance et de l’orientation de l’effecteur par rapport à la cible.
Fig. 1.9 – Utilisation de la prédiction graphique pour la téléopération spatiale. A gauche

prédiction et confirmation de la tâche, à droite exécution
Electro Technical Laboratory (ETL Japon)

Cette équipe réalise un système téléopéré pour l’assemblage et le désassemblage de
pièces mécaniques avec supervision en vision synthétique (Hasegawa, 1991). Un mo-
dule permet la modélisation interactive d’objets en utilisant la coopération d’une
caméra et d’un télémètre laser. Un module de programmation permet, à l’aide d’un
système de visualisation, de superposer l’image synthétique des objets modélisés à
l’image vidéo. Enfin, un module d’exécution gère le manipulateur, le contrôleur de
tâche ainsi que le transformateur de données.
Ergonomics in Teleoperation and Control Laboratory (ETCL Université

de Toronto, Canada)
Dans ce laboratoire, a été réalisé le système ARTEMIS (Augmented Reality TEle-
Manipulation Interface System) (Rastogi et al., 1996) (Figure 1.10). Ce système
permet de générer les modèles de l’environnement distant en utilisant la stéréovision.
Il permet de superposer le modèle stéréographique du robot sur les images stéréovidéo
du site distant, le modèle stéréographique du robot est utilisé pour simuler les
tâches de manipulation et des instructions sont ensuite envoyées au robot réel pour
23
l’exécution.
Fig. 1.10 – Architecture du système ARTEMIS
Commissariat à l’Energie Atomique de Fontenay aux Roses (CEA, France)
Un système de modélisation 3D PYRAMIDE (Bonneau et Even, 1993) a été

développé au CEA. Trois sources d’informations coopèrent pour réaliser le système :
) La base de données géométrique 3D de l’environnement constitué d’une librairie
d’objets pouvant être rencontrés.
) Les images que fournissent les caméras embarquées sur un robot mobile.
) Les informations que peut fournir l’opérateur humain.
Ces informations sont ensuite retournées à l’opérateur sous forme d’images synthéti-
ques superposées à l’image vidéo pour l’assister dans la programmation, l’exécution
et la supervision des tâches.
Virtual Tools and Robotics Laboratory (Pennsylvania State University,

USA)
Les travaux réalisés par cette équipe (Wang et al., 1996) proposent une inter-
face homme-machine utilisant des concepts de la réalité virtuelle et un système
d’évitement d’obstacles afin de planifier les trajectoires d’un télémanipulateur en
vue de la saisie d’objets. Le modèle virtuel d’une pince est superposé au départ à
son image réelle. L’opérateur peut alors tester les configurations de saisie possibles à
l’aide du modèle virtuel. Ceci permet de choisir un chemin de saisie optimum (sans
collisions) et l’appliquer au bras réel.
Laboratoire de Robotique de Paris (LRP France)

Le concept du robot caché est utilisé pour la téléopération d’un ou plusieurs robots
(Kheddar, 1997) (Figure 1.11). Dans ce cas l’environnement réel est modélisé et
le site maı̂tre est découplé du site esclave. l’architecture utilisée est basée sur une
Représentation Fonctionnelle Intermédiaire (RFI) au moyen de laquelle l’opérateur
agit directement sur la tâche. L’état désiré du robot réel est déduit à partir de cette
tâche. Cet état est adressé comme consigne au site esclave.
24
DE L’ART
Fig. 1.11 – schéma général du système de téléopération proposé par Kheddar
Laboratoire Systèmes Complexes (LSC, France)

Dans notre laboratoire LSC du CEMIF (Centre d’Etudes de Mécanique d’Ile de
France) à été développé le système MCIT (Multimedia Control Interface in Teleo-
peration) (Mallem et al., 1993), (Loukil, 1993), (Chekhar, 1994). Ce système procure
à l’opérateur une assistance à la perception et à la commande. Un module de re-
connaissance de polyèdres à partir d’une images de luminance a été développé et
intégré à MCIT (Shaheen, 1999). Il permet la mise à jour de la base de données des
objets pré-modélisés de l’environnement. La superposition des objets reconnus sur
l’image de la scène apporte une aide visuelle à la perception. Ce système automatise
des tâches fastidieuses imposées à l’opérateur comme par exemple l’appariement des
primitives des objets vus par la caméra avec celles des modèles de la base de données
3D pour les identifier et les localiser.
1.4 Internet et les environnements télérobotiques :

Bref état de l’art
Les systèmes de télérobotique sont traditionnellement implantés en utilisant des ca-
naux de communication dédiés. Le déplacement du site esclave et/ou du site maı̂tre
nécessite le déplacement du matériel ainsi que la reconfiguration réseau du canal de com-
munication reliant ces deux sites. Les personnes sont obligées de se déplacer sur le site
client (centre de contrôle afin de travailler et de préparer les missions). De plus si la ma-
chine cliente tombe en panne il devient difficile ou très coûteux de poursuivre la mission
puisqu’il s’agit d’une machine dédiée où se trouve l’interface homme machine.
Cependant la télérobotique basée sur Internet, permet une délocalisation facile des
opérateurs à faible coût, et ne dépend pas de l’endroit où se trouve le matériel qui permet
de contrôler le robot qui, lui, se trouve sur le site esclave généralement distant. Cette
idée a été exploitée par la NASA lors de la préparation de la mission sojourner sur Mars.
Initialement les scientifiques étaient obligés de se déplacer jusqu’au centre de contrôle
en Californie afin de travailler et de contrôler le robot, sachant que la communication
Terre-Mars se fait avec une bande passante très limitée. Le développement d’une inter-
25
face Internet (Backes, WWW), a donné la possibilité aux scientifiques de travailler et de

collaborer ensemble pour contrôler le robot de n’importe où dans le monde (Backes et al.,
1998). Cet exemple montre une des possibilités que peut offrir le télétravail via Internet.
Les premiers sites Internet de la télérobotique sur le Web ont été crées en 1994 par
l’américain Goldberg (Goldberg et al., 1995) et l’Australien Telerobot on the Web (Taylor
et Trevelyan, 1995). Depuis de nombreux sites Internet pour la robotique sur le web ont vu
le jour, et actuellement le site de la NASA (NASA Space Telerobotics Program)8 regroupe
23 sites web y compris le nôtre (système ARITI)9 . Dans ce qui suit, nous allons décrire
brièvement quelques systèmes utilisant Internet comme moyen de contrôler des robots.
1.4.1 Australia’s Telerobot on the Web

Lieu et auteurs : Australie, (Taylor et Trevelyan, 1995).
Type de robot : Un bras manipulateur ASEA IRB à 6 degrés de liberté (ddl).
Applications : manipulation d’objets.
Performances :
– l’utilisateur envoie la position et l’orientation de la pince axe par axe pour la placer
à côté de l’objet. Il peut contrôler l’ouverture et la fermeture de la pince.
– Deux caméras vidéo sont utilisées pour permettre à l’utilisateur de bien placer la
pince et de manipuler l’objet.
Limites :
– Il est difficile de positionner la pince et de manipuler l’objet. Ceci nécessite une
grande concentration et un bon entraı̂nement de la part de l’utilisateur.
– Le retour vidéo se fait à chaque exécution d’une tâche (pas de capture et de transfert
d’images avant l’exécution d’une tâche). Le temps minimum de réponse du système
est entre 15 et 20 secondes.
– Le système ne supporte pas plusieurs superviseurs (d’autres utilisateurs ne peuvent
pas voir ce qui se passe avec le robot tant qu’ils ne le contrôlent pas).
– La pince peut rentrer en collision avec n’importe quel objet (aucune sécurité à ce
niveau), ce qui oblige à fixer la vitesse de déplacement du robot 100mm/sec.
1.4.2 Mercury Project

Lieu et auteurs : USA - Nevada, (Goldberg et al., 1995)
Type de robot : Un robot mobile.
Applications : Téléjardinage.
Performances :
– Le robot mobile est autonome et peut être téléopéré. Sa mission est d’arroser des
plantes.
– Une caméra vidéo embarquée sur le robot permet de visualiser ce que fait le robot
Limites :
– Pas de retour vidéo pendant le déplacement du robot.
– Pas d’autres superviseurs possibles lorsque le système est en cours d’utilisation.
8
http : //ranier.oact.hq.nasa.gov/teleroboticspage/realrobots.html
9
http : //lsc.cemif.univ − evry.f r : 8080/P rojets/ARIT I/
26
DE L’ART
1.4.3 KhepOnTheWeb
Lieu et auteurs : EPFL - Suisse, (Saucy et Mondala, 1998)
Type de robot : Un robot mobile miniature, type Khepera .
Applications : Navigation avec évitement d’obstacles.
Performances :
– l’utilisateur spécifie la position et la vitesse du robot et les envoie ensuite pour
l’exécution.
– Le système utilise deux caméras vidéo (une externe et l’autre embarquée sur le
robot).
– L’utilisateur peut contrôler la caméra externe (orientation et zoom).
– Les images vidéo envoyées sont de type JPEG.
Limites :
– Le serveur d’images utilise une technique de compression qui est supporté unique-
ment par le navigateur ” Netscape ”.
– Un seul retour vidéo est possible à un instant donné (caméra externe ou embarquée).
– Le système tourne sous un système d’exploitation Windows 95 qui n’est pas stable
(n’est pas fait pour ce genre d’application), ce qui oblige à redémarrer le serveur à
chaque fois.
– Pas d’autres superviseurs possibles lorsque le système est en cours d’utilisation.
1.4.4 Xavier
Lieu et auteurs : USA - Pittsburgh, (Simmons, 1998)
Performances :
– Le robot est autonome et capable de recevoir des commandes vocales.
– Une caméra embarquée sur le robot permet de visualiser ce que voit le robot.
– L’utilisateur choisi des tâches de haut niveau prédéfinies par le système.
Limites :
– Le système retourne des informations de position et d’orientation toutes les 5 à 10
secondes ainsi qu’une image vidéo (de type GIF) toutes les 20 secondes.
– Le système supporte un seul client (utilisateur) à chaque fois.
1.4.5 RHINO
Lieu et auteurs : Allemagne, (Schulz et al., 1998)
Performances :
– Le robot est autonome.
– L’interface du système utilise la réalité virtuelle (le robot est modélisé et l’environ-
nement est semi-modélisé).
– Deux caméras réelles sont utilisées, une embarquée sur le robot permettant de vi-
sualiser ce que voit le robot et une autre caméra fixe qui visualise le robot dans son
environnement.
27
– Deux caméras virtuelles sont utilisées de la même façon que les réelles. Elles per-
mettent à l’utilisateur d’observer le déplacement du robot virtuel comme résultat
de l’exécution de la tâche.
Limites :
– Pas de retour vidéo pendant le déplacement du robot.
– L’interface utilisateur (simulation virtuelle) est basé sur des librairies ”OpenGL”
qui ne sont pas supportées par défaut par les navigateur Internet.
– Le système supporte un seul utilisateur à chaque fois.
1.4.6 PumaPaint project

Lieu et auteurs : USA - Pennsylvanie, (Stein, 1998)
Type de robot : Un bras manipulateur PUMA 760.
Application : Peinture.
Performances :
– Le bras manipulateur est capable de reproduire un dessin réalisé par un utilisateur
depuis une interface de dessin dédiée (qui ressemble à celle de “paintbrush sous
windows”.
– Il exite 4 couleurs (rouge, vert, bleu et jaune) et un pinceau pour chaque couleur.
Suivant la couleur et la trajectoire dessinée, le bras manipulateur va prendre le bon
pinceau et reproduire la trajectoire réalisée par l’utilisateur.
– Après chaque tâche l’utilisateur peut visualiser le résultat en choisissant une des
deux caméra dédiée pour ce retour vidéo.
Limites :
– Pas de retour vidéo pendant la réalisation de la tâche.
– Le système supporte un seul utilisateur à chaque fois.
1.5 Bilan
Ce premier chapitre nous a permis d’une part, de présenter les différents aspects
du télétravail ainsi que les méthodes et les tendances technologiques qui contribuent
énormément à son évolution. D’autre part, nous avons identifié les grandes lignes de
notre problématique, à savoir :
Quels sont les outils logiciels et matériels nécessaires pour la mise œuvre d’un
système de télétravail ?
Comment intégrer les nouveaux concepts et les solutions déjà apportées aux problèmes
liés à la télérobotique, sur une plate-forme universelle et à moindre coût ?
Comment rendre l’utilisation des systèmes de télétravail suffisamment souple et
intuitive pour l’opérateur, et quels types d’assistances peut on lui apporter afin
d’améliorer ses performances ?
Peut on construire une architecture client/serveur supportant un travail coopératif
et sous quelles contraintes ?
Quels sont les avantages que peut fournir les systèmes de télétravail en particulier
en utilisant le réseau Internet comme moyen de communication ?
28
1.5. BILAN
D’une manière précise, ce premier chapitre nous a permis, d’analyser les systèmes de
téléopération et de téléprogrammation de robots existants, les méthodes et les techniques
utilisées pour pallier les problèmes liés à la télérobotique en général et enfin d’analyser
les récents travaux concernant le contrôle de systèmes robotiques via Internet.
Après ces nombreux précédents efforts, certains peuvent se demander, quelle est l’ori-
ginalité du travail que nous proposons ? Quelles sont les contributions scientifiques et
techniques apportées à l’issue de ce travail ?
Dans les chapitres qui vont suivre, nous tentons de répondre à ces deux inévitables
questions ainsi qu’aux différentes problématiques posées.
Dans le chapitre suivant, nous proposons quelques outils d’assistance pour le télétravail.
Ces outils sont basés sur une approche d’assistance graphique et bénéficient de l’avantage
d’être paramétrables. Ils sont généralement destinés pour l’assistance à la téléopération
de robots.
29
30
Chapitre 2
L’assistance graphique pour le Télétravail
Le premier chapitre nous a présenté la notion de télétravail en général et les outils

technologiques dont dépend l’évolution de cette forme de travail à distance et en par-
ticulier l’outil Internet. Nous avons aussi présenté des cas particuliers de télétravail qui
sont la télérobotique et plus particulièrement la téléopération, nous avons à cette occa-
sion montré l’intérêt de la réalité virtuelle pour contourner certains problèmes comme
les inévitables retards de communication par exemple. Nous avons cependant dégagé cer-
taines problématiques auxquelles nous nous attachons dans cette thèse.
Dans ce chapitre, nous proposons des solutions aux problèmes d’assistance à l’opérateur
pour le télétravail, en particulier l’assistance à la téléopération d’un robot.
Dans la première section de ce chapitre, nous présentons un bref état de l’art sur les
métaphores graphiques. Nous verrons comment elles sont utilisées suivant les auteurs et
suivant les champs d’application.
Dans la deuxième section, nous présentons les différentes méthodes, géométriques et

analytiques utilisées pour la construction, la représentation et la manipulation des objets
virtuels en général. D’autre part, nous verrons comment ces objets virtuels sont trans-
formés en de véritables outils d’assistance pour la téléopération via Internet.
Afin de rendre ces outils facilement configurables par un opérateur un formalisme est
proposé et implanté. La structure générale de ce formalisme est présentée à la fin de ce
chapitre.
2.1 Les métaphores graphiques : Bref état de l’art

Parmi les apports de la réalité virtuelle à la téléopération, nous pouvons citer les
métaphores graphiques connues sous le nom des guides virtuels de l’anglais virtual fixtures
(Rosenberg, 1992) (Rosenberg, 1993), ou encore les mécanismes virtuels (Brooks et Ince,
31
CHAPITRE 2. L ASSISTANCE GRAPHIQUE POUR LE TELETRAVAIL
1992) voir aussi (Fraisse, 1994) (Joly et Andriot, 1995) (Kosuge et al., 1995) pour la
commande en force d’un robot. Ces accessoires virtuels facilitent les déplacements ou
les saisies d’objets dans les phases de modélisation ou de génération de trajectoires qui
s’appliqueront ensuite au robot.
2.1.1 La métaphore des mécanismes virtuels

Les mécanismes virtuels peuvent être considérés comme un ensemble d’éléments simples
tels qu’une compliance, une rotation, une composante de glissement, etc. de telle sorte
que les contraintes imposées au mouvement satisfassent la tâche à réaliser. Les avantages
d’un contrôleur basé sur les mécanismes virtuels sont principalement les suivants :
Le mécanisme exprime une relation directe entre la trajectoire désirée du manipu-
lateur et les forces externes qui lui sont appliquées par l’environnement virtuel.
Par un mécanisme virtuel on peut définir un système de coordonnées qui convient
spontanément à la tâche à laquelle il sera attribué.
En utilisant un mécanisme virtuel passif, on peut établir une commande stable si
l’opérateur et l’environnement virtuel sont passifs.
Dans (Kosuge et al., 1995), un exemple d’utilisation de mécanismes virtuels pour la
télémanipulation est donné par la Figure 2.1
Fig. 2.1 – les mécanismes virtuels pour la télémanipulation : A gauche, la structure avec
les coordonnées cylindriques (x, r, θ1 ) et l’impédance mécanique attachée au bout de l’outil
(θ2 , θ3 , θ4 ) qui permet le suivi de surface. A droite, un mécanisme virtuel associé à la tâche
d’assemblage de la boı̂te saisie par le robot.
Dans (Joly et Andriot, 1995), le principe des mécanismes virtuels est appliqué à la
fois au dispositif maı̂tre et au robot. Ainsi, le retour d’effort vers le dispositif maı̂tre et la
commande du robot se font à partir du mécanisme virtuel (voir figure Figure 2.2).
32
2.1. LES METAPHORES GRAPHIQUES : BREF ETAT DE L ART
Fig. 2.2 – Téléopération basée sur le concept de mécanismes virtuels (d’après Joly et
Andriot 95
Dans une philosophie voisine des mécanismes virtuels, un nouveau paradigme est pro-
posé dans [Backes et al. 96]. L’opérateur téléopère une trajectoire au lieu de téléopérer un
robot. Le robot esclave sera alors contraint de suivre cette trajectoire durant ou après son
établissement. Ces trajectoires sont nommées “chemins guides” (“motion guides”). Elles
sont modifiables en ligne (durant la téléopération) ou hors ligne (durant la programmation
de la trajectoire). Pendant que le robot suit une trajectoire, les commandes de l’opérateur
sont du type : avant, arrière ou arrêt. Sur la trajectoire définie, des flèches visualisent le
sens de déplacement du robot. Sur la trajectoire, on peut placer des tâches (“task lines”)
qui sont un traitement particulier à effectuer à un endroit précis du chemin guide. Le tout
est implanté dans un environnement complètement virtuel. Les prédicteurs graphiques et
la téléprogrammation intègrent aussi cet aspect dans l’interface homme - machine.
Dans (Thibout, 1996), la notion de mécanisme virtuel est utilisée pour définir des outils
virtuels (Figure 2.3) utilisés dans un atelier virtuel. On parlera alors de la métaphore
de la boı̂te à outils virtuels (Figure 2.4).
Le concept est très intéressant pour l’assistance en téléopération. Toutefois, il n’existe
pas encore une méthodologie uniforme pour l’intégration de ce concept dans une interface
de téléopération. La mise en œuvre paraı̂t assez complexe, car les mécanismes virtuels
sont conçus pour des tâches spécifiques.
2.1.2 La métaphore des guides virtuels

les recherches effectuées par Louis Rosenberg (Rosenberg, 1992) et (Rosenberg, 1993)
à l’Université de Stanford, ont consisté à trouver un moyen permettant d’améliorer les
performances d’un opérateur humain lors des tâches de télémanipulation avec délai. Il a
introduit pour la première fois le concept de guides virtuels (“Virtual Fixtures”) qu’il a
ensuite expérimenté sur un système de téléprésence (figure 2.5). L’opérateur contrôle le
robot réel via un exosquelette pour réaliser des tâches d’insertion (il s’agit de déplacer
une tige depuis un trou vers un autre trou).
Les guides virtuels utilisés par le système pour assister l’opérateur dans sa tâche sont
donnés dans la figure 2.6. L’opérateur peut sentir la présence de ces guides grâce à un
retour haptique et/ou auditif.
Il a montré qu’en utilisant ces guides virtuels on peut améliorer les performances de
ce type de tâche jusqu’à 70 %.
33
Fig. 2.3 – Exemple d’outils virtuels : en haut, des champs de force répulsifs pour
l’évitement de zones dangereuses ; en bas, des mécanismes virtuels à placer sur l’effec-
teur du robot pour guider ses mouvements (ici la rotule pour le blocage des translations,
la glissière pour le suivi de droite et de pivot)
Fig. 2.4 – La métaphore de la boı̂te à outils virtuels
34
Fig. 2.5 – le système de téléprésence utilisé pour tester les performances de l’opérateur
lors des tâches d’insertion avec ou sans l’aide des guides virtuels
Fig. 2.6 – Exemples de guides virtuels projetés dans la zone de manipulation pour assister
l’opérateur dans des tâches d’insertion d’après Rosenberg
35
D’autres recherches ont été effectuées dans le laboratoire GRASP (General Robo-
tics and Active Sensory Perception) de l’université de Pennsylvanie (Sayers et Paul,
1994). L’opérateur travaille avec une représentation virtuelle du robot distant. Les actions
réalisées dans ce monde virtuel sont observées ensuite envoyées sous forme de séquences
d’instructions au robot réel. L’opérateur utilise un petit bras maı̂tre Puma 250 comme
dispositif d’entrée/sortie (envoi des ordres au robot virtuel ou réception des retours d’ef-
forts). Le retour visuel est fourni par la simulation virtuelle qui dans ce cas utilise le
modèle virtuel du bras esclave Puma 560 (figure 2.7).
Fig. 2.7 – Le système de téléprogrammation utilisé par Sayers : A gauche, le site maı̂tre ;
A droite le site esclave.
La figure 2.8 montre quelques guides virtuels utilisés par ce système lors de l’expérim-
entation.
Une autre utilisation des guides virtuels pour une assistance à l’opérateur est donnée
par Kheddar (Kheddar, 1997), voir la figure 2.9 ou encore la figure 2.10.
La notion de guides virtuels initialement introduite par Rosenberg pour assister l’opéra-
teur, peut être décomposée en trois classes dont la classification est représentée par la
figure 2.11 :
Les guides virtuels dédiés exclusivement à l’assistance de l’opérateur :
On y regroupera toutes les métaphores graphiques dont la fonction n’a pas de lien
direct avec le robot esclave. A titre d’exemple des marqueurs de position, les divers
substituts visuels ou autres dont le rôle sera orienté vers une assistance à l’accom-
plissement de la tâche virtuelle sans effet direct sur le robot.
Les guides virtuels dédiés exclusivement à la commande du robot : On
y regroupera les mécanismes virtuels ou tout autre artifice nécessaire à la stricte
exécution d’une tâche.
Les guides virtuels partagés dédiés à la fois à l’assistance de l’opérateur
et à une exploitation de l’autonomie des robots : C’est une extension des
virtual fixtures introduites par Rosenberg. Bien que le concept dans l’esprit de cet
auteur s’applique à la téléopération pour faciliter le pilotage du robot esclave et qu’il
soit déjà largement utilisé dans les systèmes de téléopération assistée par ordinateur
(Coiffet et Gravez, 1991). Burdea et Coiffet (Burdea et Coiffet, 1994) proposent
de l’exploiter sous une forme voisine pour le robot autonome. On peut répartir ces
guides en trois sous classes :
Les guides virtuels partagés à fonctions autonomes : Cette catégorie
de guides engendre une exécution autonome de la tâche virtuelle à la fois pour
36
Fig. 2.8 – exemple de guides virtuels d’assistance à l’opérateur proposés par Sayers en
1994 : Première ligne, guide virtuel point-point pour déplacer la pointe de l’effecteur
jusqu’à un point dans l’espace et ensuite effectuer des rotations ; Deuxième ligne, pour le
suivi de zones circulaires ; Troisième ligne, pour effectuer un contact surface-surface.
MAIN VIRTUELLE
Guide virtuel
Guide virtuel
Fig. 2.9 – Guides virtuels dédiés exclusivement à l’assistance de l’opérateur. Une projec-
tion du repère du pouce sur le sol permet un guidage plus précis pour saisir ou manipuler
les objets virtuels.
37
1 2 3 4
Main virtuelle
Manche
Guides virtuels
d’assistance à l’opérateur
Pièce A
Guide virtuel à
assistance partagée Robot plan
Table
Manipulation
Ajustement
Saisie
Prehenseur autonome
a 2 doigts des axes
Fig. 2.10 – Exemple d’application des guides virtuels. Ajustement d’un préhenseur limité
en capacité d’ouverture monté sur un robot plan de type SCARA. Cette figure illustre
aussi les transformations entre l’action de l’opérateur et le robot intermédiaire de trans-
formation.
Fig. 2.11 – Classification de la métaphore des guides virtuels.
38
INTERNET
l’opérateur et pour le robot. L’exécution autonome est une aide à l’opérateur
dans le sens où la tâche virtuelle se fait toute seule. Elle constitue en même
temps une exploitation de l’autonomie du robot.
Les guides virtuels partagés à fonctions semi autonomes : Dans ce
cas l’opérateur effectue la tâche virtuelle sans assistance implicite. Le résultat
de cette exécution engendre un fonctionnement autonome du côté du robot
seulement.
Les guides virtuels partagés à fonctions de collaboration : C’est une
autre version des guides à fonctions semi autonomes. Dans ce cas l’interprétation
de la métaphore donne lieu à un fonctionnement robotique issu d’une combi-
naison d’une fonction autonome exécutée par un robot virtuel et d’une fonction
représentant l’action de l’opérateur.
2.2 Les guides virtuels pour l’assistance au télétravail

via Internet
2.2.1 Les méthodes de construction des guides virtuels
Afin de permettre à l’utilisateur d’accomplir un grand nombre de tâches à l’aide des
guides virtuels, nous lui proposons un large choix de guides :
– Différents types de surface, qui peuvent être utilisées pour ne pas franchir certaines
limites (plan, disque, etc.)
– Des volumes ouverts, qui peuvent être traversés par le robot. (cube ouvert, cylindre,
tube, etc.)
– Des volumes fermés, qui peuvent servir à définir le champs d’action du robot ou bien
englober certaines parties de l’environnement dans le but de les rendre inaccessibles.
(sphère, superquadriques, (Crespin, 1999), (Pira, 1998), (Blanc et Schlick, 1996) etc.)
– Des courbes qui peuvent servir de trajectoires au robot. (BSplines, (Peroche et al.,
1988) et (Foley et al., 1990) etc.)
Ces guides sont construits par discrétisation de leur équation : on prend des points
que l’on considère comme significatifs sur la surface du guide. Il suffit ensuite de relier ces
points pour obtenir une représentation “fil de fer” du guide.
Si on possède une équation paramétrée du guide du type :
⎡ ⎤
x
⎣ y ⎦ = f (η, ω). (2.1)
z
Les sommets du modèle filaire de l’objet seront les valeurs prises par la fonction f en
des points équi-répartis sur son domaine de définition. Et les arêtes seront définies par
l’ordre dans lequel les points ont été calculés.
Par exemple, pour une superellipsoı̈de (cf. § 2.2.1.2), on a :
⎛ ⎞
a1 cos(η)ε1 cos(ω)ε2
f (η, ω) = ⎝ a2 cos(η)ε1 sin(ω)ε2 ⎠ (2.2)
a3 sin(η)ε1
39
où (η, ω) [0, π2 ]

Alors les sommets du modèle seront les points Mi,j tels que :
π π
Mi,j = f (i ,j ) (2.3)
2n 2n
avec (i, j) [0, n] et où n définit le pas de la discrétisation.

Les arêtes seront alors les couples (Mi,j , Mi+1 , j) et les couples (Mi,j , Mi,j+1) (avec la
convention : n + 1 = 0).
Dans ce qui suit nous présentons brièvement les théories inhérentes à la manipulation
de la famille des superquadriques et des B-Splines avec pour objectif d’appliquer ces
outils à la création de guides virtuels en 3 dimensions. Les superquadriques permettent
de générer plusieurs types d’objets dans l’espace (sphère, cube, tore, etc.) à partir d’une
même formule. Un autre point de vue pour construire des objets est celui des B-Splines :
elles permettent de créer des objets modifiables localement.
2.2.1.1 Les Coniques et les superconiques
2.2.1.1.a Les coniques :
Les coniques sont une famille de courbes 2D dont l’équation générale peut se mettre
sous la forme :
x2 (1 − e2 ) + y 2 − 2px + p2 = 0 (2.4)
Elles se regroupent en trois sous-familles :
1. Si e = 1 L’équation devient
y 2 − 2px + p2 = 0 (2.5)
la courbe est nommée parabole Figure 2.12.
Fig. 2.12 – Exemple d’une parabole générée par la famille des coniques
2. Si e = 1 L’équation devient
p p
y 2 = (e2 − 1)(x − )(x − ) (2.6)
1+e 1−e
(a) Si e > 1, la courbe est nommée hyperbole (Figure 2.13 a)
(b) Si e < 1, la courbe est nommée ellipse (Figure 2.13 b)
40
INTERNET
(a) (b)
Fig. 2.13 – Exemple d’hyperboles et d’ellipse générées par la famille des coniques
2.2.1.1.b Les superconiques :
Une superconique est obtenue en appliquant une fonction de poids aux termes trigo-
nométriques de l’équation polaire d’une conique. Notons fp cette fonction de poids. Elle
est définie par :
∀t ∈ [−1, 1], fp (t) = sign(t)|t|p (2.7)
où p ∈ R+
L’équation paramètrique polaire d’une ellipse est :
x = a cos(θ)
∀θ ∈ [−π, π], (2.8)
y = b sin(θ)
On en déduit donc l’équation paramètrique polaire d’une superellipse :
x = afp (cos(θ))
∀θ ∈ [−π, π], (2.9)
y = bfp (sin(θ))
La Figure 2.14 montre quelques exemples obtenues par une superconique.
Fig. 2.14 – Exemple de superellipses, de haut en bas et de gauche à droite avec p=0.38,
0.78, 1, 1.78, 2, 3 et 6
41
2.2.1.2 Les superquadriques
Une superquadrique est définie comme le produit1 de deux superconiques. On peut

les regrouper en trois familles : les superellipsoı̈des, les supertoroı̈des et les superhyper-
boloı̈des.
2.2.1.2.a Les superellipsoı̈des :
Une superellipsoı̈de est le produit sphérique de deux superellipses de même centre.

Voici donc l’équation en coordonnées polaires (η, ω) d’une superellipsoı̈de E :
⎛ ⎞
x
⎝ cos(η)ε1 a1 cos(ω)ε2
E(η, ω) = y ⎠= ⊗ (2.10)
a3 sin(η)ε1 a2 sin(ω)ε2
z
Soit : E(η, ω) = f (η, ω) décrite dans l’équation 2.2.

Le domaine de définition D de l’équation en coordonnées polaires d’une super-ellipsoı̈de
E peut être mis sous la forme :
D = D(ε1) × D(ε2 ) (2.11)

où :
[0, 2π] si ε ∈ N avec i = 1, 2

D(εi) = (2.12)
]0, π2 [ sinon
Les figures 2.15, 2.16 et 2.17 montrent quelques exemples de guides virtuels qui peuvent
être obtenus avec une superellipsoı̈de.
Fig. 2.15 – ellipsoı̈des avec ε1 = ε2 = 1, a1 = a2 = a3 etε1 = ε2 = 1, a1 > a2 > a3
2.2.1.2.b Les supertoroı̈des :
Un supertoroı̈de est le produit sphérique de deux superellipses de centres distincts.

Voici donc l’équation en coordonnées polaires (η, ω) d’un super-toroı̈de T :
1
Produit sphérique : si p(u) = (xp (u), yp (u)) et q(v) = (xq (v), yq (v)) sont deux courbes du plan,
alors on définit le produit sphérique de p par q par la courbe de l’espace s telle que s(u, v) =
(xp (u)xq (v), xp (u)yq (v), yp (u))
42
INTERNET
Fig. 2.16 – ellipsoı̈des avec ε1 = 1, ε2 = 2; ε1 = 0.1, ε2 = 1; ε1 = ε2 = 0.35
Fig. 2.17 – ellipsoı̈des avec ε1 = ε2 = 3; ε1 = ε2 = 2; ε1 = 3, ε2 = 2
⎛ ⎞
x
a4 + cos(η)ε1 a1 cos(ω)ε2
T (η, ω) = ⎝ y ⎠ = ⊗ (2.13)
a3 sin(η)ε1 a2 sin(ω)ε2
z
Soit : ⎛ ⎞ ⎛ ⎞
x a1 (a4 + cos(η)ε1 ) cos(ω)ε2
T (η, ω) = ⎝ y ⎠ = ⎝ a2 (a4 + cos(η)ε1 ) sin(ω)ε2 ⎠ (2.14)
z a3 sin(η)ε1
On remarque que le domaine de définition d’un supertoroı̈de est le même que celui
d’une superellipsoı̈de, car en prenant a4 = 0 dans l’équation paramétrique d’un super-
toroı̈de, on obtient l’équation paramétrique d’une superellipsoı̈de.
Les figures 2.18 et 2.19 montrent quelques exemples de guides virtuels que l’on peut
obtenir avec des supertoroı̈des.
Fig. 2.18 – supertoroı̈des avec ε1 = ε2 = 1, ε1 = ε2 = 0.5
43
Fig. 2.19 – supertoroı̈des avec ε1 = 3, ε2 = 1; ε1 = 1, ε2 = 3; ε1 = ε2 = 2
2.2.1.2.c Les superhyperboloı̈des :
Les superhyperboloı̈des sont une autre famille de superquadrique. Elles n’ont pas été
implémentées dans l’application en raison de leur difficulté de représentation et du peu de
type de figure qu’elles génèrent. Voici, à titre indicatif, les équations paramétriques des
superhyperboloı̈des à une et deux nappes.
– Les superhyperboloı̈des à une nappe :
⎛ ⎞ ⎛ 1 ε1 ⎞
x a1 cos(η) cos(ω)ε2
H1 (η, ω) = ⎝ y ⎠ = ⎝ a2 cos(η) 1 ε1
sin(ω)ε2 ⎠ (2.15)
z a3 tan(η) ε 1
– Les superhyperboloı̈des à deux nappes :

⎛ ⎞ ⎛ 1 ε1 1 ε2 ⎞
x a1 cos(η) cos(ω)
H2 (η, ω) = ⎝ y ⎠ = ⎝ a2 cos(η)
1 ε1
tan(ω)ε2 ⎠ (2.16)
z a3 tan(η)ε1
2.2.1.3 Les B-Splines
Nous souhaitons permettre à l’utilisateur de définir facilement une surface quelconque.

Une première approche serait de lui faire entrer un échantillon de points appartenant
à cette surface et de procéder par interpolation. Mais le nombre de points nécessaires
à l’obtention d’un résultat convenable sera alors élevé. Une autre méthode consiste à
procéder par lissage : les points fournis par l’utilisateur seront des points de contrôle qui
n’appartiendront pas forcément à la courbe mais qui permettront de modifier la forme de
celle-ci. Les courbes et surfaces de Bézier et des B-Splines sont basées sur un tel principe.
2.2.1.3.a Les courbes de Bézier :
Si on note (Pi )i∈[0,d] les points de contrôle, la courbe de Bézier associée à ces points
est définie par :
d
P (t) = Pi Bi,d (t) (2.17)
i=0
où :
d!
Bi,d (t) = Cid ti (1 − t)d−i avec Cid = (2.18)
i!(d − i)!
44
INTERNET
Voici un exemple de courbe de Bézier :
P
p 3
P
p 2
P
p 1
2.2.1.3.b Les surfaces de Bézier :
Les surfaces de Bézier peuvent se définir à partir des courbes de Bézier : si on note
(Pi,j )i∈[0,n],j∈[0,m] les points de contrôle, alors la surface de Bézier est définie par :
n m
P (s, t) = Pi,j Bi,n (s)Bj,m(t) (2.19)
i=0 j=0
2.2.1.3.c Les courbes B-splines :
Les courbes de Bézier présentent deux inconvénients :
– Le changement d’un seul point de contrôle modifie entièrement la courbe.

– Le degré du polynôme obtenu augmente avec le nombre de points de contrôle
Voici donc une autre méthode qui permet de modifier localement la courbe à l’aide des
points de contrôle et d’avoir une complexité indépendante du nombre de points de contrôle.
Si on note (Si )i∈[0,d] les points de contrôle, la courbe B-spline de degré k associée à ces
points est définie par :
d
P (t) = Si Ni,k (t) (2.20)
i=0
où :
– Ni,1 (u) = 1 si ti ≤ u ≤ ti+1
– Ni,1 (u) = 0 sinon
ti+k −u
– Et pour k = 0, Ni,k (u) = ti+k−1u−ti
N
−ti i,k−1
(u) + ti+k N
−ti+1 i+1,k−1
(u)
Les (ti )i∈[0,d+k] étant des réels quelconques. Ici, nous avons pris :
– ti = 0 si i < k
– ti = i − k + 1 si k ≤ i ≤ d
– ti = d − k + 1 si i ≤ d + k
2.2.1.3.d Les surfaces B-splines :
De manière analogue aux surfaces de Bézier, on définit une surface B-Spline ayant pour
points de contrôle les (Pi,j )i∈[0,n],j∈[0,m] par :
n m
P (s, t) = Pi,j Ni,k (s)Nj,l (t) (2.21)
i=0 j=0
45
avec k et l les degrés des deux courbes B-Splines asociées à leurs points de contrôle.
En fixant le nombre de points contrôle de la surface à 16 points, on peut expliciter
matriciellement l’équation de la surface B-Spline :
⎧
⎨ x(s, t) = S.MBs .GBsx .MBs
t
.T t
t
y(s, t) = S.MBs .GBsy .MBs .T t (2.22)
⎩
z(s, t) = S.MBs .GBsz .MBs .T t
t
Avec :
T = t3 t2 t 1 (2.23)

S= s3 s2 s 1 (2.24)
⎛ ⎞
−1 3 −3 1
1⎜ 3 −6 3 0 ⎟
MBs = ⎜ ⎟ (2.25)
6 ⎝ −3 0 3 0 ⎠
1 4 1 0
et ⎛ ⎞
P11 P12 P13 P14
⎜ P21 P22 P23 P24 ⎟
GBs =⎜
⎝ P31
⎟ (2.26)
P32 P33 P34 ⎠
P41 P42 P43 P44
Dans le cas où l’on ne possède pas d’équation paramétrée du guide que l’on veut
créer, on n’a pas de méthode générale et nous avons implanté des méthodes au cas par
cas. Par exemple, pour un cylindre, nous discrétisons les deux extrémités (ouvertures)
du cylindre par la méthode vue ci-dessus, puis nous relions les points qui se font face à
chaque extrémité.
La figure 2.20 montre des exemples de guides virtuels obtenus par ces méthodes :
Fig. 2.20 – Cône, Cylindre, tube, cube, disque et plan
2.2.2 Représentation et manipulation des guides virtuels sur

écran
Après avoir vu comment créer des guides virtuels, nous allons maintenant voir com-
ment les représenter sur écran et permettre de les désigner et de les manipuler avec la
46
INTERNET
souris. Nous présentons le modèle de projection des données 3D sur écran, nécessaire aux
méthodes d’extraction de la 3D à partir de points 2D et celles de détection de collision
entre le robot et son environnement, que nous décrivons par la suite.
2.2.2.1 Le modèle de la caméra graphique
Le modèle de la caméra graphique est une matrice M qui permet de transformer les
coordonnées (xo , yo, zo ) d’un point dans le repère objet (Ro ) (figure 2.21) en coordonnées
u et v d’un point de l’écran. Ce modèle résulte du produit de plusieurs matrices : mise à
l’échelle et translation d’origine, projection perspective et matrice de passage du repère
(Ro ) au repère (Rc ) (cf. § 3.2.2 pour une description détaillée concernant la modélisation
de la caméra). Cette matrice est de la forme :
⎡ ⎤
c11 c12 c13 c14
M = ⎣ c21 c22 c23 c24 ⎦ (2.27)
c31 c32 c33 c34
V
B
vo
U
Xo
Zo
uo
O O Yo
b (Ro)
f
Ecran
X Z
C Y
(Rc)
Fig. 2.21 – Représentation simplifiée de la projection perspective, f étant la focale.
Ainsi, un point (x0 , y0, z0 ) de l’espace est représenté sur l’écran par le point de coor-
données (u, v) telles que :
⎡ ⎤
x0 ⎡ ⎤
⎢ y0 ⎥ s × u
M ×⎢ ⎥ ⎣
⎣ z0 ⎦ = s × v
⎦ (2.28)
s
1
2.2.2.2 Sélection d’un objet de l’espace sur l’écran
L’utilisateur doit avoir la possibilité de manipuler ces objets virtuels (pour les placer
convenablement, par exemple), il est nécessaire qu’il puisse les sélectionner en les désignant
sur écran. Cette désignation (clic avec la souris par exemple) se traduit en coordonnées
(u, v) du point de l’écran où ce clic a eu lieu. Il faut donc déterminer quel objet l’utili-
sateur à voulu désigner par ce clic. Les coordonnées (u, v) correspondent à une droite D,
47
d’équation : ⎡⎤
x ⎡ ⎤
⎢ y ⎥ s×u
(x, y, z) ∈ D ⇐⇒ ∃s, M × ⎢ ⎥ ⎣
⎣ z ⎦= s×v
⎦ (2.29)
s
1
Ensuite, il ne reste qu’à calculer quel objet possède le point qui est à la plus petite distance
de cette droite. Par exemple dans la figure 2.22, c’est l’objet 3 qui a été sélectionné (le
modèle 3D de cet objet étant connu).
Objet
V 1
(D)
U Objet
2
Objet
3
point séléctionné Xo
Zo
f
Ecran
(Ro) Yo
X Z O
C Y
(Rc)
Fig. 2.22 – Exemple de sélection d’un objet virtuel sur écran
2.2.2.2.a Déformations des guides virtuels :

Les objets proposés à l’utilisateur sont des objets élémentaires (cylindre, plan, sphère,
etc.) et il se peut que ces objets ne conviennent pas à l’environnement de travail, c’est
pourquoi nous souhaitons permettre une déformation de ces objets afin que l’on puisse
créer des guides qui s’adaptent à des environnements complexes. Le type de déformation
qui convient le mieux à nos attentes est la déformation locale puisqu’elle permet de mo-
difier le guide uniquement là où il y a problème. Le principe de cette déformation est de
donner l’impression à l’utilisateur qu’il peut “étirer” un point de l’objet.
On peut représenter un objet par une liste ordonnée de ses sommets et une liste des
couples de sommets qui forment une arête. Ainsi, ce cube de côté 1 mètre (figure 2.23)
peut être representé par :
(0, 0, 0), (0, 1, 0), (1, 1, 0), (1, 0, 0), (0, 0, 1), (0, 1, 1), (1, 1, 1), (1, 0, 1)
et
(1, 2), (2, 3), (3, 4), (4, 1), (5, 6), (6, 7), (7, 8), (8, 5), (1, 5), (2, 6), (3, 7), (4, 8)
Ainsi, on peut associer à un objet un graphe G = (X, U) où X est un ensemble dont
les éléments sont appelés sommets et U ⊂ X × X est un ensemble dont les éléments
sont appelés arcs. On peut alors définir l’application V qui à tout sommet x de X associe
l’ensemble de ses voisins, c’est à dire :
48
INTERNET
6
7
3 2
5
8
1
4
Fig. 2.23 – Exemple d’un cube avant déformation
V (x) = {u ∈ X|(u, x) ∈ U ou (x, u) ∈ U}
On appellera, d(x, y) la distance du sommet x au sommet y définie par :
d(x, y) = min{i ∈ N|y ∈ V i (x)} (2.30)
Si on appelle x0 le point de départ de la déformation et ∆0 la valeur de cette déformation,

on a :
∀x ∈ X|∆(x) = pf d(x,x0 )−1 ∆0 (2.31)

où p est appelé facteur de propagation initial et f facteur de dégradation de la propagation.
Exemple : Si on prend x0 =1, ∆0 = (1, 0, 0), p = 1 et f = 0.5 alors :
∆(2) = ∆(4) = ∆(5) = (1, 0, 0) ; ∆(3) = ∆(6) = ∆(8) = (0.5, 0, 0) et ∆(7) = (0.25, 0, 0)
On obtient donc :
7 6
8 5
2
3
1
4
Fig. 2.24 – Résultat de la déformation sur le cube
Pour effectuer la déformation, nous avons vu que nous avons besoin d’un point ini-
tial (x0 ), d’une déformation initiale (∆0 ), du facteur de propagation initial et du facteur
de dégradation de la propagation. Les deux derniers facteurs peuvent être demandés à
l’utilisateur à l’aide d’une interface. Mais, pour faciliter l’utilisation des déformations,
nous souhaitons que l’utilisateur sélectionne avec la souris le point de l’objet à considérer
comme initial, puis qu’il indique (sans relâcher le bouton de la souris) l’endroit où le point
49
initial doit se trouver après déformation.
La sélection du point se faisant sur écran, et donc sur un plan, il faut dans un premier
temps chercher quel point de l’objet a pour image le point sélectionné par l’utilisateur
(cf. § 2.2.2). De plus, on ne peut pas établir une bijection entre un déplacement dans le
plan de l’écran et un déplacement dans l’espace, sauf si l’on impose une condition sur les
degrés de liberté de l’objet. Ainsi, si on décide de fixer la composante en z de ∆0 à 0, tout
déplacement sur l’écran pourra être traduit en un déplacement dans l’espace. En outre,
lorsque l’objet a beaucoup de points, la valeur de la déformation pour les points éloignés
du point initial est très petite. Pour diminuer le temps de calcul, nous avons donc permis
à l’utilisateur d’imposer un seuil à partir duquel les déformations ne sont plus prises en
compte.
La figure 2.25 montre quelques exemples de déformation :
Fig. 2.25 – Plan, Cube ouvert et Cylindre : En haut, avant déformation ; En bas après
déformation avec p = 0.99 et f = 0.9
2.2.2.3 Détection des collisions
2.2.2.3.a Définition :
Pour que les guides puissent jouer un rôle autre que celui d’un simple indicateur visuel,
il faut qu’ils aient une consistance. En effet, il ne faut pas laisser l’utilisateur traverser
ces guides si par exemple ils sont supposés limiter le champ d’action. Ainsi, à chaque fois
que l’utilisateur rentrera en contact avec le guide, il faudra lui indiquer qu’il ne peut plus
avancer dans cette direction. C’est ce contact que l’on nomme “collision” (figure 2.26).
Nous avons développé deux méthodes de détection de collisions. La première est ana-
lytique, la seconde est géométrique.
50
INTERNET
Guide virtuel
Effecteur du robot Collision
Fig. 2.26 – Collision entre l’effecteur du robot et un objet guide sous forme d’une demi-
sphère
2.2.2.3.b Méthode analytique :

Cette méthode est appliquée pour détecter les collisions quand le guide n’a pas subi de
déformation. Lorsque tel est le cas, on connaı̂t alors l’équation de ce guide. Nous décrivons
ici brièvement la géométrie de quelques guides virtuels (figure 2.27), leurs paramètres
(tableau 2.1) ainsi que leurs équations (tableau 2.2).
Type du guide Paramètres du guide

Plan a, b.
Disque R.
Cube a, b et c.
Cylindre, cône et tube H, a1 et b1 , a2 et b2
Cône et tube droits H, a1 et b1 , a2 et b2
Superellipsoı̈de a1 , a2 , a3 , ε1 , ε2
Supertoroı̈de a1 , a2 , a3 ,a4 , ε1 , ε2
Tab. 2.1 – Les paramètres des guides virtuels pour la détection des collisions.
Où R représente le Rayon, H la hauteur, a1 et b1 la première ouverture (horizontale et

verticale respectivement), a2 et b2 la deuxième ouverture (voir la géométrie de ces guides
dans la figure 2.27).
Nous pouvons remarquer qu’avec ce type de méthode (disposant de l’équation du guide
virtuel), la détection des collisions entre un point représentant l’effecteur du robot et un
objet guide, peut se réduire à un test d’appartenance de ce point à l’objet guide. Cette
écriture analytique offre aussi l’avantage de rendre la détection de collision identique quel
que soit l’objet, si ce dernier est généré par une superquadrique par exemple (cf. § 2.2.1).
2.2.2.3.c La Méthode géométrique :

Lorsqu’au contraire le guide a été déformé, nous n’avons plus aucune information sur sa
nature (on ne connaı̂t pas l’équation d’un cylindre déformé par exemple). Nous pouvons
donc uniquement travailler avec l’ensemble des sommets et des arêtes qui constituent
l’objet.
Le but est de ne pas laisser le robot traverser l’objet guide, nous allons donc décider
qu’il y a collision si l’utilisateur approche de trop près le guide (en définissant un seuil).
51
Type du guide Equation du guide

Plan z=0, x ∈ [0, a], y ∈ [0, b]
Disque z = 0, x2 + y 2 ≤ R2
Cube z ∈ [0, c], x ∈ [0, a], y ∈ [0, b]
2 2
Cylindre, cône et tube x ∈ [0, H], x(a2 −a1 )+Ha1 + x(b2 −b1 )+Hb1 = H12
y z
2 2
Cône et tube droits x ∈ [0, H], x(a2 −a1 )+Ha1 + x(b2 −b1 )+Hb1 + 1 = H12
y z
ε2 ε2 εε21 ε2
2
Superellipsoı̈de x
a1
+ ay2 2 + az3 1 = 1
ε2
ε2 ε2 εε21 1 ε2
2 2 1
Supertoroı̈de x
a1
+ y
a2
− a4 + z
a3
=1
Tab. 2.2 – Les équations des guides virtuels pour la détection des collisions
b1 a1 b1 a1
H H
a b2 b2
a2 a2
c
R
a
Fig. 2.27 – La géométrie des guides : de gauche à droite : Cube, (cylindre ou cône ou
tube), (cône ou tube droits), plan, disque.
52
INTERNET
Il faut donc à tout moment calculer la distance entre le robot et les arêtes du guide. On
définit la distance entre un point M et un segment [AB] comme étant :
−−→
d(M, [AB]) = min{ MN , N ∈ [AB]} (2.32)
Ainsi, si un point “E” représente l’extrémité de l’effecteur du robot, alors, nous dirons
qu’il y a collision, si la distance du point “E” aux arêtes définissant l’objet est inférieure
à un certain seuil “d” (figure 2.28).
d d
A B
Fig. 2.28 – Zone de collision de seuil “d” autour d’un segment [AB]
Pour un seuil fixé, l’efficacité de cette méthode grandit avec le nombre d’arêtes définiss-
ant l’objet. Comme nous l’avons représenté dans la figure 2.29, si les arêtes de l’objet
sont trop espacées, il apparaı̂t des trous dans lesquels l’effecteur du robot pourra passer.
Ainsi, il faudrait augmenter le nombre d’arêtes pour avoir de meilleurs résultats, mais
cela réduirait la visibilité à l’écran (certaines parties de l’environnement seraient cachées
par le guide).
Trou
Zone de collision C
A
Arete
B
Fig. 2.29 – Existence de trous dans les guides virtuels
Le deuxième problème de cette méthode réside dans le temps de calcul. En effet, à

chaque fois que l’utilisateur veut bouger le robot, il faut calculer la nouvelle distance entre
le robot et le guide pour tester si ce mouvement provoque une collision.
Comme il est à la fois impératif que le système de détection de collision soit efficace
et que la visibilité à l’écran soit bonne, nous avons décidé d’utiliser deux objets pour un
même guide : on se servira d’un modèle avec peu d’arêtes pour représenter le guide à
l’écran et d’un modèle avec beaucoup plus d’arêtes (qui ne sera pas affiché (figure 2.30))
pour faire les détections de collisions.
Pour diminuer le temps de calcul, nous avons introduit la notion de sphère de sécurité
(figure 2.31). Lorsque le robot est en un point M0 et que l’on fait le calcul de la distance,
notée d0 entre le robot et un guide statique (fixé dans l’environnement virtuel), on sait
que tant que le robot reste dans la sphère de centre M0 et de rayon d0 il ne rentrera jamais
en collision avec le guide. Ainsi, il n’est pas nécessaire d’effectuer les calculs des distances
à l’intérieur de cette sphère. Une fois sorti de cette sphère, un nouveau calcul de distance
53
Fig. 2.30 – Modèle utilisé à l’écran (en haut) et modèle utilisé pour les calculs (en bas)
est effectué pour créer une nouvelle sphère de sécurité. Cette méthode permet de réduire
considérablement le temps de calcul des détections de collision.
sphère de sécurité
Fig. 2.31 – Exemple de sphère de sécurité
2.3 Les propriétés des guides virtuels

Dans ses recherches, Kheddar (Kheddar, 1997) a tenté de définir une structure globale
pour les guides virtuels à l’aide d’un ensemble de champs pouvant être optionnels selon
la nature et le contexte d’utilisation du guide virtuel :
– Un attachement :
Chaque guide virtuel peut être attaché à un objet virtuel ou à un endroit de l’en-
vironnement virtuel. Il peut être attaché d’une manière statique (il est alors figé
à un endroit ou attaché à un objet virtuel particulier) ou dynamique (il apparaı̂t
suite à un évènement, par exemple, lors de la détection de collisions). Ainsi, on
définit pour chaque guide une position et une orientation dans l’espace défini par
l’environnement virtuel.
– Une zone d’influence :
Au guide virtuel peut être associée une zone (de forme volumique, surfacique ou
autre) qui jouera le rôle d’un bassin d’attraction ou tout simplement d’une zone
d’action. En général, une zone d’influence est définie par une équation analytique
(statique ou paramètrée) qui délimite (totalement ou partiellement) la forme du
guide.
54
2.3. LES PROPRIETES DES GUIDES VIRTUELS
– Une condition d’activation :

A chaque guide est associé une condition d’activation. Elle peut se traduire par
l’appartenance d’un ensemble de paramètres extérieurs à la zone d’influence ou par
n’importe quelle autre condition liée à un évènement.
– Une fonction :
La fonction du guide définit sa raison d’être. Elle peut être explicitée par des actions
à établir à l’intérieur du guide virtuel.
– Une condition de désactivation :
La condition de désactivation met hors effet la fonction du guide virtuel. Elle peut
être définie comme une négation de la condition d’activation ou l’atteinte d’un état
final désiré.
L’idée d’une telle formalisation est très intéressante à l’assistance en téléopération,
surtout si on veut que les guides virtuels soient utilisés comme de véritables outils d’as-
sistance. Mais il n’existe pas encore de moyens interactifs permettant à l’opérateur de
créer ses propres guides virtuels, de les configurer, de les activer, selon la tâche qu’il désire
réaliser, ou même encore de les réutiliser. Un autre problème lié à l’utilisation de ces guides,
se situe au niveau de leurs portabilité. En effet, ces outils virtuels sont très spécifiques et
dépendent de la machine sur laquelle ils ont été créés. de même leur utilisation dépend
complètement de leur concepteur.
Dans un premier temps notre approche consiste à définir une librairie de guides virtuels
de base dont l’utilisation est limitée aux différentes tâches que nous avons prédéfinies
(atteindre une cible, saisie d’un objet, dépôt d’un objet etc.). A chaque guide virtuel est
associé des propriétés permettant à l’opérateur d’identifier ces outils et surtout de les
réutiliser pour d’autres tâches. Ensuite nous avons généralisé ce concept vers la création
interactive de guides virtuels et leur paramétrage en ligne (l’opérateur peut créer ses
propres outils virtuels et peut les paramétrer selon la tâche qu’il désire réaliser). Ceci
grâce à une interface homme-machine que nous avons développé sous l’environnement
JAVA. Ce qui donne donc à l’opérateur la possibilité de créer sa boı̂te à outils virtuels
à partir de n’importe quelle machine connectée à Internet (il s’agit donc d’une boı̂te à
outils portable et partageable).
2.3.1 La notion de guide virtuel simple et composé

2.3.1.1 Guide virtuel simple
Un guide virtuel simple est représenté par une simple primitive géométrique. Elle peut
être un segment de droite, un plan ou bien un volume défini par l’une des équations du
paragraphe cf. § 2.2.2. Ces guides canoniques sont généralement utilisés pour réaliser
des tâches simples telles que le suivi d’une ligne droite, évitement d’obstacles (des guides
virtuels actifs avec un champ répulsif) ou bien atteindre un objet dans l’environnement
virtuel (des guides virtuels actifs avec champ attractif). La figure 2.32 montre un exemple
de guide virtuel simple (primitive cône) qui peut être utilisé pour aider l’opérateur à
déplacer l’effecteur du robot jusqu’à la cible.
2.3.1.2 Guide virtuel composé
Un guide virtuel composé est constitué de plusieurs guides virtuels simples (un en-
semble de segments définissant une trajectoire, un ensemble de plans ou bien un ensemble
55
Guide virtuel simple
Cible
Fig. 2.32 – Exemple de “guide virtuel simple”, pour assister l’opérateur et/ou le robot à
atteindre une cible
d’objets de forme quelconque). L’opérateur peut créer différents types de guides cano-
niques et peut lier ces guides simples entre eux pour former un guide composé. Ces types
de guides sont généralement utilisés pour réaliser des tâches de téléopération complexes
tel que suivre une trajectoire quelconque ou bien assembler et désassembler des objets.
La figure 2.33 montre un guide virtuel composé, utilisé pour décrocher un objet depuis
son support métallique (cf. § 4.1). Il s’agit d’une combinaison de 3 guides simples (sous
forme de cylindres). Un autre exemple de guide virtuel composé est donné par la figure
2.34. Il est constitué par 2 guides simples (2 plans parallèles). Ce guide composé permet
d’aider l’opérateur et/ou un robot mobile à traverser une porte.
Guide virtuel composé
Cylindre 3 Cylindre 2
Cylindre 1
Fig. 2.33 – Exemple de “guide virtuel composé”, pour assister l’opérateur et/ou l’effecteur
du robot à suivre une trajectoire et manipuler un objet
2.3.2 Notion de guide virtuel passif ou actif

2.3.2.1 Guide virtuel passif
Un guide virtuel (simple ou composé) est dit passif lorsque son utilisation est limitée
à l’assistance à la perception de l’opérateur (il n’a pas d’effet direct sur le robot ni sur
son environnement).
2.3.2.2 Guide virtuel actif
Un guide virtuel (simple ou composé) est dit actif lorsque son utilisation a un effet
direct sur le robot ou sur son environnement. Les guides actifs peuvent se décomposer en
deux catégories :
56
Porte
Fig. 2.34 – Exemple de “guide virtuel composé”, pour assister l’opérateur et/ou un robot
mobile à traverser un porte
2.3.2.2.a Guide répulsif :

Dans ce cas, ce guide virtuel a pour rôle de générer un potentiel répulsif qui évite
au robot de le traverser. Ils peut être considéré comme une barrière (pour empêcher le
robot d’aller dans une zone interdite d’accès), une surface ou un volume protecteur (pour
protéger des objets de l’environnement avec lesquels le robot ne doit pas avoir de collisions
( figure 2.35) etc.
Un plan répulsif
Un cube répulsif
Ob jet
Fig. 2.35 – Exemple de “guide virtuel répulsif”, à gauche, une barrière et à droite, un
volume englobant répulsif
2.3.2.2.b Guide attractif :

Son rôle est de générer un potentiel attractif permettant de contraindre l’opérateur
et/ou le robot à atteindre un objet de l’environnement (figure 2.36). Il est très efficace
pour la génération de trajectoire.
57
(Vue interne du guide )

Champs attracteurs
Entrée
de l’outil
Objet à atteindre
Fig. 2.36 – Exemple de “guide virtuel attractif”, pour atteindre un objet de l’environne-
ment avec un outil porté par le robot
2.3.3 Formalisme proposé pour les guides virtuels

Nous avons vu qu’il existe de nombreuses possibilités d’utilisation des guides virtuels.
En effet, le rôle d’un guide virtuel dépend entièrement de la façon dont l’opérateur désire
l’utiliser (guide simple ou composé, statique ou dynamique, Actif ou passif, etc.). Afin de
faire face à ces nombreux cas d’utilisation et de permettre la gestion des guides virtuels,
une méthode de conception objet UML (Unified Modeling Language) a été utilisée. Cette
méthode est née en 1997 et elle propose de modéliser un système sous forme de différents
diagrammes apportant chacun sa contribution.
Dans cette partie nous présentons essentiellement le formalisme et les différents types de
données représentant les guides virtuels ainsi que les cas d’utilisation.
2.3.3.1 Structures de données proposées pour les guides virtuels
Cinq types de données ont été définis pour représenter un guide virtuel. Chaque type
de donnée est représenté dans un fichier. Ces fichiers sont générés au moment de la création
d’un guide virtuel comme le montre la figure 2.37.
Soit par exemple “nom guide”, le nom associé à un guide virtuel donné, le fichier
contenant le modèle de ce guide sera donc “nom guide.obj”, un modèle filaire faible-
ment discrétisé (avec peu de points et d’arêtes). Ce fichier est utilisé généralement pour
l’affichage sur écran et la détection de collisions si nous possédons l’équation de ce guide.
Dans le cas où nous ne disposons pas de l’équation du guide virtuel (si le guide a subi une
déformation par exemple), alors le fichier “nom guide.obj” est utilisé seulement pour
l’affichage et un autre fichier “nom guide.obj2”, un modèle fortement discrétisé (avec
beaucoup de points et d’arêtes) est utilisé pour la détection de collisions.
Les paramètres de l’équation du guide virtuel sont stockés dans un fichier “nom guide.ob-
j.equ”. Ces paramètres sont chargés en mémoire et utilisés pour le calcul des tests d’ap-
partenance d’un point 3D au guide virtuel et aussi lors de la détection de collisions entre
l’effecteur du robot et le guide en question.
Une matrice homogène contenant la position et l’orientation du guide virtuel par rap-
port au référentiel de travail, est stockée dans le fichier “nom guide.obj.mat”, elle est
58
Paramètres de Modéle géométrique
l’équation du guide pour l’affichage
.obj.equ .obj
Propriètés du guide
.obj.guide
Position et orientation Modéle géométrique

du guide pour le calcul
.obj.mat .obj2
Création du guide
X Y : Y utilise X
Crée un fichier
Fig. 2.37 – Représentation des différents types de données générés lors de la création d’un
guide virtuel
utilisée lors du chargement du guide afin de l’afficher au bon endroit.
Les propriétés du guide virtuel sont regroupées dans un fichier “nom guide.obj.guide”.
Il contient une structure de données correspondant au formalisme que nous avons utilisé et
implanté. Cette structure de données (figure 2.38) contient un certain nombre de champs
que nous avons jugé utiles pour définir les propriétés d’un guide virtuel.
– Nom guide : Permet l’identification d’un guide virtuel
– Type guide : Définit le type du guide virtuel (simple, composé, passif, actif). Si
le guide est “composé” alors il contient des liens vers le guide précédent et le sui-
vant. Dans le cas où le guide est “actif”, alors il nous informe s’il est “répulsif” ou
“attractif”.
– Référentiel : Contient des informations concernant la position et l’orientation du

guide dans son environnement virtuel.
– Attachement : Précise si le guide est “statique” ou “dynamique”. Dans le premier

cas, il contient le nom de l’objet virtuel ou du point de passage auquel il est attaché.
Dans le deuxième cas il contient la valeur “NULL” pour dire que le guide est libre.
– Zone d’influence : Contient le nom mathématique de l’équation ayant servi à la

création de ce guide ainsi que les paramètres correspondants.
D’une manière générale, l’activation d’un guide virtuel se fait par un test d’appar-
tenance d’un point (représentant l’effecteur du robot) au guide virtuel. Il s’agit d’une
“Pré-condition” (ou encore une condition d’activation). Dans ce cas le nom et les pa-
ramètres de l’équation du guide sont récupérés depuis la structure de données définissant
les propriétés de ce guide, et sont ensuite utilisés pour définir cette pré-condition. Il est
aussi possible d’activer un guide par un autre évènement comme par exemple la détection
de collisions ou encore définir une distance d’approche entre l’effecteur du robot et un
59
Exemples :
guide_saisie
^
guide_dépot
guide_navigation, etc ...
Nom_guide
Nom_guide_précédent
Simple Nom_guide_suivant
Composé
Type_guide Passif
Actif Répulsif
Attractif
Tx, Ty, Tz
Réferentiel Rx, Ry, Rz
Nom_objet_environnement
Statique Coordonnées du point de passage
Attachement Dynamique
Null
Nom_guide_math
Zone d’influence Paramètres
Fig. 2.38 – Schéma général de la structure des propriétés d’un guide virtuel
objet de l’environnement virtuel.
Une fois le guide activé, il reste à déterminer les actions ou les opérations à réaliser
en présence de ce guide virtuel, c’est ce que nous appelons la “Fonction” du guide.
Généralement cette fonction est issue d’une combinaison des actions que réalise l’opérateur
avec le robot virtuel et des fonctions définissant le type du guide. Si le guide est “pas-
sif” alors il est appelé “guide d’assistance libre”, s’il est “actif” (répulsif ou attractif)
alors il est appelé “guide d’assistance partagée ou semi-autonome”. La fonction
du guide peut aussi se limiter à l’exécution d’une fonction définie par le guide permettant
une exécution automatique de la tâche par le robot virtuel. Dans ce cas ce guide devient
“autonome” et est appelé “guide d’assistance autonome”.
La fonction du guide n’a plus d’effet sur le robot et sur l’opérateur, lorsque le robot
a atteint un état final désiré (dans le cas d’un guide d’assistance à l’opérateur et d’un
guide d’assistance partagée), ou encore la fin de l’exécution automatique de la tâche par
le robot (dans le cas d’un guide d’assistance autonome). Il s’agit de désactiver la fonction
du guide, ce qui définit la “Post-condition”.
2.3.3.2 Les cas d’utilisation
Dans la méthodologie UML l’étude des cas d’utilisation a pour objectif de déterminer
ce que chaque acteur (intervenant) attend du système. En effet dans notre cas, les acteurs
potentiels sont au nombre de trois :
– Utilisateur de guide.
– Superviseur.
– Administrateur de guide.
Le fait que l’utilisation des guides virtuels peut se faire par Internet, et par n’importe
quel client (opérateur) connecté au réseau, il est nécessaire de déterminer le statut de cet
opérateur (utilisateur, superviseur ou administrateur). Le tableau 2.3 résume ces différents
60
2.4. BILAN
cas d’utilisation. Des applications mettant en œuvre des acteurs et des guides virtuels,
sont données dans le chapitre 4.
Acteur Cas d’utilisation

Administrateur de guide Création d’un guide
Administrateur de guide Lecture d’un guide
Administrateur de guide Modification d’un guide
Administrateur de guide Sauvegarde d’un guide
Utilisateur Utilisation des guides
Superviseur Edition des propriétés d’un guide
Tab. 2.3 – Les différents cas d’utilisation des guides virtuels associés à chaque acteur.
2.4 Bilan
Dans ce chapitre, les notions de mécanisme et de guide virtuel indispensables à un
système de réalité augmentée basé sur un retour prédictif sont présentées. Nous avons aussi
présenté les méthodes analytiques et géométriques de création, de représentation et de ma-
nipulation des objets virtuels en général et en particulier des guides virtuels. Nous avons
proposé un nouveau formalisme pour les guides virtuels afin de les rendre paramétrables,
évolutifs et utilisables comme de véritables outils d’assistance à la téléopération (ce for-
malisme est implanté, des exemples sont donnés dans le chapitre 4).
Cependant, pour télétravailler sur Internet, il est nécessaire que ces outils d’assistance
soient portables et partageables (lors d’un travail coopératif par exemple). Il est aussi
nécessaire, que l’environnement virtuel (robot, objet, etc.) soit portable ainsi que tous
les autres modules utiles à la réalisation d’un système de télétravail (IHM, retour vidéo,
contrôle des robots réel et virtuel, etc.). Cette partie est présentée dans le chapitre suivant.
61
62
Chapitre 3
Le système expérimental de télétravail
proposé
Dans ce chapitre, nous étudions l’ensemble des problématiques posées dans le pre-
mier chapitre à savoir, les outils logiciels et matériels nécessaires pour la mise œuvre d’un
système de télétravail, l’intégration des nouveaux concepts et des solutions déjà apportées
aux problèmes liés à la télérobotique, sur une plate-forme universelle et à moindre coût.
Nous verrons, comment rendre l’utilisation des systèmes de télétravail suffisamment souple
et intuitive pour l’opérateur, et comment les outils d’assistance présentés dans le chapitre
précédent peuvent être utilisés pour améliorer les performances de l’opérateur lors du
télétravail.
Nous commençons ce chapitre par une présentation des caractéristiques d’un système
de télétravail idéal. Ensuite, nous présentons les méthodes nécessaires pour le contrôle en
réalité augmentée. Il s’agit des méthodes de modélisation géométrique de l’environnement
et de calibration de la caméra et du robot.
Dans la troisième section, nous présentons notre système expérimental de télétravail,

baptisé ARITI “Augmented Reality Interface for telerobotic applications via Internet”. Il
s’agit d’un système de télétravail dont la conception et la mise en œuvre est basée d’un
côté sur des techniques de la réalité virtuelle et augmentée et de l’autre côté sur l’exploi-
tation des techniques de développement réseaux et en particulier sur Internet.
Dans la quatrième section, nous présentons l’architecture réseau et les différents pro-
tocoles de communication de l’architecture client/serveur du système ARITI.
63
CHAPITRE 3. LE SYSTEME EXPERIMENTAL DE TELETRAVAIL PROPOSE
3.1 Caractéristiques d’un système de télétravail idéal

A l’issu de ce que nous avons présenté dans la première section du premier chapitre
et selon les recherches de la communauté CSCW (Bannon et Schmidt, 1989), (Schal et
Zeller, 1990) et (Greenberg, 1991), nous tentons maintenant de définir les caractéristiques
d’un système de télétravail idéal :
Convivialité :
Le système doit posséder une IHM (Interface Homme Machine) conviviale, qui peut
être utilisée facilement par des utilisateurs pas forcément spécialistes du domaine de
la robotique ou de l’informatique. plusieurs types d’assistances doivent être fournis à
l’utilisateur. Il s’agit généralement d’assistances à la perception de l’environnement
distant, à la commande du système distant (par exemple le robot ) et à la supervision
des tâches réalisées.
Multimodalité :
Le système doit pouvoir supporter l’échange d’informations multimodales entre le
site maı̂tre et le site esclave. Il s’agit d’informations Visuelle, Sonore, Tactile et
Kinesthésique.
Portabilité :
l’interface homme machine doit être portable. L’utilisateur doit pouvoir télé-travailler
depuis n’importe quelle machine connectée au réseau (en particulier au réseau In-
ternet).
Télé-coopération :
Le système doit supporter un télétravail coopératif, par exemple permettre de réaliser
des missions complexes en faisant participer plusieurs personnes qui peuvent se trou-
ver dans des endroits différents.
Télé-maintenance :
La maintenance du système peut être réalisée à distance.
Flexibilité et modularité :
Le système doit être flexible et modulaire, dans la mesure où il doit être ouvert à
d’éventuelles modifications.
Coût :
La réalisation d’un tel système ne doit pas engendrer un coût très important (général-
ement le coût du matériel utilisé).
3.2 Modèlisation géométrique d’environnement pour

le contrôle en Réalitée Augmentée
Dans cette partie nous allons décrire les méthodes de modélisation d’environnement
utilisées pour le contrôle en réalité augmentée du robot et de son environnement. Il s’agit
ici de la modélisation géométrique de la scène (robot, objets, guides virtuels, etc.) et de
la modélisation et calibration de la caméra et du robot.
3.2.1 Modélisation géométrique de la scène

La modélisation géométrique a pour objectif de créer un modèle de la scène, ce modèle
contient deux types de données (géométriques et topologiques). Les données géométriques
64
CONTRÔLE EN RÉALITÉE AUGMENTÉE
sont les entités de la scène tels que le robot, les objets de l’environnement ainsi que les
guides virtuels. Les données Topologiques quant à elles définissent les relations entre ces
entités et les constituants d’une même entité. Il ne s’agit pas ici de faire un état de
l’art complet sur les méthodes de représentations d’objets 3D. Mais nous allons décrire
brièvement les plus connues et ensuite nous allons présenter celles que nous avons choisi
pour télétravailler sur Internet.
Il existe trois catégories de représentation : filaire, surfacique et volumique.
3.2.1.1 Représentation filaire
Le modèle fil de fer “wire frame” est historiquement la première représentation gra-

phique à avoir été mise en œuvre. Il retient de l’objet, les coordonnées des sommets
définissant ainsi les arêtes les joignants. Ne connaissant que les arêtes et les sommets,
plusieurs interprétations d’un même modèle peuvent être faites.
Cette méthode a pour intérêt de permettre une création et une visualisation rapide
du modèle car elle permet une modification aisée des points et des arêtes. La capacité
mémoire utilisée est également très faible.
3.2.1.2 Représentations surfaciques
Ce sont les représentations se référant uniquement aux surfaces de l’objet. La plus

utilisée est la BREP “Boundary REPresentation”. C’est une représentation du solide par
ses limites (frontières) (Qiang, 1989). Les surfaces envisageables peuvent être diverses :
plans, surfaces de révolution, surfaces quelconques. L’objet est construit par assemblage de
primitives géométriques de base. Les primitives sont les éléments géométriques suivants :
point, segment, polygone et polyèdre. Les liaisons entre ces primitives sont définies par des
relations topologiques d’incidences, de contiguı̈té et d’inclusion. Ce type de modélisation
permet implicitement de modéliser aussi les volumes dans la mesure où la position de la
matière est connue.
Dans le cas le plus fréquent des polyèdres, les limites de l’objet sont des plans. Il
est alors défini par ses faces, ses arêtes et ses sommets ; d’où l’appellation de modèle
Face-Arête-Sommet (figure3.1). Deux façons permettent de construire le modèle :
– la première repose sur la définition d’un modèle fil de fer auquel sont associées les
surfaces correspondantes.
– la seconde consiste à balayer un contour de base le long d’un parcours linéaire ou
non linéaire pour créer le solide correspondant.
3.2.1.3 Représentations volumiques
Ces représentations concernent le volume de l’objet. Différents modèles entrent dans

cette catégorie, nous résumons quelques uns.
La représentation “Constructive Solid Geometry “ (CSG) : Il s’agit d’une méthode
de construction d’objets par l’application d’opérations d’assemblage d’où son appellation.
La construction de l’objet se fait par combinaison de volumes élémentaires. La démarche
est semblable à celle de l’artisan, qui usine les pièces élémentaires, les assemble pour en
obtenir une plus complexe figure 3.2. Elle est décrite par un arbre de construction où les
65
Sommets
^
Aretes
Polyèdre
Faces
Fig. 3.1 – Représentation informatique BREP d’un polyèdre
feuilles sont des solides de base et les nœuds sont des opérations comme : l’union, l’inter-
section, la différence, les transformations géométriques composées de translations ou de
rotations.
L’objet est construit à partir de primitives géométriques de base ou volumes élémentair-

es (cube, cylindre, etc.) auxquels sont appliqués les opérateurs logiques afin de les assem-
bler et de créer d’autres volumes. Les primitives géométriques de base sont paramétrées.
Les données canoniques simples caractérisent chacune des primitives (centre, rayon et
hauteur pour le cylindre par exemple).
Fig. 3.2 – Représentation CSG simple

Le paramétrage des primitives et la variété d’opérateurs facilitent la création de nou-
veaux solides en quelques secondes. La simplicité des données canoniques des primitives
rend la représentation des données concises, d’où un gain en place mémoire. Utilisée sou-
vent en CAO, elle ne peut être cependant exploitée directement pour la visualisation et
nécessite une conversion en un modèle plus approprié (la BREP par exemple) au cours
d’un processus de conversion lourd en temps de calcul.
66
Les volumes peuvent être représentés par Enumération Spatiale. Celle-ci contenant plu-
sieurs sous catégories (Pampagnin, 1990), nous présentons quelque unes :
– décomposition primaire de la scène en Voxels. Dans ce cas les éléments de volume
sont des cubes de taille fixée auxquels sont attribuées des valeurs de vérité concernant
la présence ou non de la matière. La méthode est simple mais l’espace mémoire
occupé est prohibitif.
– décomposition optimisée de la scène en Octrees. L’espace 3D est discrétisé de manière
récursive. Si un cube n’est pas homogène (plein ou vide), il est décomposé en huit
cubes plus petits et ainsi de suite. On obtient une description arborescente dont les
feuilles sont des cubes “homogènes”. Un exemple de l’utilisation de l’octree est la
représentation de l’espace libre dans l’espace de configuration d’un robot manipu-
lateur. Les deux décompositions nécessitent trop de place mémoire.
3.2.1.4 La représentation choisie pour le télétravail via Internet
Nous rappelons que notre objectif n’est pas seulement de représenter le robot et les
objets, mais surtout de les représenter pour qu’ils puissent être utilisés pour le télétravail
via Internet. Par conséquent, ils ne doivent pas dépendre d’une certaine plate forme ou de
librairies graphiques particulières qui empêcheraient leurs mobilités (utilisation à distance
via le réseau Internet). De plus, ces objets ne doivent pas être lourds à l’affichage et à la
manipulation et surtout ne doivent pas trop encombrer l’interface de télétravail fournie
à l’utilisateur. Nous avons donc choisi le modèle fil de fer pour représenter le robot, les
objets et les guides virtuels.
Le premier niveau de représentation du modèle se situe au niveau des fichiers. Chaque
fichier est au format wavefront 1 dont quelques éléments principaux sont décrits comme
suit :
v x y z : Introduit un nouveau point de coordonnées (x, y, z) dans le modèle.
f p1 p2 p3 p4 ... : Décrit un polygone formé des points p1 p2 p3 p4 ...
l p1 p2 : Crée un lien (une arête) entre les points p1 et p2 .
Un modèle “fil de fer” d’un objet est constitué de l’ensemble des points du modèle (appelés
sommets) et de l’ensemble des arêtes de l’objet.
Ainsi, nous définissons un objet par :
• Le tableau des coordonnées des sommets de l’objet.
• Le tableau des couples des sommets qui forment une arête.
La figure 3.3 illustre un exemple de représentation d’un triangle avec ce format.
1
format standard et stable utilisé pour la représentation physique des objets sous Java. Il est supporté
par la plupart des navigateurs Internet
67
2
(1, 1, 0)
1 3
(0, 0, 0) (3, 0, 0)
Tableau des sommets
0 0 0 1 1 0 3 0 0
1 2 3
Tableau des aretes
(1, 2) (2, 3) (3, 1)
Fig. 3.3 – Exemple de représentation interne d’un triangle dans l’espace
3.2.2 Modélisation et calibration de la caméra

L’objectif de la modélisation de la caméra est la détermination des relations mathémati-
ques, entre la caméra et l’environnement (Loukil, 1993), (Triboulet, 1996). Cette modélisa-
tion permet de résoudre les problèmes de la mise en coı̈ncidence des points de vue réels
et virtuels (superposition d’une image virtuelle sur une image réelle), ou encore ceux de
recalage 3D (N’zi et al., 1994), (N’zi et al., 1995a), (N’zi, 1995b).
Un modèle de caméra représente le formalisme mathématique permettant d’établir
une relation analytique entre les coordonnées d’un point dans le repère du monde et
les coordonnées de son image dans le repère d’affichage. Le modèle est alors constitué
d’un ensemble de paramètres associés aux transformations mathématiques, nécessaires au
passage, entre le repère du monde et le repère d’affichage.
Le modèle géométrique de la caméra utilisé est celui du sténopé sans distorsions. Dans
ce modèle, un point 3D P (X, Y, Z) et son image p(u, v) sont supposés se trouver sur un
rayon optique passant par le centre de la lentille et considéré non dévié (Figure 3.4).
Deux types de modèles sont distingués, le modèle géométrique direct (MGD) et le modèle
géométrique inverse (MGI). Le MGD est constitué par la relation (u, v) = f (P ), le MGI
est représenté par le rayon visuel = g(u, v).
Le MGD est formé par :
5 Modèle interne (Mint ), composé des transformations permettant d’exprimer les co-
ordonnées pixel, dans le plan image (Ri ), du point p connu dans le plan rétinien
(Rc ).
5 Modèle externe (Mext ), composé des transformations permettant d’exprimer les co-
ordonnées du point P , connu dans le repère du monde (R0 ), dans le repère lié à la
caméra (Rc ).
68
V
Axe optique Y’c p(u, v)
(Ri) c(uo, vo)

Yc p’(x’, y’) i U
C’ Plan image
point objet (Rc’) X’c
C Z’c
Zc
Yo (Rc)
Xc Plan rétinien (Ro) : repère objet
(Rc) : repère camera
P(X, Y, Z) f
(Rc’) : repère rétinien
(Ri) : repère image
(Ro) O
Xo
Zo
Mext : Tco Mint : Tic
Fig. 3.4 – Modèles géométriques de caméra
3.2.2.1 Modèle interne de la caméra
Le modèle interne de la caméra est représenté par les transformations permettant de

passer du repère de la caméra au repère lié au plan rétinien puis, au plan image :
Projection dans le plan rétinien :
C’est la transformation qui permet de passer du repère de la caméra (Rc ), au repère
rétinien (Rc ). Soit P (Xc , Yc , Zc ) un point dans (Rc ), sa projection dans le plan
rétinien donne p (x , y ) dans (Rc ). Cela donne :
Xc /Zc = x /f
(3.1)
Yc /Zc = y /f
Projection dans le plan image :
C’est la transformation qui fait passer du repère (Rc ) au repère (Ri ). Cette trans-
formation est une homothétie suivant les deux axes Xc et Yc ; puis un changement
d’origine.
On obtient le modèle suivant :
u = ki · x + u0 = ku · Xc
Zc
+ u 0 , ku = ki · f
(3.2)
v = kj · y + v0 = kv · Zc + v0 , kv = kj · f
Yc
ce qui donne sous forme matricielle :

⎞⎛ ⎛ ⎞
⎛ ⎞ ⎛ ⎞Xc Xc
Zc · u ku 0 u 0 0 ⎜ Yc ⎟ ⎜ Yc ⎟
⎝ Zc · v ⎠ = ⎝ 0 kv v0 0 ⎠·⎜ ⎟ = Mint (3 × 4) · ⎜
⎝ Zc ⎠ ⎝
⎟ (3.3)
Zc ⎠
Zc 0 0 1 0
1 1
Mint(3×4) est le modèle interne, matrice de passage de (Rc ) à (Ri ) et les paramètres
f, ki , kj , u0, v0 s’appellent les paramètres internes de la caméra (u0 , v0 représentent
l’intersection entre l’axe optique et le plan image, ki , kj sont les facteurs d’échelle
exprimant l’homothétie entre plan caméra et plan image et f la distance focale de
l’objectif)
69
3.2.2.2 Modèle externe de la caméra
C’est la transformation qui permet de passer du repère (R0 ) au repère (Rc ). Un point
de la scène ne peut être connu que par rapport à un repère lié à celle-ci, appelé repère de
travail (R0 ). Trois rotations sont possibles suivant les angles (θx , θy , θz ) et trois translations
sont possibles suivant le vecteur (ta , tb , tc )t permettant de définir la situation de (Rc ) par
rapport à (R0 ). Un point P , de coordonnées X, Y, Z connues dans le repère (R0 ), est
représenté dans le repère (Rc ) par :
⎛ ⎞ ⎛ ⎞ ⎛ ⎞
Xc X X
⎜ Yc ⎟ R3×3 T3×1 ⎜ Y ⎟ ⎜ Y ⎟
⎜ ⎟ ·⎜ ⎟ = Mext (4 × 4) · ⎜ ⎟
⎝ Zc ⎠ = 0 1 ⎝ Z ⎠ ⎝ Z ⎠
(3.4)
1 1 1
où ⎛ ⎞ ⎛ ⎞
r11 r12 r13 ta
R3×3 = ⎝ r21 r22 r23 ⎠ et T3×1 = ⎝ tb ⎠
r31 r32 r33 tc
Mext (4 × 4) est le modèle externe, exprimant la situation (position et orientation) de
la caméra par rapport au repère objet (R0 ).
Les paramètres (ta , tb , tc , θx , θy , θz ), qui sont déterminés à partir de Mext (4 × 4), sont
appelés les paramètres externes de la caméra.
3.2.2.3 Modèle global de la caméra
La matrice qui permet de passer directement du repère de travail (R0 ) au repère (Ri )
lié au plan d’affichage, permet de déterminer le modèle global de la caméra en composant
les modèles interne et externe :
⎛ ⎞
⎛ ⎞ ⎛ ⎞ Xc
Zc · u ki · f 0 u0 0 ⎜ Yc ⎟
⎝ Zc · v ⎠ = ⎝ 0 kj · f v0 0 ⎠ · ⎜⎝ Zc ⎠
⎟
Zc 0 0 1 0
1
⎛ ⎞
⎛ ⎞ X
ki · f 0 u0 0 ⎜ Y ⎟
R3×3 T3×1
=⎝ 0 kj · f v0 0 ⎠ · ·⎜ ⎟
⎝ Z ⎠
0 1
0 0 1 0
1
⎛ ⎞
X
⎜ Y ⎟
= Mint · Mext · ⎜ ⎟
⎝ Z ⎠
1
qui s’écrit :
⎛
⎞
⎛ ⎞ X
s·u ⎜ ⎟
⎝ s · v ⎠ = C3×4 · ⎜ Y ⎟ (3.5)
⎝ Z ⎠
s
1
70
avec ⎛ ⎞
c11 c12 c13 c14
C3×4 = ⎝ c21 c22 c23 c24 ⎠ et s = Zc
c31 c32 c33 c34
la coordonée s = Zc est appelé la coordonnée homogène.
C3×4 représente le modèle global de la caméra, qui exprime la relation entre le repère
objet (R0 ) et le repère image (Ri ). Les paramètres cij (i = 1..3, j = 1..4) sont appelés les
paramètres globaux de la caméra.
3.2.2.4 Modèle géométrique direct de la caméra (MGD)
Ce modèle permet d’exprimer les coordonnées (u, v) du point p image du point P .

La relation (Éq. (3.5)) est décrite par les équations :
P t · c1 + c14 − u(P t · c3 + c34 ) = 0

(3.6)
P t · c2 + c24 − v(P t · c3 + c34 ) = 0
où :
– (.) : produit scalaire,
– P : vecteur de coordonnées X, Y, Z,
– c1 : vecteur de coordonnées (c11 , c12 , c13 ),
– c2 : vecteur de coordonnées (c21 , c22 , c23 ),
– c3 : vecteur de coordonnées (c31 , c32 , c33 ).
La relation (Éq. (3.6)) permet d’exprimer les coordonnées pixel p(u, v) de l’image du
point P . On obtient ainsi le modèle géométrique direct de la caméra suivant :
⎧ P t ·c1 + c14
⎨ u= P t ·c3 + c34
(3.7)
⎩ P t ·c2 + c24
v= P t ·c3 + c34
3.2.2.5 Modèle géométrique inverse de la caméra (MGI)
Ce modèle exprime l’équation du rayon optique passant par le point image p des coor-
données (u, v). La relation (Éq. (3.6)) donne deux équations indépendantes caractérisant
le modèle inverse de la caméra qui peut se mettre sous la forme :
P t · (c1 − u · c3 ) + c14 − u · c34 = 0

(3.8)
P t · (c2 − v · c3 ) + c24 − v · c34 = 0
et peut s’écrire :
pt · −
→ + au = 0
nu
pt · −
→ + av = 0 (3.9)
nv
où
⎛ ⎞ ⎛ ⎞
c11 − u · c31 c21 − v · c31
−
→ = ⎝ c21 − u · c32 ⎠ ,
nu −
→ = ⎝ c22 − v · c32 ⎠
nv
c13 − u · c33 c23 − v · c33
71
et
au = (c14 − u · c34 ), av = (c24 − v · c34 )
La relation (Éq. (3.9)) représente deux équations de plans, où −
→ et −
nu → sont les nor-
nv
males à ceux-ci. Le rayon optique, contenant le point P et son image p, est fourni par
l’intersection de ces deux plans. Le vecteur directeur du rayon optique définissant le modèle
géométrique inverse de la caméra est donné par :
−
→
r =−
→∧−
nu →
nv (3.10)
3.2.2.6 Calibration de la caméra
La calibration de la caméra consiste à déterminer les paramètres du modèle de celle-ci.

Le pré-requis est une acquisition d’un ensemble de points dans le repère objet et de leurs
images. Afin de calibrer la caméra, nous avons expérimenté le modèle linéaire décrit au
début de la section § 3.2.2 (voir aussi la figure 3.4).
D’après la relation Éq. (3.6), un point donne deux équations. Afin d’identifier les
paramètres globaux cij (i = 1..3, j = 1..4) de la caméra, il faut donc au moins 6 points
(non tous coplanaires, non optiquement alignés) et leurs images respectives. Pour avoir une
meilleure précision lors de l’estimation de ces paramètres, par des méthodes d’optimisation
mathématiques, plus de 6 points et leurs images sont nécessaires2 . Nous avons appliqué
alors la méthode des moindres carrés (Loukil, 1993).
Nous avons utilisé une procédure de calibration classique, les coordonnées des points
de la calibration sont fournies manuellement par un opérateur. Les coordonnées des points
de l’image sont obtenues par pointage sur l’écran. Bien qu’il existe actuellement d’autres
méthodes de calibration telles que l’utilisation de plusieurs vues d’un objet (Devy et al.,
1997) ou encore la calibration automatique (qui est basée sur l’utilisation d’un robot à
quatre degrés de liberté et sur un traitement des tâches lumineuses) (Mallem et al., 1999).
Nous nous sommes contentés d’estimer le modèle linéaire de la caméra sans prendre en
compte les distorsions et les résultats obtenus sont satisfaisants pour l’objectif fixé, celui
de superposer une image virtuelle sur une image réelle.
3.2.3 Modélisation et calibration du robot

L’objectif de la modélisation du robot (l’effecteur du robot) est la détermination des
relations mathématiques, entre celui-ci et l’environnement. Cette modélisation représente
le formalisme mathématique permettant d’établir une relation analytique entre les co-
ordonnées d’un point 3D de l’environnement dans le repère du monde et les consignes
moteurs nécessaires pour que l’effecteur du robot atteigne ce point 3D.
Le robot utilisé est un système mécanique à 4 ddl (degrés de libertés). Il est constitué d’une
grande base, d’un support, d’une tourelle et d’une tige montée sur celle-ci. A l’extrémité
de la tige se trouve une pointe métallique utilisée comme moyen de saisie d’objets (fi-
gure 3.5). Les degrés de liberté du robot sont répartis comme suit : la grande base et le
support effectuent deux translations parallèlement au sol, la tourelle quant à elle effectue
deux rotations en site et azimut.
2
Pour calibrer notre caméra nous avons pris 18 points
72
Tige
Tourelle
Effecteur du robot
Support
Grande base
Fig. 3.5 – Les composantes du robot à 4 ddl utilisé pour la calibration
Nous représentons dans un premier temps les différents repères et paramètres du

système de mesures utilisé (figure 3.6) et ensuite les deux modèles géométriques direct et
inverse du robot.
Yo
mire de calibration
pointe de la tige
o Zo (Ro)
Oy
Ox
Xo
a
b Ym
Xm
Zm (Rm)
Yt
dx dz
(Rt) Xt
Zt
Fig. 3.6 – Les différents repères du système de mesures
– Ro : repère objet (c’est le repère de la mire utilisé pour la calibration du robot).

– Rt :repère associé à la position de départ (origine des moteurs) du robot.
– Rm : repère mécanique de la tourelle où s’effectue les rotations.
– (xo , yo, zo ) : coordonnées du point dans le repère objet Ro .
– (dx , dz , θx , θy ) : consignes des moteurs du robot.
– ρ : longueur de la tige (suivant l’axe Z).
– b : bras de levier (suivant Y ).
– a : bras de levier (suivant X).
– (tox , toy , toz ) : paramètres de translation de R0 vers Rt .
73
3.2.3.1 Modèle Géométrique Direct du robot (MGD)
Le MGD permet d’obtenir les coordonnées xo , yo, et zo (en mètres) de l’extrémité de

la tige du robot en fonction des paramètres dx , dz , θx , θy . Le passage de Rt vers Ro se fait
par une translation pure, il s’exprime par :
⎧
⎨ xo = tox + xt
yo = toy + yt (3.11)
⎩
zo = toz + zt
les coordonnées du repère mécanique Rm s’expriment dans le repère Rt par :
⎧
⎨ xt = dx + xm
yt = ym (3.12)
⎩
zt = dz + zm
les coordonnées de l’extrémité de la tige s’expriment dans le repère mécanique par :
⎛ ⎞ ⎛ ⎞ ⎛ ⎞ ⎛ ⎞
xm Cθy Sθx · Sθy Cθx · Sθy 0 1 0 0 a 0
⎜ ym ⎟ ⎜ 0 Cθx −Sθx ⎟ ⎜
0 ⎟ ⎜ 0 1 ⎟
0 b ⎟ ⎜ 0⎜ ⎟
⎜ ⎟ ⎜ · · ⎟
⎝ zm ⎠ = ⎝ −Sθy Sθx · Cθy Cθx · Cθy 0 ⎠ ⎝ 0 0 1 −ρ ⎠ ⎝ 0 ⎠ (3.13)
1 0 0 0 1 0 0 0 1 1
Soit finalement le MGD qui exprime les coordonnées dans le repère objet en fonction
des autres paramètres :
⎧
⎨ xo = tox + dx + a · Cθy + b · Sθx · Sθy − ρ · Cθx · Sθy
yo = toy + b · Cθx + ρ · Sθx (3.14)
⎩
zo = toz + dz − a · Sθy + b · Sθx · Cθy − ρ · Cθx · Cθy
avec
Cθ = cos θ et Sθ = sin θ
3.2.3.2 Modèle Géométrique Inverse du robot (MGI)
Ce modèle est l’inverse du précédent. Il permet d’obtenir les paramètres de translation

et de rotation du robot en fonction des coordonnées xo , yo et zo de l’extrémité de la tige.
Le système d’équation (Éq. (3.14)), contient trois équations à quatre inconnues, donc il y
a à priori une infinité de solutions. Vu la configuration du système (4 ddl), un même point
peut être atteint en utilisant plusieurs combinaisons des différents moteurs. Nous avons
donc imposé une valeur à l’un des moteurs pour obtenir une solution unique (ici c’est la
rotation θy qui est fixée à zéro par défaut). Donc il nous reste plus qu’à déterminer les
trois paramètres (dx , dz , θx ).
On pose Cθx = (1 − t2 )/(1 + t2 ), Sθx = 2t2 /(1 + t2 ) et t = tan(θx /2) dans la
deuxième équation du système (Éq. (3.14)) qui devient :
b · Cθx + ρ · Sθx = yo − toy
on obtient donc deux solutions :
74
⎧ √
⎪
⎨ θx = 2 · arctan(
ρ∓ ρ2 −(yo −toy )2 +b2
)
yo −tyo +b
d = xo − tox − a · Cθy − b · Sθy · Sθx + ρ · Sθy · Cθx (3.15)
⎪
⎩ x
dz = zo − toz + a · Sθy − b · Cθy · Sθx + ρ · Cθy · Cθx
√
ρ− ρ2 −(yo −toy )2 +b2
La solution retenue est θx = 2 · arctan( yo −tyo +b
)
3.2.3.3 Calibration de la tige du robot
La calibraion de la tige du robot dépend des 6 paramètres suivants : ρ, a, b, tox , toy et

toz . Le système donné par (Éq. (3.14)) peut s’écrire sous la forme matricielle suivante :
⎡ ⎤
ρ
⎡ ⎤ ⎢ a ⎥ ⎡ ⎤
−Cθx · Sθy Cθy Sθx · Sθy 1 0 0 ⎢ ⎥ xo − dx
⎢ b ⎥
⎣ Sθx 0 Cθx 0 1 0 ·⎢
⎦
⎢
⎥=⎣
⎥ yo ⎦ (3.16)
⎢ tox ⎥
−Cθx · Cθy −Sθy Sθx · Cθy 0 0 1 ⎣ ⎦ zo − dz
toy
toz
Donc la connaissance d’un point 3D dans le repère objet ainsi que les consignes moteurs
correspondantes (xo , yo , zo , dx , dz , θx , θy ) donne 3 équations à 6 inconnues. Il faut donc 2
points au moins pour pouvoir estimer les 6 inconnues. Nous avons utilisé 4 points et
la méthode des moindres carrés linéaire pour estimer ces paramètres, bien que d’autres
méthodes d’optimisation peuvent être utilisées, par exemple la méthode de Levenberg-
Marquardt (Shaheen, 1999). Mais les résultats que nous avons obtenus sont satisfaisants
par rapport à l’objectif que nous nous sommes fixé (une précision inférieure au mm) Le
tableau 3.1 montre les valeurs des paramètres obtenues par cette méthode.
Paramètres de calibration Valeurs (mètre)

ρ 0.733103
a 0.019364
b 0.007175
tox 0.418756
toy 0.222311
toz 1.673854
Tab. 3.1 – Les paramètres obtenus lors de calibration de la tige du robot
75
3.3 Description du système ARITI

ARITI (“Augmented Reality Interface for Telerobotic applications via Internet”) (Ot-
mane et al., 1999) (Otmane et al., 2000b) est un système de réalité augmentée permettant
à un opérateur humain de superviser et de commander un robot via le réseau Internet.
L’architecture du système a été ensuite améliorée pour supporter du Télétravail coopératif
(plusieurs personnes se trouvant à des endroits différents peuvent participer et travailler
ensemble pour réaliser une mission). La réalisation de ce système a fait l’objet d’une
étude et d’une recherche prenant en compte des contraintes liées aux domaines de la
Télérobotique (instabilité des systèmes en présence de délai) et de la Télécommunication
(transmission de données informatiques).
De nombreuses questions se sont posées au niveau du choix du matériel à utiliser(Station
de travail, PC, etc.), du système d’exploitation sur lequel doit s’exécuter le système de
télétravail (Unix, Windows (NT, 95, 98) Linux (ou Linux temps réel), etc.), des outils
de développement à utiliser (C, C++, JAVA (Java3D), VRML, OpenGL, etc.). Nous
pouvons dire que le choix est assez difficile vu le nombre important de possibilités.
Pour répondre à toutes ces questions, et par rapport aux problématiques posées, nous
avons jugé utile de prendre en considération les caractéristiques d’un système de télétravail
idéal citées au début de ce chapitre.
Nous avons donc fait le choix suivant :

– Matériel :
Un simple ordinateur personnel (PC), de plus actuellement ces ordinateurs person-
nels sont de plus en plus puissants et à moindre coût. Il devient plus facile de changer
un PC qu’une station de travail.
– Système d’exploitation :
Un système d’exploitation multi-tâche et multi-utilisateur “Linux”. Il devient plus
facile de faire de la télé-maintenance sous l’environnement Linux (noyau configurable
et système ouvert, protection des ressources, ...etc) que sous Windows (noyau et
système fermé et n’est pas à l’abri des virus informatiques etc ...)
– Outils de développement :
C, C++ et JAVA ont été choisis pour le développement de notre système. C et C++
pour la partie serveurs (vidéo et commande) et JAVA pour la partie interface homme
machine (client) dans le but d’avoir une interface portable (il s’agit de générer
un code portable standard) pouvant s’exécuter depuis n’importe quelle machine
connectée au réseau Internet.
3.3.1 Description du materiel

Le système ARITI est développé sur un PC Pentium 233 Mhz à 128 Mo de RAM. Il
est relié d’un côté à une caméra noir et blanc via une carte d’acquisition vidéo Matrox
Meteor. De l’autre côté, le PC est connecté à un robot via une liaison série RS232 (figure
3.7).
76
3.3. DESCRIPTION DU SYSTEME ARITI
ordres Réception d’images
Site maitre
^
Liaison RS 232
Site esclave
Fig. 3.7 – Illustration du matériel utilisé pour la réalisation du système ARITI
3.3.2 Description du logiciel

Le système ARITI est développé sous l’environnement Linux. Il peut être divisé en
trois parties : Une partie pour le site opérateur, une autre pour le site distant et enfin le
module de communication qui relie les deux sites.
3.3.2.1 Site distant (esclave)
Dans ce site se trouve un robot et une caméra vidéo ainsi que le module de commu-
nication serveur3 . Ce dernier est constitué de deux serveurs, un pour les images vidéo et
un autre pour les consignes robot. Le premier serveur se charge de capturer des images
via la carte d’acquisition vidéo, de les compresser (voir les méthodes de compression en
annexe A) et ensuite les envoie directement aux différents clients connectés. Le deuxième
serveur quant à lui est chargé de récupérer les ordres envoyés par le client et les transmet
directement au robot pour l’exécution (il peut se charger éventuellement de transférer des
informations depuis le robot vers le client).
3.3.2.2 Site opérateur (maı̂tre)
Dans ce site4 se trouve un opérateur humain et une machine connectée à Internet

(disposant d’un navigateur Internet ou bien ayant un interpréteur Java installé).
Le premier niveau de description de cette partie se résume en deux grands modules. Un
module de communication client qui permet l’échange d’informations avec le site esclave,
et un module d’Interface Homme Machine (IHM) qui gère les interactions entre l’opérateur
humain et le module de communication client. Ce dernier contient deux clients, un pour
la réception d’images vidéo, décompression et la visualisation et l’autre se charge d’in-
terpréter les actions de l’opérateur et les envoie sous forme d’ordres au site esclave (serveur
de commandes) qui se charge de les transmettre au robot réel.
Le module d’IHM quant à lui permet à l’opérateur de spécifier le mode de travail désiré
en rentrant en interaction avec un des trois modules : Téléopération, Téléprogrammation
3
L’implantation logicielle de ce serveur est faite en C++
4
L’implantation logicielle de ce site est faite entièrement en JAVA afin de satisfaire le critère de
portabilité.
77
ou Télésupervision et Télécoopération. Chacun des trois modules utilise un module central

appelé module Réalité Mixée (RM) qui combine les deux mondes virtuel et réel dans le
but de fournir une IHM conviviale. Le module RM joue aussi le rôle d’intermédiaire entre
les différents modes de travail et le module de communication client (figure 3.8).
Opérateur
Télésupervision
Téléopération + Téléprogrammation
Télécoopération
Site opérateur
Réalité Mixée
(IHM) (RM)
Interface Homme Machine - RV & RA -
Client Client
Images Commandes
Module communication client
Communication
Internet / Intranet
Serveur Serveur
Site distant
Images Module communication serveur Commandes
Caméra Robot
Fig. 3.8 – Architecture simplifiée du système ARITI
3.3.3 Module de Réalité Mixée (RM)

Comme son nom l’indique, ce module combine les deux techniques : La réalité vir-
tuelle et la réalité augmentée. le mot Réalité Mixée de l’anglais mixed reality (Milgram et
Kishino, 1994) (Milgram et al., 1995) est utilisé généralement pour décrire tout système
combinant le monde réel et le monde virtuel. Milgram et Kishino ont proposé le continuum
de la Réalité-Virtualité montré dans la figure 3.9. Hickey et Manninen et Petri Pulli (Hi-
ckey et al., 2000) ont introduit le concept de TéléRéalité à l’intérieur de ce continuum afin
de représenter un monde réel dans lequel des données 3D sont ajoutées. A gauche de la
figure 3.9 est représenté l’environnement réel (constitué des images 2D réelles) et à droite
un environnement purement virtuel (constitué des données 3D). Le centre du continuum
est un point dont lequel le contenu de l’environnement virtuel est identique au contenu
de l’environnement réel. Bien que chaque partie de ce continuum ne peut être considérée
que par abstraction, mais à nos yeux ce concept peut être utilisé pour déterminer le degré
de Téléprésence d’un système.
Les composantes du module de RM peuvent être regroupées en deux grandes catégories :
les données et les fonctions d’assistance.
78
Réalité Mixée (RM)

Environnement Environnement
Réel Virtuel
Réalité Augmentée (RA) Virtualité Augmentée (VA)
TéléRéalité
Fig. 3.9 – Le continuum Réalité-Virtualité d’après Milgram 1994 et Hickey 2000
3.3.3.1 Les Données
Il s’agit des données des environnements réel et virtuel. Les données de l’environnement
réel sont généralement perçues par des capteurs se trouvant sur le site réel. Dans notre cas
il s’agit des données 2D images vidéo (du robot et de son environnement) et des données
articulaires du robot (position et orientation). L’environnement virtuel est constitué de
données 3D pour la représentation graphique du robot et de son environnement (robot
virtuel, objets virtuels) et contient aussi un certain nombre d’outils virtuels d’assistance
tels que les guides virtuels. Ces deux types de données, réelles et virtuelles, sont combinés
pour former un Environnement Mixte (EM) avec lequel l’opérateur travaillera (figure
3.10).
Fig. 3.10 – Représentation des données réelles et virtuelles dans un environnement mixte
79
3.3.3.2 Les fonctions d’assistance
Afin d’aider l’opérateur à télétravailler, il est utile de lui fournir trois types d’assistance,
pour la perception de l’environnement, pour la commande du robot et pour la supervision
de tâches. La figure 3.11 illustre les trois types d’assistance fournis à l’opérateur humain
lors du télétravail.
Serveur Image
Serveur Commande
Fig. 3.11 – Les trois types d’assistance pendant le télétravail
Assistance à la perception de l’environnement :
Il s’agit d’assistance à la perception d’environnement mixte. L’opérateur perçoit son

environnement réel grâce au retour d’images vidéo d’une part et il perçoit son en-
vironnement virtuel moyennant plusieurs points de vue virtuels d’autre part (figure
3.12)
.
Images réelles
o
~
points de vue virtuels
Fig. 3.12 – Illustration de l’assistance à la perception de l’environnement
Assistance à la commande :
Il s’agit d’assister l’opérateur à la commande du robot réel distant. l’opérateur com-

mande le robot réel par l’intermédiaire du robot virtuel (figure 3.13). Ceci lui per-
met de travailler en temps réel avec cette représentation virtuelle et ne subit pas
les problèmes liés au délai de transmission dû à la distance qui sépare les deux sites
(maı̂tre et esclave). Afin d’améliorer les performances de l’opérateur à la commande
(en mode de téléopération), des guides virtuels sont utilisés. Ces derniers vont per-
mettre à l’opérateur de travailler plus vite, d’être précis et surtout d’empêcher toute
80
erreur de téléopération involontaire.
Envoi des commandes

o Clavier
Internet
Robot virtuel
+
Guides Virtuels
Etat du robot Robot réel
Joystick
Fig. 3.13 – Illustration de l’assistance à la commande
Assistance à la supervision :
Il s’agit d’aider l’opérateur à vérifier le bon déroulement des tâches réalisées c’est-
à-dire, vérifier si les tâches réalisées par le robot virtuel ont correctement été faites
par le robot réel. En effet, la superposition permanente du monde virtuel sur le
monde réel permet une confirmation de la bonne exécution d’une tâche. La présence
d’un écart entre le monde virtuel et le monde réel, se traduit par des erreurs dues à
l’exécution de la tâche par le robot réel. Dans ce cas l’opérateur doit désactiver la
commande du robot réel et procéder au recalage du modèle virtuel sur l’image réelle
(afin que les deux mondes virtuel et réel soient superposés à nouveau) et ensuite
il activera la commande du robot réel (figure 3.14). Des informations textuelles
telles que “Cible atteinte “, “Objet saisi”, “Collision détectée”, ..., sont retournées
à l’opérateur pour l’informer de l’état des opérations réalisées.
réception
d’images
Image
réelle
Superposition OUI Mise à jour
OK ? image virtuelle
virtuelle / réelle
NON
Image Désactiver la
virtuelle commande réelle
Activer la Recaler le virtuel

commande réelle sur le réel
Fig. 3.14 – Organigramme d’assistance à la supervision
3.3.4 Module de Téléopération

Ce module est celui utilisé par défaut si l’opérateur n’a pas spécifié l’un des modes de
télétravail : Téléprogrammation ou Télésupervision/Télécoopération. Il intercepte toutes
81
les actions réalisées par le robot virtuel et les transmet directement au robot réel via le mo-
dule de communication. En effet l’opérateur travaille en temps réel avec une représentation
intermédiaire qui est l’environnement virtuel (robot virtuel, objets virtuels , etc.).
Dans ce mode de travail, l’opérateur peut être assisté par des guides virtuels (cf. § 2.1.2)
pour réaliser une tâche. Ces guides virtuels ont un rôle important en téléopération du fait
qu’ils permettent d’une part d’éviter au robot réel toute mauvaise manipulation de la
part de l’opérateur (erreurs involontaires dues à la fatigue ou tout simplement des erreurs
d’inattention) et d’autre part de travailler vite avec moins d’imprécision.
Selon les tâches à réaliser, l’opérateur peut utiliser des guides virtuels déjà existants
dans la base de données des guides, les modifier (changer leurs propriétés, les déformer,
etc.), ou bien il peut créer ses propres guides virtuels grâce au module “Création guides”.
Les figures 3.15 et 3.16 illustrent respectivement la téléopération sans et avec assistance
à la commande.
Opérateur
Robot virtuel Robot Réel
Fig. 3.15 – Schéma simplifié de la téléopération sans assistance à la commande
Robot virtuel
Opérateur +
Assistance à Robot Réel

la commande
(Guides virtuels)
Fig. 3.16 – Schéma simplifié de la téléopération avec assistance à la commande
3.3.5 Module de Téléprogrammation

Le mode de travail “Téléprogrammation”, permet à l’opérateur de travailler dans un
haut niveau d’abstraction. En effet, il s’agit de donner au robot virtuel (et au réel) des
ordres de haut niveau pour réaliser une tâche. Il existe un certain nombre de tâches de
téléprogrammation gérées par ce module, par exemple “Saisir objet n˚1”, “Déposer objet
n˚1 sur le Support n˚2”, “Suivre le contour de l’objet n˚1”, ...etc (ces tâches sont décrites
dans le chapitre Application cf. § 4.1).
Une autre tâche consistant à désigner une cible à l’écran et la faire suivre par les ro-
bots virtuel et réel est aussi gérée par ce module. Cette dernière tâche consiste à atteindre
un point 3D de l’espace obtenu à partir de deux points 2D écran (figure 3.17). Afin de
réaliser cette tâche, deux points de vue virtuels différents (deux fenêtres) sont utilisés.
Nous décrivons dans ce qui suit le principe et la méthode utilisée pour déterminer un
point 3D à partir de deux points 2D.
Soit (u1 , v1 ) les coordonnées 2D du premier point obtenu par la désignation sur la première
fenêtre et M(4 × 4) le modèle de la caméra graphique associé à cette fenêtre.
Soit (u2 , v2 ) les coordonnées 2D du deuxième point obtenu par la désignation sur la
82
deuxième fenêtre et M (4 × 4) le modèle de la caméra graphique associé à cette fenêtre.

Soit (X, Y, Z) les coordonnées recherchées du point 3D dans l’espace.
La première désignation peut s’écrire sous forme :

⎡ ⎤ ⎡ ⎤
X s.u1
⎢ Y ⎥ ⎢ s.v1 ⎥
⎢ ⎥ −1 ⎢ ⎥
⎣ Z ⎦=M ×⎣ s ⎦ (3.17)
1 1
avec ⎡ ⎤
x11 x12 x13 x14
⎢ x21 x22 x23 x24 ⎥
M −1 =⎢
⎣ x31
⎥ (3.18)
x32 x33 x34 ⎦
x41 x42 x43 1
La deuxième désignation s’écrit sous la forme :
⎡ ⎤ ⎡ ⎤
X s.u2
⎢ Y ⎥ ⎢ ⎥
⎢ ⎥ = M −1 × ⎢ s.v2 ⎥ (3.19)
⎣ Z ⎦ ⎣ s ⎦
1 1
avec ⎡ ⎤
x11 x12 x13 x14
⎢ x21 x22 x23 x24 ⎥
M −1 =⎢
⎣ x31
⎥ (3.20)
x32 x33 x34 ⎦
x41 x42 x43 1
avec l’équation Éq. (3.17), les coordonnées (X, Y, Z) du point 3D vérifient :

⎧
⎨ X = (x11 × u1 + x12 × v1 + x13 ) × s + x14
Y = (x21 × u1 + x22 × v1 + x23 ) × s + x24 (3.21)
⎩
Z = (x31 × u1 + x32 × v1 + x33 ) × s + x34
l’identification de Éq. (3.17) et Éq. (3.19) donne :
s = ((x14 − x14 ) × B + (x24 − x24 ) × A ))/(B × A − B × A)
avec
A = x11 × u1 + x12 × v1 + x13
B = x21 × u1 + x22 × v1 + x23
A = x11 × u2 + x12 × v2 + x13
B = x21 × u1 + x22 × v2 + x23
En réalité, ce point 3D représente le centre d’une sphère virtuelle mobile appelée cible
mobile (peut être déplacée dans l’environnement virtuel). Ce concept peut être utilisé
pour le suivi d’objets en mouvement. En effet le robot peut suivre cet objet si une cible
mobile (guide virtuel) lui est attachée (voir le chapitre application cf. § 4.1).
83
Premier point Première droite

de vue
Point 2D Cible 3D
Désignation
Opérateur
Ecran Objet
Point 2D
Deuxième point Deuxième droite

de vue
Ecran
Fig. 3.17 – Illustration de la tâche “désignation d’une cible à l’écran”
En téléprogrammation de tâches, l’opérateur spécifie au système la tâche qu’il désire

faire réaliser par le robot et lui demande de l’exécuter. Cette tâche (une séquence de
consignes) est alors exécutée par le robot virtuel et par le robot réel simultanément (chaque
consigne est générée en ligne pour le robot virtuel pour une simulation et ensuite envoyée
au robot réel pour exécution). L’exécution du coté robot virtuel est synchronisée avec
l’exécution du coté robot réel, ceci permet à l’opérateur s’il le désire, d’arrêter l’exécution
de la tâche à n’importe quel moment (à une consigne près). La figure 3.18 illustre le
principe de téléprogrammation de tâches.
Boucle d’exécution au niveau Boucle d’exécution au niveau
du robot virtuel du robot réel
Taches
^ de + +
Opérateur de haut -
-
niveau Robot virtuel Robot Réel
Communication
Fig. 3.18 – Schéma simplifié de l’exécution de tâches en mode Téléprogrammation.
3.3.6 Module de Télésupervision et Télécoopération

Ce module est surtout utilisé lorsque plusieurs opérateurs (clients) sont connectés au
système ARITI. En effet en choisissant le mode “Supervision”, ces opérateurs peuvent
observer l’exécution d’une tâche en réel et en virtuel simultanément. Cependant à un
instant donné un seul opérateur est autorisé à commander le robot réel (il ne s’agit pas ici
d’un problème technique mais d’un choix délibéré, en effet, on peut par exemple partager
certains degrés de liberté du robot entre plusieurs opérateurs). Dans cette partie on définit
un client maı̂tre comme étant le client ayant pris la commande du robot réel, et tous les
autres seront appelés superviseurs (figure 3.19).
Le mot Télécoopération ou Télétravail coopératif, désigne la participation d’un en-
semble de clients (opérateurs distants) à la préparation et à l’exécution d’une mission.
Le système ARITI offre la possibilité à un ensemble d’opérateurs distants de travailler
en coopération. En effet, considérons par exemple une mission Mi constituée de quatre
tâches Ti (pour i = 1..4) qui s’exécutent d’une manière séquentielle (T1 ensuite T2 , T3 et
T4 ). Soit P Ti la fonction “Préparation de la Tâche “Ti ” et ETi la fonction “Exécution de
84
Superviseur
Site esclave Internet / Intranet
supervision
supervision supervision
supervision
commande
Superviseur Superviseur
Images réelles
et virtuelles
Client maitre
Fig. 3.19 – Illustration à la Télésupervision.
la Tâche Ti ”. Soit tpi le temps de préparation de chaque tâche Ti (pour i = 1..4) et tei le
temps d’exécution de cette tâche. Considérons les cas ou la mission peut être réalisée soit
par un seul opérateur (figure 3.20 (A) ) soit par plusieurs opérateurs en télécoopération
(figure 3.20 (B) ). Pour des raisons de bonne lisibilité, prenons tp1 = tp2 = tp3 = tp4 et
te1 = te2 = te3 = te4 .
3.3.6.1 Mission avec un seul opérateur
Il existe deux possibilités pour réaliser cette mission, la première consiste à préparer
toute la mission et ensuite l’exécuter (préparer les tâches Ti (pour i = 1..4) et ensuite les
exécuter dans l’ordre). La deuxième possibilité consiste en une préparation et exécution
simultané des tâches Ti (pour i = 1..4) (P T1 , ET1 ensuite P T2 , ET2 , etc). Le temps total
de l’exécution de la mission est donné par
4 4
tm = tpi + tei (3.22)
i=1 i=1
3.3.6.2 Mission avec quatre opérateurs en télécoopération
Il existe plusieurs possibilités selon l’organisation du groupe de travail. Prenons le cas

où chaque opérateur OPi (pour i = 1..4) a la responsabilité de préparer et d’exécuter
une seule tâche Ti . La préparation des différentes tâches peut être faite en parallèle par
chacun des opérateurs. Par conséquent l’opérateur OPi doit attendre la fin de l’exécution
de la tâche Ti−1 avant d’exécuter la tâche Ti (pour i = 2..4). Pendant ce temps les autres
opérateurs ( OPi (pour i = 2..4)) peuvent superviser l’exécution de la(les) tâche(s) Ti−j
85
(pour i = 2..4 et j = 1..i − 1) et inversement lorsqu’un opérateur a fini l’exécution d’une

tâche il peut superviser la suite de la mission qui sera réalisée par les autres opérateurs. En
considérant que le temps de la prise en main du robot réel soit δti << tei (pour i = 1..4)
pour chaque opérateur OPi (le temps nécessaire pour libérer la commande du robot réel
par le client maı̂tre plus le temps de la prise de la commande par un autre client) alors le
temps total de l’exécution de la mission en télécoopération est
4 4
tmc = ( tpi )/4 + tei (3.23)
i=1 i=1
ce qui donne tmc < tm.
Cette exemple illustre l’avantage que peut offrir un travail coopératif pour la réalisation
des missions complexes. En effet, la charge de travail induite par la complexité de la
mission est partagée entre plusieurs opérateurs et le temps de réalisation de la mission est
nettement réduit.
Fig. 3.20 – Exemple de préparation et d’exécution d’une mission, (A) : préparation et

exécution par un seul opérateur, (B) : Télétravail coopératif avec 4 opérateurs.
3.4 Architecture réseau du système ARITI

Dans cette section nous présentons le premier niveau de l’architecture réseau du
système ARITI (figure 3.21), ensuite nous montrons comment les différents modules
(client/serveur) échangent des informations afin d’assurer une bonne communication. Il
s’agit ici de décrire le protocole de communication entre les serveurs (images et com-
mandes) et les clients correspondants.
86
3.4. ARCHITECTURE RESEAU DU SYSTEME ARITI
INTERNET
Serveur ARITI
Serveur Web Commandes Images
PC Linux PC Linux
WWW Clients Robot Caméra
Fig. 3.21 – Architecture générale de communication avec le système ARITI : En pointillés,

une possibilité d’accéder directement au serveur ARITI sans passer par le serveur Web
Le serveur image permet d’enregistrer une image capturée par la caméra, puis de l’en-
voyer, via le protocole TCP/IP, dans un format compressé. Il se peut aussi que le serveur
envoie les modifications de l’image (différence par rapport à l’image précédente) pour di-
minuer la taille du fichier compressé par exemple. Le serveur de commande quant à lui
permet de récupérer des commandes envoyées par le client et les transmet au robot réel
pour exécution.
Pour pouvoir effectuer une requête au serveur (réception d’images, envoi de com-
mandes), le client doit avant tout être identifié par un numéro qu’il obtient en faisant une
demande au serveur (images ou commandes) (en envoyant un caractère “0 par exemple)
(figure 3.22). Le nombre de clients maximum est 255 (car ce numéro de client est codé
sur un octet allant de 1 à 255, il peut être augmenté si le besoin se fait sentir).
Fig. 3.22 – Protocole de demande d’un numéro d’identification
3.4.1 Protocole de communication client/serveur image

Dans cette partie, nous allons décrire le principe d’une demande d’une image vidéo
par un client et les différents niveaux des schémas de fonctionnement du serveur image.
87
3.4.1.1 Demande d’une image vidéo
Dès que le client a récupéré son numéro, il le renvoie au serveur pour obtenir une image
ou les modifications de l’image en format compressé (figure 3.23). En effet l’image vidéo
capturée par le serveur peut subir des pré-traitements et des compressions différentes. Le
client est informé du type du pré-traitement et/ou de la compression réalisée sur l’image
afin de la décompresser correctement. Nous appelons pré-traitement la différence entre
deux images I et I−1 (I−1 étant l’image déjà envoyée au client et I représente l’image
capturée). Avant d’envoyer une image au client, le serveur envoie en premier un octet
représentant le type de compression de l’image.
Nous présentons ici le codage des différents types de compression d’images envoyés au
client :
– “0” : Erreur : Aucune image n’est envoyée, dans le cas où on ne désire pas l’envoyer
à un client donné par exemple.
– “1” : Image Brut : L’image est envoyée sans compression.
– “2” : Compression Gzip : Un format de compression qui utilise la librairie “Zlib”
supportée par la plupart des navigateurs Internet. Ce type de compression est
généralement utilisé pour envoyer la première image aux clients. (voir annexe A
pour plus d’information sur cette méthode).
– “3” : Compression Gzip avec pré-traitement : L’image subit un pré-traitement
avant d’être compressée par Gzip. Ce format est utilisé généralement lorsqu’il y a
beaucoup de mouvements dans l’image (voir chapitre résultat pour plus de détails).
– “4” : Compression Huffman : C’est un algorithme de compression rapide et qui
fourni une bonne compression dans le cas où il y a peu de mouvements dans l’image.
– “5” : Compression Huffman avec pré-traitement : L’image subit un pré-
traitement avant d’être compressée avec Huffman. Ce format permet d’avoir un
taux de compression de l’image meilleur que le format Gzip avec pré-traitement. Il
est utilisé dans le cas où il y a peu de mouvements dans l’image.
3.4.1.2 Schéma fonctionnel du serveur image
Le serveur image est composé de 3 modules : “initialisation”, “attente d’une com-

mande” et “gestion de la commande avec le client”. Le schéma de fonctionnement
simplifié du serveur image est donné par la figure 3.24.
Le module “initialisation” permet la création d’une socket TCP/IP, l’attachement
de la socket sur un port connu et l’ouverture du service (figure 3.25 partie 1).
Le module “attente d’une commande” accepte la connexion avec le client et

réceptionne son numéro d’identification (figure 3.25 partie 2).
Le module “gestion de la commande avec le client” peut être divisé en deux

parties suivant le numéro du client :
Si le numéro vaut “0”, dans ce cas, le serveur cherche un numéro de libre (entre 1 et
255 par exemple). Si un numéro de libre est trouvé alors il est envoyé au client, sinon le
serveur renvoi le numéro “0” pour informer le client qu’il ne peut pas recevoir d’images
88
Fig. 3.23 – Protocole de communication client/serveur image
Fig. 3.24 – Schéma de fonctionnement simplifié du serveur image
89
pour l’instant (figure 3.25 partie 3-A).
Si le numéro et supérieur à “0” (le client dans ce cas est autorisé à recevoir des images),
alors le serveur prend l’image en cours, la compresse et l’envoi au client (figure 3.25 partie
3-B).
Dans la figure 3.25, est présenté le schéma de fonctionnement du serveur image, avec
en caractères gras, les fonctions réseaux C/C++ utilisées.
Fig. 3.25 – Schéma détaillé du fonctionnement du serveur image
3.4.2 Protocole de communication client/serveur commande

3.4.2.1 Protocole de connexion pour la commande du robot réel
Pour pouvoir contrôler le robot, il faut qu’aucun autre client ne l’utilise. Si le robot
n’est pas libre, le serveur envoie le caractère “U” (pour dire que le robot est en cours
90
d’utilisation) et interrompt la connexion. Sinon le serveur vérifie le mot de passe (pass-

word) : s’il est bon, il autorise le contrôle du robot en envoyant le caractère “B” (pour
dire que le mot de pass est bon), sinon le serveur envoie le caractère “M” (pour dire
que le mot de passe est mauvais) et interrompe la connexion. La fin d’utilisation du ro-
bot se fait à la coupure de la connexion TCP/IP. La figure 3.26 illustre ce protocole de
communication client/serveur commande.
Fig. 3.26 – Protocole de communication client/serveur commande. Le caractère “S”

désigne la demande de contrôle du robot
3.4.2.2 Protocole de télésupervision
Ce protocole est généralement utilisé lorsque un ou plusieurs opérateurs utilisent le

mode de télésupervision et télécoopération. En effet, le serveur de commande se charge de
renvoyer l’état final du robot et d’autres informations utiles à tous les opérateurs ayant
choisi ce mode de télétravail.
Par ailleurs, ces opérateurs devraient voir en permanence la correspondance du robot

virtuel avec le réel pendant toute la durée de contôle du robot réel par le client maı̂tre.
La figure 3.27 illustre ce protocole de communication entre le serveur commande et les
clients dits superviseurs lorsque le client maı̂tre contrôle un robot à 4 degrés de libertés
(ou PX et PY désignent deux rotations et PW et PZ les deux translations)
3.4.2.3 Schéma fonctionnel du serveur commande
De la même façon que le serveur image, le serveur commande peut être décomposé en
3 modules : “initialisation”, “attente d’une commande” et “gestion de la com-
mande avec le client” voir la figure 3.24.
Le module “initialisation” est le même que celui du serveur image et il est représenté
dans la figure 3.28 partie 1.
91
Fig. 3.27 – Protocole de communication entre le serveur de commande et les autres clients
superviseurs : le caractère “F désigne la demande de l’état final du robot
Le module “attente d’une commande”, détermine si un client se connecte pour la

première fois (nouvelle connexion) ou s’il est déjà connecté et désire contrôler le robot
réel. Dans le cas d’une nouvelle connexion, ce module réceptionne le numéro du client et
vérifie si ce numéro est supérieur ou égale à zéro. Si ce numéro est supérieur à zéro, alors
ce module réceptionne la demande de supervision ou de contrôle du robot envoyée par
le client. Dans le cas où le client désire contrôler le robot réel, ce module se charge de
récupérer les consignes du robot. Ce module est représenté dans la figure 3.28 partie 2.
Le module “gestion de la commande avec le client” peut être divisé en quatre

sous modules A, B, C et D représentés par la figure 3.28 partie 3. Nous décrivons ci-
dessous le fonctionnement de ces différents sous modules.
– Le sous module A : Alloue un numéro d’identification libre au client (figure 3.28

partie 3-A).
– Le sous module B : Enregistre les consignes envoyées par le client et les envoie
ensuite au robot réel pour exécution (figure 3.28 partie 3-B).
– Le sous module C : Vérifie si le robot est libre (n’est pas pris par un autre client),
dans ce cas, il procède à la vérification du mot de passe. Si le mot de passe est correct
alors il envoie au client une autorisation pour contrôler le robot (et la connexion
avec le robot est établie) sinon il informe le client que le mot de passe est mauvais.
Dans le cas où le robot est en cours d’utilisation par un autre client, il informe le
92
3.5. BILAN
client que le robot est déjà pris (figure 3.28 partie 3-C).
– Le sous module D : Envoie la position finale du robot suite à une demande de

supervision de la part d’un client (figure 3.28 partie 3-D).
Le schéma détaillé du fonctionnement du serveur de commande est donnée par la figure
3.28, avec en caractères gras, les fonctions réseaux C/C++ utilisées :
3.4.3 Limites et Sécurité du protocole

Le serveur peut être saturé rapidement si un client est défaillant (il demande toujours
un nouveau No de client). Une solution serait de limiter le nombre de clients par adresse
IP (non intégrée).
Le client (sauf s’il contrôle le robot) est automatiquement déconnecté du serveur si il

n’a pas envoyé de commande après un certain laps de temps (par défaut : 60 secondes).
Dans ce cas, le numéro de ce client est libéré.
Chaque numéro de client est lié à une adresse IP, donc un client ne peut pas perturber
un autre client qui se trouve sur une autre machine (au cas où un client défaillant utilise
un No de client déjà pris par un autre !).
Le mot de passe est crypté pour éviter qu’il soit facilement lu sur le réseau. Le cryptage
ne garantit pas à cent pour cent la confidentialité du mot de passe.
3.5 Bilan
Dans ce chapitre, nous avons présenté les méthodes et les outils nécessaires pour un
contrôle en réalité augmentée, à savoir la modélisation de l’environnement et la calibra-
tion de la caméra et du robot. Nous avons aussi présenté le système expérimental de
télétravail baptisé ARITI. L’interface de ce système est implantée en langage JAVA dans
le but de la rendre portable et indépendante des systèmes d’exploitation sur lesquels elle
va s’exécuter. Nous avons insisté sur des détails de l’architecture client/serveur réalisée
afin de montrer d’un côté, sa complexité et de l’autre côté, la faisabilité conceptuelle et
technique d’une architecture destinée à supporter un télétravail d’une part et un travail
coopératif d’autre part.
Par ailleurs, nous avons présenté les trois modes de télétravail, à savoir la téléopération,
la téléprogrammation de tâches et la télécoopération/télésupervision. Ce dernier mode uti-
lise un retour prédictif distribué, afin de permettre aux différents opérateurs de percevoir
à la fois, les images vidéo de l’environnement réel distant et la mise à jour 3D de l’envi-
ronnement virtuel au niveau de chaque client superviseur.
Dans le chapitre suivant, nous allons montrer quelques applications potentielles et en

particulier pour la téléopération via Internet, d’un robot à 4 degrés de libertés utilisant
le système ARITI.
93
D
C
Fig. 3.28 – Schéma détaillé du fonctionnement du serveur de commande
94
Chapitre 4
Applications
Le chapitre précédent nous a permis de présenter les différentes méthodes géométriques

utilisées pour un contrôle en réalité augmentée ainsi que le système expérimental de
télétravail proposé. Nous avons cependant, introduit les différents modes de télétravail,
téléopération, téléprogammation de tâches et la télécoopération/télésupervision.
Dans ce chapitre nous présentons une application de télémanipulation, une autre

de téléopération d’un robot mobile et les différentes applications potentielles pouvant
bénéficier du système de télétravail décrit dans le chapitre précédant.
La première application est celle réalisée avec un banc d’essai à 4 degrés de libertés trans-
formé en robot téléopérable via Internet grâce au système ARITI. En effet, nous décrirons
les tâches réalisées suivant les différents modes de télétravail ainsi que les guides virtuels
que nous avons utilisé pour réaliser quelques tâches en téléopération. Nous présentons l’in-
terface homme-machine pour cette application ainsi que le modeleur 3D que nous avons
réalisé pour créer et manipuler ces guides virtuels.
Nous présentons ensuite une application d’un projet en cours de réalisation pour l’assis-
tance aux personnes handicapées (un projet en collaboration avec l’Association Française
contre la Miopathie (AFM)) utilisant un robot mobile.
Ce chapitre s’achève par la description d’autres domaines d’applications où l’utilisation

d’un tel système de télétravail peut être intéressante.
4.1 Télétravail avec un robot à 4 ddl

4.1.1 Description du site esclave
Dans ce cas, le site esclave est constitué d’un robot, d’une zone de manipulation et
d’une caméra (figure 4.1).
95
CHAPITRE 4. APPLICATIONS
Effecteur du robot
Zone de manipulation
Tourelle Cylindres en
(2 rotations) polystyrène
1
2 Support
3 Métallique
Z Y
Support
(commandé en Z ) X
Grande base
(commandée en X)
Fig. 4.1 – Image du robot et de la zone de manipulation.
Le robot utilisé est un banc d’essai à 4 ddl, il peut effectuer deux translations parallèles
au sol et deux rotations en site et azimut. Chaque composante du robot est commandée
par un moteur pas à pas via une armoire de commande (figure 4.2 (a)), le robot peut
aussi être commandé par une liaison série RS232 en positionnant l’aiguilleur (“switch”)
en mode réseau.
La zone de manipulation est constituée de 3 cylindres en polystyrène numérotés (1,2 et
3) de 20 cm de diamètre accrochés sur des supports métalliques (figure 4.1). La figure
4.3 montre les caractéristiques de l’objet et de son support. Ces supports sont fixés à une
mire métallique située à 1 mètre environ de l’effecteur du robot.
La visualisation du robot et de son environnement est réalisée par une caméra noir et
blanc (focale de 8,5 mm) montée sur une tourelle (figure 4.2 (b)).
switch Caméra N/B
(a) (b)
Armoire de commande Tourelle
Fig. 4.2 – Image de l’armoire de commande (a) et de la caméra montée sur une tourelle
(b)
96
4.1. TELETRAVAIL AVEC UN ROBOT A 4 DDL
5 cms Cylindre en polystyrène

Crochet
trou
2 cms
4 cms
20 cms
Support
métallique
22 cms
Fig. 4.3 – Caractéristiques d’un objet à manipuler et de son support
4.1.2 Description du site client

Le site client est généralement constitué d’un opérateur et d’une machine connectée à
Internet (ordinateur ou une Station de travail disposant d’un navigateur Internet).
Comme pour tout système accessible sur réseau en particulier Internet, et vue le
nombre important de clients qui peuvent se connecter en même temps, il est nécessaire
d’avoir un administrateur pour ce type de système. En effet, dans notre cas, la création de
guides virtuels par exemple, ne peut pas se faire par plusieurs clients connectés au système
ARITI en même temps (pour éviter des conflits d’accès aux ressources du système). Ne
peut créer des guides virtuels que le client qui s’est connecté en tant qu’administrateur.
Les autres clients, peuvent les utiliser pour réaliser des tâches en téléopération.
Nous définissons alors deux types d’opérateurs (clients) :
– Administrateur : Est un client pouvant travailler avec une version de ARITI

réservée uniquement pour l’administrateur. Ce dernier réalise la mise à jour de la
version d’ARITI destinée aux autres clients.
– Utilisateurs ou superviseurs : Se sont des clients pouvant travailler avec une
version de ARITI mise à jour par l’administrateur.
La figure 4.4 illustre ces deux types de clients pouvant télétravailler avec les deux types
de versions du système ARITI.
Il existe deux versions d’Interface Homme Machine (IHM) permettant à un opérateur
de télétravailler. La première version, est appelée “IHM administrateur” et la deuxième
“IHM utilisateur”.
4.1.2.1 IHM administrateur
Cette version est destinée à l’opérateur (client) dit “administrateur” qui a pour rôle
la mise à jour éventuelle et l’administration du système ARITI. En effet, l’administrateur
peut créer des guides virtuels d’assistance à la téléopération, les tester et mettre à jour la
base de données des guides (comme indiqué dans les cas d’utilisation des guides virtuels
au chapitre cf. § 2.3 et le tableau 2.3). Il peut aussi interdire complètement l’accés au
système, ou partiellement, comme par exemple limiter le contrôle du robot réel à certains
97
Clients
utilisateurs
... IHM utilisateurs
Internet / Intranet
ARITI
Utiliser utilisateurs
Mise à jour
Guides
virtuels
Utiliser
Créer ARITI
administrateur
IHM administrateur
Client
administrateur
Fig. 4.4 – Illustration des deux types de clients “Administrateur” et “Utilisateur” du

système ARITI
clients autorisés.
L’administrateur, peut aussi créer de nouvelles tâches de téléprogrammation et les mettre
ensuite à la disposition des autres clients utilisateurs du système. En d’autres termes,
L’IHM administrateur peut être considérée comme une version expérimentale avec laquelle
l’opérateur peut créer de nouveaux modèles (robots, objets et guides virtuels) et les tester
avant de les mettre à la diposition des utilisateurs.
La figure 4.5 montre l’interface destinée au client administrateur.
Nous décrivons dans le paragraphe qui suit l’interface du système ARITI. Cette des-
cription est commune aux deux versions de l’interface “administrateur” et “utilisateur”.
L’interface du système ARITI est constituée de quatre parties. La première, en haut à
gauche de la figure 4.5, permet le contrôle en réalité augmentée du site esclave (l’opérateur
perçoit d’un coté l’environnement distant grâce au retour vidéo ainsi que la superposition
du monde virtuel sur le réel et de l’autre coté, il perçoit une horloge lui indiquant le
délai de transmission vidéo et le décalage horaire si le client se trouve à l’extérieur de la
France).
La deuxième partie de l’interface (en haut à droite de la figure 4.5) est complètement
virtuelle, elle permet de visualiser l’environnement virtuel grâce à une caméra virtuelle
que l’on peut déplacer ou tourner suivant les 3 axes X, Y et Z.
La troisième partie (en bas à gauche de la figure 4.5) permet à l’opérateur de voir ce que
voit une caméra virtuelle fixée sur l’effecteur du robot (eye-in-hand).
La quatrième partie (en bas à droite de la figure 4.5) représente le tableau de bord de
l’interface de ARITI. En effet, elle permet à l’opérateur de choisir son mode de télétravail
(téléopération, téléprogrammation de tâche ou encore télésupervision et télécoopération).
Elle permet aussi à l’opérateur de changer de point de vue de la caméra virtuelle, de
98
Superposition Caméra virtuelle Coordonnées de

Image réelle virtuel / réel Repère Horloge (plusieurs points de vue possible) l’effecteur du robot
l’administrateur
Réservés à
Point de vue de la caméra virtuelle

embarquée sur l’effecteur du robot
Fig. 4.5 – l’IHM destinée au client administrateur, avec en haut à gauche, une image
vidéo de résolution 288 × 384, en bas à droite la partie réservée à l’administrateur pour
créer des guides virtuels.
99
choisir le pas de déplacement du robot, etc.
La figure 4.7 montre comment choisir le mode de télétravail à partir du tableau de

bord de l’interface de ARITI.
4.1.2.2 IHM utilisateur
Cette deuxième version de l’interface, est destinée à tous les autres opérateurs (clients)
appelés “utilisateurs” du système ARITI. Elle est accessible sur le site web de notre labora-
toire au http : //lsc.cemif.univ−evry.f r : 8080/ ou encore sur le site de la NASA “NASA
Space Telerobotics Program” au http : //ranier.oact.hq.nasa.gov/telerobotics page/realro-
bots.html).
Fig. 4.6 – l’IHM destinée au client utilisateur, avec en haut à gauche, une image vidéo
de résolution 192 × 256, et l’utilisateur ne peut pas créer de guides virtuels.
Les différences principales entre cette version et la précédente, sont situées au niveau
de la taille de l’image vidéo et de la possibilité de créer des guides virtuels. Dans la version
administrateur (figure 4.5), l’image vidéo est de 288×384 (110592 octets = 108 KO), alors
que dans la version utilisateur (figure 4.6) la taille est de 2/3 (192 × 256=49152 octets =
48 KO).
4.1.2.3 Description de l’outil de création et de manipulation des guides vir-

tuels
Comme nous l’avons décrit dans le second chapitre, l’opérateur peut être assisté par
des guides virtuels lors de la téléopération. Il peut utiliser des guides virtuels existants
dans la base de données des guides (figure 4.7-(B)). La description de ces guides sera
donnée avec la description des tâches de téléopération dans la section suivante.
Dans le cas où l’opérateur désire créer de nouveaux guides virtuels correspondant à
une nouvelle tâche, un outil de création et de manipulation de guides virtuels apparaı̂t en
100
(C) (B)
(A)
(D)
Fig. 4.7 – (A) : Tableau de bord de l’interface de ARITI. (B) : mode téléopération, (C) :
mode téléprogrammation de tâche, (D) : contrôle du robot réel et le mode télésupervision
ou télécoopération
101
activant le bouton “Guides” (voir la figure 4.7-(A)). Il s’agit d’un modeleur 3D (figure 4.8)
permettant à l’opérateur de générer des objets virtuels en trois dimensions. Les méthodes
utilisées sont celles décrites dans le second chapitre (surfaces, volumes ouverts, volumes
fermés, etc.) et représentées par le générateur de guides virtuels dans la figure 4.9.
Tourner
Fig. 4.8 – L’interface du modeleur 3D pour la création et la manipulation de guides

virtuels.
A chaque guide virtuel est associé des propriétés permettant à l’opérateur et au système
de l’identifier afin que ce guide puisse accomplir le rôle qui lui a été réservé. Les figures
4.10 et 4.11 montrent respectivement, un exemple d’un guide virtuel simple et de ses
propriétés pour la tâche d’atteinte d’une cible. Un autre exemple de propriétés d’un guide
virtuel (figure 4.14) pour la tâche de suivi de contour est donnée dans la figure B.42.
Nous verrons plus loin les propriétés des guides virtuels composés.
4.1.3 Mode Téléopération

Dans ce mode de télétravail, l’opérateur commande le robot réel via le robot virtuel.
Il peut téléopérer le robot réel avec ou sans assistance des guides virtuels. Nous allons
décrire quelques tâches de téléopération réalisées avec assistance des guides virtuels (Ot-
mane et al., 2000a) (Otmane et al., 2000c). Ceci permettra de décrire les différents guides
présentés dans la figure 4.7-(B).
Les tâches que nous allons décrire sont les suivantes :
102
Fig. 4.9 – Générateur de guides virtuels : Exemple d’un plan généré à partir de deux
paramètres, la longueur et la largeur.
– Atteinte de cible.
– Atteinte de cible mobile.
– Suivi de contour d’un objet.
– Saisie et dépôt d’un objet.
Pour chacune d’elles, nous décrivons le(les) guide(s) associé(s).
4.1.3.1 Tâche d’atteinte de cible
La cible en question est généralement un point 3D dans l’espace. Ce point peut être
attaché à un objet de l’environnement à saisir par exemple. Le guide virtuel utilisé est un
cône tronqué ouvert (entonnoir).
L’extrémité de ce guide est attachée à la périphérie d’un objet cylindre, dans ce cas le
point 3D cible est le centre de cette extrémité représenté par le point P 1 dans la figure
4.10.
Guide virtuel Objet Cylindre
Cible
P2
E
R P1 2 mm
r1 A l
X2 L X1 r
Crochet
Y
X Z
Fig. 4.10 – Guide virtuel utilisé pour atteindre une cible : ici la cible est un point 3D se
trouvant sur la périphérie de l’objet cylindre
103
Le point E de coordonnées (Xe , Ye , Ze ) désigne l’extrémité de l’effecteur du robot.

Le point A de coordonnées (Xa , Ya , Za ) représente le centre du disque de rayon r1 pas-
sant par le point E .
Le point P1 de coordonnées (X1 , Y1 , Z1 ) est le centre de la première extrémité du guide
virtuel et de rayon r .
Le point P2 de coordonnées (X2 , Y2, Z2 ) est le centre de la deuxième extrémité du guide
et de rayon R .
Type du guide
Réferentiel
Le guide est attaché à l’objet

cylindre numéro 3
Première ouverture
horizontale/verticale
Deuxième ouverture
horizontale/verticale
Hauteur
Fig. 4.11 – Propriétés du guide virtuel d’assistance à la téléopération pour atteindre une
cible. La cible dans ce cas est l’objet cylindre numéro 3 (figure 4.1)
Nous décrivons ici les propriétés données par la figure 4.11 et le formalisme de ce guide :
– Nom du guide : L’identification de ce guide se fait par son nom (“Atteindre cibl-
e3.obj” dans figure 4.11). Ceci permet à l’opérateur de retrouver ce guide, de changer
ses propriétés pour saisir un autre objet par exemple. En effet ce guide peut être
utilisé pour toutes les tâches de saisie.
– Type du guide : Ce guide virtuel est dit “simple” et “actif en attraction” (comme
indiqué dans la figure 4.11). Il s’agit d’un guide d’assistance “semi-autonome”. Ce
type est utilisé pour définir la fonction du guide.
– Référentiel : Donne la position et l’orientation de ce guide par rapport au repère
de l’environnement virtuel.
– Attachement : L’attachement de ce guide à un objet virtuel, se fait en précisant
le nom de cet objet dans le champ “Attachement” représenté dans la figure 4.11.
Ici, ce champ contient “Objet cylindre 3.obj” qui représente bien l’objet cylindre de
numéro 3 appartenant à l’environnement virtuel.
– Zone d’influence : Constitue un volume de travail en dehors duquel l’extrémité
de l’effecteur du robot E ne peut pas sortir (sauf si l’opérateur recule suffisam-
104
ment pour faire disparaı̂tre le guide). Le nom de l’équation du guide (“tube”) et ses
paramètres sont mémorisés afin de les utiliser pour définir la condition d’activation
de ce guide (pré-condition).
– Pré-condition : Le guide virtuel est activé dès que l’effecteur du robot se rapproche
suffisamment du support métallique (atteinte de la zone d’influence). Ceci se traduit
par l’appartenance de l’extrémité de l’effecteur du robot “E au volume de ce guide
en vérifiant les contraintes suivantes :
X1 < Xe <= X2
(4.1)
(Ye − Ya )2 + (Ze − Za )2 <= r12
avec r1 = l × (R − r)/L + r et “L” représente la hauteur du guide virtuel, “l” la
hauteur du sous cône dont l’extrémité est le disque contenant le point “A” (voir
figure 4.10)
– Fonction : Elle est représentée par une combinaison des actions réalisées par
l’opérateur (dans ce cas, “Déplacer le robot”) et d’une fonction de projection
de l’extrémité de l’effecteur du robot “E” sur le point “A”. Cette projection peut
s’écrire sous la forme suivante :
⎧
⎨ Xe = Xa
Ye = Ya (4.2)
⎩
Ze = Za
avec ⎧
⎨ X a = Xe
Y a = Y 1 + r1 − r (4.3)
⎩
Za = Z1
– Post-condition : Elle constitue la négation de la pré-condition. En effet, le guide
est désactivé si par exemple l’opérateur fait reculer le robot suffisamment pour sortir
du guide ou si la cible est atteinte. Ces deux conditions peuvent s’écrire sous la forme
suivante :
⎧
⎨ Xe <= X1
ou (4.4)
⎩
Xe > X2
4.1.3.2 Tâche de suivi de cible mobile
Cette tâche permet au robot de suivre une cible virtuelle, que l’opérateur peut déplacer
dans son environnement, ou encore suivre un objet virtuel en mouvement lorsque la cible
mobile est attachée à cet objet. La figure 4.12 illustre le principe de suivi d’objet en
mouvement.
En effet le déplacement de l’objet virtuel entraı̂ne avec lui la cible qui lui est attachée.
Cet objet se déplace suivant une trajectoire que réalise l’objet en passant par les points P1 ,
P2 , P3 et P4 par exemple. Dans ce cas les coordonnées de la cible mobile sont déterminées
en fonction des coordonnées de l’objet virtuel en mouvement.
La réalisation de la tâche de suivi de cible se fait en deux étapes :
105
X
Etat initial
Cible mobile Objet virtuel Trajectoire de la cible mobile
P1
P2 Etat final
P3
P4
Z
Effecteur durobot
Fig. 4.12 – Illustration du principe de suivi de cible mobile par l’effecteur du robot.
La première étape consiste à désigner sur écran la cible mobile, et à activer un guide
virtuel pour atteindre cette cible. L’opérateur peut utiliser le même type de guide virtuel
que pour la tâche précédente, sauf que ce guide (sous forme d’une sphère) sera attaché
à un objet virtuel en mouvement. La méthode de désignation d’un point 3D à partir de
deux points 2D est décrite dans cf. § 3.3, voir aussi la figure 3.17.
La deuxième étape consiste à déplacer la cible mobile dans son environnement en

translation et/ou en rotation par rapport aux axes X, Y et Z. La figure 4.13, montre les
captures d’écran de la deuxième fenêtre de l’interface de ARITI pendant le suivi de la
cible par le robot. Ici l’opérateur ne contrôle pas directement le robot, mais ce dernier
subi la fonction d’attraction du guide virtuel attaché à la cible mobile.
4.1.3.3 Tâche de suivi de contour d’un objet
Dans cette tâche, l’opérateur téléopère le robot pour atteindre le contour d’un objet
cylindre et réalise ensuite le suivi de son contour.
Le guide virtuel utilisé pour assister l’opérateur à réaliser cette tâche est un cône de
révolution. Une extrémité de ce guide est attachée au contour d’un objet cylindre et l’autre
est destinée à recevoir l’extrémité de l’effecteur du robot (figure 4.14).
En effet, avec ce type de guide (semi-autonome), l’opérateur va pouvoir déplacer l’ef-

fecteur du robot directement sur le contour de l’objet cylindre et ensuite il lui suffit de
déplacer l’effecteur du robot de gauche à droite (ou inversement) pour parcourir le contour
du cylindre.
Les propriétés de ce guide sont données par la figure B.42, et ci-dessous nous présentons
essentiellement la pré-condition, la fonction et la post-condition de ce guide.
– Pré-condition : Le guide virtuel est activé dès que l’effecteur du robot se rapproche
suffisamment du support métallique (atteinte de la zone d’influence cône). Ceci se
traduit par l’appartenance de l’extrémité de l’effecteur du robot “E au volume de
ce guide en vérifiant les contraintes suivantes :
106
Sphère mobile Point de la désignation initiale

Guide virtuel
(A) (B)
(C) (D)
Fig. 4.13 – Exemple de suivi de cible mobile par le robot. La cible est atteinte par le
robot (A), a effectué une translation par rapport à l’axe X (B), ensuite une rotation par
rapport à l’axe Z (C) et enfin une translation par rapport à l’axe Z (D)
Objet Cylindre
Guide virtuel
A
E
R
Crochet
Disques de passage
de l’effecteur du robot Y
Centre X Z
Fig. 4.14 – Le guide virtuel utilisé pour le suivi de contour. Le point “E” désigne
l’extrémité de l’effecteur du robot et le point “A” appartient au contour du disque de
passage de “E”.
107
Fig. 4.15 – Propriètés du guide virtuel utilisé pour le suivi de contour. Dans ce cas ce
guide permet de suivre le contour du cylindre numéro 1
Xe >= Xcentre
(4.5)
(Ye − Ycentre )2 + (Ze − Zcentre )2 <= R2
– Fonction : Elle est représentée par une combinaison des actions réalisées par
l’opérateur (dans ce cas, “Déplacer le robot”) et par une fonction de projection
de l’extrémité de l’effecteur du robot “E sur le point “A qui appartient au contour
du disque contenant “E . Cette projection peut s’écrire sous la forme suivante :
⎧
⎨ Xe = Xa
Ye = Ya (4.6)
⎩
Ze = Za
– Post-condition : Dans ce cas, le guide est désactivé seulement si l’opérateur recule
le robot suffisamment pour sortir du guide.
4.1.3.4 Tâche de saisie et dépôt d’un objet
Cette tâche consiste à décrocher un objet cylindre depuis son support métallique (tâche
de saisie) et l’accrocher ensuite sur un autre support (tâche de dépôt).
L’opérateur peut être assisté par des guides virtuels pour réaliser cette tâche. Nous
décrivons ici, les guides virtuels utilisés pour chacune des tâches.
108
4.1.3.4.a Saisie d’un objet

Généralement, la tâche “saisie d’un objet” est toujours précédée de la tâche “atteinte
d’un objet”. En effet, pour saisir un objet, il faut dans un premier temps atteindre cet
objet par l’effecteur du robot. Pour cela, le guide virtuel donné dans la figure 4.10 est
utilisé. Dès que cet objet est atteint, ce guide disparaı̂t pour faire apparaı̂tre le guide de
saisie proprement dit.
La figure 4.16 décrit le guide virtuel utilisé pour saisir un objet cylindre. Ce guide est
composé de trois guides simples sous forme de cylindres appelés “Guide 1”, “Guide 2” et
“Guide 3”. Ces trois guides sont disposés de telle sorte que la tâche de saisie d’objet ne
provoque pas la détérioration du robot ou de l’objet lui même.
Le “Guide 1”, est positionné à l’intérieur de l’objet à saisir (formant ainsi une zone de
prise de l’objet). En effet, pour prendre l’objet, l’effecteur du robot doit piquer l’objet en
faisant une translation en profondeur de 2 cm.
Guide 1
Zone de prise de l’objet
Guide 2
Guide 3
P4 r2 2 cm
E
P6 A P5
r3 A
E mire métallique
P2 r1 P1
P3
Crochet
Centre de la cible
X Z
Objet Cylindre
Fig. 4.16 – Le guide virtuel utilisé pour la saisie d’un objet cylindre. Le point E désigne
l’extrémité de l’effecteur du robot et le point A désigne le centre du disque passant par
le point E .
Les propriétés de ce guide sont données par la figure 4.17, et nous présentons ensuite
la pré-condition, la fonction et la post-condition de ces guides.
Dans ce qui suit, le point Pi (figure 4.17) a pour coordonnées (Xi , Yi , Zi) pour i = 1..6
– Pré-condition : Les guides virtuels sont activés dès que le premier guide “Guide
1” est activé. En effet, ce guide est attaché à l’objet à saisir (figure 4.17-(C)), alors
que le “Guide 2” est attaché au “Guide 1” (figure 4.17-(B)) et le “Guide 3” est
attaché au “Guide 2” (figure 4.17-(A)). Ceci forme une chaı̂ne de guides virtuels
permettant ainsi l’activation de toute cette chaı̂ne dès que le premier guide est ac-
tivé.
Au moment de l’apparition de ces guides, l’effecteur du robot se trouve déjà dans

la zone d’influence du premier guide (le volume du cylindre) et sur la cible atteinte
précédemment. Les contraintes qui déterminent la pré-condition sont données par
l’appartenance de l’extrémité de l’effecteur du robot “E aux volumes de chaque
guide virtuel :
109
(A) (B) (C)
Fig. 4.17 – Les propriétés des guides virtuels utilisés pour la saisie de l’objet cylindre
numéro 3.
Dans “Guide 1” :
X1 <= Xe <= X2
(4.7)
(Ye − Ya )2 + (Ze − Za )2 <= r12
avec A(Xa , Ya , Za ) le centre du disque de rayon r1 contenant “E” et
⎧
⎨ Xa = X e
Ya = Y1 (4.8)
⎩
Za = Z1
Y3 <= Ye <= Y4
(4.9)
(Xe − Xa )2 + (Ze − Za )2 <= r22
⎧
⎨ Xa = X 3
Ya = Ye (4.10)
⎩
Za = Z3
X5 <= Xe <= X6
(4.11)
(Ye − Ya )2 + (Ze − Za )2 <= r32
⎧
⎨ Xa = X e
Ya = Y5 (4.12)
⎩
Za = Z5
110
– Fonction : Chaque guide virtuel étant semi-autonome, la fonction de chaque guide

représente alors une combinaison des actions réalisées par l’opérateur “Déplacer
le robot”) et de la fonction de projection de l’extrémité de l’effecteur du robot “E”
sur le point “A”. Cette projection est représentée pour chaque guide comme suit :
⎧
⎨ Xe = X a
Ye = Ya (4.13)
⎩
Ze = Za
– Post-condition : La chaı̂ne de guides virtuels est désactivée, lorsque l’extrémité de
l’effecteur du robot se trouve à l’extérieur du troisième guide. En effet, ceci signifie
que l’objet vient d’être saisi (décroché) de son support. Cette post-condition peut
se résumer à :
Xe > X6 (4.14)
4.1.3.4.b Dépôt d’un objet

Pour déposer un objet saisi, l’opérateur rapproche l’effecteur du robot vers un des sup-
ports métalliques sur lequel doit être accroché cet objet.
Au moment où l’effecteur du robot se rapproche de l’un des supports, une chaı̂ne de guides
virtuels apparaı̂t pour l’aider à accomplir correctement cette tâche. Il s’agit d’un guide
virtuel composé de quatre guides simples, un cône représenté par“Guide 4”, suivi de trois
cylindres imbriqués “Guide 3”, “Guide 2” et “Guide 1” (figure 4.18-(A)).
Ces quatre guides sont disposés de telle sorte que l’effecteur du robot et l’objet saisi
puissent se déplacer sans provoquer des collisions avec le support métallique.
Guide 4 Guide 2 Mur métallique
R Guide 3 P4 r2
E rc
P6 r3 P5
P7 A E
P1 r1 P2 Y
P3 X Z
Guide 1 Crochet
Objet Cylindre (A)
Trajectoire réalisée par le robot virtuel

Trajectoire réalisée par le robot réel (B)
Fig. 4.18 – Le guide virtuel utilisé pour le dépôt d’un objet cylindre. (A) : Positionnement
des différents guides, avec le point E qui désigne l’extrémité de l’effecteur du robot et
le point A le centre du disque passant par le point E ; (B) : Exemple d’influence des
guides sur les trajectoires réalisées par les robots virtuel et réel.
111
Les propriétés de ces guides sont données par la figure 4.19, et nous présentons ensuite
la pré-condition, la fonction et la post-condition de ces guides.
Dans ce qui suit, le point Pi (figure 4.18-(A)) a pour coordonnées (Xi , Yi , Zi) pour
i = 1..7.
– Pré-condition : La chaı̂ne de guides virtuels est activée dès que le quatrième
guide “Guide 4” est activé. En effet, ce guide est attaché à un autre guide “Guide
3” (figure 4.19-(D)), le “Guide 3” est attaché au “Guide 2” (figure 4.19-(C)) et le
“Guide 2” est attaché au “Guide 1” (figure 4.19-(B)). L’assistance à l’opérateur
prend son effet à la fin du parcours du guide “Guide 1”, c’est pour cette raison que
le champ “Attachement” des propriétés de ce guide contient “Guide libre” (figure
4.19-(A)).
De la même façon que les précédentes tâches, les contraintes qui déterminent la
pré-condition sont données par l’appartenance de l’extrémité de l’effecteur du robot
“E” au volume de chaque guide virtuel par exemple :
X6 <= Xe <= X7
(4.15)
(Ye − Ya )2 + (Ze − Za )2 <= rc2
avec A(Xa , Ya , Za ) le centre du disque de rayon rc contenant “E et

Pour les guides 3, 2 et 1, les pré-conditions sont déterminées avec le même principe.
– Fonction : De la même façon que la tâche de saisie, la fonction de chaque guide

représente une combinaison des actions réalisées par l’opérateur “Déplacer le ro-
bot”) et de la fonction de projection de l’extrémité de l’effecteur du robot “E sur
le point “A . La figure 4.18-(B), illustre un exemple d’influence des guides virtuels
sur les déplacements des robots virtuel et réel. En effet, les actions de l’opérateur sur
le robot virtuel sont corrigés par le guide avant l’exécution par le robot réel. Cette
correction est représentée pour chaque guide par cette fonction de projection :
⎧
⎨ Xe = Xa
Ye = Ya (4.16)
⎩
Ze = Za
– Post-condition : La chaı̂ne de guides virtuels est désactivée, lorsque l’extrémité
de l’effecteur du robot se trouve, soit à l’extérieur du “Guide 4” (généralement en
reculant, avant le dépôt de l’objet), soit à l’extérieur du guide libre “Guide 1”. En
effet, ce dernier cas signifie que l’objet vient d’être déposé (accroché) sur un support.
Cette post-condition peut se résumer à :
⎧
⎨ Xe > X7
ou (4.17)
⎩
Xe > X1 et Ye <= Y 1
4.1.4 Mode Téléprogrammation de tâches

Les tâches présentées dans la section précédente (mode téléopération), sont réalisées
par l’opérateur en téléopérant les robot virtuel et réel. Il est aussi possible d’exécuter ces
112
(A) (B) (C) (D)
Fig. 4.19 – Les propriétés des guides virtuels utilisés pour le dépôt de l’objet cylindre
numéro 3 sur le support numéro 1.
tâches d’une manière automatique par les robots virtuel et réel.

En effet, dans le mode de téléprogrammation de tâches (désignation d’objectif), l’opérateur
désigne les tâches qu’il désire faire réaliser par les robots virtuel et réel en choisissant l’une
des tâches dans le menu “TELEPROGRAMMATION” (figure 4.7-(C)).
Aprés avoir choisi une tâche, l’opérateur lance l’exécution en activant le bouton “Déma-
rrer téléprog” (figure4.7-(A)). Le rôle de l’opérateur consiste donc à superviser l’exécution
de cette tâche par les deux robots virtuel et réel. Il peut aussi intervenir pour arrêter cette
exécution s’il le désire, en activant le bouton “Arrêter téléprog” dans le tableau de bord
de l’interface du système ARITI (figure4.7-(A))
Les schémas de fonctionnement des différentes tâches de téléprogrammation sont
données dans l’annexe B
4.1.5 Mode Télésupervision et Télécoopération

Ce mode de télétravail, permet à plusieurs opérateurs connectés au système ARITI de
participer à la réalisation d’une tâche. Ce principe de télétravail est décrit dans le chapitre
précédent (3.3).
Il existe plusieurs possibilités permettant aux opérateurs de participer à une mission.
Dans cette section, nous considérons que la mission fait participer une équipe de quatre
opérateurs.
Considérons que la mission est constituée par les tâches suivantes :
– T1 : Atteindre l’objet numéro 3 se trouvant sur le support numéro 3.

– T2 : Saisir l’objet numéro 3 depuis le support numéro 3.
– T3 : Déposer l’objet saisi numéro 3 sur le support numéro 1.
– T4 : Remettre l’objet déposé sur son support d’origine (Atteindre l’objet numéro
3 sur le support numéro 1, le saisir et le déposer sur le support numéro 3). Cette
dernière tâche consiste à annuler les tâches T1 , T2 et T3 .
113
Considérons l’organisation de l’équipe comme suit :
L’opérateur OPi réalise la tâche Ti pour i = 1..4. Il est appelé “Maı̂tre” s’il a le
contrôle du robot réel, sinon il est appelé “Superviseur”. Le tableau suivant illustre
l’exécution de cette mission avec ce mode de télétravail.
Opérateur/Tâche T1 T2 T3 T4
Op1 Maı̂tre Superviseur Superviseur Superviseur
Op2 Superviseur Maı̂tre Superviseur Superviseur
Op3 Superviseur Superviseur Maı̂tre Superviseur
Op4 Superviseur Superviseur Superviseur Maı̂tre
Tab. 4.1 – Exemple d’organisation d’une équipe pour la réalisation d’une mission de
téléopération en coopération
4.2 Télétravail avec un robot mobile

Il s’agit d’une application en cours de réalisation qui consiste à téléopérer un ro-
bot mobile en utilisant le système ARITI. En effet il est possible d’ajouter au système
existant quelques modules (modèle virtuel du robot mobile, module client/serveur com-
mande) pour pouvoir contrôler un robot mobile, ou encore contrôler les deux robots si-
multanément. La figure 4.20 montre une vue générale de la mise à jour du système ARITI,
avec en pointillé les modules ajoutés.
Robot manipulateur Robot mobile virtuel

Guides virtuels
virtuel
Client commande Client image Client commande
Internet / Intranet / HF
Serveur commande
Serveur commande Serveur image
Planification Navigation Localisation
Robot manipulateur réel Caméra 1 Caméra 2 Robot mobile réel
Site esclave du robot manipulateur Site esclave du robot mobile
Fig. 4.20 – Mise à jour de l’architecture du système ARITI pour le contrôle d’un robot
mobile
Cette application nous permet d’un côté, d’étudier le comportement du système ARITI
vis à vis d’un robot mobile téléopérable et pouvant être autonome (dans ce cas le contrôle
114
4.2. TELETRAVAIL AVEC UN ROBOT MOBILE
devient semi-autonome). De l’autre coté, elle permet d’étudier comment une IHM basée
sur des techniques de la réalité virtuelle/augmentée peut contribuer à l’amélioration des
performances des personnes handicapées (Otmane et al., 2000d).
En effet, le système devient semi-autonome, du moment que le robot mobile possède

déjà une certaine autonomie, telle que l’évitement d’obstacle (capteurs ultrason), planifi-
cation, navigation et localisation. En effet, la planification permet au robot de déterminer
une trajectoire à suivre pour atteindre un but (un point dans l’environnement) désigné
par l’opérateur. La navigation, permet au robot mobile d’atteindre le but avec évitement
d’obstacles. La localisation quant à elle, permet de déterminer la position et l’orientation
du robot dans son environnement grâce aux capteurs odométriques.
Dans cette section, nous décrivons deux robots mobiles avec lesquelles nous travaillons
ainsi que l’interface homme machine permettant le contrôle du robot mobile utilisé avec
ARITI. Nous présentons ensuite quelques guides virtuels utilisés afin d’assister l’opérateur
à téléopérer le robot mobile pour traverser une porte.
4.2.1 Description des robots mobiles

Le premier robot est une base mobile qui fait 30 cm de diamètre (figure 4.21-(A)) et
le deuxième est constitué d’une base mobile (qui a la largeur d’un fauteuil roulant) sur
laquelle est embarqué un bras manipulateur de type MANUS (figure 4.21-(B)). Les deux
robots possèdent une ceinture de huit capteurs ultrason et une caméra qui peut réaliser
deux rotations.
Bras MANUS
Caméra
(A) (B)
Fig. 4.21 – Les images des deux robots mobiles utilisés. (A) : le robot utilisé avec le
système ARITI, (B) : le robot destiné au projet d’assistance aux personnes handicapées
4.2.2 Description de l’IHM

De la même façon que l’interface donnée dans la section précédente (4.1 dans la figure
4.5), l’interface pour contrôler le robot mobile (figure 4.21-(A)) est constituée de quatre
parties.
115
Une partie pour la réception d’images vidéos (pas de superposition du modèle virtuel
sur l’image réelle), deux parties pour représenter le robot mobile et son environnement
dans un mode virtuel et la quatrième partie constitue le tableau de bord de l’interface.
Ce dernier, permet à l’opérateur de :
– Choisir l’un des deux modes de contrôle, manuel (téléopération) ou navigation (semi-
autonome).
– Changer de points de vue de la caméra virtuelle.
– Créer et utiliser des guides virtuels.
La figure 4.22 montre L’IHM utilisée pour le contrôle et la supervision du robot mobile.
La fenêtre en haut à gauche, réceptionne des images vidéo envoyées par une caméra qui
visualise le robot réel et son environnement (cette caméra peut être remplacée par celle
embarquée sur le robot mobile). La fenêtre en haut à droite (figure 4.22), représente un
point de vue virtuel de la scène obtenue par une caméra virtuelle placée en hauteur (cette
caméra peut être déplacée ou tournée suivant les trois axes X, Y, Z).
La fenêtre en bas à gauche (figure 4.22), représente un point de vue virtuel donné par une
caméra embarquée sur le robot mobile (nous permet de voir ce que voit le robot mobile
virtuel).
Fig. 4.22 – L’IHM utilisée pour le contrôle et la supervision du robot mobile.
4.2.3 Guides virtuels pour traverser une porte

Dans cette section, nous présentons deux types de guides virtuels pouvant être utilisés
pour traverser une porte par le robot.
Le premier type est constitué de deux plans parallèles et répulsifs, placés de telle sorte que
le robot mobile ne puisse pas toucher les deux murs qui forment un passage représentant
116
4.2. TELETRAVAIL AVEC UN ROBOT MOBILE
une porte. Le deuxième type de guide est dit attractif, représenté sous forme d’une tra-
jectoire générée par une B-Spline.
4.2.3.1 Tâche avec deux plans répulsifs
Dans cette tâche, l’opérateur téléopère le robot réel via le robot virtuel. Il déplace le
robot virtuel jusqu’au couloir formé par les deux guides virtuels et tente de traverser la
porte. En effet, ce couloir virtuel permet au robot de se déplacer uniquement suivant des
trajectoires qui sont possibles à l’intérieur. Les deux plans répulsifs qui forment ce couloir
n’autorisent pas le robot virtuel à les traverser.
La figure 4.23 montre l’intervention des deux guides virtuels lorsque le robot mobile
tente de traverser une porte.
(A) (B)
Fig. 4.23 – Illustration de la téléopération d’un robot mobile avec assistance de deux
guides virtuels répulsifs sous forme de plans. (A) : Le robot mobile subit l’influence des
deux guides, (B) : le robot traverse la porte.
Les propriétés des deux guides virtuels sont données par la figure 4.24-(A) et 4.24-(B)
4.2.3.2 Tâche avec une courbe B-Spline attractive
Dans ce cas, l’opérateur téléopére le robot en lui faisant suivre une seule et unique
trajectoire. Cette trajectoire est générée initialement par une B-Spline (présentée dans la
section 2.2.1.3) et ensuite elle est modifiée (déformée) à la convenance de l’opérateur.
Ce type de guide virtuel, contraint le robot mobile à suivre une trajectoire précise que
l’opérateur a choisi. Cette trajectoire peut être modifiée en ligne par l’opérateur s’il le
désire.
La figure 4.25 montre une simulation du parcours réalisé par le robot mobile le long
de ce guide virtuel. Nous présentons ici les captures d’écran de la fenêtre en haut à droite
de l’interface (figure 4.22).
Les propriétés de ce guide sont données par la figure 4.26.
117
(A) (B)
Fig. 4.24 – Propriétés des deux guides virtuels utilisés pour traverser une porte par le
robot mobile.
(A) (B)
(C) (D)
Fig. 4.25 – Simulation du parcours d’une B-Spline par le robot mobile virtuel. (A) : l’état
initial, (B) : pendant le parcours, (C) : le robot traverse la porte, (D) : l’état final
118
4.3. AUTRES APPLICATIONS POTENTIELLES
Fig. 4.26 – Propriétés du guide virtuel généré par une B-Spline
4.3 Autres applications potentielles

Il existe de nombreux secteurs d’activité (nucléaire, spatial, médecine, maintenance,
enseignement...) où ce type de télétravail (télétravail, télétravail coopératif et l’utilisation
des techniques de réalité virtuelle sur des machine à faible coût) peut apporter beaucoup.
4.3.1 Nucléaire
Sur les sites nucléaires, les robots et les systèmes téléopérés sont utilisés pour diminuer
les doses de rayonnement, les contraintes physiques et/ou les risques pour les intervenants.
La plupart des machines utilisées (pour l’IHM, Client/Serveurs, etc.) sont trop onéreuses
du fait que les outils de développement et de simulation en réalité virtuelle sont fiables
et stables sur ces machines. Par conséquent, les IHMs ne sont pas portables et donc la
supervision et le contôle d’un système (robot esclave par exemple) ne peut se faire que sur
la même machine cliente (machine maı̂tre). Si cette dernière tombe en panne lors d’une
mission de téléopération, il devient très difficile et encore très coûteux de reprendre à
nouveau la mission surtout si la mission est vraiment urgente. Par ailleurs, il est difficile
et très coûteux d’envisager un télétravail coopératif sachant que le système maı̂tre ne
fonctionne que sur le même type de machine.
De nos jours, il existe des ordinateurs personnels plus performants (avec une puissance
qui ne cesse d’augmenter), sous des environnements multi-tâches et multi-utilisateurs (tels
que Linux ou encore Linux temps réel). De même, la maturité des outils de simulation
sur PC (OpenGL, VRML, etc) et la stabilité des outils développement sur Internet en
particulier le Langage Java offre la possibilité d’étendre les techniques de téléopération
vers le télétravail coopératif.
119
Le laboratoire CEREM1 (Centre d’Etude et de Recherche des Matériaux) de la DTA

(Direction des Technologies Avancées) envisage en perspective l’exploitation de cette voie
pour étendre leurs techniques de téléopération. En effet ils ont annoncé que dans un futur
proche, le développement des communications sur les réseaux généralistes comme Inter-
net, sont une formidable opportunité pour étendre les techniques de téléopération, afin
d’aborder le domaine en pleine expansion du télétravail et du travail coopératif.
CEREM participe en particulier sur ce sujet, au pôle TRV (Téléopération et Réalité Vir-
tuelle) du programme de recherche CNRS “ machines Intelligentes” avec le Laboratoire de
Robotique de Paris (LRP de l’Université de Versailles) et le Centre d’Etudes en Mécanique
d’Ile de France (CEMIF de l’Université d’Evry Val d’Essonnes).
4.3.2 Médical
L’utilisation des systèmes de télétravail, peut être intéressante dans différents niveaux
d’applications médicales. En effet, la Télésupervision par exemple permettra aux étudiants
en médecine (se trouvant dans le même établissement ou encore dans le monde entier)
d’assister en direct à une opération chirurgicale sans pour avoir à se déplacer en salle
d’opération.
Un autre exemple est celui d’assister le chirurgien par d’autres chirurgiens plus expérim-
entés ne se trouvant pas au même endroit (leurs conseils peuvent être utiles dans le cas
d’une opération délicate).
La téléchirurgie semble avoir un avenir prometteur, bien que l’idée de remplacer un chi-
rurgien par un robot n’est pas la priorité de tout le monde. Mais ce domaine en cours
de maturité peut trouver rapidement sa place en mettant le système expérimental à la
disposition des autres chercheurs dans le but d’un télétravail coopératif.
4.3.3 Enseignement
En plus de l’enseignement théorique donné aux étudiants (formation aux méthodes
et aux techniques de la robotique, réseau et informatique, etc.), des Travaux Pratiques
(TPs) moins coûteux peuvent être réalisés en utilisant de tels systèmes.
Prenons par exemple un cours de robotique sur la calibration de caméras, après avoir
étudié les différentes méthodes, les étudiants peuvent expérimenter leurs méthodes et les
tester en temps réel pendant une séance de TP. En effet, les étudiants ne sont pas obligés
d’avoir une caméra réelle à disposition, puisque une image réelle capturée suffit.
Comme il s’agit du télétravail, d’autres établissements ne disposant pas de moyens

(caméras, robot, etc.) peuvent très bien profiter de cet enseignement à condition que
l’établissement propriétaire du système les autorise.
Il ne peut pas y avoir de défaillance du système original du moment que les étudiants
tarvailleront sur des processus clones (une copie du système original, figure 4.27 ) et
éventuellement un clone par étudiant afin d’éviter d’un côté, les mélanges et les conflits
d’accés aux ressources du système et de l’autre côté un travail individuel sécurisé.
1
http ://www-dta.cea.fr/CEREM/UK/Pages/teleoper.htm
120
4.4. BILAN
Etudiants ET1 ET2 . . . . . . . . ETN
Clones du CL1 CL2 . . . . . . . . CLN Système de

processus client télétravail
CL
Intranet / Internet
SR
Clones du SR1 SR2 . . . . . . . . SRN

processus serveur
Fig. 4.27 – Illustration du télé-enseignement
4.4 Bilan
Dans ce chapitre, nous avons présenté quelques applications pouvant bénéficier d’un
système de télétravail via Internet. Nous avons cependant souligné la nécessité d’avoir
d’un côté, une interface administrateur pour la maintenance et la mise à jour d’un tel
système et de l’autre côté une interface destinée aux utilisateurs du système.
Nous avons décrit certaines tâches réalisées suivant le mode de télétravail choisi, d’un
côté, les tâches de téléopération (saisie/dépôt d’objets, etc.) où l’opérateur s’il le désire
peut être assisté par des guides virtuels. D’un autre côté, l’opérateur peut télétravailler
à niveau plus haut, pour cela, il spécifie seulement la tâche à faire exécuter par les ro-
bots virtuel et réel simultanément (il s’agit dans ce cas des tâches pré-programmées).
Enfin, si une mission nécessite l’intervention de plusieurs opérateurs simultanément dans
le but d’un travail coopératif par exemple, un opérateur prend le contrôle du robot réel
pendant que les autres supervisent en virtuel et en réel les actions de celui-ci. Dans ce
dernier cas, le contrôle des robots virtuel et réel est partagé entre les différents opérateurs.
Nous avons montré la flexibilité et l’ouverture du système ARITI pour d’autres appli-
cations, en utilisant un robot mobile. En effet, une application sur un robot mobile a été
réalisée en s’inspirant de l’existant et en rajoutant essentiellement le module contenant
les nouveaux modèles virtuels (environnement et robot mobile) ainsi que le module de
client/serveur commande (pour gérer les interactions avec le robot mobile réel).
Nous avons cité d’autres domaines d’application dans lesquels un système de télétravail
ou de travail coopératif via Internet peut être intéressant, mais cette liste n’est pas ex-
haustive.
Par ailleurs, il est nécessaire d’une part, d’évaluer les performances des tâches réalisées
avec ce système ainsi que les différents algorithmes de compression d’images utilisés.
D’autre part, d’analyser le comportement de ce système et les performances de l’archi-
tecture client/serveur du système ARITI à la fois, en fonction de la distance séparant
le site maı̂tre (client) du site esclave et en fonction du nombre d’opérateurs utilisant si-
multanément le système pour un travail coopératif. Cette partie est présentée et discutée
dans le chapitre suivant.
121
122
Chapitre 5
Evaluation et Expérimentation
Le chapitre précédent, nous a permis de présenter essentiellement, deux applications

réalisées en utilisant le système de télétravail ARITI, à savoir, la télémanipulation avec
un robot à 4 ddl et la téléopération d’un robot mobile. Nous avons présenté certaines
tâches suivant le mode de télétravail choisi, téléopération, téléprogrammation de tâches
et télécoopération/télésupervision (dans le but d’un travail coopératif par exemple). Nous
avons décrit les guides virtuels d’assistance à la téléopération ainsi que les propriétés as-
sociées.
Dans ce chapitre, nous présentons les expérimentations réalisées avec le système ARITI
utilisant un robot esclave à 4 ddl (site expérimental se trouvant dans notre laboratoire).
Les modes de télétravail utilisés pour ces expérimentations sont la téléopération et la
télécoopération/télésupervision.
Dans la première section de ce chapitre, nous évaluons les performances de certaines

tâches avec le mode de téléopération en utilisant l’interface de ARITI. Pour celà, plusieurs
sujets (opérateurs humains) ont participé aux différentes expérimentations qui consistent
à réaliser des missions de téléopération d’une part, sans assistance des guides virtuels et
d’autre part, avec assistance des guides virtuels répulsifs ou attractifs.
La deuxième section consiste à évaluer les différents algorithmes de compression d’ima-

ges vidéo et ceci suivant que l’image vidéo présente peu ou beaucoup de mouvements. Il
s’agit d’étudier d’une part, les taux de compression fournis par les différentes méthodes
de compression d’images, sachant que les images compressées seront envoyées via Inter-
net aux différents clients connectés au système ARITI. D’autre part, nous étudions les
temps de compression d’images pour chaque méthode utilisée. Ces évaluations vont nous
permettre de déterminer un algorithme de compression implanté dans le serveur d’images
permettant ainsi de choisir automatiquement la méthode à utiliser suivant la dynamique
des images (images avec peu ou beaucoup de mouvements).
123
CHAPITRE 5. EVALUATION ET EXPERIMENTATION
Dans la troisième section, nous étudions le comportement du système et les perfor-

mances de l’architecture client/serveur du système ARITI d’une part, en fonction de
la distance séparant le site maı̂tre (client) du site esclave. D’autre part, en fonction du
nombre d’opérateurs utilisant simultanément le système pour un travail coopératif avec
un retour prédictif distribué.
5.1 Evaluation des performances des tâches avec l’in-

terface de ARITI
5.1.1 Conditions expérimentales
Le site maı̂tre est un PC cadencé à 233 MHZ connecté à Internet sur lequel un
opérateur contrôle un robot virtuel. L’interface utilisée est celle déstinée à l’opérateur
dit “administrateur” décrite dans le chapitre précédent (chapitre Applications 4.1) et
représentée par la figure 4.5.
Le robot esclave utilisé est un banc d’essai à 4 ddl (2 rotations et deux translations),
transformé en un robot manipulateur décrit aussi dans le chapitre 4.1 et présenté par la
figure 4.1. Les objets à manipuler sont des cylindres en polystyrènes (numérotés 1, 2 et
3) accrochés sur des supports métalliques.
L’effecteur du robot est constitué d’une pointe métallique avec laquelle s’effectue la saisie
des objets en polystyrène. La figure 5.1 donne une vue rapprochée de l’effecteur du robot
et des trois cylindres en polystyrène.
Mur métallique Objets en polystyrène
Effecteur
du robot
Support (crochet)
métallique
Fig. 5.1 – Vue rapprochée de l’effecteur du robot et des trois cylindres en polystyrène.
L’expérimentation est réalisée avec trois missions qui consistent à réaliser les tâches
suivantes :
– Atteindre le cylindre numéro 1.
– Saisir le cylindre numéro 1 depuis son support.
– Déposer le cylindre numéro 1 sur le support numéro 3.
Le déroulement de chaque mission se fait généralement en deux étapes, préparation
de la mission par le robot virtuel, ensuite l’exécution par le robot réel.
124
DE ARITI
Soit Tp , le temps nécessaire à l’opérateur pour préparer une mission avec le robot
virtuel, et Te , le temps nécessaire pour exécuter la mission par le robot réel. Le temps de
la réalisation de la mission est donné alors par le temps total de la mission Tm :
Tm = Tp + Te (5.1)
Les vitesses de déplacement et de rotation des différentes composantes du robot réel
sont constantes (16.6 cm/s pour les translations et 16.6 degrés/s pour les rotations, voir
le tableau 5.1).
Composantes du robot réel Vitesse

Grande base 16.6 cm/s
Support 16.6 cm/s
Tige 16.6 degrés/s
Equerre 16.6 degrés/s
Tab. 5.1 – Vitesses de déplacement et de rotation des composantes du robot réel
Etant donné que la cible à atteindre est un point 3D situé à une distance d (constante)
par rapport à la position de l’effecteur du robot. Alors le temps d’exécution Te est iden-
tique pour chaque mission consistant à atteindre le cylindre numéro 1. Cependant, le
temps de réalisation de la mission (Tm ) pour atteindre le cylindre numéro 1 par exemple,
dépend complètement du temps de la préparation de cette mission avec le robot virtuel
(Tp ).
La vitesse du déplacement du robot virtuel se fait suivant l’endroit où se trouve

l’extrémité de son effecteur. En effet, l’environnement virtuel est découpé en trois zones
(zone 1, zone 2 et zone 3) représentées dans la figure 5.2. Les pas de déplacement et de
rotation du robot virtuel varient selon que l’effecteur du robot se rapproche ou s’éloigne
de la cible.
Soit (X2 , Y2 , Z2 ) les coordonnées du point P2 appartenant au premier plan de la

deuxième zone, et (X3 , Y3 , Z3), les coordonnées du point P3 appartenant au premier plan
de la troisième zone. Soit aussi (Xcible , Ycible , Zcible ) les coordonnées du point cible situé
à la périphérie de l’un des objets cylindres. Si (Xe , Ye , Ze ) sont les coordonnées du point
“E représentant l’extrémité de l’effecteur du robot virtuel, alors les conditions pour que
l’extrémité de la tige se trouve dans chacune des zones sont données par :
⎧
⎨ Xe ∈ Zone1 Xe >= X2
Xe ∈ Zone2 X1 <= Xe < X2 (5.2)
⎩
Xe ∈ Zone3 Xcible <= Xe < X1
les caractéristiques de déplacement et de rotation du robot virtuel sont données par
le tableau 5.2.
Dans tous les tests réalisés que nous allons présenter par la suite, dix opérateurs
(étudiants IUP, stagiaires, doctorants) n’ayant subi aucun apprentissage des tâches ont
participé à celles-ci. Chaque opérateur effectue une série de dix tests. Le mode de travail
est la téléopération et le contrôle du robot se fait avec le clavier.
125
Cible virtuel Objet cylindre 1
Effecteur du robot virtuel
E Mire
Crochet virtuel
(support virtuel)
X Z
P2 P3
Zone 1 Zone 2 Zone 3
Fig. 5.2 – Illustration du découpage de l’environnement virtuel en trois zones
Pas Zone 3 Zone 2 Zone 1

Translation (cm) 2 0.4 0.1
Rotation (degrés) 2 0.4 0.1
Tab. 5.2 – Les pas de déplacement et de rotation du robot virtuel
5.1.2 Atteinte d’une cible

La tâche consiste à faire atteindre l’objet cylindre numéro 1, par le robot à partir de
sa position initiale. Cette position de repos se trouve à 1 m environ de l’objet à atteindre.
Pour évaluer cette tâche, trois types de tests ont été réalisés. Le premier type de tests
est réalisé sans guide virtuel. Dans le second, l’opérateur utilise un guide virtuel répulsif,
l’effecteur du robot peut se déplacer librement à l’intérieur du guide, mais il ne peut pas
le traverser. Le troisième type de tests est réalisé en utilisant un guide virtuel attractif,
dans ce cas, les actions de l’opérateur sont combinées avec une fonction d’attraction vers
l’axe central du guide. En effet, dans ce cas, l’extrémité de l’effecteur du robot est projeté
à chaque mouvement de l’opérateur, sur l’axe central du guide virtuel.
5.1.2.1 Tests sans guide virtuel
Pour permettre à l’opérateur de voir où se trouve la cible, un signal visuel est affiché
(petit cercle autour de la cible) à la périphérie du cylindre numéro 1 (voir la figure 5.3).
Pendant ces tests, les éventuelles collisions de l’effecteur du robot avec le support
métallique (où se trouve l’objet à atteindre) ont été gérées. Le nombre de collisions est
calculé pour chaque opérateur et pour chaque test (figure 5.4-(B)). Dès qu’une collision
se produit, le message “collision” apparaı̂t sur l’écran ainsi qu’une flèche à l’endroit de la
collision (figure 5.4-(A)). Ces informations permettent à l’opérateur de corriger ses mou-
vements.
La figure 5.4-(B), montre qu’il y a en moyenne 14.9 collisions pour les dix tests soit
une collision par test.
Nous avons aussi mesuré les imprécisions avec lesquelles la cible a été atteinte par l’ef-
fecteur du robot, ainsi que le temps mis par chaque opérateur pour atteindre la cible. La
126
DE ARITI
Signal visuel
autour de la cible
Repère
Effecteur de robot virtuel
Fig. 5.3 – Illustration du signal visuel utilisé pour atteindre le cylindre numéro 1
(A) (B)
Fig. 5.4 – Gestion des collisions pendant que l’opérateur essaie d’atteindre le cylindre
numéro 1. (A) : détection des collisions, (B) : le nombre total de collisions réalisé par
chaque opérateur.
127
figure 5.5-(A), montre la moyenne des imprécisions (en mm) sur les dix tests pour chaque
opérateur par rapport à X, Y et Z. L’imprécision moyenne de tous les opérateurs est
donnée par la figure 5.5-(B).
(A) (B)
Fig. 5.5 – Les imprécisions obtenues lorsque la cible est atteinte. (A) : la moyenne des dix
tests pour chaque opérateur suivant X, Y et Z, (B) : la moyenne sur les dix opérateurs
suivant X, Y et Z.
Nous remarquons que les imprécisions sur l’axe “Y” sont plus importantes, elles cor-
respondent aux erreurs de rotation en site de l’effecteur du robot. En effet, pour éviter de
prendre le risque de provoquer des collisions entre l’effecteur du robot et le support où se
trouve l’objet à atteindre, les différents sujets (opérateurs) préfèrent maintenir l’effecteur
éloigné du support.
Nous avons mesuré les temps moyens et l’écart type (en secondes) de réalisation de
la tâche d’atteinte d’une cible. La figure 5.6 donne la moyenne des temps obtenus par les
dix opérateurs à chaque essai ainsi que l’écart type.
22.21
9.92
Fig. 5.6 – Le temps moyen pour atteindre la cible (cylindre numéro 1) à chaque essai.
La figure 5.6, montre que, pendant les trois premiers tests les temps moyen sur les dix
opérateurs sont plus important (35 , 23 et 25 sec). Ce temps à tendance à diminué dans la
suite des autres tests, ce qui montre en effet, l’adaptation des opérateurs à l’interface de
128
DE ARITI
commande ainsi que leur apprentissage. Cependant, le temps moyen sur les dix opérateurs
et sur les dix tests pour atteindre le cylindre numéro 1, est de 22.21 sec.
5.1.2.2 Tests avec guide virtuel répulsif
Le guide virtuel utilisé est un cône (appelé “tube” dans la librairie des guides virtuels)
attaché à l’objet cylindre numéro 1. Ce guide virtuel est activé en répulsion, cependant,
lorsque l’effecteur du robot virtuel se trouve à l’intérieur du guide, ses degrés de libertés
sont limités au volume de ce guide qui défini l’espace de travail (l’effecteur du robot ne
peut pas traverser le guide).
La figure 5.7 montre ce guide virtuel attaché au cylindre numéro 1.
Guide virtuel Cylindre numéro 1
Effecteur
du robot
Fig. 5.7 – Utilisation d’un guide virtuel pour atteindre le cylindre numéro 1
Les imprécisions obtenues avec ce guide virtuel sont représentées dans la figure 5.8.
(A) (B)
Fig. 5.8 – Les imprécisions obtenues lorsque la cible est atteinte en utilisant un guide
virtuel repulsif. (A) : la moyenne des dix tests pour chaque opérateur suivant X, Y et Z,
(B) : la moyenne sur les dix opérateurs suivant X, Y et Z
Contrairement aux tests réalisés précédemment (sans assistance d’un guide virtuel),
les risques de collisions sont exclus. Par ailleurs, les imprécisions pour atteindre la cible
avec assistance d’un guide virtuel répulsif, sont nettement inférieures par rapport à l’axe
“Y” si nous les comparons aux tests réalisés sans guide virtuel. En effet, la moyenne des
129
imprécisions avec guide répulsif est de 0.48 mm contre 2.44 mm sans guide virtuel. Cette
diminution s’explique par le fait que les opérateurs ont tendance à rapprocher davantage
l’effecteur du robot vers le support virtuel, sachant que le guide les empêcherait de rentrer
en collision avec ce support.
Nous remarquons aussi que les imprécisions sur l’axe des “X” est de 1 mm pour tous
les opérateurs (la cible est atteinte de la même façon pour tous). Ceci est une conséquence
directe sur le comportement identique concernant le positionnement de l’effecteur du ro-
bot à l’intérieur du guide virtuel. En effet, comme l’effecteur du robot est souvent po-
sitionné juste au dessus du support virtuel (mais toujours à l’intérieur du guide), pour
déplacer l’effecteur vers la cible, une translation en “X” suffit. Cependant, comme le pas
de déplacement est le même dans cette zone, alors ils y arrivent tous de la même façon.
Par contre, le temps nécessaire pour atteindre le cylindre numéro 1 avec un guide
virtuel répulsif est nettement plus important que sans guide virtuel. Le temps moyen sur
les dix opérateurs et sur les dix tests est de 31.48 sec (figure 5.9) contre 22.21 sec lorsque
l’opérateur n’est pas assisté par un guide virtuel répulsif. Cette perte de temps, est tout
simplement provoquée par des différentes collisions entre l’effecteur du robot et le guide
virtuel répulsif. En effet, ce dernier à tendance à repousser l’effecteur du robot à chaque
fois que l’opérateur tente de le traverser involontairement.
Par ailleurs, bien que ce type de guide (répulsif), fournit une sécurité pour l’effecteur
du robot (pas de collisions avec le support), son utilisation rend l’apprentissage difficile
(voir la courbe de la figure 5.9).
31.48
19.23
Fig. 5.9 – Le temps moyen pour atteindre la cible (cylindre numéro 1) à chaque essai en
utilisant un guide virtuel répulsif
5.1.2.3 Tests avec guide virtuel attractif
Dans cette série de tests, les opérateurs utilisent un guide virtuel attractif. Il s’agit du
même guide virtuel utilisé dans la série de tests précédente, sauf que dans ce cas le guide
devient actif en attraction. En effet, dès que l’effecteur du robot se trouve à l’intérieur
de ce guide, les actions de l’opérateur sont combinées avec une fonction d’attraction vers
l’axe central du guide.
130
DE ARITI
Les imprécisions obtenues avec ce guide virtuel sont représentées dans la figure 5.10.
Fig. 5.10 – Les imprécisions obtenues suivant X, Y et Z, lorsque la cible est atteinte en
utilisant un guide virtuel attractif
La figure 5.10, montre que les imprécisions pour atteindre le cylindre numéro 1 avec
un guide virtuel attractif, sont très petites sur les axes “X” , “Y” (0.25 mm et 0.2 mm res-
pectivement) et sont nulles sur l’axe “Z”. En effet, le fait d’avoir un guide virtuel attractif
dont la fonction consiste à projeter l’extrémité de l’effecteur du robot sur l’axe central de
ce guide et le fait, que cet axe passe par le point cible en question, alors la composante
en “Z” de l’extrémité de l’effecteur du robot ne peut être que zéro. Par ailleurs, la cible
est atteinte (en “X” et “Y”) de la même façon par tous les opérateurs, du moment qu’ils
subissent tous la même fonction du guide.
En plus, l’utilisation de ce type de guide virtuel (attractif), fourni un temps d’at-

teinte de la cible très petit par rapport aux tests effectués sans guide et avec guide virtuel
répulsif. Le temps moyen obtenu sur les dix opérateurs et sur les dix tests, est de 7.7 sec
(figure 5.11) contre 31.48 sec (avec guide répulsif) et 22.21 sec (sans assistance du guide
virtuel).
D’un autre côté, ce guide attractif, fourni un très bon apprentissage comme le montre
la figure 5.11.
5.1.3 Saisie et dépôt d’un objet

Dans cette section, nous présentons les tests réalisés en utilisant des guides virtuels
(répulsifs ou attractifs) pour saisir le cylindre numéro 1 depuis son support, pour ensuite
le déposer sur le support numéro 3.
5.1.3.1 Saisie du cylindre numéro 1
Dès que le cylindre numéro 1 est atteint (tâche atteinte d’une cible), un guide virtuel
composé de trois guides simples apparaı̂t pour assister l’opérateur à prendre l’objet cy-
lindre et le sortir de son support métallique.
Ce guide virtuel et son formalisme sont décrits dans le chapitre précédent, voir aussi la
figure 4.16 dans la section 4.1.
131
7.7
2.7
Fig. 5.11 – Le temps moyen pour atteindre la cible (cylindre numéro 1) à chaque essai
en utilisant un guide virtuel attractif
La figure 5.12 montre ce guide virtuel attaché à l’objet cylindre numéro 1, permettant de
prendre ce cylindre et de le sortir de son support métallique.
Guide de saisie Cylindre 1
Effecteur
du robot
Support
numéro 1
Fig. 5.12 – Utilisation d’un guide virtuel pour saisir et sortir le cylindre numéro 1 depuis
son support métallique.
La moyenne des temps sur dix opérateurs et à chaque essai pour réaliser cette tâche
est représentée par la figure 5.13. Avec un guide virtuel répulsif le temps moyen sur les
dix essais est de 12.78 sec alors que avec un guide virtuel attractif ce temps est diminué
(9.5 sec).
5.1.3.2 Dépôt du cylindre numéro 1 sur le support numéro 3
Afin de déposer l’objet saisi (cylindre numéro 1) sur un support métallique (numéro
3), l’opérateur dirige l’effecteur du robot (contenant l’objet) vers ce support. Un guide
virtuel composé de quatre guides simples apparaı̂t pour l’aider à déposer l’objet déjà saisi.
Cette opération consiste donc à décrocher le cylindre de l’effecteur du robot en utilisant
le support métallique numéro 3.
132
DE ARITI
12.8
9.5
8.01
4.23
(A) (B)
Fig. 5.13 – Le temps moyen pour saisir le cylindre numéro 1 à chaque essai : (A) en
utilisant un guide virtuel répulsif, (B) avec un guide virtuel attractif. En pointillé sont
représentées les moyennes pour les dix opérateurs.
Ce guide virtuel apparaı̂t au dessus du support numéro 3 comme le montre la figure

5.14.
^
Guide de dépot
Effecteur Cylindre Crochet

du robot numéro 1 numéro 3
Fig. 5.14 – Utilisation d’un guide virtuel pour déposer le cylindre numéro 1 sur le support
métallique numéro 3.
La moyenne des temps sur dix opérateurs et à chaque essai pour réaliser cette tâche est
représentée par la figure 5.15. Avec un guide virtuel répulsif le temps moyen sur les dix es-
sais est de 37.96 sec alors que avec un guide virtuel attractif ce temps est réduit à 16.86 sec.
A l’issu de ces différentes expérimentations, à savoir réaliser des missions de téléopérati-

on, sans assistance et avec assistance des guides virtuels (répulsifs ou attractifs), nous
avons essentiellement souligné et évalué quatre critères qui sont :
– Sécurité : Protéger le robot et les objets manipulés contre d’éventuelles collisions
vis à vis de l’environnement.
– Précision : Approcher l’objet à manipuler avec une bonne précision.
– Temps d’exécution : Réaliser la mission avec un meilleur temps.
133
37.9
26.5
16.8
(A) (B)
Fig. 5.15 – Le temps moyen pour déposer le cylindre numéro 1 sur le support numéro 3 à
chaque essai : (A) en utilisant un guide virtuel répulsif, (B) avec un guide virtuel attractif.
En pointillé sont représentées les moyennes sur les dix opérateurs
– Apprentissage : Faciliter l’apprentissage de la préparation de missions.

Par ailleurs, les résultats de ces expérimentations, ont montré d’une part, que l’inter-
face du système ARITI permet un apprentissage facile pour la préparation des missions de
téléopération. D’autre part, l’utilisation des guides virtuels garantit d’un côté, la sécurité
du robot et de son environnement et de l’autre côté, lorsque les guides virtuels sont ac-
tivés en attraction, ils fournissent une meilleure précision d’approche et un meilleur temps
d’exécution.
D’une manière générale, nous avons évalué l’interface et les outils d’assistance virtuels
pour la préparation et l’exécution des missions de téléopération. Nous allons maintenant
nous intéresser au retour d’images vidéo et essentiellement à l’évaluation des algorithmes
de compression d’images utilisés. Cette partie est présentée dans la section suivante.
5.2 Evaluation des algorithmes de compression d’im-

ages vidéo
Dans cette section nous présentons les résultats d’évaluation des algorithmes de com-
pression d’images utilisés. Nous allons évaluer essentiellement les taux et les temps de
compression d’image vidéo.
5.2.1 Conditions expérimentales

La capture d’images se fait sur un PC Pentium 233 MHZ via une carte d’acquisition
vidéo Matrox Meteor reliée à une caméra noir et blanc. La taille des images est de 49152
octets (256).
Deux algorithmes de compression sont utilisés (pour plus de détails, voir annexe A) :
– Gzip : Utilise la librairie “Zlib” supportée par la plupart des navigateurs Internet
(Gzib, www).
134
5.2. EVALUATION DES ALGORITHMES DE COMPRESSION D IMAGES VIDEO
– Huffman : Utilise un codage particulier, celui de représenter chaque élément de

l’image par une série de “0” et de “1” (codage binaire) (Binstock et Rex, 1995)
(Nelson et Gailly, 1996)
L’évaluation de ces algorithmes est faite sur une série de dix images vidéo capturées
(généralement les dix premières images). Un pré-traitement (différence entre deux images)
de l’image a été réalisé et combiné avec les deux méthodes de compression.
5.2.1.1 Evaluation des taux de compression d’image
Il s’agit ici de voir quelle méthode offre un meilleur taux de compression d’images.
Nous avons testé trois types de compression, “Gzip”, “Pré-traitement + Gzip” et “Pré-
traitement + Huffman”.
Des tests ont été réalisés suivant la dynamique de l’image (quantité de mouvements
dans l’image) c’est à dire, lorsque l’image présente peu de mouvements ou beaucoup de
mouvements.
Les résultats de compression donnés dans la figure 5.16, représente la taille moyenne
des dix premières images compressées par chaque méthode et suivant la dynamique de
l’image.
Fig. 5.16 – Evaluation des algorithmes de compression suivant la dynamique de l’image
Nous remarquons que l’algorithme de Huffman n’est utile que si les images à com-
presser ne contiennent pas beaucoup d’éléments différents (il est souvent précédé par un
pré-traitement comme le fait JPEG, MPEG par exemple).
Les résultats obtenus montre que lorsque l’image vidéo présente peu de mouvements la
méthode de compression “Pré-traitement + Huffman” donne un meilleur taux de compres-
sion, la taille de l’image est diminuée de 71%. Par contre, lorsque l’image présente beau-
coup de mouvements, c’est la méthode “Pré-traitement + Gzip” qui fournit le meilleur
taux de compression (44%).
Nous allons maintenant évaluer les temps de compression pour chaque méthode.
5.2.1.2 Evaluation des temps de compression d’image
Le temps que met chaque méthode pour compresser l’image est évalué sur les dix
premières images capturées. Cette évaluation fait intervenir les trois méthodes de com-
135
pression dans le cas où l’image présente peu de mouvements. Par contre lorsque l’image
présente beaucoup de mouvements, seulement deux méthodes sont utilisées (“Gzip”, “pré-
traitement + Gzip”). En effet, dans ce dernier cas la méthode “pré-traitement + Huffman”
ne présente pas d’interêt étant donné que son utilisation fournit un taux de compression
largement supérieur à la taille originale de l’image (300%).
Les figures 5.17 et 5.18, montrent respectivement les temps de compression necéssaires
pour chaque méthode avec peu de mouvements et beaucoup de mouvements dans les
images.
Nous remarquons que lorsque l’image présente peu de mouvements, la compression

“Pré-traitement + Huffman” fournit un meilleur temps, en moyenne “30ms contre “59
ms” pour “Pré-traitement + Gzip” et “80 ms” pour “Gzip” . En revanche, lorsque l’image
présente beaucoup de mouvements, le temps de compression par “Pré-traitement + Gzip”
est de “70 ms” contre “74 ms” pour “Gzip”.
Fig. 5.17 – Les temps de compression lorsqu’il y a peu de mouvements dans l’image.
Fig. 5.18 – Les temps de compression lorsqu’il y a beaucoup de mouvements dans l’image.
L’analyse des résultats obtenus nous a permis d’implanter un algorithme de choix au-
tomatique de la méthode de compression à utiliser. En effet, il suffit de déterminer un seuil
qui permet de départager l’appartenance de l’image à une des catégories peu ou beaucoup
de mouvements. Si l’image présente peu de mouvements alors la méthode “pré-traitement
136
CLIENT/SERVEUR DE ARITI
+ Huffman” est choisie, sinon c’est la méthode “pré-traitement + Gzip” qui sera utilisée.
Ce seuil, est déterminé expérimentalement par le nombre de pixels (niveau de gris)

différents dans l’image que nous avons appelé Nombre de Types d’Eléments dans l’image
(NTE).
Pour une image à 256 niveaux de gris ce seuil est “128”, si NTE est supérieur à 128 alors
l’image est considérée dans la catégorie des images présentant beaucoup de mouvements,
sinon elle est dans celles présentant peu de mouvements.
L’organigramme de choix automatique de la méthode de compression est donné par la
figure 5.19. Avec I désigne l’image brut, Ip l’image après pré-traitement, Iz image après
Gzip, Ipz image après pré-traitement et Gzip, Iph image après pré-traitement et Huffman.
Les codes “2”, “3” et “5”, représentent respectivement les types de compression “Gzip”,
“Pré-traitement + Gzip” et “Pré-traitement + huffman”.
Capure Image
Oui Première Non

image ?
I
Pre-traitement
I Ip
Oui NTE Non

> 128 ?
Ip Ip
Gzip Huffman
Iz / Ipz Iph
Code Image Code Image

2/3 Taille Iz / Ipz 5 Taille Iph
Envoi aux clients Envoi aux clients
Fig. 5.19 – Organigramme de choix automatique de méthodes de compression d’image.

l’image est envoyée aux clients avec le type de compression utilisé.
5.3 Evaluation des performances de l’architecture -

client/serveur de ARITI
De nombreuses expériences ont été réalisées afin d’évaluer les performances de l’archi-
tecture client/serveur du système ARITI. Une série de tests a été réalisée en locale au
sein même du laboratoire, et d’autres séries en moyenne et longue distance.
Nous avons étudié principalement les performances du serveur vis à vis de l’ensemble
des connexions qui pourraient avoir lieu. Nous avons mesuré à chaque fois le temps serveur
137
(Ts ) et le temps de réponse du processus client (Tr ). Nous considérons que le temps total
effectif (Tt ) est compris entre le temps de la réception d’une demande du client et le temps
de la réception d’une nouvelle demande de ce client, ce qui donne :
Tt = Ts + Tr (5.3)
Dans le cas du serveur d’image vidéo, le temps serveur est donné par :
Ts = Ti + Tc + Te (5.4)
avec
– Ti : temps de capture de l’image.
– Tc : temps de compression de l’image.
– Te : temps de l’envoi de l’image dans le buffer (zone mémoire) de la socket TCP/IP.
90
Fig. 5.20 – Evaluation du temps de capture d’images vidéo Ti avec dix images successives.
Le temps d’envoi dépend de la méthode de compression utilisée, et il varie de la même

façon que le temps de capture d’image représenté dans la section cf. § 5.2 (voir aussi les
figures 5.17, 5.18 ).
Fig. 5.21 – Evaluation du temps d’envoi Te suivant la dynamique de l’image. Le temps

représenté est une moyenne sur dix images envoyées.
138
Le temps de réponse du processus client est donné par :
Tr = δT + Td + δt (5.5)
avec
– δT : temps de transfert de l’image, il s’agit du délai Internet/Intranet et dépend
complètement de la bande passante.
– Td : temps de décompression de l’image du côté client.
– δt : temps d’envoi d’une nouvelle demande d’images au serveur. Il s’agit du temps
nécessaire pour le transfert du numéro de client (1 octet) vers le serveur.
Dans un premier temps nous présentons les résultats obtenus lorsque le système ARITI
est utilisé par un seul opérateur se connectant en local depuis une autre machine interne
au laboratoire. Par la suite, nous présentons les résultats obtenus lorsque l’opérateur se
trouve à moyenne (France, Italie, Espagne, etc.) et à longue distance (Canada, Washing-
ton, Argentine, Brésil, etc.).
Dans le but d’un télétravail coopératif, des tests avec plusieurs opérateurs connectés
simultanément au système, ont été réalisés en locale, moyenne et longue distance.
L’objectif de ces tests est d’un côté, d’analyser le comportement et les performances du
serveur image de ARITI, lorsque les sites clients se trouvent à des endroits différents dans
le monde, et pour cela, nous avons évalué le temps serveur (Ts ) et le temps de réponse
des clients (Tr ). De l’autre côté, nous avons mesuré les temps moyens necéssaires pour la
mise à jour, des images vidéo et des environnements virtuels par rapport aux différents
site clients.
5.3.1 Connexion avec un seul opérateur

5.3.1.1 Connexion locale
Dans ce cas, l’opérateur est connecté au système ARITI en utilisant un PC Pen-

tium 350 MHZ. Le débit réseau théorique en interne est de 1.25 MO/s (méga octets par
seconde), alors qu’en pratique ce débit est inférieur à 700 KO/s (Kilo Octets par seconde).
Suivant la méthode de compression d’image utilisée et suivant la dynamique de l’image

(peu ou beaucoup de mouvements), les temps serveur (Ts ) et réponse du client (Tr ) ont
été calculés sur une série de dix premières images vidéo (comptée à partir de la deuxième
image car la première ne subit pas de pré-traitement) envoyées au site client.
Dans ce type de connexion (locale), nous constatons que le fait d’utiliser des images
avec peu ou beaucoup de mouvements, avec des méthodes de compression différentes, ne
présentent pas un écart important sur le temps total Tt (Éq. (5.3)). En effet, pour des
images brutes (sans compression), le temps total moyen est de 576 ms (0.104 sec + 0.472
sec, voir la figure 5.22-(A)).
Pour des images avec peu de mouvements, ce temps avec une compression “Gzip” est
de 536 ms (0.173 sec + 0.363 sec voir la figure 5.22-(B)) alors qu’il est de 446 ms (0.153
sec + 0.293 sec, voir la figure 5.23-(A)) lorsque “Gzip” est précédée d’un pré-traitement.
Par contre ce temps est de 591 ms (0.138 sec +0.453 sec, dans la figure 5.23-(B)) lorsque
la méthode de Huffman précédée d’un pré-traitement est utilisée sachant qu’elle fournit
139
0.472
0.363
0.104 0.173
(A) (B)
Fig. 5.22 – Evaluation des temps serveur et réponse du client lorsqu’il y a peu de mou-
vements dans l’image. (A) : Pour des images brutes, (B) : Pour des images compressées
avec Gzip.
un meilleur taux de compression (environ 71% de la taille de l’image brute).
0.453
0.293
0.153 0.138
(A) (B)
Fig. 5.23 – Evaluation des temps serveur et réponse du client lorsqu’il y a peu de mouve-
ments dans l’image. (A) : Pour des images prétraitées ensuite compressées en Gzip, (B) :
Pour des images prétraitées en compressées avec Huffman.
Pour des images avec beaucoup de mouvements, le temps total moyen est de 535 ms
pour une compression “Gzip” (figure 5.24-(A)) et vaut 531 ms (figure 5.24-(B)) lorsque
la compression “Gzip” est précédée d’un pré-traitement.
Dans cette expérimentation, les faibles variations du temps total moyen, quelque soit la
méthode de compression d’image, est une conséquence directe du fait que le site opérateur
n’est pas éloigné du site esclave. En effet, en connexion locale, les délais de communications
sont très faibles malgré leurs instabilités (par exemple ce délai augmente brusquement lors
de l’expérimentation avec la méthode de Huffman précédée d’un pré-traitement représenté
par la figure 5.23-(B)).
Expérimentalement, les images qui résultent des déplacements réalisés par le robot,
sont considérées comme étant des images présentant peu de mouvements. Dans la majo-
140
0.362
0.365
0.17 0.169
(A) (B)
Fig. 5.24 – Evaluation des temps serveur et réponse du client lorsqu’il y a beaucoup de
mouvements dans l’image. (A) : Pour des images compressées avec Gzip, (B) : Pour des
images prétraitées et ensuite compressées avec Gzip.
rité des cas, c’est la méthode de Huffman précédée d’un pré-traitement qui est utilisée.
Nous présentons maintenant, les résultats obtenus lorsque le site opérateur se trouve
à moyenne distance.
5.3.1.2 Connexion moyenne distance
De nombreux opérateurs en Europe ont utilisé le système ARITI et réalisé des tâches.
Nous présentons ci-dessous, quelques résultats de connexion lorsque le site opérateur se
trouve en France, en Italie, en Espagne et au Royaume-Uni.
La figure 5.25, montre le résultat d’une connexion d’un opérateur se trouvant à “Tou-
louse”. Le temps moyen serveur est de 127 ms et le temps moyen de réception d’une
nouvelle demande du client est de 2.49 sec, ce qui donne un temps total (Tt ) moyen de
2.617 sec.
2.49
0.127
Fig. 5.25 – Evaluation des temps serveur et réponse du client à moyenne distance.
L’adresse Internet du site client est “Toulouse-17-133.abo.wanadoo.fr”.
141
Dans la figure 5.26, l’opérateur se trouve à l’INRETS (Institut National de Recherche

sur les Transports et leurs Sécurité) et le temps total moyen est de 3.178 sec (0.108 sec +
3.07 sec)
3.07
0.108
L’adresse Internet du site client est “pc-41-13.inrets.fr”.
Un autre type de connexion est celui où le site opérateur est relié à Internet par un
modem, il s’agit d’une connexion dont le débit réel est inférieur à 6 KO/s. Le temps total
moyen est de 5.312 sec (0.112 sec + 5.2 sec voir la figure 5.27).
5.2
0.112
L’adresse du site client est “dyn-213-36-102-192.ppp.libertysurf.fr”.
Une connexion depuis l’Italie a permit d’avoir un temps total moyen intéressant de
l’ordre de 1.085 sec, avec Tr = 0.95 sec et Ts = 0.135 sec (figure 5.28). Dans ce cas, le
débit du côté du site client est de 1 GB/s (Giga Bits par seconde).
Il est évident que le temps total Tt dépend essentiellement de la bande passante des
deux sites maı̂tre et esclave, et aussi suivant le nombre de personnes connectées au réseau
Internet à un instant donné. Nous constatons aussi que le temps serveur (Ts ) moyen subit
une faible variation (de 108 ms à 135 ms suivant les expérimentations présentées par les
figures 5.25, 5.26, 5.27 et 5.28).
142
0.95
0.135
L’adresse Internet du site client est “pc.area.ba.cnr.it”.
Dans le tableau 5.3, nous présentons les résultats pour d’autres connexions réalisées à
moyenne distance. La première ligne représente les résultats de connexion depuis l’IRISA1
de Rennes (avec une bande passante de 1 GB/s). La deuxième et la troisième ligne, pour
une connexion de l’Espagne et la dernière du Royaume-Uni.
Les résultats représentés dans ce tableau sont obtenus sur une série d’envoi de 30 images
vidéo. avec
– MTs : Moyenne du Temps serveur.
– MTr : Moyenne du Temps de réponse du client (réception d’une nouvelle demande
du client)
– T MI : Taille Moyenne de l’image vidéo
– HC : Heure de Connexion (heure locale)
Adresse du site distant MTs (ms) MTr (sec) T MI (KO) HC

castor.irisa.fr 101.13 1.10 14.696 17 :08 :03
usuario1-36-131-230.dialup.uni2.es 115.09 4.69 15.366 15 :51 :13
usuario1-36-142-66.dialup.uni2.es 114.40 7.18 16.570 11 :30 :25
user142008.dial.netline.net.uk 109.90 4.72 14.525 16 :35 :49
Tab. 5.3 – Quelques résultats de connexion à moyenne distance
Nous présentons dans ce qui suit, les résultats de connexion lorsque le site opérateur
se trouve à une longue distance.
5.3.1.3 Connexion longue distance
La télépération du robot à aussi été réalisée par des opérateurs se trouvant dans
d’autres continents, tels que l’Amérique, l’Asie et l’Océanie. Nous présentons ici quelques
résultats de connexion depuis “San Francisco”, “Washington”, “Canada”, “Brésil”, “Ar-
gentine”.
La figure 5.29, montre les résultats de connexion d’un opérateur se trouvant a “San
Francisco”. Le temps total Tt moyen est de 5.9 sec (0.12 sec + 5.78 sec)
1
Institut de Recherche en Informatique et Systèmes Aléatoires
143
5.78
0.12
Fig. 5.29 – Evaluation des temps serveur et réponse du client à longue distance. L’adresse
du site client est “1Cust161.tnt1.san-francisco3.ca.da.uu.net”
Pour une connexion depuis l’école polytechnique de Montréal “Canada”, Le temps

total moyen est de 5.624 sec (0.144 sec + 5.48 sec voir la figure 5.30).
5.48
0.144
Fig. 5.30 – Evaluation des temps serveur et réponse du client à longue distance. L’adresse
Internet du site client est “internet-pub2.biblio.polymtl.ca”
D’autres résultats de connexion à longue distance, sont représentés dans le tableau

5.4. La première ligne l’opérateur se trouve à “Washington”, la deuxième et la troisième
ligne depuis le “Brésil”. Dans les deux dernières lignes, les opérateurs n’ont pas contrôlé
le robot réel (ils n’ont pas demandé le “Login” et le “Pin code” pour avoir le contrôle du
robot réel), mais ils ont reçu des images vidéo et utilisé le robot virtuel (ils ont réalisé des
tâches seulement en virtuel).
avec MTs , MTr et T MI une moyenne sur 30 images vidéo envoyées.
Nous allons maintenant évaluer les performances de l’architecture client/serveur de
ARITI, lorsque plusieurs opérateurs l’utilisent en même temps.
144
Adresse du site distant MTs (ms) MTr (sec) T MI (KO) HC
Washington 2 111.78 1.46 12.584 18 :25 :32
host052199.arnet.net.ar 109.26 5.69 14.348 16 :54 :20
line181.comsat.net.ar 119.41 7.45 16.581 19 :08 :27
maverick.furb.rct-sc.br 107.94 5.37 15.570 13 :30 :25
nc2608-50.cudenver.edu 111.78 1.27 13.696 20 :08 :03
141-211-31-173.bus.umich.edu 114.92 1.42 14.356 21 :01 :13
Tab. 5.4 – Quelques résultats de connexion à longue distance
5.3.2 Connexion avec plusieurs opérateurs avec retour prédictif

distribué
Dans cette section nous présentons quelques résultats lorsque par exemple un opérateur
(appelé maı̂tre) contrôle le robot réel via le robot virtuel et les autres opérateurs (super-
viseurs), supervisent en virtuel et en réel les actions réalisées par l’opérateur maı̂tre. Un
superviseur peut redevenir maı̂tre en prenant à nouveau le contrôle du robot réel. En effet,
un seul opérateur peut avoir le contrôle du robot réel à un instant donné.
5.3.2.1 Connexion locale
Une expérimentation a été réalisée en locale au sein même de notre laboratoire Systèmes
Complexes du CEMIF (Centre d’Etude de Mécanique d’Ils de France). Cinq opérateurs
se sont connectés au système ARITI dans le but d’un télétravail coopératif (une mission
partagée par cinq opérateurs).
Les machines maı̂tres sont des Pentiums, dont la vitesse du processeur est de 350
Mhz pour le maı̂tre et 500 Mhz pour les autres. Pour cette expérience, les connexions au
système ARITI sont faites d’une manière séquentielle. En effet, le deuxième opérateur,
attend environ 1 mn après la connexion du premier, etc. Ce temps d’attente nous l’avons
imposé afin de pouvoir récupérer suffisamment de données nécessaires pour évaluer les
performances du client/serveur en fonction du nombre de clients connectés au système.
Nous présentons ici essentiellement l’expérimentation lorsque le premier opérateur contrôle
le robot réel et les quatre autres supervisent en virtuel et en réel les actions réalisées par
cet opérateur maı̂tre.
Nous avons mesuré les moyennes des temps, serveur et réponse du client, sur une série
de 10 images vidéo envoyées. Cette évaluation est faite dans un premier temps avec un
seul opérateur connecté, ensuite avec 2, 3, 4 et 5 opérateurs simultanément.
avec :
– MT s désigne la Moyenne du Temps serveur en fonction du nombre de connexions
simultanées.
– MT r désigne la Moyenne du Temps de réponse du client (ou reprise du serveur) en
fonction du nombre de connexions simultanées.
Des résultats avec les différentes méthodes de compression d’images sont représentés
dans les figure 5.31, 5.32 pour des images avec peu de mouvements et la figure 5.33 pour
des images avec beaucoup de mouvements.
145
(A) (B)
Fig. 5.31 – Les temps moyens, serveur et reprise du serveur, pour une connexion de 1 à 5
clients lorsqu’il y a peu de mouvements dans l’image. (A) : Pour des images brutes, (B) :
Pour des images compressées avec Gzip.
(A) (B)
Fig. 5.32 – Les temps moyens, serveur et reprise du serveur, pour une connexion de 1 à
5 clients lorsqu’il y a peu de mouvements dans l’image. (A) : Pour des images prétraitées
ensuite compressées en Gzip, (B) : Pour des images prétraitées et compressées avec Huff-
man.
146
(A) (B)
Fig. 5.33 – Les temps serveur, et reprise du serveur, pour une connexion de 1 à 5 clients
lorsqu’il y a beaucoup de mouvements dans l’image. (A) : Pour des images compressées
avec Gzip, (B) : Pour des images prétraitées et ensuite compressées avec Gzip.
Ces expérimentations montrent que le serveur d’image se comporte de la même façon

pour une ou plusieurs connections simultanées. En effet, pour des images brutes la moyenne
du temps serveur (MT s) vaut 104 ms pour une seule connexion et 110 ms pour 2, 3, 4
et 5 connexions simultanées (figure 5.31-(A)). Pour des images avec peu de mouvement
et compressées en “Gzip” ce temps varie de 173 ms pour une connexion à 190 ms pour 5
connexions (5.31-(B)).
Par contre, cette variation est plus intéressante lorsque les images vidéo ont subit un
pré-traitement avant compression. Nous constatons que ce temps passe de 153 ms pour
un client à 140 ms pour 5 clients lorsque la méthode “Gzip” précédée d’un pré-traitement
est utilisée (figure 5.32-(A)). Cette diminution de la moyenne du temps serveur est aussi
plus importante lorsque la méthode de Huffman précédée d’un pré-traitement est utilisée,
elle varie entre 138 ms pour un client et 114 ms pour 5 clients (figure 5.32-(B)).
Lorsque l’image subie beaucoup de mouvements, le temps serveur varie entre 170 ms pour
un seul client et 190 ms pour 5 clients avec une compression “Gzip” (figure 5.33-(A)).
Nous présentons maintenant les résultats obtenus lors de la télésupervision avec re-
tour prédictif distribué. Pour cela, nous avons mesuré les temps moyens nécessaires pour
la mise à jour des images réelles et des environnements réels, en fonction du nombre de
clients connectés au système ARITI (voir le tableau 5.5).
Soit :
– MR ER : Moyenne du temps de Réponse du client pour la mise à jours des images
Réelles
– MR EV : Moyenne du temps de Réponse du client pour la mise à jours de l’envi-
ronnement virtuel.
Ces résultats, montrent le gain de temps que peut fournir un retour prédictif lors d’un
télétravail ou encore lors d’un télétravail coopératif. En effet, les actions réalisées par
l’opérateur maı̂tre avec le robot virtuel dans son environnement virtuel, sont récupérées
par le serveur de commande et envoyées aux différents superviseurs. Pour la mise à jours
de l’environnement virtuel du côté de chaque client, le serveur de commande informe
chaque client superviseur, de l’état actuel du robot et des tâches en cours. Dans cette
147
Nombre d’opérateurs MR ER (ms) MR EV (ms)

1 591 11.0266
2 624 24.7395
3 596 44.8783
4 596 71.7134
5 624 98.9045
Tab. 5.5 – La moyenne des temps pour la mise à jour des images réelles et des environne-
ments virtuels lors d’un télétravail coopératif avec plusieurs opérateurs. Dans ce cas, les
opérateurs se trouvent dans le même laboratoire.
expérimentation, les données necéssaires sont les coordonnées des quatre moteurs du ro-
bot (24 octets) et une chaı̂ne de caractères représentant le codage de l’état des tâches
réalisées (9 octets). Il est cependant évident que la taille totale des données nécessaires
pour la mise à jour des environnements virtuels est très petite par rapport à la taille des
images à envoyer pour la mise à jour de l’affichage réel (33 octets << 12584 octets dans
le meilleur des cas).
Par contre, le temps moyen pour la mise à jour des environnements virtuels augmente
en fonction du nombre d’opérateurs utilisant le système ARITI simultanément. Cette
augmentation se justifie par le fait que le serveur envoie les données (pour la mise à jour
de l’environnement virtuel) dans l’ordre de passage en mode “télésupervision”. La figure
5.34 montre les deux courbes représentant les temps moyen de mise à jour des images
réelles et des environnements virtuels.
Fig. 5.34 – Temps de mise à jour des images réelles et des environnements virtuels en
fonction du nombre d’opérateur utilisant le système ARITI en connexion locale.
Nous allons maintenant voir les résultats de connexion à moyenne et longue distance.
5.3.2.2 Connexion moyenne et longue distance
Deux expérimentations ont été réalisées en faisant participer seulement deux opérateurs
à chaque fois.
148
5.4. BILAN
La première expérimentation est réalisée avec deux opérateurs se trouvant en Espagne,

le premier opérateur se connecte et prend la commande du robot réel, et le deuxième se
connecte 2 mn plus tard et utilise le mode “télésupervision”. De la même façon que
précédemment, nous avons mesuré les temps moyen pour la mise à jour des images réelles
et des environnements virtuels, voir le tableau 5.6.
La deuxième expérimentation fait participer deux autres opérateurs, le premier se

trouve en Italie et le second à Montréal (Canada). Dans les mêmes conditions d’expérimen-
tation que précédemment, le premier opérateur prend le contrôle du robot réel et le second
supervise en virtuel et en réel. Les résultats de cette expérience sont donnés dans le tableau
5.7.
Adresse3 ordre de connexion MR ER (s) MR EV (s)
usuario1-36-131-230.dialup.uni2.es 1 4.80 0.39
usuario1-36-142-66.dialup.uni2.es 2 5.14 0.48
Tab. 5.6 – La moyenne des temps pour la mise à jour des images réelles et des environ-
nements virtuels lors d’un travail coopératif avec deux opérateurs distants. Dans ce cas,
les opérateurs se trouvent en Espagne.
Adresse ordre de connexion MR ER (s) MR EV (s)

pc.area.ba.cnr.it 1 1.15 0.14
internet-pub2.biblio.polymtl.ca 2 5.49 0.82
Tab. 5.7 – La moyenne des temps pour la mise à jour des images réelles et des environ-
nements virtuels lors d’un travail coopératif avec deux opérateurs distants. Dans ce cas,
le premier se trouve en Italie et le deuxième au Canada.
5.4 Bilan
Les expérimentations présentées dans ce chapitre, nous ont permis d’évaluer notre
système de télétravail ARITI. En effet, dans la première section, nous avons montré que
l’interface de ARITI permet un apprentissage des tâches et que l’utilisation des guides
virtuels fournit une sécurité pour le robot et son environnement. De même, l’utilisation
des guides virtuels attractifs permet d’améliorer les performances des opérateurs vis à vis
des tâches de téléopération, en fournissant une meilleure précision d’approche des objets
à manipuler (inférieure au mm) et un meilleur temps de réalisation des missions (7.7 sec
pour une tâche d’atteinte d’une cible avec un guide virtuel attractif contre 22.21 sec sans
guide virtuel).
Par ailleurs, l’évaluation des méthodes de compression d’images étudiées, nous a per-
mis de déterminer un algorithme de choix automatique de la compression à réaliser en
fonction de la dynamique de l’image. En effet, le choix s’est porté sur un “pré-traitement”
suivi de la méthode de “Huffman” lorsque les images vidéo présentent peu de mouvements
(avec un taux de compression de 71%). Par contre, lorsque les images présentent beau-
coup de mouvements, le “pré-traitement” suivi de la méthode “Gzip” est choisie pour
149
compresser les images vidéo (avec un taux de compression de 44%).
D’autres expérimentations ont été réalisées pour évaluer les performances du système
ARITI et essentiellement l’architecture client/serveur. Nous avons montré la stabilité du
serveur vis à vis de nombreuses connexions, locales, moyennes et grandes distances. En
effet, la téléopération en utilisant le système ARITI, essentiellement à moyenne et longue
distance, est devenue possible grâce au retour prédictif permettant aux opérateurs d’une
part, de contrôler le robot réel via sa représentation virtuelle et d’autre part, de superviser
l’exécution des tâches en réalité augmentée. Bien que les délais de transmissions d’images
vidéo en particulier, dépendent complètement de la distance et de la bande passante des
deux sites et essentiellement des sites clients. Par exemple pour une téléopération en local
avec un débit réseau inférieur à 700 KO/s, nous obtenons un peu plus de deux images
par seconde. Pour une téléopération depuis “Toulouse” le délai moyen est de 2.5 sec pour
une image, depuis l’IRISA de Rennes et l’Italie avec un débit de 1 Gbits/s, ce délai est
autour d’une seconde (une image par seconde).
Pour une téléopération à longue distance, le même phénomène a été constaté, par
exemple depuis “San-francisco”, “Montréal” et “Argentine”, ce délai est entre 5 et 7 se-
condes alors que depuis “Washington” le retour d’une images vidéo se fait toutes les 1.5
sec en moyenne.
D’autre part, la conception et la mise en œuvre d’une architecture de communication

client/serveur, supportant de multiples connexions simultanées (jusqu’à 255 opérateurs) à
permis à plusieurs clients distants de télétravailler en coopération avec un retour prédictif
distribué. En effet, un travail coopératif avec deux opérateurs distants (dans la première
expérience les opérateurs se trouvent en “Espagne” et dans la seconde, un se trouve en
“Italie” et l’autre au “Canada”) à été réalisé. Le premier opérateur a pris le contrôle des
robots virtuel et réel et le second supervise toutes les actions réalisées par le premier, en
virtuel et en réel et ensuite reprend à son tour, le contrôle des robots. Ces expérimentations
ont montré, l’avantage d’un retour prédictif distribué (mise à jour des environnements
virtuels des sites clients distants) lors d’un travail coopératif en présence de délais de
transmission. En effet, les temps de mise à jour des environnements virtuels du côté des
clients superviseurs est de 480 ms pour l’Espagne et de 820 ms pour le Canada, contre
respectivement, 5.14 sec et 5.49 sec pour les retours d’images vidéo.
150
Conclusions
Tout au long de cette thèse, nous avons essayé d’atteindre nos objectifs. En effet, des
réponses aux problématiques posées ont été apportées et présentent ainsi notre contribu-
tion, à savoir :
Les outils logiciels et matériels nécessaires pour la mise en œuvre d’un système de
télétravail ont été proposés et utilisés pour la réalisation du système ARITI (ce
problème est traité dans le chapitre 3).
Les nouveaux concepts et les solutions déjà apportées aux problèmes liés à la
télérobotique, ont été intégrés sur une plate-forme universelle et à moindre coût,
puisque l’interface du système ARITI a été développée sur un simple PC (ce problème
est traité dans les chapitres 3 et 4).
L’utilisation d’un système de télétravail est devenue souple et fournit un bon ap-
prentissage pour l’opérateur. Les expérimentations réalisées avec le système ARITI
l’ont montré dans le chapitre 5.
Les types d’assistances nécessaires à l’opérateur afin d’améliorer ses performances,
sont présentés dans le chapitre 3, il s’agit d’assistance à la perception de l’environ-
nement, à la commande du robot et à la supervision des tâches. Pour l’assistance à
la commande du robot, des guides virtuels sont utilisés, ces derniers sont présentés
dans les chapitres 2 et 4, et leurs performances sont discutées dans le chapitre 5.
Une architecture client/serveur supportant un travail coopératif est réalisée et est
présentée dans le chapitre 3 et ses performances sont discutées dans le chapitre 5.
Quelques avantages que peuvent offrir les systèmes de télétravail en particulier en
utilisant le réseau Internet, ont été fournis dans le chapitre 4.
Le premier chapitre nous a permis d’un côté, de présenter les différents aspects du
télétravail ainsi que les méthodes et les tendances technologiques qui contribuent énormém-
ent à son évolution. D’un autre côté, il nous a permis d’analyser les systèmes de téléopérati-
on et de téléprogrammation de robots existants, les méthodes et les techniques utilisées
pour pallier les problèmes liés à la télérobotique en général et enfin d’analyser les récents
travaux concernant le contrôle de systèmes robotique via Internet. A l’issu de ce chapitre,
des problématiques ont été dégagées est ont fait objet d’études et de discussions dans les
autres chapitres.
Dans le second chapitre, les notions de mécanisme et de guide virtuel indispensables à

un système de réalité augmentée basé sur un retour prédictif ont été présentées. Nous avons
aussi présenté les méthodes analytiques et géométriques de création, de représentation
et de manipulation des objets virtuels en général et en particulier des guides virtuels.
Nous avons ensuite proposé un nouveau formalisme pour les guides virtuels afin de les
rendre paramétrables, évolutifs et utilisables comme de véritables outils d’assistance à la
téléopération via Internet.
CONCLUSIONS
Dans le troisième chapitre, nous avons présenté les méthodes et les outils nécessaires
pour un contrôle en réalité augmentée à savoir, la modélisation de l’environnement et la
calibration de la caméra et du robot. Nous avons aussi présenté le système expérimental de
télétravail baptisé ARITI. L’interface de ce système est implantée en langage JAVA dans
le but de la rendre portable et indépendante des systèmes d’exploitation sur lesquels elle
va s’exécuter. Nous avons insisté sur des détails de l’architecture client/serveur réalisée
afin de montrer d’un côté, sa complexité et de l’autre côté, la faisabilité conceptuelle et
technique d’une architecture destinée à supporter un télétravail d’une part et un travail
coopératif d’autre part.
Par ailleurs, nous avons présenté les trois modes de télétravail utilisés qui sont la téléopéra-
tion, la téléprogrammation de tâches et la télécoopération/télésupervision. Ce dernier
mode utilise un retour prédictif distribué, afin de permettre aux différents opérateurs de
percevoir à la fois, les images vidéo de l’environnement réel distant et la mise à jour 3D
de l’environnement virtuel au niveau de chaque client superviseur.
Dans le quatrième chapitre, nous avons présenté quelques applications pouvant bénéfic-
ier d’un système de télétravail via Internet. Nous avons cependant souligné la nécessité
d’avoir d’un côté, une interface administrateur pour la maintenance et la mise à jour d’un
tel système et de l’autre côté une interface destinée aux utilisateurs du système.
Nous avons décrit certaines tâches réalisées suivant le mode de télétravail choisi, d’un
côté, les tâches de téléopération (saisie/dépôt d’objets, etc.) où l’opérateur s’il le désire
peut être assisté par des guides virtuels. D’un autre côté, l’opérateur peut télétravailler à
un haut niveau (superviseur). Pour cela, il spécifie seulement la tâche à faire exécuter par
les robots virtuel et réel simultanément. Enfin, si une mission nécessite l’intervention de
plusieurs opérateurs simultanément dans le but d’un travail coopératif par exemple, un
opérateur prend le contrôle du robot réel pendant que les autres supervisent en virtuel et
en réel les actions de celui-ci. Dans ce dernier cas, le contrôle des robots virtuel et réel est
partagé entre les différents opérateurs.
Nous avons montré la flexibilité et l’ouverture du système ARITI pour d’autres appli-
cations, en utilisant un robot mobile. En effet, une application sur un robot mobile a été
réalisée en s’inspirant de l’existant et en rajoutant essentiellement le module contenant les
nouveaux modèles virtuels ainsi que le module de client/serveur commande. Nous avons
cité d’autres domaines d’application où un système de télétravail ou de travail coopératif
via Internet peut être intéressant. La liste fournie n’est bien entendu pas exhaustive.
Dans le dernier chapitre, nous avons réalisé des expérimentations afin d’évaluer notre
système de télétravail ARITI. En effet, nous avons montré que l’interface de ARITI per-
met un apprentissage des tâches et que l’utilisation des guides virtuels fournit une sécurité
pour le robot et son environnement. Nous avons montré que l’utilisation des guides vir-
tuels attractifs permet d’améliorer les performances des opérateurs vis à vis des tâches de
téléopération, en fournissant une meilleure précision d’approche des objets à manipuler
et un meilleur temps de réalisation des missions (7.7 sec pour une tâche d’atteinte d’une
cible avec un guide virtuel attractif contre 22.21 sec sans guide virtuel).
Par ailleurs, l’évaluation des méthodes de compression d’images étudiées, nous a permis
de déterminer un algorithme de choix automatique de la compression à réaliser en fonction
de la dynamique de l’image. En effet, le choix s’est porté sur un “pré-traitement” suivi de
la méthode de “Huffman” lorsque les images vidéo présentent peu de mouvements (avec
un taux de compression de 71%). Par contre, lorsque les images présentent beaucoup de
152
CONCLUSIONS
mouvements, la méthode “pré-traitement” suivie de “Gzip” est choisie pour compresser

les images vidéo (avec un taux de compression de 44%).
Les autres expérimentations présentées dans ce dernier chapitre, ont permis d’évaluer
les performances du système ARITI et essentiellement l’architecture client/serveur. Nous
avons montré la stabilité du serveur vis à vis de nombreuses connexions, locales, moyennes
et grandes distances. En effet, le télétravail et le travail coopératif en utilisant le système
ARITI (essentiellement à moyenne et longue distance) sont devenus possibles grâce au
retour prédictif distribué. Ce dernier, permet aux opérateurs d’un côté, de contrôler le
robot réel via sa représentation virtuelle et d’un autre côté, de superviser l’exécution des
tâches en réalité augmentée.
Un système expérimental de télétravail via Internet, baptisé ARITI (Augmented Rea-

lity Interface for Telerobotic applications via Internet) a été réalisé. Il est accessible sur In-
ternet d’une part, depuis 1999 sur le site Web de notre laboratoire (http ://lsc.cemif.univ-
evry.fr :8080/Projets/ARITI) et d’autre part, depuis Février 2000 sur le site de la NASA
(Nasa Space Telerobotics program au http : //ranier.oact.hq.nasa.gov/telerobotics page/-
realrobots.html).
Le système ARITI est le premier système en France qui permet la téléopération en réalité
augmentée via Internet.
153
CONCLUSIONS
Perspectives
Système de télétravail multimodal
Il est possible de rajouter au système ARITI des retours d’informations multimodales

afin d’augmenter le degré de téléprésence de l’opérateur. Il s’agit d’informations Sonore,
Tactile et Kinesthésique. En effet, l’ajout d’un microphone (connecté à une carte son du
PC serveur) sur le site esclave ainsi que des capteurs de contact et de force au niveau
de l’effecteur du robot, permettrait de récupérer via des processus serveurs dédiés, toutes
ces informations vers les machines clientes (sites maı̂tres) où se trouvent les opérateurs.
Cependant, des questions se posent d’une part, sur le choix du format des fichiers audio
ainsi que les méthodes de compression à utiliser. D’autre part, sur les dispositifs à retour
tactile et d’effort pouvant être utilisés sur un système de télétravail via Internet. Des
joysticks à retour d’effort à moindre coût, existent et fonctionnent sous l’environnement
Linux.
La figure 5.35 illustre cette multimodalité avec des transferts d’informations audio et
haptique, avec un processus dédié pour chaque type d’information.
Site serveur Site client
Processus Processus
Son Son
Tactile Tactile
Force Force
PC avec carte son,

joystick à retour d’effort.
Fig. 5.35 – Illustration des transferts d’informations multimodales via Internet entre le
site maı̂tre (client) et le site esclave (serveur).
Cette multimodalité impose la contrainte que la machine du client doit disposer du

matériel adapté (organe à retour d’effort) pour réaliser une commande à retour d’effort
du robot.
Interaction de ARITI avec d’autres systèmes de réalité aug-

mentée et de réalité virtuelle
Il faut remarquer que dans l’état actuel du système ARITI, nous ne pouvons travailler
qu’avec des environnements modélisés (robot, objets, etc.). En effet, pour permettre une
modélisation interactive de l’environnement nous pouvons faire appel à d’autres systèmes
dédiés sans pour autant reprendre les travaux et tous les efforts réalisés à ce sujet.
En effet, la communication en réseau avec ces systèmes permettrait l’échange des

données afin de combler ce manque. De la même façon si nous désirons faire du traite-
ment d’images afin de recaler un objet virtuel sur le réel nous n’allons pas le faire avec
154
CONCLUSIONS
le système ARITI, mais une communication avec le système MCIT (Mutimédia Control
Interface in Teleoperation) existant sur une station Silicon Graphics (SG) au sein de notre
laboratoire pourrait très bien apporter cette solution. En effet, du moment que le transfert
de l’image vidéo de ARITI vers MCIT suffit pour que ce dernier traite l’image et ensuite
envoie les informations nécessaires pour recaler l’objet virtuel sur le réel(Mallem et al.,
1996) et (Moreau et al., 1997).
La figure 5.36 illustre cette perspective.
ARITI Internet / Intranet / RS232 MCIT
PC Linux
Station
Envoi images SG
Serveur
Réception résultats
Traitement des images

...
( reconnaissance d’objets,
appariement 2D/3D, etc ...)
Clients ... Internet / Intranet
Fig. 5.36 – Illustration de la communication entre le système ARITI et MCIT pour faire
du recalage d’objets virtuels sur les objets réels.
L’interopérabilité entre un système de vision artificielle (MCIT) et un système de

télétravail (ARITI) permet d’étendre les possibilités de ce dernier.
Télécalibration de la caméra
Il est maintenant possible de calibrer la caméra vidéo à distance. En effet, la connais-

sance des coordonnées 3D de l’effecteur du robot à chaque instant (grâce au modèle
géométrique direct du robot), permet à l’opérateur d’extraire les points 2D écran (à par-
tir des images vidéo qu’il reçoit) correspondants aux points 3D de l’extrémité de l’effecteur
du robot.
Cette télécalibration, peut aussi se faire automatiquement, à condition que l’extrémité

de l’effecteur du robot soit suffisamment visible (contrastée par rapport à l’environnement
etc.) afin que la détection du point 2D correspondant, puisse se faire par un traitement
d’image. Bien entendu, cette télécalibration doit se faire par l’opérateur “administrateur”,
car elle nécessite la mise à jour du module de calibration de la caméra (régénérer un autre
exécutable).
La télécalibration permet le changement du point de vue réel (télécommander la

caméra pour faire un zoom par exemple, etc) et la mise à jour de la superposition du
monde virtuel sur le réel, moyennant une intervention minimale de l’opérateur.
155
CONCLUSIONS
Téléopération de plusieurs robots en coopération
Afin de permettre à plusieurs opérateurs de contrôler plusieurs robots oeuvrant en

coopération, une extension du système ARITI peut être réalisée. Cependant, il est nécessaire
de s’intéresser aux problèmes de partage et de gestion des ressources communes (les ob-
jets et les outils virtuels communs, la gestion des points de vue virtuels et réels). Des
questions se posent à savoir, comment doit se faire la communication entre les différentes
entités virtuelles ? Quelles sont les méthodes et les outils nécessaires pour permettre l’in-
teropérabilité (Allongue et M.Soto, 1997) de ces différentes entités virtuelles ?
La figure 5.37 illustre un exemple de deux opérateurs distants qui désirent réaliser une
mission qui nécessite l’intervention de deux robots, chaque opérateur contrôle un robot et
voit ce que fait l’autre en virtuel et en réel. Ici, les caractéristiques et les fonctionalités de
chaque robot sont gérées par un serveur dédié. L’extension du système ARITI ne servira
que d’intermédiaire pour le contrôle des deux robots via Internet.
Serveur Site client 1
robot 1
Extention du
Robot 1 serveur
ARITI
Site client 2
Serveur
robot 2
Robot 2
Fig. 5.37 – Illustration de la téléopération de deux robots par deux clients distants en
utilisant une extension du système ARITI.
Langage de haut niveau pour la télémanipulation d’objets via

Internet
Les méthodes étudiées et les outils utilisés pour réaliser le système de télétravail ARITI,
peuvent très bien être utilisées et améliorées pour la conception d’un langage de haut ni-
veau pour la télémanipulation d’objets via Internet. En effet, les méthodes de désignation
et de manipulation sur écran d’objets virtuels (décrites dans le chapitre 2), ainsi que
l’existence des outils virtuels paramétrables et portables (comme les guides virtuels par
exemple) peuvent être utilisés pour créer un langage de télémanipulation de haut niveau.
Par exemple l’opérateur peut saisir et déposer un objet virtuel avec la souris (2D ou
encore 3D ou 6D), et les robots virtuel et réel exécutent la tâche sans que l’opérateur
agisse sur le robot virtuel. Ceci nécessite l’utilisation des guides virtuels complètement
autonomes qui seront associés à chaque sous tâche (saisie, dépôt, etc.). Pour cela, une
analyse sur les interactions de l’opérateur avec l’environnement virtuel est nécessaire (as-
socier un sens aux différentes actions de l’opérateur vis à vis de l’environnement virtuel),
156
CONCLUSIONS
ainsi qu’une grammaire prenant en compte des outils d’assistance qui vont provoquer
l’auto-commande du robot.
Cette analyse est rendu possible grâce à une connaissance plus approfondie de l’envi-
ronnement. En effet, il faut en plus du modèle géométrique utilisé actuellement, prendre
en compte les modèles cinématiques, dynamiques et physiques (liaisons ou dépendances
entre les objets de l’environnement).
Projet d’assistance aux personnes handicapées
L’application présentée succinctement dans le chapitre 4 concernant le télétravail avec

un robot mobile, se poursuit vers une assistance efficace d’une personne handicapée et vers
le travail coopératif. En effet, la réalisation d’une interface portable, à moindre coût avec
une architecture supportant un travail coopératif, permettrait aux personnes handicapées
(se trouvant dans un même appartement muni d’une connexion Intranet par exemple) de
partager un robot (ou plusieurs robots) pour réaliser des tâches (figure 5.38).
L’utilisation des méthodes et des techniques issues de réalité virtuelle ou augmentée,

permettrait un interfaçage efficace entre la personne handicapée et l’environnement ou
se trouve le robot. Par exemple, les différentes fonctions d’assistances décrites dans le
chapitre 3, telles que l’assistance à la perception de l’environnement, à la commande du
robot (en utilisant des guides virtuels par exemple) ainsi que l’assistance à la supervision
des tâches, peuvent être exploitées et améliorées afin de rendre les interactions entre une
personne handicapée et le système robotique plus intuitives.
Cependant, ce travail nécessite une collaboration et l’avis des spécialistes en ergonomie

d’interface homme - machine, en psychologie ainsi que les personnes concernées qui sont
les handicapés.
Réseau Local (Intranet)
Serveur Client
Client
HF
Client
HF
Robot
Client
mobile
Client
Client
Fig. 5.38 – Illustration de l’utilisation d’un seul robot par plusieurs personnes handi-
capées.
157
CONCLUSIONS
158
Bibliographie
Allongue, S. et M.Soto (1997). Paradigmes sur les comportements dans le cadre de l’in-
teropérabilité en réalité virtuelle. In 1ere conf. francophone de Modélisation et Simu-
lation des systèmes de production et logistique MOSIM’97.
Andriot, C. Automatique des Systèmes Téléopérés avec Retour d’Effort. Limitation des
Performances. Thèse de doctorat, Université Pièrre et Marie Curie (1997).
Backes, P. G., Tao, K. S., et Tharp, G. K. (1998). Mars pathfinder mission internet-
based operations using wits. In IEEE, International Conference on Robotics and
Automation, pages 284–291.
Backes, P. G. (WWW). Pathfinder sojourner rover simulation web page.
http ://mars.graham.com/wits/.
Bannon, L. et Schmidt, K. (1989). Cscw : Four characters in search of a context. In In
Proceedings of the European Community Conference on CSCW (EC-CSCW), pages
358–372, London.
Bejczy, A. (1992). Teleoperation : The language of the human hand. In The IEEE Int.
Workshop on Robot and Human Communication, ROMAN’92, pages 32–43, Septem-
ber 1-3, Tokyo, Japan.
Bejczy, A. et Kim, W. (1990). Predictive displays and shared compliance control for time-
delayed telemanipulation. In IEEE Int. Workshop on Intelligent Robots and Systems,
IROS’90, pages 407–412, Tsuchiura, Japan, July.
Bejczy, A., Kim, W., et Venema, S. (1990). The phantom robot : Predictive displays
for teleoperation with time delay. In IEEE Int. Conf. on Robotics and Automation,
pages 546–551.
Binstock, A. et Rex, J. (1995). Practical Algorithms for Programmers. Reading, MA :
Addison-Wesley.
Blanc, C. et Schlick, C. (1996). Ratioquadrics : an alternative model for superquadrics.
Bonneau, P. et Even, P. (1993). Man-machine cooperation for 3d objects pose estimation.
In IEEE SMC conf., volume 2, pages 294–299, Le Touquet, december.
Brooks, T. (1990). Telerobotic response requierements. In IEEE Int. Conf. on Systems
Man and Cybernetics, pages 113–120, Nice, France, May.
Brooks, T. et Ince (1992). Operator vision aids for telerobotic assembly and servicing in
space. In IEEE Int. Conf. on Robotics and Automation, ICRA’92, pages 886–891,
Nice, France, May.
Béréziat, A., Lagorce, J., et Turbé-Suetens, N. (2000). Travail et activités à distance.
Editions d’Organisation.
159
BIBLIOGRAPHIE
Burdea, G. (1993). Virtual Reality systems and Applications. Edison, NJ, USA.
Burdea, G. et Coiffet, P. (1994). Virtual Reality Technology. John Wiley et Sons, Inc Eds,
New York.
Burdea, G., Zhuang, G., Roskos, J., et E. Silver, K. L. (1992). A portable dextrous master
with force feedback. In Presence, volume 1, No. 1, pages 18–28.
Cammoun, Detriche, Lauture, et Lesigne (1994). Telerobotics in the service of disabled
persons. In ORIA’94 de la téléprésence vers la réalité virtuelle, 5éme colloque inter-
national et convention d’affaires, pages 249–254, Marseilles, Decembre.
Caudell, T. P. (1994). Introduction to augmented reality. In SPIE Proceedings :Telema-
nipulator and Telepresence Technologies, volume 2351, pages 66–70.
Causse, O. et Crowley, J. (1993). A man-machine interface for a mobile robot. In
IEEE/RSJ Int. Conf. on Intelligent Robots and Systems, IROS’93, pages 1487–1494,
Yokohama, Japan, July 26-30.
Chekhar, Y. Saisie et Traitement d’images télémétriques. Application à la Téléopération.
Doctorat de robotique, Université d’Evry Val d’Essonne (1994).
Clement, G., Fournier, Gravez, P., et Morillon, J. (1988). Computer aided teleopera-
tion : From arm to vehicle control. In IEEE Int. Conf. on Robotics and Automation,
ICRA’88, volume 1, pages 590–592,, Philadelphia, PA, April 24-29.
Coiffet, P. et Gravez, P. (1991). Human-Robot Cooperation : Toward an Advanced Teleo-
peration Mode. Tzafestas editor, Marcel Dekker Inc.
Conway, L., Volz, R., et Walker, M. (1990). Teleautonomous systems : Projection and
coordinating intelligent action at a distance. In IEEE Tran. on Robotics and Auto-
mation, volume 6, pages 146–158, April.
Crespin, R. (1999). Surfaces implicites. http ://dept-info.labri.u-
bordeaux.fr/∼crespin/Implicite/index.html.
DeLarminat, P. (1993). Automatique – commande des systèmes linèaires. Edition Hermès,
Paris.
Devy, M., Garric, V., et Orteu, J. (1997). Camera calibration from multiple views of
a 2d object, using a global non linear minimization method. In IEEE Int. Conf.
on Intelligent Robots and Systems, IROS’97, volume 3, pages 1583–1589, Grenoble,
septembre.
Feiner, S., MacIntyre, B., et al (1993). Windows on the world : 2d windows for 3d
augmented reality. In Proceedings of ACM Symposium on User Interface Software
and Technology, pages 145–155, Atlanta, GA, Association for Computing Machinery.
Ferell, W. R. (1965). Remote manipulation with transmission delay. In IEEE Transactions
on Human Factors in Electronics, volume 6, pages 24–32, september.
Ferell, W. R. (1966). Delayed force feedback. In IEEE Transactions on Human Factors
in Electronics, pages 445–449, octobre.
Fiorini, A., Bejczy, A. K., et Schenker, S. (1992). Integrated interface for advanced teleo-
peration. In IEEE SMC Conf, pages 18–21, October.
Foley, van Dam, Feiner, et Hughes (1990). Computer Graphics - principles and practice.
Addison-Wesley publishing company.
Fraisse, P. Contribution à la Commande Robuste Position/Force des Robots Manipulateurs
à Architecture Complexe Application à un Robot à Deux Bras. Thèse de doctorat,
l’Université Montpellier II (17 Fevrier, 1994).
160
BIBLIOGRAPHIE
Freedman, P. (1993). Robotics in the 1990’s : An overview of current trends. IEEE

Canadian Review.
Fuchs, P. (1996). Les interfaces de la réalité virtuelle. Collection -Interfaces- Les journées
de montpellier, Montpellier.
Galerne, S. Architecture ouverte de la commande adaptée à la robotique de coopération
h/m. Application au domaine médical. Thèse de doctorat, Université Paris XII (1989).
Goldberg, K., Mascha, M., Getner, S., et Rothenberg, N. (1995). Desktop teleoperation via
the world wide web. In IEEE, International Conference on Robotics and Automation,
Nagoya, Japan.
Grace, Vulkovich, et Chun (1993). Asix degree of freedom micromanipulator for ophthal-
mic surgery. In IEEE Int. Conference on Robotics and Automaion, pages 630–635,
Atlanta, USA.
Graves, S. et Volz, R. (1995). Action selection in teleautonomous systems. In IEEE/RSJ
Int. Conf. on Intelligent Robots and Systems, IROS’95, volume 3, pages 14–19, Pitts-
burgh, PA, August 5-9.
Greenberg, S. (1991). Computer-supported cooperative work and groupware : an intro-
duction to the special issues. In Int. Journal on Man-Machine Studies, pages 133–141.
Gzib, C. (www). http : //www.inf o − zip.org/pub/inf ozip/zlib/.
Hasegawa, T. (1991). A model-based tele-robot system with manipulation skills. In
ISART, pages 449–506, Tokyo, Japan, March 91.
Hayati, S. et Venkataraman, S. (1989). Design and implementation of a robot control
system with traded shared control capability. In IEEE Int. Conf. on Robotics and
Automation, volume 3, pages 1310–1315, May 14-19, Scottsdale, Arizona.
Hickey, S., Manninen, T., et Pulli, P. P. (July. 23-26. 2000). Telereality - the next step for
telepresence. In World Multiconference on Systemics, Cybernetics and Informatics
SCI 2000, volume 3. Virtual Engineering and Emergent Computing, pages 65–70,
Orlando, Florida, USA.
Hunter, Jones, et Sagar (1994). A teleoperated microsurgical robot and associated virtual
environment for eye surgery. In PRESENCE, volume 2 No. 4, pages 265–280.
Joly, L. et Andriot, C. (1995). Imposing motion constraints to a force reflecting telerobot
through real-time simulation of virtual mechanism. In IEEE Int. Conf. on Robotics
and Automation, ICRA’95, pages 357–362, Nagoya, Japan.
Kheddar, A. Téléopération basée sur le concept du robo caché. Doctorat de spécialité
robotique, Université Pièrre et Marie Curie (19 Decembre 1997).
Kheddar, A., Atlani, D., Iles, A., et Blazevic, P. (1996). New trends in legged robots
teleoperation. In IEEE Int. Workshop on Robot and Human Communication, RO-
MAN’96, pages 232–237, Nov. 11-14, Tsukuba, Japan.
Kim, W. S. (1993). Graphical operator interface for space telerobotics. In IEEE Int.
Conf. on Robotics and Automation, pages 761–768, Atlanta, Georgia.
Kim, W., Hannaford, B., et Bejczy, A. (1992). Force-reflection and shared compliant
control in operating telemanipulators with time delay. In IEEE Trans. on Robotics
and Automation, volume 8, No. 2, pages 176–185, April.
Koren, Y. (1985). Robotics for engineers. McGraw-Hill, New York, USA.
161
BIBLIOGRAPHIE
Kosuge, K., Itoh, T., Fukuda, T., et Otsuba, M. (1995). Tele-manipulation system ba-
sed on task-oriented virtual tool. In IEEE Int. Conf. on Robotic and Automation,
ICRA’95, pages 351–356, Nagoya, Japan.
Kosuge, K., Murayama, H., et Takeo, T. (1996). Bilateral feedback control of telemani-
pulators via computer network. In IEEE/RSJ Int. Conf. on Intelligent Robots and
Systems, IROS’96, volume 3, pages 1380–1385, Osaka, Japan.
Lawrence, D. (1993). Stability and transparency in bilateral teleoperation. In The IEEE
Transactions on Robotics and Automation, volume 9, No. 5, pages 624–637, October.
Lederman, S. et Klatzky, R. (1994). The intelligent hand : An experimental approach to
human object recognition and implications for robotics and ai. AI Magazine.
Leung, G. et Francis, B. (1992). Channel”. In 30th Annual Allerton Conf. on Com-
munication, Control and Computing, pages 629–701, Monticello, IL, Sept. 30 - Oct.
2.
Loukil, A. Interface Homme-machine de Contrôle Commande en Robotique téléopérée.
Doctorat de robotique, Université d’Evry Val d’Essonne (1993).
Mallem, M., Chavand, F., et Colle, E. (1992). Computer-assisted visual perception in
teleoperated robotics. In Robotica Journal, volume 10, pages 93–103, Cambridge
Univ. Press, England.
Mallem, M., Rougeaux, et Mellanger, H. (1993). A trajectory generation module for 2d
and 1/2 environment. In IEEE Computers in design, manufacturing and production,
7th Annual European Computer conference, pages 24–27, May.
Mallem, M., M. Shaheen, X., Dourille, et Chavand, F. (1996). A matching method between
an image and its 3d-model using a geometric constraint aproach based on contact.
In CESA’96 IMACS Multiconfèrence, pages 565–569.
Mallem, M., Shaheen, M., et Chavand, F. (1999). Automatic camera calibration based on
robot calibration. In the 16t h IEEE Instrumentation and Measurement Technology
Conference, Venice, Italy, 24-26 mai.
Michelman, P. et Allen, P. (1994). Shared autonomy in a robot hand teleoperation system.
In IEEE/RSJ Int. Conf. on Intelligent Robots and Systems IROS’94, volume 1, pages
253–259, Munich, Germany, Sept. 12-16.
Milgram, P. et Kishino, F. (Dec. 1994). A taxonomy of mixed reality visual displays. In
IEICE Trans. on Information Systems, special issue on Networked Reality, volume
E77-D, N˚. 12, pages 1321–1329.
Milgram, P., Rastogi, A., et grodski, J. (July. 5-7. 1995). Telerobotic control using augmen-
ted reality. In Proceedings 4t h IEEE International Workshop on Robot and Human
Communication (RO-MAN’95), Tokyo.
Moreau, G., Mallem, M., Chavand, F., et N’Zi, E. (1997). Two 3d recovering methods for
robot control. In IFAC’97, SYROCO, pages 531–537.
Nelson, M. et Gailly, J.-L. (1996). The Data Compression Book. New York, NY : M&T
Books.
Niemeyer, G. et Slotine, J. (1991). Stable adaptive teleoperation. In The IEEE Journal
of Oceanic Engineering, volume 16, No. 1, pages 152–162, January.
Nilles, J. (1998). Managing telework : Strategies for managing the virtual Workforce. John
Wiley & Sons.
162
BIBLIOGRAPHIE
Noyes, M. et Sheridan, T. (1984). A novel predictor for telemanipulation through a time

delay. In Annu. Conf. Manual Control, Moffett Field, CA, NASA Ames Research
Center.
N’zi, C. Modélisation et reconstruction 3D interactive d’environnement : application à
la téléopération. Doctorat de spécialité robotique, Université Evry Val d’Essonne,
France (7 Decembre 1995b).
N’zi, C., Chavand, F., Mallem, M., et Triboulet, J. (1994). Methods for updating the
enviromnent’s geometric database in telerobotics. In IMACS SPRANN’94, Signal
Processing Robotics And Neural Networks, page 628.
N’zi, C., Mallem, M., et Chavand, F. (1995a). Method for updating the environment 3d
geometrical database using single camera view. In IFIP WG 7.6 Working Conference,
pages 301–307.
Otmane, S., Mallem, M., Mavel, S., et Chavand, F. (8 et 9 Avril 1999). Un système
de réalité augmentée pour des applications télérobotique via interne. In JJCR’11,
Journée des Jeunes Chercheurs en Robotique, pages 57–62, EPFL Lauzane.
Otmane, S., Mallem, M., et Chavand, F. (3 et 4 février 2000a.). Les guides virtuels actifs
pour l’assistance à la téléopération via internet. In JJCR’12, Journée des Jeunes
Chercheurs en Robotique, pages 118– 124, Bourges, France.
Otmane, S., Mallem, M., Kheddar, A., et Chavand, F. (April 16-20, 2000b). Ariti : an
augmented reality interface for teleoperation on the internet. In Advanced Simulation
Technologies Conference (ASTC2000) - High Performance Computing, pages 254–
261, Wyndham City Center Hotel, Washington, D.C., USA.
Otmane, S., Mallem, M., Kheddar, A., et Chavand, F. (April 16-20, 2000c). Active virtual
guide as an apparatus for augmented reality based telemanipulation system on the in-
ternet. In IEEE Computer Society - 33rd Annual Simulation Symposium ANSS2000,
pages 185–191, Wyndham City Center Hotel, Washington, D.C., USA.
Otmane, S., Colle, E., Mallem, M., et Hoppenot, P. (July 23-26, 2000d). Disabled people
assistance by a semiautonomous robotic system : Use of virtual reality to enhance
human performences. In World Multiconference on Systemics, Cybernetics and Infor-
matics (SCI2000), volume 3 - Virtual Engineering and Emergent Computing, pages
684–689, Orlando, Florida, USA.
Oyama, E., Tsunemoto, N., Tachi, S., et Inoue, Y. (1992). Remote manipulation using
virtual environment. In 2nd Int. Symp. on Measurement and Control in Robotics,
ISMCR’92, pages 311–318, Tsukuba Science City, Japan, Nov. 15-19.
Pampagnin, L. Reconnaissance d’objets tridimensionnels en perception monoculaire et
multisensorielle - Application à la robotique spacials. Thèse de doctorat, Université
Paul Sabatier, Toulouse (31 Octobre 1990).
Peroche, B., Ghazanfarpour, D., Argence, J., et Michelucci, D. (1988). La synthèse
d’image. Hermes.
Pira, R. (1998). New geometric solids in ray tracing.
http ://www.engr.mun.ca/∼rahim/graphics/superquad noframe.html.
Qiang, S. Stratégies de localisation et identification d’objet à partir de quelques mesures
tridimensionnelles. Thèse de doctorat, Institut National Polytechnique de Larraine
(10 Juillet 1989).
163
BIBLIOGRAPHIE
Rastogi, A., Milgram, P., Drasic, D., et Grodski, J. J. (1996). SPIE Volume 2653 :
Stereoscopic Displays and Virtual Reality Systems III. Mark T. Boalas and Scott S.
Fisher and John O. Merritt, San Jose, California, USA.
Rosenberg, L. (1992). The use of virtual fixtures as perceptual overlays to enhance ope-
rator performance in remote environments. In Technical Report, No. AL-TR-1992-
XXX, USAF Amstrong Laboratory, WPAFB OH.
Rosenberg, L. (1993). The use of virtual fixtures to enhance telemanipulation with time
delay. In Proceedings, ASME Winter Anual Meeting on Haptic Interfaces for Virtual
environment and Teleoperator Systems, New Orleans, Loisiana.
Saucy, P. et Mondala, F. (Oct. 12-17, 1998). Khepontheweb : One year of access to a
mobile robot on the internet. In IEEE/RSJ International Conference on Intelligent
Robots and Systems IROS’98, pages 23–30, Victoria, B.C. Canada.
Sayers, C. et Paul, R. (1994). An operator interface for teleprogramming employing
synthetic fixtures. In Presence, volume 3, No. 4.
Sayers, C., Lai, A., et Paul, R. (May, 1995). Visual imagery for subsea teleprogramming.
In IEEE Robotics and Automation Conference.
Schal, T. et Zeller, B. (1990). A methodological approach to computer-supported coope-
rative work. In Fifth European Conference on Cognitive Ergonomics, pages 3–6.
Schulz, D., Burgard, W., et Cremers, A. (Oct. 12-17, 1998). Predictive simulation of au-
tonomous robots for tele-operation systems using the world wide web. In IEEE/RSJ
International Conference on Intelligent Robots and Systems IROS’98, pages 31–36,
Victoria, B.C. Canada.
Shaheen, M. Reconnaissance d’objets polyèdriques à partir d’une image vidéo pour la
téléopération. Doctorat de robotique, Université d’Evry Val d’Essonne (9 avril 1999).
Sheridan, T. B. (1992). Telerobotics, Automation and Human Supervisory Control. The
MIT Press, Cambridge, USA.
Sheridan, T. (1993). Space teleoperation through time delay : Review and prognosis. The
IEEE Trans. on Robotics and Automation, 9 :592–606.
Simmons, R. (Oct. 12-17, 1998). Xavier : An autonomous mobile robot on the web.
In IEEE/RSJ International Conference on Intelligent Robots and Systems IROS’98,
pages 43–48, Victoria, B.C. Canada.
Spenny, C. et Schneider, D. (1997). Object resolved teleoperation. In IEEE Int. Conf. on
Robotics and Automation, ICRA’97, Albuquerque, NM, USA, April 20-25.
Spong, M. (1993). Communication delay and control in telerobotics. In Journal of the
Robotics Society of Japan, volume 11, No. 6, pages 803–810.
Stein, M. (Oct. 12-17, 1998). Painting on the world wode web : The pumapaint project.
In IEEE/RSJ International Conference on Intelligent Robots and Systems IROS’98,
pages 37–42, Victoria, B.C. Canada.
Tarn, T. J., Xi, N., Guo, C., et Bejczy, A. (1995). Function-based control sharing for ro-
botic systems. In IEEE/RSJ Int. Conf. on Intelligent Robots and Systems, IROS’95,
volume 3, pages 1–6, Pittsburgh, PA, August 5-9.
Taylor, K. et Trevelyan, J. (Oct. 1995). Australia’s telerobot on the web. In 26t h Inter-
national Symposium On Idustrial Robots, Singapore.
Thibout, C. Réalité Virtuelle et Langages Graphiques : une application pour la
téléopération. Doctorat de mention informatique, Université de Rennes 1 (07 no-
vembre 1996).
164
BIBLIOGRAPHIE
Triboulet, J. Caractèrisation d’un système multicapteur pour la modélisation d’environ-

nement : application à la téléopération. Doctorat de spécialité robotique, Université
d’Evry Val d’Essonne , France (1996).
Uenohara, M. et Kanade, T. (1995). Vision-based object registration for real-time image
overlay. In Computer Vision, Virtual Reality and Robotics in Medicine : CVRMed
’95, pages 14–22, N. Ayache. Berlin, Springer-Verlag.
Urban, E. C. (1995). The information warrior. In IEEE Spectrum, volume 11, pages
66–70.
Vertut, J. et Coiffet, P. (1984). Les Robots : Téléopération. Edition Hermes, Vol 3A et
3B, Paris, France.
Wang, C., Cannon, D. J., et MA, H. (1996). A human-machine system interacting virtual
tools with a robotic collision avoidance concept using conglomerates of sphers. In
Jounal in Teleoperation.
Zak, H. et Das, H. (1995). Towards a training methodology for skilled teleoperation. In
IEEE Trans. on Systems Man and Cybernetics, volume 25, No. 2, pages 313–327,
Februrary.
165
BIBLIOGRAPHIE
166
Table des figures
1.1 Illustration de l’architecture générale d’un système de Téléopération . 11

1.2 Exemples de système : A gauche, le système de téléopération du CEA/CEREM ;
A droite, le système de téléprésence avec un robot mobile du groupe
de recherche en téléprésence “California Corporation Telepresence Re-
search” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Classement de la TAO, TDO et TSA selon le degré d’autonomie du
dispositif esclave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 Exemple du système Poste de Travail Mobile (PTM) du CEA piloté
par un contrôleur TAO 2000 . . . . . . . . . . . . . . . . . . . . . . . 15
1.5 Exemples de robots : A gauche, l’exploration de Mars par “sojourner”,
à droite , la maintenance de satellites . . . . . . . . . . . . . . . . . . 15
1.6 Exemple d’utilisation d’un robot embarqué sur un véhicule sous marin
JASON ((Sayers et al., 1995)) . . . . . . . . . . . . . . . . . . . . . . 16
1.7 Illustration de la téléchirurgie . . . . . . . . . . . . . . . . . . . . . . 17
1.8 Rehaussement d’images vidéo dégradées par superposition d’une image
synthétique “fil de fer” à une image caméra . . . . . . . . . . . . . . 21
1.9 Utilisation de la prédiction graphique pour la téléopération spatiale. A
gauche prédiction et confirmation de la tâche, à droite exécution . . . 23
1.10 Architecture du système ARTEMIS . . . . . . . . . . . . . . . . . . . 24
1.11 schéma général du système de téléopération proposé par Kheddar . . 25
2.1 les mécanismes virtuels pour la télémanipulation : A gauche, la struc-

ture avec les coordonnées cylindriques (x, r, θ1 ) et l’impédance mécanique
attachée au bout de l’outil (θ2 , θ3 , θ4 ) qui permet le suivi de surface.
A droite, un mécanisme virtuel associé à la tâche d’assemblage de la
boı̂te saisie par le robot. . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2 Téléopération basée sur le concept de mécanismes virtuels (d’après
Joly et Andriot 95 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3 Exemple d’outils virtuels : en haut, des champs de force répulsifs pour
l’évitement de zones dangereuses ; en bas, des mécanismes virtuels à
placer sur l’effecteur du robot pour guider ses mouvements (ici la rotule
pour le blocage des translations, la glissière pour le suivi de droite et
de pivot) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 La métaphore de la boı̂te à outils virtuels . . . . . . . . . . . . . . . 34
TABLE DES FIGURES
2.5 le système de téléprésence utilisé pour tester les performances de l’opérateur

lors des tâches d’insertion avec ou sans l’aide des guides virtuels . . . 35
2.6 Exemples de guides virtuels projetés dans la zone de manipulation
pour assister l’opérateur dans des tâches d’insertion d’après Rosenberg 35
2.7 Le système de téléprogrammation utilisé par Sayers : A gauche, le site
maı̂tre ; A droite le site esclave. . . . . . . . . . . . . . . . . . . . . . 36
2.8 exemple de guides virtuels d’assistance à l’opérateur proposés par Sayers
en 1994 : Première ligne, guide virtuel point-point pour déplacer la
pointe de l’effecteur jusqu’à un point dans l’espace et ensuite effec-
tuer des rotations ; Deuxième ligne, pour le suivi de zones circulaires ;
Troisième ligne, pour effectuer un contact surface-surface. . . . . . . 37
2.9 Guides virtuels dédiés exclusivement à l’assistance de l’opérateur. Une
projection du repère du pouce sur le sol permet un guidage plus précis
pour saisir ou manipuler les objets virtuels. . . . . . . . . . . . . . . 37
2.10 Exemple d’application des guides virtuels. Ajustement d’un préhenseur
limité en capacité d’ouverture monté sur un robot plan de type SCARA.
Cette figure illustre aussi les transformations entre l’action de l’opérateur
et le robot intermédiaire de transformation. . . . . . . . . . . . . . . 38
2.11 Classification de la métaphore des guides virtuels. . . . . . . . . . . . 38
2.12 Exemple d’une parabole générée par la famille des coniques . . . . . 40
2.13 Exemple d’hyperboles et d’ellipse générées par la famille des coniques 41
2.14 Exemple de superellipses, de haut en bas et de gauche à droite avec
p=0.38, 0.78, 1, 1.78, 2, 3 et 6 . . . . . . . . . . . . . . . . . . . . . . 41
2.15 ellipsoı̈des avec ε1 = ε2 = 1, a1 = a2 = a3 etε1 = ε2 = 1, a1 > a2 > a3 . 42
2.16 ellipsoı̈des avec ε1 = 1, ε2 = 2; ε1 = 0.1, ε2 = 1; ε1 = ε2 = 0.35 . . . . . 43
2.17 ellipsoı̈des avec ε1 = ε2 = 3; ε1 = ε2 = 2; ε1 = 3, ε2 = 2 . . . . . . . . . 43
2.18 supertoroı̈des avec ε1 = ε2 = 1, ε1 = ε2 = 0.5 . . . . . . . . . . . . . . 43
2.19 supertoroı̈des avec ε1 = 3, ε2 = 1; ε1 = 1, ε2 = 3; ε1 = ε2 = 2 . . . . . . 44
2.20 Cône, Cylindre, tube, cube, disque et plan . . . . . . . . . . . . . . . 46
2.21 Représentation simplifiée de la projection perspective, f étant la focale. 47
2.22 Exemple de sélection d’un objet virtuel sur écran . . . . . . . . . . . 48
2.23 Exemple d’un cube avant déformation . . . . . . . . . . . . . . . . . 49
2.24 Résultat de la déformation sur le cube . . . . . . . . . . . . . . . . . 49
2.25 Plan, Cube ouvert et Cylindre : En haut, avant déformation ; En bas
après déformation avec p = 0.99 et f = 0.9 . . . . . . . . . . . . . . . 50
2.26 Collision entre l’effecteur du robot et un objet guide sous forme d’une
demi-sphère . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.27 La géométrie des guides : de gauche à droite : Cube, (cylindre ou cône
ou tube), (cône ou tube droits), plan, disque. . . . . . . . . . . . . . 52
2.28 Zone de collision de seuil “d” autour d’un segment [AB] . . . . . . . 53
2.29 Existence de trous dans les guides virtuels . . . . . . . . . . . . . . . 53
2.30 Modèle utilisé à l’écran (en haut) et modèle utilisé pour les calculs (en
bas) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
TABLE DES FIGURES
2.31 Exemple de sphère de sécurité . . . . . . . . . . . . . . . . . . . . . . 54

2.32 Exemple de “guide virtuel simple”, pour assister l’opérateur et/ou le
robot à atteindre une cible . . . . . . . . . . . . . . . . . . . . . . . . 56
2.33 Exemple de “guide virtuel composé”, pour assister l’opérateur et/ou
l’effecteur du robot à suivre une trajectoire et manipuler un objet . . 56
2.34 Exemple de “guide virtuel composé”, pour assister l’opérateur et/ou
un robot mobile à traverser un porte . . . . . . . . . . . . . . . . . . 57
2.35 Exemple de “guide virtuel répulsif”, à gauche, une barrière et à droite,
un volume englobant répulsif . . . . . . . . . . . . . . . . . . . . . . 57
2.36 Exemple de “guide virtuel attractif”, pour atteindre un objet de l’en-
vironnement avec un outil porté par le robot . . . . . . . . . . . . . . 58
2.37 Représentation des différents types de données générés lors de la création
d’un guide virtuel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.38 Schéma général de la structure des propriétés d’un guide virtuel . . . 60
3.1 Représentation informatique BREP d’un polyèdre . . . . . . . . . . . 66

3.2 Représentation CSG simple . . . . . . . . . . . . . . . . . . . . . . . 66
3.3 Exemple de représentation interne d’un triangle dans l’espace . . . . 68
3.4 Modèles géométriques de caméra . . . . . . . . . . . . . . . . . . . . 69
3.5 Les composantes du robot à 4 ddl utilisé pour la calibration . . . . . 73
3.6 Les différents repères du système de mesures . . . . . . . . . . . . . . 73
3.7 Illustration du matériel utilisé pour la réalisation du système ARITI 77
3.8 Architecture simplifiée du système ARITI . . . . . . . . . . . . . . . 78
3.9 Le continuum Réalité-Virtualité d’après Milgram 1994 et Hickey 2000 79
3.10 Représentation des données réelles et virtuelles dans un environnement
mixte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.11 Les trois types d’assistance pendant le télétravail . . . . . . . . . . . 80
3.12 Illustration de l’assistance à la perception de l’environnement . . . . 80
3.13 Illustration de l’assistance à la commande . . . . . . . . . . . . . . . 81
3.14 Organigramme d’assistance à la supervision . . . . . . . . . . . . . . 81
3.15 Schéma simplifié de la téléopération sans assistance à la commande . 82
3.16 Schéma simplifié de la téléopération avec assistance à la commande . 82
3.17 Illustration de la tâche “désignation d’une cible à l’écran” . . . . . . 84
3.18 Schéma simplifié de l’exécution de tâches en mode Téléprogrammation. 84
3.19 Illustration à la Télésupervision. . . . . . . . . . . . . . . . . . . . . 85
3.20 Exemple de préparation et d’exécution d’une mission, (A) : préparation
et exécution par un seul opérateur, (B) : Télétravail coopératif avec 4
opérateurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.21 Architecture générale de communication avec le système ARITI : En
pointillés, une possibilité d’accéder directement au serveur ARITI sans
passer par le serveur Web . . . . . . . . . . . . . . . . . . . . . . . . 87
3.22 Protocole de demande d’un numéro d’identification . . . . . . . . . . 87
3.23 Protocole de communication client/serveur image . . . . . . . . . . . 89
TABLE DES FIGURES
3.24 Schéma de fonctionnement simplifié du serveur image . . . . . . . . . 89

3.25 Schéma détaillé du fonctionnement du serveur image . . . . . . . . . 90
3.26 Protocole de communication client/serveur commande. Le caractère
“S” désigne la demande de contrôle du robot . . . . . . . . . . . . . 91
3.27 Protocole de communication entre le serveur de commande et les autres
clients superviseurs : le caractère “F désigne la demande de l’état final
du robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.28 Schéma détaillé du fonctionnement du serveur de commande . . . . . 94
4.1 Image du robot et de la zone de manipulation. . . . . . . . . . . . . . 96

4.2 Image de l’armoire de commande (a) et de la caméra montée sur une
tourelle (b) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.3 Caractéristiques d’un objet à manipuler et de son support . . . . . . 97
4.4 Illustration des deux types de clients “Administrateur” et “Utilisateur”
du système ARITI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.5 l’IHM destinée au client administrateur, avec en haut à gauche, une
image vidéo de résolution 288 × 384, en bas à droite la partie réservée
à l’administrateur pour créer des guides virtuels. . . . . . . . . . . . 99
4.6 l’IHM destinée au client utilisateur, avec en haut à gauche, une image
vidéo de résolution 192×256, et l’utilisateur ne peut pas créer de guides
virtuels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.7 (A) : Tableau de bord de l’interface de ARITI. (B) : mode téléopération,
(C) : mode téléprogrammation de tâche, (D) : contrôle du robot réel
et le mode télésupervision ou télécoopération . . . . . . . . . . . . . 101
4.8 L’interface du modeleur 3D pour la création et la manipulation de
guides virtuels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.9 Générateur de guides virtuels : Exemple d’un plan généré à partir de
deux paramètres, la longueur et la largeur. . . . . . . . . . . . . . . . 103
4.10 Guide virtuel utilisé pour atteindre une cible : ici la cible est un point
3D se trouvant sur la périphérie de l’objet cylindre . . . . . . . . . . 103
4.11 Propriétés du guide virtuel d’assistance à la téléopération pour at-
teindre une cible. La cible dans ce cas est l’objet cylindre numéro 3
(figure 4.1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.12 Illustration du principe de suivi de cible mobile par l’effecteur du robot. 106
4.13 Exemple de suivi de cible mobile par le robot. La cible est atteinte
par le robot (A), a effectué une translation par rapport à l’axe X (B),
ensuite une rotation par rapport à l’axe Z (C) et enfin une translation
par rapport à l’axe Z (D) . . . . . . . . . . . . . . . . . . . . . . . . 107
4.14 Le guide virtuel utilisé pour le suivi de contour. Le point “E” désigne
l’extrémité de l’effecteur du robot et le point “A” appartient au contour
du disque de passage de “E”. . . . . . . . . . . . . . . . . . . . . . . 107
4.15 Propriètés du guide virtuel utilisé pour le suivi de contour. Dans ce
cas ce guide permet de suivre le contour du cylindre numéro 1 . . . . 108
TABLE DES FIGURES
4.16 Le guide virtuel utilisé pour la saisie d’un objet cylindre. Le point E
désigne l’extrémité de l’effecteur du robot et le point A désigne le
centre du disque passant par le point E . . . . . . . . . . . . . . . . 109
4.17 Les propriétés des guides virtuels utilisés pour la saisie de l’objet cy-
lindre numéro 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.18 Le guide virtuel utilisé pour le dépôt d’un objet cylindre. (A) : Position-
nement des différents guides, avec le point E qui désigne l’extrémité
de l’effecteur du robot et le point A le centre du disque passant par
le point E ; (B) : Exemple d’influence des guides sur les trajectoires
réalisées par les robots virtuel et réel. . . . . . . . . . . . . . . . . . . 111
4.19 Les propriétés des guides virtuels utilisés pour le dépôt de l’objet cy-
lindre numéro 3 sur le support numéro 1. . . . . . . . . . . . . . . . . 113
4.20 Mise à jour de l’architecture du système ARITI pour le contrôle d’un
robot mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.21 Les images des deux robots mobiles utilisés. (A) : le robot utilisé avec
le système ARITI, (B) : le robot destiné au projet d’assistance aux
personnes handicapées . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.22 L’IHM utilisée pour le contrôle et la supervision du robot mobile. . . 116
4.23 Illustration de la téléopération d’un robot mobile avec assistance de
deux guides virtuels répulsifs sous forme de plans. (A) : Le robot mobile
subit l’influence des deux guides, (B) : le robot traverse la porte. . . 117
4.24 Propriétés des deux guides virtuels utilisés pour traverser une porte
par le robot mobile. . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.25 Simulation du parcours d’une B-Spline par le robot mobile virtuel.
(A) : l’état initial, (B) : pendant le parcours, (C) : le robot traverse la
porte, (D) : l’état final . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.26 Propriétés du guide virtuel généré par une B-Spline . . . . . . . . . . 119
4.27 Illustration du télé-enseignement . . . . . . . . . . . . . . . . . . . . 121
5.1 Vue rapprochée de l’effecteur du robot et des trois cylindres en poly-

styrène. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.2 Illustration du découpage de l’environnement virtuel en trois zones . 126
5.3 Illustration du signal visuel utilisé pour atteindre le cylindre numéro 1 127
5.4 Gestion des collisions pendant que l’opérateur essaie d’atteindre le cy-
lindre numéro 1. (A) : détection des collisions, (B) : le nombre total
de collisions réalisé par chaque opérateur. . . . . . . . . . . . . . . . 127
5.5 Les imprécisions obtenues lorsque la cible est atteinte. (A) : la moyenne
des dix tests pour chaque opérateur suivant X, Y et Z, (B) : la moyenne
sur les dix opérateurs suivant X, Y et Z. . . . . . . . . . . . . . . . . 128
5.6 Le temps moyen pour atteindre la cible (cylindre numéro 1) à chaque
essai. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.7 Utilisation d’un guide virtuel pour atteindre le cylindre numéro 1 . . 129
TABLE DES FIGURES
5.8 Les imprécisions obtenues lorsque la cible est atteinte en utilisant un

guide virtuel repulsif. (A) : la moyenne des dix tests pour chaque
opérateur suivant X, Y et Z, (B) : la moyenne sur les dix opérateurs
suivant X, Y et Z . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
essai en utilisant un guide virtuel répulsif . . . . . . . . . . . . . . . 130
5.10 Les imprécisions obtenues suivant X, Y et Z, lorsque la cible est at-
teinte en utilisant un guide virtuel attractif . . . . . . . . . . . . . . 131
essai en utilisant un guide virtuel attractif . . . . . . . . . . . . . . . 132
5.12 Utilisation d’un guide virtuel pour saisir et sortir le cylindre numéro 1
depuis son support métallique. . . . . . . . . . . . . . . . . . . . . . 132
5.13 Le temps moyen pour saisir le cylindre numéro 1 à chaque essai : (A) en
utilisant un guide virtuel répulsif, (B) avec un guide virtuel attractif.
En pointillé sont représentées les moyennes pour les dix opérateurs. . 133
5.14 Utilisation d’un guide virtuel pour déposer le cylindre numéro 1 sur le
support métallique numéro 3. . . . . . . . . . . . . . . . . . . . . . . 133
5.15 Le temps moyen pour déposer le cylindre numéro 1 sur le support
numéro 3 à chaque essai : (A) en utilisant un guide virtuel répulsif,
(B) avec un guide virtuel attractif. En pointillé sont représentées les
moyennes sur les dix opérateurs . . . . . . . . . . . . . . . . . . . . . 134
5.16 Evaluation des algorithmes de compression suivant la dynamique de
l’image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.17 Les temps de compression lorsqu’il y a peu de mouvements dans l’image. 136
5.18 Les temps de compression lorsqu’il y a beaucoup de mouvements dans
l’image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.19 Organigramme de choix automatique de méthodes de compression
d’image. l’image est envoyée aux clients avec le type de compression
utilisé. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.20 Evaluation du temps de capture d’images vidéo Ti avec dix images
successives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.21 Evaluation du temps d’envoi Te suivant la dynamique de l’image. Le
temps représenté est une moyenne sur dix images envoyées. . . . . . 138
5.22 Evaluation des temps serveur et réponse du client lorsqu’il y a peu de
mouvements dans l’image. (A) : Pour des images brutes, (B) : Pour
des images compressées avec Gzip. . . . . . . . . . . . . . . . . . . . 140
5.23 Evaluation des temps serveur et réponse du client lorsqu’il y a peu de
mouvements dans l’image. (A) : Pour des images prétraitées ensuite
compressées en Gzip, (B) : Pour des images prétraitées en compressées
avec Huffman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.24 Evaluation des temps serveur et réponse du client lorsqu’il y a beau-
coup de mouvements dans l’image. (A) : Pour des images compressées
avec Gzip, (B) : Pour des images prétraitées et ensuite compressées
avec Gzip. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
TABLE DES FIGURES
5.25 Evaluation des temps serveur et réponse du client à moyenne distance.

L’adresse Internet du site client est “Toulouse-17-133.abo.wanadoo.fr”. 141
L’adresse Internet du site client est “pc-41-13.inrets.fr”. . . . . . . . 142
L’adresse du site client est “dyn-213-36-102-192.ppp.libertysurf.fr”. . 142
L’adresse Internet du site client est “pc.area.ba.cnr.it”. . . . . . . . . 143
5.29 Evaluation des temps serveur et réponse du client à longue distance.
L’adresse du site client est “1Cust161.tnt1.san-francisco3.ca.da.uu.net” 144
5.30 Evaluation des temps serveur et réponse du client à longue distance.
L’adresse Internet du site client est “internet-pub2.biblio.polymtl.ca” 144
5.31 Les temps moyens, serveur et reprise du serveur, pour une connexion
de 1 à 5 clients lorsqu’il y a peu de mouvements dans l’image. (A) :
Pour des images brutes, (B) : Pour des images compressées avec Gzip. 146
5.32 Les temps moyens, serveur et reprise du serveur, pour une connexion
de 1 à 5 clients lorsqu’il y a peu de mouvements dans l’image. (A) :
Pour des images prétraitées ensuite compressées en Gzip, (B) : Pour
des images prétraitées et compressées avec Huffman. . . . . . . . . . 146
5.33 Les temps serveur, et reprise du serveur, pour une connexion de 1 à 5
clients lorsqu’il y a beaucoup de mouvements dans l’image. (A) : Pour
des images compressées avec Gzip, (B) : Pour des images prétraitées
et ensuite compressées avec Gzip. . . . . . . . . . . . . . . . . . . . . 147
5.34 Temps de mise à jour des images réelles et des environnements vir-
tuels en fonction du nombre d’opérateur utilisant le système ARITI en
connexion locale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
5.35 Illustration des transferts d’informations multimodales via Internet
entre le site maı̂tre (client) et le site esclave (serveur). . . . . . . . . 154
5.36 Illustration de la communication entre le système ARITI et MCIT
pour faire du recalage d’objets virtuels sur les objets réels. . . . . . . 155
5.37 Illustration de la téléopération de deux robots par deux clients distants
en utilisant une extension du système ARITI. . . . . . . . . . . . . . 156
5.38 Illustration de l’utilisation d’un seul robot par plusieurs personnes han-
dicapées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
A.39 Illustration de l’arbre binaire de Huffman pour la compression d’images i
B.40 Tâche de téléprogrammation “Atteinte du cible” . . . . . . . . . . . v
B.41 Tâche de téléprogrammation “Atteinte une cible mobile” . . . . . . . vi
B.42 Tâche de téléprogrammation “Suivre le contour du cylindre numéro 1” vi
B.43 Tâche de téléprogrammation “Saisir ou Déposer un objet” . . . . . . vii
B.44 Tâche de téléprogrammation “Tour de Hanoı̈” . . . . . . . . . . . . . viii
TABLE DES FIGURES
Liste des tableaux
1.1 Développement du télétravail en Europe, 1998-1999. d’aprés (Béréziat

et al., 2000) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Etude marketing des applications de RV . . . . . . . . . . . . . . . . . 18
2.1 Les paramètres des guides virtuels pour la détection des collisions. . . . 51
2.2 Les équations des guides virtuels pour la détection des collisions . . . . 52
2.3 Les différents cas d’utilisation des guides virtuels associés à chaque acteur. 61
3.1 Les paramètres obtenus lors de calibration de la tige du robot . . . . . 75
4.1 Exemple d’organisation d’une équipe pour la réalisation d’une mission

de téléopération en coopération . . . . . . . . . . . . . . . . . . . . . . 114
5.1 Vitesses de déplacement et de rotation des composantes du robot réel . 125

5.2 Les pas de déplacement et de rotation du robot virtuel . . . . . . . . . 126
5.3 Quelques résultats de connexion à moyenne distance . . . . . . . . . . . 143
5.4 Quelques résultats de connexion à longue distance . . . . . . . . . . . . 145
5.5 La moyenne des temps pour la mise à jour des images réelles et des
environnements virtuels lors d’un télétravail coopératif avec plusieurs
opérateurs. Dans ce cas, les opérateurs se trouvent dans le même la-
boratoire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
environnements virtuels lors d’un travail coopératif avec deux opérateurs
distants. Dans ce cas, les opérateurs se trouvent en Espagne. . . . . . . 149
environnements virtuels lors d’un travail coopératif avec deux opérateurs
distants. Dans ce cas, le premier se trouve en Italie et le deuxième au
Canada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
C.8 Quelques adresses Internet des sites clients en Europe ayant utilisé ARITI ix
C.9 Quelques adresses Internet des sites clients dans le monde ayant utilisé
ARITI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
C.10 suite : Quelques adresses Internet des sites clients dans le monde ayant
utilisé ARITI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
LISTE DES TABLEAUX
Annexes
A Les méthodes de compression Gzip et Huffman

A.1 Codage de Huffman
Le codage de Huffman est préparé par un algorithme spécial que nous avons mis en
œuvre pour avoir une bonne compression d’images dans certains cas (peu de mouvements
dans l’image). Chaque élément de l’image (par exemple : un octet) est remplacé, suivant
un alphabet spécifique, par une série de 0 ou de 1.
Pour compresser, l’algorithme de Huffman applique deux passes :

– Première passe : Permet de mesurer le poids de chaque élément dans l’image. Ce
poids correspond au nombre de fois qu’un élément est présent dans le fichier à
compresser. Puis, grâce aux poids obtenu, on en déduit un arbre binaire de Huffman
où chaque fin de branche correspond à un élément (Voir Figure A.39).
– Deuxième pass : Permet de remplacer chaque élément du fichier par son alphabet
de Huffman correspondant.
Fig. A.39 – Illustration de l’arbre binaire de Huffman pour la compression d’images

ANNEXES
Pour le cas du serveur image, nous avons choisi un cas particulier de l’arbre de Huff-
man : les branches de gauche (qui ont une valeur de 1) n’ont pas de branches filles.
L’avantage avec cet arbre, c’est que son codage reste simple : on a juste à donner le
nombre d’éléments suivi des éléments puis du codage.
A.1.1 Avantage de la compression d’Huffman

– Rapide (GZip demande plus de temps).
– Bonne compression dans le cas où seulement quelques éléments ont des poids très
grands.
– Compression sans perte.
Par conséquent cette compression peut être très mauvaise s’il y a beaucoup de mouvements
dans l’image.
A.1.2 Exemple de compression
soit par exemple le mot ’PRESSEEPRESSEE’ :

– Poids de ’P’ : 2
– Poids de ’R’ : 2
– Poids de ’E’ : 6
– Poids de ’S’ : 4
Grâce à l’arbre créé, la compression donne :
000.001.1.01.01.1.1.000.001.1.01.01.1.1
Soit 26 bits, donc 4 octets (sans compter l’entête) au lieu de 14 octets.
Le codage serait par exemple :
14d, 04d, E, S, R, P, 00000110b, 10111000b,00110101b,11000000b
au lieu de :
14d, ’P’, ’R’, ’E’, ’S’, ’S’, ’E’, ’E’, ’P’ ,’R’, ’E’, ’S’, ’S’, ’E’, ’E’
soit 10 octets au lieu de 15.
A.2 Codage de Gzip

Pour compresser en Gzip, on utilise la librairie ’Zlib’. Cette compression utilise une
méthode de dégonflement’ qui correspond à un codage de Huffman spécifique et un com-
pactage LZ77.
Dans la méthode de dégonflement’, on ajoute 2 règles supplémentaires dans l’algo-
rithme de Huffman classique :
– Les éléments qui ont des codes plus courts sont placés à la gauche de ceux de plus
longs codes.
– Le positionnement d’éléments ayant des codes de même longueur, sont toujour placés
vers la gauche.
La compression de LZ77 consiste à retrouver des mots qui sont répétés. Par exemple, si
on a :
’Blah blah blah blah blah !’
on pourra le coder par

Blahb[D = 5, L = 18]! .
[D = 5] veut dire que le début de la chaı̂ne a une distance de 5, ce qui donne le mot
’lah b’
ii
A. GZIP ET HUFFMAN
[L = 18] veut dire que le mot sera répété jusqu’à obtenir une longueur de 18 caractères. La
compression Gzip utilise la compression LZ77 en premier, puis la compression de Huffman.
A.2.1 Avantage de la compression GZip

– Rapide si le niveau de compression est bas.
– Bonne compression en général (allant de 5 :1 à 2 :1).
– Compression sans perte.
– La librairie existe C/C++ et en Java.
Par contre, la compression Gzip devient trop lente pour un niveau de compression trop
haut.
iii
ANNEXES
iv
B. FONCTIONNEMENT DES TACHES DE TELEPROGRAMMATION
B Schémas de fonctionnement des tâches de téléprog-

rammation
B.1 Atteindre un point cible
La figure ci-dessous (B.40) montre le schéma de fonctionnement de la tâche consistant
à atteindre une cible dont l’opérateur fournis les coordonnées 3D.
Choix du mode de légende:

fonctionnement
Type_tache="Atteindre cible" évènement
Saisie des coord 3D Etat
Validation Fonction
Demarrer Teleprogrammation
Création et lancement d’une

thread pour synchronisation
oui
Arret ? non Automate pour Atteindre un cible
Calcule les ordres à envoyer

(Modèle Géométrique Inverse)
Envoie les ordres au

robot virtuel
Envoie les ordres au robot réel
Synchronisation
robot virtuel / robot réel
oui non
Type_tache="" Fin de tache
Fig. B.40 – Tâche de téléprogrammation “Atteinte du cible”
B.2 Atteindre une cible mobile

La figure B.41 montre le schéma de fonctionnement de la tâche consistant à atteindre
une cible mobile.
Cette tâche utilise donc l’automate précédent pour atteindre une cible.
B.3 Suivre le contour du cylindre 1

La figure B.42 montre le schéma de fonctionnement de la tâche consistant à suivre le
contour du cylindre 1. Elle utilise aussi l’automate pour atteindre une cible.
B.4 Prendre/déposer un objet

La figure B.43 montre le schéma de fonctionnement de la tâche consistant à prendre
ou à déposer une cylindre.
A tout instant, on connaı̂t l’état mémoire du système grâce à deux tableaux : le premier
v
ANNEXES
légende:
Type_tache="Atteindre cible" évènement
Clic sur le bouton Mode Etat

ModeTrouverPoint3D
Choix du mode de Fonction

Clic sur fenetre 2 Fonctionnement
Clic sur fenetre 3
Calcul du point 3D
correspondant
Démarrer téléprogrammation
Création et lancement d’une thread pour

synchronisation robot virtuel/ robot réel
AUTOMATE POUR ATTEINDRE UNE CIBLE
Fig. B.41 – Tâche de téléprogrammation “Atteinte une cible mobile”

Fonctionnement
évènement
Type_tache="Suivi de contour"
Etat
Démarrer téléprogrammation
Fonction
Création et lancement d’une thread

pour synchronisation robot virtuel/ robot réel
oui Tour de cercle

terminé ?
non
Calcul du point 3D
correspondant
AUTOMATE POUR ATTEINDRE UNE CIBLE
Fig. B.42 – Tâche de téléprogrammation “Suivre le contour du cylindre numéro 1”
vi
B. FONCTIONNEMENT DES TACHES DE TELEPROGRAMMATION
tableau contient le numéro du support de chaque cylindre et le deuxième tableau contient

la position du cylindre sur son crochet.

fonctionnement
évènement
Type_tache="Prendre / Deposer objet"
Etat
Fonction
oui
Arret ? non
Calcule les ordres a envoyer

grace au Modèle Géométrique Inverse
Envoie les ordres au

robot virtuel
Envoie les ordres au robot réel
Synchronisation
robot virtuel / robot réel
mise à jour de oui non

l’état des supports Fin de tache
Fig. B.43 – Tâche de téléprogrammation “Saisir ou Déposer un objet”
B.5 Tour de Hanoı̈

La figure B.44 montre le schéma de fonctionnement de la tour de Hanoı̈. Ce schéma
utilise l’automate permettant d’atteindre une cible.
L’algorithme de la tour de Hanoı̈ correspond à une succession de tâches de prise et de
dépôt d’objets. On peut donc créer une tâche complexe à partir d’un ensemble de tâches
plus simples.
vii
ANNEXES

fonctionnement
évènement
Type_tache="Prendre / Deposer objet"
On rentre le n° du crochet de Etat

départ et d’arrivée
Fonction

Mise à jour état des supports
ALGORITHME DE LA TOUR DE HANOI
mise à jour de
l’état des supports
Type_tache=""
Fig. B.44 – Tâche de téléprogrammation “Tour de Hanoı̈”
viii
C. ADRESSE INTERNET DES SITES CLIENTS
C Les sites clients ayant utilisé ARITI

Nous présentons dans cette annexe, les adresses et les noms Internet des sites clients
dans le monde ayant utilisés le système ARITI entre juillet et fin septembre 2000.
C.1 En Europe
Adresse du site distant Nom du site distant

– France – – France –
213.36.112.69 dyn-213-36-112-69.ppp.libertysurf.fr
195.132.110.53 r110m53.cybercable.tm.fr
131.254.40.59 castor.irisa.fr
131.254.40.52 semnon.irisa.fr
164.138.17.133 Toulouse-17-133.abo.wanadoo.fr
137.121.41.13 pc-41-13.inrets.fr
— Espagne — — Espagne —
62.36.142.66 usuario1-36-142-66.dialup.uni2.es
— Italie — — Italie —
194.119.205.166 ba.cnr.it
139.191.160.68 pcrt28.jrc.it
- Royaume Uni- - Royaume Uni -

62.137.116.152 modem-152.pigeon.dialup.pol.co.uk
212.111.142.8 user142008.dial.netline.net.uk
– Gréce – – Gréce –
143.233.3.18 iris.iit.demokritos.GR
195.242.129.18 borealis.compulink.gr
- Finlande - - Finlande -
212.38.227.18 free-1-18.dyn.nic.fi
Tab. C.8 – Quelques adresses Internet des sites clients en Europe ayant utilisé ARITI
ix
ANNEXES
C.2 Dans le monde

– Argentine – – Argentine –
200.45.52.199 host052199.arnet.net.ar
200.47.57.181 line181.comsat.net.ar
200.42.105.46 a200042105046.rev.prima.com.ar
200.32.56.184 rqta-1-184.trcnet.com.ar
200.42.136.184 a200042136184.rev.prima.com.ar
209.13.191.122 AVE2ppp-890.uc.infovia.com.ar
200.51.38.140 modem140-as12.capfed1.sinectis.com.ar
200.10.117.168 ppp-117-168.movi.com.ar
216.244.207.59 modem59-tc11.capfed1.sinectis.com.ar
200.42.146.89 a200042146089.rev.prima.com.ar
200.45.52.199 host052199.arnet.net.ar
200.42.105.46 a200042105046.rev.prima.com.ar
200.16.135.225 h200016135225.ssd.net.ar
– Brésil – – Brésil –
200.135.24.31 maverick.furb.rct-sc.br
- Australie - - Australie -
203.12.148.119 as1-p119.ncle.hunterlink.net.au
- Mexique - - Mexique -
148.233.186.36 du-148-233-186-36.prodigy.net.mx
- Canada - - Canada -
132.207.88.24 internet-pub2.biblio.polymtl.ca
Tab. C.9 – Quelques adresses Internet des sites clients dans le monde ayant utilisé ARITI
x
C. ADRESSE INTERNET DES SITES CLIENTS

- .net - - .net -
38.30.134.121 ip121.baltimore20.md.pub-ip.psi.net
63.38.44.161 1Cust161.tnt1.san-francisco3.ca.da.uu.net
209.244.215.139 dialup-209.244.215.139.Washington2.Level3.net
208.5.13.64 cols20851364.cols.net
208.37.59.59 w059.z208037059.lax-ca.dsl.cnc.net
216.230.1.204 ip204.vcu4.richmond.i-c.net
62.158.248.216 p3E9EF8D8.dip.t-dialin.net
63.225.232.20 pppdslj20.slkc.uswest.net
24.131.171.151 el08-24-131-171-151.ce.mediaone.net
208.37.14.250 w250.z208037014.sjc-ca.dsl.cnc.net
38.31.170.115 ip115.salt-lake-city12.ut.pub-ip.psi.net
141.155.104.21 adsl-141-155-104-21.bellatlantic.net
- .edu - - .edu -
141.211.31.173 141-211-31-173.bus.umich.edu
132.194.22.50 nc2608-50.cudenver.edu
35.9.38.30 walther.egr.msu.edu
128.2.179.206 MARYSMACHINE.SPEECH.CS.CMU.EDU
- .com - - .com -
199.174.226.92 user-33qtois.dialup.mindspring.com
199.174.227.69 user-33qtoq5.dialup.mindspring.com
4.54.14.160 PPPa35-ResaleGastonia1-2R7135.saturn.bbn.com
24.93.38.185 cs9338-185.austin.rr.com
204.210.133.137 roc-204-210-133-137.rochester.rr.com
24.93.38.185 338-185.austin.rr.com
63.64.166.69 minnow019.mapletronics.com
209.79.29.29 209-79-29-29.max-tnt-01.simi.ca.us.cnmnetwork.com
207.226.216.177 stpm3-4-177.olg.com
- autres - - autres -
130.240.35.111 xi111.sm.luth.se
130.240.35.94 xi094.sm.luth.se
193.10.62.197 unnamed.kmh.se
193.231.207.101 ppp96.dnttm.ro
193.193.217.132 murka.kot.poltava.ua
Tab. C.10 – suite : Quelques adresses Internet des sites clients dans le monde ayant utilisé
ARITI
xi
ANNEXES
xii
D. DES ROBOTS REELS SUR INTERNET
D Les différents systèmes utilisant Internet comme

moyen de contrôle
Nous présentons ici une liste des différents systèmes utilisant Internet comme moyen
de contrôle. Cette liste est hébergée par la NASA à l’adresse :
http : //ranier.oact.hq.nasa.gov/teleroboticsp age/realrobots.html
ARITI- Augmented Reality Interface for Telerobotic applications via In-

ternet - control a 4-DOF robot using a remote computer
Australian Telerobot - remotely operate a 6-DOF ASEA manipulator located at
the University of Western Australia. Believed to be the first remotely operated industrial
robot on the Web !
Bradford Robotic Telescope - robotic operation of an automated telescope
CSC Telerobot - remotely operate a 6-DOF manipulator located at the Carnegie
Science Center in Pittsburgh.
Drinking Maiden Exhibition - telerobotic examination of The Drinking Maiden
by Ernst Wenck
Eyebot Project - control a manipulator holding a webcam - and read about their
great no-budget implementation !
iNTERFACE - (formerly known as Doppleganger) an attempt to create a telerobotic
machine that is controllable through the web which will eventually be displayed in an art
context
Interactive Model Railroad - remote operation of a real train set in Germany ! Is
it a robot ? It depends on your definition...
Interfacing Reality - remotely fly a robotic blimp (currently offline)
Jason - use a web-connected mobile robot to solve an online mystery. Part of the
Jason Project
Khep On The Web - a Khepera robot controlled from your web browser, with
streaming video
Legal Tender - a telerobotic laboratory to investigate counterfeit currency
Meachanical Gaze - allows multiple remote users to actively control up to six degrees
of freedom (DOF) of a robot arm with an attached camera to explore a collection of
physical museum exhibits
Mercury project - robotic tele-excavation of ”Southwest Nevada” over the Internet
(currently inactive, but the historical logs are great !)
Net-Robot - a net-controllable manipulator in Germany, which you can watch solve
the Towers-Of-Hanoi problem
xiii
ANNEXES
PumaPaint - use a Puma robot to paint with brushes, paint and easel - create real
art !
Rhino - let your robotic tourguide show you the Deutsches Museum Bonn (only
active for short periods)
Robotic Garden - robotic plant tending and maintenance over the Internet. If you
water the robot, will it grow up to be a big robot ?
RoboToy - control a 5-DOF manipulator at the University of Wollongong to pick up
pieces of Australian styrofoam ! In a very neat twist, you can control either the real robot,
or a JAVA simulation !
Schoolnet - Robotics Centre WebCam with web-driven remote pan and tilt poin-
ting
UC Santa Barbara Remotely Operated Telescope - the Remote Access As-
tronomy Project invites you to access their Remotely Operated Telescope and submit
requests
University of Ballarat Telerobot - internet operation of a robot manipulator
V-Car - remotely drive R/C cars via the web, with a very interesting interface
Xavier - an Internet-guided mobile robot currently wandering around Carnegie Mel-
lon University
xiv
Résumé :
La téléprésence, ou la présence virtuelle, devient de plus en plus courante grâce à l’évolution
technologique, impliquant une ouverture du potentiel du télétravail. Ce dernier est fortement lié
à la virtualité et à la téléprésence, donc aussi à la robotique et à l’informatique, autant qu’aux
communications. Cette thèse étudie les méthodes et les outils nécessaires à la réalisation d’un
système de télétravail via Internet.
Dans un premier temps, nous présentons les tendances technologiques qui ont contribué à
l’évolution du télétravail. Ensuite, nous nous intéressons à la téléopération et la télérobotique,
nous verrons comment les techniques de la réalité virtuelle et augmentée ont contribué à per-
cer certains verrous, liés généralement à la distance qui sépare les deux sites maı̂tre et esclave.
Dans un deuxième temps, nous nous intéressons à l’assistance au télétravail via Internet. Nous
étudions les méthodes et les outils nécessaires à la réalisation des guides virtuels portables et
paramétrables en proposant ainsi le formalisme implanté.
Dans un troisième temps, nous étudions les méthodes utiles pour un contrôle en réalité aug-
mentée (modélisation d’environnement et calibration de la caméra et du robot). Nous présentons
la méthode retenue pour le télétravail via Internet. Ensuite, nous présentons notre système
expérimental de télétravail baptisé ARITI (Augmented Reality Interface for Telerobotic appli-
cations via Internet). Dans un quatrième temps, nous présentons deux applications, une pour la
télémanipulation et l’autre, pour la téléopération d’un robot mobile.
Enfin, dans un cinquième temps, Nous évaluons quelques tâches de téléopération ainsi que les
méthodes de compression d’image vidéo utilisées. Nous montrons d’une part, la stabilité du ser-
veur du système ARITI vis à vis des différentes connexions, locale, moyenne et grande distance.
D’autre part, comment le retour prédictif distribué facilite à plusieurs opérateurs de télétravailler
en coopération.
Mots-clé : télétravail, travail coopératif, télérobotique, réalité virtuelle, réalité augmentée, In-
ternet
Abstract :
Telepresence or virtual presence has became more and more commonplace thanks to evolution
of technology which implies an opening to the telework capacities. Telework is essentially linked
to virtuality and telepresence and consequently linked to robotics and computing as well as
communications. This work deals with the methods and the tools necessary to the achievement
of a telework system via Internet.
We have first presented, the technologies which has contributed to the advance of the telework.
We will then focus on teleoperation and telerobotics and we will realize how virtual reality tech-
nologies contribute to cope with some problems due to the distance between the master and the
slave sites. Secondly, our interest will focus on telework assistance via Internet. The methods
and tools necessary to the achievement of transportable and configurable virtual fixtures are
studied and a formalism is proposed.
Thirdly, the useful methods for augmented reality control are studied (environment modeling,
camera an robot calibration), then the selected method for the telework via Internet is pre-
sented. Then, the description of the experimental telework system namely ARITI (Augmented
Reality Interface for Telerobotic applications via Internet) is given. Fourthly, Two applications
are presented, one is about telemanipulation tasks, the other one is about teleoperation of the
mobile robot.
Finally, we will estimate the efficiency of some teleoperation tasks and video images compression
methods. On the one hand, we will see the efficiency of the ARITI system with multiple connec-
tions, locale, medium and high distance. On the other hand, we will see how the distributed
predictive display makes it easy for different operators to work together in cooperative mode.
Keywords : telework, cooperative work, telerobotic, virtual reality, augmented reality, Internet

Otmane00

Transféré par

Droits d'auteur :

Formats disponibles

Otmane00

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Otmane00

Transféré par

Droits d'auteur :

Formats disponibles

Télétravail Robotisé et Réalité Augmentée : Application

à la Téléopération via Internet

To cite this version:

HAL Id: tel-00682240

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

UNIVERSITE D’EVRY-VAL D’ESSONNE

Laboratoire Systèmes Complexes du CEMIF

Télétravail Robotisé et Réalité Augmentée :

M. P. Coiﬀet : Directeur de Recherches au CNRS, Rapporteur

Qu’il me soit permis de remercier ici Messieurs :

Je remercie vivement monsieur Florent CHAVAND, Professeur à l’Université d’Evry

Mes sincères remerciements vont à monsieur Malik MALLEM, Professeur à l’Univer-

Que monsieur Philippe EVEN, Maı̂tre de Conférences à l’Université de Versailles, soit

Mes salutations vont à Etienne COLLE, Hichem MAAREF, Philippe HOPPENOT,

A Frédéric DAVESNE et à tous les thèsards du Laboratoire Systèmes Complexes, pour

Mes reconnaissances vont aux secrétaires Murielle BOURGOIS, Sylviane RAT et au

Science sans conscience n’est

Table des matières

1 Le Télétravail : Etat de l’art 5

2 L’assistance graphique pour le Télétravail 31

3 Le système expérimental de télétravail proposé 63

3.2.2.3 Modèle global de la caméra . . . . . . . . . . . . . . . . 70

4.1.3.1 Tâche d’atteinte de cible . . . . . . . . . . . . . . . . . . 103

5 Evaluation et Expérimentation 123

Table des ﬁgures

Liste des tableaux

L’architecture des futures organisations “virtuelles” reposerait toute entière sur un

La téléprésence, ou la présence virtuelle, qui devient de plus en plus courante grâce à

Le chapitre 4 présente deux applications réalisées, une de télémanipulation et l’autre

personnes handicapées (un projet en collaboration avec l’Association Française contre la

Le chapitre 5 présente les diﬀérentes expérimentations réalisées avec le système ARITI

Souvent considéré comme une conséquence du progrès technique, le télétravail n’est

1.1 Bref historique

Cependant, le télétravail continue à se développer très rapidement en Europe, bien qu’il

Total UE 6 690 4.5 +45

USA3 14 700 12.9 +42

Tab. 1.1 – Développement du télétravail en Europe, 1998-1999. d’aprés (Béréziat et al.,

1.2 Les tendances technologiques pour le télétravail

cune procurer un accès rapide à Internet.

Les progrès techniques considérables dans le domaine de la compression et décompres-

1.2.2 Le travail coopératif

Le “Computer Supported Cooperative Work” (CSCW), traduit en français sous le terme

Les verrous existant sont d’une manière générale à la fois d’ordre :

1.2.3 Les Interfaces Homme-Machine avancées

1.3 Télétravail : Téléopération et Télérobotique

besoin de prolonger le geste de l’homme au delà de la main, et se poursuit par l’ambition

Fig. 1.1 – Illustration de l’architecture générale d’un système de Téléopération

Fig. 1.2 – Exemples de système : A gauche, le système de téléopération du CEA/CEREM ;

1.3.1.1 Le problème de délai de transmission

De nombreuses recherches ont été réalisées pour l’étude et l’analyse du problème de

Dans les systèmes de téléopération originels, l’opérateur doit impérativement subire

1.3.1.2 Evolution des systèmes de téléopération

L’évolution de l’informatique et des supports de télécommunication numérique est à

 La Téléopération à Désignation d’Objectif (supervisée) - TDO

Dans ce mode, l’opérateur est plutôt vu comme un superviseur (Sheridan, 1992).

 La Téléopération Semi autonome - TSA

La plupart des systèmes de téléopération actuels, s’orientent vers l’utilisation des

Pas autonome Semi autonome Complètement autonome

La télérobotique résulte en fait de la fusion des deux domaines originellement séparés

1.3.2.1 Quelques domaines d’application

La Téléopération à Désignation d’Objectif (supervisée) - TDO

La Téléopération Semi autonome - TSA

L’aide aux handicapés

L’armée : Les militaires utilisent la RV pour plusieurs raisons comme : la si-

L’enseignement : L’apprentissage à l’aide des hypermédia entraı̂ne une navigation

La chirurgie : En chirurgie, la tendance est de réduire la taille de l’accès à la

Divertissement : Une forme simple de la RA est utilisée pendant le journal de

Conception, fabrication, entretien et réparation : Quand les techniciens de

Robotique et Télérobotique : Comme nous l’avons mentionné au début de

Electro Technical Laboratory (ETL Japon)

Ergonomics in Teleoperation and Control Laboratory (ETCL Université

Commissariat à l’Energie Atomique de Fontenay aux Roses (CEA, France)

Virtual Tools and Robotics Laboratory (Pennsylvania State University,

Laboratoire de Robotique de Paris (LRP France)

Laboratoire Systèmes Complexes (LSC, France)