Stage de Victor Dubs - Université de Technologie de Compiègne - [4/09/18 au 15/02/19]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage : contacter André

Sujet

• Proposition de stage

Stage (Septembre 2018 - Février 2019)

Septembre

• 3,
  - Arrivée
  - Visite et installation du poste de travail
  - Etude de l'existant : Analyse des développements des stages précédents axés sur le langage naturel ainsi que sur la visualisation des données en 3D, Recherche des technologies actuelles pertinentes sur ce domaine
  - Installation d'Eclipse et Android Studio ainsi que les SDK utilisés pour le développement d'application Google Cardboard
  -------------------------------------------------------------------------CHATBOT---------------------------------------------------------------------------------------
• 4,
  - Focus dans un premier temps sur l'aspect langage naturel, correction et maîtrise du chatbot pour ensuite implémenter la reconnaissance vocale
  - Installation d'Atom pour la partie Web
  - Etude poussée du chatbot, correction des différents bugs notamment au niveau des mesures (confusion string/array)
• 5,
  - Focus sur DialogFlow, utilisé dans le chatbot. Test et compréhension du système
  - Bug apparu : Le chatbot a perdu la connexion à son agent DialogFlow, visiblement dû aux tests avec mon propre compte Google
  - L'ancien agent était visiblement linké au compte Google du CDS
  - La version V2 de DialogFlow est proposée, celle-ci met en avant une reconnaissance vocale intégrée, en revanche celle-ci est apparue avant la réalisation du Chatbot qui utilise la V1 je vais donc enquêter s'il existe une justification particulière
  - La problème de connexion à l'agent provenait en réalité de Google
• 6,
  - Focus sur les travaux fait sur la modélisation 3D le temps que le chatbot redevienne fonctionnel
  - Etude du code de l'application et des technos utilisées
• 7,
  - Lecture des différents Rapports des anciens stagiaires
  - Point avec André Schaaff sur le chatbot, les fonctionnalités, ce qui pourrait être intéressant à développer et son architecture
• 10 - 14,
  - Etude des différentes solutions pour l'implémentation d'une reconnaissance vocale au chatbot
  - Etude d'une migration du chatbot utilisant la V1 vers la V2 de l'api
  - Mise en place d'un enregistrement du micro sur le chatbot
  Quelques difficultés apparues : La migration de la V1 vers la V2 semble impliquer l'utilisation de nodeJS et donc de retravailler l'architecture du chatbot, également l'api de capture Web Audio API est assez complexe et nécessite un certain temps pour être maitrisée
  - Apprentissage de NodeJS et de la Web Audio API
  - Point avec André Schaaff sur les autres technos possibles à DialogFlow pour ne plus le rendre dépendant uniquement de Google et ainsi d'avoir plusieurs agents éventuels, Choix de la reconnaissance vocale pour transfert texte vers DialogFlow OU envoi d'un fichier audio à DialogFlow pour traitement interne. Le choix a été de faire 2 versions de Chatbot chacune utilisant une méthode différente (des différences de temps de traitement entre V1 et V2 influe notamment sur ce choix)
  - Présentation par Laurent Michel de XMM-Newton / SVOM
• 17 - 21,
  - Focus sur une conversion de l'architecture du projet vers NodeJS
  - Présentation du travail de documentaliste par Emmanuelle Perret et Mihaela Buga
• 24 - 28,
  - Liaison des fonctions entre elles (variables require), parcours de tout le projet pour clarifier l'architecture et les appels de fonctions provenant d'autres fichiers js
  - Difficultés pour retrouver l'origine de chaque fonction, tout est chargé en même temps et il est nécessaire de faire CTRL+F dans chaque fichier pour retrouver sa provenance
  - Appel vers l'API V2 fonctionnel depuis le code JS, celui-ci est isolé et éxécute une requête prédéterminée, une fois la liaison des fonctions réalisé il sera possible de tout reconnecter vers la page index.html
  - Suggestion lors de la présentation du chatbot au sein du CDS de l'utiliser afin de découvrir les différents outils du CDS de façon ludique, éventualité de développer le côté découverte plus tard dans le développement
• Point sur le code :
  var exports = module.exports = {}
  Requis dans chaque fichier JS dont les fonctions sont utilisées dans un autre fichier
  
  exports.requestAladin=requestAladin
  Requis pour chaque fonction, on écrit de cette manière après avoir déclarer la fonction dans le fichier JS, ainsi il est toujours possible d'appeler une fonction exportée depuis le même fichier
  (exemple : non possible avec :
  exports.getRequest=function(result){
  return result.queryResult.queryText;
  }
  )
  
  L'arborescence des fichiers reste globalement la même que précédemment

Octobre

• 1 - 5,
  Difficultés lors de la tentative d'ajout de la partie dynamique html du chatbot à la partie connection avec l'api notamment du à un manque d'expérience sur NodeJS, notamment JSDOM
  Proposition de prendre du recul sur le code et de passer sur une autre partie du projet, point à prévoir Lundi 8
  --------------------------------------------------------------------------------CARDBOARD---------------------------------------------------------------------------------------
• 8 - 12,
  - Changement de projet vers le développement de l'aspect Google Cardboard : Dans un premier temps pouvoir voir une image fits en RV et pouvoir afficher les infos sur les objets dans la zone regardée, ces informations doivent apparaître et disparaitre de façon dynamique
  - Etude de l'utilisation d'Android Studio : le développement d'une "couche" supplémentaire permettant d'afficher des infos nécessiterait de toucher à de l'OpenGL et notamment de faire des traitement très complexes, changement de support de développement vers Unity
  - Unity utilise C# ou Js, ayant déjà utilisé Unity avec C# je me dirige vers ce langage, celui-ci permettant d'utiliser des fonctionnalités supplémentaires sur Unity, je conserve en revanche la possibilité de développer des modules externes en Js (lien code chatbot par ex)
  - Premier objectif : trouver un template pour l'utilisation d'une image en panorama semblable à celle d'Android Studio
  - Framework "Createch Interactive", celui-ci permet notamment 2 choses : Transformer une image 360 en un panorama affichable dans unity et Créer des hotspot pouvant déclencher un script lorsqu'on clique dessus
  - Une modification du système de Hotspot sera probablement nécessaire pour transformer ça en "temps de focus" sur la zone ciblée
  - Le framework utilise une procédure nécessitant de créer l'image VR avant le lancement de l'application, l'idée serait également d'intégrer ce processus à l'application pour pouvoir changer d'image en cours d'utilisation
• 15 - 20,
  - Maitrise de Unity : Compréhension et affichage de l'UI lors de l'activation d'un hotspot, utilisation d'un asset pour obtenir une police vectorielle
  - Modification du trigger du framework pour se déclencher lorsque le "Ray" rencontre un "Collider" de type hotspot, tests en modifiant un texte de l'UI
  - Présentation devant le conseil de tous les services du CDS et du travail réalisé cette année, un point de vue global très intéressant sur la situation actuelle du CDS
  - Problème au niveau de la gestion du Raycast, le ray ne semble pas prendre le centre de la "vue" : Nécessaire de créer un Raycast prenant le centre de l'écran tel qu'il est vu grace aux cardboards
  - Mise en place d'un crosshair pour déterminer correctement l'endroit visé avec le regard
• 22 - 26,
  - Point sur l'avancement :
  Premier objectif - Obtenir un hud propre affichant des informations sur le premier pano, en récupérant notamment les données via le serveur
  Améliorations - Gérer l'orientation de la caméra en fonction de l'heure, Obtenir un effet de zoom (aspect à explorer)

Novembre

• 1 - 15, - Problème d'un cadre blanc apparaissant lors du test uniquement sur cardboard : la création dynamique d'un hotspot pose problème et crée un genre de canvas pour les GameObject, solution à déterminer plus tard
  - Problématique de l'affichage de l'UI en Réalité Virtuelle, celle-ci ne peut pas être implémentée comme une UI classique et doit être implémentée dans le "world space", première solution est donc de placer un élément "canvas" et de le déplacer de façon à ce qu'il suive les mouvements de la caméra en déplaçant son élément "transform". Après de nombreux essais la solution trouvée est de mettre ces éléments en tant que fils de la caméra : lorsqu'un GameObject est fils d'un autre, celui-ci garde la même position par rapport à son objet père, ce qui donne l'impression qu'il agit comme un UI classique dans notre situation. Cela a notamment permis de réimplémenter le viseur au centre, les tests sur la cardboard se sont trouvés très concluants (risque de flou ou d'illisibilité pour du texte), le viseur permettant de beaucoup gagner en précision.
  - Réception des 100 Cardboards qui étaient attendues, un test sur une des cardboards m'a permis de constater une nette amélioration de la netteté et de la précision de l'application
  - Mise en place de l'appel serveur avec un module nommé "www" permettant de faire des appels http au sein de l'application, j'ai repris le code notamment utilisé dans le chatbot pour récupérer tout d'abord des données de Vizier, après plusieurs tests c'est visiblement l'appel "TAP" qui me semble le plus approprié, cela implique de créer une requête en ADQL.
  Il me semble nécessaire d'approfondir mes connaissances à propos des différentes possibilités d'appels serveur, leur fonctionnement, ex : qu'apporte l'utilisation du service "TAP" ?, également apprendre à maitriser l'utilisation d'ADQL afin de comprendre comment créer une requête pour notamment trouver des objets dans une certaine zone.
  - Un important bug notamment dû à l'utilisation de Unity sur Linux m'empêchait d'utiliser le module www, j'ai donc dû réinstaller l'ensemble des logiciels et des package .NET, n'ayant pas d'alternative à l'utilisation de ce module, la solution fut d'ouvrir le projet via l'IDE MonoDevelop, et ensuite rouvrir le projet via Unity, la cause du problème reste inconnue mais tout fonctionne dorénavant.
• - Les tests de performances pour les appels serveurs m'ont parus très bon, il est possible d'enchaîner des centaines de requêtes sans ressentir de ralentissement, la question se pose maintenant de la façon dont les données doivent être récupérées :
  1. Lancer en permanence des appels serveurs pour obtenir des infos sur ce qui est regardé
  2. Lancer un premier appel serveur pour récupérer les infos de base sur les objets les plus pertinents sur toute l'image, enfin lors du parcours uniquement appeler le serveur pour plus d'infos lors d'un passage sur un de ces objets
  D'autres possibilités sont à envisager, une contrainte est à prendre en compte : une limite sur le nombre de requêtes, cela ne semble pas sain de "mitrailler" de requêtes le serveur, réduire leur nombre au minimum semble le plus judicieux ce qui me pousserait à partir vers la seconde solution.
  - Pour construire une requête il est nécessaire d'obtenir deux éléments : ra (right acension = longitude) et dec (declination = latitude). Il faut donc à partir de Unity les récupérer, le plus important et le plus complexe semble notamment de calibrer l'image, notamment en prenant un objet précis dont on connait ra et dec et ensuite de placer la caméra sur cet élément. Unity nous permet de récupérer le vecteur de direction de la caméra, grace à ray.direction, grace à la formule que m'a fourni françois-xavier je peux les convertir en dec et ra. J'ai en revanche besoin de l'aide d'André Schaaff pour le calibrage, ne sachant pas comment récupérer un repère de cette image, ou quel service utiliser pour le trouver.

Décembre

• La solution choisie est de créer un focus sur une certaine zone : dès que le curseur (donc le centre de l'écran) dépasse une certaine distance la zone de focus est réinitialisée, lorsque cela arrive, on prend le point du curseur comme focus, et on fait en théorie une requête TAP sur la zone visée (un cône d'une certaine taille à définir). Pour l'instant la requête de test utilisée prend le premier astre en terme de distance, il reste à définir quelle serait la meilleure approche, probablement de faire apparaitre l'astre le plus important.
• Actuellement sont affichés dec, ra, le vecteur de direction de la caméra, ainsi que le vecteur du gyroscope autour du viseur, cela a notamment pour utilité de calibrer les coordonnées en zéro. Le calibrage se fait grace à Aladin, en revanche celui affiche les coordonnées au format galactique (alpha = 0-360°, beta = -90 - 90°). Il est donc nécessaire de convertir les coordonnées équatoriales en données galactiques :
  
  avec alpha=ra et delta=dec, epsilon est une constante
• Le canvas d'affichage des informations et le canvas du cercle indiquant l'origine du focus sont 2 canvas distincts, le cercle doit être sur son propre canvas pour pouvoir être déplacé avec précision.
• Le système de focus pour l'affichage utilise un Raycast standard, on ne gère pas de collision non plus (en réalité le système de HotSpot du framework n'est actuellement pas utilisé, il serait éventuellement possible de l'utiliser pour sauvegarder les points qui ont déjà été focus).
  Après plusieurs tests et notamment l'affichage d'une image sur le canvas de focus, il est difficile de distinguer les images avec la Cardboard, l'idée serait alors de créer un nouveau système de focus au sein du canvas : Lorsqu'on regarde un certain temps une image celle-ci s'agrandit (= une copie de l'image est affichée plus proche de la caméra).
  Une difficulté apparaît en revanche : Un Raycast standard ne fonctionne pas sur une Image qui est considérée comme un élément d'UI, il faut alors utiliser un Graphic Raycast, son utilisation est plus complexe et on doit gérer une liste d'éléments graphiques qui sont parcourus.
• Des recherches ont été faites sur les possibiltés d'ajouter la reconnaissance vocale à l'application : de nombreux assets sont présents pour cette fonctionnalité, la plus prometteuse semble notamment l'utilisation du speech recognition présent sur les smartphones Android, il serait ensuite possible de faire le parallèle avec DialogFlow et ainsi utiliser uniquement la V1 via des requêtes textuelles.
• Piste de recherche conversion données galactiques : Utilisation du code Java de conversion disponible sur l'intranet du CDS

Janvier (2019)

• 3 - 11, Rédaction du rapport de stage
• 14 - 18, Travail sur le calibrage de l'application pour qu'elle corresponde notamment aux coordonnées d'Aladin. La première étape était d'utiliser les coordonnées galactiques, il était donc nécessaire de convertir les coordonnées équatoriales de l'application vers les coordonnées galactiques notamment en utilisant les équations montrées précédemment. Ainsi le décalage pouvait se calculer une fois celles-ci disponible. Le point de repère utilisé pour le calibrage est le centre galactique.
  2 détails importants sont alors apparus : Aladin permet en réalité d'afficher les coordonnées équatoriales, ce qui permet de ne pas avoir à utiliser les coordonnées galactiques. Repérer et appliquer le décalage en coordonnées galactique se révèle très complexe.
  J'ai donc repéré le décalage sur les coordonnées équatoriales : On se place avec Unity sur le centre galactique et on relève les coordonnées, dans Aladin on se place au même endroit en utilisant le fonction recherche "galactic center" et on relève également les coordonnées. Ensuite on applique la différence aux coordonnées de Unity pour qu'elles correspondent à celles d'Aladin.
  A ce moment là les coordonnées correspondent uniquement pour le centre galactique, en revanche lors des déplacements du curseur les coordonnées sont inversées. Il est donc nécessaire d'inverser la déclinaison et l'ascension droite.
  Point important du traitement des coordonnées est qu'il est important que la déclinaison soit comprise entre -90° et 90° ainsi que l'ascension droite entre 0° et 360° : Si delta > 90 alors le dépassement est amputé de 90, de même pour -90°. Si alpha < 0° alors le dépassement est amputé de 360.
• La conversion en coordonnées galactiques reste toutefois présente car pouvant être utile notamment pour les afficher.
• Il est maintenant possible de faire une requête avec les bonnes coordonnées vers les différents serveurs : Le problème restait notamment de parser les données Json qui sont récupérées lors de la requête. J'ai utilisé l'asset Json .NET qui permet de parser notamment les tableaux et de créer des objets flexibles pour des situations où les données sont variables, le traitement de situations complexes devient alors beaucoup plus simple. Pour l'architecture de l'application j'ai créé un "jsonHandler" pour encapsuler le traitement des données et enventuellement pouvoir changer de technologie. Les données sont donc récupérées correctement et on peut afficher l'identifiant et le nom du premier astre recontré.
  Il est maintenant nécessaire :
  - d'affiner la requête ADQL pour trouver le résultat le plus pertinent,
  - développer le canvas d'affichage,
  - centrer le cercle de focus sur l'endroit exact de l'objet trouvé et eventuellement le réduire
• Amélioration de la qualité de la skybox en augmentant la limite des images à 4096*4096
• Tentative d'importation d'une image dans sur l'interface lors d'un focus : Utilisation de l'asset PowerUI pour intégrer du code HTML/CSS/JS dans un GameObject, la tentative fut d'intégrer Aladin Lite au sein de l'application. Finalement les capacités de l'asset restent trop limitées pour intégrer un widget aussi complexe, il est donc nécessaire de trouver une autre solution pour intégrer une image.
• 21 - 25, Problème rencontré : Pour placer le cercle de focus au bon endroit il est nécessaire de récupérer la déclinaision et l'ascension droite du serveur, puis de reconvertir ces coordonnées en cartésien et retrouver les mêmes coordonnées que le vecteur ray.direction. Le calcul inverse ne fonctionnant pas je me suis rendu compte que mes premiers calculs manquaient une étape : transformer l'axe -180°/180° en 0°/360°.
• L'API v1 de DialogFlow va devenir obsolète le 23 octobre 2019
• Observation des différentes solutions d'implémentation de DialogFlow dans Unity : Il existait un asset nommé API.AI qui correspond à l'ancien nom de DialogFlow, cet asset n'est plus mis à jour et permettait d'utiliser la v1 de DialogFlow et le début de la v2. Visiblement seule la fonction texte est encore fonctionnelle et implique de devoir transformer le vocal en texte dans Unity. Cette solution ne semble pas être la meilleure car elle ne sera probablement plus fonctionnelle dans peu de temps.
• Une autre possibilité serait de récupérer directement un package pour C# de DialogFlow qui est utilisé en .NET, en revanche il m'est impossible de récupérer le package car apparemment 'Google.Cloud.Dialogflow.V2' est introuvable. Il faudrait également que je me renseigne sur .NET qui est une technologie que je ne connais pas vraiment.

Février

• ...

Liens

• package Unity : https://mega.nz/#!LhhxHIiS!b2Vl3SRaq92EcswEdu9vWj-yK1wUQNjnDMe5wAkN-54

• APK : https://mega.nz/#!booHhARY!DxWIFwB9Wb3763h4uLa4-Jn4rCPyIFVTlsEjCWLD38E

Versions testables

• ...

Documentation

• ...

Travail post stage éventuel

• ...

Liste des améliorations à envisager

• ...

Bugs connus

• ...