Formation sportive en réalité virtuelle (Post-WIMP 16/17)

De Ensiwiki
Aller à : navigation, rechercher

Introduction

Équipe de projet

  • Bayart Jérémie
  • Biehler Mathias
  • Desgardin Samir
  • Fournier Hugo
  • Marçon Gautier

Contexte

Aujourd'hui, les méthodes d'entrainement sportif classiques visant à répéter des mouvements considérés comme idéaux sont souvent coûteuses en ressources humaines mais également en temps. En effet, il est délicat de se former seul et le regard externe d'un coach connaissant les mouvements parfaits se fait souvent ressentir.

C'est en partant de ce constat et du fait que les moyens d'apprentissage actuels ne permettaient pas d'outrepasser ces contraintes que nous avons envisagé une solution permettant de se former de manière autonome, la plus efficace possible, et qui soit accessible depuis chez soi.

Matériel utilisé

Pour répondre à cette problématique, il était tout d'abord important de pouvoir détecter de manière aussi précise que possible les mouvements d'un individu afin de pouvoir quantifier l'exactitude de ses mouvements par rapport au geste qu'il souhaite réaliser.

Pour cela, nous avons utilisé la Kinect for Windows en version 1.8.

Concernant le rendu en environnement virtuel, nous avons utilisé l'Oculus Rift DK2 en version 1.3.

Nous reviendrons plus en détail sur leur utilisation par la suite.

Description de la solution envisagée

La solution retenue afin de répondre au mieux à ce besoin s'articulait initialement autour de plusieurs axes mentionnés ci-après. Tout d'abord, il semblait important dans un objectif d'immersion la plus complète possible d'obtenir un système performant permettant un rendu en temps réel sans ralentissement ni latence. D'autre part, afin d'observer de la meilleure des façons les gestes idéaux à reproduire pour l'utilisateur, la possibilité d'ajouter à la volée des miroirs, ou encore d'utiliser différents points de vue comme une vue à la troisième ou à la première personne paraissait intéressante. Concernant le modèle à suivre, il était prévu d'indiquer à l'utilisateur et en temps réel, des trajectoires à suivre dans l'environnement virtuel afin de parfaire ses mouvements.

Enfin, afin de quantifier le caractère idéal du geste en fonction du modèle, nous souhaitions implémenter un système de métriques permettant notamment à l'utilisateur d'observer ses progrès dans le temps.

La plupart des solutions envisagées ont pu être réalisées dans le cadre de ce projet. Néanmoins, certaines n'ont finalement pas été retenues comme étant les plus efficaces, et des alternatives permettant à l'utilisateur d'obtenir des résultats à priori meilleurs ont été mises en place, en particulier dans la représentation qui était faite du mouvement idéal.

Nous reviendrons plus en détail sur chacun de ces points dans la prochaine partie.

Etat des lieux de ce qui a été réalisé

Généralités

Nous avons choisi d'utiliser Unity pour interfacer ensemble toutes les composantes du projet de manière efficace.

Le principe de l'application se décompose en plusieurs étapes majeures :

- Acquisition du mouvement

- Reproduction du mouvement dans l'environnement virtuel

- Interaction avec l'environnement : choix du geste ou de l'environnement

- Observation du caractère idéal du geste

Nous décrivons donc dans cette partie l'ensemble du processus.

Capture des mouvements

Wimp skeleton.jpg

Le première étape consiste donc à acquérir une représentation de l'individu aussi précise que possible grâce à la Kinect qui enregistre à une fréquence de 30Hz. Elle nous permet d'obtenir un squelette simplifié de l'utilisateur qui servira à l'animation d'un modèle 3D permettant de visualiser les mouvements effectués.

Le squelette est composé d'une vingtaine de points répartis aux endroits clés du squelette comme les extrémités et les articulations. L'image ci-contre correspond à la représentation 3D d'un modèle tel qu'il est enregistré par la Kinect.

C'est précisément ce modèle qui servira de base à la représentation de l'individu dans l'environnement virtuel.

Visualisation

Kinect perso.png

Afin d'obtenir une immersion aussi poussée que possible, les squelettes 3D sont ensuite mappés sur des modèles humains réalistes comportant les mêmes hiérarchies d'articulations. L'image ci-contre représente l'un de ces modèles en mouvement, permettant de ne pas travailler directement avec des squelettes dans l'environnement virtuel.


Contrairement à la solution initialement proposée d'obtenir un rendu à la première personne et où les indications du geste idéal seraient directement affichées sous forme de flèches ou trajectoires, nous nous sommes orientés vers le fait de pouvoir choisir entre un mode à la première personne et un autre à la troisième personne. . A cela, nous avons décidé d'ajouter un miroir permettant à l'utilisateur de voir exactement ses mouvements en face de lui dans le cas d'une vue à la première personne, ou derrière le personnage afin de voir les mouvements de dos dans l'autre cas. Nous avons de plus choisi d'afficher un modèle effectuant le mouvement idéal à côté de notre propre modèle, visible en vue directe ou à travers le miroir selon la vue choisie, et permettant de reproduire plus naturellement les mouvements observés.

L'environnement de la scène, et en particulier les miroirs, peuvent être désactivés de manière directe, et une rotation des personnages est également possible afin d'observer la scène sous un autre angle. Le problème de l'inversion gauche-droite observée sera traitée de manière objective dans l'évaluation de notre interaction.


Les images ci-après montrent quelques exemples de possibilités d'environnement en fonction des choix de l'utilisateur :


Wimp env1.png Wimp env2.png Wimp env4.png


Des scripts C# se chargent de lier des touches du clavier à des actions spécifiques telles que :

- M : Ajouter/Supprimer un miroir derrière le personnage

- E : Ajouter/Supprimer l’environnement (terrain, arbres…)

- R : Permet la rotation des modèles avec les touches directionnelles


Néanmoins, ces représentations posaient un problème de subjectivité dans la façon de quantifier l'écart entre les mouvements de l'utilisateur et ceux du modèle. C'est précisément la raison pour laquelle nous avons implémenté une fonction de scoring permettant de mesurer cet écart.

C'est ce que nous verrons dans la prochaine partie.

L'entraînement

La phase d'entraînement permet donc à l'individu de se comparer au modèle à l'aide de métriques objectives dont nous définissons le sens.

On s'intéresse à la reproduction du mouvement dans le bon timing et de la manière la plus précise possible. Pour cela on compare pour chacun des deux modèles, la distance entre chacun des vingt-deux points et le centre des modèles. On obtient donc un score représentatif de l'erreur qui correspond à la distance entre le mouvement idéal et le mouvement réalisé. De fait, le score affiché correspondant au score instantané et est nul si le mouvement est parfaitement réalisé. Il augmente lorsque celui-ci n'est pas bien exécuté.

Le score se situe dans notre cas dans la partie supérieure gauche de l'écran et permet un retour en continu et en temps réel pour l'utilisateur. Nous avons également fait en sorte de pouvoir obtenir une moyenne de ces scores instantanés sur une période donnée, afin d'obtenir une idée globale de la précision d'un ensemble de mouvements.

Descriptions des problèmes rencontrés

Lors de ce projet, nous avons été confrontés à certains problèmes techniques. Certains sont relativement simples à corriger, mais nécessitent du matériel supplémentaire. Pour d'autres il a fallu contourner le problème sans pouvoir, pour l'heure, apporter une solution directe.

Avant même de nous lancer dans le projet, nous avons été confrontés à différents soucis. Nous avons voulus tester les deux principaux outils de notre dispositif (Kinect et Oculus) et il s'est avéré que l'Oculus n'était pas compatible avec les ordinateurs portables, ce qui pose un souci sur un projet qui se déroule au Fablab et où le nombre de machines est limité. Il a également rendu impossible le travail personnel hors de l'école.

Une fois le projet commencé, nous avons encore fait face à un certain nombre de soucis mentionnés ci-après.

Proposition de branchement pour notre dispositif


Un problème s'est présenté avec l'Oculus Rift DK2. En effet celui ci est branché à l'ordinateur et le câble gêne la détection quand il passe entre l'utilisateur et la caméra. Une solution relativement simple pour palier à ce soucis est de brancher l'oculus à l’opposé de la Kinect. Ce que nous n'avons pas encore pu mettre en place faute de câbles suffisamment longs, mais en cas de développement d'une réelle version cela ne serait pas un problème.

Ceci nous amène à un second problème qui serait réglé de la même façon. Actuellement le fait de porter l'Oculus empêche de faire des mouvements trop amples sans prendre le risque de de s'emmêler dans les câbles voire de le débrancher.



Problèmes du câble et de la vitesse du mouvement pour la Kinect

Nous avons été confrontés à une dernière série de problèmes plus compliqués à régler :

- La Kinect a du mal à suivre les mouvements trop rapides malgré sa fréquence d'acquisition de 30Hz. Pour contourner ce problème nous nous sommes pour l'instant concentrés sur des mouvements lents. Cela n'est pas problématique dans la mesure où le but de notre prototype est surtout de valider les différentes vues et option (Avatar inversé ou non, avec ou sans miroir). Une fois notre prototype validé pour des mouvements simples et son utilité prouvée nous pourrons réfléchir aux meilleurs outils à utiliser pour améliorer l'acquisition et la précision.

- La Kinect a aussi du mal avec la détection de personnes de profil, la solution est dans ce cas de travailler sur des mouvements principalement de face et limitant les rotations par rapport à l'axe vertical.


Évaluation de l’interaction créée

Comme vu précédemment, notre projet souhaite donner la possibilité de reproduire un ou plusieurs mouvements, dans le but de pouvoir les assimiler et les reproduire facilement. Pour cela, il propose un système utilisant Kinect pour capturer les mouvements de l’utilisateur, et donne un retour sur l’action effectuée par l’utilisateur pour que celui-ci comprenne les défauts de son mouvement et se perfectionne. Ainsi, notre système affiche un avatar modèle et un avatar représentant l’utilisateur dans la scène. Plusieurs modes sont possibles pour l’affichage de ces avatars : on peut voir les avatars de face (la main droite de l’utilisateur lève la main droite de l’avatar, mais celle-ci est à gauche dans la scène car l’avatar se présente de face) ou on peut voir les avatars inversés, à la manière des miroirs (la main droite se lève à droite). Par ailleurs, notre système permet l’ajout d’un miroir derrière les avatars pour mieux percevoir les mouvements effectués. Notre étude s’est focalisée sur la facilité qu’ont les utilisateurs à reproduire un mouvement en fonction de ces différents modes.


Procédure

Comme expliqué précédemment, nous avons mis en place un système de score. Ce score n’est pas forcément le plus pertinent, puisqu’il est très sensible à la synchronisation des deux squelettes. Cependant, il permet d’avoir un indicateur basique constituant une mesure objective de la qualité de la reproduction du mouvement. A partir de ce score instantané, nous avons calculé le score moyen sur une séquence de mouvements. C’est ce score moyen qui a servi d’outil de comparaison pour déterminer le mode le plus performant pour notre système.


Résultats

Pour éviter tout biais éventuel, nous avons effectué les évaluations en suivant une procédure within-subject. Nous avons d’abord comparé l’affichage des avatars non retournés face aux avatars retournés. Pour chaque configuration, les participants ont eu deux essais pour réaliser le mouvement demandé. Nous avons obtenu les résultats suivants :

Score moyen Essais Samir Jérémie Hugo Gautier Mathias
Avatars non inversés Essai 1 3.86 4.18 3.72 3.98 4.32
Essai 2 3.64 4.02 3.02 3.21 3.87
Avatars inversés Essai 1 4.52 4.98 4.95 4.49 5.55
Essai 2 4.20 4.59 4.25 4.12 4.95

Comme le score représente une distance, plus le score est petit, mieux le sujet a reproduit le mouvement. On remarque une tendance pour les sujets à mieux réussir avec les avatars non inversés, où la main droite du sujet lève la main droite de l’avatar. Un avatar inversé demande une gymnastique intellectuelle pour se représenter quel membre bouger. D'autre part, on remarque qu'il y a un apprentissage conséquent entre le premier et le deuxième essai, dans les deux configurations.

Nous avons ensuite comparé les performances avec et sans miroir derrière les avatars, avec les avatars non inversés.

Score moyen Samir Jérémie Hugo Gautier Mathias
Avec miroir 3.64 4.02 3.02 3.21 3.87
Sans miroir 3.28 4.25 3.25 3.60 3.45

Le miroir ne semble rien apporter dans l’interaction à la troisième personne.


Voies d'améliorations

Dans l'ensemble, la plupart des objectifs ont été tenus. Néanmoins, quelques fonctionnalités supplémentaires auraient permis de rendre l'interaction plus complète.

En effet, les animations du modèle à suivre ont été importées à partir de mouvement prédéfinis au format de fichier fbx car nous avons été confrontés au problème de rejouer un mouvement enregistré par l'utilisateur. Enregistrer des mouvements à la volée et les faire rejouer par le modèle directement depuis l'interface de l'application aurait été un réel plus pour l'utilisateur. Ce point constitue la principale voir d'amélioration de notre projet.

De plus, dans le cas d'un mouvement à la première personne, des indicateurs de mouvement à suivre en temps réel auraient également constitué un plus dans l'expérience utilisateur.

Les autres améliorations possibles ont été abordées dans la partie concernant les problèmes rencontrés et ne sont pas du fait de l'interaction elle-même mais plutôt de limitations techniques, en rapport avec le matériel que nous avons choisi d'utiliser. Elles constituent donc également des pistes d'amélioration possibles mais ne seront pas plus détaillées ici car non évitables avec ces technologies.

Conclusion

La plupart des objectifs que nous nous étions fixés ont été remplis, malgré les quelques divergences par rapport à l'idée originelle. En effet, au fur et à mesure du développement, certaines alternatives concernant l'interaction nous paraissaient plus pertinentes que celles initialement proposées. Nous avons également été confrontés à des limitations techniques, en particulier celles liées à la Kinect.

Néanmoins, nous avons pu observer les effets de l'apprentissage sur notre interaction. Grâce aux métriques, il a également été possible de mesurer les performances de l'utilisateur en fonction des paramètres de l'interaction.

Nous avons donc ainsi pu constater les limites de notre interaction et envisager un certain nombre de pistes d'amélioration.