Système de pointage par orientation de la tête

De Ensiwiki
Aller à : navigation, rechercher

Expert.png  Troisième Année 

Contexte et objectifs

Contexte

Notre équipe est constituée de trois élèves de MMIS IRVM :

Nous avons mis en place, dans le cadre de notre cours d'interactions post-WIMP (18/19), un système permettant un pointage sur ordinateur par orientation de la tête par rapport à l'écran.

Notre public cible est l'ensemble des programmeurs qui utilisent des interfaces cliquables pour programmer, comme Atom ou Emacs par exemple. Il est possible d'optimiser le temps passé à programmer. Typiquement, la tâche simple de chercher la souris avec sa main pour effectuer un homing et cliquer est potentiellement optimisable.

Pour ce faire, nous utilisons le système Optitrack. Il permet, grâce à des caméras infrarouges (qui envoient et reçoivent de la lumière infrarouge), de repérer des capteurs réfléchissants dans l'espace perçu par plusieurs caméras. Ainsi, en définissant un rigid body (ensemble de 3 capteurs ou plus reliés par un corps rigide, et donc immobiles les uns par rapport aux autres), nous pouvons suivre la position et l'orientation d'un objet dans l'espace, par exemple la tête de l'utilisateur de notre dispositif.

Optitrack Studio.jpg
Optitrack Capteurs.jpg

Objectifs

Nous souhaitons donc mettre en place un système qui permet au programmeur de cliquer sans lever ses mains du clavier. D'un point de vue optimisation du temps de travail, cela lui permet ainsi d'économiser le temps de homing de la main sur la souris à chaque fois qu'il a besoin de cliquer.

Notre défi est de créer un système comparable voire meilleur que le touchpad dans des situations où on ne peut pas programmer avec la souris aisément (dans un train par exemple). Nous ne pensons pas pouvoir faire mieux que la souris (à cause de la différence d'habitude notamment) mais nous avons attendu les résultats pour pouvoir faire la comparaison avec le touchpad.

Nous souhaitons également mettre l'accent sur la latence : étant donné que la souris a une latence très faible, nous souhaitons qu'il en soit de même pour notre système. Une performance moindre que la souris et le touchpad sur ce plan là serait très handicapante pour la prise en main du dispositif, étant donnée l'habitude que l'on a avec les deux autres systèmes.

Solution envisagée

Nous avons donc envisagé une solution qui permet de cliquer grâce à l'orientation de la tête. Grâce à l'Optitrack, et à un système rigide de capteurs positionnés sur le front de l'utilisateur, nous traquons en temps réel la position de sa tête, qui est un bon indicateur d'où se porte son regard.

Il est nécessaire d'effectuer deux passes de calibration : la première permet de détecter où se trouve l'écran grâce à l'Optitrack, et la seconde permet de calibrer la relation entre l'orientation de la tête de l'utilisateur et le lieu où le curseur doit se trouver sur l'écran.

Ensuite, le système que nous avons mis en place comporte deux états. Pour passer de l'un à l'autre, l'utilisateur doit appuyer sur la touche qui permet de remonter en haut d'une page ou d'aller en bas, ce qui lui permet de ne pas avoir à trop bouger la main.

  • Dans le premier état, l'application est passive et laisse l'utilisateur écrire de façon normale dans son éditeur de texte.
  • Dans le second état, elle est active et le curseur se déplace selon l'orientation de la tête de l'utilisateur, qui peut cliquer en utilisant la touche Alt. Cela lui permet de ne pas avoir à utiliser la souris pour cliquer, et le homing est, au premier abord, plus efficace que celui de la souris, car l'utilisateur garde ses mains sur le clavier (dans un endroit facile à trouver : juste à la gauche de la barre d'espace).

La touche choisie pour cliquer est importante, car il est nécessaire que d'une part, l'utilisateur sache où elle se trouve sans avoir à baisser la tête sur le clavier, ce qui rendrait nul le pointage, et d'autre part, aucune touche importante pour la tâche de rédaction ne soit utilisée. En effet, lorsqu'on prend la souris pour cliquer, c'est souvent pour corriger la mise en forme, ou copier et coller quelque chose. Il est donc nécessaire de ne pas utiliser la touche entrée ou espace par exemple, même si ce sont les deux touches dont la localisation est plus évidente. De même, un raccourci comme Ctrl+C ou Ctrl+V ne serait pas un bon choix, car l'utilisateur aurait à sortir du mode de pointage pour effectuer un copier-coller, ce qui lui ferait perdre du temps.

Problèmes et solutions

Programmation sous Windows

Problème

Les projets C++ sous Windows sont assez difficiles à importer depuis Linux lorsqu'on ne les a pas débutées sous Windows. En effet, le principal environnement de développement utilisable en C++ sous Windows est Visual Studio, qui n'autorise pas l'import de projets non créés par lui. De plus, il ne détectait pas les librairies de base du type librairie mathématique, ce qui nous empêchait de compiler le projet et donc de commencer les tests.

Solution

Pour pallier à ce problème, nous sommes passés sous CLion, et avons créé un CMakeLists nous mêmes. Ainsi, nous avons pu compiler le projet car les librairies de base étaient accessibles depuis CLion. Etant donné que le seul compilateur disponible était celui de Visual Studio, nous n'avons en revanche pas été en mesure d'avoir un débugger, ce qui a posé problème.

Socket UDP

Problème

Un des principaux problèmes auxquels nous avons été confrontés a été la manipulation d'une socket UDP pour la réception des informations envoyées par l'Optitrack et nécessaires à l'acquisition de la position voulue du curseur sur l'écran.

Plus précisément, la calibration a posé un problème. En effet, lors de celle-ci, l'utilisateur doit placer un capteur sur un coin de l'écran, appuyer sur une touche, puis déplacer le capteur sur un autre coin et appuyer à nouveau, et ce jusqu'à avoir acquis les quatre coins. Pendant le temps de pause en attendant l'appui sur une touche, la socket stockait dans son buffer toutes les données entrantes. Ainsi, en appuyant sur la touche, nous récupérions non pas la donnée en temps réelle que nous souhaitions avoir, mais celle qui avait été acquise juste après le dernier appui sur une touche.

Solution

Nous avons réussi à pallier à ce problème en ne mettant plus le système en pause mais en ne prélevant que la donnée dans le buffer au moment où on appuyait sur la touche, en jetant les autres au fur et à mesure de l'acquisition de nouvelles données. Ainsi, nous avons les données en temps réel et pouvons calibrer correctement l'écran.

Calibration de l'écran

Problème

Nous utilisions, pour calibrer l'écran, une fonction de la librairie gmtl qui permet de projeter un point sur un plan pour projeter le quatrième point capturé sur le plan des trois autres et avoir un rectangle compris dans un plan. Cette fonction trouvait la projection non pas sur le point le plus proche du plan par rapport au point donné, mais quelque part beaucoup plus loin, ce qui nous donnait un écran aberrant et empêchait de faire la calibration correctement.

Solution

Nous avons cessé de prendre en compte le quatrième point (qui était plus une confirmation qu'une information nécessaire), et l'avons déduit des trois autres.

Librairie gmtl

Problème

Nous avions besoin de quaternions pour traquer le rigid body placé sur la tête de l'utilisateur. Nous avons donc utilisé la bibliothèque gmtl, qui permet de manipuler des objets mathématiques tels que les points et les quaternions. Pourtant, beaucoup de fonctions de cette bibliothèque n'ont pas fonctionné de la manière qui était décrite dans la documentation.

Solution

Nous sommes donc passés par d'autres fonctions (qui manipulaient des matrices et non directement des angles) pour contourner ce problème.

Précision de la calibration

Problème

SetupOptitrack1.png
SetupOptitrack.png

Malgré le nombre et la répartition des samples lors de la calibration de l'Optitrack, ainsi que la précision "exceptionnelle" vantée par Motive, nous avons constaté lors de nos premiers tests des sauts du curseur qui entrainaient un manque de précision du pointage. De plus, ces sauts et les mouvements naturels de la tête, qui ne peut pas rester totalement immobile pendant l'acquisition, entraînent des sélections non voulues de quelques lettres ou d'une ligne entière lors des clics, ce qui n'est pas acceptable étant donné que le rôle premier du système est de pouvoir cliquer.

Solution

Nous avons dans un premier temps pensé que mettre une certaine résistance pourrait aider à la stabilité (par exemple, au lieu du lieu du curseur à une frame donnée, il serait intéressant de prendre la moyenne des frames précédentes, étant donné qu'un système résistif serait compliqué à mettre en place pour les mouvements de la tête et entraîneraient très probablement une fatigue supplémentaire non négligeable).

Nous avons ensuite décidé de changer la disposition des caméras pour faire en sorte que toutes puissent voir le rigid body lorsque la tête est dans son axe de repos. En effet, avant cela, deux caméras étaient situées derrière l'utilisateur et ne voyaient pas le rigid body, à cause de l'occlusion de la tête. Nous avons donc placé ces caméras de part et d'autre de l'utilisateur.

Il y a donc beaucoup moins de sauts, mais ils augmentent fortement à partir d'une certaine inclinaison de la tête vers le bas.

Nous avons finalement décidé d'ajouter également deux caméras, ce qui a drastiquement réduit la hauteur et le nombre des sauts. Ceux qui restent sont dus en grande partie aux mouvements naturels de la tête.

Mouvements induits par la pédale

Problème

Nous avions dans un premier temps utilisé la pédale pour cliquer (elle est composée de trois pédales, que nous avions liées chacune à un clic de la souris).

Lors de l'appui sur la pédale, le mouvement de la jambe induit un léger mouvement de la tête, et donc du curseur. Il n'était donc pas facile de cliquer sans sélectionner.

Solution

Nous avons mis en place deux solutions à ce problème :

  • Nous avons lié une touche du clavier, la touche Alt qui est peu utilisée pendant un exercice de programmation mais se trouve à un endroit très reconnaissable du clavier (à gauche de la barre espace), au clic. L'utilisateur peut donc cliquer en évitant le mouvement parasite dû à l'appui avec le pied sur la pédale.
  • Nous avons fait en sorte que lors d'un clic, le curseur reste immobile durant 0.2 secondes, ce qui évite une partie des sélections non voulues.

Résistance à la lumière du soleil

Problème

Nous avons majoritairement fait nos expériences dans une pièce dont les rideaux étaient clos et avec un temps couvert. Cependant lors des derniers tests, le soleil passait par une fenêtre du fablab que nous ne pouvions pas couvrir. La lumière du soleil étant forte, et chargée en infrarouges, les caméras on reconnu les taches de lumière comme des capteurs, ce qui a faussé la réception et créé des interférences que l'on a ressenti sous la forme de sautillements du curseur. Même lorsqu'on masquait les taches de lumière, l'amélioration ne durait qu'un temps à cause du mouvement du soleil et donc des taches de lumière.

Solution

Il n'y a pas à ce jour d'autre solution contre ces problèmes que d'utiliser notre système que dans une pièce où le soleil ne donne pas. Pour une utilisation de la vie réelle, il serait très intéressant de trouver un système de trackage alternatif ne comptant pas sur le fait qu'il soit le seul à émettre de la lumière infrarouge.

Réalisation

Ce qui a été fait jusqu'ici

Mise en place de l'Optitrack

Nous avons mis en place l'Optitrack de la manière suivante :

  • Nous avons installé quatre, puis six, caméras autour de l'utilisateur. C'est un nombre plutôt bas, mais il suffit, avec un bon calibrage, à avoir la position et la rotation de l'unique rigid body que nous souhaitions suivre.
  • Nous avons ensuite calibré l'Optitrack grâce à une wand de calibrage de manière à avoir des samples assez nombreux et divers pour couvrir l'entièreté de l'espace et avoir la meilleure précision possible. Ainsi, à chaque calibration, nous avons une précision en position d'environ 0.2 mm.
  • Nous avons enfin envoyé grâce au logiciel Motive les données depuis l'Optitrack jusqu'à la socket UDP.

Réception des données

La réception des données est faite grâce à une socket UDP, qui permet de transmettre les données envoyées par l'Optitrack à l'ordinateur où le curseur doit être manipulé.

Nous avons à cet effet repris un code qui nous a été donné par notre encadrant François Bérard, et qui permet d'afficher en continu les informations reçues via la socket. Nous l'avons adapté pour pouvoir récupérer les informations lorsque nous le souhaitions sans forcément les afficher. Nous avons également fait en sorte de pouvoir choisir quels étaient les éléments sur lesquels on voulait recevoir des informations. Typiquement, pour la marche normale du dispositif, on veut recevoir des informations sur l'unique rigid body qui sera celui associé à la tête de l'utilisateur.

Calibration du système

Nous avons mis en place deux calibrations.

  • La première permet de déduire la position (et la taille) de l'écran à partir de ses quatre coins. On déduit dans un premier temps un plan des trois premiers points, puis on calcule les vecteurs directeurs de ce plan grâce à eux (vecteurs horizontal et vertical). Elle est effectuée en repérant un à un les coins de l'écran grâce à un unique réflecteur.
  • La seconde permet d'avoir la position initiale de l'utilisateur par rapport à l'écran, et d'en déduire la façon dont le curseur va bouger en fonction de l'orientation de la tête de l'utilisateur. Elle est effectuée en demandant à l'utilisateur de se positionner de manière naturelle et confortable face à l'écran en le regardant, et en prenant les données du rigid body associé à sa tête comme référence.

Changement d'état du système

L'idée est d'attribuer deux états possibles au système : un état de base, où il n'agit pas, et un état de pointage, où l'utilisateur peut déplacer le curseur grâce à l'orientation de sa tête. Le changement d'état se fait grâce à l'appui d'une touche sur le clavier.

Calcul de la position du pointeur

A partir de la position et l'orientation relatives de la tête de l'utilisateur par rapport au plan de l'écran, nous cherchons à déduire la position du curseur. Ceci se fait en calculant l'intersection entre la normale à la tête de l'utilisateur et le plan de l'écran. Si le curseur est en dehors des limites de l'écran, nous le plaçons au point le plus proche à l'intérieur de l'écran.

Expérience de Fitz

Nous avons voulu évaluer de manière objective notre dispositif. Pour cela nous avons mis en place un expérience de Fitz. Nous avons utilisé une implémentation opensource développée par Jacob O. Wobbrock, Susumu Harada, Edward Cutrell et I. Scott MacKenzie, touvable ici. Le logiciel nous permet de connaitre notre indice de performance ainsi que d'avoir les trajectoires effectives de nos participants.

Fitz experience.jpg

Evaluation de l'interaction créée

L'évaluation se fait en deux parties.

La première consiste à faire manipuler la session, en utilisant le système de pointage, et ceci plusieurs fois pour pouvoir mesurer son aisance, son apprentissage et recueillir ses retours. Cela permet également au sujet de s'habituer au système.

L'autre consiste en un test de Fitz, qui permet de déterminer les performances du pointage par orientation de la tête, selon la taille de la cible et la distance au point de départ. Elle nous permet de comparer l'efficacité du pointage par l'orientation de la tête à celle du pointage avec la souris ou le touchpad, par exemple.

Nous souhaitons interroger l'utilisateur sur les critères suivants :

  • La facilité avec laquelle il estime avoir utilisé le système,
  • Son ressenti au niveau de la précision, en comparaison à ce qu'il fait avec une souris,
  • Son ressenti au niveau de la rapidité et de la latence, en comparaison à ce qu'il fait avec la souris,
  • Son ressenti au niveau de son champ de vision,
  • La fatigue qu'il a ressentie au cours de l'exercice, et après celui-ci,
  • Son confort pendant l'exercice.

Evaluations préliminaires

Nous avons nous-même testé le système dans un premier temps pour en voir les faiblesses les plus évidentes et tenter de les corriger avant de le faire tester à des utilisateurs extérieurs à notre groupe. Nous avions alors 4 caméras et nous n'avions pas le système de stabilisation lors du clic. Nous avons obtenu le résultat suivant :

Tigru.png

On peut observer deux choses principales :

  • Pour des tâches grossières, comme créer une forme (donc acquisition de deux points pour deux coins du rectangle englobant la forme), le système est assez efficace.
  • Pour des tâches plus précises, comme un tracé à "tête levée", on continue à constater des sauts : les lignes ne sont pas régulières.

Evaluations grâce à des sujets

Nous avons fait tester notre dispositif à 6 sujets (et nous, mais on ne s'inclut pas dans les résultats étant donné que nous sommes d'une part plus habitués au système et d'autre part trop impliqués pour être objectifs).

Point de vue utilisateur

Nous avons obtenu des retours divers en leur demandant leur ressenti sur les différentes questions que nous avions :

  • Aisance : tous ont trouvé le système assez facile à utiliser, grâce à la ressemblance entre pointer son regard quelque part et pointer le curseur. Cependant, un sujet nous a dit que bien que cette ressemblance soit vraie lorsqu'on regarde le centre de l'écran, la correspondance s'estompe à mesure qu'on porte son regard sur les côtés de l'écran. Cela l'a légèrement perturbé. Un autre sujet a dit que le découplage mouvement/clic l'avait perturbé, et c'est d'ailleurs une remarque que l'on a lorsqu'on parle du projet à des personnes extérieures : elles s'attendent à cliquer en clignant des yeux.

Vis à vis de la correspondance qui n'est pas parfaite, nous pourrions retoucher nos formules pour atténuer la différence perçue.

Vis à vis du découplage, nous pourrions réfléchir à un système alternatif pour cliquer.

  • Précision : une majorité des sujets ont trouvé la précision insuffisante pour acquérir des cibles petites. C'est en partie dû aux tremblements de la tête, et lorsqu'il y avait encore quatre caméras seulement, à l'occlusion que fait la tête au rigid body, qui faisait que le système recevait des données de moins de caméras. Un des sujets nous a dit qu'il trouvait plus pertinent de faire des tâches moins précises comme le scroll grâce à la tête.

Pour améliorer notre précision, nous pourrions :

    • Mettre en place un amortissement qui compenserait les tressautements dus aux mouvements de la tête et aux imprécisions du système en prenant la moyenne des précédentes positions à chaque instant.
    • Ajouter une fenêtre qui, au bout de quelques instants (0.2 secondes par exemple) de quasi-stabilité du curseur, ouvrirait une vue zoomée pour pouvoir faire l'acquisition sur une plus grosse cible.
    • Ajouter plus de caméras, qui tendent à chaque fois à réduire les tressautements dus à l'occlusion.
  • Latence : nous n'avons eu que des retours positifs au niveau de la latence, qui est selon les sujets comparable à celle de la souris ou du touchpad.
  • Champ de vision : étonnamment, nous n'avons pas eu de réflexions négatives par rapport au champ de vision. Certains sujets inclinaient la tête pour pointer, mais n'ont pas pu expliquer pourquoi ils avaient ce réflexe.
  • Fatigue : Les sujets ont reporté que le système ne les avait pas fatigués à cause de la rotation de la tête. Cependant, lorsqu'ils utilisaient la pédale, ils ont reporté de la fatigue au niveau du pied, surtout chez ceux qui n'avaient pas l'habitude de conduire. En effet, il n'y a pas de résistance dans la pédale, ce qui fait qu'on clique dès qu'on repose son pied.

Nous pensons qu'il faut garder la solution de la touche pour cliquer, car elle parait plus satisfaisante pour l'utilisateur et plus précise (n'induisant pas de mouvement parasite de la tête).

  • Confort : Un utilisateur nous a dit qu'il trouvait le pointage par la tête plus confortable que celui avec la souris. Les réponses ont globalement été très positives sur le confort.

Statistiquement

Dans cette partie nous faisons une comparaison entre la souris et notre dispositif d'un point de vu de l'expérience de Fitz. La figure de gauche correspond à notre matériel et à droite la souris.

Div traj.JPG Traj souris.JPG

Nous observons que les trajectoires sont beaucoup plus directes à la souris qu'avec la tête. Nous notons également beaucoup de dépassement de cibles (overshooting).

Div curves.JPG Souris curves.JPG

Nous pouvons voir sur les courbes ci-dessus les deux points cités précédemment, notamment l'overshooting, avec le changement soudain de vitesse. On observe également d'avantage d'instabilités à la tête qu'on peut lire sur la courbe Jerk.

Lors de notre expérience de Fitz, qui permet l'anticipation, la souris a un indice de performance de 10bit/s (contre 4-5 bits/s dans une expérience classique). Nous avons mesuré également le trackpad qui est en moyenne à 5.2 bits/s. Notre dispositif quant à lui, a un indice de 3.22 bit/s en moyenne. Notre interaction est donc moins efficace que la souris et le trackpad.

Conclusion

Malgré les difficultés de réalisation, nous sommes satisfaits du système que nous avons réussi à créer.

Nous pourrions donc l'améliorer sous différents axes, dont les deux principaux sont :

  • Amélioration de la stabilité du curseur
  • Mise en place de solutions pour une meilleure précision
  • Ajout d'une résistance à la lumière du soleil.

Il serait également intéressant de tester un mouvement du curseur relatif et non absolu, et de comparer les résultats.

Ce projet nous a énormément intéressés, et ce sous plusieurs angles. D'un point de vue technique, créer un nouveau système d’interactions est très instructif. C'est également très gratifiant, car ce projet nous permet d'avoir une expérience, plutôt réussie, à notre actif. Nous sommes également passés par quasiment toutes les phases de la création d'une nouvelle interaction, à partir d'un système qui n'est pas fait pour elle au départ et d'une idée de besoin. C'est très formateur.

Nous souhaitons remercier notre encadrant, François Bérard, et les personnes qui ont bien voulu tester notre interaction, pour l'aide qu'ils nous ont apporté pour la réalisation de ce projet.