Wiki de Projets IMA - Contributions de l’utilisateur [fr]

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-02-21T12:00:58Z

Dmarruch : /* Rapport */

''Etudiante : Diana Marrucho ''
''Encadrants : Rochdi Merzouki, Othman Lakhal''

== Présentation générale du projet ==

===Contexte du projet===
La société All-Trends est une start-up lilloise développant la technologie e-Bridium® de fabrication additive directe à granulés en plasturgie dans le but d'imprimer des pièces en polymère à partir de granulés plastiques non-propriétaires.

Dans le cadre du programme Centaure, All-Trends s'est associée à Polytech Lille et le laboratoire CRIStAL afin de l'accompagner pour la réalisation d'un prototype d'impression 3D robotisé à base des granulés. Une buse, permettant la fusion des granulés est fixée à un robot Kuka pour pouvoir imprimer dans toutes les positions.

Actuellement, des pièces à base de PS (Polystyrène) ont été réalisées en salle C002 à Polytech Lille et des tests sont effectués les vendredis.
[[Fichier:GCODE_EBRIDIUM.png|700px|thumb|center|Robot KUKA et Buse ALL-TRENDS.]]
[[Fichier:GCODE_PIECES.png|700px|thumb|center|Pièces imprimées en PS.]]

==Cahier des charges==

===But du projet===
Dans une première partie, l'objectif est de tester différents types de matières et d'en contrôler la régulation de température de la buse en fonction des granulés utilisés.

Actuellement, le robot est contrôlé par un contrôleur ''CompactRIO'' de ''National Instruments''.
La seconde partie du projet consisterait donc à intégrer le programme de commande sur une ''MyRIO'' de ''National Instruments''.

Pour se faire, l'utilisation du logiciel LabVIEW est nécessaire.

===Planning Prévisionnel===
*Semaine 1 :
**Apprentissage du LabVIEW ;
*Semaine 2 :
**Prise en main sur la programmation et la commande du dispositif robotisé existant ;
*Semaine 3-4 :
**Test d'impression et régulation pour trois différentes matières ;
*Semaine 5 :
**Intégration du programme de commande et supervision embarqué sur une MyRIO de ''National Instruments'' ;
*Semaine 6 :
**Test et validation ;
**Rédaction du rapport.

==Avancement du projet==
===Semaine 1 (du 11/01/2018 au 14/01/2018)===
*A partir de mercredi, j'ai repris en main le logiciel LabVIEW. Lecture de la documentation d'utilisation Labview et du CompactRIO de ''National Instruments'' :
**Lien de la documentation :[https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwjSvrTkydnYAhVEtBQKHSUaDIcQFggxMAE&url=http%3A%2F%2Fwww.mit.bme.hu%2Fsystem%2Ffiles%2Foktatas%2Ftargyak%2F7258%2Fcriodevgudfull.pdf&usg=AOvVaw3ZNQC-jm6kkskpguWi_ZzS]
*Réalisation de tests sur la jambe de cheval : contrôle par LabVIEW via CompactRIO, analog output, du système électro-pneumatique pour le contrômle des muscles de la jambe de cheval.
*'''Nouvel objectif : réaliser un interpréteur du G-Code via LabVIEW afin de pouvoir tout contrôler directement par National Instruments sans l'utilisation de Matlab. Attention à prendre en compte que ce n'est pas la plateforme support qui se déplace mais le bras robot Kuka.'''
*Vendredi : en présence de monsieur Grégory SANT de la société All-Trends, nous avons effectués des tests d'impression de pièces 3D avec des granulés de polystyrène en effectuant des variations des deux anneaux de température, de débit de sortie de buse, de vitesse ou de hauteur afin de pouvoir renseigner les paramètres les plus optimaux pour le robot industriel et la tête d'impression All-Trends. L'objectif des prochains tests sera de diminuer la taille de la buse afin de se rendre compte de son impact sur la pièce imprimée et surtout de pouvoir avoir une résolution maximale avec un temps réduit. Effectivement, contrairement à une imprimante 3D classique, ce robot plutôt destiné à l'industrie, permet de sortir 700g de matériaux à l'heure contre 1kg la journée pour l'imprimante classique. De plus, le coût de la matière est moindre contrairement au fil qui est déjà dégradé par sa transformation en fil.

===Semaine 2 (du 15/01/2018 au 21/01/2018)===
*Actuellement, afin de pouvoir réaliser des impression, ''Matlab'' était utilisé afin de générer les différentes trajectoires. Les pièces réalisées jusqu'à présent sont des pièces dont le périmètre était imprimé, sans grand angle et sans support pour une pièce déportée. L'objectif de la semaine 2 est donc de pouvoir tester de nouvelles formes.
*Afin de pouvoir convertir le fichier 3D, généralement de format STL, on utilise le slicer CURA que l'on paramètre avec les données correspondant au diamètre de la buse utilisée, à la température des couronnes et du plateau chauffant, au diamètre de sortie du cordon, à la hauteur de couche...
*Le but de cette semaine est donc de réaliser un interpréteur avec ''LabVIEW'' capable de transformer le G-Code en fichier CSV :
**Dans un premier temps, j'ai d'abord cherché à récupérer toutes les données du gcode et les indexer dans un tableau :
[[Fichier:GCODE1.PNG|700px|thumb|center|Récupération des données du Gcode par LabVIEW.]]
*Ensuite, afin de ne garder que les données qui nous intéressent, à savoir les lignes de code contenant les commandes en G, j'ai récupéré selon toutes les différentes commandes (à savoir les commandes selon G0, G1, G2, G3, G4, G20, G21, G28, G29, G90, G91 et G92 selon la documentation du ''Wiki RepRap'' [http://reprap.org/wiki/G-code/fr#M205_Repetier]
*A partir de mercredi, et de la lecture du document ''Software KUKA.CAMRob KRC 3.0'', et des paramètres que CAMRob peut prendre en considération, je me suis limitée à la récupération des données correspondantes. En effet, le fichier de donnée CAM peut contenir jusqu'à 26 paramètres selon des positions bien précises. Ainsi, voici les données pouvant être récupérées pour le fichier CSV utilisé par CAMRob :
[[Fichier:GCODE2.PNG|700px|thumb|center|CAMRob data parameters.]]
*Les données récupérées seront donc les cordonnées cartésiennes selon les axes X, Y et Z pour les paramètres 2, 3 et 4. Suite au paramétrage de la buse et de la base du robot Kuka, on récupère les rotations A, B et C. Car elles ne sont pas paramétrées dans le slicer. De plus, on y introduit la vitesse de 0.04m/s qui sera ensuite réglée en pourcentage sur CAMRob, ainsi que l'accélération que l'on a fixé à 1m/s². Tous les autres paramètres sont fixés à 0 car non utilisés. Cela me donne donc en face avant et diagramme de LabVIEW les aperçus suivants :
[[Fichier:GCODE3.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE4.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Vendredi, suite à des tests dès le matin avec la présence de messieurs Gragory SANT et Othman LAKHAL, nous avons imprimé pour la première fois avec le Polystyrène, des pièces pleines. Cela fut dans un premier temps compliqué car le slicer CURA n'était pas très précis concernant les premières couches, le motif du remplissage et les pièces n'étaient donc pas parfaites. Nous avons donc essayé d'imprimer des pièces basiques (des disques, des rectangles, une attache fleur, une raquette sans angles et ne nécessitant pas de support) avec différents remplissages (entre 15 et 100%). Suite aux réglages des différents paramètres, au changement de slicer vers ''Slic3r'' qui est plus précis et qui nous permet de ne pas faire de motif de remplissage aléatoirement et aux différents tests de la journée, notre réglage le plus précis était donc le suivant :
**Température Haute de la buse : 250°C ;
**Température Basse de la buse : 260°C ;
**Vitesse : 75% de 0.04m/s ;
**Débit : 0.04V.
**Et dont les paramètres sur ''Slic3r'' étaient les suivants :
[[Fichier:GCODE5.png|1000px|thumb|center|Slic3r Parameters.]]

===Semaine 3 (du 22/01/2018 au 28/01/2018)===
*Le premier objectif de cette semaine est maintenant de prendre en compte les vitesses générées par le slicer et non plus de la fixer nous même sur CAMRob en pourcentage de la vitesse maximale. Pour cela, je vais récupérer les données selon le paramètre F des commandes G. Les vitesses sont différentes selon que nous sommes en remplissage, en support, en transfert d'un point à l'autre ou encore en périmètre.
*De plus, suite aux problèmes rencontrés vendredi, c'est-à-dire que certaines cases étaient vides donc posaient problème lors de la lecture par CAMRob du fichier CSV, j'ai supprimé ses cases car elles permettaient de ne pas fournir de matière PS à la buse pour aller d'un point à l'autre, mais la communication ne se fait pas encore directement entre CAMRob et le CompactRIO.
*Voici donc le diagramme réalisé et la face avant sur LabVIEW :
[[Fichier:GCODE6.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE7.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Afin de pouvoir récupérer les données générées par notre fichier CSV lu par ''CAMROB'', il est nécessaire d'établir une liaison RSI. Cette liaison RSI entre le robot et le PC est nécessaire pour récupérer la vitesse du moteur de la buse afin de ne plus avoir à la fixer nous même.
*Le prochain objetif est donc de tester de nouvelles pièces pleines ou creuses avec les nouveaux réglages, et par la suite commencer à tester des pièces avec nécessité de support car présentent des angles importants et/ou sont déportées.
*Mercredi :
**Test des trajectoires sur le robot KUKA du nouveau programme et essai d'un début de pièce avec support : remarque que le plateau de verre était soumis à une quantité importante de vibrations surtout au changement de trajectoire sur petites pièces même en contrôle T1 (c'est-à-dire sans mode auto). Il était donc nécessaire de trouver un moyen de fixation et de stabilisation pour les futurs tests.

*Cette semaine, et dans un second temps, j'ai optimisé le fichier ''LabVIEW'':
**Réalisation de sous-VI de chaque récupération des données intéressanteS (positions X, Y, Z, vitesse F, et vitesse moteur E en tour/min) afin de simplifier l'affichage et de permettre une meilleure ergonomie de l'interface :
[[Fichier:GCODE_X.PNG|1000px|thumb|center|Récupération du paramètre X (idem pour Y et Z avec limite de 0).]]
[[Fichier:GCODE_F.PNG|1000px|thumb|center|Récupération de la variable vitesse robot F et conversion en m/s]]
[[Fichier:GCODE_CALCUL_E.PNG|1000px|thumb|center|Calcul de la valeur de la vitesse moteur E à partir de F.]]
[[Fichier:GCODE_E.PNG|1000px|thumb|center|Récupération de la valeur E et rotation inverse si valeur nulle.]]
[[Fichier:Interface_GCODE.PNG|1000px|thumb|center|Interface utilisateur Labview pour G-Code en CSV.]]

*Tests du vendredi et avancées :
**Ce vendredi, Othman a mis en place la liaison RSI entre le robot (CAMROB) et LabVIEW afin d'envoyer la vitesse moteur traduite par la relation . Cette liaison consiste dons à récupérer la vitesse du moteur de l'extrudeur et de passer en mode auto.
**Tests :
***1er test : pièce pleine avec un remplissage de 30% sur une forme parallélépipédique avec une vitesse du robot à 50% de vitesses de périmètres et de transfert à 60mm/sec, et une vitesse de remplissage à 80mm/sec. Notre première remarque était que le robot était trop lent donc arrêt au bout de 3 couches.
***2nd test : pièce identique réduite de 50% selon les axes X et Y pour permettre une réalisation plus rapide, mais avec un remplissage de 30% à une vitesse de 75%. Le robot est légèrement plus rapide et de ce fait nous avons pu terminer la pièce dans les délais. Les principales remarques étaient que les contours étaient effectués trop rapidement, et que l'intérieur, donc le remplissage de la pièce à 30% était bien trop rapide et débitait donc trop de matière.
***3ème test : pièce identique, avec un remplissage à 15% et une diminution de la vitesse de remplissage et de transfert avec les nouveaux paramètres.

**Conclusion de ces tests : nous pouvons désormais réaliser des pièces pleines grâce à l'interface ''LabVIEW'', mais les paramètres de l'impression sont encore à améliorer pour le polystyrène. La dernière pièce réalisée lors de ces tests est prometteuse. Maintenant, il faut chercher les paramètres à récupérer pour améliorer la qualité de l'impression, et surtout augmenter la rapidité et donc optimiser au mieux la quantité de matière pouvant être utilisée dans l'heure (pour rappel 700g/heure de granulés peuvent être transformés par cette buse). Enfin, lors de nos essais, lorsque les moteurs s'arrêtaient, c'est à dire à 0tr/min, il y avait toujours un dépot de matière qui se faisait. Pour eviter ce phénomène, il serait intéressant de voir si nous pouvons réaliser une rétractation de la matière comme il est possible de le faire sur certaines machines 3D telles que celles du fabricarium de l'école.

*Un des objectifs de la semaine prochaine est donc de réaliser de nouvelles pièces et de permettre une meilleure finition de pièce et donc de changer les paramètres en fonction de notre avancée. Tester aussi si on ajoute des couches supplémentaires au dessus où en dessous pour observer une meilleure finition.

===Semaine 4 (du 29/01/2018 au 04/02/2018)===
*Pour contrôler l'un des paramètres qui posaient problème la semaine passée, j'ai tout d'abord essayé de réaliser une rétractation de la matière.
Pour cela, lorsque le débit doit être nul, j'ai remplacé la vitesse du moteur qui était à 0 tour/min à -10 tour/min qui permettra d'éviter un dépot de matière supplémentaire sur la pièce imprimée.

*L'un des objectif de cette semaine ainsi que de la semaine 5 est d'établir une connexion RSI complète entre Labview et le Kuka :
**Actuellement, le cheminement suivant doit être suivi pour établir la connexion avec le KUKA doit passer par CAMROB, license expensive :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> USB -> Kuka CAMROB -> RSI -> Labview
**Le but est de diminuer toutes les manipulations intermédiaires et de réaliser le cheminement suivant :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> RSI -> Communiquer avec KUKA et Tête D'impression (Buse ALLTRENDS)

*Vendredi, nous avons imprimé pour la première fois des pièces telles une grenouille et des parallélépipèdes afin de contrôler la vitesse et de présenter à une entreprise intéressée par le projet, le travail effectué. Nous avons remarqué que la vitesse introduite n'était pas respectée. En effet, en ayant bridé l'accélération à 0.1m/s², le robot limitait donc la vitesse et on observait donc une dégradation de la matière à l'intérieur de la buse. Lors du dernier essai de la journée, nous avons modifié ce paramètre, et effectivement, la dégradation du polystyrène était moins observée.
[[Fichier:GCODE_CUBE.PNG|1000px|thumb|center|Support et premières couches du cube.]]
[[Fichier:GCODE_GRENOUILLE.PNG|1000px|thumb|center|Première grenouille imprimée.]]
On a remarqué qu'il faudrait améliorer les contours par la suite.

===Semaines 5, 6 et 7 (du 05/02/2018 au 20/02/2018)===
*Le contrôleur MYRio a été commandé semaine 5 et réceptionné le jeudi 15 février.

*Ensuite, l'objectif des semaines 4 et 5 est donc d'établir la connexion RSI entre Labview et Kuka.
La connexion RSI (Robot Sensor Interface) qui est une interface de communication Ethernet entre le robot industriel et un système de capteurs, et qui doit être intégré au programme KRL.
Pour se faire, il est nécessaire d'établir des fichiers SRC, XML et RSI. J'utilise donc le logiciel ''RSIVisualShell'' afin de réaliser la connexion RSI.

*Les données prévelées du fichier CSV généré par ''Labview'' sont donc inscrites en entrées par réception de bloc de données au format XML.
Le mode de traitement des signaux est fixé à 12ms avec filtrage (variable de champ #IPO).

*Ci-dessous les fichiers réalisés :
**Fichier XML :
[[Fichier:GCODE_XML.png|1000px|thumb|center|Fichier XML.]]
**Fichier RSI :
[[Fichier:GCODE_RSI.PNG|1000px|thumb|center|Fichier RSI.]]
**Fichier SRC :
[[Fichier:GCODE_SRC.png|1000px|thumb|center|Fichier SRC.]]

Difficultés rencontrées :
*Durant presque une semaine, j'ai été bloquée suite à l'ajout inopportun d'un espace vide qui ne permettait donc pas la lecture du fichier RSI ;
*Le fichier source 8 jours avant d'être débloqué. En effet, j'avais effectué les essais sur le partage d'une seule donnée via la liaison RSI et le problème d'envoi/réception était correct. Cependant, lorsque j'ai ajouté toutes les valeurs à transmettre, le robot envoyait bien les instructions mais ne recevait aucune variable. Lundi 19 février j'ai donc décidé de reprendre le code ligne par ligne pour voir la différence, et en copiant le programme SRC initial ligne par ligne, j'ai supprimé l'erreur tout en conservant exactement le même code. Je soupçonne donc que des caractères inscrits dans mon fichier posaient problème mais je ne sais pas lesquels.
*Ensuite, toujours dans le fichier source, j'ai eu de la difficulté à trouver le moyen de changer les base et outil pour le système Robot+Buse, mais après lecture de la documentation, l'aide de Othman, j'ai finalement trouvé l'erreur ;
*Pour finir, la dernière difficulté rencontrée réside en l'affectation en temps réelle de la vitesse du robot. En effet, je souhaitais effectuer directement l'affectation via les variables $VEL.CP=$SEN_PREA[9], or celle-ci doit être modifiée via la commande BAS(VEL_CP,$SEN_PREA[9]). J'ai donc passé ma journée de mardi à résoudre ce problème.

===Semaine 7 + Soutenance (du 20/02/2018 au 21/02/2018)===
*Finalisation du projet.
*Rédaction du rapport.
*Réalisation de la présentation

==Rapport==
Rapport rendu : [[Fichier:MARRUCHO Diana Rapport PFE.pdf]]

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-02-21T12:00:12Z

Dmarruch :

''Etudiante : Diana Marrucho ''
''Encadrants : Rochdi Merzouki, Othman Lakhal''

== Présentation générale du projet ==

===Contexte du projet===
La société All-Trends est une start-up lilloise développant la technologie e-Bridium® de fabrication additive directe à granulés en plasturgie dans le but d'imprimer des pièces en polymère à partir de granulés plastiques non-propriétaires.

Dans le cadre du programme Centaure, All-Trends s'est associée à Polytech Lille et le laboratoire CRIStAL afin de l'accompagner pour la réalisation d'un prototype d'impression 3D robotisé à base des granulés. Une buse, permettant la fusion des granulés est fixée à un robot Kuka pour pouvoir imprimer dans toutes les positions.

Actuellement, des pièces à base de PS (Polystyrène) ont été réalisées en salle C002 à Polytech Lille et des tests sont effectués les vendredis.
[[Fichier:GCODE_EBRIDIUM.png|700px|thumb|center|Robot KUKA et Buse ALL-TRENDS.]]
[[Fichier:GCODE_PIECES.png|700px|thumb|center|Pièces imprimées en PS.]]

==Cahier des charges==

===But du projet===
Dans une première partie, l'objectif est de tester différents types de matières et d'en contrôler la régulation de température de la buse en fonction des granulés utilisés.

Actuellement, le robot est contrôlé par un contrôleur ''CompactRIO'' de ''National Instruments''.
La seconde partie du projet consisterait donc à intégrer le programme de commande sur une ''MyRIO'' de ''National Instruments''.

Pour se faire, l'utilisation du logiciel LabVIEW est nécessaire.

===Planning Prévisionnel===
*Semaine 1 :
**Apprentissage du LabVIEW ;
*Semaine 2 :
**Prise en main sur la programmation et la commande du dispositif robotisé existant ;
*Semaine 3-4 :
**Test d'impression et régulation pour trois différentes matières ;
*Semaine 5 :
**Intégration du programme de commande et supervision embarqué sur une MyRIO de ''National Instruments'' ;
*Semaine 6 :
**Test et validation ;
**Rédaction du rapport.

==Avancement du projet==
===Semaine 1 (du 11/01/2018 au 14/01/2018)===
*A partir de mercredi, j'ai repris en main le logiciel LabVIEW. Lecture de la documentation d'utilisation Labview et du CompactRIO de ''National Instruments'' :
**Lien de la documentation :[https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwjSvrTkydnYAhVEtBQKHSUaDIcQFggxMAE&url=http%3A%2F%2Fwww.mit.bme.hu%2Fsystem%2Ffiles%2Foktatas%2Ftargyak%2F7258%2Fcriodevgudfull.pdf&usg=AOvVaw3ZNQC-jm6kkskpguWi_ZzS]
*Réalisation de tests sur la jambe de cheval : contrôle par LabVIEW via CompactRIO, analog output, du système électro-pneumatique pour le contrômle des muscles de la jambe de cheval.
*'''Nouvel objectif : réaliser un interpréteur du G-Code via LabVIEW afin de pouvoir tout contrôler directement par National Instruments sans l'utilisation de Matlab. Attention à prendre en compte que ce n'est pas la plateforme support qui se déplace mais le bras robot Kuka.'''
*Vendredi : en présence de monsieur Grégory SANT de la société All-Trends, nous avons effectués des tests d'impression de pièces 3D avec des granulés de polystyrène en effectuant des variations des deux anneaux de température, de débit de sortie de buse, de vitesse ou de hauteur afin de pouvoir renseigner les paramètres les plus optimaux pour le robot industriel et la tête d'impression All-Trends. L'objectif des prochains tests sera de diminuer la taille de la buse afin de se rendre compte de son impact sur la pièce imprimée et surtout de pouvoir avoir une résolution maximale avec un temps réduit. Effectivement, contrairement à une imprimante 3D classique, ce robot plutôt destiné à l'industrie, permet de sortir 700g de matériaux à l'heure contre 1kg la journée pour l'imprimante classique. De plus, le coût de la matière est moindre contrairement au fil qui est déjà dégradé par sa transformation en fil.

===Semaine 2 (du 15/01/2018 au 21/01/2018)===
*Actuellement, afin de pouvoir réaliser des impression, ''Matlab'' était utilisé afin de générer les différentes trajectoires. Les pièces réalisées jusqu'à présent sont des pièces dont le périmètre était imprimé, sans grand angle et sans support pour une pièce déportée. L'objectif de la semaine 2 est donc de pouvoir tester de nouvelles formes.
*Afin de pouvoir convertir le fichier 3D, généralement de format STL, on utilise le slicer CURA que l'on paramètre avec les données correspondant au diamètre de la buse utilisée, à la température des couronnes et du plateau chauffant, au diamètre de sortie du cordon, à la hauteur de couche...
*Le but de cette semaine est donc de réaliser un interpréteur avec ''LabVIEW'' capable de transformer le G-Code en fichier CSV :
**Dans un premier temps, j'ai d'abord cherché à récupérer toutes les données du gcode et les indexer dans un tableau :
[[Fichier:GCODE1.PNG|700px|thumb|center|Récupération des données du Gcode par LabVIEW.]]
*Ensuite, afin de ne garder que les données qui nous intéressent, à savoir les lignes de code contenant les commandes en G, j'ai récupéré selon toutes les différentes commandes (à savoir les commandes selon G0, G1, G2, G3, G4, G20, G21, G28, G29, G90, G91 et G92 selon la documentation du ''Wiki RepRap'' [http://reprap.org/wiki/G-code/fr#M205_Repetier]
*A partir de mercredi, et de la lecture du document ''Software KUKA.CAMRob KRC 3.0'', et des paramètres que CAMRob peut prendre en considération, je me suis limitée à la récupération des données correspondantes. En effet, le fichier de donnée CAM peut contenir jusqu'à 26 paramètres selon des positions bien précises. Ainsi, voici les données pouvant être récupérées pour le fichier CSV utilisé par CAMRob :
[[Fichier:GCODE2.PNG|700px|thumb|center|CAMRob data parameters.]]
*Les données récupérées seront donc les cordonnées cartésiennes selon les axes X, Y et Z pour les paramètres 2, 3 et 4. Suite au paramétrage de la buse et de la base du robot Kuka, on récupère les rotations A, B et C. Car elles ne sont pas paramétrées dans le slicer. De plus, on y introduit la vitesse de 0.04m/s qui sera ensuite réglée en pourcentage sur CAMRob, ainsi que l'accélération que l'on a fixé à 1m/s². Tous les autres paramètres sont fixés à 0 car non utilisés. Cela me donne donc en face avant et diagramme de LabVIEW les aperçus suivants :
[[Fichier:GCODE3.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE4.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Vendredi, suite à des tests dès le matin avec la présence de messieurs Gragory SANT et Othman LAKHAL, nous avons imprimé pour la première fois avec le Polystyrène, des pièces pleines. Cela fut dans un premier temps compliqué car le slicer CURA n'était pas très précis concernant les premières couches, le motif du remplissage et les pièces n'étaient donc pas parfaites. Nous avons donc essayé d'imprimer des pièces basiques (des disques, des rectangles, une attache fleur, une raquette sans angles et ne nécessitant pas de support) avec différents remplissages (entre 15 et 100%). Suite aux réglages des différents paramètres, au changement de slicer vers ''Slic3r'' qui est plus précis et qui nous permet de ne pas faire de motif de remplissage aléatoirement et aux différents tests de la journée, notre réglage le plus précis était donc le suivant :
**Température Haute de la buse : 250°C ;
**Température Basse de la buse : 260°C ;
**Vitesse : 75% de 0.04m/s ;
**Débit : 0.04V.
**Et dont les paramètres sur ''Slic3r'' étaient les suivants :
[[Fichier:GCODE5.png|1000px|thumb|center|Slic3r Parameters.]]

===Semaine 3 (du 22/01/2018 au 28/01/2018)===
*Le premier objectif de cette semaine est maintenant de prendre en compte les vitesses générées par le slicer et non plus de la fixer nous même sur CAMRob en pourcentage de la vitesse maximale. Pour cela, je vais récupérer les données selon le paramètre F des commandes G. Les vitesses sont différentes selon que nous sommes en remplissage, en support, en transfert d'un point à l'autre ou encore en périmètre.
*De plus, suite aux problèmes rencontrés vendredi, c'est-à-dire que certaines cases étaient vides donc posaient problème lors de la lecture par CAMRob du fichier CSV, j'ai supprimé ses cases car elles permettaient de ne pas fournir de matière PS à la buse pour aller d'un point à l'autre, mais la communication ne se fait pas encore directement entre CAMRob et le CompactRIO.
*Voici donc le diagramme réalisé et la face avant sur LabVIEW :
[[Fichier:GCODE6.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE7.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Afin de pouvoir récupérer les données générées par notre fichier CSV lu par ''CAMROB'', il est nécessaire d'établir une liaison RSI. Cette liaison RSI entre le robot et le PC est nécessaire pour récupérer la vitesse du moteur de la buse afin de ne plus avoir à la fixer nous même.
*Le prochain objetif est donc de tester de nouvelles pièces pleines ou creuses avec les nouveaux réglages, et par la suite commencer à tester des pièces avec nécessité de support car présentent des angles importants et/ou sont déportées.
*Mercredi :
**Test des trajectoires sur le robot KUKA du nouveau programme et essai d'un début de pièce avec support : remarque que le plateau de verre était soumis à une quantité importante de vibrations surtout au changement de trajectoire sur petites pièces même en contrôle T1 (c'est-à-dire sans mode auto). Il était donc nécessaire de trouver un moyen de fixation et de stabilisation pour les futurs tests.

*Cette semaine, et dans un second temps, j'ai optimisé le fichier ''LabVIEW'':
**Réalisation de sous-VI de chaque récupération des données intéressanteS (positions X, Y, Z, vitesse F, et vitesse moteur E en tour/min) afin de simplifier l'affichage et de permettre une meilleure ergonomie de l'interface :
[[Fichier:GCODE_X.PNG|1000px|thumb|center|Récupération du paramètre X (idem pour Y et Z avec limite de 0).]]
[[Fichier:GCODE_F.PNG|1000px|thumb|center|Récupération de la variable vitesse robot F et conversion en m/s]]
[[Fichier:GCODE_CALCUL_E.PNG|1000px|thumb|center|Calcul de la valeur de la vitesse moteur E à partir de F.]]
[[Fichier:GCODE_E.PNG|1000px|thumb|center|Récupération de la valeur E et rotation inverse si valeur nulle.]]
[[Fichier:Interface_GCODE.PNG|1000px|thumb|center|Interface utilisateur Labview pour G-Code en CSV.]]

*Tests du vendredi et avancées :
**Ce vendredi, Othman a mis en place la liaison RSI entre le robot (CAMROB) et LabVIEW afin d'envoyer la vitesse moteur traduite par la relation . Cette liaison consiste dons à récupérer la vitesse du moteur de l'extrudeur et de passer en mode auto.
**Tests :
***1er test : pièce pleine avec un remplissage de 30% sur une forme parallélépipédique avec une vitesse du robot à 50% de vitesses de périmètres et de transfert à 60mm/sec, et une vitesse de remplissage à 80mm/sec. Notre première remarque était que le robot était trop lent donc arrêt au bout de 3 couches.
***2nd test : pièce identique réduite de 50% selon les axes X et Y pour permettre une réalisation plus rapide, mais avec un remplissage de 30% à une vitesse de 75%. Le robot est légèrement plus rapide et de ce fait nous avons pu terminer la pièce dans les délais. Les principales remarques étaient que les contours étaient effectués trop rapidement, et que l'intérieur, donc le remplissage de la pièce à 30% était bien trop rapide et débitait donc trop de matière.
***3ème test : pièce identique, avec un remplissage à 15% et une diminution de la vitesse de remplissage et de transfert avec les nouveaux paramètres.

**Conclusion de ces tests : nous pouvons désormais réaliser des pièces pleines grâce à l'interface ''LabVIEW'', mais les paramètres de l'impression sont encore à améliorer pour le polystyrène. La dernière pièce réalisée lors de ces tests est prometteuse. Maintenant, il faut chercher les paramètres à récupérer pour améliorer la qualité de l'impression, et surtout augmenter la rapidité et donc optimiser au mieux la quantité de matière pouvant être utilisée dans l'heure (pour rappel 700g/heure de granulés peuvent être transformés par cette buse). Enfin, lors de nos essais, lorsque les moteurs s'arrêtaient, c'est à dire à 0tr/min, il y avait toujours un dépot de matière qui se faisait. Pour eviter ce phénomène, il serait intéressant de voir si nous pouvons réaliser une rétractation de la matière comme il est possible de le faire sur certaines machines 3D telles que celles du fabricarium de l'école.

*Un des objectifs de la semaine prochaine est donc de réaliser de nouvelles pièces et de permettre une meilleure finition de pièce et donc de changer les paramètres en fonction de notre avancée. Tester aussi si on ajoute des couches supplémentaires au dessus où en dessous pour observer une meilleure finition.

===Semaine 4 (du 29/01/2018 au 04/02/2018)===
*Pour contrôler l'un des paramètres qui posaient problème la semaine passée, j'ai tout d'abord essayé de réaliser une rétractation de la matière.
Pour cela, lorsque le débit doit être nul, j'ai remplacé la vitesse du moteur qui était à 0 tour/min à -10 tour/min qui permettra d'éviter un dépot de matière supplémentaire sur la pièce imprimée.

*L'un des objectif de cette semaine ainsi que de la semaine 5 est d'établir une connexion RSI complète entre Labview et le Kuka :
**Actuellement, le cheminement suivant doit être suivi pour établir la connexion avec le KUKA doit passer par CAMROB, license expensive :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> USB -> Kuka CAMROB -> RSI -> Labview
**Le but est de diminuer toutes les manipulations intermédiaires et de réaliser le cheminement suivant :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> RSI -> Communiquer avec KUKA et Tête D'impression (Buse ALLTRENDS)

*Vendredi, nous avons imprimé pour la première fois des pièces telles une grenouille et des parallélépipèdes afin de contrôler la vitesse et de présenter à une entreprise intéressée par le projet, le travail effectué. Nous avons remarqué que la vitesse introduite n'était pas respectée. En effet, en ayant bridé l'accélération à 0.1m/s², le robot limitait donc la vitesse et on observait donc une dégradation de la matière à l'intérieur de la buse. Lors du dernier essai de la journée, nous avons modifié ce paramètre, et effectivement, la dégradation du polystyrène était moins observée.
[[Fichier:GCODE_CUBE.PNG|1000px|thumb|center|Support et premières couches du cube.]]
[[Fichier:GCODE_GRENOUILLE.PNG|1000px|thumb|center|Première grenouille imprimée.]]
On a remarqué qu'il faudrait améliorer les contours par la suite.

===Semaines 5, 6 et 7 (du 05/02/2018 au 20/02/2018)===
*Le contrôleur MYRio a été commandé semaine 5 et réceptionné le jeudi 15 février.

*Ensuite, l'objectif des semaines 4 et 5 est donc d'établir la connexion RSI entre Labview et Kuka.
La connexion RSI (Robot Sensor Interface) qui est une interface de communication Ethernet entre le robot industriel et un système de capteurs, et qui doit être intégré au programme KRL.
Pour se faire, il est nécessaire d'établir des fichiers SRC, XML et RSI. J'utilise donc le logiciel ''RSIVisualShell'' afin de réaliser la connexion RSI.

*Les données prévelées du fichier CSV généré par ''Labview'' sont donc inscrites en entrées par réception de bloc de données au format XML.
Le mode de traitement des signaux est fixé à 12ms avec filtrage (variable de champ #IPO).

*Ci-dessous les fichiers réalisés :
**Fichier XML :
[[Fichier:GCODE_XML.png|1000px|thumb|center|Fichier XML.]]
**Fichier RSI :
[[Fichier:GCODE_RSI.PNG|1000px|thumb|center|Fichier RSI.]]
**Fichier SRC :
[[Fichier:GCODE_SRC.png|1000px|thumb|center|Fichier SRC.]]

Difficultés rencontrées :
*Durant presque une semaine, j'ai été bloquée suite à l'ajout inopportun d'un espace vide qui ne permettait donc pas la lecture du fichier RSI ;
*Le fichier source 8 jours avant d'être débloqué. En effet, j'avais effectué les essais sur le partage d'une seule donnée via la liaison RSI et le problème d'envoi/réception était correct. Cependant, lorsque j'ai ajouté toutes les valeurs à transmettre, le robot envoyait bien les instructions mais ne recevait aucune variable. Lundi 19 février j'ai donc décidé de reprendre le code ligne par ligne pour voir la différence, et en copiant le programme SRC initial ligne par ligne, j'ai supprimé l'erreur tout en conservant exactement le même code. Je soupçonne donc que des caractères inscrits dans mon fichier posaient problème mais je ne sais pas lesquels.
*Ensuite, toujours dans le fichier source, j'ai eu de la difficulté à trouver le moyen de changer les base et outil pour le système Robot+Buse, mais après lecture de la documentation, l'aide de Othman, j'ai finalement trouvé l'erreur ;
*Pour finir, la dernière difficulté rencontrée réside en l'affectation en temps réelle de la vitesse du robot. En effet, je souhaitais effectuer directement l'affectation via les variables $VEL.CP=$SEN_PREA[9], or celle-ci doit être modifiée via la commande BAS(VEL_CP,$SEN_PREA[9]). J'ai donc passé ma journée de mardi à résoudre ce problème.

===Semaine 7 + Soutenance (du 20/02/2018 au 21/02/2018)===
*Finalisation du projet.
*Rédaction du rapport.
*Réalisation de la présentation

==Rapport==
[[Rendu du rapport final:MARRUCHO Diana Rapport PFE.pdf]]

Projets IMA5 2017/2018

2018-02-21T11:59:12Z

Dmarruch : /* 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.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Conception d'une pompe automatique à insuline]]</td>
<td>Alice Coffin / Amina Fahem</td>
<td>Belkacem Ould Bouamama</td>
<td>[[Fichier:rapport_mi_PFE_COFFIN_FAHEM.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P18 Localisation of quadrotors]]</td>
<td>Nicky UNG / Hugo Delatte</td>
<td>Jérémie DEQUIDT / Gang ZHENG</td>
<td>[[Fichier:RapportMi-PFE-UNG DELATTE.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P25 Développement d'un cobot ]]</td>
<td>Tristan HART</td>
<td>Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td>[[Fichier:RapportIntermédiaire_PFE25_HART.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P29 QT pour tablette à retour tactile]]</td>
<td>lValentin BEAUCHAMP / Vivian SENAFFE</td>
<td>Laurent GRISONI</td>
<td>[[Fichier:Rapport_pfe_BEAUCHAMP_SENAFFE.pdf]] </td>
<td> [[Fichier:BEAUCHAMP_SENAFFE_Rapport_Final_PFE.pdf]]</td>
<td> </td>
</tr>

<tr>
<td>[[P30 patcher l’IoT par intrusion]]</td>
<td>Alexis DORIAN</td>
<td>Thomas Vantroys /Worldline</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P33 Utilisation de Nao avec des enfants autistes]]</td>
<td>Antoine ARNAUDET</td>
<td>Thomas VANTROYS</td>
<td> [[Fichier:ARNAUDET_ANTOINE_RAPPORT_DECEMBRE_2017_PFE.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Robot reconstructeur de mouvement]]</td>
<td>Baptiste GRILLERE / Jean-Baptiste SAISON</td>
<td>Rochdi MERZOUKI / Guillaume DEWAELE</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P21 Projet bras déformable antagoniste]]</td>
<td>Florian GIOVANNANGELI</td>
<td>Thor BIEZE</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P20 Projet marionnette déformable interactive ]]</td>
<td>Bacem HAGUI</td>
<td>Félix VANNESTE, Jeremie DEQUIDT</td>
<td> [[Fichier:bacem_mi_parcours.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P5 Commande d’une centrale de production de biogaz ]]</td>
<td>Cheikh Soilihi SAID AHMED</td>
<td>Midzodzi PEKPE </td>
<td>[[Fichier:Rapport_intermediaire.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P15 Réseau de capteurs temps réel ]]</td>
<td>Edmur Lopes</td>
<td>Alexandre Boé / Xavier Redon / Thomas Vantroys</td>
<td>[[Fichier:Rapport_mi_parcours.pdf ]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P23 Application de gestion de conteneurs pour sites Web]]</td>
<td>Alexis MACHEREZ</td>
<td>Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P36 Robots Mobiles Chorégraphes]]</td>
<td>Joshua LETELLIER</td>
<td>Rochdi MERZOUKI</td>
<td>[[Fichier:RapportAvancementPFE_Letellier_Joshua.pdf]] </td>
<td>[[Fichier:RapportFinalPFE_Letellier.pdf]] </td>
<td> </td>
</tr>
<tr>
<td>[[P26 Réseau de capteurs de pollution]]</td>
<td>Marianne BUTAYE</td>
<td>Alexandre BOE / Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td>[[Fichier:Rapport p26 2018 marianne butaye.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P32 Apprentissage automatique pour la détection d’attaques par déni de services ]]</td>
<td>Robin Cavalieri</td>
<td>Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Réseau LoRaWAN ]]</td>
<td>François Lefevre</td>
<td>Alexandre BOE / Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P38 Conception par fabrication additive des pièces en plastique à partir d’un robot]]</td>
<td>Diana Marrucho</td>
<td>Rochdi MERZOUKI</td>
<td> </td>
<td>[[Fichier:MARRUCHO Diana Rapport PFE.pdf]]</td>
<td> </td>
</tr>
</table>

== Matériel nécessaires ==

<table border="1">
<tr>
<th>Projet</th>
<th>Matériel</th>
</tr>
<tr>
<td>P15</td>
<td> 2 câbles usb
50 Positions Embase Connecteur 0,100 po (2,54 mm) Trou traversant Or [https://www.digikey.fr/products/fr?keywords=SFH11-PBPC-D25-ST-BK%20]
</td>
</tr>
<tr>
<td> P27 Réseau LoRaWAN </td>
<td> 1 Raspberry Pi 3 + boîtier + alimentation + câble USB 
 3 STM32 Nucleo + 3 câbles mini-USB 

 3 modules émetteurs LoRa 

 1 module récepteur LoRa 

 1 carte SD 

 10 câbles de connexion 
</td>
</tr>

Fichier:MARRUCHO Diana Rapport PFE.pdf

2018-02-21T11:58:25Z

Dmarruch :

Projets IMA5 2017/2018

2018-02-21T11:57:47Z

Dmarruch : /* 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.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Conception d'une pompe automatique à insuline]]</td>
<td>Alice Coffin / Amina Fahem</td>
<td>Belkacem Ould Bouamama</td>
<td>[[Fichier:rapport_mi_PFE_COFFIN_FAHEM.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P18 Localisation of quadrotors]]</td>
<td>Nicky UNG / Hugo Delatte</td>
<td>Jérémie DEQUIDT / Gang ZHENG</td>
<td>[[Fichier:RapportMi-PFE-UNG DELATTE.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P25 Développement d'un cobot ]]</td>
<td>Tristan HART</td>
<td>Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td>[[Fichier:RapportIntermédiaire_PFE25_HART.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P29 QT pour tablette à retour tactile]]</td>
<td>lValentin BEAUCHAMP / Vivian SENAFFE</td>
<td>Laurent GRISONI</td>
<td>[[Fichier:Rapport_pfe_BEAUCHAMP_SENAFFE.pdf]] </td>
<td> [[Fichier:BEAUCHAMP_SENAFFE_Rapport_Final_PFE.pdf]]</td>
<td> </td>
</tr>

<tr>
<td>[[P30 patcher l’IoT par intrusion]]</td>
<td>Alexis DORIAN</td>
<td>Thomas Vantroys /Worldline</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P33 Utilisation de Nao avec des enfants autistes]]</td>
<td>Antoine ARNAUDET</td>
<td>Thomas VANTROYS</td>
<td> [[Fichier:ARNAUDET_ANTOINE_RAPPORT_DECEMBRE_2017_PFE.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Robot reconstructeur de mouvement]]</td>
<td>Baptiste GRILLERE / Jean-Baptiste SAISON</td>
<td>Rochdi MERZOUKI / Guillaume DEWAELE</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P21 Projet bras déformable antagoniste]]</td>
<td>Florian GIOVANNANGELI</td>
<td>Thor BIEZE</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P20 Projet marionnette déformable interactive ]]</td>
<td>Bacem HAGUI</td>
<td>Félix VANNESTE, Jeremie DEQUIDT</td>
<td> [[Fichier:bacem_mi_parcours.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P5 Commande d’une centrale de production de biogaz ]]</td>
<td>Cheikh Soilihi SAID AHMED</td>
<td>Midzodzi PEKPE </td>
<td>[[Fichier:Rapport_intermediaire.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P15 Réseau de capteurs temps réel ]]</td>
<td>Edmur Lopes</td>
<td>Alexandre Boé / Xavier Redon / Thomas Vantroys</td>
<td>[[Fichier:Rapport_mi_parcours.pdf ]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P23 Application de gestion de conteneurs pour sites Web]]</td>
<td>Alexis MACHEREZ</td>
<td>Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P36 Robots Mobiles Chorégraphes]]</td>
<td>Joshua LETELLIER</td>
<td>Rochdi MERZOUKI</td>
<td>[[Fichier:RapportAvancementPFE_Letellier_Joshua.pdf]] </td>
<td>[[Fichier:RapportFinalPFE_Letellier.pdf]] </td>
<td> </td>
</tr>
<tr>
<td>[[P26 Réseau de capteurs de pollution]]</td>
<td>Marianne BUTAYE</td>
<td>Alexandre BOE / Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td>[[Fichier:Rapport p26 2018 marianne butaye.pdf]]</td>
<td> </td>
</tr>
<tr>
<td>[[P32 Apprentissage automatique pour la détection d’attaques par déni de services ]]</td>
<td>Robin Cavalieri</td>
<td>Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Réseau LoRaWAN ]]</td>
<td>François Lefevre</td>
<td>Alexandre BOE / Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P38 Conception par fabrication additive des pièces en plastique à partir d’un robot]]</td>
<td>Diana Marrucho</td>
<td>Rochdi MERZOUKI</td>
<td> </td>
<td>[[Fichier:MARRUCHO_Diana_Rapport_PFE.pdf]]</td>
<td> </td>
</tr>
</table>

== Matériel nécessaires ==

<table border="1">
<tr>
<th>Projet</th>
<th>Matériel</th>
</tr>
<tr>
<td>P15</td>
<td> 2 câbles usb
50 Positions Embase Connecteur 0,100 po (2,54 mm) Trou traversant Or [https://www.digikey.fr/products/fr?keywords=SFH11-PBPC-D25-ST-BK%20]
</td>
</tr>
<tr>
<td> P27 Réseau LoRaWAN </td>
<td> 1 Raspberry Pi 3 + boîtier + alimentation + câble USB 
 3 STM32 Nucleo + 3 câbles mini-USB 

 3 modules émetteurs LoRa 

 1 module récepteur LoRa 

 1 carte SD 

 10 câbles de connexion 
</td>
</tr>

Fichier:GCODE RSI.PNG

2018-02-21T11:52:14Z

Dmarruch :

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-02-21T11:50:58Z

Dmarruch : /* Semaines 5, 6 et 7 (du 05/02/2018 au 20/02/2018) */

Fichier:GCODE SRC.png

2018-02-21T11:50:02Z

Dmarruch :

Fichier:GCODE XML.png

2018-02-21T11:49:25Z

Dmarruch :

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-02-21T11:48:39Z

Dmarruch : /* Semaine 4 (du 29/01/2018 au 04/02/2018) */

''Etudiante : Diana Marrucho ''
''Encadrants : Rochdi Merzouki, Othman Lakhal''

== Présentation générale du projet ==

===Contexte du projet===
La société All-Trends est une start-up lilloise développant la technologie e-Bridium® de fabrication additive directe à granulés en plasturgie dans le but d'imprimer des pièces en polymère à partir de granulés plastiques non-propriétaires.

Dans le cadre du programme Centaure, All-Trends s'est associée à Polytech Lille et le laboratoire CRIStAL afin de l'accompagner pour la réalisation d'un prototype d'impression 3D robotisé à base des granulés. Une buse, permettant la fusion des granulés est fixée à un robot Kuka pour pouvoir imprimer dans toutes les positions.

Actuellement, des pièces à base de PS (Polystyrène) ont été réalisées en salle C002 à Polytech Lille et des tests sont effectués les vendredis.
[[Fichier:GCODE_EBRIDIUM.png|700px|thumb|center|Robot KUKA et Buse ALL-TRENDS.]]
[[Fichier:GCODE_PIECES.png|700px|thumb|center|Pièces imprimées en PS.]]

==Cahier des charges==

===But du projet===
Dans une première partie, l'objectif est de tester différents types de matières et d'en contrôler la régulation de température de la buse en fonction des granulés utilisés.

Actuellement, le robot est contrôlé par un contrôleur ''CompactRIO'' de ''National Instruments''.
La seconde partie du projet consisterait donc à intégrer le programme de commande sur une ''MyRIO'' de ''National Instruments''.

Pour se faire, l'utilisation du logiciel LabVIEW est nécessaire.

===Planning Prévisionnel===
*Semaine 1 :
**Apprentissage du LabVIEW ;
*Semaine 2 :
**Prise en main sur la programmation et la commande du dispositif robotisé existant ;
*Semaine 3-4 :
**Test d'impression et régulation pour trois différentes matières ;
*Semaine 5 :
**Intégration du programme de commande et supervision embarqué sur une MyRIO de ''National Instruments'' ;
*Semaine 6 :
**Test et validation ;
**Rédaction du rapport.

==Avancement du projet==
===Semaine 1 (du 11/01/2018 au 14/01/2018)===
*A partir de mercredi, j'ai repris en main le logiciel LabVIEW. Lecture de la documentation d'utilisation Labview et du CompactRIO de ''National Instruments'' :
**Lien de la documentation :[https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwjSvrTkydnYAhVEtBQKHSUaDIcQFggxMAE&url=http%3A%2F%2Fwww.mit.bme.hu%2Fsystem%2Ffiles%2Foktatas%2Ftargyak%2F7258%2Fcriodevgudfull.pdf&usg=AOvVaw3ZNQC-jm6kkskpguWi_ZzS]
*Réalisation de tests sur la jambe de cheval : contrôle par LabVIEW via CompactRIO, analog output, du système électro-pneumatique pour le contrômle des muscles de la jambe de cheval.
*'''Nouvel objectif : réaliser un interpréteur du G-Code via LabVIEW afin de pouvoir tout contrôler directement par National Instruments sans l'utilisation de Matlab. Attention à prendre en compte que ce n'est pas la plateforme support qui se déplace mais le bras robot Kuka.'''
*Vendredi : en présence de monsieur Grégory SANT de la société All-Trends, nous avons effectués des tests d'impression de pièces 3D avec des granulés de polystyrène en effectuant des variations des deux anneaux de température, de débit de sortie de buse, de vitesse ou de hauteur afin de pouvoir renseigner les paramètres les plus optimaux pour le robot industriel et la tête d'impression All-Trends. L'objectif des prochains tests sera de diminuer la taille de la buse afin de se rendre compte de son impact sur la pièce imprimée et surtout de pouvoir avoir une résolution maximale avec un temps réduit. Effectivement, contrairement à une imprimante 3D classique, ce robot plutôt destiné à l'industrie, permet de sortir 700g de matériaux à l'heure contre 1kg la journée pour l'imprimante classique. De plus, le coût de la matière est moindre contrairement au fil qui est déjà dégradé par sa transformation en fil.

===Semaine 2 (du 15/01/2018 au 21/01/2018)===
*Actuellement, afin de pouvoir réaliser des impression, ''Matlab'' était utilisé afin de générer les différentes trajectoires. Les pièces réalisées jusqu'à présent sont des pièces dont le périmètre était imprimé, sans grand angle et sans support pour une pièce déportée. L'objectif de la semaine 2 est donc de pouvoir tester de nouvelles formes.
*Afin de pouvoir convertir le fichier 3D, généralement de format STL, on utilise le slicer CURA que l'on paramètre avec les données correspondant au diamètre de la buse utilisée, à la température des couronnes et du plateau chauffant, au diamètre de sortie du cordon, à la hauteur de couche...
*Le but de cette semaine est donc de réaliser un interpréteur avec ''LabVIEW'' capable de transformer le G-Code en fichier CSV :
**Dans un premier temps, j'ai d'abord cherché à récupérer toutes les données du gcode et les indexer dans un tableau :
[[Fichier:GCODE1.PNG|700px|thumb|center|Récupération des données du Gcode par LabVIEW.]]
*Ensuite, afin de ne garder que les données qui nous intéressent, à savoir les lignes de code contenant les commandes en G, j'ai récupéré selon toutes les différentes commandes (à savoir les commandes selon G0, G1, G2, G3, G4, G20, G21, G28, G29, G90, G91 et G92 selon la documentation du ''Wiki RepRap'' [http://reprap.org/wiki/G-code/fr#M205_Repetier]
*A partir de mercredi, et de la lecture du document ''Software KUKA.CAMRob KRC 3.0'', et des paramètres que CAMRob peut prendre en considération, je me suis limitée à la récupération des données correspondantes. En effet, le fichier de donnée CAM peut contenir jusqu'à 26 paramètres selon des positions bien précises. Ainsi, voici les données pouvant être récupérées pour le fichier CSV utilisé par CAMRob :
[[Fichier:GCODE2.PNG|700px|thumb|center|CAMRob data parameters.]]
*Les données récupérées seront donc les cordonnées cartésiennes selon les axes X, Y et Z pour les paramètres 2, 3 et 4. Suite au paramétrage de la buse et de la base du robot Kuka, on récupère les rotations A, B et C. Car elles ne sont pas paramétrées dans le slicer. De plus, on y introduit la vitesse de 0.04m/s qui sera ensuite réglée en pourcentage sur CAMRob, ainsi que l'accélération que l'on a fixé à 1m/s². Tous les autres paramètres sont fixés à 0 car non utilisés. Cela me donne donc en face avant et diagramme de LabVIEW les aperçus suivants :
[[Fichier:GCODE3.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE4.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Vendredi, suite à des tests dès le matin avec la présence de messieurs Gragory SANT et Othman LAKHAL, nous avons imprimé pour la première fois avec le Polystyrène, des pièces pleines. Cela fut dans un premier temps compliqué car le slicer CURA n'était pas très précis concernant les premières couches, le motif du remplissage et les pièces n'étaient donc pas parfaites. Nous avons donc essayé d'imprimer des pièces basiques (des disques, des rectangles, une attache fleur, une raquette sans angles et ne nécessitant pas de support) avec différents remplissages (entre 15 et 100%). Suite aux réglages des différents paramètres, au changement de slicer vers ''Slic3r'' qui est plus précis et qui nous permet de ne pas faire de motif de remplissage aléatoirement et aux différents tests de la journée, notre réglage le plus précis était donc le suivant :
**Température Haute de la buse : 250°C ;
**Température Basse de la buse : 260°C ;
**Vitesse : 75% de 0.04m/s ;
**Débit : 0.04V.
**Et dont les paramètres sur ''Slic3r'' étaient les suivants :
[[Fichier:GCODE5.png|1000px|thumb|center|Slic3r Parameters.]]

===Semaine 3 (du 22/01/2018 au 28/01/2018)===
*Le premier objectif de cette semaine est maintenant de prendre en compte les vitesses générées par le slicer et non plus de la fixer nous même sur CAMRob en pourcentage de la vitesse maximale. Pour cela, je vais récupérer les données selon le paramètre F des commandes G. Les vitesses sont différentes selon que nous sommes en remplissage, en support, en transfert d'un point à l'autre ou encore en périmètre.
*De plus, suite aux problèmes rencontrés vendredi, c'est-à-dire que certaines cases étaient vides donc posaient problème lors de la lecture par CAMRob du fichier CSV, j'ai supprimé ses cases car elles permettaient de ne pas fournir de matière PS à la buse pour aller d'un point à l'autre, mais la communication ne se fait pas encore directement entre CAMRob et le CompactRIO.
*Voici donc le diagramme réalisé et la face avant sur LabVIEW :
[[Fichier:GCODE6.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE7.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Afin de pouvoir récupérer les données générées par notre fichier CSV lu par ''CAMROB'', il est nécessaire d'établir une liaison RSI. Cette liaison RSI entre le robot et le PC est nécessaire pour récupérer la vitesse du moteur de la buse afin de ne plus avoir à la fixer nous même.
*Le prochain objetif est donc de tester de nouvelles pièces pleines ou creuses avec les nouveaux réglages, et par la suite commencer à tester des pièces avec nécessité de support car présentent des angles importants et/ou sont déportées.
*Mercredi :
**Test des trajectoires sur le robot KUKA du nouveau programme et essai d'un début de pièce avec support : remarque que le plateau de verre était soumis à une quantité importante de vibrations surtout au changement de trajectoire sur petites pièces même en contrôle T1 (c'est-à-dire sans mode auto). Il était donc nécessaire de trouver un moyen de fixation et de stabilisation pour les futurs tests.

*Cette semaine, et dans un second temps, j'ai optimisé le fichier ''LabVIEW'':
**Réalisation de sous-VI de chaque récupération des données intéressanteS (positions X, Y, Z, vitesse F, et vitesse moteur E en tour/min) afin de simplifier l'affichage et de permettre une meilleure ergonomie de l'interface :
[[Fichier:GCODE_X.PNG|1000px|thumb|center|Récupération du paramètre X (idem pour Y et Z avec limite de 0).]]
[[Fichier:GCODE_F.PNG|1000px|thumb|center|Récupération de la variable vitesse robot F et conversion en m/s]]
[[Fichier:GCODE_CALCUL_E.PNG|1000px|thumb|center|Calcul de la valeur de la vitesse moteur E à partir de F.]]
[[Fichier:GCODE_E.PNG|1000px|thumb|center|Récupération de la valeur E et rotation inverse si valeur nulle.]]
[[Fichier:Interface_GCODE.PNG|1000px|thumb|center|Interface utilisateur Labview pour G-Code en CSV.]]

*Tests du vendredi et avancées :
**Ce vendredi, Othman a mis en place la liaison RSI entre le robot (CAMROB) et LabVIEW afin d'envoyer la vitesse moteur traduite par la relation . Cette liaison consiste dons à récupérer la vitesse du moteur de l'extrudeur et de passer en mode auto.
**Tests :
***1er test : pièce pleine avec un remplissage de 30% sur une forme parallélépipédique avec une vitesse du robot à 50% de vitesses de périmètres et de transfert à 60mm/sec, et une vitesse de remplissage à 80mm/sec. Notre première remarque était que le robot était trop lent donc arrêt au bout de 3 couches.
***2nd test : pièce identique réduite de 50% selon les axes X et Y pour permettre une réalisation plus rapide, mais avec un remplissage de 30% à une vitesse de 75%. Le robot est légèrement plus rapide et de ce fait nous avons pu terminer la pièce dans les délais. Les principales remarques étaient que les contours étaient effectués trop rapidement, et que l'intérieur, donc le remplissage de la pièce à 30% était bien trop rapide et débitait donc trop de matière.
***3ème test : pièce identique, avec un remplissage à 15% et une diminution de la vitesse de remplissage et de transfert avec les nouveaux paramètres.

**Conclusion de ces tests : nous pouvons désormais réaliser des pièces pleines grâce à l'interface ''LabVIEW'', mais les paramètres de l'impression sont encore à améliorer pour le polystyrène. La dernière pièce réalisée lors de ces tests est prometteuse. Maintenant, il faut chercher les paramètres à récupérer pour améliorer la qualité de l'impression, et surtout augmenter la rapidité et donc optimiser au mieux la quantité de matière pouvant être utilisée dans l'heure (pour rappel 700g/heure de granulés peuvent être transformés par cette buse). Enfin, lors de nos essais, lorsque les moteurs s'arrêtaient, c'est à dire à 0tr/min, il y avait toujours un dépot de matière qui se faisait. Pour eviter ce phénomène, il serait intéressant de voir si nous pouvons réaliser une rétractation de la matière comme il est possible de le faire sur certaines machines 3D telles que celles du fabricarium de l'école.

*Un des objectifs de la semaine prochaine est donc de réaliser de nouvelles pièces et de permettre une meilleure finition de pièce et donc de changer les paramètres en fonction de notre avancée. Tester aussi si on ajoute des couches supplémentaires au dessus où en dessous pour observer une meilleure finition.

===Semaine 4 (du 29/01/2018 au 04/02/2018)===
*Pour contrôler l'un des paramètres qui posaient problème la semaine passée, j'ai tout d'abord essayé de réaliser une rétractation de la matière.
Pour cela, lorsque le débit doit être nul, j'ai remplacé la vitesse du moteur qui était à 0 tour/min à -10 tour/min qui permettra d'éviter un dépot de matière supplémentaire sur la pièce imprimée.

*L'un des objectif de cette semaine ainsi que de la semaine 5 est d'établir une connexion RSI complète entre Labview et le Kuka :
**Actuellement, le cheminement suivant doit être suivi pour établir la connexion avec le KUKA doit passer par CAMROB, license expensive :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> USB -> Kuka CAMROB -> RSI -> Labview
**Le but est de diminuer toutes les manipulations intermédiaires et de réaliser le cheminement suivant :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> RSI -> Communiquer avec KUKA et Tête D'impression (Buse ALLTRENDS)

*Vendredi, nous avons imprimé pour la première fois des pièces telles une grenouille et des parallélépipèdes afin de contrôler la vitesse et de présenter à une entreprise intéressée par le projet, le travail effectué. Nous avons remarqué que la vitesse introduite n'était pas respectée. En effet, en ayant bridé l'accélération à 0.1m/s², le robot limitait donc la vitesse et on observait donc une dégradation de la matière à l'intérieur de la buse. Lors du dernier essai de la journée, nous avons modifié ce paramètre, et effectivement, la dégradation du polystyrène était moins observée.
[[Fichier:GCODE_CUBE.PNG|1000px|thumb|center|Support et premières couches du cube.]]
[[Fichier:GCODE_GRENOUILLE.PNG|1000px|thumb|center|Première grenouille imprimée.]]
On a remarqué qu'il faudrait améliorer les contours par la suite.

===Semaines 5, 6 et 7 (du 05/02/2018 au 20/02/2018)===
*Le contrôleur MYRio a été commandé semaine 5 et réceptionné le jeudi 15 février.

*Ensuite, l'objectif des semaines 4 et 5 est donc d'établir la connexion RSI entre Labview et Kuka.
La connexion RSI (Robot Sensor Interface) qui est une interface de communication Ethernet entre le robot industriel et un système de capteurs, et qui doit être intégré au programme KRL.
Pour se faire, il est nécessaire d'établir des fichiers SRC, XML et RSI. J'utilise donc le logiciel ''RSIVisualShell'' afin de réaliser la connexion RSI.

*Les données prévelées du fichier CSV généré par ''Labview'' sont donc inscrites en entrées par réception de bloc de données au format XML.
Le mode de traitement des signaux est fixé à 12ms avec filtrage (variable de champ #IPO).

*Ci-dessous les fichiers réalisés :
**Fichier XML :
[[Fichier:GCODE_XML.png|1000px|thumb|center|Fichier XML.]]
**Fichier RSI :
[[Fichier:GCODE_RSI.png|1000px|thumb|center|Fichier RSI.]]
**Fichier SRC :
[[Fichier:GCODE_SRC.png|1000px|thumb|center|Fichier SRC.]]

Difficultés rencontrées :
*Durant presque une semaine, j'ai été bloquée suite à l'ajout inopportun d'un espace vide qui ne permettait donc pas la lecture du fichier RSI ;
*Le fichier source 8 jours avant d'être débloqué. En effet, j'avais effectué les essais sur le partage d'une seule donnée via la liaison RSI et le problème d'envoi/réception était correct. Cependant, lorsque j'ai ajouté toutes les valeurs à transmettre, le robot envoyait bien les instructions mais ne recevait aucune variable. Lundi 19 février j'ai donc décidé de reprendre le code ligne par ligne pour voir la différence, et en copiant le programme SRC initial ligne par ligne, j'ai supprimé l'erreur tout en conservant exactement le même code. Je soupçonne donc que des caractères inscrits dans mon fichier posaient problème mais je ne sais pas lesquels.
*Ensuite, toujours dans le fichier source, j'ai eu de la difficulté à trouver le moyen de changer les base et outil pour le système Robot+Buse, mais après lecture de la documentation, l'aide de Othman, j'ai finalement trouvé l'erreur ;
*Pour finir, la dernière difficulté rencontrée réside en l'affectation en temps réelle de la vitesse du robot. En effet, je souhaitais effectuer directement l'affectation via les variables $VEL.CP=$SEN_PREA[9], or celle-ci doit être modifiée via la commande BAS(VEL_CP,$SEN_PREA[9]). J'ai donc passé ma journée de mardi à résoudre ce problème.

===Semaine 7 + Soutenance (du 20/02/2018 au 21/02/2018)===
*Finalisation du projet.
*Rédaction du rapport.
*Réalisation de la présentation

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-02-21T11:48:12Z

Dmarruch : /* Semaine 3 (du 22/01/2018 au 28/01/2018) */

''Etudiante : Diana Marrucho ''
''Encadrants : Rochdi Merzouki, Othman Lakhal''

== Présentation générale du projet ==

===Contexte du projet===
La société All-Trends est une start-up lilloise développant la technologie e-Bridium® de fabrication additive directe à granulés en plasturgie dans le but d'imprimer des pièces en polymère à partir de granulés plastiques non-propriétaires.

Dans le cadre du programme Centaure, All-Trends s'est associée à Polytech Lille et le laboratoire CRIStAL afin de l'accompagner pour la réalisation d'un prototype d'impression 3D robotisé à base des granulés. Une buse, permettant la fusion des granulés est fixée à un robot Kuka pour pouvoir imprimer dans toutes les positions.

Actuellement, des pièces à base de PS (Polystyrène) ont été réalisées en salle C002 à Polytech Lille et des tests sont effectués les vendredis.
[[Fichier:GCODE_EBRIDIUM.png|700px|thumb|center|Robot KUKA et Buse ALL-TRENDS.]]
[[Fichier:GCODE_PIECES.png|700px|thumb|center|Pièces imprimées en PS.]]

==Cahier des charges==

===But du projet===
Dans une première partie, l'objectif est de tester différents types de matières et d'en contrôler la régulation de température de la buse en fonction des granulés utilisés.

Actuellement, le robot est contrôlé par un contrôleur ''CompactRIO'' de ''National Instruments''.
La seconde partie du projet consisterait donc à intégrer le programme de commande sur une ''MyRIO'' de ''National Instruments''.

Pour se faire, l'utilisation du logiciel LabVIEW est nécessaire.

===Planning Prévisionnel===
*Semaine 1 :
**Apprentissage du LabVIEW ;
*Semaine 2 :
**Prise en main sur la programmation et la commande du dispositif robotisé existant ;
*Semaine 3-4 :
**Test d'impression et régulation pour trois différentes matières ;
*Semaine 5 :
**Intégration du programme de commande et supervision embarqué sur une MyRIO de ''National Instruments'' ;
*Semaine 6 :
**Test et validation ;
**Rédaction du rapport.

==Avancement du projet==
===Semaine 1 (du 11/01/2018 au 14/01/2018)===
*A partir de mercredi, j'ai repris en main le logiciel LabVIEW. Lecture de la documentation d'utilisation Labview et du CompactRIO de ''National Instruments'' :
**Lien de la documentation :[https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwjSvrTkydnYAhVEtBQKHSUaDIcQFggxMAE&url=http%3A%2F%2Fwww.mit.bme.hu%2Fsystem%2Ffiles%2Foktatas%2Ftargyak%2F7258%2Fcriodevgudfull.pdf&usg=AOvVaw3ZNQC-jm6kkskpguWi_ZzS]
*Réalisation de tests sur la jambe de cheval : contrôle par LabVIEW via CompactRIO, analog output, du système électro-pneumatique pour le contrômle des muscles de la jambe de cheval.
*'''Nouvel objectif : réaliser un interpréteur du G-Code via LabVIEW afin de pouvoir tout contrôler directement par National Instruments sans l'utilisation de Matlab. Attention à prendre en compte que ce n'est pas la plateforme support qui se déplace mais le bras robot Kuka.'''
*Vendredi : en présence de monsieur Grégory SANT de la société All-Trends, nous avons effectués des tests d'impression de pièces 3D avec des granulés de polystyrène en effectuant des variations des deux anneaux de température, de débit de sortie de buse, de vitesse ou de hauteur afin de pouvoir renseigner les paramètres les plus optimaux pour le robot industriel et la tête d'impression All-Trends. L'objectif des prochains tests sera de diminuer la taille de la buse afin de se rendre compte de son impact sur la pièce imprimée et surtout de pouvoir avoir une résolution maximale avec un temps réduit. Effectivement, contrairement à une imprimante 3D classique, ce robot plutôt destiné à l'industrie, permet de sortir 700g de matériaux à l'heure contre 1kg la journée pour l'imprimante classique. De plus, le coût de la matière est moindre contrairement au fil qui est déjà dégradé par sa transformation en fil.

===Semaine 2 (du 15/01/2018 au 21/01/2018)===
*Actuellement, afin de pouvoir réaliser des impression, ''Matlab'' était utilisé afin de générer les différentes trajectoires. Les pièces réalisées jusqu'à présent sont des pièces dont le périmètre était imprimé, sans grand angle et sans support pour une pièce déportée. L'objectif de la semaine 2 est donc de pouvoir tester de nouvelles formes.
*Afin de pouvoir convertir le fichier 3D, généralement de format STL, on utilise le slicer CURA que l'on paramètre avec les données correspondant au diamètre de la buse utilisée, à la température des couronnes et du plateau chauffant, au diamètre de sortie du cordon, à la hauteur de couche...
*Le but de cette semaine est donc de réaliser un interpréteur avec ''LabVIEW'' capable de transformer le G-Code en fichier CSV :
**Dans un premier temps, j'ai d'abord cherché à récupérer toutes les données du gcode et les indexer dans un tableau :
[[Fichier:GCODE1.PNG|700px|thumb|center|Récupération des données du Gcode par LabVIEW.]]
*Ensuite, afin de ne garder que les données qui nous intéressent, à savoir les lignes de code contenant les commandes en G, j'ai récupéré selon toutes les différentes commandes (à savoir les commandes selon G0, G1, G2, G3, G4, G20, G21, G28, G29, G90, G91 et G92 selon la documentation du ''Wiki RepRap'' [http://reprap.org/wiki/G-code/fr#M205_Repetier]
*A partir de mercredi, et de la lecture du document ''Software KUKA.CAMRob KRC 3.0'', et des paramètres que CAMRob peut prendre en considération, je me suis limitée à la récupération des données correspondantes. En effet, le fichier de donnée CAM peut contenir jusqu'à 26 paramètres selon des positions bien précises. Ainsi, voici les données pouvant être récupérées pour le fichier CSV utilisé par CAMRob :
[[Fichier:GCODE2.PNG|700px|thumb|center|CAMRob data parameters.]]
*Les données récupérées seront donc les cordonnées cartésiennes selon les axes X, Y et Z pour les paramètres 2, 3 et 4. Suite au paramétrage de la buse et de la base du robot Kuka, on récupère les rotations A, B et C. Car elles ne sont pas paramétrées dans le slicer. De plus, on y introduit la vitesse de 0.04m/s qui sera ensuite réglée en pourcentage sur CAMRob, ainsi que l'accélération que l'on a fixé à 1m/s². Tous les autres paramètres sont fixés à 0 car non utilisés. Cela me donne donc en face avant et diagramme de LabVIEW les aperçus suivants :
[[Fichier:GCODE3.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE4.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Vendredi, suite à des tests dès le matin avec la présence de messieurs Gragory SANT et Othman LAKHAL, nous avons imprimé pour la première fois avec le Polystyrène, des pièces pleines. Cela fut dans un premier temps compliqué car le slicer CURA n'était pas très précis concernant les premières couches, le motif du remplissage et les pièces n'étaient donc pas parfaites. Nous avons donc essayé d'imprimer des pièces basiques (des disques, des rectangles, une attache fleur, une raquette sans angles et ne nécessitant pas de support) avec différents remplissages (entre 15 et 100%). Suite aux réglages des différents paramètres, au changement de slicer vers ''Slic3r'' qui est plus précis et qui nous permet de ne pas faire de motif de remplissage aléatoirement et aux différents tests de la journée, notre réglage le plus précis était donc le suivant :
**Température Haute de la buse : 250°C ;
**Température Basse de la buse : 260°C ;
**Vitesse : 75% de 0.04m/s ;
**Débit : 0.04V.
**Et dont les paramètres sur ''Slic3r'' étaient les suivants :
[[Fichier:GCODE5.png|1000px|thumb|center|Slic3r Parameters.]]

===Semaine 3 (du 22/01/2018 au 28/01/2018)===
*Le premier objectif de cette semaine est maintenant de prendre en compte les vitesses générées par le slicer et non plus de la fixer nous même sur CAMRob en pourcentage de la vitesse maximale. Pour cela, je vais récupérer les données selon le paramètre F des commandes G. Les vitesses sont différentes selon que nous sommes en remplissage, en support, en transfert d'un point à l'autre ou encore en périmètre.
*De plus, suite aux problèmes rencontrés vendredi, c'est-à-dire que certaines cases étaient vides donc posaient problème lors de la lecture par CAMRob du fichier CSV, j'ai supprimé ses cases car elles permettaient de ne pas fournir de matière PS à la buse pour aller d'un point à l'autre, mais la communication ne se fait pas encore directement entre CAMRob et le CompactRIO.
*Voici donc le diagramme réalisé et la face avant sur LabVIEW :
[[Fichier:GCODE6.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE7.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Afin de pouvoir récupérer les données générées par notre fichier CSV lu par ''CAMROB'', il est nécessaire d'établir une liaison RSI. Cette liaison RSI entre le robot et le PC est nécessaire pour récupérer la vitesse du moteur de la buse afin de ne plus avoir à la fixer nous même.
*Le prochain objetif est donc de tester de nouvelles pièces pleines ou creuses avec les nouveaux réglages, et par la suite commencer à tester des pièces avec nécessité de support car présentent des angles importants et/ou sont déportées.
*Mercredi :
**Test des trajectoires sur le robot KUKA du nouveau programme et essai d'un début de pièce avec support : remarque que le plateau de verre était soumis à une quantité importante de vibrations surtout au changement de trajectoire sur petites pièces même en contrôle T1 (c'est-à-dire sans mode auto). Il était donc nécessaire de trouver un moyen de fixation et de stabilisation pour les futurs tests.

*Cette semaine, et dans un second temps, j'ai optimisé le fichier ''LabVIEW'':
**Réalisation de sous-VI de chaque récupération des données intéressanteS (positions X, Y, Z, vitesse F, et vitesse moteur E en tour/min) afin de simplifier l'affichage et de permettre une meilleure ergonomie de l'interface :
[[Fichier:GCODE_X.PNG|1000px|thumb|center|Récupération du paramètre X (idem pour Y et Z avec limite de 0).]]
[[Fichier:GCODE_F.PNG|1000px|thumb|center|Récupération de la variable vitesse robot F et conversion en m/s]]
[[Fichier:GCODE_CALCUL_E.PNG|1000px|thumb|center|Calcul de la valeur de la vitesse moteur E à partir de F.]]
[[Fichier:GCODE_E.PNG|1000px|thumb|center|Récupération de la valeur E et rotation inverse si valeur nulle.]]
[[Fichier:Interface_GCODE.PNG|1000px|thumb|center|Interface utilisateur Labview pour G-Code en CSV.]]

*Tests du vendredi et avancées :
**Ce vendredi, Othman a mis en place la liaison RSI entre le robot (CAMROB) et LabVIEW afin d'envoyer la vitesse moteur traduite par la relation . Cette liaison consiste dons à récupérer la vitesse du moteur de l'extrudeur et de passer en mode auto.
**Tests :
***1er test : pièce pleine avec un remplissage de 30% sur une forme parallélépipédique avec une vitesse du robot à 50% de vitesses de périmètres et de transfert à 60mm/sec, et une vitesse de remplissage à 80mm/sec. Notre première remarque était que le robot était trop lent donc arrêt au bout de 3 couches.
***2nd test : pièce identique réduite de 50% selon les axes X et Y pour permettre une réalisation plus rapide, mais avec un remplissage de 30% à une vitesse de 75%. Le robot est légèrement plus rapide et de ce fait nous avons pu terminer la pièce dans les délais. Les principales remarques étaient que les contours étaient effectués trop rapidement, et que l'intérieur, donc le remplissage de la pièce à 30% était bien trop rapide et débitait donc trop de matière.
***3ème test : pièce identique, avec un remplissage à 15% et une diminution de la vitesse de remplissage et de transfert avec les nouveaux paramètres.

**Conclusion de ces tests : nous pouvons désormais réaliser des pièces pleines grâce à l'interface ''LabVIEW'', mais les paramètres de l'impression sont encore à améliorer pour le polystyrène. La dernière pièce réalisée lors de ces tests est prometteuse. Maintenant, il faut chercher les paramètres à récupérer pour améliorer la qualité de l'impression, et surtout augmenter la rapidité et donc optimiser au mieux la quantité de matière pouvant être utilisée dans l'heure (pour rappel 700g/heure de granulés peuvent être transformés par cette buse). Enfin, lors de nos essais, lorsque les moteurs s'arrêtaient, c'est à dire à 0tr/min, il y avait toujours un dépot de matière qui se faisait. Pour eviter ce phénomène, il serait intéressant de voir si nous pouvons réaliser une rétractation de la matière comme il est possible de le faire sur certaines machines 3D telles que celles du fabricarium de l'école.

*Un des objectifs de la semaine prochaine est donc de réaliser de nouvelles pièces et de permettre une meilleure finition de pièce et donc de changer les paramètres en fonction de notre avancée. Tester aussi si on ajoute des couches supplémentaires au dessus où en dessous pour observer une meilleure finition.

===Semaine 4 (du 29/01/2018 au 04/02/2018)===
*Pour contrôler l'un des paramètres qui posaient problème la semaine passée, j'ai tout d'abord essayé de réaliser une rétractation de la matière.
Pour cela, lorsque le débit doit être nul, j'ai remplacé la vitesse du moteur qui était à 0 tour/min à -10 tour/min qui permettra d'éviter un dépot de matière supplémentaire sur la pièce imprimée.

*L'un des objectif de cette semaine ainsi que de la semaine 5 est d'établir une connexion RSI complète entre Labview et le Kuka :
**Actuellement, le cheminement suivant doit être suivi pour établir la connexion avec le KUKA doit passer par CAMROB, license expensive :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> USB -> Kuka CAMROB -> RSI -> Labview
**Le but est de diminuer toutes les manipulations intermédiaires et de réaliser le cheminement suivant :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> RSI -> Communiquer avec KUKA et Tête D'impression (Buse ALLTRENDS)

*Vendredi, nous avons imprimé pour la première fois des pièces telles une grenouille et des parallélépipèdes afin de contrôler la vitesse et de présenter à une entreprise intéressée par le projet, le travail effectué. Nous avons remarqué que la vitesse introduite n'était pas respectée. En effet, en ayant bridé l'accélération à 0.1m/s², le robot limitait donc la vitesse et on observait donc une dégradation de la matière à l'intérieur de la buse. Lors du dernier essai de la journée, nous avons modifié ce paramètre, et effectivement, la dégradation du polystyrène était moins observée.
[[Fichier:GCODE_CUBE.jpg|1000px|thumb|center|Support et premières couches du cube.]]
[[Fichier:GCODE_GRENOUILLE.jpg|1000px|thumb|center|Première grenouille imprimée.]]
On a remarqué qu'il faudrait améliorer les contours par la suite.

===Semaines 5, 6 et 7 (du 05/02/2018 au 20/02/2018)===
*Le contrôleur MYRio a été commandé semaine 5 et réceptionné le jeudi 15 février.

*Ensuite, l'objectif des semaines 4 et 5 est donc d'établir la connexion RSI entre Labview et Kuka.
La connexion RSI (Robot Sensor Interface) qui est une interface de communication Ethernet entre le robot industriel et un système de capteurs, et qui doit être intégré au programme KRL.
Pour se faire, il est nécessaire d'établir des fichiers SRC, XML et RSI. J'utilise donc le logiciel ''RSIVisualShell'' afin de réaliser la connexion RSI.

*Les données prévelées du fichier CSV généré par ''Labview'' sont donc inscrites en entrées par réception de bloc de données au format XML.
Le mode de traitement des signaux est fixé à 12ms avec filtrage (variable de champ #IPO).

*Ci-dessous les fichiers réalisés :
**Fichier XML :
[[Fichier:GCODE_XML.png|1000px|thumb|center|Fichier XML.]]
**Fichier RSI :
[[Fichier:GCODE_RSI.png|1000px|thumb|center|Fichier RSI.]]
**Fichier SRC :
[[Fichier:GCODE_SRC.png|1000px|thumb|center|Fichier SRC.]]

Difficultés rencontrées :
*Durant presque une semaine, j'ai été bloquée suite à l'ajout inopportun d'un espace vide qui ne permettait donc pas la lecture du fichier RSI ;
*Le fichier source 8 jours avant d'être débloqué. En effet, j'avais effectué les essais sur le partage d'une seule donnée via la liaison RSI et le problème d'envoi/réception était correct. Cependant, lorsque j'ai ajouté toutes les valeurs à transmettre, le robot envoyait bien les instructions mais ne recevait aucune variable. Lundi 19 février j'ai donc décidé de reprendre le code ligne par ligne pour voir la différence, et en copiant le programme SRC initial ligne par ligne, j'ai supprimé l'erreur tout en conservant exactement le même code. Je soupçonne donc que des caractères inscrits dans mon fichier posaient problème mais je ne sais pas lesquels.
*Ensuite, toujours dans le fichier source, j'ai eu de la difficulté à trouver le moyen de changer les base et outil pour le système Robot+Buse, mais après lecture de la documentation, l'aide de Othman, j'ai finalement trouvé l'erreur ;
*Pour finir, la dernière difficulté rencontrée réside en l'affectation en temps réelle de la vitesse du robot. En effet, je souhaitais effectuer directement l'affectation via les variables $VEL.CP=$SEN_PREA[9], or celle-ci doit être modifiée via la commande BAS(VEL_CP,$SEN_PREA[9]). J'ai donc passé ma journée de mardi à résoudre ce problème.

===Semaine 7 + Soutenance (du 20/02/2018 au 21/02/2018)===
*Finalisation du projet.
*Rédaction du rapport.
*Réalisation de la présentation

Fichier:Interface GCODE.PNG

2018-02-21T11:47:52Z

Dmarruch :

Fichier:GCODE X.PNG

2018-02-21T11:47:38Z

Dmarruch :

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-02-21T11:46:42Z

Dmarruch : /* Contexte du projet */

''Etudiante : Diana Marrucho ''
''Encadrants : Rochdi Merzouki, Othman Lakhal''

== Présentation générale du projet ==

===Contexte du projet===
La société All-Trends est une start-up lilloise développant la technologie e-Bridium® de fabrication additive directe à granulés en plasturgie dans le but d'imprimer des pièces en polymère à partir de granulés plastiques non-propriétaires.

Dans le cadre du programme Centaure, All-Trends s'est associée à Polytech Lille et le laboratoire CRIStAL afin de l'accompagner pour la réalisation d'un prototype d'impression 3D robotisé à base des granulés. Une buse, permettant la fusion des granulés est fixée à un robot Kuka pour pouvoir imprimer dans toutes les positions.

Actuellement, des pièces à base de PS (Polystyrène) ont été réalisées en salle C002 à Polytech Lille et des tests sont effectués les vendredis.
[[Fichier:GCODE_EBRIDIUM.png|700px|thumb|center|Robot KUKA et Buse ALL-TRENDS.]]
[[Fichier:GCODE_PIECES.png|700px|thumb|center|Pièces imprimées en PS.]]

==Cahier des charges==

===But du projet===
Dans une première partie, l'objectif est de tester différents types de matières et d'en contrôler la régulation de température de la buse en fonction des granulés utilisés.

Actuellement, le robot est contrôlé par un contrôleur ''CompactRIO'' de ''National Instruments''.
La seconde partie du projet consisterait donc à intégrer le programme de commande sur une ''MyRIO'' de ''National Instruments''.

Pour se faire, l'utilisation du logiciel LabVIEW est nécessaire.

===Planning Prévisionnel===
*Semaine 1 :
**Apprentissage du LabVIEW ;
*Semaine 2 :
**Prise en main sur la programmation et la commande du dispositif robotisé existant ;
*Semaine 3-4 :
**Test d'impression et régulation pour trois différentes matières ;
*Semaine 5 :
**Intégration du programme de commande et supervision embarqué sur une MyRIO de ''National Instruments'' ;
*Semaine 6 :
**Test et validation ;
**Rédaction du rapport.

==Avancement du projet==
===Semaine 1 (du 11/01/2018 au 14/01/2018)===
*A partir de mercredi, j'ai repris en main le logiciel LabVIEW. Lecture de la documentation d'utilisation Labview et du CompactRIO de ''National Instruments'' :
**Lien de la documentation :[https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwjSvrTkydnYAhVEtBQKHSUaDIcQFggxMAE&url=http%3A%2F%2Fwww.mit.bme.hu%2Fsystem%2Ffiles%2Foktatas%2Ftargyak%2F7258%2Fcriodevgudfull.pdf&usg=AOvVaw3ZNQC-jm6kkskpguWi_ZzS]
*Réalisation de tests sur la jambe de cheval : contrôle par LabVIEW via CompactRIO, analog output, du système électro-pneumatique pour le contrômle des muscles de la jambe de cheval.
*'''Nouvel objectif : réaliser un interpréteur du G-Code via LabVIEW afin de pouvoir tout contrôler directement par National Instruments sans l'utilisation de Matlab. Attention à prendre en compte que ce n'est pas la plateforme support qui se déplace mais le bras robot Kuka.'''
*Vendredi : en présence de monsieur Grégory SANT de la société All-Trends, nous avons effectués des tests d'impression de pièces 3D avec des granulés de polystyrène en effectuant des variations des deux anneaux de température, de débit de sortie de buse, de vitesse ou de hauteur afin de pouvoir renseigner les paramètres les plus optimaux pour le robot industriel et la tête d'impression All-Trends. L'objectif des prochains tests sera de diminuer la taille de la buse afin de se rendre compte de son impact sur la pièce imprimée et surtout de pouvoir avoir une résolution maximale avec un temps réduit. Effectivement, contrairement à une imprimante 3D classique, ce robot plutôt destiné à l'industrie, permet de sortir 700g de matériaux à l'heure contre 1kg la journée pour l'imprimante classique. De plus, le coût de la matière est moindre contrairement au fil qui est déjà dégradé par sa transformation en fil.

===Semaine 2 (du 15/01/2018 au 21/01/2018)===
*Actuellement, afin de pouvoir réaliser des impression, ''Matlab'' était utilisé afin de générer les différentes trajectoires. Les pièces réalisées jusqu'à présent sont des pièces dont le périmètre était imprimé, sans grand angle et sans support pour une pièce déportée. L'objectif de la semaine 2 est donc de pouvoir tester de nouvelles formes.
*Afin de pouvoir convertir le fichier 3D, généralement de format STL, on utilise le slicer CURA que l'on paramètre avec les données correspondant au diamètre de la buse utilisée, à la température des couronnes et du plateau chauffant, au diamètre de sortie du cordon, à la hauteur de couche...
*Le but de cette semaine est donc de réaliser un interpréteur avec ''LabVIEW'' capable de transformer le G-Code en fichier CSV :
**Dans un premier temps, j'ai d'abord cherché à récupérer toutes les données du gcode et les indexer dans un tableau :
[[Fichier:GCODE1.PNG|700px|thumb|center|Récupération des données du Gcode par LabVIEW.]]
*Ensuite, afin de ne garder que les données qui nous intéressent, à savoir les lignes de code contenant les commandes en G, j'ai récupéré selon toutes les différentes commandes (à savoir les commandes selon G0, G1, G2, G3, G4, G20, G21, G28, G29, G90, G91 et G92 selon la documentation du ''Wiki RepRap'' [http://reprap.org/wiki/G-code/fr#M205_Repetier]
*A partir de mercredi, et de la lecture du document ''Software KUKA.CAMRob KRC 3.0'', et des paramètres que CAMRob peut prendre en considération, je me suis limitée à la récupération des données correspondantes. En effet, le fichier de donnée CAM peut contenir jusqu'à 26 paramètres selon des positions bien précises. Ainsi, voici les données pouvant être récupérées pour le fichier CSV utilisé par CAMRob :
[[Fichier:GCODE2.PNG|700px|thumb|center|CAMRob data parameters.]]
*Les données récupérées seront donc les cordonnées cartésiennes selon les axes X, Y et Z pour les paramètres 2, 3 et 4. Suite au paramétrage de la buse et de la base du robot Kuka, on récupère les rotations A, B et C. Car elles ne sont pas paramétrées dans le slicer. De plus, on y introduit la vitesse de 0.04m/s qui sera ensuite réglée en pourcentage sur CAMRob, ainsi que l'accélération que l'on a fixé à 1m/s². Tous les autres paramètres sont fixés à 0 car non utilisés. Cela me donne donc en face avant et diagramme de LabVIEW les aperçus suivants :
[[Fichier:GCODE3.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE4.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Vendredi, suite à des tests dès le matin avec la présence de messieurs Gragory SANT et Othman LAKHAL, nous avons imprimé pour la première fois avec le Polystyrène, des pièces pleines. Cela fut dans un premier temps compliqué car le slicer CURA n'était pas très précis concernant les premières couches, le motif du remplissage et les pièces n'étaient donc pas parfaites. Nous avons donc essayé d'imprimer des pièces basiques (des disques, des rectangles, une attache fleur, une raquette sans angles et ne nécessitant pas de support) avec différents remplissages (entre 15 et 100%). Suite aux réglages des différents paramètres, au changement de slicer vers ''Slic3r'' qui est plus précis et qui nous permet de ne pas faire de motif de remplissage aléatoirement et aux différents tests de la journée, notre réglage le plus précis était donc le suivant :
**Température Haute de la buse : 250°C ;
**Température Basse de la buse : 260°C ;
**Vitesse : 75% de 0.04m/s ;
**Débit : 0.04V.
**Et dont les paramètres sur ''Slic3r'' étaient les suivants :
[[Fichier:GCODE5.png|1000px|thumb|center|Slic3r Parameters.]]

===Semaine 3 (du 22/01/2018 au 28/01/2018)===
*Le premier objectif de cette semaine est maintenant de prendre en compte les vitesses générées par le slicer et non plus de la fixer nous même sur CAMRob en pourcentage de la vitesse maximale. Pour cela, je vais récupérer les données selon le paramètre F des commandes G. Les vitesses sont différentes selon que nous sommes en remplissage, en support, en transfert d'un point à l'autre ou encore en périmètre.
*De plus, suite aux problèmes rencontrés vendredi, c'est-à-dire que certaines cases étaient vides donc posaient problème lors de la lecture par CAMRob du fichier CSV, j'ai supprimé ses cases car elles permettaient de ne pas fournir de matière PS à la buse pour aller d'un point à l'autre, mais la communication ne se fait pas encore directement entre CAMRob et le CompactRIO.
*Voici donc le diagramme réalisé et la face avant sur LabVIEW :
[[Fichier:GCODE6.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE7.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Afin de pouvoir récupérer les données générées par notre fichier CSV lu par ''CAMROB'', il est nécessaire d'établir une liaison RSI. Cette liaison RSI entre le robot et le PC est nécessaire pour récupérer la vitesse du moteur de la buse afin de ne plus avoir à la fixer nous même.
*Le prochain objetif est donc de tester de nouvelles pièces pleines ou creuses avec les nouveaux réglages, et par la suite commencer à tester des pièces avec nécessité de support car présentent des angles importants et/ou sont déportées.
*Mercredi :
**Test des trajectoires sur le robot KUKA du nouveau programme et essai d'un début de pièce avec support : remarque que le plateau de verre était soumis à une quantité importante de vibrations surtout au changement de trajectoire sur petites pièces même en contrôle T1 (c'est-à-dire sans mode auto). Il était donc nécessaire de trouver un moyen de fixation et de stabilisation pour les futurs tests.

*Cette semaine, et dans un second temps, j'ai optimisé le fichier ''LabVIEW'':
**Réalisation de sous-VI de chaque récupération des données intéressanteS (positions X, Y, Z, vitesse F, et vitesse moteur E en tour/min) afin de simplifier l'affichage et de permettre une meilleure ergonomie de l'interface :
[[Fichier:GCODE_X.png|1000px|thumb|center|Récupération du paramètre X (idem pour Y et Z avec limite de 0).]]
[[Fichier:GCODE_F.png|1000px|thumb|center|Récupération de la variable vitesse robot F et conversion en m/s]]
[[Fichier:GCODE_CALCUL_E.png|1000px|thumb|center|Calcul de la valeur de la vitesse moteur E à partir de F.]]
[[Fichier:GCODE_E.png|1000px|thumb|center|Récupération de la valeur E et rotation inverse si valeur nulle.]]
[[Fichier:Interface_GCODE.png|1000px|thumb|center|Interface utilisateur Labview pour G-Code en CSV.]]

*Tests du vendredi et avancées :
**Ce vendredi, Othman a mis en place la liaison RSI entre le robot (CAMROB) et LabVIEW afin d'envoyer la vitesse moteur traduite par la relation . Cette liaison consiste dons à récupérer la vitesse du moteur de l'extrudeur et de passer en mode auto.
**Tests :
***1er test : pièce pleine avec un remplissage de 30% sur une forme parallélépipédique avec une vitesse du robot à 50% de vitesses de périmètres et de transfert à 60mm/sec, et une vitesse de remplissage à 80mm/sec. Notre première remarque était que le robot était trop lent donc arrêt au bout de 3 couches.
***2nd test : pièce identique réduite de 50% selon les axes X et Y pour permettre une réalisation plus rapide, mais avec un remplissage de 30% à une vitesse de 75%. Le robot est légèrement plus rapide et de ce fait nous avons pu terminer la pièce dans les délais. Les principales remarques étaient que les contours étaient effectués trop rapidement, et que l'intérieur, donc le remplissage de la pièce à 30% était bien trop rapide et débitait donc trop de matière.
***3ème test : pièce identique, avec un remplissage à 15% et une diminution de la vitesse de remplissage et de transfert avec les nouveaux paramètres.

**Conclusion de ces tests : nous pouvons désormais réaliser des pièces pleines grâce à l'interface ''LabVIEW'', mais les paramètres de l'impression sont encore à améliorer pour le polystyrène. La dernière pièce réalisée lors de ces tests est prometteuse. Maintenant, il faut chercher les paramètres à récupérer pour améliorer la qualité de l'impression, et surtout augmenter la rapidité et donc optimiser au mieux la quantité de matière pouvant être utilisée dans l'heure (pour rappel 700g/heure de granulés peuvent être transformés par cette buse). Enfin, lors de nos essais, lorsque les moteurs s'arrêtaient, c'est à dire à 0tr/min, il y avait toujours un dépot de matière qui se faisait. Pour eviter ce phénomène, il serait intéressant de voir si nous pouvons réaliser une rétractation de la matière comme il est possible de le faire sur certaines machines 3D telles que celles du fabricarium de l'école.

*Un des objectifs de la semaine prochaine est donc de réaliser de nouvelles pièces et de permettre une meilleure finition de pièce et donc de changer les paramètres en fonction de notre avancée. Tester aussi si on ajoute des couches supplémentaires au dessus où en dessous pour observer une meilleure finition.

===Semaine 4 (du 29/01/2018 au 04/02/2018)===
*Pour contrôler l'un des paramètres qui posaient problème la semaine passée, j'ai tout d'abord essayé de réaliser une rétractation de la matière.
Pour cela, lorsque le débit doit être nul, j'ai remplacé la vitesse du moteur qui était à 0 tour/min à -10 tour/min qui permettra d'éviter un dépot de matière supplémentaire sur la pièce imprimée.

*L'un des objectif de cette semaine ainsi que de la semaine 5 est d'établir une connexion RSI complète entre Labview et le Kuka :
**Actuellement, le cheminement suivant doit être suivi pour établir la connexion avec le KUKA doit passer par CAMROB, license expensive :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> USB -> Kuka CAMROB -> RSI -> Labview
**Le but est de diminuer toutes les manipulations intermédiaires et de réaliser le cheminement suivant :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> RSI -> Communiquer avec KUKA et Tête D'impression (Buse ALLTRENDS)

*Vendredi, nous avons imprimé pour la première fois des pièces telles une grenouille et des parallélépipèdes afin de contrôler la vitesse et de présenter à une entreprise intéressée par le projet, le travail effectué. Nous avons remarqué que la vitesse introduite n'était pas respectée. En effet, en ayant bridé l'accélération à 0.1m/s², le robot limitait donc la vitesse et on observait donc une dégradation de la matière à l'intérieur de la buse. Lors du dernier essai de la journée, nous avons modifié ce paramètre, et effectivement, la dégradation du polystyrène était moins observée.
[[Fichier:GCODE_CUBE.jpg|1000px|thumb|center|Support et premières couches du cube.]]
[[Fichier:GCODE_GRENOUILLE.jpg|1000px|thumb|center|Première grenouille imprimée.]]
On a remarqué qu'il faudrait améliorer les contours par la suite.

===Semaines 5, 6 et 7 (du 05/02/2018 au 20/02/2018)===
*Le contrôleur MYRio a été commandé semaine 5 et réceptionné le jeudi 15 février.

*Ensuite, l'objectif des semaines 4 et 5 est donc d'établir la connexion RSI entre Labview et Kuka.
La connexion RSI (Robot Sensor Interface) qui est une interface de communication Ethernet entre le robot industriel et un système de capteurs, et qui doit être intégré au programme KRL.
Pour se faire, il est nécessaire d'établir des fichiers SRC, XML et RSI. J'utilise donc le logiciel ''RSIVisualShell'' afin de réaliser la connexion RSI.

*Les données prévelées du fichier CSV généré par ''Labview'' sont donc inscrites en entrées par réception de bloc de données au format XML.
Le mode de traitement des signaux est fixé à 12ms avec filtrage (variable de champ #IPO).

*Ci-dessous les fichiers réalisés :
**Fichier XML :
[[Fichier:GCODE_XML.png|1000px|thumb|center|Fichier XML.]]
**Fichier RSI :
[[Fichier:GCODE_RSI.png|1000px|thumb|center|Fichier RSI.]]
**Fichier SRC :
[[Fichier:GCODE_SRC.png|1000px|thumb|center|Fichier SRC.]]

Difficultés rencontrées :
*Durant presque une semaine, j'ai été bloquée suite à l'ajout inopportun d'un espace vide qui ne permettait donc pas la lecture du fichier RSI ;
*Le fichier source 8 jours avant d'être débloqué. En effet, j'avais effectué les essais sur le partage d'une seule donnée via la liaison RSI et le problème d'envoi/réception était correct. Cependant, lorsque j'ai ajouté toutes les valeurs à transmettre, le robot envoyait bien les instructions mais ne recevait aucune variable. Lundi 19 février j'ai donc décidé de reprendre le code ligne par ligne pour voir la différence, et en copiant le programme SRC initial ligne par ligne, j'ai supprimé l'erreur tout en conservant exactement le même code. Je soupçonne donc que des caractères inscrits dans mon fichier posaient problème mais je ne sais pas lesquels.
*Ensuite, toujours dans le fichier source, j'ai eu de la difficulté à trouver le moyen de changer les base et outil pour le système Robot+Buse, mais après lecture de la documentation, l'aide de Othman, j'ai finalement trouvé l'erreur ;
*Pour finir, la dernière difficulté rencontrée réside en l'affectation en temps réelle de la vitesse du robot. En effet, je souhaitais effectuer directement l'affectation via les variables $VEL.CP=$SEN_PREA[9], or celle-ci doit être modifiée via la commande BAS(VEL_CP,$SEN_PREA[9]). J'ai donc passé ma journée de mardi à résoudre ce problème.

===Semaine 7 + Soutenance (du 20/02/2018 au 21/02/2018)===
*Finalisation du projet.
*Rédaction du rapport.
*Réalisation de la présentation

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-02-21T11:45:04Z

Dmarruch :

''Etudiante : Diana Marrucho ''
''Encadrants : Rochdi Merzouki, Othman Lakhal''

== Présentation générale du projet ==

===Contexte du projet===
La société All-Trends est une start-up lilloise développant la technologie e-Bridium® de fabrication additive directe à granulés en plasturgie dans le but d'imprimer des pièces en polymère à partir de granulés plastiques non-propriétaires.

Dans le cadre du programme Centaure, All-Trends s'est associée à Polytech Lille et le laboratoire CRIStAL afin de l'accompagner pour la réalisation d'un prototype d'impression 3D robotisé à base des granulés. Une buse, permettant la fusion des granulés est fixée à un robot Kuka pour pouvoir imprimer dans toutes les positions.

Actuellement, des pièces à base de PS (Polystyrène) ont été réalisées en salle C002 à Polytech Lille et des tests sont effectués les vendredis.
[[Fichier:GCODE_EBRIDIUM.PNG|700px|thumb|center|Robot KUKA et Buse ALL-TRENDS.]]
[[Fichier:GCODE_PIECES.PNG|700px|thumb|center|Pièces imprimées en PS.]]

==Cahier des charges==

===But du projet===
Dans une première partie, l'objectif est de tester différents types de matières et d'en contrôler la régulation de température de la buse en fonction des granulés utilisés.

Actuellement, le robot est contrôlé par un contrôleur ''CompactRIO'' de ''National Instruments''.
La seconde partie du projet consisterait donc à intégrer le programme de commande sur une ''MyRIO'' de ''National Instruments''.

Pour se faire, l'utilisation du logiciel LabVIEW est nécessaire.

===Planning Prévisionnel===
*Semaine 1 :
**Apprentissage du LabVIEW ;
*Semaine 2 :
**Prise en main sur la programmation et la commande du dispositif robotisé existant ;
*Semaine 3-4 :
**Test d'impression et régulation pour trois différentes matières ;
*Semaine 5 :
**Intégration du programme de commande et supervision embarqué sur une MyRIO de ''National Instruments'' ;
*Semaine 6 :
**Test et validation ;
**Rédaction du rapport.

==Avancement du projet==
===Semaine 1 (du 11/01/2018 au 14/01/2018)===
*A partir de mercredi, j'ai repris en main le logiciel LabVIEW. Lecture de la documentation d'utilisation Labview et du CompactRIO de ''National Instruments'' :
**Lien de la documentation :[https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwjSvrTkydnYAhVEtBQKHSUaDIcQFggxMAE&url=http%3A%2F%2Fwww.mit.bme.hu%2Fsystem%2Ffiles%2Foktatas%2Ftargyak%2F7258%2Fcriodevgudfull.pdf&usg=AOvVaw3ZNQC-jm6kkskpguWi_ZzS]
*Réalisation de tests sur la jambe de cheval : contrôle par LabVIEW via CompactRIO, analog output, du système électro-pneumatique pour le contrômle des muscles de la jambe de cheval.
*'''Nouvel objectif : réaliser un interpréteur du G-Code via LabVIEW afin de pouvoir tout contrôler directement par National Instruments sans l'utilisation de Matlab. Attention à prendre en compte que ce n'est pas la plateforme support qui se déplace mais le bras robot Kuka.'''
*Vendredi : en présence de monsieur Grégory SANT de la société All-Trends, nous avons effectués des tests d'impression de pièces 3D avec des granulés de polystyrène en effectuant des variations des deux anneaux de température, de débit de sortie de buse, de vitesse ou de hauteur afin de pouvoir renseigner les paramètres les plus optimaux pour le robot industriel et la tête d'impression All-Trends. L'objectif des prochains tests sera de diminuer la taille de la buse afin de se rendre compte de son impact sur la pièce imprimée et surtout de pouvoir avoir une résolution maximale avec un temps réduit. Effectivement, contrairement à une imprimante 3D classique, ce robot plutôt destiné à l'industrie, permet de sortir 700g de matériaux à l'heure contre 1kg la journée pour l'imprimante classique. De plus, le coût de la matière est moindre contrairement au fil qui est déjà dégradé par sa transformation en fil.

===Semaine 2 (du 15/01/2018 au 21/01/2018)===
*Actuellement, afin de pouvoir réaliser des impression, ''Matlab'' était utilisé afin de générer les différentes trajectoires. Les pièces réalisées jusqu'à présent sont des pièces dont le périmètre était imprimé, sans grand angle et sans support pour une pièce déportée. L'objectif de la semaine 2 est donc de pouvoir tester de nouvelles formes.
*Afin de pouvoir convertir le fichier 3D, généralement de format STL, on utilise le slicer CURA que l'on paramètre avec les données correspondant au diamètre de la buse utilisée, à la température des couronnes et du plateau chauffant, au diamètre de sortie du cordon, à la hauteur de couche...
*Le but de cette semaine est donc de réaliser un interpréteur avec ''LabVIEW'' capable de transformer le G-Code en fichier CSV :
**Dans un premier temps, j'ai d'abord cherché à récupérer toutes les données du gcode et les indexer dans un tableau :
[[Fichier:GCODE1.PNG|700px|thumb|center|Récupération des données du Gcode par LabVIEW.]]
*Ensuite, afin de ne garder que les données qui nous intéressent, à savoir les lignes de code contenant les commandes en G, j'ai récupéré selon toutes les différentes commandes (à savoir les commandes selon G0, G1, G2, G3, G4, G20, G21, G28, G29, G90, G91 et G92 selon la documentation du ''Wiki RepRap'' [http://reprap.org/wiki/G-code/fr#M205_Repetier]
*A partir de mercredi, et de la lecture du document ''Software KUKA.CAMRob KRC 3.0'', et des paramètres que CAMRob peut prendre en considération, je me suis limitée à la récupération des données correspondantes. En effet, le fichier de donnée CAM peut contenir jusqu'à 26 paramètres selon des positions bien précises. Ainsi, voici les données pouvant être récupérées pour le fichier CSV utilisé par CAMRob :
[[Fichier:GCODE2.PNG|700px|thumb|center|CAMRob data parameters.]]
*Les données récupérées seront donc les cordonnées cartésiennes selon les axes X, Y et Z pour les paramètres 2, 3 et 4. Suite au paramétrage de la buse et de la base du robot Kuka, on récupère les rotations A, B et C. Car elles ne sont pas paramétrées dans le slicer. De plus, on y introduit la vitesse de 0.04m/s qui sera ensuite réglée en pourcentage sur CAMRob, ainsi que l'accélération que l'on a fixé à 1m/s². Tous les autres paramètres sont fixés à 0 car non utilisés. Cela me donne donc en face avant et diagramme de LabVIEW les aperçus suivants :
[[Fichier:GCODE3.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE4.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Vendredi, suite à des tests dès le matin avec la présence de messieurs Gragory SANT et Othman LAKHAL, nous avons imprimé pour la première fois avec le Polystyrène, des pièces pleines. Cela fut dans un premier temps compliqué car le slicer CURA n'était pas très précis concernant les premières couches, le motif du remplissage et les pièces n'étaient donc pas parfaites. Nous avons donc essayé d'imprimer des pièces basiques (des disques, des rectangles, une attache fleur, une raquette sans angles et ne nécessitant pas de support) avec différents remplissages (entre 15 et 100%). Suite aux réglages des différents paramètres, au changement de slicer vers ''Slic3r'' qui est plus précis et qui nous permet de ne pas faire de motif de remplissage aléatoirement et aux différents tests de la journée, notre réglage le plus précis était donc le suivant :
**Température Haute de la buse : 250°C ;
**Température Basse de la buse : 260°C ;
**Vitesse : 75% de 0.04m/s ;
**Débit : 0.04V.
**Et dont les paramètres sur ''Slic3r'' étaient les suivants :
[[Fichier:GCODE5.png|1000px|thumb|center|Slic3r Parameters.]]

===Semaine 3 (du 22/01/2018 au 28/01/2018)===
*Le premier objectif de cette semaine est maintenant de prendre en compte les vitesses générées par le slicer et non plus de la fixer nous même sur CAMRob en pourcentage de la vitesse maximale. Pour cela, je vais récupérer les données selon le paramètre F des commandes G. Les vitesses sont différentes selon que nous sommes en remplissage, en support, en transfert d'un point à l'autre ou encore en périmètre.
*De plus, suite aux problèmes rencontrés vendredi, c'est-à-dire que certaines cases étaient vides donc posaient problème lors de la lecture par CAMRob du fichier CSV, j'ai supprimé ses cases car elles permettaient de ne pas fournir de matière PS à la buse pour aller d'un point à l'autre, mais la communication ne se fait pas encore directement entre CAMRob et le CompactRIO.
*Voici donc le diagramme réalisé et la face avant sur LabVIEW :
[[Fichier:GCODE6.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE7.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Afin de pouvoir récupérer les données générées par notre fichier CSV lu par ''CAMROB'', il est nécessaire d'établir une liaison RSI. Cette liaison RSI entre le robot et le PC est nécessaire pour récupérer la vitesse du moteur de la buse afin de ne plus avoir à la fixer nous même.
*Le prochain objetif est donc de tester de nouvelles pièces pleines ou creuses avec les nouveaux réglages, et par la suite commencer à tester des pièces avec nécessité de support car présentent des angles importants et/ou sont déportées.
*Mercredi :
**Test des trajectoires sur le robot KUKA du nouveau programme et essai d'un début de pièce avec support : remarque que le plateau de verre était soumis à une quantité importante de vibrations surtout au changement de trajectoire sur petites pièces même en contrôle T1 (c'est-à-dire sans mode auto). Il était donc nécessaire de trouver un moyen de fixation et de stabilisation pour les futurs tests.

*Cette semaine, et dans un second temps, j'ai optimisé le fichier ''LabVIEW'':
**Réalisation de sous-VI de chaque récupération des données intéressanteS (positions X, Y, Z, vitesse F, et vitesse moteur E en tour/min) afin de simplifier l'affichage et de permettre une meilleure ergonomie de l'interface :
[[Fichier:GCODE_X.png|1000px|thumb|center|Récupération du paramètre X (idem pour Y et Z avec limite de 0).]]
[[Fichier:GCODE_F.png|1000px|thumb|center|Récupération de la variable vitesse robot F et conversion en m/s]]
[[Fichier:GCODE_CALCUL_E.png|1000px|thumb|center|Calcul de la valeur de la vitesse moteur E à partir de F.]]
[[Fichier:GCODE_E.png|1000px|thumb|center|Récupération de la valeur E et rotation inverse si valeur nulle.]]
[[Fichier:Interface_GCODE.png|1000px|thumb|center|Interface utilisateur Labview pour G-Code en CSV.]]

*Tests du vendredi et avancées :
**Ce vendredi, Othman a mis en place la liaison RSI entre le robot (CAMROB) et LabVIEW afin d'envoyer la vitesse moteur traduite par la relation . Cette liaison consiste dons à récupérer la vitesse du moteur de l'extrudeur et de passer en mode auto.
**Tests :
***1er test : pièce pleine avec un remplissage de 30% sur une forme parallélépipédique avec une vitesse du robot à 50% de vitesses de périmètres et de transfert à 60mm/sec, et une vitesse de remplissage à 80mm/sec. Notre première remarque était que le robot était trop lent donc arrêt au bout de 3 couches.
***2nd test : pièce identique réduite de 50% selon les axes X et Y pour permettre une réalisation plus rapide, mais avec un remplissage de 30% à une vitesse de 75%. Le robot est légèrement plus rapide et de ce fait nous avons pu terminer la pièce dans les délais. Les principales remarques étaient que les contours étaient effectués trop rapidement, et que l'intérieur, donc le remplissage de la pièce à 30% était bien trop rapide et débitait donc trop de matière.
***3ème test : pièce identique, avec un remplissage à 15% et une diminution de la vitesse de remplissage et de transfert avec les nouveaux paramètres.

**Conclusion de ces tests : nous pouvons désormais réaliser des pièces pleines grâce à l'interface ''LabVIEW'', mais les paramètres de l'impression sont encore à améliorer pour le polystyrène. La dernière pièce réalisée lors de ces tests est prometteuse. Maintenant, il faut chercher les paramètres à récupérer pour améliorer la qualité de l'impression, et surtout augmenter la rapidité et donc optimiser au mieux la quantité de matière pouvant être utilisée dans l'heure (pour rappel 700g/heure de granulés peuvent être transformés par cette buse). Enfin, lors de nos essais, lorsque les moteurs s'arrêtaient, c'est à dire à 0tr/min, il y avait toujours un dépot de matière qui se faisait. Pour eviter ce phénomène, il serait intéressant de voir si nous pouvons réaliser une rétractation de la matière comme il est possible de le faire sur certaines machines 3D telles que celles du fabricarium de l'école.

*Un des objectifs de la semaine prochaine est donc de réaliser de nouvelles pièces et de permettre une meilleure finition de pièce et donc de changer les paramètres en fonction de notre avancée. Tester aussi si on ajoute des couches supplémentaires au dessus où en dessous pour observer une meilleure finition.

===Semaine 4 (du 29/01/2018 au 04/02/2018)===
*Pour contrôler l'un des paramètres qui posaient problème la semaine passée, j'ai tout d'abord essayé de réaliser une rétractation de la matière.
Pour cela, lorsque le débit doit être nul, j'ai remplacé la vitesse du moteur qui était à 0 tour/min à -10 tour/min qui permettra d'éviter un dépot de matière supplémentaire sur la pièce imprimée.

*L'un des objectif de cette semaine ainsi que de la semaine 5 est d'établir une connexion RSI complète entre Labview et le Kuka :
**Actuellement, le cheminement suivant doit être suivi pour établir la connexion avec le KUKA doit passer par CAMROB, license expensive :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> USB -> Kuka CAMROB -> RSI -> Labview
**Le but est de diminuer toutes les manipulations intermédiaires et de réaliser le cheminement suivant :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> RSI -> Communiquer avec KUKA et Tête D'impression (Buse ALLTRENDS)

*Vendredi, nous avons imprimé pour la première fois des pièces telles une grenouille et des parallélépipèdes afin de contrôler la vitesse et de présenter à une entreprise intéressée par le projet, le travail effectué. Nous avons remarqué que la vitesse introduite n'était pas respectée. En effet, en ayant bridé l'accélération à 0.1m/s², le robot limitait donc la vitesse et on observait donc une dégradation de la matière à l'intérieur de la buse. Lors du dernier essai de la journée, nous avons modifié ce paramètre, et effectivement, la dégradation du polystyrène était moins observée.
[[Fichier:GCODE_CUBE.jpg|1000px|thumb|center|Support et premières couches du cube.]]
[[Fichier:GCODE_GRENOUILLE.jpg|1000px|thumb|center|Première grenouille imprimée.]]
On a remarqué qu'il faudrait améliorer les contours par la suite.

===Semaines 5, 6 et 7 (du 05/02/2018 au 20/02/2018)===
*Le contrôleur MYRio a été commandé semaine 5 et réceptionné le jeudi 15 février.

*Ensuite, l'objectif des semaines 4 et 5 est donc d'établir la connexion RSI entre Labview et Kuka.
La connexion RSI (Robot Sensor Interface) qui est une interface de communication Ethernet entre le robot industriel et un système de capteurs, et qui doit être intégré au programme KRL.
Pour se faire, il est nécessaire d'établir des fichiers SRC, XML et RSI. J'utilise donc le logiciel ''RSIVisualShell'' afin de réaliser la connexion RSI.

*Les données prévelées du fichier CSV généré par ''Labview'' sont donc inscrites en entrées par réception de bloc de données au format XML.
Le mode de traitement des signaux est fixé à 12ms avec filtrage (variable de champ #IPO).

*Ci-dessous les fichiers réalisés :
**Fichier XML :
[[Fichier:GCODE_XML.png|1000px|thumb|center|Fichier XML.]]
**Fichier RSI :
[[Fichier:GCODE_RSI.png|1000px|thumb|center|Fichier RSI.]]
**Fichier SRC :
[[Fichier:GCODE_SRC.png|1000px|thumb|center|Fichier SRC.]]

Difficultés rencontrées :
*Durant presque une semaine, j'ai été bloquée suite à l'ajout inopportun d'un espace vide qui ne permettait donc pas la lecture du fichier RSI ;
*Le fichier source 8 jours avant d'être débloqué. En effet, j'avais effectué les essais sur le partage d'une seule donnée via la liaison RSI et le problème d'envoi/réception était correct. Cependant, lorsque j'ai ajouté toutes les valeurs à transmettre, le robot envoyait bien les instructions mais ne recevait aucune variable. Lundi 19 février j'ai donc décidé de reprendre le code ligne par ligne pour voir la différence, et en copiant le programme SRC initial ligne par ligne, j'ai supprimé l'erreur tout en conservant exactement le même code. Je soupçonne donc que des caractères inscrits dans mon fichier posaient problème mais je ne sais pas lesquels.
*Ensuite, toujours dans le fichier source, j'ai eu de la difficulté à trouver le moyen de changer les base et outil pour le système Robot+Buse, mais après lecture de la documentation, l'aide de Othman, j'ai finalement trouvé l'erreur ;
*Pour finir, la dernière difficulté rencontrée réside en l'affectation en temps réelle de la vitesse du robot. En effet, je souhaitais effectuer directement l'affectation via les variables $VEL.CP=$SEN_PREA[9], or celle-ci doit être modifiée via la commande BAS(VEL_CP,$SEN_PREA[9]). J'ai donc passé ma journée de mardi à résoudre ce problème.

===Semaine 7 + Soutenance (du 20/02/2018 au 21/02/2018)===
*Finalisation du projet.
*Rédaction du rapport.
*Réalisation de la présentation

Fichier:GCODE ROBOT.jpg

2018-02-21T11:44:27Z

Dmarruch :

Fichier:GCODE PIECES.png

2018-02-21T11:44:02Z

Dmarruch :

Fichier:GCODE GRENOUILLE.PNG

2018-02-21T11:43:45Z

Dmarruch :

Fichier:GCODE F.PNG

2018-02-21T11:43:31Z

Dmarruch :

Fichier:GCODE EBRIDIUM.png

2018-02-21T11:43:03Z

Dmarruch :

Fichier:GCODE E.PNG

2018-02-21T11:42:49Z

Dmarruch :

Fichier:GCODE CUBE.PNG

2018-02-21T11:42:14Z

Dmarruch :

Fichier:GCODE CALCUL E.PNG

2018-02-21T11:36:52Z

Dmarruch :

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-02-08T11:38:03Z

Dmarruch :

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-02-08T10:30:31Z

Dmarruch : /* Semaine 4 (du 29/01/2018 au 04/02/2018) */

''Etudiante : Diana Marrucho ''
''Encadrant : Rochdi Merzouki''

== Présentation générale du projet ==

===Contexte du projet===
La société All-Trends est une start-up lilloise développant la technologie e-Bridium® de fabrication additive directe à granulés en plasturgie dans le but d'imprimer des pièces en polymère à partir de granulés plastiques non-propriétaires.

Dans le cadre du programme Centaure, All-Trends s'est associée à Polytech Lille et le laboratoire CRIStAL afin de l'accompagner pour la réalisation d'un prototype d'impression 3D robotisé à base des granulés. Une buse, permettant la fusion des granulés est fixée à un robot Kuka pour pouvoir imprimer dans toutes les positions.

Actuellement, des pièces à base de PLA (acide polyactique) ont été réalisées en salle C002 à Polytech Lille et des tests sont effectués les vendredis.

==Cahier des charges==

===But du projet===
Dans une première partie, l'objectif est de tester différents types de matières et d'en contrôler la régulation de température de la buse en fonction des granulés utilisés.

Actuellement, le robot est contrôlé par un contrôleur ''CompactRIO'' de ''National Instruments''.
La seconde partie du projet consisterait donc à intégrer le programme de commande sur une ''MyRIO'' de ''National Instruments''.

Pour se faire, l'utilisation du logiciel LabVIEW est nécessaire.

===Planning Prévisionnel===
*Semaine 1 :
**Apprentissage du LabVIEW ;
*Semaine 2 :
**Prise en main sur la programmation et la commande du dispositif robotisé existant ;
*Semaine 3-4 :
**Test d'impression et régulation pour trois différentes matières ;
*Semaine 5 :
**Intégration du programme de commande et supervision embarqué sur une MyRIO de ''National Instruments'' ;
*Semaine 6 :
**Test et validation ;
**Rédaction du rapport.

==Avancement du projet==
===Semaine 1 (du 11/01/2018 au 14/01/2018)===
*A partir de mercredi, j'ai repris en main le logiciel LabVIEW. Lecture de la documentation d'utilisation Labview et du CompactRIO de ''National Instruments'' :
**Lien de la documentation :[https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwjSvrTkydnYAhVEtBQKHSUaDIcQFggxMAE&url=http%3A%2F%2Fwww.mit.bme.hu%2Fsystem%2Ffiles%2Foktatas%2Ftargyak%2F7258%2Fcriodevgudfull.pdf&usg=AOvVaw3ZNQC-jm6kkskpguWi_ZzS]
*Réalisation de tests sur la jambe de cheval : contrôle par LabVIEW via CompactRIO, analog output, du système électro-pneumatique pour le contrômle des muscles de la jambe de cheval.
*'''Nouvel objectif : réaliser un interpréteur du G-Code via LabVIEW afin de pouvoir tout contrôler directement par National Instruments sans l'utilisation de Matlab. Attention à prendre en compte que ce n'est pas la plateforme support qui se déplace mais le bras robot Kuka.'''
*Vendredi : en présence de monsieur Grégory SANT de la société All-Trends, nous avons effectués des tests d'impression de pièces 3D avec des granulés de polystyrène en effectuant des variations des deux anneaux de température, de débit de sortie de buse, de vitesse ou de hauteur afin de pouvoir renseigner les paramètres les plus optimaux pour le robot industriel et la tête d'impression All-Trends. L'objectif des prochains tests sera de diminuer la taille de la buse afin de se rendre compte de son impact sur la pièce imprimée et surtout de pouvoir avoir une résolution maximale avec un temps réduit. Effectivement, contrairement à une imprimante 3D classique, ce robot plutôt destiné à l'industrie, permet de sortir 700g de matériaux à l'heure contre 1kg la journée pour l'imprimante classique. De plus, le coût de la matière est moindre contrairement au fil qui est déjà dégradé par sa transformation en fil.

===Semaine 2 (du 15/01/2018 au 21/01/2018)===
*Actuellement, afin de pouvoir réaliser des impression, ''Matlab'' était utilisé afin de générer les différentes trajectoires. Les pièces réalisées jusqu'à présent sont des pièces dont le périmètre était imprimé, sans grand angle et sans support pour une pièce déportée. L'objectif de la semaine 2 est donc de pouvoir tester de nouvelles formes.
*Afin de pouvoir convertir le fichier 3D, généralement de format STL, on utilise le slicer CURA que l'on paramètre avec les données correspondant au diamètre de la buse utilisée, à la température des couronnes et du plateau chauffant, au diamètre de sortie du cordon, à la hauteur de couche...
*Le but de cette semaine est donc de réaliser un interpréteur avec ''LabVIEW'' capable de transformer le G-Code en fichier CSV :
**Dans un premier temps, j'ai d'abord cherché à récupérer toutes les données du gcode et les indexer dans un tableau :
[[Fichier:GCODE1.PNG|700px|thumb|center|Récupération des données du Gcode par LabVIEW.]]
*Ensuite, afin de ne garder que les données qui nous intéressent, à savoir les lignes de code contenant les commandes en G, j'ai récupéré selon toutes les différentes commandes (à savoir les commandes selon G0, G1, G2, G3, G4, G20, G21, G28, G29, G90, G91 et G92 selon la documentation du ''Wiki RepRap'' [http://reprap.org/wiki/G-code/fr#M205_Repetier]
*A partir de mercredi, et de la lecture du document ''Software KUKA.CAMRob KRC 3.0'', et des paramètres que CAMRob peut prendre en considération, je me suis limitée à la récupération des données correspondantes. En effet, le fichier de donnée CAM peut contenir jusqu'à 26 paramètres selon des positions bien précises. Ainsi, voici les données pouvant être récupérées pour le fichier CSV utilisé par CAMRob :
[[Fichier:GCODE2.PNG|700px|thumb|center|CAMRob data parameters.]]
*Les données récupérées seront donc les cordonnées cartésiennes selon les axes X, Y et Z pour les paramètres 2, 3 et 4. Suite au paramétrage de la buse et de la base du robot Kuka, on récupère les rotations A, B et C. Car elles ne sont pas paramétrées dans le slicer. De plus, on y introduit la vitesse de 0.04m/s qui sera ensuite réglée en pourcentage sur CAMRob, ainsi que l'accélération que l'on a fixé à 1m/s². Tous les autres paramètres sont fixés à 0 car non utilisés. Cela me donne donc en face avant et diagramme de LabVIEW les aperçus suivants :
[[Fichier:GCODE3.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE4.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Vendredi, suite à des tests dès le matin avec la présence de messieurs Gragory SANT et Othman LAKHAL, nous avons imprimé pour la première fois avec le Polystyrène, des pièces pleines. Cela fut dans un premier temps compliqué car le slicer CURA n'était pas très précis concernant les premières couches, le motif du remplissage et les pièces n'étaient donc pas parfaites. Nous avons donc essayé d'imprimer des pièces basiques (des disques, des rectangles, une attache fleur, une raquette sans angles et ne nécessitant pas de support) avec différents remplissages (entre 15 et 100%). Suite aux réglages des différents paramètres, au changement de slicer vers ''Slic3r'' qui est plus précis et qui nous permet de ne pas faire de motif de remplissage aléatoirement et aux différents tests de la journée, notre réglage le plus précis était donc le suivant :
**Température Haute de la buse : 250°C ;
**Température Basse de la buse : 260°C ;
**Vitesse : 75% de 0.04m/s ;
**Débit : 0.04V.
**Et dont les paramètres sur ''Slic3r'' étaient les suivants :
[[Fichier:GCODE5.png|1000px|thumb|center|Slic2r Parameters.]]

===Semaine 3 (du 22/01/2018 au 28/01/2018)===
*Le premier objectif de cette semaine est maintenant de prendre en compte les vitesses générées par le slicer et non plus de la fixer nous même sur CAMRob en pourcentage de la vitesse maximale. Pour cela, je vais récupérer les données selon le paramètre F des commandes G. Les vitesses sont différentes selon que nous sommes en remplissage, en support, en transfert d'un point à l'autre ou encore en périmètre.
*De plus, suite aux problèmes rencontrés vendredi, c'est-à-dire que certaines cases étaient vides donc posaient problème lors de la lecture par CAMRob du fichier CSV, j'ai supprimé ses cases car elles permettaient de ne pas fournir de matière PS à la buse pour aller d'un point à l'autre, mais la communication ne se fait pas encore directement entre CAMRob et le CompactRIO.
*Voici donc le diagramme réalisé et la face avant sur LabVIEW :
[[Fichier:GCODE6.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE7.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]
*Le prochain objetif est donc de tester de nouvelles pièces pleines ou creuses avec les nouveaux réglages, et par la suite commencer à tester des pièces avec nécessité de support car présentent des angles importants et/ou sont déportées.

===Semaine 4 (du 29/01/2018 au 04/02/2018)===
*Pour contrôler l'un des paramètres qui posaient problème la semaine passée, j'ai tout d'abord essayé de réaliser une rétractation de la matière.
Pour cela, lorsque le débit doit être nul, j'ai remplacé la vitesse du moteur qui était à 0 tour/min à -10 tour/min qui permettra d'éviter un dépot de matière supplémentaire sur la pièce imprimée.

*L'un des objectif de cette semaine ainsi que de la semaine 5 est d'établir une connexion RSI complète entre Labview et le Kuka :
**Actuellement, le cheminement suivant doit être suivi pour établir la connexion avec le KUKA doit passer par CAMROB, license expensive :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> USB -> Kuka CAMROB -> RSI -> Labview
**Le but est de diminuer toutes les manipulations intermédiaires et de réaliser le cheminement suivant :
***Logiciel de CAO -> Slicer délivrant un GCODE -> Convertisseur GCODE en CSV (Labview) -> RSI -> Communiquer avec KUKA et Tête D'impression (Buse ALLTRENDS)

*Vendredi, nous avons imprimé pour la première fois des pièces telles une grenouille (Photo ci-dessous) et des parallélépipèdes afin de contrôler la vitesse et de présenter à une entreprise intéressée par le projet, le travail effectué. Nous avons remarqué que la vitesse introduite n'était pas respectée. En effet, en ayant bridé l'accélération à 0.1m/s², le robot limitait donc la vitesse et on observait donc une dégradation de la matière à l'intérieur de la buse. Lors du dernier essai de la journée, nous avons modifié ce paramètre, et effectivement, la dégradation du polystyrène était moins observée.

===Semaine 5 (du 05/02/2018 au 11/02/2018)===

===Semaine 6 (du 12/02/2018 au 18/02/2017)===

===Semaine 7 + Soutenance (du 19/02/2018 au 23/02/2018)===

==Bibliographie==

==Annexes==

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-01-23T12:10:07Z

Dmarruch : /* Avancement du projet */

''Etudiante : Diana Marrucho ''
''Encadrant : Rochdi Merzouki''

== Présentation générale du projet ==

===Contexte du projet===
La société All-Trends est une start-up lilloise développant la technologie e-Bridium® de fabrication additive directe à granulés en plasturgie dans le but d'imprimer des pièces en polymère à partir de granulés plastiques non-propriétaires.

Dans le cadre du programme Centaure, All-Trends s'est associée à Polytech Lille et le laboratoire CRIStAL afin de l'accompagner pour la réalisation d'un prototype d'impression 3D robotisé à base des granulés. Une buse, permettant la fusion des granulés est fixée à un robot Kuka pour pouvoir imprimer dans toutes les positions.

Actuellement, des pièces à base de PLA (acide polyactique) ont été réalisées en salle C002 à Polytech Lille et des tests sont effectués les vendredis.

==Cahier des charges==

===But du projet===
Dans une première partie, l'objectif est de tester différents types de matières et d'en contrôler la régulation de température de la buse en fonction des granulés utilisés.

Actuellement, le robot est contrôlé par un contrôleur ''CompactRIO'' de ''National Instruments''.
La seconde partie du projet consisterait donc à intégrer le programme de commande sur une ''MyRIO'' de ''National Instruments''.

Pour se faire, l'utilisation du logiciel LabVIEW est nécessaire.

===Planning Prévisionnel===
*Semaine 1 :
**Apprentissage du LabVIEW ;
*Semaine 2 :
**Prise en main sur la programmation et la commande du dispositif robotisé existant ;
*Semaine 3-4 :
**Test d'impression et régulation pour trois différentes matières ;
*Semaine 5 :
**Intégration du programme de commande et supervision embarqué sur une MyRIO de ''National Instruments'' ;
*Semaine 6 :
**Test et validation ;
**Rédaction du rapport.

==Avancement du projet==
===Semaine 1 (du 11/01/2018 au 14/01/2018)===
*A partir de mercredi, j'ai repris en main le logiciel LabVIEW. Lecture de la documentation d'utilisation Labview et du CompactRIO de ''National Instruments'' :
**Lien de la documentation :[https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwjSvrTkydnYAhVEtBQKHSUaDIcQFggxMAE&url=http%3A%2F%2Fwww.mit.bme.hu%2Fsystem%2Ffiles%2Foktatas%2Ftargyak%2F7258%2Fcriodevgudfull.pdf&usg=AOvVaw3ZNQC-jm6kkskpguWi_ZzS]
*Réalisation de tests sur la jambe de cheval : contrôle par LabVIEW via CompactRIO, analog output, du système électro-pneumatique pour le contrômle des muscles de la jambe de cheval.
*'''Nouvel objectif : réaliser un interpréteur du G-Code via LabVIEW afin de pouvoir tout contrôler directement par National Instruments sans l'utilisation de Matlab. Attention à prendre en compte que ce n'est pas la plateforme support qui se déplace mais le bras robot Kuka.'''
*Vendredi : en présence de monsieur Grégory SANT de la société All-Trends, nous avons effectués des tests d'impression de pièces 3D avec des granulés de polystyrène en effectuant des variations des deux anneaux de température, de débit de sortie de buse, de vitesse ou de hauteur afin de pouvoir renseigner les paramètres les plus optimaux pour le robot industriel et la tête d'impression All-Trends. L'objectif des prochains tests sera de diminuer la taille de la buse afin de se rendre compte de son impact sur la pièce imprimée et surtout de pouvoir avoir une résolution maximale avec un temps réduit. Effectivement, contrairement à une imprimante 3D classique, ce robot plutôt destiné à l'industrie, permet de sortir 700g de matériaux à l'heure contre 1kg la journée pour l'imprimante classique. De plus, le coût de la matière est moindre contrairement au fil qui est déjà dégradé par sa transformation en fil.

===Semaine 2 (du 15/01/2018 au 21/01/2018)===
*Actuellement, afin de pouvoir réaliser des impression, ''Matlab'' était utilisé afin de générer les différentes trajectoires. Les pièces réalisées jusqu'à présent sont des pièces dont le périmètre était imprimé, sans grand angle et sans support pour une pièce déportée. L'objectif de la semaine 2 est donc de pouvoir tester de nouvelles formes.
*Afin de pouvoir convertir le fichier 3D, généralement de format STL, on utilise le slicer CURA que l'on paramètre avec les données correspondant au diamètre de la buse utilisée, à la température des couronnes et du plateau chauffant, au diamètre de sortie du cordon, à la hauteur de couche...
*Le but de cette semaine est donc de réaliser un interpréteur avec ''LabVIEW'' capable de transformer le G-Code en fichier CSV :
**Dans un premier temps, j'ai d'abord cherché à récupérer toutes les données du gcode et les indexer dans un tableau :
[[Fichier:GCODE1.PNG|700px|thumb|center|Récupération des données du Gcode par LabVIEW.]]
*Ensuite, afin de ne garder que les données qui nous intéressent, à savoir les lignes de code contenant les commandes en G, j'ai récupéré selon toutes les différentes commandes (à savoir les commandes selon G0, G1, G2, G3, G4, G20, G21, G28, G29, G90, G91 et G92 selon la documentation du ''Wiki RepRap'' [http://reprap.org/wiki/G-code/fr#M205_Repetier]
*A partir de mercredi, et de la lecture du document ''Software KUKA.CAMRob KRC 3.0'', et des paramètres que CAMRob peut prendre en considération, je me suis limitée à la récupération des données correspondantes. En effet, le fichier de donnée CAM peut contenir jusqu'à 26 paramètres selon des positions bien précises. Ainsi, voici les données pouvant être récupérées pour le fichier CSV utilisé par CAMRob :
[[Fichier:GCODE2.PNG|700px|thumb|center|CAMRob data parameters.]]
*Les données récupérées seront donc les cordonnées cartésiennes selon les axes X, Y et Z pour les paramètres 2, 3 et 4. Suite au paramétrage de la buse et de la base du robot Kuka, on récupère les rotations A, B et C. Car elles ne sont pas paramétrées dans le slicer. De plus, on y introduit la vitesse de 0.04m/s qui sera ensuite réglée en pourcentage sur CAMRob, ainsi que l'accélération que l'on a fixé à 1m/s². Tous les autres paramètres sont fixés à 0 car non utilisés. Cela me donne donc en face avant et diagramme de LabVIEW les aperçus suivants :
[[Fichier:GCODE3.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE4.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]

*Vendredi, suite à des tests dès le matin avec la présence de messieurs Gragory SANT et Othman LAKHAL, nous avons imprimé pour la première fois avec le Polystyrène, des pièces pleines. Cela fut dans un premier temps compliqué car le slicer CURA n'était pas très précis concernant les premières couches, le motif du remplissage et les pièces n'étaient donc pas parfaites. Nous avons donc essayé d'imprimer des pièces basiques (des disques, des rectangles, une attache fleur, une raquette sans angles et ne nécessitant pas de support) avec différents remplissages (entre 15 et 100%). Suite aux réglages des différents paramètres, au changement de slicer vers ''Slic3r'' qui est plus précis et qui nous permet de ne pas faire de motif de remplissage aléatoirement et aux différents tests de la journée, notre réglage le plus précis était donc le suivant :
**Température Haute de la buse : 250°C ;
**Température Basse de la buse : 260°C ;
**Vitesse : 75% de 0.04m/s ;
**Débit : 0.04V.
**Et dont les paramètres sur ''Slic3r'' étaient les suivants :
[[Fichier:GCODE5.png|1000px|thumb|center|Slic2r Parameters.]]

===Semaine 3 (du 22/01/2018 au 28/01/2018)===
*Le premier objectif de cette semaine est maintenant de prendre en compte les vitesses générées par le slicer et non plus de la fixer nous même sur CAMRob en pourcentage de la vitesse maximale. Pour cela, je vais récupérer les données selon le paramètre F des commandes G. Les vitesses sont différentes selon que nous sommes en remplissage, en support, en transfert d'un point à l'autre ou encore en périmètre.
*De plus, suite aux problèmes rencontrés vendredi, c'est-à-dire que certaines cases étaient vides donc posaient problème lors de la lecture par CAMRob du fichier CSV, j'ai supprimé ses cases car elles permettaient de ne pas fournir de matière PS à la buse pour aller d'un point à l'autre, mais la communication ne se fait pas encore directement entre CAMRob et le CompactRIO.
*Voici donc le diagramme réalisé et la face avant sur LabVIEW :
[[Fichier:GCODE6.png|1000px|thumb|center|Diagramme de l'interpréteur GCODE en CSV.]]
[[Fichier:GCODE7.PNG|700px|thumb|center|Face avant de l'interpréteur GCODE en CSV.]]
*Le prochain objetif est donc de tester de nouvelles pièces pleines ou creuses avec les nouveaux réglages, et par la suite commencer à tester des pièces avec nécessité de support car présentent des angles importants et/ou sont déportées.

===Semaine 4 (du 29/01/2018 au 04/02/2018)===

===Semaine 5 (du 05/02/2018 au 11/02/2018)===

===Semaine 6 (du 12/02/2018 au 18/02/2017)===

===Semaine 7 + Soutenance (du 19/02/2018 au 23/02/2018)===

==Bibliographie==

==Annexes==

Fichier:GCODE7.PNG

2018-01-23T12:04:26Z

Dmarruch :

Fichier:GCODE6.png

2018-01-23T12:04:11Z

Dmarruch : Dmarruch a téléversé une nouvelle version de Fichier:GCODE6.png

Fichier:GCODE6.png

2018-01-23T12:03:22Z

Dmarruch :

Fichier:GCODE5.png

2018-01-23T11:43:20Z

Dmarruch :

Fichier:GCODE4.PNG

2018-01-23T11:28:25Z

Dmarruch :

Fichier:GCODE3.png

2018-01-23T11:28:05Z

Dmarruch :

Fichier:GCODE2.PNG

2018-01-23T11:09:00Z

Dmarruch :

Fichier:GCODE1.PNG

2018-01-23T10:50:58Z

Dmarruch :

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-01-15T10:21:59Z

Dmarruch : /* Semaine 1 (du 11/01/2018 au 14/01/2018) */

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-01-15T10:18:43Z

Dmarruch : /* Semaine 1 (du 11/01/2018 au 14/01/2018) */

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-01-15T10:15:58Z

Dmarruch : /* Avancement du projet */

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-01-15T10:15:38Z

Dmarruch : /* Semaine 1 (du 11/01/2018 au 14/01/2018) */

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-01-15T10:15:00Z

Dmarruch : /* Planning Prévisionnel */

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-01-15T09:50:59Z

Dmarruch : /* Semaine 1 (du 09/01/2018 au 14/01/2018) */

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-01-09T16:35:45Z

Dmarruch : /* But du projet */

P38 Conception par fabrication additive des pièces en plastique à partir d’un robot

2018-01-09T16:33:28Z

Dmarruch : Page créée avec « ''Etudiante : Diana Marrucho '' ''Encadrant : Rochdi Merzouki'' == Présentation générale du projet == ===Contexte du projet=== La société All-Trends est une sta... »

Projets IMA5 2017/2018

2018-01-09T15:54:24Z

Dmarruch : /* 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.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>
<tr>
<td>[[P1 Conception d'une pompe automatique à insuline]]</td>
<td>Alice Coffin / Amina Fahem</td>
<td>Belkacem Ould Bouamama</td>
<td>[[Fichier:rapport_mi_PFE_COFFIN_FAHEM.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P18 Localisation of quadrotors]]</td>
<td>Nicky UNG / Hugo Delatte</td>
<td>Jérémie DEQUIDT / Gang ZHENG</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P25 Développement d'un cobot ]]</td>
<td>Tristan HART</td>
<td>Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys </td>
<td>[[Fichier:RapportIntermédiaire_PFE25_HART.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P29 QT pour tablette à retour tactile]]</td>
<td>lValentin BEAUCHAMP / Vivian SENAFFE</td>
<td>Laurent GRISONI</td>
<td>[[Fichier:Rapport_pfe_BEAUCHAMP_SENAFFE.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P30 patcher l’IoT par intrusion]]</td>
<td>Alexis DORIAN</td>
<td>Thomas Vantroys /Worldline</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P33 Utilisation de Nao avec des enfants autistes]]</td>
<td>Antoine ARNAUDET</td>
<td>Thomas VANTROYS</td>
<td> [[Fichier:ARNAUDET_ANTOINE_RAPPORT_DECEMBRE_2017_PFE.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P34 Robot reconstructeur de mouvement]]</td>
<td>Baptiste GRILLERE / Jean-Baptiste SAISON</td>
<td>Rochdi MERZOUKI / Guillaume DEWAELE</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P21 Projet bras déformable antagoniste]]</td>
<td>Florian GIOVANNANGELI</td>
<td>Thor BIEZE</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P20 Projet marionnette déformable interactive ]]</td>
<td>Bacem HAGUI</td>
<td>Félix VANNESTE, Jeremie DEQUIDT</td>
<td> [[Fichier:bacem_mi_parcours.pdf]] </td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P5 Commande d’une centrale de production de biogaz ]]</td>
<td>Cheikh Soilihi SAID AHMED</td>
<td>Midzodzi PEKPE </td>
<td>[[Fichier:Rapport_intermediaire.pdf]]</td>
<td> </td>
<td> </td>
</tr>

<tr>
<td>[[P15 Réseau de capteurs temps réel ]]</td>
<td>Edmur Lopes</td>
<td>Alexandre Boé / Xavier Redon / Thomas Vantroys</td>
<td>[[Fichier:Rapport_mi_parcours.pdf ]] </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P23 Application de gestion de conteneurs pour sites Web]]</td>
<td>Alexis MACHEREZ</td>
<td>Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P36 Robots Mobiles Chorégraphes]]</td>
<td>Joshua LETELLIER</td>
<td>Rochdi MERZOUKI</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P26 Réseau de capteurs de pollution]]</td>
<td>Marianne BUTAYE</td>
<td>Alexandre BOE / Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P32 Apprentissage automatique pour la détection d’attaques par déni de services ]]</td>
<td>Robin Cavalieri</td>
<td>Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P27 Réseau LoRaWAN ]]</td>
<td>François Lefevre</td>
<td>Alexandre BOE / Xavier REDON / Thomas VANTROYS</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P38 Conception par fabrication additive des pièces en plastique à partir d’un robot]]</td>
<td>Diana Marrucho</td>
<td>Rochdi MERZOUKI</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
</table>

== Matériel nécessaires ==

<table border="1">
<tr>
<th>Projet</th>
<th>Matériel</th>
</tr>
<tr>
<td>P15</td>
<td> 2 câbles usb </td>
</tr>
<tr>
<td> P27 Réseau LoRaWAN </td>
<td> 1 Raspberry Pi 3 + boîtier + alimentation + câble USB 
 3 STM32 Nucleo + 3 câbles mini-USB 

 3 modules émetteurs LoRa 

 1 module récepteur LoRa 

 1 carte SD 

 10 câbles de connexion 
</td>
</tr>

Fichier:P34 Rapport Projet Haptique COFFIN MARRUCHO V5.pdf

2017-05-10T20:33:16Z

Dmarruch : a téléversé une nouvelle version de « Fichier:P34 Rapport Projet Haptique COFFIN MARRUCHO V5.pdf »

Fichier:P34 Rapport Projet Haptique COFFIN MARRUCHO V5.pdf

2017-05-10T19:30:06Z

Dmarruch : a téléversé une nouvelle version de « Fichier:P34 Rapport Projet Haptique COFFIN MARRUCHO V5.pdf »

Fichier:P34 Rapport Projet Haptique COFFIN MARRUCHO V5.pdf

2017-05-10T18:13:04Z

Dmarruch : a téléversé une nouvelle version de « Fichier:P34 Rapport Projet Haptique COFFIN MARRUCHO V5.pdf »

IMA4 2016/2017 P34

2017-05-10T18:01:44Z

Dmarruch : /* Fichiers Rendus */

__TOC__
 
== '''Cahier des charges''' ==

==== Contexte Général ====
'''Qu'est-ce que l'haptique ?'''
*L'haptique est la science du toucher. Elle permet de simuler des sensations comme la forme, la texture d'objets qui existent mais qui ne sont pas présents.

'''Quelques exemples d'application actuels'''
*Ecran tactile (smartphone, tablette), créer du relief pour sentir les touches d'un clavier.
*Chirurgie à distance, retour de force...

===Présentation générale du projet===
'''Actuellement'''
*Nous disposons d'une plate-forme à 6 axes de liberté et contrôlée par 6 moteurs pilotés deux à deux.
*Le programme permettant de contrôler ces moteurs se fait via un Raspberry déjà présent dans la maquette.

*Un étudiant ayant déjà travaillé sur ce projet a déjà chargé un programme permettant de contrôler les translations Tx, Ty et Tz selon les axes x, y et respectivement z.

'''Objectif du projet'''
*Le but de notre projet est de déplacer une plate-forme pour qu'une personne ayant placé un doigt sur cette surface plane puisse sentir la forme d'un objet. C'est à dire que la plate-forme devra suivre le doigt qu'une personne aura placé dessus tout en restant tangente à celui-ci.

====Tâches à réaliser====
*Concernant les déplacements de la plate-forme :
**Les déplacements en translation suivant x, y et z ont déjà été programmés.
**Objectif : comprendre comment les déplacements en translation ont été réalisés afin de pouvoir, par la suite, programmer les déplacements en rotation.

*Réalisation du programme :
**Pour réaliser le programme permettant la rotation de la plate-forme, nous allons utiliser le logiciel ''Matlab / Simulink''.
**Utilisation d'un modèle mathématique pour pouvoir tester notre travail sur ordinateur.
**Programmer dans le Raspberry avec un code C réalisé avec ''Matlab'' qui traduit notre simulation mathématique.

===Exemple d'application de notre projet===
*Créer l'illusion de la présence d'une orange en sentant sa forme arrondie et sa texture en utilisant uniquement un plan sans relief.

==Environnement général et tuteurs==

===Lieu de travail principal===
*IRCICA, 50 Avenue du Halley à Villeneuve-d'Ascq

===Tuteurs du projet===
*Betty SEMAIL
*Frédéric GIRAUD
*Laurent GRISONI

==Choix techniques : matériel et logiciel==
*Logiciel principalement utilisé :
**''Matlab / Simulink''
*Matériel fourni :
**Maquette : interface plate-forme à 6 axes de liberté
**Raspberry
*Matériel à acheter :
**Aucun matériel nécessaire

==Calendrier prévisionnel==

====Calendrier====
*Présentation du contexte et du projet. Définition du cahier des charges.
**Prise de contact par mail le 29-11-2016 ;
**Rencontre le 13-12-2016 pour présentation du projet à l'IRCICA.

*Première séance à l'IRCICA : Mercredi 25 Janvier

===Feuille d'heures===
<br\>
(A noter que les heures écrites sont les heures travaillées par personne du binôme. Le quota horaire est à multiplier par 2 pour avoir le nombre d'heures total.)
<br\>
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total par personne approximativement
|-
|
Rendez-vous présentation
|
1h
|
|
|
|
|
|
|
|
|
|
|
|1h
|-
|Définition cahier des charges
|
1h
|
|
|
|
|
|
|
|
|
|
|
|1h
|-
|Explications complémentaires
|
|
|1h
|
|
|
|
|
|
|
|
|
|1h
|-
|Lecture rapport de stage et thèse
|
|4h
|
|
|
|
|
|
|
|
|
|
|4h
|-
|Récupération, tri, lecture et tests anciens programmes
|
|
|5h
|4h
|4h
|1h
|
|
|
|
|
|
|14h
|-
|Modification programme pour tester rotations
|
|
|
|
|
|2h
|
|
|
|
|
|
|2h
|-
|Tester programmes
|
|
|
|
|
|1h
|1h
|
|
|
|
|
|2h
|-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|Rédaction Wiki
|
|
|
|1h
|
|
|
|
|
|
|
|
|1h
|-
|Dont problèmes logiciels
|
|
|3h
|1h
|
|
|
|
|
|
|
|
|4h
|-
|DEUXIEME PARTIE DU PROJET : PARTIE MODELISATION
|-
|Découverte de l'ancien schéma de commande Simulink non commenté
|
|
|
|
|
|
|3h
|
|
|
|
|
|3h
|-
|Compréhension code et schéma de commande
|
|
|
|
|
|
|
|4h
|1h30
|
|
|
|5h30
|-
|Récupération ancien rapport pour aide à la compréhension
|
|
|
|
|
|
|
|
|2h30
|
|
|
|2h30
|-
|Recherches et bouquinage
|
|
|
|
|
|
|
|
|
|2h
|2h
|13h
|17h
|-
|Simulations / Tests Matlab
|
|
|
|
|
|
|
|
|
|2h
|2h
|7h
|11h
|-
|Préparation soutenance, récupération des fichier et fin rédaction rapport
|
|
|
|
|
|
|
|
|
|
|
|18h
|18h
|-
|TOTAL
|2h
|4h
|9h
|6h
|4h
|4h
|4h
|4h
|4h
|4h
|4h
|38h
|87h/pers
|}

==Avancement du Projet==

===Semaine 1===
<br\>
Séance du mercredi :
*Découverte du lieu de travail
*Lecture du rapport de stage de la personne ayant effectué les déplacements en translations sur le robot Hexapod (Valentin CATTIAU)
<br\>
Schéma du robot hexapod :
[[Fichier:schema_hexapod.png|1000px|center|thumb|Robot Hexapod]]
<br\>

===Semaine 2===
<br\>
Séance du lundi (3h):
*Découverte et premiers aperçus des programmes/code Simulink avec Michel AMBERG et Frédéric GIRAUD
*Impossibilité d'ouvrir les fichiers Simulink, problèmes de compilation avec Matlab :
**On a donc dû réinstaller Matlab, ce qui a pris beaucoup de temps.
<br\>
Séance du mercredi (4h):
*Michel AMBERG nous a montré comment compiler les différents programmes avec Matlab. Cependant, la compilation Matlab entraînait directement le lancement du programme sur le Raspberry PI 3B, donc nous devions effectuer la commande "kill" depuis le terminal dans le Raspberry.
*Nous avons ensuite effectué une copie du fichier "reset.sh" permettant d'initialiser les codeurs sur les positions fixées par l'utilisateur sur le robot Hexapod. Pour cela, nous plaçons des cales en plexiglas afin de permettre d'avoir un angle à peu près identique au niveau de chaque codeur. Ces positions étant nécessaires à l'utilisation des programmes réalisés par notre prédécesseur.
*Dans un second temps, nous avons débuté la répartition des anciens programmes dans des sous-dossiers afin de s'organiser au mieux. En même temps, nous avons compilé les programmes pour voir ceux qui peuvent encore fonctionner (certaines parties de programme sont communes sur plusieurs programmes, si elles ont été modifiées pour un programme plus récent, les anciennes versions ne fonctionnerons plus).
<br\>
Séance du jeudi (2h):
*Suite de la répartition du mercredi
*Création d'un tableau de suivi permettant de savoir à quoi correspondent chaque fichier et les GPIO du raspberry.
<br\>

===Semaines 3 et 4===
<br\>
*Durant ces séances, nous avons étudié le code réalisé par Valentin CATTIAU (code non commenté), afin de comprendre ce qu'il avait réalisé.
*A partir de cette recherche, nous avons pu déterminer quels étaient les programmes fonctionnels et ceux non utilisables. Cela nous a permis de poursuivre notre tableau de suivi démarré en semaine 2.
<br\>
*Afin de pouvoir libérer notre poste de travail (utilisé par une autre personne), nous avons dû changer de PC. Cependant, le package de Matlab Simulink pour travailler avec un Raspberry s'installait mais n'était pas utilisable. Cela nous a donc un peu ralenties dans la poursuite de notre travail d'étude du projet.
<br\>

===Semaine 5===
<br\>
*Dans un premier temps, nous avons terminé la phase de tri des fichiers non utilisés.
<br\>
*Modification code existant :
**Récupération du code fonctionnel "cercle.slx" :
***Initialement, les moteurs étaient contrôlés deux à deux en utilisant un unique capteur de position par groupe de deux moteurs (moteurs 1-2, 3-4 et 5-6).
***Notre modification consiste à récupérer les valeurs des six capteurs pour contrôler nos six moteurs indépendamment.
**Ce que nous avons réalisé :
<br\>
[[Fichier:cercle_avant_apres.png|1000px|center|thumb|Schémas Simulink avant et après modifications]]
<br\>
*Tests :
**Problème rencontré : suite au détachement des bras, qui étaient reliés deux à deux par un petit tube transparent , nous avons remarqué que les mouvements ne sont plus synchronisés. En effet, nous observions un léger décalage entre deux bras commandés à l'identique.
**Nous avons donc relancé l'exécutable initial afin de voir si le problème persistait, et en effet, ce problème existait déjà mais comme les deux bras étaient reliés, un moteur en entraînait un autre.
<br\>
Vidéo avec les bras liés deux à deux :
[[Media:video_translation.mp4|Lien vidéo]]
<br\>
<br\>
Vidéo avec les bras détachés :
[[Media:video_test_rotation.mp4|Lien vidéo]]
<br\>
<br\>
*Objectif prochaine séance : comprendre le phénomère, peut être consigne erronée (couple différents), ou dû à la succession envoi des données.
<br\>

===Semaine 6===
<br\>
*Changement d'objectif :
**Nous avons récupéré l'ancien schéma de simulation Simulink fait par Valentin CATTIAU afin d'ajouter nos objectifs, c'est à dire les rotations, ce qui nous permet donc de débuter la partie simulation.
**Début de modification du schéma afin d'y intégrer ces rotations.
<br\>
*Schéma de la commande donné dans le rapport de Valentin CATTIAU :
<br\>
[[Fichier:schema_commande.png|800px|center|thumb|Schémas Simulink avant et après modifications]]
<br\>
*Voici le schéma de simulation récupéré :
<br\>
[[Fichier:simulation_commande_haptique1.png|1200px|center|thumb|Schémas Simulink avant et après modifications]]
<br\>

===Semaine 7===
<br\>
(Poursuite de la semaine 6)
*A l'aide du rapport de stage du précédent étudiant et de nos cours de Robotique 1 avec monsieur MERZOUKI, nous avons essayé de comprendre ce qui avait été réalisé. Cependant, nous avons rencontré des difficultés concernant plusieurs points.
<br\>
*Avec nos recherches sur internet et dans le cours de Robotique 1, nous avons essayé de comprendre le travail réalisé. Nos difficultés ont été principalement l'étude de la dynamique et cinématique (directes et inverses). Les données entrées/sorties de chaque bloc ne correspondait pas à ce que nous aurions du effectivement avoir.
<br\>
*Objectif pour la prochaine séance : récupération du rapport de projet car la modélisation du robot avait été réalisée dans le cadre d'un projet de master 2 et non du stage, donc le rapport de stage était incomplet pour aider à la compréhension (code Matlab non commenté et rapport de stage faisant des rappels au rapport de projet, cependant nous n'avons pas le rapport de projet).
<br\>

===Semaine 8===
<br\>
(Poursuite de la semaine 7 + Réception du rapport de projet : [[Media:rapport_cattiau.pdf|Lien rapport Valentin CATTIAU]])
*Incohérence entre nos recherches et la réalisation de sa modélisation :
**Suite à la comparaison avec nos cours de Robotique 1 et nos recherches, nous avons enfin compris le pourquoi de notre incompréhension de sa modélisation :
***l'étude cinématique pour lui correspondait à l'étude géométrique pour nous ;
***l'étude dynamique pour lui correspondait à l'étude cinématique pour nous.
<br\>

===Semaines 9, 10 et au delà===
<br\>
*Etudes et recherches effectuées pour la réalisation de nos modèles cinématiques et géométriques.
<br\>
*Modification du schéma de simulation de la commande Matlab Simulink :
**[[Media:haptique_modele_complet.pdf|Lien pour la commande complète du système]]
**[[Media:haptique_robot.pdf|Lien pour le sous-système du robot Hexapod]]
**[[Media:haptique_controle.pdf|Lien pour le sous-système du contrôle de la commande du robot Hexapod]]
**[[Media:haptique_PID.pdf|Lien pour les PID du sous-système du contrôle de la commande du robot Hexapod]]
<br\>
*Code de génération de la jacobienne inverse avec récupération dans un fichier txt :
**Calcul de la jacobienne inverse : [[Media:jacobienne_inverse.pdf|Lien du fichier pdf]]
<br\>
*Modification des codes Matlab des blocs de cinématique et géométrique (Remarque : la jacobienne générée par Matlab étant importante, cela peut expliquer le nombre de lignes important dans les fichiers suivants) :
**Cinématique inverse : [[Media:cinematique_inverse.txt|Lien du fichier texte]]
**Cinématique directe : [[Media:cinematique_directe.txt|Lien du fichier texte]]
**Géométrique inverse : [[Media:geometrique_inverse.txt|Lien du fichier texte]]
**Géométrique directe : [[Media:geometrique_directe.txt|Lien du fichier texte]]
<br\>
*Malgré toutes les recherches effectuées et aides obtenues, nous n'avons pas pu trouver assez d'informations pour compléter notre modèle géométrique direct (temps insuffisant pour le travail à effectuer).
<br\>

== Fichiers Rendus ==
<br\>
[[Media:P34_Rapport_Projet_Haptique_COFFIN_MARRUCHO_V5.pdf|Lien du rapport de projet]]

IMA4 2016/2017 P34

2017-05-10T18:01:13Z

Dmarruch :

Fichier:P34 Rapport Projet Haptique COFFIN MARRUCHO V5.pdf

2017-05-10T17:56:42Z

Dmarruch :

IMA4 2016/2017 P34

2017-05-10T09:20:37Z

Dmarruch : /* Feuille d'heures */

__TOC__
 
== '''Cahier des charges''' ==

==== Contexte Général ====
'''Qu'est-ce que l'haptique ?'''
*L'haptique est la science du toucher. Elle permet de simuler des sensations comme la forme, la texture d'objets qui existent mais qui ne sont pas présents.

'''Quelques exemples d'application actuels'''
*Ecran tactile (smartphone, tablette), créer du relief pour sentir les touches d'un clavier.
*Chirurgie à distance, retour de force...

===Présentation générale du projet===
'''Actuellement'''
*Nous disposons d'une plate-forme à 6 axes de liberté et contrôlée par 6 moteurs pilotés deux à deux.
*Le programme permettant de contrôler ces moteurs se fait via un Raspberry déjà présent dans la maquette.

*Un étudiant ayant déjà travaillé sur ce projet a déjà chargé un programme permettant de contrôler les translations Tx, Ty et Tz selon les axes x, y et respectivement z.

'''Objectif du projet'''
*Le but de notre projet est de déplacer une plate-forme pour qu'une personne ayant placé un doigt sur cette surface plane puisse sentir la forme d'un objet. C'est à dire que la plate-forme devra suivre le doigt qu'une personne aura placé dessus tout en restant tangente à celui-ci.

====Tâches à réaliser====
*Concernant les déplacements de la plate-forme :
**Les déplacements en translation suivant x, y et z ont déjà été programmés.
**Objectif : comprendre comment les déplacements en translation ont été réalisés afin de pouvoir, par la suite, programmer les déplacements en rotation.

*Réalisation du programme :
**Pour réaliser le programme permettant la rotation de la plate-forme, nous allons utiliser le logiciel ''Matlab / Simulink''.
**Utilisation d'un modèle mathématique pour pouvoir tester notre travail sur ordinateur.
**Programmer dans le Raspberry avec un code C réalisé avec ''Matlab'' qui traduit notre simulation mathématique.

===Exemple d'application de notre projet===
*Créer l'illusion de la présence d'une orange en sentant sa forme arrondie et sa texture en utilisant uniquement un plan sans relief.

==Environnement général et tuteurs==

===Lieu de travail principal===
*IRCICA, 50 Avenue du Halley à Villeneuve-d'Ascq

===Tuteurs du projet===
*Betty SEMAIL
*Frédéric GIRAUD
*Laurent GRISONI

==Choix techniques : matériel et logiciel==
*Logiciel principalement utilisé :
**''Matlab / Simulink''
*Matériel fourni :
**Maquette : interface plate-forme à 6 axes de liberté
**Raspberry
*Matériel à acheter :
**Aucun matériel nécessaire

==Calendrier prévisionnel==

====Calendrier====
*Présentation du contexte et du projet. Définition du cahier des charges.
**Prise de contact par mail le 29-11-2016 ;
**Rencontre le 13-12-2016 pour présentation du projet à l'IRCICA.

*Première séance à l'IRCICA : Mercredi 25 Janvier

===Feuille d'heures===
<br\>
(A noter que les heures écrites sont les heures travaillées par personne du binôme. Le quota horaire est à multiplier par 2 pour avoir le nombre d'heures total.)
<br\>
{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures supplémentaires !! Total par personne approximativement
|-
|
Rendez-vous présentation
|
1h
|
|
|
|
|
|
|
|
|
|
|
|1h
|-
|Définition cahier des charges
|
1h
|
|
|
|
|
|
|
|
|
|
|
|1h
|-
|Explications complémentaires
|
|
|1h
|
|
|
|
|
|
|
|
|
|1h
|-
|Lecture rapport de stage et thèse
|
|4h
|
|
|
|
|
|
|
|
|
|
|4h
|-
|Récupération, tri, lecture et tests anciens programmes
|
|
|5h
|4h
|4h
|1h
|
|
|
|
|
|
|14h
|-
|Modification programme pour tester rotations
|
|
|
|
|
|2h
|
|
|
|
|
|
|2h
|-
|Tester programmes
|
|
|
|
|
|1h
|1h
|
|
|
|
|
|2h
|-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|-
|Rédaction Wiki
|
|
|
|1h
|
|
|
|
|
|
|
|
|1h
|-
|Dont problèmes logiciels
|
|
|3h
|1h
|
|
|
|
|
|
|
|
|4h
|-
|DEUXIEME PARTIE DU PROJET : PARTIE MODELISATION
|-
|Découverte de l'ancien schéma de commande Simulink non commenté
|
|
|
|
|
|
|3h
|
|
|
|
|
|3h
|-
|Compréhension code et schéma de commande
|
|
|
|
|
|
|
|4h
|1h30
|
|
|
|5h30
|-
|Récupération ancien rapport pour aide à la compréhension
|
|
|
|
|
|
|
|
|2h30
|
|
|
|2h30
|-
|Recherches et bouquinage
|
|
|
|
|
|
|
|
|
|2h
|2h
|13h
|17h
|-
|Simulations / Tests Matlab
|
|
|
|
|
|
|
|
|
|2h
|2h
|7h
|11h
|-
|Préparation soutenance, récupération des fichier et fin rédaction rapport
|
|
|
|
|
|
|
|
|
|
|
|10h
|10h
|-
|TOTAL
|2h
|4h
|9h
|6h
|4h
|4h
|4h
|4h
|4h
|4h
|4h
|30h
|79h/pers
|}

==Avancement du Projet==

===Semaine 1===
<br\>
Séance du mercredi :
*Découverte du lieu de travail
*Lecture du rapport de stage de la personne ayant effectué les déplacements en translations sur le robot Hexapod (Valentin CATTIAU)
<br\>
Schéma du robot hexapod :
[[Fichier:schema_hexapod.png|1000px|center|thumb|Robot Hexapod]]
<br\>

===Semaine 2===
<br\>
Séance du lundi (3h):
*Découverte et premiers aperçus des programmes/code Simulink avec Michel AMBERG et Frédéric GIRAUD
*Impossibilité d'ouvrir les fichiers Simulink, problèmes de compilation avec Matlab :
**On a donc dû réinstaller Matlab, ce qui a pris beaucoup de temps.
<br\>
Séance du mercredi (4h):
*Michel AMBERG nous a montré comment compiler les différents programmes avec Matlab. Cependant, la compilation Matlab entraînait directement le lancement du programme sur le Raspberry PI 3B, donc nous devions effectuer la commande "kill" depuis le terminal dans le Raspberry.
*Nous avons ensuite effectué une copie du fichier "reset.sh" permettant d'initialiser les codeurs sur les positions fixées par l'utilisateur sur le robot Hexapod. Pour cela, nous plaçons des cales en plexiglas afin de permettre d'avoir un angle à peu près identique au niveau de chaque codeur. Ces positions étant nécessaires à l'utilisation des programmes réalisés par notre prédécesseur.
*Dans un second temps, nous avons débuté la répartition des anciens programmes dans des sous-dossiers afin de s'organiser au mieux. En même temps, nous avons compilé les programmes pour voir ceux qui peuvent encore fonctionner (certaines parties de programme sont communes sur plusieurs programmes, si elles ont été modifiées pour un programme plus récent, les anciennes versions ne fonctionnerons plus).
<br\>
Séance du jeudi (2h):
*Suite de la répartition du mercredi
*Création d'un tableau de suivi permettant de savoir à quoi correspondent chaque fichier et les GPIO du raspberry.
<br\>

===Semaines 3 et 4===
<br\>
*Durant ces séances, nous avons étudié le code réalisé par Valentin CATTIAU (code non commenté), afin de comprendre ce qu'il avait réalisé.
*A partir de cette recherche, nous avons pu déterminer quels étaient les programmes fonctionnels et ceux non utilisables. Cela nous a permis de poursuivre notre tableau de suivi démarré en semaine 2.
<br\>
*Afin de pouvoir libérer notre poste de travail (utilisé par une autre personne), nous avons dû changer de PC. Cependant, le package de Matlab Simulink pour travailler avec un Raspberry s'installait mais n'était pas utilisable. Cela nous a donc un peu ralenties dans la poursuite de notre travail d'étude du projet.
<br\>

===Semaine 5===
<br\>
*Dans un premier temps, nous avons terminé la phase de tri des fichiers non utilisés.
<br\>
*Modification code existant :
**Récupération du code fonctionnel "cercle.slx" :
***Initialement, les moteurs étaient contrôlés deux à deux en utilisant un unique capteur de position par groupe de deux moteurs (moteurs 1-2, 3-4 et 5-6).
***Notre modification consiste à récupérer les valeurs des six capteurs pour contrôler nos six moteurs indépendamment.
**Ce que nous avons réalisé :
<br\>
[[Fichier:cercle_avant_apres.png|1000px|center|thumb|Schémas Simulink avant et après modifications]]
<br\>
*Tests :
**Problème rencontré : suite au détachement des bras, qui étaient reliés deux à deux par un petit tube transparent , nous avons remarqué que les mouvements ne sont plus synchronisés. En effet, nous observions un léger décalage entre deux bras commandés à l'identique.
**Nous avons donc relancé l'exécutable initial afin de voir si le problème persistait, et en effet, ce problème existait déjà mais comme les deux bras étaient reliés, un moteur en entraînait un autre.
<br\>
Vidéo avec les bras liés deux à deux :
[[Media:video_translation.mp4|Lien vidéo]]
<br\>
<br\>
Vidéo avec les bras détachés :
[[Media:video_test_rotation.mp4|Lien vidéo]]
<br\>
<br\>
*Objectif prochaine séance : comprendre le phénomère, peut être consigne erronée (couple différents), ou dû à la succession envoi des données.
<br\>

===Semaine 6===
<br\>
*Changement d'objectif :
**Nous avons récupéré l'ancien schéma de simulation Simulink fait par Valentin CATTIAU afin d'ajouter nos objectifs, c'est à dire les rotations, ce qui nous permet donc de débuter la partie simulation.
**Début de modification du schéma afin d'y intégrer ces rotations.
<br\>
*Schéma de la commande donné dans le rapport de Valentin CATTIAU :
<br\>
[[Fichier:schema_commande.png|800px|center|thumb|Schémas Simulink avant et après modifications]]
<br\>
*Voici le schéma de simulation récupéré :
<br\>
[[Fichier:simulation_commande_haptique1.png|1200px|center|thumb|Schémas Simulink avant et après modifications]]
<br\>

===Semaine 7===
<br\>
(Poursuite de la semaine 6)
*A l'aide du rapport de stage du précédent étudiant et de nos cours de Robotique 1 avec monsieur MERZOUKI, nous avons essayé de comprendre ce qui avait été réalisé. Cependant, nous avons rencontré des difficultés concernant plusieurs points.
<br\>
*Avec nos recherches sur internet et dans le cours de Robotique 1, nous avons essayé de comprendre le travail réalisé. Nos difficultés ont été principalement l'étude de la dynamique et cinématique (directes et inverses). Les données entrées/sorties de chaque bloc ne correspondait pas à ce que nous aurions du effectivement avoir.
<br\>
*Objectif pour la prochaine séance : récupération du rapport de projet car la modélisation du robot avait été réalisée dans le cadre d'un projet de master 2 et non du stage, donc le rapport de stage était incomplet pour aider à la compréhension (code Matlab non commenté et rapport de stage faisant des rappels au rapport de projet, cependant nous n'avons pas le rapport de projet).
<br\>

===Semaine 8===
<br\>
(Poursuite de la semaine 7 + Réception du rapport de projet : [[Media:rapport_cattiau.pdf|Lien rapport Valentin CATTIAU]])
*Incohérence entre nos recherches et la réalisation de sa modélisation :
**Suite à la comparaison avec nos cours de Robotique 1 et nos recherches, nous avons enfin compris le pourquoi de notre incompréhension de sa modélisation :
***l'étude cinématique pour lui correspondait à l'étude géométrique pour nous ;
***l'étude dynamique pour lui correspondait à l'étude cinématique pour nous.
<br\>

===Semaines 9, 10 et au delà===
<br\>
*Etudes et recherches effectuées pour la réalisation de nos modèles cinématiques et géométriques.
<br\>
*Modification du schéma de simulation de la commande Matlab Simulink :
**[[Media:haptique_modele_complet.pdf|Lien pour la commande complète du système]]
**[[Media:haptique_robot.pdf|Lien pour le sous-système du robot Hexapod]]
**[[Media:haptique_controle.pdf|Lien pour le sous-système du contrôle de la commande du robot Hexapod]]
**[[Media:haptique_PID.pdf|Lien pour les PID du sous-système du contrôle de la commande du robot Hexapod]]
<br\>
*Code de génération de la jacobienne inverse avec récupération dans un fichier txt :
**Calcul de la jacobienne inverse : [[Media:jacobienne_inverse.pdf|Lien du fichier pdf]]
<br\>
*Modification des codes Matlab des blocs de cinématique et géométrique (Remarque : la jacobienne générée par Matlab étant importante, cela peut expliquer le nombre de lignes important dans les fichiers suivants) :
**Cinématique inverse : [[Media:cinematique_inverse.txt|Lien du fichier texte]]
**Cinématique directe : [[Media:cinematique_directe.txt|Lien du fichier texte]]
**Géométrique inverse : [[Media:geometrique_inverse.txt|Lien du fichier texte]]
**Géométrique directe : [[Media:geometrique_directe.txt|Lien du fichier texte]]
<br\>
*Malgré toutes les recherches effectuées et aides obtenues, nous n'avons pas pu trouver assez d'informations pour compléter notre modèle géométrique direct (temps insuffisant pour le travail à effectuer).
<br\>

== Fichiers Rendus ==