RV01 Réalité Augmentée pour la conduite avec un Heads Up Display. Karim LAMOURI & Caimin XIE

Transcription

1 RV01 Réalité Augmentée pour la conduite avec un Heads Up Display Karim LAMOURI & Caimin XIE 9 janvier 2015

2 Table des matières 1 Contexte 2 2 Objectifs Objectifs initiaux Objectifs finaux fixés lors de la dernière revue de projet Réalisation Architecture de l application Mise en place du système Aide au stationnement Vision nocturne Détecteur d angles morts Aide anti-collision Affichage d informations textuelles avec géolocalisation Menu Bilan général Difficultés Résultats par rapport à l objectif Retours utilisateurs Conclusion

3 1 Contexte L UV RV01 est une matière enseignée à l UTC qui introduit les bases théoriques et techniques de la réalité virtuelle. Les étudiants assistant à ce cours doivent réaliser un projet pédagogique. Nous nous sommes intéressés au thème aide à la conduite avec l affichage tête haute en réalité augmentée sur le pare-brise. Nous pensons que l affichage tête haute à un grand avenir dans l automobile. En effet, perdre de vue la route quelques secondes pour regarder son GPS, ou pour changer de station de radio peut être très dangereux. Les affichages tête haute, permette de superposer la vision normale d un automobiliste avec des informations extérieurs. Ainsi l utilisateur pourrait, par exemple, avoir un retour sur sa conduite sans avoir à quitter la route des yeux. Maîtrise d œuvre Karim LAMOURI Caimin XIE Maîse d ouvrage Remy FRENOY Paul GEORGE Indira THOUVENIN 2

4 2 Objectifs Le but du projet est de réaliser un outil de simulation de conduite dans un monde virtuel. Dans ce monde virtuel, l utilisateur est au volant d une voiture muni d un HUD (Heads-Up Display). Cette simulation nous servira à vérifier la pertinence de certaines fonctionnalités d un HUD au sein d une voiture. Pour aider l utilisateur à conserver ses repères de la vie réelle, notre application affichera le tableau de bord de la voiture. Cet outil doit permettre de : Vérifier si le mode de contrôle et les méthodes d interaction sont confortables pour l utilisateur. Evaluer l interface graphique : organisation des composants, design, représentation de l information. Les informations sur le pare-brise ne doivent pas être trop nombreuses et déconcentrer l utilisateur. Evaluer les risques en s appuyant sur des informations que les capteurs de la voiture lui transmettent ( par exemple la vitesse des voitures avoisinantes pour les doubler) 2.1 Objectifs initiaux Au début du projet, en fonction de nos compétences et de la durée du projet, nous avons défini les fonctions à réaliser et les avions classé en trois niveaux. Niveau Essentiel : Aide au stationnement : Lorsque l utilisateur veut se garer, il peut activer une vue de dessus de son véhicule et des objets l environnant. Cette vue de dessus s affiche sur son pare-brise. Niveau Complémentaire : Aide à l anti-collision : Lorsque l utilisateur s approche dangereusement (en fonction de sa vitesse) d un obstacle, une alerte s affiche sur le pare-brise. Cette alerte comporte la vitesse de l obstacle s il est mouvant. Cette fonction s active automatiquement. Interface de communication : Une notification apparait sur le pare-brise lorsqu un appel est reçu (par un téléphone virtuel). L utilisateur voit donc la notification sur son pare-brise et peu décider de décrocher ou non son téléphone (virtuel). Niveau Avancé : Mode nuit : Le pare-brise se teinte de vert, et le contraste est modifié pour voir des éléments peu visibles dans le noir. Cette fonction doit être activée par l utilisateur. Les interfaces d interaction avec le logiciel devaient être faites grâce à une wiimote ou un razer hydra 3

5 2.2 Objectifs finaux fixés lors de la dernière revue de projet Au fur et à mesure de la réalisation de notre application nos choix ont été remis en cause. Nous avons jugés que l utilisation d une wiimote ou d un razer hydra n était pas du tout adaptée à une application de simulation de conduite. Nous avons donc complètement revu nos interfaces d interaction. Pour passer à un volant et à un pédalier. De plus lors de notre deuxième revue d avancement (le niveau essentiel et avancé avaient été réalisés), un chargé de TD nous a fait la remarque que les fonctions que nous avions implémentés n était pas vraiment de la réalité augmenté. Nous avons donc décidé de remanier notre projet suite à cette remarque. La fonction d interface de communication à été abandonné au profit d un détecteur d angle mort. Ayant réussi à terminer nos objectifs principaux plus tôt que prévu, nous avons décider d implémenter un nouveau niveau à notre application : le niveau super avancé. Dans ce niveau, nous avons implémenté une fonction d affichage d informations textuelles géolocalisées et un menu pour aider les utilisateurs lambda. Ainsi voilà les changements récapitulés : Suppression de l interface de communication dans le niveau intermédiaire Ajout : Dans le niveau intermédiaire : Détecteur d angle mort : Lorsqu un objet rentre dans les angles morts du véhicule, le pare-brise se teinte partiellement d orange sur le côté dont l angle mort est dangereux. Dans le niveau super avancé : Affichage d informations textuelles géolocalisées Menu : Sert de point d entrée à notre application. Il permet d avoir facilement accès à toutes les scènes de notre application pour tester notre voiture munie d un HUD 4

6 3 Réalisation Dans cette partie, nous allons présenter les fonctions réalisées dans l ordre chronologique de réalisation. 3.1 Architecture de l application Notre projet est basé sur un projet Unity nommé : Car Tutorial. Celui-ci est disponible sur l Unity Asset Store. Ce projet nous a fourni les éléments basiques pour la réalisation de notre application : le terrain, la route, la maquette de la voiture et un script de base pour le comportement de la voiture (mouvements verticaux et horizontaux). Notre avons séparé les éléments du paquet Car Tutorial et notre propre travail. Celui-ci se trouve, non-modifié, à la racine de notre dossier Asset. En effet, nous considérions les fonctions que nous allions réaliser comme des extensions de Car Tutorial. Nous ne voulions pas non plus noyer notre travail dans les composantes de Car Tutorial ce qui aurait rendu la lecture de nos travaux très compliqué et confus. Nous pensons que notre application peut servir de base pour le développement pour d autres applications avec un HUD. Concernant l organisation des dossiers, nous avons suivi les conventions d Unity. Seul le dossier CarTutorial ne fait pas parti des conventions Unity. Il abrite le contenu du projet original Car Tutorial. 3.2 Mise en place du système Au début du projet, nous avons pris le temps d étudier attentivement le projet Car Tutorial. C est à ce moment, au vu de la complexité des scripts et du projet, que nous avons décidé d isoler dans un dossier tout les éléments fournis par ce projet. Nous avons également conclu que notre application pourrait être aussi complexe. A cet effet, nous avons mis en place un outil de versioning (git). En effet, nous savions que nous allions créer pleins de petits objets qui serait dur à importer et exporter pour fusionner nos travaux. De plus, nous voulions pouvoir revenir rapidement et facilement en arrière si un problème survenait. Une fois cette base solide mise en place, nous avons commencé la réalisation des fonctionnalités de notre application. 3.3 Aide au stationnement Se garer en voiture est parfois compliqué. Nous ne savons pas si nous avons l espace nécessaire ou pas, par exemple. L aide au stationnement est la première fonctionnalité réalisée. Celle-ci s appuie sur le rendu d une caméra sur notre HUD. 5

7 Note : Cette fonction s active par la touche u du clavier ou les boutons à droite du volant G27. Figure 3.1 L aide au stationnement activé sur le HUD 3.4 Vision nocturne La conduite nocturne est parfois compliquée. Surtout en campagne et sans éclairage municipal. Parfois des piétons ou des cycles sont présents sur cette route. S ils sont vêtus de manière sombre, il devient compliqué d anticiper leur présence. A cette effet la seconde fonctionnalité pour notre HUD à été une vision nocturne. Pour afficher cette vision nocturne, nous appliquons un shader à une caméra qui vient retranscrire sa vision sur le HUD. Le projet Car Tutorial ne comportant pas de scène nocturne, nous avons dû en créer une de toute pièce. Nous y avons même ajouté du brouillard pour diminuer encore plus la visibilité. Note : Cette fonction s active par la touche i du clavier ou les boutons à gauche du volant G Détecteur d angles morts Dans certaines voitures, on a beaucoup d angles morts sur les côtés qui ne sont pas couverts par les rétroviseurs. Le changement de file peut donc être très dangereux en zone urbaine ou les obstacles surgissent de partout. A cet effet, nous voulions tester un avertisseur pour tester les angles morts de notre véhicule. La détection d angles morts se fait par des cubes transparents. De chaque côté du véhicule, on trouve dix cubes formant une zone triangulaire. Grâce aux deux fonctions OnTriggerEnter et OnTriggerExit, la voiture peut savoir s il y a des obstacles dans l angle mort du conducteur. 6

8 Figure 3.2 La vision nocturne désactivée sur le HUD Figure 3.3 La vision nocturne activée sur le HUD Lors de la détection d un obstacle, une barre verticale jaune transparente apparait sur le parebrise du côté correspondant. Cette barre disparait si l obstacle disparait de l angle mort. Note : Cette fonction s active automatiquement. 7

9 Figure 3.4 Le détecteur d angle mort activant une notification car quelque chose s y trouve 3.6 Aide anti-collision Nous avons constaté qu en conduisant il n est pas toujours facile d apprécier une distance de sécurité par rapport à une vitesse. A cet effet, cette aide d anti-collision permet de savoir si l on est trop proche d un obstacle en fonction de la vitesse du véhicule (ainsi elle s activera à une distance plus proche de l obstacle à petite vitesse, comparée à une grande vitesse). Pour détecter si un obstacle est devant notre véhicule, nous avons utilisé un Raycast. Ce rayon détecte d abord l objet devant par la collision avec une longueur variable par rapport à la vitesse de notre voiture. Il enregistre la position de l objet détecté. Il répète cet opération tant que l on détecte l objet. Ce qui nous permet grâce à ses coordonnées d en déduire la vitesse de l obstacle. Le HUD affiche donc un message d alerte en y incluant la vitesse de l obstacle. Note : Cette fonction s active automatiquement. 3.7 Affichage d informations textuelles avec géolocalisation Cette fonctionnalité part d un constat, les panneaux d indication au bord des routes ne sont pas toujours très clairs. Ainsi avec cette fonctionnalité, nous voulons essayer de montrer que l affichage dynamique des informations plus une flèche pointant dynamiquement vers ces informations peu-être très pertinent. Pour la réalisation de cette fonction, nous avons d abord défini un objet vide pour représenter la zone de diffusion (récupération de ses coordonnées). Lorsque la voiture entre dans la zone d émission, elle reçoit un message textuel sur son parebrise. Une flèche apparait en même temps sur le pare-brise de la voiture. Cette flèche pointe toujours vers l expéditeur du message. Note : Cette fonction s active automatiquement. 8

10 Figure 3.5 L aide anti-collision active car un obstacle est tre s proche Figure 3.6 La voiture affiche une information textuelle appuye e par une fle che indiquant la direction d ou provient l information 3.8 Menu Pour rendre notre application plus simple pour les utilisateurs, une interface graphique a e te re alise e. Voici les boutons pre sents, et leur buts : 9

11 (a) Menu principal avec l accès aux contrôles et aux (b) Menu des contôles pour savoir comment utiliser différentes scènes de notre application l application Figure 3.7 Les deux menus de notre application Contrôle : ce bouton affiche les commandes de contrôle de notre application. Scène Jour : Ce bouton lance une scène adaptée à l essai de la voiture dans le jour pour tester l aide au parking. A cet effet, il y a deux voitures garées à côté de notre voiture. Scène Nuit : Ce bouton lance une scène nocturne. Cette scène convient parfaitement pour tester la vision nocturne. A cet effet, deux voitures sont cachées dans le noir. En activant la vision nocturne nous pouvons les voir apparaitre. Scène AI : Au lancement de cette scène, une voiture démarre et suit automatiquement la route à côté de notre voiture. Scène Beacon : Cette scène sert à tester nos informations textuelles géolocalisées. Au lancement, notre voiture est arrêtée devant une zone émettant des informations géolocalisées. Il suffit d avancer un peu pour voir s afficher les informations et une flèche pointant vers l expéditeur du message. Quitter : pour quitter l application. De plus dans chaque scène, la touche échappe permet de retourner au menu principal. 10

12 4 Bilan général 4.1 Difficultés Au cours de ce projet, nous avons eu affaire à de nombreuses difficultés. Le premier type de difficulté était les difficultés de compatibilité. En effet, lorsque nous avons eu l intention d utiliser un volant pour notre application, nous avons acheté un volant (Trust GXT27). Celui-ci s est avéré inutilisable avec Unity. Nous avons donc eu à trouver, avec les enseignants de RV01, une solution. Cette solution s est métamorphosée en un volant Logitech G27. Ce problème de compatibilité fut très gênant mais très facile à résoudre. Le deuxième problème auquel nous nous sommes confrontés est un atout d Unity. Il s agit de sa flexibilité. En effet Car tutorial étant déjà en parti en javascript, nous avons décidé de continuer dans cette voie. La flexibilité du javascript est très dangereuse si nous ne sommes pas rigoureux. Ainsi, à plusieurs reprises, nous avons débuggé notre programme pendant des heures alors que l algorithme était bon. Nous avions seulement fait une faute de frappe dans le nom d une variable. Il nous aurait certainement été préférable de réaliser nos modules en C#. Plus strict et fortement typé. Le troisième problème auquel nous nous sommes confrontés a été la difficulté de versionner les sources de Unity. En effet, le versioning des fichiers sources s est très bien passé. Cependant pour les fichiers binaires tel que les prefabs, la tâche a été très compliquée et hasardeuse. En cas de conflit (car chacun avait modifié le même binaire) nous n avions pas d autres choix que d élire manuellement la version à conserver (perdant ainsi ce qui avait été réalisé sur l autre). Nous ne pouvions pas les fusionner. Unity gagnerais beaucoup à être versionnalisable plus efficacement. Le dernier problème était nos compétences. Nous sommes étudiants en informatique sans formation avec des outils de modélisation 3D. Nous n avons pas pu créer nos propres objets 3D. Il a toujours fallu s appuyer sur des objets déjà existants et créés par d autres. Le problème est que ces objets n étaient pas toujours adaptés à nos besoins. C est pour cela que nos interfaces graphiques ne sont pas toujours du plus bel effet. Mais nous sommes quand même très contents du résultat de notre application. Celle-ci est harmonieuse et user-friendly, malgré nos compétences faibles en interface utilisateur et ergonomie. Nous pensons qu avoir un membre de l équipe en Master Design aurait pu être un gros plus pour notre application. 4.2 Résultats par rapport à l objectif Par rapport à nos objectifs initiaux, notre projet a grandement été modifié. En effet, certaines fonctionnalités ont été remplacées par d autres (nous pouvons penser à l interface de notification d appel sur HUD que nous avons supprimée au profit d un détecteur d angle mort.) Nous avons également ajouté une nouvelle fonctionnalité : l affichage d informations textuelles 11

13 géolocalisées. Les modes de contrôle de notre application ont également été modifiés. Nous sommes passés d une application qui devait utiliser une wiimote ou un razer hydra à un volant ou un clavier. Nous pensions également que notre interface utilisateur serait bien plus pauvre. Ce n est, au final, pas le cas. 4.3 Retours utilisateurs Après avoir fini notre projet, nous l avons fait tester à nos amis. Ils ont tout de suite compris le fonctionnement de l application. Seul un point critiqué a été noté : l inclinaison du HUD. En effet lorsque les images défilent dessus, elles sont déformées à cause de l inclinaison du pare-brise. Cela a été la seule remarque sur notre application. Nous pensons donc avoir bien réussi notre application dans l ensemble. Il serait pourtant intéressant d évaluer la possibilité d intégrer un Oculus Rift. En effet peut-être qu avec une situation plus réaliste et un champ de vision de l utilisateur agrandi, l inclinaison du HUD ne serait pas aussi gênante. 4.4 Conclusion Pour notre projet, nous avons réussi à compléter nos objectifs initiaux et même plus. Comme vous avez pu le voir plus haut, nous avons eu le temps de rajouter des fonctionnalités à notre projet. Nous sommes également très contents du pilotage de notre projet. Dès le début, nous avons fait le bon choix de considérer notre application comme un projet lourd et complexe. A cet effet, nous avons donc prévu un planning et utilisé un outil de versioning (Git). Sans ce dernier outil, nous aurions perdu un temps fou à fusionner nos avancées personnelles entre chaque réunion. Surtout à la fin où la cadence s est particulièrement accélérée car la date de livraison approchait. Il nous a aussi évité de gros bugs liés à la fusion des composants. En fusionnant petit à petit, nous nous assurions que nos composants étaient compatibles. La création d une vidéo pour notre projet a également été un exercice très formateur. C est la première fois que nous réalisions une vidéo promotionnelle d un de nos projets. 12