Description

La plate-forme de simulation SOFA (https://www.sofa-framework.org/) est un logiciel open source qui existe depuis plus de 10 ans. Il est utilisé pour la simulation médicale et la robotique. Afin de favoriser sa démocratisation, nous souhaitons que SOFA soit accessible depuis un navigateur internet. Pour cela, il faudra interfacer SOFA avec un front-end web développé précédemment.

Objectifs

Interfacer un front-end html css avec un moteur de simulation écrit en C. Il s’agit de permettre à des utilisateurs d’éditer du code, de lancer des simulations, de sauvegarder des simulations et d’obtenir un retour visuel, le tout en ligne et en temps réel.

Calendrier prévisionnel

Réalisation du Projet

Choix techniques : matériel et logiciel

Matériel

Un serveur de l’Inria permettant de faire tourner des instances de SOFA de manière distante

Logiciel

Django pour la réalisation de front-end web (codage en Python et HTML)
Bootstrap pour enrichir le design de la front-end
webGL avec Qt pour la partie de rendu 3D des simulations (codage en Python, HTML, JavaScript coté webGl et C côté logiciel)

Liste des tâches à effectuer

Mise en place d’une base de données permettant de gérer des utilisateurs et leur offrant accès à des sessions privées.
Définition et réalisation d’un modèle de base de données pour les projets SOFA que l’on prévoit de stocker
Définition et réalisation des pages web permettant l’édition de code et l’accueil du rendu d’exécution en temps réel
Définition et réalisation des pages web complémentaires nécessaires au bon fonctionnement du site
Implémentation du processus d’exécution d’un script et de récupération en temps réel du flux d’exécution de SOFA

Travail réalisé

Semaine 1

Bilan de la première réunion avec monsieur Jérémie Dequidt, membre de l’équipe DEFROST travaillant sur SOFA, afin de mieux connaître l’orientation souhaitée du projet : SOFA est un logiciel de simulation numérique dans le médicale, la robotique solide et depuis 2015 la robotique déformable. Il connaît un attrait grandissant auprès des professionnels des domaines concernés mais peine à être accessible pour 2 raisons majeures :

le logiciel est difficile à prendre en main sans connaissance du C++ ou de la physique utilisée pour les calculs ;
le logiciel n’est pas encore disponible en binaires et son noyau de 500 000 lignes de code est long à compiler (4 heures en moyenne) ;

Le premier problème a été résolu en créant un binding Python permettant de générer des simulations via des scripts et par la récupération d’évènements clavier (interaction en temps réel).

Pour répondre au second problème, l’équipe souhaiterai pouvoir rendre accessible SOFA depuis un navigateur où une version embarquée de SOFA permettrait facilement à un utilisateur de réaliser quelques tests. Le but est de donner un aperçu des fonctionnalités de SOFA avant de se décider à compiler soit même une version sur son ordinateur ou bien de permettre un partage simple de projets SOFA sur un espace dédié offrant des fonctionnalités d’aperçue.

Un exemple de modèle dont on souhaite se rapprocher est le site Shadertoy (https://www.shadertoy.com/) qui lui-même utilise des scripts modifiables afin de générer des modèles géométriques 3D

Les technologies envisagées pour la modélisation 3D sont webGL et Qt. SOFA pourra être appelé directement en ligne de commande, il conviendra de décider les retours à sélectionnés. Monsieur Damien Marchal n’ayant pas été joignable cette semaine, j’ai pu fixé un rendez-vous la semaine prochaine.

Semaine 2

Bilan de la première réunion avec monsieur Damien Marchal, également membre de l’équipe DEFROST travaillant sur SOFA: Nous souhaitons interfacer SOFA avec des requêtes API. L’objectif de réalisation avec webGL est encore incertain :

on ne sait pas quelle partie de SOFA devra être conservée
on ne sait pas si SOFA est réalistiquement compactable
on ne sait pas quelles sont les interactions que nous pourrons offrir à l’utilisateur

Néanmoins, nous pouvons faire émerger des nécessités pour le site à créer nous permettant de construire son cahier des charges :

L’utilisateur doit pouvoir éditer le code de sa scène (un script python par exemple) ;
L’utilisateur doit pouvoir avoir un retour en temps réel de l’exécution de sa scène ;
L’utilisateur doit pouvoir paramétrer son projet comme ″privé″ ou ″publique″ et avoir accès aux projets qui sont publiques ;
L’utilisateur doit pouvoir se connecter à un compte afin de sauvegarder ses projets et y accéder ;

Compte-tenu de l’incertitude face à la réalisation d’un rendu 3D temps réel, j’ai proposé l’idée de commencer par présenter un rendu vidéo de l’exécution. Il s’avère que SOFA permet d’éditer un fichier vidéo mp4 permettant de visualiser une scène et part ailleurs des serveurs à l’INRIA sont en mesure de faire tourner des instances de SOFA ainsi accessibles à distances. Il a donc été convenu qu’une première version du site permettra dans un premier temps de faire un retour vidéo des simulations (donc temps non réel) : cela permettra d’avoir un premier livrable fonctionnel et utilisable si la version de modélisation 3D en temps réel n’aboutit pas. Dès lors, j’ai pu schématiser la situation :

En rouge le niveau 1, en bleu le niveau 2. À noter que plusieurs serveurs sont disponibles à l’Inria mais pour le moment nous ne prévoyons d’en utiliser qu’un et donc les problèmes de redondance et de haute disponibilité ne sont pour le moment pas considérés.

Semaine 3

Les projets déjà développés auparavant sont disponibles sur un GitLab privé de l’Inria dont je viens de recevoir l’accès. La première étape de mon travail consiste à faire un rapport de test des projets afin d’affiner notre cahier des charges si nécessaire.

Projet antérieur n°1

Ce projet présente les fonctionnalités suivantes :

gestion fonctionnelle des comptes clients (modèle de BDD, création de compte, login/logout)
vérification des adresses mails conformes (par comparaison à un dictionnaire)
page de création d’un nouveau projet comportant une grille où le placement de points permet le calcul et la création d’un maillage

Ce projet ne présente pas :

de modèle de BDD pour les projets
de zone interactive d’édition de code

Projet antérieur n°2

Ce projet présente les fonctionnalités suivantes :

gestion en partie fonctionnelle des comptes clients (modèle de BDD, création de compte, login mais logout défectueux)
barre de navigation
modèle de BDD définissant la structure d’un projet SOFA
page de création d’un nouveau projet comportant une zone interactive d’édition de code

Ce projet ne présente pas :

de moyen de sauvegarder les projets dans la base de données
d'élément concernant un retour d’information vidéo ou autre (les champs sont tracés mais non implémentés)

Semaine 4

Suite à mon rapport sur les projets déjà existants de nouveaux éléments ont été ajoutés au cahier des charges :

un utilisateur devra pouvoir uploader un projet déjà existant sur sa machine ;
un utilisateur devra pouvoir télécharger les projets publiques ;
l’utilisateur doit pouvoir créer un nouveau projet à partir d’un projet déjà existant ;

J’ai décidé d’abandonner le projet antérieur n°1 pour diverses raisons :

la saisie de scène n’est pas le modèle qui nous intéresse (saisie de points sur une grille pour créer un maillage) et s’appuie sur un travail en développement d’un chercheur de l’équipe DEFROST
l’arborescence du projet n’est pas satisfaisante : toutes les fonctions sont séparées en petites applications (login, logout, gestion des scènes, gestion des utilisateurs, etc) ce qui serait bien pour créer un modèle très réutilisable or nous souhaitons avoir un modèle simple, pouvant être rapidement déployé et facilement maintenu.
la base de données n’est pas structurée et ne présente aucun modèle
l’interface graphique n’est pas satisfaisante : elle est fonctionnelle dans le peu qu’elle fait mais n’est pas agréable à utiliser
la rédaction du code existant n’est pas satisfaisante : les noms de variables sont inconsistants, le français côtoie l’anglais avec des fautes d’orthographes, etc. De manière générale, la rédaction du code effectuée entrave une potentielle facilité de maintenance.

Cette semaine j’ai continué un travail de tri et d’adaptation du code du projet antérieur n°2

Semaine 5

Après de nouvelles discussions avec M. Marchal, j’ai établi qu’il valait mieux repartir de zéro plutôt que de continuer de tenter d’adapter le code du projet antérieur n°2. Cette décision survient car la rédaction de ce projet ne nous convient pas :

le projet a été réalisé il y a 6 mois mais la version de django utilisée est antérieure à la version la plus récente disponible à ce moment, induisant l’utilisation de pas mal de fonctions obsolètes
le modèle de base de données est à revoir
beaucoup de fonctionnalités sont rédigées mais non utilisées ou non fonctionnelles, appelant à un tri important de code et à pas mal de refactoring

Nous avons donc décidé d’un accord commun qu’il serait plus sain de repartir d’un projet vierge. Il est cependant à noté que les pistes envisagées dans le projet antérieur n°2 sont pour la plupart satisfaisantes. Nous partirons donc sur les technologies communes suivantes :

Django pour la gestion de la base de données (programmation en python compatible avec les bindings de SOFA)
SQLite pour le modèle de BDD, étant donné qu’il s’agit d’un format extrêmement portable (constitué d’un seul fichier)
Django CodeMirror pour la création de la fenêtre de saisie de code (des tests avancés seront nécessaire mais de ce qui fonctionne actuellement le module semble prometteur)
Bootstrap pour le design du site, pour son accessibilité et sa réputation

Semaine 6

Afin de bien saisir toute la construction d’une application django j’ai pris le temps cette semaine de suivre la documentation officielle (https://www.djangoproject.com/start/)

Je suis désormais en mesure de :

créer une application
créer des vues
créer un modèle de base de données
naviguer dans la base de données via la console Django
créer et manager des utilisateurs
manager ma base de données via le serveur de développement

python manage.py runserver
puis accès à http://127.0.0.1:8000/admin/

utiliser le système de template
gérer les fichiers statiques de ressources

Semaine 7

Afin de partir sur un modèle de base de données satisfaisant, je me suis chargé de le définir et de le faire valider. Ci-dessous se trouve un schéma UML du modèle conçu :

Le champ ″src″ de ″Projects″ contient un url renvoyant au projet initial dans le cas où le ″project″ est une copie d’un projet disponible dans notre base de données. Le fichier ZIP ″file_system″ regroupera les fichiers suivants :

index.html
index.png
index.mp4
main.html
main.py (or .pyscn .psl .scn)
data/
scripts/

Exemple de peuplement de la base de données :

Semaine 8

Afin de permettre la mise en place de toutes les fonctionnalités du site, il m’a fallut déterminer toutes les pages web indispensables au bon fonctionnement de l’application et permettant d’offrir toutes les fonctionnalités recherchées.

Les images ci-dessous permettent de donner un aperçu des templates envisagées. Elles seront passées au format numérique au besoin:

Les pages web indispensables à implémenter se résument aux pages suivantes, d’autres feront potentiellement leur apparition au besoin :

www.sofasite.com/home: page d’accueil avec message d’accueil et aperçu des projets récents ;
www.sofasite.com/login : page de login et de création de compte ;
www.sofasite.com/logout : page de logout ;
www.sofasite.com/browse : page de parcours des projets publique existants. Proposera une fonction de tri alphabétique et chronologique ;
www.sofasite.com/search/xxxxxx : page de recherche (via recherche par mots de l’utilisateur) ;
www.sofasite.com/new : page de création d’un nouveau projet. Permet seulement de définir le nom du projet et son statut (publique ou privé) ;
www.sofasite.com/import : page permettant d’importer directement un projet déjà existant sur la machine de l’utilisateur ;
www.sofasite.com/project/xxx : page d’un projet permettant de voir toutes les données de celui-ci. L’URL sera idéalement haché pour ne pas pouvoir deviner les adresses d’autres projets ;
www.sofasite.com/project/xxx/edit :page de modification d’un projet (édition de code) et proposant un retour direct d’exécution (retour vidéo ou 3D + résumé d’exécution retourné par SOFA) ;
www.sofasite.com/username/projects : page permettant de voir tous les projets pour un utilisateur connecté ;
www.sofasite.com/username/profile : page permettant à un utilisateur connecté de consulter et modifier son profile ;

Exemple du modèle de la page www.sofasite.com/project/xxx/edit

J'ai également terminé le système de login/logout cette semaine.

Semaine 9

Afin d’améliorer l’aspect graphique du site j’utiliserai Boostrap. En plus d’améliorer l’aspect visuel de toutes les pages, Bootstrap nous permettra de facilement mettre en place une barre de navigation utilisable sur chaque page.

Ci-dessous un schéma de sa conception, montrant toutes les fonctionnalités que nous souhaitons lui intégrer :

Le symbole (+) représente un bouton menant à la page /new.
Le symbole (↑) représente un bouton menant à la page /import

Ci-dessous une première étape de l’implémentation de cette barre de navigation (fichier navbar.html des templates):

Semaine 10

Travail sur django CodeMirror et la création de la fenêtre de saisie de code.

Livrables

Fichier:Rapport intermediaire P05.pdf

Fichier:Soutenance intermédiaire P05.pdf

IMA5 2018/2019 P05

Sommaire