Wiki d'activités IMA - Contributions de l’utilisateur [fr]

Projets IMA5 2014/2015

2015-02-24T12:14:06Z

Nmartin1 : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

== Répartition des binômes ==

<table border="1">
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<tr>
<td>[[P1 Modélisation et commande de l'auto-ignition d'un moteur HCCI]]</td>
<td>Moulé Alexandre / Taché Clément </td>
<td> Anne-Lise Gehin / Jean-Yves Dieulot </td>
<td>[[Fichier:Rapport decembre moule tache.pdf]] </td>
<td>[[Fichier: RapportFinPFE.pdf]]</td>
</tr>
<tr><td>[[P5 Filtrage des indicateurs numériques de diagnostic]]</td>
<td> ZIOU Ismaïl / HAMZAOUI Oussama </td>
<td> Belkacem Ould Bouamama </td>
<td>[[Fichier:rapport_Z.pdf]]</td>
<td>[[Fichier:Rapport PFE ZIOU HAMZAOUI.pdf]]</td>
</tr>
<tr>
<td>[[P6 Gestion des flux thermiques du bâtiment Polytech]]</td>
<td>Florian Royer / Zohour Assaieb </td>
<td> Belkacem Ould Bouamama </td>
<td> [[Fichier:Rapport_Intermédiaire_Royer_Assaieb.pdf]] </td>
<td> [[Fichier:Rapport_Final_PFE_ProjetP6.pdf]] </td>
</tr>
<tr><td>[[P7 Utilisation d'un Robot Nao pour les enfants autistes]]</td>
<td> Rodriguez Loïc/Ismaïl Tahry</td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Projetpfenaomi.pdf]]</td>
<td>[[Fichier:Rapport PFE RodriguezTahry.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P8 Pilulier]]</td>
<td> Alexandre Mercier / Emile Pinet</td>
<td> Thomas VANTROYS / Alexandre BOE </td>
<td>[[Fichier:Rapport decembre PFE pilulier mercier pinet.pdf]]</td>
<td>[[Fichier:Rapport PFE Pinet Mercier.pdf]]</td>
</tr>
<tr><td>[[P9 Agenda pour personnes non lectrices]]</td>
<td> Cédric DESPREZ & Soufiane HADDAOUI </td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Rapport_MiSoutenance_DESPREZ_HADDAOUI.pdf]]</td>
<td>[[Fichier:RapportFinal_Desprez-Haddaoui.pdf‎]]</td>
</tr>
<tr><td>[[P11 Détecteur d'obstacles pour fauteuils électriques]]</td>
<td> Geoffrey ROSE / Marjorie TIXIER </td>
<td> GAPAS / Blaise Conrard </td>
<td> [[Fichier:Rapport_Intermédiaire_PFE_GAPAS_Rose_Tixier.pdf]]
<td></td>
</tr>
<tr><td>[[P12 Automatiser à l'aide d'une interface LabView la procédure de mesure de conductivité électrique d'un alternateur à griffes]]</td>
<td> Hugo FONDU </td>
<td> Abdelkader Benabou </td>
<td>[[Fichier:rapport_presoutenance.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P13 Construction d'un support motorisé pour la réalisation des essais de décharges électrostatique]]</td>
<td> JEBBARI Zineb / BEKRAOUI Oumaima </td>
<td> Nathalie Rolland </td>
<td> [[Fichier:rapportJebbek.pdf]] </td>
<td> [[Fichier:rapport-final-jebbek.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P19 Contrôle et synchronisation d'instruments en microscopie]]</td>
<td> Simon Duthoit</td>
<td> Samuel Hym </td>
<td></td>
<td>[[Fichier:RapportPFESimonDuthoit.pdf]]</td>
</tr>
<tr><td>[[P21 Balise Bluetooth Low Energy]]</td>
<td> Kévin CHALONO / Armagan YAMNAZ</td>
<td> Thomas VANTROYS </td>
<td> [[ Fichier:ProjetBLE 1 pdf.pdf]]</td>
<td>[[Fichier:Rapport_PFE_Yanmaz_Chalono2.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P21 Bis Prototypage d'interactions localisées et contextualisées ]]</td>
<td> Olivier Tailliez</td>
<td> Thomas Vantroys / Yvan Peter </td>
<td></td>
<td>[[Fichier: PFE_Olivier_Tailliez.pdf‎]]</td>
</tr>
<tr><td>[[P22 Google Glass en logistique ]]</td>
<td> Jérémy Gondry / Vincent Meunier </td>
<td> Laurent Grisoni </td>
<td>[[Fichier:Rapport_intermediaire_Gondry_Meunier.pdf]]</td>
<td>[[Fichier:Rapport_final_PFE_Meunier_Gondry.pdf]]</td>
</tr>
<tr><td>[[P24 Robot de surveillance domestique]]</td>
<td> Sébastien DELTOMBE </td>
<td> Xavier Redon </td>
<td>[[Fichier:Rapport_PFE_P24_Deltombe.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P25 SmartMeter]]</td>
<td> Thomas Ederlé / Sylvain Fossaert</td>
<td> Guillaume Renault / Xavier Redon / Alexandre Boé </td>
<td> [[Fichier:RapportFossaertEderle.pdf]] </td>
<td> [[Fichier:RapportEderleFossaert.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P26 Vehicule Electrique ]]</td>
<td> Smain Labdouni / Adnane Jaoui </td>
<td> Arnaud Chielens / Philippe Delarue </td>
<td> [[Fichier:RAPPORT_VE_DEC.pdf]]</td>
<td> [[Fichier:Rapport_pfe_Jaoui_Labdouni_Fevrier.pdf]] </td>
</tr>
<tr><td>[[P27 Controle Direct de Puissance d'un Convertisseur Matriciel ]]</td>
<td> Quentin Pesqueux / Nicolas Alexandre </td>
<td> Philippe Delarue </td>
<td> [[Fichier:PFE_IMA5_MATRIX_CONVERTER_Alexandre_Pesqueux.pdf]]</td>
<td> [[Fichier:Rapport_PFE_Alexandre_Pesqueux.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle]]</td>
<td> Charlotte BRICOUT / Nathan MARTIN </td>
<td> Jérémie DEQUIDT</td>
<td> [[Fichier:-BRICOUT MARTIN--Rapport PFE.pdf]] </td>
<td> [[Fichier:Rapport PFE VF.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P33 Ligthing contactless / "wireless"]]</td>
<td> Benjamin Lafit </td>
<td> Alexandre Boé </td>
<td> [[Fichier:Rapport_Benjamin_Lafit.pdf]] </td>
<td> [[Fichier:Rapport_Final_Benjamin_Lafit.pdf‎]]</td>
<td></td>
</tr>
<tr><td>[[P35 Hack-a-Wii : Emulation de wiimote pour rendre la Wii accessibles aux personnes handicapées ]]</td>
<td> Fabien Violier </td>
<td> Laurent Grisoni </td>
<td> </td>
<td></td>
</tr>
<tr><td>[[P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA ]]</td>
<td> Jérôme Vaessen </td>
<td> Julien Cartigny / Pierrick Buret </td>
<td> [[Fichier:Rapport_VAESSEN_presoutenance.pdf‎]] </td>
<td> [[Fichier:Rapport_PFE_P37_VAESSEN_finale.pdf‎]] </td>
<td></td>
</tr>
<tr><td>[[P44 Création d'un systeme domotique sans fil ]]</td>
<td> Benoit MALIAR / Thomas MAURICE</td>
<td> Pierrick BURET / Thomas VANTROYS </td>
<td> [[Fichier:RapportMaliarMauriceDecembre.pdf]] </td>
<td> [[Fichier:Rapport_final_Maliar_Maurice.pdf]]</td>
</tr>
<tr><td>[[P45 Aide à la navigation d'un véhicule autonome]]</td>
<td> Pierre APPERCÉ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
<td></td>
</tr>
<tr><td>[[P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens]]</td>
<td> Valentin VERGEZ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
<td></td>
</tr>
<tr><td>[[P57 CHRU Lille : Smart Picking]]</td>
<td> Mathieu Bossennec / Florian Caron</td>
<td> Gwénaëlle Maton / Alexandre Boé / Thomas Vantroys </td>
<td></td>
<td></td>
</tr>
<tr>
<td>[[P58 Transformation des spectateurs d’un concert en afficheur géant interactif]]</td>
<td> Hautecoeur Mélanie </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td>[[Fichier : PFE_Rapport_Hautecoeur_Melanie.pdf‎]]</td>
</tr>
<tr><td>[[P59 Assistance globale pour aide au parking]]</td>
<td> Mathieu GERIER / Céline LY </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td>[[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf]]‎</td>
<td>[[Fichier:Rapport_projet_GERIER_LY.pdf]]</td>
</tr>
</table>

Fichier:Rapport PFE VF.pdf

2015-02-24T12:12:17Z

Nmartin1 :

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T11:18:14Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 2600 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "palais" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone Ecoflex 00-30 dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer davantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, de distributeurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configuré pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur ne se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. La pièce est destinée à maintenir verticalement le robot et à le fixer au socle. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. Côté logiciel, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme (Voir figure ci-dessous). Le simulation n'est donc pas représentative du comportement du robot.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité. Notre robot admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée au clavier et elle est appliquée à chacune des cavités à tour de rôle toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

D'autre part, la pièce a été imprimée et nous obtenons le système suivant:

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû modifier le processus de fabrication pour que le remplissage se fasse plus rapidement.

Nous avons ensuite débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités sans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T11:13:13Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 2600 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "palais" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone Ecoflex 00-30 dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer davantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, de distributeurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configuré pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur ne se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. La pièce est destinée à maintenir verticalement le robot et à le fixer au socle. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. Côté logiciel, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme (Voir figure ci-dessous). Le simulation n'est donc pas représentative du comportement du robot.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité. Notre robot admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée au clavier et elle est appliquée à chacune des cavités à tour de rôle toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

D'autre part, la pièce a été imprimée et nous obtenons le système suivant:

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû modifier le processus de fabrication pour que le remplissage se fasse plus rapidement.
Pour palier aux problèmes d'étanchéité, nous avons boucher les deux extrémités du cylindre avec du silicone. Nous viendrons ensuite percer et introduire en force les câbles.

Nous avons ensuite débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités sans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T11:03:16Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 2600 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "palais" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone Ecoflex 00-30 dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer davantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, de distributeurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configuré pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur ne se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. La pièce est destinée à maintenir verticalement le robot et à le fixer au socle. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. Côté logiciel, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme (Voir figure ci-dessous). Le simulation n'est donc pas représentative du comportement du robot.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité. Notre robot admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée au clavier et elle est appliquée à chacune des cavités à tour de rôle toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

D'autre part, la pièce a été imprimée et nous obtenons le système suivant:

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T11:01:06Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 2600 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "palais" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone Ecoflex 00-30 dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer davantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, de distributeurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configuré pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur ne se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. La pièce est destinée à maintenir verticalement le robot et à le fixer au socle. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. Côté logiciel, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme (Voir figure ci-dessous). Le simulation n'est donc pas représentative du comportement du robot.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité. Notre robot admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée au clavier et elle est appliquée à chacune des cavités à tour de rôle toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T11:00:15Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 2600 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "palais" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer davantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, de distributeurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configuré pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur ne se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. La pièce est destinée à maintenir verticalement le robot et à le fixer au socle. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. Côté logiciel, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme (Voir figure ci-dessous). Le simulation n'est donc pas représentative du comportement du robot.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité. Notre robot admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée au clavier et elle est appliquée à chacune des cavités à tour de rôle toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T10:49:08Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 2600 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "palais" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer davantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, de distributeurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur ne se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. La pièce est destinée à maintenir verticalement le robot et à le fixer au socle. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. Côté logiciel, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme (Voir figure ci-dessous).

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T10:46:00Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 2600 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "palais" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer davantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, de distributeurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur ne se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T10:41:50Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 2600 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "palais" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer davantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, d'actionneurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T10:36:56Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 2600 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, d'actionneurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T10:32:22Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 2600 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, d'actionneurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T10:24:21Z

Nmartin1 : /* Ressources à disposition */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception Assistée par Ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter sur l'Arduino, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 3000 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, d'actionneurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T10:22:33Z

Nmartin1 : /* Ressources à disposition */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de natures différentes peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception assistée par ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 3000 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, d'actionneurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-20T10:21:10Z

Nmartin1 : /* Matériel à disposition */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

* Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

* Mettre en place une simulation SOFA

* Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

* Réaliser le contrôle pneumatique du prototype

* Mettre à jour le plug-in SOFA pour la communication série entre la simulation informatique et le prototype relié au dispositif de contrôle pneumatique

* Interfacer la simulation avec le prototype réel. C’est-à-dire permettre le contrôle du robot par le bais de la simulation informatique

* Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Ressources à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de nature différente peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception assistée par ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 3000 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, d'actionneurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

[[Fichier:Simu sofa.png|400px|thumb|center|Version finale de la simulation sur SOFA]]

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

==Conclusion==

Tous les objectifs du projet ont été atteints et nous avons pu présenter nos résultats au centre de recherche du King's College qui en est satisfait. Actuellement, nous sommes capables de commander un robot déformable, mis en mouvement par un dispositif pneumatique, par le biais d'une simulation informatique. On peut le commander directement par le biais de l'interface graphique de la plate-forme logicielle SOFA en utilisant le pointeur de la souris. On peut également définir une trajectoire qui sera lue au démarrage de la simulation.

Le projet va pouvoir évoluer avec un contrôle hydraulique qui se substituera à la commande pneumatique. Il sera nécessaire de revoir les proportions du prototype afin que celui-ci soit conforme aux dimensions d'un endoscope. Il faudra également changer sa composition pour permettre son utilisation en chirurgie non-invasive.

A travers ce projet, nous avons progressé en programmation C++ sur les logiciels Arduino et SOFA. De plus, nous avons appréhendé les grands principes de fonctionnement de la simulation numérique appliquée aux robots déformables. Nous avons également découvert le fonctionnement d'un dispositif de contrôle pneumatique et l'avons pris en main. Nous avons expérimenté plusieurs processus de fabrication de prototype en silicone. Enfin, nous avons progressé en Conception Assistée par Ordinateur en modélisant le prototype sur différents logiciels.

Ce projet est une belle opportunité pour travailler sur un projet conséquent, réparti dans le temps. Cela nous permet, par ailleurs, de sortir du cadre de Polytech Lille pour travailler dans une autre structure et d'être intégrés à une équipe.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-18T15:17:49Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

- Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

- Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

- Valider le modèle sur le robot développé au King's College de Londres

- Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Matériel à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de nature différente peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception assistée par ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 3000 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, d'actionneurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcul pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car une explication théorique sera disponible.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont très satisfaits de l'avancée coté Français.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-18T15:03:44Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

- Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

- Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

- Valider le modèle sur le robot développé au King's College de Londres

- Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Matériel à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de nature différente peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception assistée par ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 3000 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, d'actionneurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit OpenBeam Starter et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage. Actuellement, le robot modélisé se déforme pour atteindre un point sous le contrôle de la souris. L'objectif principal du projet est que le prototype réel subisse les mêmes déformations simultanément. Pour cela, nous devons engager une communication entre la simulation informatique et la carte arduino qui contrôle le dispositif pneumatique.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Nous avons débuté les tests en pression avec le prototype plus rigide. On a sensiblement augmenté la gamme de pression à injecter pour avoir une déformation conséquente du robot. Cependant, la déformation n'est pas optimale à cause des fuites, une fois que la pression injectée est grande. De ce fait, il nous faut concevoir une pièce qui limitera les fuites. Cette pièce sera conçue pour maintenir le câble d'injection dans les cavités dans pour autant les déformer. Il sera donc nécessaire de la concevoir très précisément en CAO.

Dans la simulation informatique SOFA, nous utilisons le plug-in "SoftRobot" qui permet notamment de contrôler le robot modélisé par injection d'air. Par ailleurs, le plug-in n'est pas configuré pour la communication série entre la simulation et une carte arduino pour le contrôle pneumatique. Jusqu'ici, l'envoi de données entre SOFA et Arduino était exploité pour le contrôle de servomoteur. De ce fait, nous avons mis à jour le plug-in afin que celui-ci permette l'échange de données dont nous avons besoin.

En parallèle, nous avons élaboré un nouveau programme arduino, chargé de la communication avec la plate-forme logicielle SOFA. Celui-ci établi la connexion série, traite les données issues de la simulation et les envoie au dispositif de contrôle.

'''Semaine 19'''

Nous avons commencé les tests liés à l'interfaçage. Dans un premier temps, nous avons constaté quelques problèmes dans les programmes du plug-in SoftRobot que nous avons modifié. Une fois les erreurs résolues, on constate que la communication série est fonctionnelle bien que certains paramètres de la simulation sont à ajuster :

*Le module de Young qui régit la rigidité du robot
*Le coefficient de Poisson qui permet de caractériser la contraction de la matière perpendiculairement à la direction de l'effort appliqué.
*Le coefficient d'ajustement des valeurs entre la simulation et le programme arduino

En ce qui concerne le module de Young, des essais mécaniques ont été réalisés sur le silicone Dragon Skin que nous avons utilisé. De ce fait, on connaît déjà le module de Young qui est de 150 000 Pa. Pour le coefficient de Poisson, on le fixe à 0.4 car au dessus de ce seuil, la simulation diverge et en dessous, on perd en précision. Enfin, il est nécessaire d'ajuster la simulation par rapport à la réalité. Une fois les coefficients précédents définis, on ajuste dans la scène SOFA, la pression maximale à injecter par rapport à celle relative au contrôle pneumatique. Ainsi, la déformation dans la simulation est fidèle à la déformation réelle du robot.

Au delà d'une certaine pression, les fuites deviennent trop importantes pour un contrôle précis du dispositif. De ce fait, nous avons réfléchi à plusieurs solutions pour maintenir les tuyaux dans le prototype. Après concertation, nous avons décidé de boucher les cavités avec un disque de silicone et d'insérer en force les tuyaux afin qu'ils restent bloqués.

Nous avons testé ce nouveau système d'étanchéité et les résultats sont satisfaisants. On peut injecter jusque deux fois la pression maximale déterminée auparavant.

'''Semaine 20'''

La déformation du prototype réel et du modèle de SOFA ne sont pas similaires. On remarque, en effet, que le modèle ne se courbe pas mais suit une déformation linéaire. Ce constat a mis en évidence le fait que le modèle ne possède pas suffisamment de sections et de points sur sa longueur pour se déformer correctement. Une fois ce problème résolu, la simulation est opérationnelle.

Nous devons réaliser une vidéo afin de l'envoyer au King's College. De ce fait, on décide de rédiger un script Shell qui décrit automatiquement une trajectoire pour le modèle. Ce script génère un fichier d'extension '.ws' qui sera automatiquement lu et exécuté lorsque la scène SOFA est jouée.

En parallèle, on débute l'étude de faisabilité pour la migration technologique de pneumatique à hydraulique.Après concertation avec l'équipe, nous décidons d'expliquer entièrement le processus de calcule pour le contrôle pneumatique et hydraulique ainsi que la différence entre les deux systèmes. Grace à notre rapport, la migration sera plus simple car il sera disponible une explication théorique.

La vidéo du dispositif en fonctionnement est appréciée des Anglais, ils sont contents de l'avancée coté Français.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-04T10:31:23Z

Nmartin1 : /* Matériel à disposition */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

- Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

- Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

- Valider le modèle sur le robot développé au King's College de Londres

- Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Matériel à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|left]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de nature différente peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|left]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|left]]

'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception assistée par ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|left]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 3000 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, d'actionneurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit X et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-02-04T10:28:26Z

Nmartin1 : /* Matériel à disposition */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

Rapport intermédiaire:
[[Fichier:-BRICOUT_MARTIN--Rapport_PFE.pdf]]

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

- Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

- Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

- Valider le modèle sur le robot développé au King's College de Londres

- Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Matériel à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|right]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de nature différente peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|100px|thumb|right]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

[[Fichier:Logo_gid.jpg|100px|thumb|left]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

[[Fichier:Logo_Avidemux.png|100px|thumb|right]]
'''Le logiciel Avidemux'''

Avidemux est un logiciel libre de montage vidéo linéaire, pour les systèmes d'exploitation GNU/Linux, MacOS X et Windows.

[[Fichier:Logo_Rhino.jpg|100px|thumb|left]]

'''Le logiciel Rhinocéros 3D'''

C'est un logiciel de Conception assistée par ordinateur utilisé par exemple dans le milieu du design industriel ou de de l'architecture.

[[Fichier:Logo_Arduino.png|100px|thumb|right]]

'''Le logiciel Arduino'''

Le logiciel Arduino est un environnement de développement permettant d'écrire, de compiler et de téléverser du code sur le microcontrôleur Arduino. Notre code peut alors s'exécuter, indépendamment d'un ordinateur.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

[[Fichier:Figures robot.JPG|400px|thumb|center|Publication du robot du King's College]]

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|200px|thumb|right|Coupe transversale du prototype]]
'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

[[Fichier:Profil_3000n.JPG|400px|thumb|center|Vue de profil à 3000 noeuds]]

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

'''Semaine 14'''

Nous avons finalisé notre prototype et il est actuellement fonctionnel. On commence alors à prendre en main le dispositif de contrôle pneumatique.
Celui-ci est constitué d'une carte arduino, d'une carte électronique, d'actionneurs et d'un compresseur pneumatique. Une fois les connexions établies entre les différents éléments de notre système, on connecte une poche en silicone pour débuter les tests en pression. On utilisera notre prototype une fois le programme arduino fonctionnel.

'''Semaine 15'''

Nous avons élaboré un programme arduino permettant d'envoyer une consigne de pression à une poche de silicone. Pour cela, nous sommes partis d'un programme existant non fonctionnel et nous l'avons retravaillé afin que l'erreur entre la consigne envoyée et la valeur appliquée soit la plus petite possible. Actuellement l'envoi est configurée pour fournir une unique consigne au lieu des trois désirées pour remplir les cavités. On constate également quelques oscillations à faible amplitude avant que la valeur se stabilise autour de la consigne.

'''Semaine 16'''

Nous avons conçu un socle pour maintenir notre prototype. Pour cela, nous avons utilisé un kit X et nous avons réalisé une pièce en Conception Assistée par Ordinateur sur le logiciel Rhinoceros 3D. Il nous reste à imprimer la pièce par le biais d'une imprimante 3D. En parallèle, nous avons retravaillé le script sur le logiciel Avidemux. A ce stade, la vidéo obtenue n'est pas satisfaisante. En effet, on constate que le gonflement des cavités n'est pas uniforme.

[[Fichier:simu_cylinder.png|300px|thumb|center|Vue en simulation du robot contrôlé par pression pneumatique]]

'''Semaine 17'''

Nous avons continué les tests en pression mais cette fois-ci sur le prototype directement. Pour le moment, on ne remplit que la première cavité et il nous faudra modifier le programme arduino afin d'envoyer une consigne sur chaque cavité à tour de rôle par exemple. Celui-ci admet une pression plus importante que les poches de silicone précédemment utilisées. On constate plusieurs fuite et nous allons devoir chercher des solutions pour les minimiser.
Nous avons fabriqué un second prototype en silicone selon le même mode de fabrication. Ce robot va nous permettre de réaliser une seconde série de tests en pression afin de vérifier que chaque prototype tolère la même pression maximum et suit le même comportement.

[[Fichier:Robot1.jpg|250px|thumb|center|Robot sur le socle]]

Nous avons connecté les 3 cavités du prototype à notre dispositif de contrôle. Ainsi, nous avons retravaillé notre programme arduino afin de gonfler une à une les cavités. Ainsi, on peut juger de l'étanchéité de chacune et obtenir un mouvement du prototype. La consigne est entrée dans le moniteur série d'arduino et elle est appliquée à une des cavités toutes les 2 secondes.

On constate que le silicone utilisé n'est pas adéquate car à chaque mouvement du prototype, celui-ci "rebondit". Le silicone est donc trop mou et il est nécessaire de fabriquer un prototype en silicone plus dur. Précédemment, nous avions utilisé du silicone Ecoflex 00-30 qui est particulièrement flexible. On va passer sur un prototype en silicone Dragon Skin A10.

On remarque également un retard dans le programme arduino. En effet, pour chaque consigne envoyée, la pression d'air appliquée croît graduellement et n'est donc pas instantanément appliquée. Ce problème peut être issu de la boucle de contrôle dans le programme ou à une mauvaise gestion des pas de temps.

'''Semaine 18'''

Après analyse, nous avons déterminé les problèmes du programme Arduino et commencé à implémenter des solutions. La régulation est actuellement faite sur la première cavité uniquement. De ce fait, lors de l'envoi de consigne sur les deux autres cavités, l'erreur est très importante. Nous devons retravailler le code pour créer une régulation standard sur les trois cavités. On souhaite également changer le programme pour que l'envoi de consigne soit fait par interruption. Pour cela, on va utiliser la librairie "MsTimer2.h".

En parallèle du contrôle pneumatique, nous travaillons sur la simulation. Celle-ci n'était pas jouée en temps réel à cause du trop grand nombre de noeuds qui composent le maillage du prototype. Pour palier à ce problème, nous avons réalisé en CAO sur le logiciel Rhinoceros 3D un prototype que l'on extrait en '.obj'. Ainsi, le maillage est réalisé automatiquement et il est donc moins précis. Afin d'éviter un maillage trop grossier des cavités, on les extrait en 'obj' séparément.

[[Fichier:Vue dessus perspective.JPG|750px|thumb|center|Vue de dessus et vue en perspective du prototype sur Rhino]]

Dans notre scène SOFA, on insère par conséquent 4 fichiers "objet" correspondants aux trois cavités et au prototype global. Finalement, on obtient une simulation temps réel adéquate pour la prochaine étape du projet : l'interfaçage.

[[Fichier:Simulation1.jpg|350px|thumb|center|Simulation Temps réel]]

Nous avons fabriqué un premier prototype en silicone Dragon Skin mais celui-ci étant très visqueux, nous ne sommes pas parvenus à combler tout le moule en moins de 45 minutes ce qui correspond au temps de séchage du silicone. Nous avons dû réitérer le processus de fabrication en injectant avec deux seringues à la fois pour que le remplissage se fasse plus rapidement. Nous avons ensuite couler par dessus du silicone afin de boucher les cavités pour que le prototype soit opérationnel pour les nouveaux tests en pression.

Fichier:Logo Avidemux.png

2015-02-04T10:21:02Z

Nmartin1 :

Fichier:Logo Arduino.png

2015-02-04T10:19:37Z

Nmartin1 :

Fichier:Logo Rhino.jpg

2015-02-04T10:09:50Z

Nmartin1 :

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-01-28T13:49:10Z

Nmartin1 : /* Journal de Bord */

Fichier:Simu cylinder.png

2015-01-28T13:48:34Z

Nmartin1 : a téléversé une nouvelle version de « Fichier:Simu cylinder.png » : Vue en simulation du robot contrôlé par pression pneumatique.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-01-28T09:46:16Z

Nmartin1 : /* Journal de Bord */

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-01-28T09:43:22Z

Nmartin1 : /* Journal de Bord */

Fichier:Simu cylinder.png

2015-01-28T09:42:01Z

Nmartin1 : a téléversé une nouvelle version de « Fichier:Simu cylinder.png » : Version du 28 janvier 2015 à 09:41 rétablie

Fichier:Simu cylinder.png

2015-01-28T09:41:43Z

Nmartin1 : a téléversé une nouvelle version de « Fichier:Simu cylinder.png »

Fichier:Simu cylinder.png

2015-01-28T09:41:00Z

Nmartin1 :

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2015-01-28T09:39:36Z

Nmartin1 : /* Journal de Bord */

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2014-12-15T09:49:45Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

- Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

- Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

- Valider le modèle sur le robot développé au King's College de Londres

- Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Matériel à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|right]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de nature différente peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|50px|thumb|right]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.[[Fichier:Logo_gid.jpg|50px|thumb|right]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|150px|thumb|right|Coupe transversale du prototype]]
[[Fichier:Profil_3000n.JPG|150px|thumb|right|Vue de profil à 3000 noeuds]]

'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot. Pour cela, nous utilisons le logiciel Avidemux qui est un logiciel libre disponible sous Ubuntu. Nous avions dans un premier temps essayé différents scripts shell mais nous avons rencontré différents problèmes quant aux formats des images ou à leurs tailles.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2014-12-15T09:44:56Z

Nmartin1 : /* Journal de Bord */

[[Fichier:Logo_polytech.jpg‎‎|200px|thumb|right]]

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

==Contexte du projet de fin d'études==
[[Fichier:Logo_inria.jpg‎‎|180px|thumb|left]]

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

- Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

- Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

- Valider le modèle sur le robot développé au King's College de Londres

- Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Matériel à disposition==
[[Fichier:Logo_sofa.png‎|150px|thumb|right]]
'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de nature différente peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.[[Fichier:Logo_blender.png|50px|thumb|right]]

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.[[Fichier:Logo_gid.jpg|50px|thumb|right]]

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope. Dans un premier temps, nous concevons un modèle aux dimensions indiquées dans une publication de l'équipe. Blender nous fournira un rendu 3D de l'endoscope et nous réaliserons le maillage du prototype avec le logiciel SOFA.

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Mailler une forme conçue par Conception Assistée par Ordinateur (CAO) signifie la modéliser géométriquement par des éléments finis tels que des tétraèdres dans notre cas.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID. L'avantage de ce logiciel est qu'il propose non seulement une modélisation du prototype mais aussi son maillage.

'''Semaine 3'''

Sur GID, on modélise le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins important qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème qu'avec Blender. De ce fait, nous décidons de doubler les dimensions du prototype afin d'obtenir des cavités plus grandes et de soumettre le résultat à l'équipe du King's College.

Le prochain objectif est donc de prendre contact avec eux pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

[[Fichier:Vue_coupe.JPG‎‎|150px|thumb|right|Coupe transversale du prototype]]
[[Fichier:Profil_3000n.JPG|150px|thumb|right|Vue de profil à 3000 noeuds]]

'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Les dimensions retenues sont donc deux fois plus grandes que celles initialement prévues. Les cavités ont donc un diamètre de 3 mm pour une longueur de 100 mm. Le robot mesurera 110 mm et aura un diamètre extérieur de 34 mm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (entre 2000 et 3000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 10000 et 11000 noeuds) et obtenir un modèle réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

A la fin de cette semaine, nous avons conçu un premier modèle à 2600 noeuds.

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé. Actuellement, la convergence est imparfaite.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot. En parallèle, nous élaborons plusieurs modèles FEM afin de trouver le bon compromis entre le nombre de noeuds qui ne doit pas être trop important pour que le prototype soit fonctionnel et la géométrie qui doit restée fidèle à celle fixée auparavant.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. En effet, nous devons réaliser un moule aux dimensions précises afin de couler le silicone.

'''Semaine 11'''

Nous avons à présent acheté le matériel et avons élaborer une stratégie de fabrication du moule. Pour cela, nous avons acheté:

- 6 tiges filetées pour créer des cavités

- 1 tube en PVC d'un diamètre intérieur de 34 mm pour donner une forme cylindrique au prototype

- 1 tube en cuivre d'un diamètre extérieur de 16 mm pour creuser la géométrie

L'extrémité basse du robot sera fixée sur une plaque de PVC et la haute, sur une plaque de plexiglas afin de contrôler le remplissage. Les tiges filetées seront fixées à l'aide de boulons sur chaque extrémité. Le tube de cuivre sera rentré en force dans chaque place et sera ainsi immobile lors de la phase de coulage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

[[Fichier:Profil_10000n.JPG|150px|thumb|right|Vue de profil du prototype à 10 000 noeuds]]
[[Fichier:Face_10000n.JPG|150px|thumb|right|Coupe transversale]]
'''Semaine 12'''

Nous avons conçu le moule et avons coulé du silicone "Dragon Skin" dans celui-ci. Nous avons laissé sécher environ 3 heures avant de démouler.
En parallèle, nous avons terminé les différents modèles en CAO et les soumettons à validation avant de faire l'implantation en simulation du modèle retenu.

Nous avons démoulé notre premier prototype physique mais nous constatons que les cavités ne sont pas parallèles entre elles. De ce fait, il est nécessaire de réitérer le processus de fabrication et de fixer d'avantage les extrémités afin que celles-ci n'aient aucun degré de liberté. Ainsi, le nouveau prototype devrait être opérationnel.

'''Semaine 13'''

Nous avons crée une seconde scène SOFA qui intègre le modèle à 10 000 nœuds. Etant donné que celui-ci est particulièrement précis, il nous est impossible d'utiliser SOFA en temps réel pour évaluer les besoins en pression. De ce fait, nous devons programmer un enchaînement de mouvements qui seront exécutés par notre robot. Nous pourrons ainsi réaliser une série captures "step by step" de la position du robot sous SOFA. Enfin, nous réaliserons une vidéo qui récupérera toutes les images et qui reconstituera de manière fluide la trajectoire qu'aura pris le robot.

En parallèle, nous entamons un second cycle de fabrication en réutilisant le moule. Nous avons en effet améliorer le processus de coulage du silicone par rapport au premier essai.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2014-12-03T13:21:32Z

Nmartin1 : /* Journal de Bord */

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

==Contexte du projet de fin d'études==

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

- Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

- Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

- Valider le modèle sur le robot développé au King's College de Londres

- Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Matériel à disposition==

'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de nature différente peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope.

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Obtenir un maillage d'une forme conçu par CAO, signifie diviser cette forme en plusieurs autres formes (généralement des triangles ou des tétraèdres). Le but est de mettre en mouvement le tout, ce qui est impossible avec un objet plein.
Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé (trop grande imprécision). Après plusieurs tentatives de maillage vaines issues de Blender, nous avons décidé de travailler avec le logiciel GID.

'''Semaine 3'''

Sur GID, il est nécessaire de modéliser à nouveau le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins importants qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs. Nous nous retrouvons donc en face du même problème.

Le prochain objectif est donc de prendre contact avec l'équipe du King's College pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Par ailleurs, nous avons décidé de multiplier par deux les dimensions du robot afin de faciliter la conception du prototype physique. En effet, le diamètre du robot cylindrique n'est que de 16 mm et sa longueur est de 10 cm.

A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle allégé (environ 2000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

- un modèle précis pour évaluer les besoins en pression (entre 5000 et 6000 noeuds) et obtenir une simulation réaliste

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant. Ce fichier scène nous permet par exemple de régler la rigidité du silicone, ou encore de définir le remplissage des cavités.

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on crée quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot dans notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. Nous concevons également la maquette de coulage du robot. Il faut en effet pouvoir couler le silicone, le faire sécher et le démouler pour obtenir notre robot.

'''Semaine 11'''

Le matériel est maintenant acheté et la maquette pour réaliser le robot conçue. Nous prévoyons d'utiliser un tuyau en PVC de diamètre intérieur 34 cm, 6 tiges filetées pour créer les cavités, un tube en cuivre pour creuser le cylindre. Le tout fixé entre deux planches de bois. Les différents tubes seront ainsi immobiles lors de la phase de coulage et de séchage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

'''Semaine 12'''

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2014-11-26T14:37:06Z

Nmartin1 : /* Journal de Bord */

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2014-11-26T14:17:01Z

Nmartin1 : /* Journal de Bord */

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

==Contexte du projet de fin d'études==

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

- Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

- Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

- Valider le modèle sur le robot développé au King's College de Londres

- Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Matériel à disposition==

'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de nature différente peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope.

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé. Après plusieurs tentatives de maillage vaines avec SOFA, nous avons décidé de travailler avec le logiciel GID.

'''Semaine 3'''

Sur GID, il est nécessaire de modéliser à nouveau le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins importants qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs.

Le prochain objectif est de prendre contact avec l'équipe du King's College pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Par ailleurs, nous avons décidé de multiplier par deux les dimensions du robot afin de faciliter la conception du prototype physique. En effet, le diamètre du robot cylindrique est de 16 mm et sa longueur est de 10 cm.
A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle précis pour évaluer les besoins en pression (entre 5000 et 6000 noeuds)

- un modèle allégé (environ 2000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant.

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on créé quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot de notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''

Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot.

'''Semaine 10'''

Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. Nous concevons également la maquette de coulage du robot. Il faut en effet pouvoir couler le silicone, le faire sécher et le démouler pour obtenir notre robot.

'''Semaine 11'''

Le matériel est maintenant acheté et la maquette pour réaliser le robot conçue. Nous prévoyons d'utiliser un tuyau en PVC de diamètre intérieur 34 cm, 6 tiges filetées pour créer les cavités, un tube en cuivre pour creuser le cylindre. Le tout fixé entre deux planches de bois. Les différents tubes seront ainsi immobiles lors de la phase de coulage et de séchage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2014-11-26T14:16:21Z

Nmartin1 : /* Journal de Bord */

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

==Contexte du projet de fin d'études==

Dans le cadre d'un projet commun avec le King's College de Londres, l'équipe Shacra de l'INRIA de Lille va travailler pendant 2 ans sur un projet de robot déformable. L'objectif est de contrôler des robots non-rigides qui pourraient faire progresser la chirurgie non invasive. A terme, le laboratoire envisage de créer un endoscope pneumatique. Actuellement, les robots sont de types pneumatiques et le contrôle est effectué en emplissant ou vidant des volumes d'air. Le projet pourrait évoluer avec un contrôle hydraulique qui serait plus précis grâce à une mesure de l'eau injectée dans les cavités.

==Description des missions à réaliser==

Les objectifs du projet sont :

- Développer un modèle FEM (Finite Element Method) du robot sur la plateforme logicielle SOFA

- Faire un prototype pneumatique simplifié de l'endoscope afin de valider le contrôle du robot par le biais d'une simulation informatique. Pour mener à bien le projet, une partie de contrôle bas-niveau des régulateurs de pression sera nécessaire

- Valider le modèle sur le robot développé au King's College de Londres

- Faire une étude de faisabilité pour passer de la technologie pneumatique à hydraulique

==Matériel à disposition==

'''Le logiciel SOFA'''

SOFA est une plate-forme de recherche et développement dédiée aux simulations physiques interactives et en particulier à la simulation médicale. La plate-forme regroupe de nombreux algorithmes issus de domaines de recherche variés. Des modèles de nature différente peuvent être combinés de façon à produire des simulations complexes qui restent compatibles avec des temps de calcul optimaux.

'''Le logiciel Blender'''

Blender est un logiciel libre de modélisation, d’animation et de rendu en 3D. Il dispose de fonctions avancées de modélisation, de sculpture 3D, de texturage, d’animation 3D et de rendu. Le logiciel prend en charge diverses simulations physiques telles que les particules, les corps rigides, les corps souples et les fluides.

'''Le logiciel GID'''

GID est un logiciel adaptatif universel pré et post-processeur pour les simulations numériques. Il a été conçu pour couvrir tous les besoins en simulation numérique de pré à post-traitement: modélisation géométrique, définition efficace des données d'analyse, maillage, transfert de données à un logiciel d'analyse et visualisation des résultats numériques.

==Journal de Bord==

'''Semaine 1'''

Pour démarrer notre projet, nous avons commencé par élaborer un environnement de travail complet:

- Pour travailler depuis Polytech : Installation sur nos machines personnelles des logiciels Blender et SOFA

- Pour travailler depuis l'INRIA : Etablissement d'une convention et obtention des accès au bâtiment du laboratoire

Lors de la première séance complète, nous avons pris en main Blender. Ce logiciel va nous permettre de modéliser un prototype simplifié de l'endoscope.

'''Semaine 2'''

Une fois le robot entièrement modélisé sur Blender, on génère un modèle sous le format ".obj" afin d'effectuer le maillage. Le prototype modélisé sous Blender contient des cavités très fines rendant le processus de maillage impossible sur le logiciel SOFA. Le nombre de nœuds du prototype est trop important et nos machines ne supportent pas les calculs. Un nombre de tétraèdres moins important ne fait pas apparaître les cavités sur le prototype maillé. Après plusieurs tentatives de maillage vaines avec SOFA, nous avons décidé de travailler avec le logiciel GID.

'''Semaine 3'''

Sur GID, il est nécessaire de modéliser à nouveau le prototype du robot. Une fois le modèle terminé, nous réalisons un maillage avec un nombre de nœuds moins importants qu'auparavant mais le prototype n'est pas maillé correctement. Si l'on augmente le nombre de nœuds et par conséquent, le nombre de tétraèdres, le logiciel ne supporte pas les calculs.

Le prochain objectif est de prendre contact avec l'équipe du King's College pour connaître les possibilités de modification du prototype qui permettraient un maillage correct du modèle.

'''Semaine 4'''

Après discussion avec le King's college, notre modèle est validé. Par ailleurs, nous avons décidé de multiplier par deux les dimensions du robot afin de faciliter la conception du prototype physique. En effet, le diamètre du robot cylindrique est de 16 mm et sa longueur est de 10 cm.
A présent, notre travail se scinde en deux parties.

La première partie consiste à modéliser deux prototypes sur GID avec des nombres d'éléments différents:

- un modèle précis pour évaluer les besoins en pression (entre 5000 et 6000 noeuds)

- un modèle allégé (environ 2000 nœuds) pour que la simulation avec SOFA soit fluide et temps réel

La seconde partie consiste à mettre en simulation le prototype exporté de GID au format ".msh". Ce fichier mesh contient les coordonnées des points et les éléments de l'objet maillé. A partir de ce mesh, on cherche à générer un fichier au format ".xml" afin que les données contenues dans le mesh soient exploitables dans une scène Sofa. Pour ce faire, on utilise un script existant qui génère le fichier souhaité. Enfin, on rédige un fichier ".scn" qui va permettre de mettre en mouvement le prototype modélisé auparavant.

'''Semaine 5'''

On souhaite valider notre modèle avec la technologie pneumatique. Pour ce faire, il est nécessaire de contrôler le prototype dans Sofa en pneumatique. Pour cela, on utilise le plug-in de Sofa SoftRobots. Sur notre modèle, on dessine des "BoxROI" qui sont des boîtes permettant de sélectionner les tétraèdres d'un volume. Ici, on créé quatre "BoxROI": une boîte permettant de fixer la base du robot déformable et trois boîtes pour sélectionner une cavité sur deux de notre modèle. En effet, il n'y aura que trois cavités sur les six de contrôlées. Une fois les tétraèdres des cavités sélectionnées par le biais des BoxROI, on récupère tous les triangles qui composent les cavités. Cette opération permet de sélectionner la surface au lieu du volume et nous permettra le contrôle par pression leur remplissage. Maintenant, il est nécessaire de fixer un point que l'on nommera "Goal" et un second point nommé "Effector". "Goal" est le point que va suivre le modèle."Effector" est un point du modèle qui cherchera à converger vers le "Goal". Une fois ces deux points définis, il nous reste à tester différentes pressions pour connaître la tolérance de notre système ainsi que plusieurs valeurs du module de Young pour avoir la rigidité souhaitée. Après plusieurs tests, on retiendra une pression maximale de 2MPa et un module de Young de 18MPa.

'''Semaine 6'''

Durant cette séance, nous avons rendu notre code fonctionnel en essayant de mettre en mouvement le robot de notre scène. Celui-ci a un mouvement correct s'il parvient à converger vers le point demandé.

'''Semaine 7 & 8'''

Pas de séance de projet allouée.

'''Semaine 9'''
Cette semaine, nous reprenons en main la scène SOFA afin de mettre en mouvement le robot.

'''Semaine 10'''
Nous parvenons maintenant à simuler notre robot cylindrique en temps réel. Lorsque le "Goal" se déplace, notre robot va, par injection d'air dans ses cavités, essayer d'atteindre le point "Goal" avec son centre outil ("Effector").

D'un autre côté, nous entamons les réflexions quant à la réalisation matérielle du robot. Nous concevons également la maquette de coulage du robot. Il faut en effet pouvoir couler le silicone, le faire sécher et le démouler pour obtenir notre robot.

'''Semaine 11'''
Le matériel est maintenant acheté et la maquette pour réaliser le robot conçue. Nous prévoyons d'utiliser un tuyau en PVC de diamètre intérieur 34cm, 6 tiges filetées pour créer les cavités, un tube en cuivre pour creuser le cylindre. Le tout fixé entre deux planches de bois. Les différents tubes seront ainsi immobiles lors de la phase de coulage et de séchage. Un "chapeau" en silicone sera ensuite coulé et soudé à une extrémité du robot pour assurer l'étanchéité des cavités.

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2014-09-28T19:20:04Z

Nmartin1 :

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs à Polytech Lille

Projet de Fin d'Etudes (PFE)

==Journal de Bord==

'''Semaine 1'''

Nous avons réglé les problèmes dits logistiques:

- Installation des logiciels nécessaires au travail sur machines personnelles - Blender, SOFA

- Rédaction des conventions et obtentions des accès au laboratoire

Prise en main de Blender afin de modéliser une première version du robot déformable cylindrique.

'''Semaine 2'''

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2014-09-28T19:19:17Z

Nmartin1 :

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs

Projet de Fin d'Etudes (PFE)

==Journal de Bord==

'''Semaine 1'''

Nous avons réglé les problèmes dits logistiques:

- Installation des logiciels nécessaires au travail sur machines personnelles - Blender, SOFA

- Rédaction des conventions et obtentions des accès au laboratoire

Prise en main de Blender afin de modéliser une première version du robot déformable cylindrique.

'''Semaine 2'''

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2014-09-28T19:17:53Z

Nmartin1 :

Charlotte BRICOUT & Nathan MARTIN

Élèves Ingénieurs

Projet de Fin d'Etudes (PFE)

==Journal de Bord==

'''Semaine 1'''

Nous avons réglé les problèmes dits logistiques:
- Installation des logiciels nécessaires au travail sur machines personnelles - Blender, SOFA
- Rédaction des conventions et obtentions des accès au laboratoire

Prise en main de Blender afin de modéliser une première version du robot déformable cylindrique.

'''Semaine 2'''

P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle

2014-09-28T19:10:10Z

Nmartin1 : Page créée avec « Charlotte BRICOUT & Nathan MARTIN Elèves Ingénieurs Projet de Fin d'Etudes (PFE) »

Charlotte BRICOUT & Nathan MARTIN
Elèves Ingénieurs
Projet de Fin d'Etudes (PFE)

Projets IMA5 2014/2015

2014-09-28T19:05:30Z

Nmartin1 : /* Répartition des binômes */

Projets IMA5 2014/2015

2014-09-28T19:03:07Z

Nmartin1 : /* Répartition des binômes */

Guidage et Surveillance d'un véhicule à travers un Cockpit de conduite

2014-04-19T09:34:55Z

Nmartin1 :

Charlotte BRICOUT

Nathan MARTIN

IMA4 - Polytech Lille

Dans le cadre de la quatrième année au sein de la spécialité Informatique-Microélectronique-Automatique à Polytech Lille, nous allons réaliser un projet permettant de piloter et surveiller un véhicule autonome à travers un cockpit de conduite. Ce projet est dans la continuité du projet européen InTraDE (Intelligent Transportation for Dynamic Environment), consistant au transport autonome d'un fret. Notre projet sera encadré par Rochdi MERZOUKI et Xavier REDON.

[[Fichier:Rob.jpg|400px|thumb|center|Véhicule Robucar]]

'''Résumé du projet:'''

Nous souhaitons relier le cockpit de conduite de Polytech Lille à un véhicule autonome Robucar. Le cockpit qui fonctionne sous le logiciel de simulation temps réel SCANeR Studio, communiquera directement en WiFi avec le Robucar. Tout d'abord, nous modéliserons le parking de Polytech Lille sur le logiciel SCANeR Studio afin de créer un environnement pour la simulation. Ensuite, nous élaborerons un scénario dans lequel nous intégrerons un véhicule de type Robucar, pouvant être piloté par une API (Application Programming Interface) que nous programmerons sur le PC supervision du cockpit de conduite.
L'objectif de ce projet est de récupérer la vitesse et l'angle de braquage des roues du Robucar et de les envoyer au PC Supervision où ils seront récupérés par une API. L’envoie de ces consignes se fera par le biais d’un serveur UDP. L’API, constituant un client pour le serveur, prendra en charge l'application des consignes reçues au cockpit de conduite et au modèle dynamique Robucar de la simulation.
De ce fait, nous verrons évoluer le Robucar en temps réel dans la simulation et simultanément, le volant du cockpit suivra les mouvements du véhicule réel. L'utilisateur pourra ainsi suivre le déplacement de la Robucar dans la simulation et observer, parallèlement, les mouvements
du volant dans le cockpit. Cette application est utile pour la surveillance mais aussi pour le guidage d’un véhicule.

[[Fichier:resume.PNG|900px|thumb|center|Schéma de principe]]

== Matériel à disposition ==
[[Fichier:Cockpit.jpg|170px|thumb|right|Cockpit de conduite]]

Pour notre projet nous avons à disposition:

- un véhicule Robucar muni d'un PC intégré et d'une carte d'acquisition DSPACE (en C002)

- les logiciels permettant sa conduite, à savoir Matlab, Simulink et Control Desk

- un PC supervision (en C002)

- un Cockpit de simulation (en C002)

- un Accès au logiciel de simulation SCANeR Studio (en C002)

Nous travaillerons sur le logiciel de développement Microsoft Visual Studio 2005 pour programmer le serveur et l'API.

== Description des outils à disposition ==

[[Fichier:scaner.png|370px|thumb|right|Logiciel de simulation Temps Réel SCANeR Studio]]

===SCANeR Studio: Logiciel de simulation pour la recherche et l'ingénierie===

SCANeR Studio est un logiciel de simulation de conduite automobile Temps Réel offrant à ses utilisateurs une interface de surveillance ou
de contrôle d'un véhicule (voiture, poids lourd, cycliste, 2 roues etc).
Il permet la représentation d'un environnement, modélisé en 3D dans le logiciel, auquel un ou plusieurs véhicules sont intégrés.
Les véhicules simulés sont de différents types et on s'intéressera pour notre application aux véhicules "simples" et "Advanced".

Selon leur type, les véhicules sont contrôlés par différentes API dans SCANeR Studio:

- automatiquement par la simulation : API TRAFFIC, c'est le cas des véhicules de type simple.

- à l'aide d'un élément extérieur tel qu'un cockpit de simulation ou un véhicule réel : API Modelhandler, c'est le cas des véhicules de type Advanced.

Le logiciel comporte 5 modes permettant de réaliser une simulation:

- Terrain : permet de modéliser un environnement

- Véhicule : permet de sélectionner, de créer ou d’importer un véhicule dans la simulation

- Scénario : permet d’établir un scénario avec un Terrain et des Véhicules et de choisir les API

- Simulation : permet de simuler le Scénario en Temps réel

- Analyse : permet de récupérer des données de la simulation

Pour réaliser notre simulation, nous commençons par créer un terrain représentant le parking de Polytech Lille. C'est dans le mode
scénario que nous choisissons les véhicules à intégrer à la simulation. Ici, nous avons intégré un véhicule Robucar (de type véhicule "Advanced") et on intègre éventuellement des véhicules simples. Dans le mode simulation, nous choisissons les API qui seront actives.
Ici, les API indispensables sont "Modelhandler" et l'API que nous avons développé pour lire les consignes envoyées par le serveur et
les appliquer dans la simulation. Les deux API vont s'échanger des données par le biais de canaux : les Export Channels. Notre API
enverra donc une consigne de vitesse et d'angle de braquage des roues sur des Export Channels, définis par un nom ou un numéro, afin
que ModelHandler puissent lire ces informations.

===Le véhicule ROBUCAR===
[[Fichier:robucar.jpg|290px|thumb|right|Véhicule Robucar]]

Le Robucar est un véhicule automatique "intelligent", autonome et électrique, commercialisé par la société ROBOSOFT. Il est composé d'un châssis à quatre roues motrices et directionnelles pilotables séparément.
Il y a donc deux paramètres de commande pour chaque roue : l'orientation et la vitesse de rotation). Le véhicule est équipé d'un ordinateur de bord et d'une carte d'acquisition Temps Réel DSPACE qui récupère les données du véhicule. L'accès à ces données sur d'ordinateur intégré est rendu possible par la librairie CLIB. Celle-ci permet, en effet, de récupérer les données acquise par la DSPACE.

Dans le cadre de notre projet, nous considérons que seules les roues avant du véhicule sont directionnelles. Nous appliquerons donc la même consigne de vitesse et de braquage aux deux roues avant.

===Création d'un Serveur UDP===

Pour créer une communication entre le PC supervision et le PC intégré au Robucar, nous avons choisi de créer un serveur UDP. Nous avons préféré ce protocole au TCP car il est plus rapide et la perte de quelques paquets n'est pas gênante pour notre application. C'est donc sur l'aspect temps réel de la simulation que nous souhaitons mettre l'accent. Le serveur est implémenté en langage C++ sur Windows grâce à la bibliothèque Windows Sockets 2 (« Winsock2 »).
Le RobuCar est piloté avec un programme Matlab et son programme Simulink correspondant. On charge dans le logiciel dSPACE ControlDesk du Robucar le programme de pilotage correspondant à celui sur MATLAB. Une interface apparaît et nous pouvons alors accès à un poste de pilotage pour diriger le véhicule (cf figure ci-dessous). Lors de la conduite, des valeurs de consignes de la vitesse moyenne et l’angle de braquage
des roues sont récupérées par le serveur grâce à la bibliothèque «clib32». Le serveur implémente une structure de données contenant les deux valeurs et forme avec celles-ci un paquet à envoyer au client. Sur le PC supervision, l'API Client se connecte au serveur et reçoit alors des paquets contenant les consignes de vitesse et de braquage.

[[Fichier:pilotage.PNG|500px|thumb|center|Poste de pilotage sur dSPACE ControlDesk]]

==Journal de bord==

===Semaine 1===
[[Fichier:Parking.png|300px|thumb|right|Parking Polytech Lille modélisé]]

Lors de cette première séance, nous avons pris en main le logiciel SCANeR Studio et notamment le mode terrain qui permet de concevoir un environnement de simulation.
De ce fait, nous avons débuté la conception du parking de Polytech Lille sur le logiciel. Pour créer des routes identiques à celles du parking,
on utilise une image satellite de celui-ci et on calque les routes créées sur la photo. Pour chacune des routes, on définit le sens de circulation et le mode de priorité.

===Semaine 2===

Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio. Pour le tester, nous créons un scénario mettant en scène plusieurs véhicules de type "simple" qui sont pilotés automatiquement par le logiciel grâce à l'API Traffic. Nous lançons ainsi la simulation
et observons le comportement des véhicules sur les routes que nous avons conçu pour s'assurer du bon paramétrage de chacune des parcelles de routes.

Résultats des simulations sur le terrain:

- Dans certains virages et dans le rond point à l'entrée du parking, le comportement des véhicules en mode automatique est anormal

- Les véhicules se comportent normalement sur les lignes droites, aux Cédez-le-passage et dans les virages à 90 degrés.

Les virages étaient modélisés en "Polyline" ce qui est compliqué à traiter d'un point de vue logiciel. Nous avons dû re-modéliser plusieurs virages en prenant des sections de route plus simples.
Ainsi, les défauts de trajectoire des véhicules sont corrigés. Le parking est opérationnel pour l'élaboration de notre scénario futur.

===Semaine 3===

La prochaine étape est la conception de deux programmes: un serveur UDP qui sera lancé sur le PC du Robucar et une API client, lancé sur le PC
supervision. Nous commençons à nous auto-former sur la conception d'une API sous SCANeR Studio en prenant connaissance de la documentation disponible. Pour débuter, nous décidons de réaliser une API simple qui affiche la vitesse d'un véhicule de type "simple". On débute alors la
conception de cette API.

En première partie de séance, nous nous entretenons avec le doctorant Vincent Coelen pour faire un point sur les API. On évoquera entre autre les points suivants:

- comprendre l'utilisation des canaux (EXPORT CHANNEL)

- mettre à disposition la documentation nécessaire pour les utiliser

- comment transformer un projet C++ en une API qui évoluera dans le logiciel

Nous nous entretenons également avec M. Merzouki pour définir plus précisément le cahier des charges. Les points abordés sont les suivants:

- Programmation d'un Serveur UDP sur l'ordinateur intégré au Robucar pour communiquer en WIFI avec une API Client

- Programmation d'une API Client à implanter sur le logiciel SCANeR du PC Supervision

- Conception d'une seconde API permettant d'envoyer des consignes de vitesse et de braquage dans la simulation

- Fusion de ces deux dernières API

Ensuite, nous commençons à prendre en main l'utilisation des sockets en C++ pour le serveur UDP et l'API Client. Nous utiliserons les sources suivantes:

[http://www.frameip.com/entete-udp/ Frampeip: Serveur en mode non connecté]

[http://rex.plil.fr/Enseignement/Reseau/Reseau.IMA4sc/reseau.html Cours IMASC : Programmation Réseau]

[http://www.linux-france.org/prj/edu/archinet/systeme/index_monopage.html Linux: Tutoriel sur les Serveurs]

===Semaine 4===

Nous commençons à nous focaliser sur le fonctionnement du Robucar. Vincent Coelen nous explique comment fonctionne la DSPACE et comment utiliser un programme MATLAB pour récupérer des données du véhicule tels que la vitesse, l'angle de braquage, la position de la boîte de vitesse etc. On découvre aussi le fonctionnement du Cockpit en utilisant une API déjà fonctionnelle permettant d'envoyer des commandes
à celui-ci depuis la simulation. L'API Cockpit est implantée sur le logiciel SCANeR du PC Supervision. Nous utiliserons cette API par la suite
car notre API enverra les consignes de vitesse et d'angle braquage à ModelHandler et l'API Cockpit lira ces valeurs par le biais des Export Channels sur ModelHandler.

Nous continuons la programmation du serveur UDP et de l'API Client et nous réalisons les premiers tests du serveur:

- On met le PC Supervision et le PC du Robucar sur le même réseau

- On essaie de se "pinger" l'un l'autre pour vérifier la connexion entre les deux ordinateurs: la connexion est ouverte

Problème rencontré:

Les codes du serveur et du client ne compilent pas car il manque des librairies. Nous renseignons les librairies manquantes et corrigeons les erreurs de compilation.

===Semaine 5 ===

Nous réorganisons les codes du serveur et du client avec l'aide de M. Redon. Le serveur et l'API Client ne fonctionnent actuellement pas.
Afin d'accéder aux données de la DSPACE, il nous faut utiliser un Parser, programmé par un doctorant ayant travaillé sur le Robucar auparavant. Ce parser prend en paramètre les noms des variables dans le programme Simulink et nous renvoie leur nom système correspondant, exploitable en C++. Pour cela, il faut indiquer au parser le chemin (path) et le nom exact des variables dans Simulink. Dans le serveur UDP, on récupère donc
grâce à la librairie Clib les valeurs de la vitesse et l'angle de braquage des roues du Robucar.

Après une série de débogages, le serveur UDP est fonctionnel. Les échanges de paquets entre les deux PC connectés se font rapidement. Grâce à un compteur dans le programme du Serveur, on constate que beaucoup de paquets sont perdus mais ceci ne devrait pas poser trop de problèmes dans
la simulation, dans la mesure ou le débit d'émission de paquets est rapide.

===Semaine 6===

On débute la programmation de la seconde API permettant d'envoyer des données à la simulation. Pour ce faire, on doit prendre en main l'écriture sur les EXPORT CHANNELS.
En effet, ils permettent d'échanger des informations entre les différentes API. Ici, on cherche à échanger des données entre notre API et
l'API ModelHandler qui pilote le modèle Robucar dans la simulation. On va donc renseigner les cases mémoires de la vitesse et de l'angle de braquage des roues dans lesquelles Modelhandler lis ces informations pour les envoyer sur le modèle de la simulation.

===Semaine 7===

On continue et termine rapidement la programmation de l'API. On réalise les premiers tests de celle-ci dans Scaner Studio. Pour ce faire, on charge notre terrain (parking de Polytech Lille), on ajoute un scénario qui dans notre cas est l'ajout d'un véhicule de type Advanced piloté par Modelhandler. On ajoute ensuite une API en utilisant le fichier .exe généré par notre projet sur Visual Studio. Enfin, on sélectionne notre API et l'API ModelHandler dans le mode simulation.

[[Fichier:api.PNG|900px|thumb|center|Sélection des API]]

Problèmes rencontrés:

- Problème dans les héritages des dépendances supplémentaires du projet dans Microsoft Visual Studio: on doit ajouter certaines librairies supplémentaires

- l'API bloque la simulation bien qu'elle compile correctement indépendamment de la simulation. A première vue, ce problème serait dû à une
erreur de segmentation.

===Semaine 8===

L'API envoyant des données fixes à SCANeR Studio est fonctionnelle.

Les problèmes résolus sont :

- Le format d'envoi des consignes de vitesse et de braquage n'était pas correct (Float au lieu de Double). Cette erreur de format occasionnait
une erreur de segmentation

- Il est nécessaire de démarrer le moteur en fixant la variable "IgnitionKey" à 3 ce qui correspond à moteur en marche (Engine Start)

- Il est préférable d'écrire sur la variable "TimeOfUpdate" pour "synchroniser" l'envoi de données entre ModelHandler qui fonctionne à 500Hz et notre API qui fonctionne à 100Hz

- On mettra également la boîte de vitesse à 1 (GearBox)

Les commandes envoyées sur les canaux sont :

Com_setDoubleData(CabToModelOutput,"Accelerator", OutputData.accelerator);
Com_setDoubleData(CabToSteeringOutput,"SteeringWheel",OutputData.vehiculewheelangle);
Com_setShortData(CabToModelOutput, "GearBoxAutoMode", 0);
Com_setShortData(CabToModelOutput, "WantedGear", 1);
Com_setShortData(CabToModelOutput, "IgnitionKey", 3);
Com_setDoubleData(CabToModelOutput, "TimeOfUpdate",Process_GetTime());

On impose 0 sur “GearBoxAutoMode” pour gérer la boîte de vitesse manuellement.

On impose 3 sur “IgnitionKey” pour démarrer le moteur (Start Engine)

On impose 1 sur “WantedGear” pour démarrer en vitesse numéro 1

Nous commençons à fusionner l'API client et cette API.

=== Semaine 9===

Les deux API sont fusionnées et nous commençons les tests de notre nouvelle API. Nous l'ajoutons à SCANeR et celle-ci devient rapidement fonctionnelle. Cependant, nous rencontrons des problèmes avec la connexion WIFI qui n'est pas fiable et qui coupe très souvent. En effet, nous avons dans un premier temps créé un réseau ad hoc. Ce type de réseau est facile et rapide à mettre en place mais sa fiabilité reste limitée.
Il y a des pertes de données et de connexion assez fréquentes. De plus, La bande passante est limitée. Un problème subsiste donc, le temps de latence entre l'envoi des consignes et l'application de celles-ci au modèle de SCANeR Studio est très important. En d'autres mots, les déplacements du Robucar ne sont pas fiables dans la simulation. Nous avons donc poursuivi les tests en connectant le Robucar et le PC Supervision par Ethernet. La connexion est plus stable mais le cahier des charges nous impose une communication WIFI. Nous nous sommes donc
procurés un routeur que nous avons configuré pour établir une connexion entre les deux PC. La connexion est alors stable et les échanges de
paquets se font rapidement. On conservera donc cette configuration pour la suite des tests.

Après une nouvelle phase de tests, nous constatons que l'angle de braquage des roues dans la simulation n'est pas correct. Le Robucar fourni un angle compris entre 2242 (angle de 30° à gauche) et 3002 (angle de 30° à droite). De ce fait, le déplacement tout droit correspond à une valeur de 2622. Dans la simulation, la direction tout droit correspond à zéro. Pour tourner à gauche, on veut un angle en radian positif et pour tourner à droite un angle négatif. Dans la mesure où la variation de l’angle en fonction de la position du volant est sensible, on choisit un intervalle I ∈[2600;2670] pour aller tout droit. Le calcul de l’angle pour tourner à gauche ou à droite est réalisé selon une règle de 3.
Nous avons également réajusté la vitesse du véhicule dans la simulation. En effet, la consigne de vitesse envoyée par le Robucar représente la moyenne des vitesses des roues avant et arrière. Or les roues arrière ont une vitesse plus faible que les roues avant. De ce fait, nous avons calculé un coefficient permettant d’ajuster la vitesse uniquement selon la vitesse des roues avant. Ici, ce coefficient vaut 1,34.

=== Semaine 10===

Une fois les paramètres réajustés, les mouvements du modèle dans SCANeR sont relativement précis et on peut maintenant surveiller le véhicule
lors de son déplacement selon plusieurs points de vue (Top View, Driver View etc).

[[Fichier:Driver_view.PNG|500px|thumb|center|Driver View dans la simulation]]

Malheureusement, le cockpit de conduite n'est plus à Polytech Lille depuis plusieurs semaines et ne pouvons donc pas tester le système complet
avec le Robucar, le PC supervision et le cockpit de conduite. L'API cockpit étant fonctionnelle, le système dans sa globalité devrait fonctionner sans problème.

=== Bilan de fin de projet ===

Ce projet nous a permis d'appréhender les notions de serveur et de client, jamais étudiées jusqu'ici. Ces nouvelles notions ont soulevé plusieurs
problèmes tels que le débit d'émission et la fiabilité du réseau entre les deux composantes du système. Nous avons pris en main SCANeR Studio en utilisant chacun des modes pour créer une simulation complète. En parallèle, nous avons pu comprendre le fonctionnement des API ainsi que les liens internes entre celles-ci.

En utilisant un cockpit de conduite tel que celui de la salle C002 à Polytech Lille, la surveillance d’un véhicule est possible à courte distance. En effet, la connectivité actuelle ne permet pas la communication entre le cockpit (ou le PC supervision ici) et le Robucar. Par ailleurs, si on pallie à ce problème, on pourrait imaginer le guidage du véhicule dans des zones confinées où la perception d’obstacles et la détection de collision par le conducteur est difficile. On pourrait également utiliser le télémètre laser pour la détection d’obstacles et envoyer, de la même façon, les informations à l’opérateur sur le cockpit de simulation.

== Rendus du projet ==

Rapport de projet: [[Fichier:-BRICOUT_MARTIN-_Rapport_projet_IMA4.pdf‎]]

Logiciel SCANeR

2014-04-19T07:45:15Z

Nmartin1 : Annulation des modifications 12477 de Nmartin1 (discussion)

#REDIRECTION [[Guidage et Surveillance d'un train de véhicule à travers un Cockpit de conduite]]

Logiciel SCANeR

2014-04-19T07:43:17Z

Nmartin1 : Page blanchie

Guidage et Surveillance d'un véhicule à travers un Cockpit de conduite

2014-04-10T07:31:07Z

Nmartin1 : /* Semaine 5 */

Dans le cadre de la quatrième année au sein de la spécialité Informatique-Microélectronique-Automatique, nous allons réaliser un projet permettant de piloter et surveiller
un véhicule autonome à travers un cockpit de conduite. Ce projet sera encadré par Rochdi MERZOUKI et Xavier REDON.

'''Résumé du projet:'''

Dans le cadre du projet InTraDE, transport autonome du fret, nous souhaitons relier le cockpit de conduite de la salle C002 à un véhicule mobile RobuCar.
Pour cela, le cockpit qui fonctionne sous le simulateur de dynamique du véhicule SCANeR Studio, communiquera directement via le réseau WiFi avec un véhicule autonome Robucar.
Tout d'abord, nous modéliserons le parking de Polytech Lille sur le logiciel SCANeR Studio. Ensuite, nous intégrerons à ce terrain un véhicule Robucar déjà modélisé.
Nous élaborerons alors un scénario dans SCANeR mettant en scène plusieurs véhicules, pilotés automatiquement par SCANeR et le Robucar, piloté par une API (Application Programming Interface)
sur le PC supervision. L'objectif de ce projet est de récupérer, par le biais d'une première API, des consignes de vitesse et d'angle de braquage des roues imposées au Robucar (par le biais d'un programme MATLAB déjà opérationnel) et
de les envoyer au PC Supervision où ils seront récupérées par une seconde API. Celle-ci prendra en charge l'acheminement de ces données vers le cockpit et la simulation sur les channels adéquates pour que l'API (ModelHandler) qui contrôle le véhicule simulé prenne en compte ces consignes et les applique au modèle dynamique. De ce fait, nous verrons évoluer en temps réel le Robucar dans la simulation et simultanément,
le volant du cockpit suivra les mouvements du véhicule réel. L'utilisateur pourra ainsi suivre le déplacement de la Robucar dans la simulation et observer, parallèlement, les mouvements du volant dans le cockpit.

'''Pour aller plus loin'''

On pourra également télé-opérer le véhicule réel à tout moment, c'est à dire le piloter via le cockpit. La manipulation pourra éventuellement être réalisée avec deux Robucars.

== Matériel à disposition ==

Pour notre projet nous avons à disposition:

- un véhicule Robucar muni d'un PC intégré et d'une carte d'acquisition DSPACE (en C002)

- les logiciels permettant sa conduite, à savoir Matlab, Simulink et Control Desk

- un PC supervision (en C002)

- un Cockpit de simulation (en C002)

- un Accès au logiciel de simulation SCANeR Studio (en C002)

Nous travaillerons sur le logiciel de développement Microsoft Visual Studio 2005.

== Définition des outils à disposition ==

[[Fichier:scaner.png|370px|thumb|right|Logiciel de simulation Temps Réel SCANeR Studio]]

===SCANeR Studio: Logiciel de simulation pour la recherche et l'ingénierie===

SCANeR Studio est un logiciel de simulation de conduite automobile Temps Réel offrant à ses utilisateurs une interface de surveillance ou de contrôle d'un véhicule (voiture, poids lourd, cycliste, piéton).
Il permet la représentation d'un environnement, modélisé en 3D par le logiciel, auquel un ou plusieurs véhicules sont intégrés.
Les véhicules simulés sont de différents types et on s'intéressera pour notre application aux véhicules "simples" et "Advanced".

Selon leur type, les véhicules sont contrôlés par différentes API (Application Programming Interface) dans SCANeR Studio:

- automatiquement par la simulation : API TRAFFIC. C'est le cas des véhicules de type simples.

- à l'aide d'un élément extérieur tel qu'un cockpit de simulation ou un véhicule réel : API Modelhandler. C'est le cas des véhicule de type Advanced.

Pour réaliser une simulation, il faut un terrain et un scenario. C'est dans le mode scenario que nous choisissons les véhicules à mettre en place dans la simulation. Ici, nous modéliserons le Parking de Polytech Lille puis nous y intégrerons le Robucar (de type véhicule "Advanced") et éventuellement des véhicules simples. Nous choisissons également les API qui seront actives. Ici, les API indispensables sont Modelhandler et l'API que nous avons développé pour lire les consignes envoyées par le serveur et les appliquer dans la simulation. Les deux API vont s'échanger des données par le biais de canaux : les Export Channels. Notre API enverra donc une consigne de vitesse et d'angle de braquage des roues sur des Export Channels définis précisément afin que ModelHandler puissent les informations.

===Le véhicule ROBUCAR===

[[Fichier:robucar.jpg|350px|thumb|right|Véhicule Robucar]]

Le Robucar est un véhicule automatique "intelligent", autonome et électrique, commercialisé par la société ROBOSOFT. Il est composé d'un châssis à quatre roues motrices et directionnelles pilotables séparément.
Il y a donc deux paramètres de commande pour chaque roue : l'orientation et la vitesse de rotation). Le véhicule est équipé d'un ordinateur de bord et d'une carte d'acquisition Temps Réel DSPACE qui récupère les données du véhicule. L'accès à ces données sur d'ordinateur intégré est rendu possible par la librairie CLIB. Celle-ci permet, en effet, de récupérer les données acquise par la DSPACE.

Dans le cadre de notre projet, nous considérons que seules les roues avants du véhicule sont directionnelles. Nous appliquerons donc la même consigne de vitesse et de braquage aux deux roues avant.

===Création d'un Serveur UDP===

Pour créer une communication entre le PC supervision et le PC intégré au Robucar, nous avons choisi de créer un serveur UDP. Nous avons préféré ce protocole au TCP car il est plus rapide et la perte de quelques paquets n'est pas gênante pour notre application. Le serveur est implémenté en langage C++ sur Windows grâce à la bibliothèque Windows Sockets 2 (« Winsock2 »).
Le RobuCar est piloté avec un programme Matlab et son programme Simulink correspondant. On charge dans le logiciel dSPACE ControlDesk du Robucar le programme correspondant à celui sur MATLAB. Une interface apparaît et nous pouvons alors piloter le véhicule. Lors de la conduite, des valeurs de consignes pour la vitesse moyenne et l’angle de braquage des roues sont donc récupérées dans l’API Serveur grâce à la bibliothèque « clib32 ». Sur le PC supervision, l'API Client se connecte au serveur et reçoit alors des paquets contenant une consigne de vitesse et de braquage.

==Journal de bord==

===Semaine 1===
[[Fichier:Parking.png|300px|thumb|right|Parking Polytech Lille modélisé]]

Lors de cette première séance, nous avons pris en main le logiciel SCANeR Studio et notamment le mode terrain qui permet de concevoir un environnement de simulation.
De ce fait, nous avons débuté la conception du parking de Polytech Lille sur le logiciel.

===Semaine 2===

Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio et avons débuté l'élaboration d'un scénario mettant en scène un Robucar qui est de type "vehicle Advanced"
et plusieurs véhicules de type "vehicle simple" qui seront pilotés automatiquement par le logiciel. Le Robucar est piloté par l'API ModelHandler et nous pouvons donc dès à présent tester la fonctionnalité
de notre terrain.

Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio et avons débuté l'élaboration d'un scénario mettant en scène, dans un premier temps, uniquement des véhicules de type "vehicle simple". Ces véhicules sont pilotés automatiquement par le logiciel, ce qui nous permet de nous concentrer sur notre terrain. Nous pouvons ainsi dès à présent tester sa fonctionnalité.

Résultats des simulations sur le terrain:

- Dans certains virages et dans le rond point à l'entrée du parking, le comportement des véhicules en mode automatique est anormal

- Les véhicules se comportent normalement sur les lignes droites, aux Cédez-le-passage et dans les virages à 90 degrés.

Les virages étaient modélisés en "Polyline" ce qui est compliqué à traiter d'un point de vue logiciel. Nous avons dû re-modéliser plusieurs virages en prenant des sections de route plus simples.
Ainsi, les défauts de trajectoire des véhicules sont corrigés. Le parking est opérationnel pour l'élaboration de notre scénario futur.

===Semaine 3===

La prochaine étape est la conception de deux API: un serveur UDP qui sera lancé sur la Robucar et un client, lancé sur le PC de supervision. Nous commençons à nous auto-former sur la conception d'une API sous SCANeR Studio en prenant connaissance de la documentation disponible. On décide de réaliser une API simple qui affiche la vitesse d'un véhicule de type simple. On débute alors la conception de cette API.

En première partie de séance, nous nous entretenons avec le doctorant Vincent Coelen pour faire un point sur les API. On évoquera entre autre les points suivants:

- comprendre l'utilisation des canaux (EXPORT CHANNEL)

- mettre à disposition la documentation nécessaire pour les utiliser

- comment transformer un projet C++ en une API qui évoluera dans le logiciel

Nous nous entretenons également avec M. Merzouki pour définir plus précisément le cahier des charges. Les points abordés sont les suivants:

- Programmation d'un Serveur UDP sur l'ordinateur intégré au Robucar pour communiquer en WIFI avec une API Client

- Programmation d'une API Client à implanter sur le logiciel SCANeR du PC Supervision

- Conception d'une seconde API permettant d'envoyer des consignes de vitesse et de braquage dans la simulation

- Fusion de ces deux dernières API

Ensuite, nous commençons à prendre en main l'utilisation des sockets en C++ pour le serveur UDP et l'API Client. Nous utiliserons les sources suivantes:

[http://www.frameip.com/entete-udp/ Frampeip: Serveur en mode non connecté]

[http://rex.plil.fr/Enseignement/Reseau/Reseau.IMA4sc/reseau.html Cours IMASC : Programmation Réseau]

[http://www.linux-france.org/prj/edu/archinet/systeme/index_monopage.html Linux: Tutoriel sur les Serveurs]

===Semaine 4===

Nous commençons à nous focaliser sur le fonctionnement du Robucar. Vincent nous explique comment marche la DSPACE et comment utiliser un programme MATLAB pour récupérer des données du véhicule
tels que la vitesse, l'angle de braquage, la position de la boîte de vitesse etc. On découvre aussi le fonctionnement du Cockpit en utilisant une API déjà fonctionnelle permettant d'envoyer des commandes
au cockpit depuis la simulation. Cette API est implantée sur le logiciel SCANeR du PC Supervision.
Nous continuons la programmation du serveur UDP de l'API Client.

Les Premiers tests du serveur:

- On met le PC Supervision et le PC du Robucar sur le même réseau

- On essaie de se "pinger" l'un l'autre pour vérifier la connexion entre les deux ordinateurs

Problème rencontré:
Les codes du serveur et du client ne compilent pas car il manque des librairies. Nous renseignons les librairies manquantes et corrigeons les erreurs de compilation.

===Semaine 5 ===

Nous réorganisons les codes du serveur et du client avec l'aide de M. Redon. Le serveur et l'API Client ne fonctionne actuellement pas.
Afin d'accéder aux données de la DSPACE, il nous faut utiliser un Parser, programmé par un doctorant ayant travaillé sur le Robucar auparavant. Ce parser prend en paramètre les noms des
variables dans le programme Simulink et nous renvoie leur nom système correspondant, exploitable en C++. Pour cela, il faut indiquer au parser le chemin (path) et le nom exact des variables dans Simulink.
Dans le serveur UDP, on récupère donc grâce à la librairie Clib les valeurs de la vitesse et l'angle de braquage des roues du Robucar.

===Semaine 6===

Le serveur UDP est fonctionnel. Les échanges de paquets entre les deux PC connectés se font rapidement. Grâce à un compteur dans le programme du Serveur, on constate que beaucoup de paquets
sont perdus mais ceci ne devrait pas poser trop de problèmes dans la simulation

===Semaine 7===

On débute la programmation de la seconde API permettant d'envoyer des données à la simulation. Pour ce faire, on doit prendre en main l'écriture sur les EXPORT CHANNELS.
En effet, ils permettent d'échanger des informations entre les différentes API. Ici, on cherche à échanger des données entre cette API et l'API ModelHandler qui pilote le modèle
(Robucar dans la simulation). On va donc renseigner les cases mémoires de la vitesse et de l'angle de braquage des roues dans lesquelles Modelhandler lis ces informations pour les
envoyer sur le modèle de la simulation.

===Semaine 8===

On continue la programmation de l'API elle est terminée rapidement. On réalise les premiers tests de l'API dans Scaner Studio. Pour ce faire, on charge notre terrain (parking de Polytech Lille),
on ajoute un scénario qui dans notre cas est l'ajout d'un véhicule de type Advanced piloté par Modelhandler. On ajoute ensuite une API en utilisant le fichier .exe généré par notre projet sur Visual Studio.

Problèmes rencontrés:

- Problème dans les héritages des dépendances supplémentaires du projet dans Microsoft Visual Studio: on doit ajouter certaines librairies supplémentaires

- l'API bloque la simulation bien qu'elle compile correctement indépendamment de la simulation

===Semaine 9===

L'API envoyant des données fixes à SCANeR Studio est fonctionnelle.

Les problèmes résolus sont :

- Le format d'envoi des consignes de vitesse et de braquage n'était pas correct (Float au lieu de Double)

- Il est nécessaire de démarrer le moteur en fixant la variable "IgnitionKey" à 3 ce qui correspond à moteur en marche (Engine Start)

- Il est préférable d'écrire sur la variable "TimeOfUpdate" pour "synchroniser" l'envoi de données entre ModelHandler qui fonctionne à 500Hz et notre API qui fonctionne à 100Hz

- On mettra également la boîte de vitesse à 1 (GearBox)

Nous commençons à fusionner l'API client et cette API.

=== Semaine 10===

Les deux API sont fusionnées et nous commençons les tests de notre nouvelle API. Nous l'ajoutons à SCANeR et celle-ci devient rapidement fonctionnelle. Cependant, nous rencontrons des problèmes avec la connexion WIFI qui n'est pas fiable et qui coupe très souvent. En effet, nous avons dans un premier temps créé un réseau ad hoc. Ce type de réseau est facile et rapide à mettre en place mais sa fiabilité reste limitée. Il y a des pertes de données et de connexion assez fréquentes. De plus, La bande passante est limitée. Un problème subsiste donc, le temps de latence entre l'envoi des consignes et l'application de celles-ci au modèle de SCANeR Studio est très important. En d'autres mots, les déplacements du Robucar ne sont pas fiables sur la simulation. Nous avons donc poursuivi les tests en connectant le Robucar et le PC Supervision par Ethernet. Cependant, le cahier des charges nous impose une communication WIFI. Nous nous sommes procuré un routeur que nous avons configuré pour établir une connexion entre les deux appareils.
Après une nouvelle phase de tests, nous constatons que l'angle de braquage des roues dans la simulation n'est pas correct. On multipliera la consigne reçue par un coefficient pour ajuster la valeur car l'angle de consigne doit être en radian alors que le cockpit envoie un entier autour de 2600. Ces réglages, nous obtenons un résultats satisfaisant en terme de rapidité de réponse de la simulation par rapport au véhicule réel.
Par manque de temps, le parking de Polytech Lille utilisé pour jouer la simulation restera d'une apparence des plus basiques.

Guidage et Surveillance d'un véhicule à travers un Cockpit de conduite

2014-04-10T07:26:49Z

Nmartin1 : /* Semaine 3 */

Guidage et Surveillance d'un véhicule à travers un Cockpit de conduite

2014-04-10T07:22:41Z

Nmartin1 : /* Semaine 2 */

Dans le cadre de la quatrième année au sein de la spécialité Informatique-Microélectronique-Automatique, nous allons réaliser un projet permettant de piloter et surveiller
un véhicule autonome à travers un cockpit de conduite. Ce projet sera encadré par Rochdi MERZOUKI et Xavier REDON.

'''Résumé du projet:'''

Dans le cadre du projet InTraDE, transport autonome du fret, nous souhaitons relier le cockpit de conduite de la salle C002 à un véhicule mobile RobuCar.
Pour cela, le cockpit qui fonctionne sous le simulateur de dynamique du véhicule SCANeR Studio, communiquera directement via le réseau WiFi avec un véhicule autonome Robucar.
Tout d'abord, nous modéliserons le parking de Polytech Lille sur le logiciel SCANeR Studio. Ensuite, nous intégrerons à ce terrain un véhicule Robucar déjà modélisé.
Nous élaborerons alors un scénario dans SCANeR mettant en scène plusieurs véhicules, pilotés automatiquement par SCANeR et le Robucar, piloté par une API (Application Programming Interface)
sur le PC supervision. L'objectif de ce projet est de récupérer, par le biais d'une première API, des consignes de vitesse et d'angle de braquage des roues imposées au Robucar (par le biais d'un programme MATLAB déjà opérationnel) et
de les envoyer au PC Supervision où ils seront récupérées par une seconde API. Celle-ci prendra en charge l'acheminement de ces données vers le cockpit et la simulation sur les channels adéquates pour que l'API (ModelHandler) qui contrôle le véhicule simulé prenne en compte ces consignes et les applique au modèle dynamique. De ce fait, nous verrons évoluer en temps réel le Robucar dans la simulation et simultanément,
le volant du cockpit suivra les mouvements du véhicule réel. L'utilisateur pourra ainsi suivre le déplacement de la Robucar dans la simulation et observer, parallèlement, les mouvements du volant dans le cockpit.

'''Pour aller plus loin'''

On pourra également télé-opérer le véhicule réel à tout moment, c'est à dire le piloter via le cockpit. La manipulation pourra éventuellement être réalisée avec deux Robucars.

== Matériel à disposition ==

Pour notre projet nous avons à disposition:

- un véhicule Robucar muni d'un PC intégré et d'une carte d'acquisition DSPACE (en C002)

- les logiciels permettant sa conduite, à savoir Matlab, Simulink et Control Desk

- un PC supervision (en C002)

- un Cockpit de simulation (en C002)

- un Accès au logiciel de simulation SCANeR Studio (en C002)

Nous travaillerons sur le logiciel de développement Microsoft Visual Studio 2005.

== Définition des outils à disposition ==

[[Fichier:scaner.png|370px|thumb|right|Logiciel de simulation Temps Réel SCANeR Studio]]

===SCANeR Studio: Logiciel de simulation pour la recherche et l'ingénierie===

SCANeR Studio est un logiciel de simulation de conduite automobile Temps Réel offrant à ses utilisateurs une interface de surveillance ou de contrôle d'un véhicule (voiture, poids lourd, cycliste, piéton).
Il permet la représentation d'un environnement, modélisé en 3D par le logiciel, auquel un ou plusieurs véhicules sont intégrés.
Les véhicules simulés sont de différents types et on s'intéressera pour notre application aux véhicules "simples" et "Advanced".

Selon leur type, les véhicules sont contrôlés par différentes API (Application Programming Interface) dans SCANeR Studio:

- automatiquement par la simulation : API TRAFFIC. C'est le cas des véhicules de type simples.

- à l'aide d'un élément extérieur tel qu'un cockpit de simulation ou un véhicule réel : API Modelhandler. C'est le cas des véhicule de type Advanced.

Pour réaliser une simulation, il faut un terrain et un scenario. C'est dans le mode scenario que nous choisissons les véhicules à mettre en place dans la simulation. Ici, nous modéliserons le Parking de Polytech Lille puis nous y intégrerons le Robucar (de type véhicule "Advanced") et éventuellement des véhicules simples. Nous choisissons également les API qui seront actives. Ici, les API indispensables sont Modelhandler et l'API que nous avons développé pour lire les consignes envoyées par le serveur et les appliquer dans la simulation. Les deux API vont s'échanger des données par le biais de canaux : les Export Channels. Notre API enverra donc une consigne de vitesse et d'angle de braquage des roues sur des Export Channels définis précisément afin que ModelHandler puissent les informations.

===Le véhicule ROBUCAR===

[[Fichier:robucar.jpg|350px|thumb|right|Véhicule Robucar]]

Le Robucar est un véhicule automatique "intelligent", autonome et électrique, commercialisé par la société ROBOSOFT. Il est composé d'un châssis à quatre roues motrices et directionnelles pilotables séparément.
Il y a donc deux paramètres de commande pour chaque roue : l'orientation et la vitesse de rotation). Le véhicule est équipé d'un ordinateur de bord et d'une carte d'acquisition Temps Réel DSPACE qui récupère les données du véhicule. L'accès à ces données sur d'ordinateur intégré est rendu possible par la librairie CLIB. Celle-ci permet, en effet, de récupérer les données acquise par la DSPACE.

Dans le cadre de notre projet, nous considérons que seules les roues avants du véhicule sont directionnelles. Nous appliquerons donc la même consigne de vitesse et de braquage aux deux roues avant.

===Création d'un Serveur UDP===

Pour créer une communication entre le PC supervision et le PC intégré au Robucar, nous avons choisi de créer un serveur UDP. Nous avons préféré ce protocole au TCP car il est plus rapide et la perte de quelques paquets n'est pas gênante pour notre application. Le serveur est implémenté en langage C++ sur Windows grâce à la bibliothèque Windows Sockets 2 (« Winsock2 »).
Le RobuCar est piloté avec un programme Matlab et son programme Simulink correspondant. On charge dans le logiciel dSPACE ControlDesk du Robucar le programme correspondant à celui sur MATLAB. Une interface apparaît et nous pouvons alors piloter le véhicule. Lors de la conduite, des valeurs de consignes pour la vitesse moyenne et l’angle de braquage des roues sont donc récupérées dans l’API Serveur grâce à la bibliothèque « clib32 ». Sur le PC supervision, l'API Client se connecte au serveur et reçoit alors des paquets contenant une consigne de vitesse et de braquage.

==Journal de bord==

===Semaine 1===
[[Fichier:Parking.png|300px|thumb|right|Parking Polytech Lille modélisé]]

Lors de cette première séance, nous avons pris en main le logiciel SCANeR Studio et notamment le mode terrain qui permet de concevoir un environnement de simulation.
De ce fait, nous avons débuté la conception du parking de Polytech Lille sur le logiciel.

===Semaine 2===

Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio et avons débuté l'élaboration d'un scénario mettant en scène un Robucar qui est de type "vehicle Advanced"
et plusieurs véhicules de type "vehicle simple" qui seront pilotés automatiquement par le logiciel. Le Robucar est piloté par l'API ModelHandler et nous pouvons donc dès à présent tester la fonctionnalité
de notre terrain.

Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio et avons débuté l'élaboration d'un scénario mettant en scène, dans un premier temps, uniquement des véhicules de type "vehicle simple". Ces véhicules sont pilotés automatiquement par le logiciel, ce qui nous permet de nous concentrer sur notre terrain. Nous pouvons ainsi dès à présent tester sa fonctionnalité.

Résultats des simulations sur le terrain:

- Dans certains virages et dans le rond point à l'entrée du parking, le comportement des véhicules en mode automatique est anormal

- Les véhicules se comportent normalement sur les lignes droites, aux Cédez-le-passage et dans les virages à 90 degrés.

Les virages étaient modélisés en "Polyline" ce qui est compliqué à traiter d'un point de vue logiciel. Nous avons dû re-modéliser plusieurs virages en prenant des sections de route plus simples.
Ainsi, les défauts de trajectoire des véhicules sont corrigés. Le parking est opérationnel pour l'élaboration de notre scénario futur.

===Semaine 3===

La prochaine étape est la conception de deux API: un serveur UDP qui sera lancé sur la Robucar et un client, lancé sur le PC de supervision. Nous commençons à nous auto-former sur la conception d'une API sous SCANeR Studio en prenant connaissance de la documentation disponible. On décide de réaliser une API simple qui affiche la vitesse d'un véhicule de type simple. On débute alors la conception de cette API.

En première partie de séance, nous nous entretenons avec le doctorant Vincent XX pour faire un point sur les API. On évoquera entre autre les points suivants:

- comprendre l'utilisation des canaux (EXPORT CHANNEL)

- mettre à disposition la documentation nécessaire pour les utiliser

- comment transformer un projet C++ en une API qui évoluera dans le logiciel

Nous entretiendrons également avec M. Merzouki pour définir plus précisément le cahier des charges. Les points abordés sont les suivants:

- Programmation d'un Serveur UDP sur l'ordinateur intégré au Robucar pour communiquer en WIFI avec une API Client

- Programmation d'une API Client à implanter sur le logiciel SCANeR du PC Supervision

- Conception d'une seconde API permettant d'envoyer des consignes de vitesse et de braquage dans la simulation

- Fusion de ces deux API

En seconde partie de séance, nous commençons à prendre en main l'utilisation des sockets en C++ pour le serveur UDP et l'API Client. Nous utiliserons les sources suivantes:

[http://www.frameip.com/entete-udp/ Frampeip: Serveur en mode non connecté]

[http://rex.plil.fr/Enseignement/Reseau/Reseau.IMA4sc/reseau.html Cours IMASC : Programmation Réseau]

[http://www.linux-france.org/prj/edu/archinet/systeme/index_monopage.html Linux: Tutoriel sur les Serveurs]

===Semaine 4===

Nous commençons à nous focaliser sur le fonctionnement du Robucar. Vincent nous explique comment marche la DSPACE et comment utiliser un programme MATLAB pour récupérer des données du véhicule
tels que la vitesse, l'angle de braquage, la position de la boîte de vitesse etc. On découvre aussi le fonctionnement du Cockpit en utilisant une API déjà fonctionnelle permettant d'envoyer des commandes
au cockpit depuis la simulation. Cette API est implantée sur le logiciel SCANeR du PC Supervision.
Nous continuons la programmation du serveur UDP de l'API Client.

Les Premiers tests du serveur:

- On met le PC Supervision et le PC du Robucar sur le même réseau

- On essaie de se "pinger" l'un l'autre pour vérifier la connexion entre les deux ordinateurs

Problème rencontré:
Les codes du serveur et du client ne compilent pas car il manque des librairies. Nous renseignons les librairies manquantes et corrigeons les erreurs de compilation.

===Semaine 5 ===

Nous réorganisons les codes du serveur et du client avec l'aide de M. Redon. Le serveur et l'API Client ne fonctionne actuellement pas.
Afin d'accéder aux données de la DSPACE, il nous faut utiliser un Parser, programmé par un doctorant ayant travaillé sur le Robucar auparavant. Ce parser prend en paramètre les noms des
variables dans le programme Simulink et nous renvoie leur nom système correspondant, exploitable en C++. Pour cela, il faut indiquer au parser le chemin (path) et le nom exact des variables dans Simulink.
Dans le serveur UDP, on récupère donc grâce à la librairie Clib les valeurs de la vitesse et l'angle de braquage des roues du Robucar.

===Semaine 6===

Le serveur UDP est fonctionnel. Les échanges de paquets entre les deux PC connectés se font rapidement. Grâce à un compteur dans le programme du Serveur, on constate que beaucoup de paquets
sont perdus mais ceci ne devrait pas poser trop de problèmes dans la simulation

===Semaine 7===

On débute la programmation de la seconde API permettant d'envoyer des données à la simulation. Pour ce faire, on doit prendre en main l'écriture sur les EXPORT CHANNELS.
En effet, ils permettent d'échanger des informations entre les différentes API. Ici, on cherche à échanger des données entre cette API et l'API ModelHandler qui pilote le modèle
(Robucar dans la simulation). On va donc renseigner les cases mémoires de la vitesse et de l'angle de braquage des roues dans lesquelles Modelhandler lis ces informations pour les
envoyer sur le modèle de la simulation.

===Semaine 8===

On continue la programmation de l'API elle est terminée rapidement. On réalise les premiers tests de l'API dans Scaner Studio. Pour ce faire, on charge notre terrain (parking de Polytech Lille),
on ajoute un scénario qui dans notre cas est l'ajout d'un véhicule de type Advanced piloté par Modelhandler. On ajoute ensuite une API en utilisant le fichier .exe généré par notre projet sur Visual Studio.

Problèmes rencontrés:

- Problème dans les héritages des dépendances supplémentaires du projet dans Microsoft Visual Studio: on doit ajouter certaines librairies supplémentaires

- l'API bloque la simulation bien qu'elle compile correctement indépendamment de la simulation

===Semaine 9===

L'API envoyant des données fixes à SCANeR Studio est fonctionnelle.

Les problèmes résolus sont :

- Le format d'envoi des consignes de vitesse et de braquage n'était pas correct (Float au lieu de Double)

- Il est nécessaire de démarrer le moteur en fixant la variable "IgnitionKey" à 3 ce qui correspond à moteur en marche (Engine Start)

- Il est préférable d'écrire sur la variable "TimeOfUpdate" pour "synchroniser" l'envoi de données entre ModelHandler qui fonctionne à 500Hz et notre API qui fonctionne à 100Hz

- On mettra également la boîte de vitesse à 1 (GearBox)

Nous commençons à fusionner l'API client et cette API.

=== Semaine 10===

Les deux API sont fusionnées et nous commençons les tests de notre nouvelle API. Nous l'ajoutons à SCANeR et celle-ci devient rapidement fonctionnelle. Cependant, nous rencontrons des problèmes avec la connexion WIFI qui n'est pas fiable et qui coupe très souvent. En effet, nous avons dans un premier temps créé un réseau ad hoc. Ce type de réseau est facile et rapide à mettre en place mais sa fiabilité reste limitée. Il y a des pertes de données et de connexion assez fréquentes. De plus, La bande passante est limitée. Un problème subsiste donc, le temps de latence entre l'envoi des consignes et l'application de celles-ci au modèle de SCANeR Studio est très important. En d'autres mots, les déplacements du Robucar ne sont pas fiables sur la simulation. Nous avons donc poursuivi les tests en connectant le Robucar et le PC Supervision par Ethernet. Cependant, le cahier des charges nous impose une communication WIFI. Nous nous sommes procuré un routeur que nous avons configuré pour établir une connexion entre les deux appareils.
Après une nouvelle phase de tests, nous constatons que l'angle de braquage des roues dans la simulation n'est pas correct. On multipliera la consigne reçue par un coefficient pour ajuster la valeur car l'angle de consigne doit être en radian alors que le cockpit envoie un entier autour de 2600. Ces réglages, nous obtenons un résultats satisfaisant en terme de rapidité de réponse de la simulation par rapport au véhicule réel.
Par manque de temps, le parking de Polytech Lille utilisé pour jouer la simulation restera d'une apparence des plus basiques.

Guidage et Surveillance d'un véhicule à travers un Cockpit de conduite

2014-04-10T07:21:45Z

Nmartin1 : /* Semaine 2 */

Dans le cadre de la quatrième année au sein de la spécialité Informatique-Microélectronique-Automatique, nous allons réaliser un projet permettant de piloter et surveiller
un véhicule autonome à travers un cockpit de conduite. Ce projet sera encadré par Rochdi MERZOUKI et Xavier REDON.

'''Résumé du projet:'''

Dans le cadre du projet InTraDE, transport autonome du fret, nous souhaitons relier le cockpit de conduite de la salle C002 à un véhicule mobile RobuCar.
Pour cela, le cockpit qui fonctionne sous le simulateur de dynamique du véhicule SCANeR Studio, communiquera directement via le réseau WiFi avec un véhicule autonome Robucar.
Tout d'abord, nous modéliserons le parking de Polytech Lille sur le logiciel SCANeR Studio. Ensuite, nous intégrerons à ce terrain un véhicule Robucar déjà modélisé.
Nous élaborerons alors un scénario dans SCANeR mettant en scène plusieurs véhicules, pilotés automatiquement par SCANeR et le Robucar, piloté par une API (Application Programming Interface)
sur le PC supervision. L'objectif de ce projet est de récupérer, par le biais d'une première API, des consignes de vitesse et d'angle de braquage des roues imposées au Robucar (par le biais d'un programme MATLAB déjà opérationnel) et
de les envoyer au PC Supervision où ils seront récupérées par une seconde API. Celle-ci prendra en charge l'acheminement de ces données vers le cockpit et la simulation sur les channels adéquates pour que l'API (ModelHandler) qui contrôle le véhicule simulé prenne en compte ces consignes et les applique au modèle dynamique. De ce fait, nous verrons évoluer en temps réel le Robucar dans la simulation et simultanément,
le volant du cockpit suivra les mouvements du véhicule réel. L'utilisateur pourra ainsi suivre le déplacement de la Robucar dans la simulation et observer, parallèlement, les mouvements du volant dans le cockpit.

'''Pour aller plus loin'''

On pourra également télé-opérer le véhicule réel à tout moment, c'est à dire le piloter via le cockpit. La manipulation pourra éventuellement être réalisée avec deux Robucars.

== Matériel à disposition ==

Pour notre projet nous avons à disposition:

- un véhicule Robucar muni d'un PC intégré et d'une carte d'acquisition DSPACE (en C002)

- les logiciels permettant sa conduite, à savoir Matlab, Simulink et Control Desk

- un PC supervision (en C002)

- un Cockpit de simulation (en C002)

- un Accès au logiciel de simulation SCANeR Studio (en C002)

Nous travaillerons sur le logiciel de développement Microsoft Visual Studio 2005.

== Définition des outils à disposition ==

[[Fichier:scaner.png|370px|thumb|right|Logiciel de simulation Temps Réel SCANeR Studio]]

===SCANeR Studio: Logiciel de simulation pour la recherche et l'ingénierie===

SCANeR Studio est un logiciel de simulation de conduite automobile Temps Réel offrant à ses utilisateurs une interface de surveillance ou de contrôle d'un véhicule (voiture, poids lourd, cycliste, piéton).
Il permet la représentation d'un environnement, modélisé en 3D par le logiciel, auquel un ou plusieurs véhicules sont intégrés.
Les véhicules simulés sont de différents types et on s'intéressera pour notre application aux véhicules "simples" et "Advanced".

Selon leur type, les véhicules sont contrôlés par différentes API (Application Programming Interface) dans SCANeR Studio:

- automatiquement par la simulation : API TRAFFIC. C'est le cas des véhicules de type simples.

- à l'aide d'un élément extérieur tel qu'un cockpit de simulation ou un véhicule réel : API Modelhandler. C'est le cas des véhicule de type Advanced.

Pour réaliser une simulation, il faut un terrain et un scenario. C'est dans le mode scenario que nous choisissons les véhicules à mettre en place dans la simulation. Ici, nous modéliserons le Parking de Polytech Lille puis nous y intégrerons le Robucar (de type véhicule "Advanced") et éventuellement des véhicules simples. Nous choisissons également les API qui seront actives. Ici, les API indispensables sont Modelhandler et l'API que nous avons développé pour lire les consignes envoyées par le serveur et les appliquer dans la simulation. Les deux API vont s'échanger des données par le biais de canaux : les Export Channels. Notre API enverra donc une consigne de vitesse et d'angle de braquage des roues sur des Export Channels définis précisément afin que ModelHandler puissent les informations.

===Le véhicule ROBUCAR===

[[Fichier:robucar.jpg|350px|thumb|right|Véhicule Robucar]]

Le Robucar est un véhicule automatique "intelligent", autonome et électrique, commercialisé par la société ROBOSOFT. Il est composé d'un châssis à quatre roues motrices et directionnelles pilotables séparément.
Il y a donc deux paramètres de commande pour chaque roue : l'orientation et la vitesse de rotation). Le véhicule est équipé d'un ordinateur de bord et d'une carte d'acquisition Temps Réel DSPACE qui récupère les données du véhicule. L'accès à ces données sur d'ordinateur intégré est rendu possible par la librairie CLIB. Celle-ci permet, en effet, de récupérer les données acquise par la DSPACE.

Dans le cadre de notre projet, nous considérons que seules les roues avants du véhicule sont directionnelles. Nous appliquerons donc la même consigne de vitesse et de braquage aux deux roues avant.

===Création d'un Serveur UDP===

Pour créer une communication entre le PC supervision et le PC intégré au Robucar, nous avons choisi de créer un serveur UDP. Nous avons préféré ce protocole au TCP car il est plus rapide et la perte de quelques paquets n'est pas gênante pour notre application. Le serveur est implémenté en langage C++ sur Windows grâce à la bibliothèque Windows Sockets 2 (« Winsock2 »).
Le RobuCar est piloté avec un programme Matlab et son programme Simulink correspondant. On charge dans le logiciel dSPACE ControlDesk du Robucar le programme correspondant à celui sur MATLAB. Une interface apparaît et nous pouvons alors piloter le véhicule. Lors de la conduite, des valeurs de consignes pour la vitesse moyenne et l’angle de braquage des roues sont donc récupérées dans l’API Serveur grâce à la bibliothèque « clib32 ». Sur le PC supervision, l'API Client se connecte au serveur et reçoit alors des paquets contenant une consigne de vitesse et de braquage.

==Journal de bord==

===Semaine 1===
[[Fichier:Parking.png|300px|thumb|right|Parking Polytech Lille modélisé]]

Lors de cette première séance, nous avons pris en main le logiciel SCANeR Studio et notamment le mode terrain qui permet de concevoir un environnement de simulation.
De ce fait, nous avons débuté la conception du parking de Polytech Lille sur le logiciel.

===Semaine 2===

Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio et avons débuté l'élaboration d'un scénario mettant en scène un Robucar qui est de type "vehicle Advanced"
et plusieurs véhicules de type "vehicle simple" qui seront pilotés automatiquement par le logiciel. Le Robucar est piloté par l'API ModelHandler et nous pouvons donc dès à présent tester la fonctionnalité
de notre terrain.

Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio et avons débuté l'élaboration d'un scénario mettant en scène, dans un premier temps, uniquement des véhicules de type "vehicle simple" qui seront pilotés automatiquement par le logiciel. Nous pouvons ainsi dès à présent tester la fonctionnalité
de notre terrain.

Résultats des simulations sur le terrain:

- Dans certains virages et dans le rond point à l'entrée du parking, le comportement des véhicules en mode automatique est anormal

- Les véhicules se comportent normalement sur les lignes droites, aux Cédez-le-passage et dans les virages à 90 degrés.

Les virages étaient modélisés en "Polyline" ce qui est compliqué à traiter d'un point de vue logiciel. Nous avons dû re-modéliser plusieurs virages en prenant des sections de route plus simples.
Ainsi, les défauts de trajectoire des véhicules sont corrigés. Le parking est opérationnel pour l'élaboration de notre scénario futur.

===Semaine 3===

La prochaine étape est la conception de deux API: un serveur UDP qui sera lancé sur la Robucar et un client, lancé sur le PC de supervision. Nous commençons à nous auto-former sur la conception d'une API sous SCANeR Studio en prenant connaissance de la documentation disponible. On décide de réaliser une API simple qui affiche la vitesse d'un véhicule de type simple. On débute alors la conception de cette API.

En première partie de séance, nous nous entretenons avec le doctorant Vincent XX pour faire un point sur les API. On évoquera entre autre les points suivants:

- comprendre l'utilisation des canaux (EXPORT CHANNEL)

- mettre à disposition la documentation nécessaire pour les utiliser

- comment transformer un projet C++ en une API qui évoluera dans le logiciel

Nous entretiendrons également avec M. Merzouki pour définir plus précisément le cahier des charges. Les points abordés sont les suivants:

- Programmation d'un Serveur UDP sur l'ordinateur intégré au Robucar pour communiquer en WIFI avec une API Client

- Programmation d'une API Client à implanter sur le logiciel SCANeR du PC Supervision

- Conception d'une seconde API permettant d'envoyer des consignes de vitesse et de braquage dans la simulation

- Fusion de ces deux API

En seconde partie de séance, nous commençons à prendre en main l'utilisation des sockets en C++ pour le serveur UDP et l'API Client. Nous utiliserons les sources suivantes:

[http://www.frameip.com/entete-udp/ Frampeip: Serveur en mode non connecté]

[http://rex.plil.fr/Enseignement/Reseau/Reseau.IMA4sc/reseau.html Cours IMASC : Programmation Réseau]

[http://www.linux-france.org/prj/edu/archinet/systeme/index_monopage.html Linux: Tutoriel sur les Serveurs]

===Semaine 4===

Nous commençons à nous focaliser sur le fonctionnement du Robucar. Vincent nous explique comment marche la DSPACE et comment utiliser un programme MATLAB pour récupérer des données du véhicule
tels que la vitesse, l'angle de braquage, la position de la boîte de vitesse etc. On découvre aussi le fonctionnement du Cockpit en utilisant une API déjà fonctionnelle permettant d'envoyer des commandes
au cockpit depuis la simulation. Cette API est implantée sur le logiciel SCANeR du PC Supervision.
Nous continuons la programmation du serveur UDP de l'API Client.

Les Premiers tests du serveur:

- On met le PC Supervision et le PC du Robucar sur le même réseau

- On essaie de se "pinger" l'un l'autre pour vérifier la connexion entre les deux ordinateurs

Problème rencontré:
Les codes du serveur et du client ne compilent pas car il manque des librairies. Nous renseignons les librairies manquantes et corrigeons les erreurs de compilation.

===Semaine 5 ===

Nous réorganisons les codes du serveur et du client avec l'aide de M. Redon. Le serveur et l'API Client ne fonctionne actuellement pas.
Afin d'accéder aux données de la DSPACE, il nous faut utiliser un Parser, programmé par un doctorant ayant travaillé sur le Robucar auparavant. Ce parser prend en paramètre les noms des
variables dans le programme Simulink et nous renvoie leur nom système correspondant, exploitable en C++. Pour cela, il faut indiquer au parser le chemin (path) et le nom exact des variables dans Simulink.
Dans le serveur UDP, on récupère donc grâce à la librairie Clib les valeurs de la vitesse et l'angle de braquage des roues du Robucar.

===Semaine 6===

Le serveur UDP est fonctionnel. Les échanges de paquets entre les deux PC connectés se font rapidement. Grâce à un compteur dans le programme du Serveur, on constate que beaucoup de paquets
sont perdus mais ceci ne devrait pas poser trop de problèmes dans la simulation

===Semaine 7===

On débute la programmation de la seconde API permettant d'envoyer des données à la simulation. Pour ce faire, on doit prendre en main l'écriture sur les EXPORT CHANNELS.
En effet, ils permettent d'échanger des informations entre les différentes API. Ici, on cherche à échanger des données entre cette API et l'API ModelHandler qui pilote le modèle
(Robucar dans la simulation). On va donc renseigner les cases mémoires de la vitesse et de l'angle de braquage des roues dans lesquelles Modelhandler lis ces informations pour les
envoyer sur le modèle de la simulation.

===Semaine 8===

On continue la programmation de l'API elle est terminée rapidement. On réalise les premiers tests de l'API dans Scaner Studio. Pour ce faire, on charge notre terrain (parking de Polytech Lille),
on ajoute un scénario qui dans notre cas est l'ajout d'un véhicule de type Advanced piloté par Modelhandler. On ajoute ensuite une API en utilisant le fichier .exe généré par notre projet sur Visual Studio.

Problèmes rencontrés:

- Problème dans les héritages des dépendances supplémentaires du projet dans Microsoft Visual Studio: on doit ajouter certaines librairies supplémentaires

- l'API bloque la simulation bien qu'elle compile correctement indépendamment de la simulation

===Semaine 9===

L'API envoyant des données fixes à SCANeR Studio est fonctionnelle.

Les problèmes résolus sont :

- Le format d'envoi des consignes de vitesse et de braquage n'était pas correct (Float au lieu de Double)

- Il est nécessaire de démarrer le moteur en fixant la variable "IgnitionKey" à 3 ce qui correspond à moteur en marche (Engine Start)

- Il est préférable d'écrire sur la variable "TimeOfUpdate" pour "synchroniser" l'envoi de données entre ModelHandler qui fonctionne à 500Hz et notre API qui fonctionne à 100Hz

- On mettra également la boîte de vitesse à 1 (GearBox)

Nous commençons à fusionner l'API client et cette API.

=== Semaine 10===

Les deux API sont fusionnées et nous commençons les tests de notre nouvelle API. Nous l'ajoutons à SCANeR et celle-ci devient rapidement fonctionnelle. Cependant, nous rencontrons des problèmes avec la connexion WIFI qui n'est pas fiable et qui coupe très souvent. En effet, nous avons dans un premier temps créé un réseau ad hoc. Ce type de réseau est facile et rapide à mettre en place mais sa fiabilité reste limitée. Il y a des pertes de données et de connexion assez fréquentes. De plus, La bande passante est limitée. Un problème subsiste donc, le temps de latence entre l'envoi des consignes et l'application de celles-ci au modèle de SCANeR Studio est très important. En d'autres mots, les déplacements du Robucar ne sont pas fiables sur la simulation. Nous avons donc poursuivi les tests en connectant le Robucar et le PC Supervision par Ethernet. Cependant, le cahier des charges nous impose une communication WIFI. Nous nous sommes procuré un routeur que nous avons configuré pour établir une connexion entre les deux appareils.
Après une nouvelle phase de tests, nous constatons que l'angle de braquage des roues dans la simulation n'est pas correct. On multipliera la consigne reçue par un coefficient pour ajuster la valeur car l'angle de consigne doit être en radian alors que le cockpit envoie un entier autour de 2600. Ces réglages, nous obtenons un résultats satisfaisant en terme de rapidité de réponse de la simulation par rapport au véhicule réel.
Par manque de temps, le parking de Polytech Lille utilisé pour jouer la simulation restera d'une apparence des plus basiques.

Guidage et Surveillance d'un véhicule à travers un Cockpit de conduite

2014-04-10T07:18:03Z

Nmartin1 :

Dans le cadre de la quatrième année au sein de la spécialité Informatique-Microélectronique-Automatique, nous allons réaliser un projet permettant de piloter et surveiller
un véhicule autonome à travers un cockpit de conduite. Ce projet sera encadré par Rochdi MERZOUKI et Xavier REDON.

'''Résumé du projet:'''

Dans le cadre du projet InTraDE, transport autonome du fret, nous souhaitons relier le cockpit de conduite de la salle C002 à un véhicule mobile RobuCar.
Pour cela, le cockpit qui fonctionne sous le simulateur de dynamique du véhicule SCANeR Studio, communiquera directement via le réseau WiFi avec un véhicule autonome Robucar.
Tout d'abord, nous modéliserons le parking de Polytech Lille sur le logiciel SCANeR Studio. Ensuite, nous intégrerons à ce terrain un véhicule Robucar déjà modélisé.
Nous élaborerons alors un scénario dans SCANeR mettant en scène plusieurs véhicules, pilotés automatiquement par SCANeR et le Robucar, piloté par une API (Application Programming Interface)
sur le PC supervision. L'objectif de ce projet est de récupérer, par le biais d'une première API, des consignes de vitesse et d'angle de braquage des roues imposées au Robucar (par le biais d'un programme MATLAB déjà opérationnel) et
de les envoyer au PC Supervision où ils seront récupérées par une seconde API. Celle-ci prendra en charge l'acheminement de ces données vers le cockpit et la simulation sur les channels adéquates pour que l'API (ModelHandler) qui contrôle le véhicule simulé prenne en compte ces consignes et les applique au modèle dynamique. De ce fait, nous verrons évoluer en temps réel le Robucar dans la simulation et simultanément,
le volant du cockpit suivra les mouvements du véhicule réel. L'utilisateur pourra ainsi suivre le déplacement de la Robucar dans la simulation et observer, parallèlement, les mouvements du volant dans le cockpit.

'''Pour aller plus loin'''

On pourra également télé-opérer le véhicule réel à tout moment, c'est à dire le piloter via le cockpit. La manipulation pourra éventuellement être réalisée avec deux Robucars.

== Matériel à disposition ==

Pour notre projet nous avons à disposition:

- un véhicule Robucar muni d'un PC intégré et d'une carte d'acquisition DSPACE (en C002)

- les logiciels permettant sa conduite, à savoir Matlab, Simulink et Control Desk

- un PC supervision (en C002)

- un Cockpit de simulation (en C002)

- un Accès au logiciel de simulation SCANeR Studio (en C002)

Nous travaillerons sur le logiciel de développement Microsoft Visual Studio 2005.

== Définition des outils à disposition ==

[[Fichier:scaner.png|370px|thumb|right|Logiciel de simulation Temps Réel SCANeR Studio]]

===SCANeR Studio: Logiciel de simulation pour la recherche et l'ingénierie===

SCANeR Studio est un logiciel de simulation de conduite automobile Temps Réel offrant à ses utilisateurs une interface de surveillance ou de contrôle d'un véhicule (voiture, poids lourd, cycliste, piéton).
Il permet la représentation d'un environnement, modélisé en 3D par le logiciel, auquel un ou plusieurs véhicules sont intégrés.
Les véhicules simulés sont de différents types et on s'intéressera pour notre application aux véhicules "simples" et "Advanced".

Selon leur type, les véhicules sont contrôlés par différentes API (Application Programming Interface) dans SCANeR Studio:

- automatiquement par la simulation : API TRAFFIC. C'est le cas des véhicules de type simples.

- à l'aide d'un élément extérieur tel qu'un cockpit de simulation ou un véhicule réel : API Modelhandler. C'est le cas des véhicule de type Advanced.

Pour réaliser une simulation, il faut un terrain et un scenario. C'est dans le mode scenario que nous choisissons les véhicules à mettre en place dans la simulation. Ici, nous modéliserons le Parking de Polytech Lille puis nous y intégrerons le Robucar (de type véhicule "Advanced") et éventuellement des véhicules simples. Nous choisissons également les API qui seront actives. Ici, les API indispensables sont Modelhandler et l'API que nous avons développé pour lire les consignes envoyées par le serveur et les appliquer dans la simulation. Les deux API vont s'échanger des données par le biais de canaux : les Export Channels. Notre API enverra donc une consigne de vitesse et d'angle de braquage des roues sur des Export Channels définis précisément afin que ModelHandler puissent les informations.

===Le véhicule ROBUCAR===

[[Fichier:robucar.jpg|350px|thumb|right|Véhicule Robucar]]

Le Robucar est un véhicule automatique "intelligent", autonome et électrique, commercialisé par la société ROBOSOFT. Il est composé d'un châssis à quatre roues motrices et directionnelles pilotables séparément.
Il y a donc deux paramètres de commande pour chaque roue : l'orientation et la vitesse de rotation). Le véhicule est équipé d'un ordinateur de bord et d'une carte d'acquisition Temps Réel DSPACE qui récupère les données du véhicule. L'accès à ces données sur d'ordinateur intégré est rendu possible par la librairie CLIB. Celle-ci permet, en effet, de récupérer les données acquise par la DSPACE.

Dans le cadre de notre projet, nous considérons que seules les roues avants du véhicule sont directionnelles. Nous appliquerons donc la même consigne de vitesse et de braquage aux deux roues avant.

===Création d'un Serveur UDP===

Pour créer une communication entre le PC supervision et le PC intégré au Robucar, nous avons choisi de créer un serveur UDP. Nous avons préféré ce protocole au TCP car il est plus rapide et la perte de quelques paquets n'est pas gênante pour notre application. Le serveur est implémenté en langage C++ sur Windows grâce à la bibliothèque Windows Sockets 2 (« Winsock2 »).
Le RobuCar est piloté avec un programme Matlab et son programme Simulink correspondant. On charge dans le logiciel dSPACE ControlDesk du Robucar le programme correspondant à celui sur MATLAB. Une interface apparaît et nous pouvons alors piloter le véhicule. Lors de la conduite, des valeurs de consignes pour la vitesse moyenne et l’angle de braquage des roues sont donc récupérées dans l’API Serveur grâce à la bibliothèque « clib32 ». Sur le PC supervision, l'API Client se connecte au serveur et reçoit alors des paquets contenant une consigne de vitesse et de braquage.

==Journal de bord==

===Semaine 1===
[[Fichier:Parking.png|300px|thumb|right|Parking Polytech Lille modélisé]]

Lors de cette première séance, nous avons pris en main le logiciel SCANeR Studio et notamment le mode terrain qui permet de concevoir un environnement de simulation.
De ce fait, nous avons débuté la conception du parking de Polytech Lille sur le logiciel.

===Semaine 2===

Pendant cette séance, nous avons finalisé la conception du parking sur SCANeR Studio et avons débuté l'élaboration d'un scénario mettant en scène un Robucar qui est de type "vehicle Advanced"
et plusieurs véhicules de type "vehicle simple" qui seront pilotés automatiquement par le logiciel. Le Robucar est piloté par l'API ModelHandler et nous pouvons donc dès à présent tester la fonctionnalité
de notre terrain.

Résultats des simulations sur le terrain:
- Dans certains virages et dans le rond point à l'entrée du parking, le comportement des véhicules en mode automatique est anormal
- Les véhicules se comportent normalement sur les lignes droites, aux Cédez-le-passage et dans les virages à 90 degrés.

Les virages étaient modélisés en "Polyline" ce qui est compliqué à traiter d'un point de vue logiciel. Nous avons dû re-modéliser plusieurs virages en prenant des sections de route plus simples.
Ainsi, les défauts de trajectoire des véhicules sont corrigés. Le parking est opérationnel pour l'élaboration de notre scénario futur.

===Semaine 3===

La prochaine étape est la conception de deux API: un serveur UDP qui sera lancé sur la Robucar et un client, lancé sur le PC de supervision. Nous commençons à nous auto-former sur la conception d'une API sous SCANeR Studio en prenant connaissance de la documentation disponible. On décide de réaliser une API simple qui affiche la vitesse d'un véhicule de type simple. On débute alors la conception de cette API.

En première partie de séance, nous nous entretenons avec le doctorant Vincent XX pour faire un point sur les API. On évoquera entre autre les points suivants:

- comprendre l'utilisation des canaux (EXPORT CHANNEL)

- mettre à disposition la documentation nécessaire pour les utiliser

- comment transformer un projet C++ en une API qui évoluera dans le logiciel

Nous entretiendrons également avec M. Merzouki pour définir plus précisément le cahier des charges. Les points abordés sont les suivants:

- Programmation d'un Serveur UDP sur l'ordinateur intégré au Robucar pour communiquer en WIFI avec une API Client

- Programmation d'une API Client à implanter sur le logiciel SCANeR du PC Supervision

- Conception d'une seconde API permettant d'envoyer des consignes de vitesse et de braquage dans la simulation

- Fusion de ces deux API

En seconde partie de séance, nous commençons à prendre en main l'utilisation des sockets en C++ pour le serveur UDP et l'API Client. Nous utiliserons les sources suivantes:

[http://www.frameip.com/entete-udp/ Frampeip: Serveur en mode non connecté]

[http://rex.plil.fr/Enseignement/Reseau/Reseau.IMA4sc/reseau.html Cours IMASC : Programmation Réseau]

[http://www.linux-france.org/prj/edu/archinet/systeme/index_monopage.html Linux: Tutoriel sur les Serveurs]

===Semaine 4===

Nous commençons à nous focaliser sur le fonctionnement du Robucar. Vincent nous explique comment marche la DSPACE et comment utiliser un programme MATLAB pour récupérer des données du véhicule
tels que la vitesse, l'angle de braquage, la position de la boîte de vitesse etc. On découvre aussi le fonctionnement du Cockpit en utilisant une API déjà fonctionnelle permettant d'envoyer des commandes
au cockpit depuis la simulation. Cette API est implantée sur le logiciel SCANeR du PC Supervision.
Nous continuons la programmation du serveur UDP de l'API Client.

Les Premiers tests du serveur:

- On met le PC Supervision et le PC du Robucar sur le même réseau

- On essaie de se "pinger" l'un l'autre pour vérifier la connexion entre les deux ordinateurs

Problème rencontré:
Les codes du serveur et du client ne compilent pas car il manque des librairies. Nous renseignons les librairies manquantes et corrigeons les erreurs de compilation.

===Semaine 5 ===

Nous réorganisons les codes du serveur et du client avec l'aide de M. Redon. Le serveur et l'API Client ne fonctionne actuellement pas.
Afin d'accéder aux données de la DSPACE, il nous faut utiliser un Parser, programmé par un doctorant ayant travaillé sur le Robucar auparavant. Ce parser prend en paramètre les noms des
variables dans le programme Simulink et nous renvoie leur nom système correspondant, exploitable en C++. Pour cela, il faut indiquer au parser le chemin (path) et le nom exact des variables dans Simulink.
Dans le serveur UDP, on récupère donc grâce à la librairie Clib les valeurs de la vitesse et l'angle de braquage des roues du Robucar.

===Semaine 6===

Le serveur UDP est fonctionnel. Les échanges de paquets entre les deux PC connectés se font rapidement. Grâce à un compteur dans le programme du Serveur, on constate que beaucoup de paquets
sont perdus mais ceci ne devrait pas poser trop de problèmes dans la simulation

===Semaine 7===

On débute la programmation de la seconde API permettant d'envoyer des données à la simulation. Pour ce faire, on doit prendre en main l'écriture sur les EXPORT CHANNELS.
En effet, ils permettent d'échanger des informations entre les différentes API. Ici, on cherche à échanger des données entre cette API et l'API ModelHandler qui pilote le modèle
(Robucar dans la simulation). On va donc renseigner les cases mémoires de la vitesse et de l'angle de braquage des roues dans lesquelles Modelhandler lis ces informations pour les
envoyer sur le modèle de la simulation.

===Semaine 8===

On continue la programmation de l'API elle est terminée rapidement. On réalise les premiers tests de l'API dans Scaner Studio. Pour ce faire, on charge notre terrain (parking de Polytech Lille),
on ajoute un scénario qui dans notre cas est l'ajout d'un véhicule de type Advanced piloté par Modelhandler. On ajoute ensuite une API en utilisant le fichier .exe généré par notre projet sur Visual Studio.

Problèmes rencontrés:

- Problème dans les héritages des dépendances supplémentaires du projet dans Microsoft Visual Studio: on doit ajouter certaines librairies supplémentaires

- l'API bloque la simulation bien qu'elle compile correctement indépendamment de la simulation

===Semaine 9===

L'API envoyant des données fixes à SCANeR Studio est fonctionnelle.

Les problèmes résolus sont :

- Le format d'envoi des consignes de vitesse et de braquage n'était pas correct (Float au lieu de Double)

- Il est nécessaire de démarrer le moteur en fixant la variable "IgnitionKey" à 3 ce qui correspond à moteur en marche (Engine Start)

- Il est préférable d'écrire sur la variable "TimeOfUpdate" pour "synchroniser" l'envoi de données entre ModelHandler qui fonctionne à 500Hz et notre API qui fonctionne à 100Hz

- On mettra également la boîte de vitesse à 1 (GearBox)

Nous commençons à fusionner l'API client et cette API.

=== Semaine 10===

Les deux API sont fusionnées et nous commençons les tests de notre nouvelle API. Nous l'ajoutons à SCANeR et celle-ci devient rapidement fonctionnelle. Cependant, nous rencontrons des problèmes avec la connexion WIFI qui n'est pas fiable et qui coupe très souvent. En effet, nous avons dans un premier temps créé un réseau ad hoc. Ce type de réseau est facile et rapide à mettre en place mais sa fiabilité reste limitée. Il y a des pertes de données et de connexion assez fréquentes. De plus, La bande passante est limitée. Un problème subsiste donc, le temps de latence entre l'envoi des consignes et l'application de celles-ci au modèle de SCANeR Studio est très important. En d'autres mots, les déplacements du Robucar ne sont pas fiables sur la simulation. Nous avons donc poursuivi les tests en connectant le Robucar et le PC Supervision par Ethernet. Cependant, le cahier des charges nous impose une communication WIFI. Nous nous sommes procuré un routeur que nous avons configuré pour établir une connexion entre les deux appareils.
Après une nouvelle phase de tests, nous constatons que l'angle de braquage des roues dans la simulation n'est pas correct. On multipliera la consigne reçue par un coefficient pour ajuster la valeur car l'angle de consigne doit être en radian alors que le cockpit envoie un entier autour de 2600. Ces réglages, nous obtenons un résultats satisfaisant en terme de rapidité de réponse de la simulation par rapport au véhicule réel.
Par manque de temps, le parking de Polytech Lille utilisé pour jouer la simulation restera d'une apparence des plus basiques.