Robot Médical
Présentation et définition du Cahier des charges:
Objectif du projet:
Le but principal de ce projet s'articule autour du développement d'un contrôle autonome d'un robot mobile-manipulateur dédié à la Curiethérapie.
Description du projet:
Le robot médical est un robot manipulateur opérateur appelé Kuka et porté par un robot omnidirectionnel holonome. On voudrait alors réaliser une commande autonome de ce dernier, en lui attribuant une trajectoire optimale au centre de l'outil de l'aiguille de radiothérapie afin que le robot puisse générer les mouvements nécessaires pour la réalisation de cette mission. On passerait donc d'un contrôle permanent du robot avec un pad ou d'une Wiimote, à une gestion parfaitement autonome de celui-ci. Rappelons que ce projet a une finalité outre qu'académique puisqu'il se fait en collaboration avec le centre de radiothérapie de Lille.
Matériel principal disponible:
- Chassis du robot.
- 4 roues motrices contrôlées par 4 contrôleurs + 4 moteurs
- Un raspberry pi connecté aux 4 contrôleurs.
- Un module CompactRIO.
- Une centrale inertielle.
Tâches à réaliser:
- Effectuer le modèle cinématique inverse de la position de notre robot afin de commander les 4 roues motrices en vitesse. Ce modèle sera calculé en fonction des mesures effectuées grâce aux capteurs de position situés sur le centre de gravité de chacune des roues.
- Créer une simulation du modèle obtenu et de la commande permettant d'automatiser le robot.
- Ajouter des capteurs infrarouges au châssis du robot afin que celui-ci puisse éviter d'éventuel obstacle au cours de son déplacement.
- Implémenter le résultat.
Avancement du projet:
Semaine 1 (03/02/2014):
Durant cette première semaine, nous allons surtout nous familiariser avec notre projet. Pour cela, nous commençons par lister tous les composants qui constituent notre projet que nous aurions à prendre en main par la suite. Nous avons pu nous documenter sur les moteurs du robot par exemple et tester le programme déjà implémenté qui permet un contrôle du chassis avec une Wii mote. Cela nous permet de mieux cerner le fonctionnement holonome de notre robot.
En résumé:
- découverte du matériel.
- documentation.
- prise en main du projet + démo robot.
- Installation des logiciels requis.
Semaine 2 (10/02/2014):
Au cours de cette semaine, nous avons eu un premier contact avec notre tuteur de projet afin de fixer le cahier des charges et les objectifs attendus de la réalisation de ce projet. Nous avons établi le schéma suivant qui résume bien le fonctionnement demandé du système:
En somme, nous devons pouvoir générer une trajectoire aléatoire qui doit être ensuite réalisée par notre robot de façon totalement autonome. De ce fait, une MCI (modèle cinématique inverse) sera réalisée afin de déterminer la matrice qui régie notre système.
D'un autre côté, une prise en main du logiciel Labview est faite, un logiciel qui nous permettra par la suite de pouvoir programmer le CompactRIO et la centrale inertielle.
En résumé:
- prise de contact avec notre tuteur projet.
- définition du cahier des charges.
- prise en main de labview.
Semaine 3 (17/02/2014):
Afin de mieux cerner quelques points qui nous paraissaient encore flous concernant notre projet, nous avons décidé de faire appel à philippe Gombault, étudiant en IMA5 qui avait précédemment travaillé sur ce même projet l'an passé. Ce dernier nous a prodigué de précieux conseils, notamment celui de réaliser une sauvegarde de la carte SD du raspberry pi avant toute utilisation. Afin d'éviter tout risque de détérioration du précédent projet qui est en parfait état de marche, nous avons donc suivi ses conseils et nous avons réalisé une sauvegarde de la carte que nous gardons précieusement en cas de besoin.
Par ailleurs, nous nous sommes également attelé à la prise en main de la centrale inertielle que notre encadrant a mis à notre disposition. Ce petit composant technologique nous permettra par la suite d'enregistrer les déplacements du robot dans l'espace. Sa prise en main se fait principalement grâce au logiciel Labview, préalablement téléchargé et installé. On peut s'y connecter et y accéder par USB à l'aide des câbles fournis
Nous avons également décidé de commencer un modèle géométrique inverse du système afin de réaliser sa modélisation.
En résumé:
- prise de contact avec Philippe Gombault.
- sauvegarde de la carte SD.
- prise en main de la centrale inertielle Xsens.
- Réalisation MGI en cours.
Semaine 4 (3/03/2014):
Après tenté de réaliser une MGI durant la semaine précédente, nous nous sommes rendus compte que ce modèle la n'était pas le plus efficace pour modéliser notre système. En fait, nous avons rencontré quelques difficultés au niveau des calculs, principalement liées au fait que notre robot n'est pas adapté à ce genre de modélisation. Nous avons donc basculé sur un MCI (modèle cinématique inverse), un choix qui nous parait plus judicieux et plus réalisable.
Au cours de cette semaine, nous avons également eu un contact avec notre encadrant qui nous a donné quelques directives en plus. Il nous a notamment conseillé de nous documenter sur le net afin de trouver des capteurs optiques que l'on pourrait ajouter à notre robot pour que ce dernier puisse également gérer la détection d'obstacles pour pouvoir les éviter. Nous nous sommes donc attelés à cette tâche également, en parallèle avec les précédentes démarches déjà entamées.
En résumé:
- MGI inexploitable, réalisation du MCI en cours
- Prise de contact avec notre tuteur de projet + recherche capteurs
Semaine 5 (10/03/2014):
A ce stade du projet, nous avons réussi à faire plusieurs avancées. L'une des premières que l'on peut citer est la réalisation d'un modèle cinématique direct (nous avions prévu de réaliser un modèle cinématique inverse, mais il se trouve qu'il est préférable et plus simple de passer par un modèle direct. Le modèle inverse peut ensuite être obtenu aisément). Ce dernier nous semble correct, mais nous avons décidé d'attendre une validation par notre professeur encadrant avant d'en réaliser une simulation pour en vérifier le fonctionnement.
Autre point important, le contrôle de la centrale inertielle: ce dernier semble fonctionnel, nous arrivons à récupérer correctement, à partir d'un programme Labview, les valeurs que le Xsens nous renvoie en fonction du déplacement de ce dernier dans l'espace.
En plus de recevoir l’accélération en X, Y et Z et la vitesse de rotation en X, Y et Z, l’utilisateur reçoit les angles d’Euler. Les angles d’Euler sont les angles indiquant la position du repère de la centrale inertielle par rapport au repère terrestre.
Etant donnée que cette partie du projet semble bien fonctionner, nous décidons donc de nous attaquer aux autres composants que l'on doit tous aussi bien pouvoir contrôler, à savoir le raspberry Pi et le module CompactRIO
En résumé:
- Réalisation du MCD
- Controle de la centrale inertielle sur labview actif
- capteurs commandés par l'encadrant.
- Prise en main CompactRIO
- Prise en main Raspberry Pi
Semaine 6 (17/03/2014):
Après voir eu une entrevue avec notre encadrant, nous avons pu valider notre modèle cinématique direct, non sans quelques corrections. Au final, nous obtenons la matrice suivante pour notre système, qui prend en entrée les vitesses angulaires de chaque roue pour obtenir en sortie la position du chassis en fonction de X et Y ainsi que de l'angle de lacet Phi:
.PNG)
A partir de ce modèle ci, nous pouvons facilement établir le modèle inverse en calculant la matrice inverse de notre système. Pour cela, nous utiliserons un logiciel de calcul formel tel que Maple, qui nous donnera un résultat très rapidement.
En parallèle a la modélisation du modèle, nous nous sommes heurtés à quelques difficultés au niveau de la prise en main de nos deux principaux modules, le CompactRIO et le Raspberry pi. Ces obstacles nous ont quelques peu ralentis dans la progression de notre projet.
En résumé:
- Correction et Validation du MCD par notre professeur.
- Réalisation du MCI à l'aide de Mapple.
- Difficultés logiciels rencontrés au niveau de Labview + CompactRIO
- Difficultés de prise en main au niveau du Raspberry Pi
Semaine 7 (24/03/2014):
Après avoir réussi à obtenir nos différents modèle cinématiques, direct et inverse, nous pouvons à présent les tester en simulation grâce au logiciel matlab simulink:
Il s'avère qu'après avoir réalisé cette simulation, nous obtenons des résultats très satisfaisants qui corroborent la matrice précédemment établie:
Par ailleurs, nous avons également pu avoir accès à notre raspberry pi grâce à l'intervention de M. Redon qui nous a aidé franchir les obstacles auxquels nous étions confrontés à ce niveau là. Cependant, quelques difficultés subsistent encore du côté du CompactRIO, à prioro à cause d'un version de logiciel non compatible avec ce dernier.
En résumé:
- Contrôle du raspberry actif (Aide de M. Redon)
- Implémentation et simulation du MC sur Matlab.
Semaine 8 (31/03/2014):
Après avoir pu accéder au raspberry pi, nous pouvons maintenant accès aux programmes qu'il contient également. Ces derniers vont nous donner une idée du langage python, des entrées/sorties à utiliser pour communiquer avec les contrôleurs ainsi que la façon de les utiliser. De ce fait, le programme que l'on se doit d'implémenter sera similaire aux autres à ce niveau, il devra par contre inclure une "procédure" qui permettrait de communiquer et de recevoir des messages par protocole UDP. Pour cela et après quelques recherches sur le net au sujet du langage python, nous pouvons utiliser le programme suivant:
Il ne restera plus qu'à traiter le message obtenu, en fragmentant le message reçu et en attribuant à chaque contrôleur, la consigne adéquate.
Du côté du programme pour le CompactRIO, nous avons réussi à en avoir un qui semble fonctionnel. Il comporte une implémentation de la matrice de notre système issue du modèle inverse, ainsi qu'un protocole UDP qui servira par la suite à envoyer les commandes sur le raspberry pi qui fait office d'intermédiaire entre ce dernier et le contrôle des roues.
En résumé:
- Prise en main du langage python et création d'un nouveau programme contenant un protocole UDP pour la réception.
- Réalisation d'un programme labview avec protocole UDP pour la transmission.
Semaine 9 (07/04/2014):
Durant cette dernière semaine, nous allons nous faire le bilan de ce qui a été fait jusqu'ici et nous commencerons à préparer notre rapport ainsi que notre présentation orale.
En définitif, nous n'avons pas pu régler nos soucis avec le logiciel Labview. Par conséquent, nous n'avons pas pu implémenter nos résultats sur le module CompactRIO comme cela était prévu initialement. Sans cette implémentation, nous ne pouvons pas non plus tester notre programme python de réception de données, ceci malgré une modélisation et une simulation qui montrent que nos réalisations avec toutes les chances de fonctionner.
En résumé:
- Derniers tests du programme Labview
- Dernieres améliorations du programme python
- bilan + prépation rapport écrit et soutenance orale.
Conclusion:
En guise de conclusion, on peut dire que nous n'avons pas pu outrepasser les difficultés logicielles auxquelles nous avons été confrontés, et ceci malgré des résultat totalement exploitables. Cependant, notre travail ne sera pas vain puisqu'à travers ce projet, nous avons pu expérimenter les différentes phases de suivi et de réalisation d'un projet, de la modélisation jusqu'à l'implémentation. Nous avons également pu mettre à profit nos différentes connaissances acquises dans une multitude de domaines et confronter notre sens de l'organisation, de la gestion et de l'autonomie à un sujet bien réel et à des fins utiles.
Rapport du projet: Fichier:Rapport projet.pdf
