IMA4 2017/2018 P67 : Différence entre versions

De Wiki de Projets IMA
(Feuille d'heures)
(Feuille d'heures)
Ligne 274 : Ligne 274 :
 
| 7H
 
| 7H
 
| 2H30
 
| 2H30
| 2H
+
|
 
|  
 
|  
 
| 2H
 
| 2H
Ligne 384 : Ligne 384 :
 
| 3H
 
| 3H
 
|3H
 
|3H
|
+
|3H
 
|3H
 
|3H
 
|
 
|
Ligne 454 : Ligne 454 :
 
| 9H30
 
| 9H30
 
| 10H
 
| 10H
|
+
| 5H
 
| 6H
 
| 6H
 
|45H
 
|45H

Version du 16 mai 2018 à 01:01

Sommaire


Présentation générale

Objectifs

L'objectif de ce projet est de réaliser un scanner 3D permettant de modéliser un objet existant, en fichier .STL exploitable par une imprimante 3D. L'idée étant de laisser ce scanner à disposition des élèves, au Fabricarium de l'école.

Description

A l'heure actuelle, l'idée de duplication et de clonage d'objet est en pleine extension. En effet, les futuristes s'accordent à dire que l'imprimante 3D sera disponible dans les habitations au même titre qu'une imprimante classique papier, d'ici quelques années. Que ce soit pour de la vaisselle, des jouets ou encore de la décoration. Les logiciels de modélisations sont de plus en plus nombreux et de plus en plus accessibles aux non initiés ( par exemple le logiciel de modélisation fourni avec Windows 10). Toutefois, la conception et la modélisation d'objets complexes du quotidien, est parfois délicate et chronophage.

Tout comme une photocopieuse, l'idée du projet est de « photocopier » un objet. L'objectif principal sera de scanner l'objet et d'ensuite le sauvegarder en format STL sur une carte SD ou dans un dossier. Les logiciels qui permettent d'imprimer en 3D, comme CURA par exemple, ont plusieurs fonctions qui permettent des modifications (d'échelle notamment), à partir du fichier STL. Ainsi, l'utilisateur pourra modifier quelques paramètres de son objet avant de le dupliquer.

Pour ce faire, il existe deux méthodes (voire même trois). En effet, il existe le scan via technologie laser (capteur de distance), le scan via utilisation d'une caméra permettant de créer un nuage de points via un émetteur laser infrarouge et un récepteur infrarouge (type kinect), et enfin la photogrammétrie. Les deux premières techniques seront exploitées et nous essaierons de les mêler afin d'obtenir le meilleur scan possible en combinant les avantages des deux méthodes sans en avoir les inconvénients.

Une attention toute particulière sera apporté à la tenue à jour de l'avancement du projet. Effectivement, l'ensemble des membres du Fabricarium doit pouvoir connaître l'avancement exacte du projet, qu'il s'en intéresse de près ou de loin.

Ensuite, selon la complexité demandée et l'avancement du projet, il sera possible de l'améliorer avec différentes options. La première étant de corriger automatiquement le scan avant son rendu en fichier STL. En effet, si par exemple le support de l'objet est scanné, il faut en faire abstraction. Les trous, bien qu'en nombre limité, seront sûrement présents pour les objets complexes, il faudra alors les combler. Cette tâche peut être réalisée manuellement mais il convient qu'il serait plus agréable et pratique pour l'utilisateur, que le scanner s'en charge automatiquement. Ensuite, il pourrait être utile de lier directement le scanner et l'imprimante. Afin de ne pas avoir à transférer la carte SD d'une machine vers l'autre, encore une fois pour des raisons pratiques. Puis, il serait intéressant que le fichier scanné puisse également s'enregistrer dans un format modifiable par un logiciel de modélisation. Par exemple une tasse avec une anse cassée, pourrait être rapidement réparée (qu'on scanne ou non l'anse). Enfin, la version la plus aboutie du projet serait d'ajouter une interface graphique au scanner afin de pouvoir faire toutes les étapes précédentes facilement et de manière agréable.

Cette duplication rapide et accessible gratuitement permettra aux étudiants de l'école de dupliquer leur objets facilement.

Analyse du projet

Il existe déjà plusieurs techniques permettant de scanner des objets. Parmi elles, trois sont assez pratiquées mais contiennent toutes des inconvénients non négligeables.

Analyse du premier concurrent

FabScanPi
Result3d.jpg

La détection des contours de l'objet par un détecteur de distance laser est la technique la plus répendue pour les utilisateurs non professionnels. L'idée est d'utiliser un faisceau laser projeté sur l'objet de manière verticale. Ce faisceau est alors analysé par le capteur. L'avantage de ce système est que les points du faisceau laser ne se dilatent pas avec la distance. L'objet est ensuite mis en rotation sur l'axe verticale afin d'en faire le contour complet. L'ensemble de ces données de distance est alors enregistré sur une carte SD. Un logiciel permet ensuite d’exploiter toutes les sauvegardes en un fichier STL. Le scan est stable et correct.

Cependant, la précision du rendu laisse à désirer. En effet, ce type de scanner permet de contenter les utilisateurs ne cherchant pas un résultat professionnel mais est loin de convenir dans le cadre d'une reproduction fidèle. Un scanner de ce type est disponible en open source : le FabScanPI. De plus, ce type de scanner ne prend pas en compte la vison vue du « haut » de l'objet. Une tasse serait alors représentée comme étant un cylindre plein (pour le contenant) avec un disque encastré dedans (correspondant à l'anse).


Analyse du second concurrent

Kinect.jpg

Il existe ensuite la possibilité de scanner avec une caméra qui crée un nuage de points en 3D. Le principe est sensiblement le même que celui expliqué précédemment mais dans un environnement en 3 dimensions. La caméra envoie des ondes qui seront ensuite réfléchies sur l'environnement extérieurs et analysées par le capteur présent sur la caméra. Cette technique présente comme avantage de pouvoir ajouter la couleur au scanner grâce à la caméra (ce qui ne nous importe pas vraiment dans le cas d'une duplication d'objet, mais éventuellement dans celui d'une modification par logiciel de modélisation). Il est possible de déplacer la caméra et ainsi de scanner des objets plus grands (pièce à vivre, habitation, etc). Il est alors possible de survoler nos objets et d'en détecter les éventuelles complexités (comme la tasse évoquée juste avant) Cependant la présence de « bruits » comme les trous ou les mauvais scan, sont ainsi plus présents . De plus, la caméra scanne tout l’environnement de part sa puissance. Les murs de la pièces, le support etc... tout est scanné. Contrairement à la technique précédente, il ne suffit plus de « descendre » le fichier scanné à un axe en z=0 pour supprimer le support. En effet ici, le scan s'étant réalisé avec une mobilité de la caméra, l'objet scanné ne donne pas forcément un scan droit. Une retouche est alors nécessaire pour corriger les défauts du scan. Enfin ce type de scanner utilisant cette technologie est très onéreux.

Cependant, il existe une caméra peu chère que la communité s'est accaparé. La caméra qui nous intéresse est la kinect. Effectivement, cette caméra, originalement prévue pour l'utilisation avec la console de salon Xbox 360 de Microsoft, est désormais complètement « Reverse Engineered » et la communauté peut désormais utiliser la caméra pour des projets comme le notre. Son faible coup et son abondance sur les marché permettent un accès à une technologie précise, à moindre coup. Il est conseillé de la programmer en C#, mais ceci n'est pas indispensable. Des logiciels tels que Skanect ou Kinect-Fusion, totalement openSource, permettent de retoucher les scans faits avec la caméra de manière assez simple et de les rendre sous forme STL.


Analyse du troisième concurrent

Homme scanné via photogrammetrie
Femme.jpg

Enfin il existe aussi la technique de photogrammétrie. L'idée est de prendre une centaine de photos d'un objet avec un appareil photo puissant, comme un reflex. Ensuite un logiciel payant (environ 40 euros par mois) vous permet de « build » votre objet sous forme de fichier STL après plusieurs heures de traitement. Ce système est donc onéreux et chronophage. Il ne sera donc normalement pas exploité dans ce projet, cependant je tenais à l'évoquer car il constitue à l'heure actuelle, la façon la plus précise et la plus « simple » de scanner un objet. Le coté pécuniaire étant son seul très gros inconvénient.

Il faut noter que toutes ces méthodes ont une limite commune : le transparent ! Un verre de lunettes ne permettra pas pas un scan précis, de par le phénomène de réflexion. Il faut alors peindre l'objet avec de la peinture temporelle pour pouvoir le scanner. Ce qui n'est pas pratique.


Positionnement par rapport à l'existant

L'idée va ainsi être de tester les techniques évoquées précédemment et essayer de les combiner afin d'obtenir un système qui combine les avantages des systèmes sans en avoir les inconvénients. Afin d'en faciliter l'utilisation par un étudiant Lambda.

Le but de mon projet de Scanner 3D est d'être accessible facilement et gratuitement, par tous, via le fabricarium de l'école. La tenue à jour de l'avancement du projet est essentielle dans l'élaboration du scanner. Le wiki servira de point d'avancement pour toutes les personnes voulant s'intéresser de près ou de loin au projet. Afin de limiter les coûts et de conserver le maximum de qualité du scan, je vais utiliser la caméra kinect. Cette dernière sera mise en rotation à 360 degrés, via un système de moteurs, autour d'un objet à scanner en position fixe. Cette caméra montera le long d'un bras incurvé en forme d'arc de cercle. Une fois arrivée en haut elle aura scan l’intégralité de la pièce sous tous les points de vue d'une demi sphère (l'hémisphère sud n'étant pas exploitable à cause du support). Ensuite je tenterai de modifier un logiciel existant via api ou documentation, pour qu'il fasse exactement ce que je veux, afin de paramétrer au mieux le build et d'optimiser le rendu du fichier STL. Ce système stable limitera le bruit d'un mouvement de caméra (avantage du concurrent 1) avec la qualité de scan du concurrent 2.

Enfin, le projet sera suivi par l'équipe des FabManagers que je formerai une fois le scanner réalisé (et tout au long de son élaboration). Je mettrai aussi une documentation papier et informatique pour quiconque souhaitant en apprendre plus sur le système et/ou l'améliorer par la suite.

Ce scanner 3D serait donc un projet d'un étudiant fait pour les étudiants afin de leur permettre de dupliquer leur objets, dans quelque but que ce soit.

Scénario d'usage du produit ou du concept envisagé

Imaginons Bill, un étudiant en MECA3, tout récemment arrivé à Polytech en début d'année. Il a peu de revenus et souhaite limiter au maximum ses dépenses mensuelles.

Pourtant, un soir, un peu trop énervé après un examen de thermodynamique il ouvre son réfrigérateur un peu trop violemment et casse la poignée en deux. Impossible pour lui de la réparer car elle est fendue en deux et le point de colle qu'il a mis ne suffit pas. Une poignée de frigo ça ne se trouve pas si facilement ! Puis c'est un vieux qu'il avait récupéré dans sa famille. Impossible de retrouver une poignée neuve. Devrait-il renoncer à ouvrir son garde manger réfrigérant ? Non !

Comme tous les étudiants de Polytech Lille, il a accès au Fabricarium de l'école. Après avoir pris connaissance de l'existence d'un scanner 3D à l'école, il décide de se renseigner sur son utilisation via la documentation mise à disposition des élèves. Comme toutes machines du Fabricarium, il se fait formé à son utilisation par un des membres du Fabricarium.

Il place donc sa poignée, rafistolée vulgairement avec un point de colle, dans le scanner. Quelques minutes plus tard, il dispose d'un fichier STL, de la forme de sa poignée de réfrigérateur. Il lance donc l'impression du fichier sur l'imprimante 3D du FAB. Le soir même, Bill peut de nouveau utiliser son réfrigérateur comme au premier jour.

Il se dit que cet outil est vraiment utile et qu'il serait utile d'en profiter ! Il duplique alors sa coque de téléphone . Il met ce fichier STL sur un drive. On ne sait jamais ! Peut être qu'un jour il oubliera sa coque de téléphone chez ses parents, et il sera bien heureux de pouvoir en réimprimer une identique le moment voulu, lorsque son pauvre portable sera nu, sans défense. En plus les imprimantes 3D se démocratise de plus en plus. Il y en a dans les bureaux de postes, dans les magasins de type LeroyMerlin, chez des particuliers, etc... ça ne devrait pas être trop difficile de trouver un endroit ou imprimer ce dont il a besoin.

Ensuite, dans l'année, après avoir découpé une pièce de bois, il l'a travaillée avec minutie afin d'en faire un axe complexe, contenant une roue demi crantée. La pièce est parfaite pour son projet en cours de dynamique du solide. Il utilise alors le scanner pour faire une sauvegarde de cet axe avant de le retravailler et éventuellement le modifier de façon irréversible.

Et c'est ainsi que Bill a également pu se faire un deuxième porte manteau mural, lui qui en avait qu'un seul, pour son manteau d'hiver . Ou encore, en utilisant la même méthode, il a pu dupliquer sa petite figurine Pikachu qu'il avait étant enfant.

En ouverture, on peut supposer que ce système de scanner devienne de plus en plus développé. Au point d'être utilisé par les entreprises. Imaginez qu'une pièce du meuble de Bill casse ! Alors IKEA qui possède une base de donnée de fichiers scannés de ses meubles, lui envoie le fichier STL à imprimer, pour son pied d'étagère Shtomël ! Ce scanner à donc permis de faciliter la vie des étudiants de Polytech Lille. Comme ce fut le cas pour Bill, le scanner a permis de dupliquer des objets et d'en faire des copies sous forme de fichier STL, que ce soit dans un but ludique, utile, ou dans le cadre d'un projet d'étude.

Réponse à la question difficile

Les deux questions qui me durent posées lors de la première présentation étaient : "Jusqu'à quelle taille d'objet pouvons nous scanner ?" ainsi que "Combien de temps durera un scan ?"

Selon les différentes dispositions auxquelles j'ai pensé lors de l'élaboration d'un "prototype" sur papier, la taille de l'objet à scanner devrait être au maximum d'environ 30 cm cube et de minimum 3 cm cube pour avoir un scan précis. Pour ce qui est du temps du scan (hors temps d'impression du fichier STL), il devrait être de moins d'environ 5 minutes pour être considéré comme efficace.

Préparation du projet

Le projet sera amené à évoluer dans le temps, en fonction des réussites, des échecs et de ce que le Fabricarium souhaite ou non.


Cahier des charges

Le scanner devra être le plus simple possible d'utilisation ! Il devra permettre dans un premier temps, de remplir l'objectif principal : permettre de pouvoir réimprimer une pièce en 3D, le plus fidèlement possible par rapport à la pièce d'origine. Peu importe la technique utilisée. La suite de ce projet consistera à améliorer ces différents scans et optimiser la duplication des objets pour le rendre accessible au non initiés. L'objet scanné devra avoir une taille raisonnable pour permettre un scan optimal (ni trop petit, ni avec de trop grandes dimensions). Le scanner doit être "autonome" et une fois lancé, l'utilisateur n'a pas à intervenir sur le scanner (à part pour récupérer le fichier .STL sur la carte SD à la fin du scan.


De plus, j'ai décider d'utiliser le plus de matériel déjà à disposition. L'idée étant d'utiliser les ressources disponibles au Fabricarium, à l'école (à disposition des IMAs) ou encore disponible dans ma réserve de matériel personnelle. Cela me permet alors de limiter les dépenses, afin de réaliser le projet le moins coûteux possible pour l'école. En effet, il va s'en dire que si les frais de mon projet étaient trop grands, il serait plus intéressant pour le Fabricarium d'investir dans un scanner à plusieurs centaines d'euros chez un professionnel.

Choix techniques : matériel et logiciel

Je vais utiliser dans un premier temps le scanner avec capteur de distance laser afin d'en tester les limites et d'en tirer les avantages. Ensuite j'utiliserai la méthode du scan via la caméra kinect afin de saisir les fondamentaux de la procédure à suivre (tolérance aux vibrations, création de trous,...) pour obtenir un scan optimal. J'essayerai alors de combiner les deux techniques afin de faire une sorte de scanner hybride, possédant les avantages des deux techniques, sans en avoir les inconvénients.

Liste des tâches à effectuer

Les différentes tâches à effectuer :

étape 1 :Élaborer un scanner avec le capteur de distance et l'analyser en profondeur afin de s'en inspirer un maximum pour en tirer les avantages de cette méthode de scan.

étape 2 : Faire un scan avec la caméra kinect afin d'en tirer les enseignements d'un scan avec caméra

étape 3 : Faire des nombreux points avec l'équipe du Fabricarium pour répondre à leurs attentes et faire quelque chose qui correspond le mieux à leurs besoins.

étape 4 : Conception d'un modèle hybride permettant un scan de meilleur qualité que les deux méthodes précédentes et de manière plus facile.

étape 5 : Améliorations de ce dernier système réaliser afin d'en faire un scanner le plus abouti possible.

Calendrier prévisionnel

Le projet étant à rendre au moi de mai, mais comptant une marge d'erreurs et d'améliorations éventuelles, le calendrier prévisionnel optimal serait donc :

Fin de l'étape 1 : Début février,la première technique de scan, par capteur de distance laser, a été testée, exploitée et étudiée.

Fin de l'étape 2 : Fin Février, la seconde technique de scan, via caméra kinect, a été testée, exploitée et étudiée.

Fin de l'étape 3 : Mi mars, les réunions avec le fabricarium ont abouti sur un modèle final à confectionner.

Fin de l'étape 4 : Fin Avril, le scanner final est réalisé et opérationnel.

Fin de l'étape 5 : Le temps restant sera consacré à l'amélioration de ce dernier modèle, et à l'analyse du projet (erreurs commises, décisions judicieuses ou non). Je consacrerai également un temps de formation pour les membres de Fabricarium, afin qu'ils puissent eux même former les étudiants par la suite, pour pouvoir utiliser ce scanner. Si le projet n'est pas totalement terminé ou encore améliorable, ces mêmes membres pourront poursuivre le projet afin d'atteindre l'objectif principal : donner accès à un scanner 3D aux étudiants de l'école.

Réalisation du Projet

Feuille d'heures

Étant présent à chacune des séances facultatives de 2h du lundi, et responsable de la salle E306le jeudi de 8h à 10h, en plus des séances obligatoires de 4h le mercredi après midi, mon temps de travail consacré à ce projet est de minimum 8h par semaine à l'école (sauf cas exceptionnel). S'ajoute à ces heures, les heures personnelles faites chez moi le week end et lors de la semaine (trou dans l'emploi du temps et/ou séance prolongée). En effet, il faut que je compense le fait d'être seul pour avoir une avancée similaire aux autres groupes en binôme.


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 S11 Heures S12 Heures S13 Heures vacances + S14 + S15 Total
Analyse du projet / recherche 15H 2H 2H 1H 1H (étude datasheet TB6560)
Récupération du matériel 1H 1H (au frabricarium) 2H30
Mise en place de l'alimentation / soudure 2H 2H 1H 1H30 0H30
Code et mise en rotation optimisée des moteurs 3H 3H 4H 1H30 1H 2H30 (à cause de la panne du TB6560) 1H
rédaction du wiki 4H 3H 2H30 3H 1H 4H 2H 3H (rédaction et correction) 5H (rattrapage des semaines de retard) 4H
conception et réalisation de pièce (découpe laser / Imprimante 3D / Shopbot) 3H30 2H 5H 7H 2H30 2H 3H Shopbot
Installation des drivers, découverte et paramétrage de SKANECT 1H30 2H
Test de scan avec la kinect 2H 2H 3H 3H(tests finaux)
Formation Fabricarium 1H30 Imprimante 3D 1H30 ShopBot (2nd lieu)
assemblage des pièces / collage du bois 2H 2H 2H
test capteur de mesure de distance 2H
imagination conception et croquis de la structure finale 3H 3H 3H 3H
eagle 2H
construction et assemblage de la structure finale 30H
rédaction rapport 7H
total 19H 11H 8H30 10H30 8H30 11H 8H30 8H 10H 7H 9H30 10H 5H 6H 45H

Prologue : Partons sur de bonnes bases

Avant d'entamer officiellement le projet, avec des créneaux horaires prévus à cet effet, un travail en amont à dû être réalisé.


En effet, premièrement, un long travail de recherche a été fait. Il fallait que je puisse voir les technologies existantes. De plus je devais m'assurer que le fait de réaliser "une photocopieuse d'objet" était faisable !

Parallèlement, je me suis rapproché de Rodolphe Astori afin de soumettre mon projet et de demander si celui ci intéresserait éventuellement le Fabricarium. L'idée lui plu aussitôt !

Après avoir étudier longuement les différentes technologies existantes, ainsi que leur défauts,j'ai décidé de proposer l'idée de proposer mon projet aux professeurs responsables.

Une fois le sujet approuvé par ces derniers, je pouvais alors me rapprocher des membres du fabricarium pour leur exposer le projet oralement, et commencer à réunir les personnes suscitant un plus ou moins grand intérêt pour le scanner. Cela me permit alors de fixer un premier cahier des charges.

Une fois ceci fait, j'ai alors continuer longuement mes recherches et ai opté pour différents composants, sélectionnés selon leur qualité, leur prix, et les avis des internautes, les suggestions des professeurs et de certains IMA les ayant testés.


J'ai donc dès le début du mois d'octobre, commencé à élaborer différents prototypes sur papier et exploré différentes options pour réaliser le scanner.

De plus la présentation devant une partie de la classe et un professeur référent, m'a permis de confirmer certains choix et également de voir différentes options à étudier, auxquelles je n'avais pas pensé !

Puis, un temps fut également consacré à la recherche de matériel nécessaire. La plupart du matériel étant déjà disponible à l'école, chez moi, ou à faible coût sur internet, j'ai décidé de commander une petite partie du matériel afin de pouvoir manipuler certains éléments qui m'étaient jusqu'alors inconnus. Finalement les délais de livraison étant très longs, je me suis retrouvé avec des livraisons en "compte goutte", sans vraiment pouvoir tester grand chose. Ce n'est pas très dérangeant étant donné que cette partie de "test" était "facultative", le projet ne commençant officiellement qu'au second semestre.

Enfin, la rédaction du wiki fut également un peu chronophage mais nécessaire. Surtout que ce wiki est également le seul moyen simple que chacun (professeurs et membres du fabricarium notamment) puisse connaître l'avancement du projet ainsi que les lignes directrices du travail effectué.

Semaine 1 : Alimentations, soudures et test du matériel

Cette semaine, le projet fut officiellement lancé ! Comme le conseillé le sujet du projet, je devait tester les deux types de scans possibles (par capteurs de mesure de distance et par kinect). J'ai alors décidé de commencer par la première méthode.

Certaines concertations avec les professeur furent nécessaires pour voir différentes options à choisir concernant le matériel qui était à disposition.

Par exemple, afin d'éviter les coûts liés à l'achat d'une alimentation 12 V continu', j'ai repris une alimentation de PC utilisée pour un ancien PFE et prenant la poussière depuis quelques temps.


Les premières heures furent donc consacrées aux désossements de certaines pièces d'anciens projets ainsi qu'au fait de rassembler les différents pièces nécessaires déjà à disposition.

Suite à quoi je décidai de commencer par la partie alimentation. En effet, pensant avoir une alimentation sur secteur classique, je n'avais pas prévu de me retrouver avec une alimentation de PC. Cependant, cette modification est un avantage car elle me permettra d'alimenter l'ensemble de mes composants. Mais surtout, le poids assez important de l'alimentation servira de contrepoids éventuel pour la caméra Kinect.

Effectivement, je ne connais pas encore la forme finale de mon scanner mais il est probable qu'un bras tourne autour de l'objet à dupliqué. Auquel cas il sera nécessaire de compenser le poids de la caméra lorsque celle si sera éloigné de l’objet, et donc lorsqu'elle créera un déséquilibre évident de l'ensemble. Ce contrepoids créer par l'alimentation permettra ainsi d'éviter de devoir scellé le scanner sur une grande plaque.

J'ai d'abord dû me renseigner sur comment fournir du 12 Volt (nécessaire au pilotage des moteurs) avec l'alimentation mise à ma disposition. Après quelques recherches, j'ai donc bouclé l'alimentation sur la terre, pour la court-circuiter. Après quoi je pouvais normalement disposer de 5V (fil rouge) et de 12V (fil jaune de l'alimentation). Cependant l'alimentation ne démarrait pas.

Mot2.jpg
Cont.jpg

J'ai donc décidé de dénuder de nouveaux câbles et de souder de nouveau les extrémités afin de les rendre de nouveaux exploitables. En effet le problème venait de là et une fois les nouveaux câbles mis en place, l'alimentation démarrait normalement. Les anciens câbles devaient très certainement avoir un peu mal vieilli depuis le temps. J'en ai alors profité pour découper quelques câbles d'avance, anticipant le fait de devoir alimenter l’Arduino et sûrement d'autres composants par la suite. L'alimentation marche (photo avec le voltmètre à l'appui), il faut alors que je procède aux soudures de mes différents composants pour pouvoir les tester !

L'étape fut donc un peu minutieuse sachant que je devait souder les pins sur mes deux contrôleurs moteurs, sur mon Arduino pro micro reçu récemment et sur les mes moteurs pour pouvoir les connecter facilement à une Breadboard/planche à pain.

125.jpg

Une fois ceci réalisé, j'ai donc upload un code simpliste de rotation de moteur sur l’Arduino UNO dont je disposais afin de vérifier la bonne transmission de l'information des moteurs et de contrôler mes soudures par la même occasion. J'ai alors réalisé le montage correspondant pour procéder aux tests. Bien entendu, cela n'a pas marché du premier coup, j'avais une soudure un peu grossière que j'ai eu à retoucher rapidement. Le deuxième essai fut le bon ! J'ai donc pu vérifier que mes deux moteurs ainsi que les deux contrôleurs moteurs fonctionnaient correctement. C'était le cas !

J'avais donc à la fin de ma deuxième séance une alimentation qui fonctionnait correctement; des moteurs et un circuits permettant une mise en rotation efficace d'un moteur. Il me suffit alors de reproduire un second montage identique et de modifier légèrement le code pour contrôler deux moteurs. L’idée étant d'utiliser un moteur pour mettre en rotation l'objet et un autre pour permettre l'élévation du capteur de mesure de distance le long de l'objet à scanner.


J'ai alors essayé de remplacer mes moteurs NEMA 17 par ceux du projet de Jean Wasilewski. Les moteurs étaient censés faire la même chose, car de modèle identiques. Cependant, ce deuxième type de moteur ne réagissait pas de la même façon et faisait des sorte de "sursaut". Je n'ai pas eu le temps de déterminer l'origine du problème. Plus tard je reviendrai sur ce problème. Sachant que les moteurs fonctionnaient avec un autre contrôleur moteur sur le projet de Jean, je reprendrai donc ces mêmes contrôleurs si j'ai besoin d'utiliser ces moteurs. Le problème vient peut être aussi du code. Je décide de poursuivre sur une autre partie du projet. En effet, même si les deux moteurs de J.W. ne fonctionnaient pas, les deux miens marchaient correctement et pour le moment je n'en n'avais besoin que de deux. Je prendrai donc le temps de venir régler ce problème (sûrement très simple à résoudre) lorsque j'aurai besoin de plus de moteurs, sûrement dans la suite du projet.

Pour conclure la première séance de 4H, je suis parti acheté du bois à Leroy Merlin (avec de l'argent prêté par Monsieur Redon), découpé aux dimensions de la découpeuse laser du Fabricarium, afin de refaire le stock disponible pour les IMA cette année.

J'ai ensuite, dans la semaine, utilisé un peu de mon temps libre lors des pauses pour aller demander quelques conseils à Rodolphe Astori (notamment son point de vue sur la réalisation d'un prototype en bois, face à celui en aluminium). Il m'a alors conseillé de commencer sur un système en bois pour prototyper le tout, et si les résultats sont satisfaisants, nous pourrons passer sur un modèle plus rigide en aluminium, éventuellement découpé chez un de leur partenaire, le TechShop.


adaptateur soudé pour permettre l'alimentation de l'Arduino grâce à l'alimentation du PC

Le week end, j'ai repris la caisse de matériel pour mon projet (avec l'accord de Monsieur Redon) pour pouvoir continuer le projet chez moi. J'ai alors pu dénuder et souder d'autre câbles, ainsi qu'un adaptateur Arduino. Cela me permet ainsi d'alimenter mon Arduino directement avec l'alimentation du PC mise à disposition. Elle est là, autant l'exploiter au maximum !

N'ayant pas encore le capteur de mesure de distance (seule pièce réellement indispensable à commander), il faudra donc que je commence d'autres tâches avant de tester ce composant. Les différentes tâches à réaliser sont explicitées ci après, dans les objectifs pour les semaines suivantes.

Fin de la semaine 1, fonctionnement des moteurs

L'objectif pour les prochaines semaines est de finir le premier type de scanner pour respecter le calendrier prévisionnel. Il faut donc faire fonctionner les moteurs issus du projet de Jean Wasilewski ainsi qu'entamer une première modélisation 3D des pièces nécessaires pour la réalisation du premier scanner à mesure de distance laser. Suite à ça je devrais faire la carte électronique de l'ensemble. Il faudra également que j'organise une réunion avec certains membres du Fabricarium intéressés par le projet, pour leur présenter l'avancement de ce dernier. Une fois ceci réalisé, je pourrais passé aux second type de scanner et il faudra que je tente un scanner avec la kinect. Et commencer à proposer des schémas prototypes pour la réalisation de mon scanner final, à Rodolphe et aux membres du Fabricarium.


Semaine 2 : rassemblement du matériel, les idées prennent forme

Cette semaine fut un peu moins une réussite que la précédente malheureusement. Bien que j'ai continué à travailler sur le sujet lors des deux séances "facultatives" du lundi et jeudi et celle du mercredi, je me suis retrouvé confronté à certains problèmes. En effet, premièrement, j'ai souhaité upload mon code (qui fonctionnait parfaitement sur une arduino uno), sur une arduino pro micro. Malheureusement cela ne marchait pas. Après plusieurs heures à comprendre le problème, à réupload, déconnecter-reconnecter, etc... Il s'est avéré qu'une mauvaise soudure couplée à un faux contact entre la pro micro et le câble USB (câble défectueux) étaient à l'origine du dysfonctionnement (Je ne m'en apercevrais qu'après plusieurs heures de frustration).

partie mécanique "élévatrice du capteur"
partie mécanique "rotation du plateau"

Je n'ai pas non plus réussi à faire fonctionner les moteur de Jean Wasilewski. Je pense que ceci était dû à de mauvaise valeur de capacité. Je reviendrais sur le problème plus tard car je n'ai pas besoin de faire tourner plus de deux moteurs pour le moment.


L'idée du scanner est de faire s'élever un capteur de mesure de distance qui enregistrera des données sur une carte SD. L’élévation peut se faire avec courroie ou avec le rotation d'une vis d’Archimède. Je verrai selon les avantages et les inconvénients de chacune des deux méthodes, celle que je décide d'utiliser. Le capteur de mesure de distance n'étant pas encore arrivé, je décide alors de me lancer dans la recherche de nouveaux éléments de matériel pour confectionner la structure de mon scanner.

J'ai ainsi pu beaucoup avancer sur la recherche et la récupération de matériel. Cela m'a permis d'éclaircir certains points sombres et de résoudre certains problèmes. Le Fabricarium est une véritable mine d'or lorsqu’on cherche une pièce de récupération ! J'ai donc pris plusieurs composants (non électronique) que je n'avais pas prévu d'utiliser à la base mais qui sans doute faciliteront tôt ou tard mon projet (roulements à billes, barre de métal, coupleurs etc...). Il me manquait également un coupleur permettant de faire la jonction entre un moteur (axe de 5 mm) et l'axe de type hélicoïdale (vis d’Archimède)( 8 mm). Finalement j'ai dû attendre le week end pour en récupérer un chez mes parents, ceux du fabricarium n'étant pas au bon diamètre.

J'avais ainsi lors de cette semaine peu avancé d'un point de vue physique et visible. Mais j'avais cependant rassembler différents éléments qui m’éviteront d'être freiné plus tard.

L'apparence du scanner prend peu à peu forme. L'idée sera de mettre en rotation un objet sur un plateau situé au dessus d'un premier moteur nema 17. Le capteur de mesure de distance enregistrera les informations sur une carte SD (il faudra voir comment cela est possible (via Raspberry ou l’Arduino sera peut être suffisante). Une autre partie du scanner permettra de faire s’élever le capteur de mesure de distance petit a petit de sorte à scanner l'objet de sa base à son sommet. Il me reste à déterminer la méthode d’élévation qui a le plus d'avantages. Le test devra être fait une fois que le capteur de mesure de distance sera reçu.

De plus j'ai pu récupérer vendredi soir, des capacités avec des valeurs correspondantes à celles dont j'avais besoin pour faire tourner les moteurs de l'ancien projet de 5A (à savoir 47 µF).

Enfin, après avoir un peu échangé avec Ropdolphe du Fabricarium, ce dernier m'a conseillé d'utiliser le logiciel "onshape", qui est un logiciel de CAO en ligne qui permet, tout comme un drive, de partager ses fichiers de modélisations et de pouvoir les modifier. Cela permettra l'échange et l'éventuelle amélioration des pièces que j'aurai commencé à créer, avant de les imprimer.

Pour la semaine prochaine il faudrait que je fasse tourner mes moteurs ensemble, que j'implémente le code sur mon arduino pro micro et de me décider sur le fait que je fasse monter le capteur de mesure de distance via une courroie ou alors via un axe en forme de vis d’Archimède permettant l'ascension du capteur.


Semaine 3 : une belle avancée mais également quelques erreurs

C'est reparti ! Les choses vont de nouveau mieux ! Bien que je n'ai pas encore reçu le capteur de mesure de distance, j'ai tout de même réussi à régler pas mal des problèmes de la semaine dernière !

La soudure défectueuse de l’Arduino pro Micro a était détectée et réparée ! De plus le petit problème de connexion dû au câble USB défectueux fut détecté également assez rapidement. En effet après avoir exploré toutes les différentes sources éventuelles de problème, le problème ne pouvait venir que d'une erreur "bête" mais ce sont souvent les plus dures à détecter !

En plus de cela, un problème de bread Board est venu également jouer un peu avec mes nerfs. En effet, il s’avérait que la masse commune n'était pas commune sur toute la planche à essai, mais uniquement sur une moitié ! J'ai perdu un peu de temps sur ce léger problème, simpliste, mais face auquel je n'avais encore jamais était confronté jusqu'alors. Je savais, de par mes tests de la première semaine que le problème ne pouvait pas venir de mes contrôleurs moteurs ni de mon code ! Je pu donc trouver la source du souci rapidement et procéder à la suite !

Cod.jpg

Effectivement, tout ceci étant réglé, je me lance sur le montage global  ! Je me munis alors de la BreadBoard, de l’Arduino pro Micro et des deux contrôleurs moteurs ! j'y ajoute les deux moteurs Nema 17 et je les associe à leur partie respective. Le premier est attaché à un axe type vis d’Archimède, qui permettra de faire s'élever le capteur de mesure de distance, via le coupleur que j'ai pu récupérer chez moi le week end. Il est un peu trop "souple" mais je compenserai cette flexibilité via l'ajout de tuteurs en métal, trouvés au FAB et de toute manière essentiel pour éviter que le capteur ne "tourne" en même temps que l'axe sur lequel il est fixé. Le second moteur Nema sera quand à lui relié à un plateau tournant. La logique de solidité et de facilité de fixation voudrait que je modélise et imprime un plateau avec un axe de 8mm pour fixer à un des coupleurs dont je dispose. Cependant l'état du scanner étant encore au rang de prototype, je décide de gagner un peu de temps en découpant un simple disque à la découpeuse laser, que j'ai ensuite fixé à un coupleur via de la colle. Le montage est un peu grossier mais me permettra de faire mes premiers tests. Je referai alors la pièce en version finale à l'impression 3D un peu plus tard. Le but étant d'avancer le plus loin possible, de sorte de pouvoir procéder ensuite le plus rapidement aux tests de scans avec la caméra kinect (deuxième type de scanner à explorer dans mon sujet de projet). Je découpe alors ce disque à la découpeuse laser du Fabricarium (j'avais anticipé le fait de devoir l'utiliser pour le projet, j'ai donc ainsi suivi la formation obligatoire du Fabricarium sur cette machine lors du premier semestre). Le résultat, suite au collage, n'est pas transcendant mais fera amplement l'affaire pour faire les premiers tests.


J'ai donc ensuite upload un code simpliste sur une Arduino UNO et le même sur une Arduino pro micro afin de vérifier le fonctionnement des deux micro contrôleurs (surtout pour contrôler une fois de plus les soudures faites par mes soins sur la Micro). Le code est simple mais permet de comprendre le contrôle des moteurs qui n'est pas forcément si évident aux premiers abords. Voici le code qui a était mis sur les deux Arduino. Ce code sera bien entendu modifié par la suite, et adapté à la situation, une fois la partie mécanique terminée et assemblée.

Montage global avec plateau découpé au laser

A noter que malheureusement, quelques heures plus tard la découpeuse laser tombera en panne (hors service suite à un problème de filtre). Je ne sais pas pour combien de temps la machine sera inaccessible, mais je serai sûrement obligé de procéder exclusivement à une création de pièces via imprimante 3D par la suite si le problème persiste. Cela risque de me ralentir dans les jours et semaines à venir. En effet, la découpe laser étant beaucoup plus rapide qu'une conception et une impression chronophage de pièces sur une imprimante.


Ainsi après quelques petits réglages j'ai donc un montage global fonctionnel où mon alimentation de PC permet de rendre "autonome" une Arduino UNO ou MEGA (non utilisée pour le moment mais sûrement utile par la suite), ainsi que de fournir le courant et la tension nécessaires pour alimenter mon Arduino pro micro, et les deux moteurs Nema 17.

Comme on peut le voir sur le montage général présent dans la vidéo ci jointe, le montage fonctionne parfaitement ! Le plateau avec l'objet tournant permet de mettre en rotation un objet sans avoir besoin d'un couple trop important. Le tout n'est cependant pas très stable. Ceci est dû à la fixation et aux matériaux un peu rudimentaires utilisés. Comme déjà précisé précédemment, cette partie sera ensuite normalement améliorée via la création d'une pièce en 3D.


Un problème est survenu, sans gravité pour le moment mais à surveiller. En effet les contrôleurs moteurs chauffent de manière anormale. Pas d'odeur de brûlé ni de fumée apparente mais il semblerait que cela chauffe trop malgré tout. A surveiller. Afin de compenser cette augmentation de chaleur, j'ai donc récupérer un dissipateur (et un ventilateur de petite taille facultatif pour la suite éventuellement) afin de refroidir les deux pièces. La taille n'est pas tout à fait adaptée mais elle fera l'affaire. Effectivement le dissipateur est un peu gros mais je peux le mettre sur les deux contrôleurs moteurs en même temps si cela est possible (il faudra prendre ceci en compte lors du routage de la carte électronique (selon la disposition, la carte électronique devra être adaptée)).

Fonctionnement de l'ensemble


Fin de semaine : prise de conscience de l'erreur, heureusement sans gravité ni dégât matériel

J'ai compris mon erreur, cause du fonctionnement anormal, origine de l'échauffement... En effet, mes moteurs ont besoin de 2A pour fonctionner et mes contrôleurs moteurs ont un fonctionnement conseillé jusque 0.725 Ampère... Je pensais gagner du temps et éviter un coût en utilisant mes contrôleurs moteurs personnels, mais ceux ci n'étaient pas tout à fait adaptés. Après avoir vu avec Mr Boé, il faut que l'on change de contrôleurs moteurs. Je vais donc me tourner vers les contrôleurs moteurs de l'ancien PFE. Il faut donc absolument que je fasse fonctionner correctement les moteurs de Jean Wasilewski. Auquel cas nous serons obligé de rajouter des contrôleurs moteurs à la liste de matériel nécessaire au projet. Je vais donc me focaliser sur le fonctionnement de ces moteurs qui utilisent un pont en H pour fonctionner. Le fonctionnement est différent mais n'a pas l'air plus difficile.

Je vais donc rapidement (ce week end si possible) me focaliser là dessus, pour essayer de régler ce problème afin d'éviter d'avoir à engendrer de nouveaux achats de composants et ainsi devoir attendre les délais de livraison. Le problème n'est pas dramatique mais aurait pu être évité, je suis totalement responsable de cette erreur et j'aurais dû prêter davantage attention à la datasheet de mes contrôleurs moteurs. Je m’étais basé sur plusieurs sources d'internet faisant fonctionner les moteurs Nema 17 avec les mêmes contrôleurs moteurs sans prêter attention au fait que ceux ci pouvaient ne pas être totalement adaptés. La priorité est donc désormais de refaire remarcher le tout avec mes nouveaux composants.

Ensuite, plus tard, les différentes étapes qui sont la suite logique de l'avancement du projet (et donc a travaillé les semaines suivantes) sont donc de penser à commencer la carte électronique (bien que d'autres éléments vont venir s'y ajouter) mais le fait d'avoir une idée de ses dimensions me permettra de savoir où et comment la placer sur le montage final. De plus il faudrait que je commence à modéliser et imprimer certaines pièces pour faire la partie mécanique du projet. Je pense me tourner vers l'impression 3D car je ne sais pas pendant combien de temps la découpeuse laser va être hors service). Si tout se passe bien, cette partie sera terminée à la réception du capteur de mesure de distance, et je pourrais ainsi procéder au différents tests dès que le capteur sera arrivé.


Semaine 4 : optimisation de rotation des moteurs, premier scan avec la kinect et modélisations 3D : Avancée dans de nombreux points !

Cette semaine, j'ai travaillé durant les nombreuses heures de trous que nous avions, et également chez moi les soirs de la semaine et le week end, ainsi, j'ai pu avancer largement cette semaine ! En voici un détail :

le TB6560 à "réparer"

De façon à ne plus reproduire la même erreur, j'ai donc réétudié mes datasheets dans le détail. Résultat : j'ai donc deux types de moteurs NEMA 17 like. Un type à 12V et 0.7 Ampère et un a 12V et 1.7A. De plus j'ai deux types de contrôleurs, un ayant une possibilité de fonctionnement de 475 à 875 milliampère, ainsi que ceux de l'ancien PFE que je n'arrive pas à faire fonctionner pour une raison toujours inconnue. Ou plutôt si, j'arrive à les faire fonctionner mais pas avec une rotation fluide. En effet, je constate des soubresauts qui sont dus à un mauvais réglage du potentiomètre pour le courant de phase. Je vais donc continuer avec les moteurs de 0.7A et avec les contrôleurs moteurs de 0.475 à 0.875A. Ceux ci fonctionnent très bien ensemble et je pourrais revenir sur le problème si j'ai besoin de plus de moteurs ou de changer la méthode de contrôle des moteurs.


Plus tard dans la semaine, Alexandre Boé me donnera un contrôleur moteur pouvant supporter jusqu'à 3 Ampères pour mon deuxième type de moteur à 1.7A. Le TB6560, utilisé actuellement sur un projet d'IMA5. Malheureusement, le mien étant cassé, je ne peux pas le tester sur des valeurs supérieures à 1.4A (le switch numéro 1 étant cassé). Je corrigerai donc ceci avec une soudure pour feinter un switch activé sur la valeur 1.


En parallèle j'ai décidé de réaliser mes premiers tests avec la caméra kinect. En effet, il était, selon moi, temps de commencer à exploiter cette méthode de scan. De plus, la commande des composants venant d'être lancée, il fallait que j'attende la réception de mon capteur de mesure de distance. Je ne pouvait donc guère avancer sur la méthode de scanner avec ce dit capteur. Je décide alors de tester la caméra de Microsoft.

J'ai donc commencé par beaucoup me renseigner sur la caméra, son fonctionnement et sur les différents drivers à installer. J'en ai profité pour essayer également d'installer les drivers pour la version de la seconde caméra kinect, le KINECT V2, disponible avec la console XBOX ONE. J'ai testé rapidement avec ma KINECT V2 personnelle, mais très peu de logiciels gratuits permettent un scan avec cette caméra. Je reste donc sur ma première idée, celle de rester avec la caméra, largement reverse engineering, la caméra KINECT for Microsoft, première version.

J'ai donc dû télécharger en premier un SDK version 1.8 (fonctionnant avec la première version de la caméra). Celui si permet de faire fonctionner la caméra sur un système d'exploitation et de pouvoir commencer certains premiers tests de bon fonctionnement de la caméra (détection, couleur, profondeur, etc...)

J'ai ensuite chercher à télécharger un logiciel permettant un scan et la création d'un fichier STL. Des logiciels de ce type existent en effet et permettent un scan correct pour le commun des mortels. Cependant, la qualité que nous recherchons doit ici être optimale afin de scanner avec précision un objet complexe.

Mes prédécesseurs d'IMA5 ayant également travaillé sur un scanner il y a de ça quelques années, utilisaient KinectFusion(aussi appelé KinFu). Après quelques recherches il s'avère que ce logiciel est devenu un peu obsolète et il convient mieux d'utiliser de nouveaux logiciels, optimisés et étant apparus récemment. Je décide alors de tester un logiciel dont j'ai beaucoup vu ressortir le nom lors de mes recherches sur le sujet : Skanect.

interface de SKANECT

L'installation et le paramétrage de la caméra et du logiciel ne sont pas si intuitifs que cela au premier abord. Cependant après quelques minutes de prise en main, le paramétrage a tendance à se répéter, voire même à être rébarbatif. Il suffit de le faire correctement une fois, et d'enregistrer les réglages afin de gagner du temps par la suite.

J'ai alors tenté de scanner le buste d'un étudiant de l'école. Pourquoi un buste ? Tout simplement parce que le logiciel proposait une option de scan de personne, déjà paramétrée, d'environ 2m cube. De plus, il est plus facile de s’apercevoir de la qualité des détails sur un visage d'un charmant étudiant en mécanique, que sur une tasse de café (bien que...)


Voici mes différents retours sur le test :

Les points positifs :

Le logiciel, une fois configuré correctement est assez facile d'utilisation et propose une correction du scan (remplissage des trous, lissage, amélioration diverses) Skanect permet un rendu en STL, ce qui est en accord parfait avec le projet. La qualité du scan et la puissance de la caméra sont assez surprenantes, je m'attendais à un résultat de qualité moindre.

Les points négatifs :

message d'erreur lors de la rotation trop rapide de la caméra

Malheureusement il y a de très gros points négatifs, notamment la difficulté de scanner ! En effet, pour mon premier scan, j'ai dû m'y reprendre environ 20 fois avant d'avoir mon premier scan de réalisé, et encore, de bien mauvaise qualité ! Effectivement, la stabilité de la caméra est extrêmement dure à gérer ! Dès que la caméra bouge un peu trop rapidement (dans le cas d'une rotation de la caméra autour de l'objet immobile, à scanner) ou que l'objet à scanner bouge un peu trop (dans le cas d'une rotation de l'objet sur un plateau), le scan plante. Il est alors possible de rectifier le tir, mais cela est à double tranchant : soit le logiciel redetecte l'objet correctement et le scan peut reprendre, soit le logiciel détecte de façon erronée l'objet et on peut se retrouver avec des formes qui ne ressemblent en rien à l'objet de départ (visage avec un nez qui en fait la taille d’environ 5)

La mise en rotation stable de la caméra est très difficile et délicate.

Les corrections automatiques proposées ont tendance à corriger l'objet de manière un peu "brute" et les détails sont alors perdus. Ce qui est problématique, lorsqu'on souhaite reproduire un objet scanné à l’identique;

Le rendu peut paraître correct, une fois ramener à des dimensions imprimables (environ 10cm cube), mais cela est assez évident. En effet, cela revient au même que de prendre une photo avec un appareil photo de qualité moyenne et de rendre la photo en dimensions très petites, la qualité semble augmentée ! Il en est de même dans notre cas, des contours grossiers paraissent ainsi très précis une fois le buste réduit fortement de taille. Le résultat sera bien moins satisfaisant sur un objet d'environ 15 cm cube que nous souhaiterions reproduire à l'échelle 1/1.

Kinectun.jpg
scan erroné à cause d'une correction automatique ratée, suite à une rotation non stable de la caméra

Comme évoqué précédemment, il a fallu que je m'y reprenne à de nombreuses reprises pour avoir mon premier scan ! Soit je tournais trop vite autour de la personne, soit la personne en question n'était pas à la bonne "profondeur" (distance de la caméra), soit le scan plantait pour une raison inconnue,... il fallait donc recommencer de 0 ! Et quand le scan parvenait à être réalisé, il était très peu convaincant (trous dans la tête, menton digne d'un frère Bogdanov, pas d'oreilles, etc...

J'ai donc tenté diverses techniques : - rotation de la caméra autour de l'objet -> beaucoup de ratés à cause des la faibles stabilité de la caméra (je la portais simplement dans mes mains) - rotation de la personne (sur une chaise de bureau) et caméra fixe -> "trous" au dessus de la tête car hors champs de la caméra, et rotation parfois trop rapide de l'intéressé, engendrant un échec de scan. Ou encore des modifications terrifiantes du faciès (dûes à la modification de position, en effet il est très difficile de rester totalement immobile lorsque l'on est mis en rotation).


En conclusion les premiers scans étaient donc plutôt difficiles à réaliser de part le manque d'expérience ! Je m'attendais à un résultat très médoicre mais facile à obtenir, j'ai finalement un scan très difficile à obtenir mais pour un résultat plus correct que ce que je pensais !


Lors des prochaines séances il faudra que je retente de nombreuses conditions de scan (obscurité, différentes distances de la caméra, différentes vitesses de rotation de l'objet, ou de la caméra, différentes tailles d'objets, etc...) Je n'ai en effet' pas eu le temps de tester de nombreuses configurations cette semaine, les heures défilant trop vite !

Désormais il faudra déterminer s'il est plus judicieux et facile de scanner via une mise en rotation de la caméra kinect ou via une mise en rotation de l'objet. Un compromis peut également être fait avec, imaginons, une rotation de l'objet à scanner et la caméra montant sur un bras (comme un arc de cercle) selon l'axe z et légèrement selon y, pour s’incliner une fois au dessus de l'objet.

L'avantage de la mise en rotation de la caméra, c'est que si le montage est fonctionnel dans un cas, il le sera dans tous les autres ! En effet, la caméra ne changeant pas de poids et effectuant à chaque scan la même action, il suffit juste de trouver une solution qui fonctionne une fois, pour que celle ci fonctionne tout le temps. Le problème c'est qu'elle est plus compliquée à mettre en place mécaniquement (rails pour la caméra ? Support pour l'objet ? Moteurs assez puissants ? problème d'équilibre de l'ensemble du montage....)

Si à l'inverse je dois mettre uniquement l'objet en rotation (avec une caméra immobile), bien que je gagne en facilité pour l'aspect programmation (un simple plateau en rotation) et en "conception" mécanique, il y a un risque de non fonctionnement dans certains cas. En effet, imaginons qu'un objet trop lourd soit disposés sur le plateau, il pourrait faire pencher le plateau sous son poids et donner un scan oblique. De plus, si l'objet est vraiment trop lourd, il peut augmenter le couple nécessaire à la mise en rotation du plateau, jusqu'à éventuellement bloquer ce dernier, sous un poids trop important... Enfin cette technique empêche aussi le scannage en vue du haut, de l'objet... Autant de questions auxquelles il faut encore répondre !

Je déterminerai la configuration optimale au fur et à mesure des tests et des conseils des différents professeurs et membres du Fabricarium.


Puis, pris dans un élan de courage, j'ai décidé de modéliser en 3D mes premières pièces. Bien que Rodolhe Astori m'ait conseillé de faire mes modélisations sur ONSHAPE (sorte de drive ou les utilisateurs ayant l'autorisation, peuvent modifier les pièces), j'ai modélisé les pièce simplistes sur FreeCAD. Utilisant ce logiciel depuis la PeiP, je pouvais modéliser rapidement, et cela me permettait de me refamiliariser avec un logiciel de CAO basique, car je n'avait plus touché à un logiciel de ce type depuis plusieurs mois (modélisation 3D de la manette de jeux vidéo pour la partie Bonus du tutorat système au S7). De plus, les deux pièces que j'ai modélisées étaient relativement simples : un plateau tournant pour remplacé celui fait à la découpeuse laser précédemment et trop peu stable lorsqu'un objet lourd est positionné dessus. Ainsi qu'un "tuteur" servant à éviter la rotation de ce qui supportera le capteur de mesure de distance, lorsque celui ci sera positionné sur la vis sans fin, lui permettant de s'élever. Les pièces plus complexes seront modélisées via ONSHAPE, pour faciliter la modification et les vérifications de Rodolphe et des membres du FAB.

tuteur
tuteur imprimé

L’impression du tuteur à était une semi réussite (légère torsion due au décollement de la pièce avec le plateau, lors de l'impression (surface pas assez adhérente sur ma Dagoma personnelle)) mais cela devrait faire l'affaire.

Cependant, mon impression du plateau tournant fut une catastrophe (torsion du plateau, impression ratée car trop grossière,... La quantité de PLA diminuant à vue d’œil sur ma bobine personnelle, j'ai donc décidé de tenter une nouvelle impression au Fabricarium la semaine prochaine. Effectivement, cette pièce allant être scannée de manière inévitable, car elle est en contact direct avec l'objet à scanner, il faut que cette pièce soit la plus parfaite possible (lisse et droite, non voilée) afin de pouvoir la faire disparaître rapidement au moment du rendu (descendre le rendu 3D sous un plan horizontal jusqu'à ce que le plateau tournant scanné, disparaisse sous ce plan, et ensuite réaliser une troncature). Si le plateau est voilé ou avec des défauts, le résultat ne sera jamais correct et une erreur constante se répétera à chaque scan, il faut donc éviter cela en créant à tout prix une pièce impeccable !

La semaine prochaine, il faudra que je teste les moteurs 1.7A avec le nouveau contrôleur fourni par Alexandre Boé. Pour ce faire, il faudra que je répare dans un premier temps le switch. De plus, mon alimentation ayant subit quelques dommages (soudures cassées à cause des diverses manipulations, je devrai faire une petite session réparation en début de semaine. Si le capteur de mesure de distance est reçu, je pourrais réaliser mes premiers tests dessus. Je pourrais ainsi commencer à concevoir un premier jet de carte électronique, en vue d'avoir un PCB satisfaisant, assez rapidement. Dans le cas contraire je poursuivrai les modélisations 3D des pièces nécessaires, cette fois ci en m'initiant à ONSHAPE, afin de pouvoir recevoir une aide éventuelle via le système de modification à distance proposé par cette application. J'ai actuellement un léger retard par rapport à mon calendrier prévisionnel mais cela n'est pas dramatique, un investissement constant et régulier devrait me permettre de vite rattraper ce retard. Enfin, je pense organiser une petite réunion informative sur mes avancées, auprès des membres du Fabricarium intéressés par le projet !


Semaine 5 : continuons les impressions, la découverte de Skanect, et mettons le wiki à jour !

J'ai commencé cette semaine par imprimer la pièce du plateau tournant dont l'impression avait échoué la semaine dernière. Je me suis orienté vers une technique d'encastration. Ça évite l'ennui et le coup d'un coupleur et son système de visserie. Effectivement, la force s'opposant à la rotation (et agissant sur la liaison "axe du moteur encastré dans la pièce 3D") est finalement assez faible puisque que l'objet est centré. La force dominante est le poids qui agit selon l'axe du moteur. Ainsi le fait d'encastrer permet d'assurer une fixation suffisante et facilement modélisable en 3D.

fichier .STL à réimprimer

Le résultat de l'impression est bien plus satisfaisant ! Le plateau est, presque parfaitement lisse, et résistant (33% renforcé à l'impression pour éviter de plier sous le poids des objets placés dessus)!


plateau imprimé et encastré dans le moteur

S'en est suivi une longue session de mis à jour du WIKI. En effet, bien que nous ne soyons même pas encore à la moitié des séances, mon wiki fait déjà plus de 10 000 mots. J'ai donc fait une petite séance de relecture permettant de prendre un certain recul sur le travail déjà effectué et celui restant. Cela m'a permis de faire une sorte de bilan et de voir là où les erreurs ont étaient faites. J'ai modifié aussi la mise en page et j'ai fait une petite correction des fautes d'orthographe et lexicographiques. Le travail fait en amont sur le wiki, facilitera à la fin du projet, la rédaction de la documentation que je laisserai à disposition au Fabricarium. Mon wiki est certes très détaillé mais il permettra également de servir de témoin d'avancement pour les membres du fabricarium. Il sera sûrement amené à être consulté de nombreuses fois par des étudiants de Polytech Lille et du Fabricarium en cas de souci et/ou de besoin de se former sur le scanner, le comprendre, l'améliorer etc... Ainsi une attention toute particulière est apporté à la rédaction de ce wiki et à sa mise à jour régulière. Ceci étant essentiel pour qu'il soit consulté et que l'avancement soit suivi facilement par les personnes souhaitant proposer leur aide éventuelle pour une partie spécifique par exemple. (La tenue irréprochable du wiki était d'ailleurs précisé dans l'intitulé du sujet de mon projet).


Ensuite, comme précisé précédemment dans le compte rendu de la semaine dernière, lors des différentes manipulations et tests, mes soudures ont étaient très largement abîmées et dégradées. Certaines ont d'ailleurs cédés et rendent donc le montage et l'alimentation inutilisable. J'ai ainsi pris un peu plus d'une heure pour redécouper, dénuder et ressouder mes câbles afin d'avoir des fils nets et propres, et pouvoir ainsi éviter tout faux contact, etc... Bien que ce résultat sera sûrement éphémère et nécessitera sans doute une nouvelle session de rafistolage, ses modifications me permettront de poursuivre mes tests sans souci pendant plusieurs semaines.


J'ai alors pu refaire de nouveaux tests sur les moteurs Nema 17 issus du projet de la placeuse de composants pour PCB. Et mes problèmes de soubresauts évoqués dans la séance précédente, se sont très nettement améliorés ! En effet, les sursauts du moteurs s'estompent très largement en ajustant le potentiomètre présents sur le contrôleur moteurs (ce n’était pas le cas avant). Ces derniers ne chauffent donc plus autant qu'avant (le courant est sûrement mieux dissipé). Leur température est donc nettement plus correcte que ce qu'elle a était ! Les sursauts ne sont plus du tout ressentis aux bruits et en mouvement (rotation du plateau homogène et constante). Lorsque qu'on garde le moteur en main on sent de très légers "claquements" particuliers aux moteurs pas à pas. J'ai alors comparé mon vibrement de mes moteurs à celui des moteurs identiques fixés sur la placeuse de LEGO, pour le projet de Eloi et Justine. Leur état est sensiblement le même. J'ai fait constater la comparaison à Monsieur Redon, et il a jugé mon vibrement comme négligeable. Effectivement, les moteurs de la placeuse LEGO étant fixés à une armature, il est possible que leur vibrement éventuel soit encore moins perceptible. Nous en avons donc déduit que mes réglages étaient corrects et que je pouvais me focaliser sur une autre étape ! Éventuellement si je fini le projet en avance, je tenterais de régler parfaitement les moteurs si cela est possible (avec un analyseur, oscillo, etc... en C201)

Je n'ai pas eu le temps de me focaliser sur le TB6560 pour faire tourner mon moteur 1.7A, ni même de regarder les contrôles de moteurs avec les A4988. Je reviendrai sur ces étapes plus tard. En effet je n'ai pas besoin de faire tourner plus de deux moteurs pour le moment, je me chargerai donc de ses étapes lorsque le besoin s'en fera sentir. Je préfère en effet me focaliser sur les étapes essentielless désormais, à savoir essayer d'améliorer les scans avec la kinect et proposer des solutions à mettre en place pour le faire. Il faudra ensuite que je fasse des prototypes à tester et à présenter au FAB. En attendant la livraison du capteur de mesure de distance, je travaille donc sur d'autres étapes de mon projet.


Enfin, j'ai pu profiter de mes quelques heures libres dans mon emploi du temps pour aller échanger un peu avec Rodolphe Astori sur mes ressentis de différents tests et pour voir éventuellement quand je pourrai faire une petite présentation/bilan de mi-projet aux personnes du FAB souhaitant en savoir un peu plus sur le sujet. Nous fixerons une petite réunion prochainement.

J'ai pu poursuivre la configuration et les tests de scanning via skanect.

trou au sommet du crâne
trous divers

Cette fois ci j'ai décidé de faciliter la réalisation du scan en me mettant moi même en rotation sur une chaise de bureau, avec la caméra fixe. Il s'avère que le scan à donné un résultat plus que correct ! Il y avait tout de même la présence de certains trous dus à l’impossibilité pour les rayons IF de la caméra d'accéder au sommet de mon crâne ou encore, derrière certains plis de ma capuche. Finalement, après correction automatique du logiciel, les trous furent comblé de manière grossière mais acceptable. Le but étant surtout de découvrir les différentes possibilités du logiciel et de la caméra afin de trouver la combinaison optimale pour un scan. Le scan fut réalisé grâce à une mise en rotation très lente et délicate.

J'ai enregistré en vidéo la réalisation du scan. Ceci nous permet de nous apercevoir de la minutie dont il faut faire preuve. De plus, sur la vidéo on constate bien les différentes couches de profondeurs grâce au différentes couleurs (selon la distance de réflexion des ondes infrarouges) La difficulté réside également dans l'ajustement de la distance maximum et minimum de portée de scan. Effectivement, si le paramétrage possède une portée trop longue, le scan sera totalement raté car il prendra en compte la rotation de l'objet, mais également les objets fixes qui l'entourent... Dans ce cas, le scan plante donc très rapidement après son lancement.

portée trop grande de scan, scannant ainsi l'objet et le décor en arrière plan

J'ai cependant réussi à obtenir un résultat final exploitable. La version gratuite de Skanect possède un nombre de faces limitées. Ce qui diminue la qualité sur un scan complexe comme celui de mon buste, mais qui ne devrait pas poser trop de problème avec une pièce simple (cube, tasse, clé, etc)

Finalement voici le résultat final du scan de mon buste ainsi que le fichier .STL qui en fut généré :

scan après corrections
mon buste en fichier .STL

A noter que Monsieur Redon a constaté le résultat du scan et a jugé le résultat correct ainsi que "rassurant pour espérer qu'on puisse finalement avoir un résultat à la fin (rire)". L'objectif dans les jours à venir va donc désormais être de réaliser différents tests de scan et dans diverses conditions. Je me chargerai de faire varier la luminosité, la vitesse de mobilité de la caméra, son orientation selon les différents axes, la distance de scan, la taille de l'objet à scanner, etc... L’objectif sera de déterminer les facteurs susceptibles de faire planter le scan, et ceux permettant une reproduction fidèle et optimale de l'objet original.


Voici la vidéo de la réalisation du scan en vitesse réelle :


Je décide enfin, de profiter du week end pour m’initier à ONSHAPE et commencer la modélisation des parties restantes pour le scanner avec capteur de mesure de distance. Les pièces plus ou moins complexes sont: - le support du moteur "élévateur" soutenant la vis sans fin, le tuteur et les deux barres métalliques empêchant la rotation du capteur. - la pièce où je viendrai fixer le capteur de mesure de distance et qui sera attachée à la vis sans fin. - une coque éventuelle pour carte électronique (que je modéliserai ultérieurement, une fois le PCB définitif réalisé) - une pièce permettant de rassembler les différents éléments en 1 seul, une sorte de squelette qui liera les deux moteurs. J'avais pensé faire cette pièce avec deux grands axes en métal récupérés au FAB, permettant d'ajuster la distance séparant le plateau tournant et le capteur de distance. Facilitant ainsi l'amélioration des mesures et l'ajustation parfaite des réglages grâce à la facilité de modifier les conditions de tests. Je vois en effet le projet comme étant un projet sur le long terme que j'essaierai de mener le plus loin possible et qui, je l'espère sera amené à évoluer dans le temps et à être amélioré. Je dois donc le concevoir avec une notion d'amélioration éventuelle, et ainsi prévoir les choses de façon à faciliter son évolution. Ainsi, cette distance ajustable, en plus de permettre de faire facilement différents tests de distance, permettra aussi de pouvoir ajuster le scanner en fonction de la taille de l'objet que l'on a à scanner. Nous créerons ainsi un scanner évolutif et adaptable, toujours dans le but d'avoir un scanner des plus efficace et précis possible.

Il serait également judicieux de commencer à concevoir des plans et des dessins de projet de scanner utilisant la caméra kinect. La réalisation et la création de ce scanner étant sans doute la partie la plus chronophage du projet, il faut que je l'anticipe rapidement. Je compte d'abord, afin de limiter les coûts et le temps, concevoir l'essentiel de ce 2ième scanner (au moins pour le prototypage) en découpeuse laser. Nous verrons ensuite grâce aux différents tests, s'il n'est pas plus judicieux de s'orienter vers un modèle en aluminium ou vers des pièces imprimées en 3D. Je ferai donc dans les séances suivantes, beaucoup de découpes laser (excepté pour la partie "support" de la caméra, que je pense uniquement modélisable en 3D via logiciel de CAO.).


Semaine 6 : Pièce 3D toutes terminées, on attend plus que le capteur de mesure distance !

Cette semaine, l'avancée fut un peu moins flagrante que les deux précédentes. Effectivement, premièrement nous avions bien moins d'heures de libre dans l'emploi du temps. De plus la prise en main de ONSHAPE fut un peu plus complexe que ce à quoi je m'attendais. En effet, après avoir fait mes dernières pièces sur FreeCAD et m'être beaucoup formé à l'utilisation de SolidWorks, il fallait qu'une fois de plus je me force à maîtriser un nouveau "logiciel".

Le principe d'apprentissage fut tout de même assez rapide, les logiciels de CAO reposent tous plus ou moins sur la même méthodologie : création via dessin d'une pièce en 2D, puis extrusion et ajout de matières, etc... La partie la plus longue est donc de devoir retrouver où se trouve telle ou telle fonction dans les barres des taches, etc... Cependant je dois avouer que ONSHAPE est vraiment très puissant ! Pour faire simple, c'est l’équivalent d'un google drive ou d'un git, mais pour les pièces en 3D. Chacun peut faire ces pièces sur son PC, pas besoin d'installer quoi que ce soit, tout se fait en ligne après une création de compte. Libre à chacun à de partager ses créations comme bon lui semble, avec les personnes de son choix.

De plus, selon les différents droits attribués, les personnes peuvent visionner, cloner ou même modifier les pièces pour les améliorer. Je pense que ONSHAPE va être amené à grandir et à devenir de plus en plus connu. Quoi qu'il en soit je ne regrette absolument d'avoir suivi le conseil de Rodolphe à propos de cette application, je pense désormais l'utiliser à la place des logiciels ce CAO sur lesquels je modélisais jusqu'à présent et qui sont "ressource-ivores".

Cependant, fonctionnant en ligne, ONSHAPE peut rendre la modélisation un peu compliquée lorsque la connexion internet n'est pas bonne. C'est ce qui m'est arrivé durant la séance de 4h Mercredi aprés midi en E306... Chaque modification, chaque ajustement de valeur, se met à jour une ou deux secondes après le click de souris. Les modélisations des pièces nécessaires au scanner par capteur de mesure de distance ont donc été un peu plus longues que prévues... Cependant, j'ai tout de même réussi à finir de toutes les modéliser avant la fin de la séance.

Ainsi après quelques heures de modélisation je disposais des trois pièces que je comptais créer ! A savoir :

tuteur pour capteur de mesure de distance
support moteur du plateau tournant
support capteur de mesure distance


La première pièce, le "tuteur pour capteur de mesure de distance", maintient l'écart entre les deux barres "tutrices" permettant lélévation du capteur. Elle assure aussi que la distance objet-capteur de distance est bien conservée tout au long du scan. Enfin, elle garde le moteur maintenu afin d'éviter les soubresauts ou le déplacement non souhaités du moteur.

La seconde pièce, "support capteur de mesure de distance", est une partie mécanique plus complexe, permettant de maintenir le capteur de mesure de distance droit et orienté vers l'objet à scanner, tout en le faisant s'élever grâce à l'axe hélicoïdale.

Enfin la dernière, "le support moteur du plateau tournant", permet le maintien du moteur et facilite le maintien de la distance plateau tournant-capteur.

Ne maîtrisant véritablement que l'imprimante Dagoma jusqu'à présent, j'ai également utilisé une partie de mon temps libre pour faire une formation au Fabricarium dans le but de maîtriser toutes les imprimantes 3D mises à disposition. Je pourrai ainsi imprimer mes différentes pièces une fois celles ci modélisées.


De plus, la commande Farnel étant arrivée juste avant le début des vacances, j'ai pu récupérer le capteur de mesure de distance que j'attendais. Je vais ainsi pourvoir éventuellement procéder à quelques tests sur son fonctionnement pendant les vacances, pour m'avancer un peu.


Semaine de vacances : Assemblage et premières limites de l’impression 3D...

Je profite de la semaine d’interruption pédagogique pour rattraper mon léger retard de ma faible avancée la semaine précédente. En effet, l'école étant accessible et ouverte, ainsi que la salle E306, et le Fabricarium, j'ai pu finalement bien avancer.

Premièrement toutes les imprimantes 3D étaient disponibles et libre ! Chose impossible en période scolaire habituellement. J'en ai donc grandement profiter pour mettre à profit ma récente formation sur les différentes imprimantes. Plus tard je comprendrais que ce choix de venir pendant les vacances m'a fait gagner un temps considérable. En effet, aux vues des nombreux problèmes rencontrés durant cette semaine de disponibilité totale des imprimantes, les mêmes problèmes en période d'overbookage des imprimantes m'aurait facilement fait perdre deux semaines. Ici, j'ai pu corriger rapidement et réimprimer dans la foulée ! Résultat : en une semaine je passait de mes modèles 3D sur ONSHAPE, à une version physique imprimée et aboutie (du moins aboutie pour un prototype "qui prend forme").

Durant cette semaine, je vais être confronté aux limites de l'impression 3D...

Premièrement : le temps ! Si on lançait une seule et même impression, contenant toute mes pièces nécessaires, sur une seule imprimante, il faudrait plus de 28 heures d'impression ! L'idée a donc était de faire plusieurs petites impressions, en monopolisant les imprimantes du FAB. De plus j'ai réduit considérablement le temps d'impression en passant les paramètres de remplissage de "plein" (100% sur la witbox) à "renforcé" (17% sur la Dagoma DiscoEasy200). Là pièce est en effet moins résistante mais n'étant pas persuadé que les pièces conviendront parfaitement, je décide de faire un compromis de résistance pour gagner du temps. Je réimprimerais éventuellement tout à la fin en 100% de remplissage pour la version ultime du scanner. J'ai décidé aussi de réduire la précisons d'impression (nous sommes toujours bien en dessous du millimètre mais je ne me souviens plus des valeurs exactes des paramètres). Tout ceci a pu me permettre une impression total de 18H. Remarque : Je paierai finalement ces deux petites modifications un peu plus tard dans le wiki...


Puis une impression lancée n'est pas forcément une impression qui aboutira ! Effectivement la dagoma n'a jamais daigné se lancer. De plus la witbox à complètement planté... Je déciderai finalement de réimprimer les pièces sur mon imprimante personnelle pendant ce qu'il restait des vacances.


Malheureusement, le PLA que j'utilise sur mon imprimante perso est un peu particulier (de l'"Octofiber" utilisé pour les pièces de couleur "bleu nuit" un peu brillant). Il est légèrement plus résistant que la moyenne. Cependant, il a une fâcheuse tendance à se rétracté sur lui même au moment du refroidissement. Ce qui entraîne des pièces courbées... Même l'ajout d'un support pour améliorer la fixation sur le plateau n'y change rien. : ne support de maintien pli avec la pièce. Ce fut particulièrement problématique lors des impressions de mes différentes pièces !

pièce diforme en sa base, pli survenu lors du refroidissement du PLA
pièce brisée sous le coup d'un coup de marteau un peu trop généreux
encastrement provisoire, endommagé lors de l’encastrement et rafistolé comme possible

Ainsi mes pièces en plus d'être courbées et donc peu stable, elles avait une légère inclinaison au niveau des "cylindres creux" censés maintenir les barres en métal. De plus, n'ayant pas laissé de marge de sécurité de peur d'être trop ample (j'ai mis un trou de 8mm de diamètre pour recevoir une barre de la même dimension.) Avec le recul, je pense qu'il aurait mieux valut laisser un millimètre de plus au moins. Je me retrouvait donc avec des pièces pliées, avec des "tunnels courbés" pour accueillir des barres rigides trop grosses. Autant dire que j'ai un peu regretter d'avoir baissé la précision au maximum. Pour les encastrement chaque dixième de millimètre compte.

Je me dis alors que je forcerais un peu au moment de l'encastrement et que ça suffira pour les tests. C'était sans comptais sur le second paramètre que j'avais modifié : la remplissage ! Un léger coup de marteau et BIM : me voilà en train de ramasser les petits morceaux d'une pièce que j'avais mis 7 heures à imprimer... (le "support plateau tournant)

Je décide d'y aller un peu plus délicatement avec la pièce "tuteur pour capteur de mesure de distance". Le moteur s'encastre (bien que j'ai dû forcé, les dimensions n'étant pas parfaitement adaptées). La première barre en métal également. Mais pas la seconde qui a cassé un peu l'encoche censé recevoir la barre. Je décide alors de faire la méthode dite "de bricolage". J'ai mis quelques élastiques et de la colle afin de limité le jeu de cette barre. Cela marche parfaitement bien que l'esthétique ne soit pas génial. Une fois de plus, j'imprimerais cette pièce dans de meilleurs conditions, un peu plus tard. Étant donné que cette pièce sera sûrement manipulée de nombreuses fois et risque d'être d'avantage endommagée, je décide de la conservé pour le moment, au point où elle en est elle ne craint plus rien !


upright=0.8impression du "support de capteur de mesure de distance" complètement ratée. Et qui plus est, aux mauvaises dimensions

Et quand tout s'est bien passé : impression, dimensions respectées, pas de plis, pas de bavure, etc... et que vous pensez enfin avoir quelque chose d'exploitable... TADA ! c'est le moment qu'intervient les erreurs de calibrage ! Pour le coup, je n'ai pas d'excuse, c'est juste moi même qui suis ***. Allez savoir pourquoi, pour encastrer deux cylindres séparés de 2 cm, j'ai décidé de les séparer de deux..INCH ! Et pour encastrer roulement à bille de 8 mm de diamètre, autant voire large et faire 8 mm de RAYON ! Après tout comme dit monsieur Vantroys "la règle de base en mécanique, même quand c'est aux bonnes dimensions ça ne rentrera pas". Tout cela pour dire que malgré mes nombreuses vérifications, j'ai laissé traîner des erreurs de mesures, parfois explicables par inattention, parfois complètement incompréhensibles...

Même ma pièce la plus simple, le tuteur supérieur qui maintient juste les barres parallèles, ne correspond pas ! La fameuse tendance à plier lors du séchage du PLA n'a pas épargné cette pièce qui semble parfaite au prima bords, mais qui en fait est légèrement décalé par rapport à ce qui était prévu. Ceci a pour conséquence de ne pas donner des barres totalement parallèles. Le coulissement des roulement à billes ne sera donc pas possible sans forcer, et donc endommager les roulement à billes...

Et pour finir, après quelques minutes d'impression et de fausses persuasion de "ça va quand même marché", je me vois contraint d'arrêter l'impression de recommencer la modélisation de ma pièce la plus complexe "support capteur de mesure de distance". Je ne sais pas expliquer le nombres d'erreur faites lors de la modélisation... Toujours est-il que j'ai du recommencer cette pièce de 0. De toute façon, l'impression avait complètement planté, avec un décollement total de la pièce du plateau et une énorme "boule de PLA" fondue et brûlée dessus (malheureusement un incident pas si rare que ça sur ma dagoma...).



En y réfléchissant, aucune pièce n'a était réussi du 1er coup ! Je remodélise alors toutes les pièces et les réimprimes toutes ! Excepté le "support capteur de mesure de distance" qui est vraiment très long à imprimer et qui, une fois rafistolé, sera amplement suffisant pour mes différents tests. Pour les autres pièces, je me résout à reprendre une modélisation un peu plus adaptée, avec une petite retouche de certaines pièces pour gagner un peu de temps à l'impression et en performance.

nouveau support du moteur lié au plateau tournant
support du capteur de mesure distance, repensé, amélioré et fonctionnel
nouveau tuteur supérieur, très légèrement modifié et réimprimé

Ainsi mon "support plateau tournant" sera moins plein et possédera une marge d'erreur plus grande pour l'encastrement des barres et du moteur : 1 mm ! (Cela ne sera pas non plus suffisant mais au moins j'ai réussi à encastrer le tout en forçant un peu !).

Mon "tuteur" sera rapidement repensé et réimprimer, en prenant en compte cette fois l'écart de diamètre des barres à encastré.

Mon "support capteur de mesure distance", complètement repensé est alors revérifié moult fois avant d'être lancé en impression. Son prédécesseur cumulait les erreurs et incohérences... Je ne compte pas faire deux fois la même bêtise ! Finalement cette pièce sera imprimée et c'est celle qui me posera le moins de souci : encastrement sans forcé, fixation résistante, impression sans bavure ni pli...

pièce de support de moteur fissuré sous les contraintes des barres, à cause d'une pliure non voulue, encore une fois due à un refroidissement défaillant



Bien entendu tout ne s'est pas résolu parfaitement et mon "support plateau tournant" se courbera une fois de plus malgré les précautions prises, et aura une grande fissure qui va se formée petit à petit...

En conclusion, après des impressions laborieuses, je fini finalement par obtenir un résultat acceptable bien que pas du tout professionnel (support du plateau tournant fissuré, et support du moteur élévateur, courbé, provisoirement rafistolé avec de la colle et des élastiques). Je réimprimerai le tout avec les imprimantes du FAB (avec les paramètres de précision et de remplissage optimales). Ma bobine personnelle étant quasiment finie et les imprimantes 3D du Fab redevenant de moins en moins accessibles avec la reprises des cours, réimprimés ces pièces parfaitement, alors qu'elles n'ont peut être même pas leur forme définitive pour le scanner, serait une perte de temps.



Heureusement, tout n'est pas tout noir ! J'ai tout de même pu imprimer le fichier STL de mon buste scanné il y a quelques jours. L'impression à été faite sur l'imprimante la moins précise des 3 car cette partie était plus une partie "bonus". Ainsi àprès 6h d'impression, naquit "un petit moi". Bien que cela ne constitue pas une grande difficulté au vues de la facilité d'utilisation du logiciel Skanect, cela permet de se donner une petite idée des performances et des possibilités de la caméra Kinect. On peut noter une nette fidélité au modèle initial. Je pense pouvoir être reconnaissable sans grande difficulté.

buste imprimé
trou dans le crâne corrigé par Skanect, mais infidèle au modèle réel

Cependant on constate quelques soucis, comme par exemple un gros trou dans le sommet du crâne, dû au manque de scanne à cet endroit, que le logiciel à corriger tant bien que mal. De plus on distingue des "faces". Effectivement la version gratuite de skanect n'offre qu'un nombre limitée de faces pour le fichier scanné. Ceci est distinguable sur un modèle complexe comme un buste, mais ne devrait pas posé de problème pour des pièces mécaniques, comme celles destinées à être scannées par le scanner au Fabricarium. Je tiens à rester sur mes gardes tout de même. Le modèle est fidèle mais comme expliqué précédemment dans le wiki, un modèle "grand" comme un buste, ramené à des dimensions imprimables, parait très précis (comme réduire de taille une image de mauvaise qualité, on a la sensation que la qualité augmente), mais cela sera bien entendu à tester sur des objets à reproduire à l'échelle 1/1. Je pense que le résultat sera bien moins satisfaisant pour ceux ci : un défaut de scan sera directement reproduit sur le produit final. Il faudra donc veillé à la grande qualité de scan à réaliser.


Semaine 7 : une ossature qui semble correcte, un capteur capricieux, et une alim' toute neuve !

Après cette semaine de vacances j'ai pu ainsi prendre un peu de recul sur mon projet. J'ai pris calmement le temps de relire l'intégralité de mon wiki et d'en corriger les fautes d'orthographe (beaucoup trop nombreuses...). J'ai donc pu constater que certaines pistes que j'avais prévu d'explorer sont passé à la trappe au profit de certaines autres. L'exemple le plus probant est celui du système d'élévation du capteur de mesure de distance : je devais essayer une méthode de "poulie/courroie" ou un système de vis sans fin. Je me suis orienté sans vraie raison vers la seconde solution. J'ai tout simplement "oublié" la première, étant pris dans le projet et dans son avancée, j'en ai négligé certains points. Ici, rien de bien dramatique étant donné que je pense que chacune des deux méthodes est aussi bonne que l'autre. Mais il faudra que je me fixe certaines méthodes de travaille et m'impose certaines explorations de solutions par la suite. En effet le temps commence à être précieux ! nous sommes déjà à plus de la moitié du projet !


scanner monté
montage final

Désormais, l'ensemble de mes pièces sont imprimées et assemblées ( bien sûr ce n'est sans doute pas la forme définitive, et les pièces seront sûrement améliorées et réimprimées plus tard). Je peux donc procéder à quelques tests. Le point le plus sensible concernent l'élévation du capteur de mesure de distance. En effet, cela ne se voit pas à l’œil nu mais les deux barres parallèles (sur lesquelles le support du capteur va coulisser), ne sont pas parfaitement parallèles. Au sommet de la vis sans fin, l'écart est parfait et le glissement se fait avec quasiment aucun frottement. Pourtant plus on descend et s'approche du moteur, plus les barres ont tendance à s'écarter et ainsi à rendre le glissement difficile. Effectivement, la pièce n'étant pas du tout modulable, les roulements à billes sont alors compressés contre les barres métalliques. Sur le long terme, cela peut endommager la barre et le roulement. J'avais peur que cette augmentation du couple nécessaire à la bonne rotation, soit trop importante pour le moteur NEMA17, et qu'ainsi le capteur ne pourrais pas aller jusqu'à la butée basse de la vis. Par chance il n'en était rien ! Après avoir mis en rotation les moteurs, je me suis aperçu que tout allait parfaitement, et le frottement important que l'on sent lorsqu'on bouge la vis à la main, ne se distingue pas lorsque les moteurs sont sous tension. Cependant, le projet étant amenés à perdurer dans le temps, je tâcherais de modifier cette légère erreur, qui pour le moment est de l'ordre du détail, mais pourrait endommager gravement le coulissement, à petit feu. A noter que Monsieur Redon a pu voir les deux moteurs en marche, l'un faisant tourner le plateau et le second permettant l'élévation du capteur de mesure de distance.

support du capteur de mesure de distance, lié à l'ensemble du système élévateur

N'ayant pas eu de temps de tester le capteur de mesure de distance pendant la période d'interruption pédagogique, je m'y suis attelé dès le début de la semaine. Malheureusement tout n'était pas aussi simple que ce que je pensais. Premièrement, les jumpers dont je disposés était trop gros pour rentrer dans la connectique du capteur. J'ai donc commencé par limer avec un cuter les parties femelles des 3 jumpers (vcc, gnd et data) pour gagner quelques précieux micromètre et pouvoir ainsi connecté mes files. Une fois ceci fait, j'ai alors tenter de coder directement une analyse de la distance précise, en fonction de la valeur retournée par le capteurs. Ceci est réalisable, notamment avec la fonction map, très pratique dans mon cas. J'ai ensuite réalisé que l'augmentation de la tension renvoyé par le capteur n'était pas linéaire et ainsi la fonction map était inutilisable, ou du moins, sans modifications approfondie avec la datasheet en référence. J'ai donc chercher à répertorié les différentes valeurs de tension lues, en fonction de la distance séparant un objet du capteur. Le but était de voir si, premièrement les résultats étaient précis, et ensuite de savoir si il était bien en accord avec la documentation fournie du capteur. Enfin je pourrais me faire une idée d'une marge d'erreur à prendre en compte. Pourtant j'ai fais une première petite erreur, j'ai pris comme objet de référence, le premier qui me tombé sous la main, à savoir un de mes moteurs NEMA. Ceux ci sont en métal, argentés et, d'après les remarques sur les différents forum, très mauvais pour les reflets. Je m'en apercevrais assez rapidement et je ferai mes tests avec un objet mat. Malheureusement, les chiffre ne donnait rien de logique, j'ai commençait à remplir le tableur des valeurs relevées, et c'était une catastrophe ! Les valeurs fluctuait du tout ou rien, sans vraie logique... Je constatais un stabilisation autour d'une valeur seulement après avoir laissé le capteur immobile pendant plus d'une minute ! Ce qui n'était pas du tout normal. D'après les avis, les conditions de luminosités, les couleurs de l'objet, etc... influent beaucoup sur le résultats de la valeur retournée. Mais là c'était vraiment anormal ! Je ne sais pas l'origine du souci et je ne l'ai pas trouvé du tout durant cette semaine. L'objectif sera donc de régler le plus rapidement possible ce souci dès le début de la semaine 8 ! Je ne peux plus me permettre de perdre beaucoup de temps sur les choses qui devrait marchait du premier coup...


nouvelle alimentation pour la version finale du projet


Enfin, j'ai eu la bonne surprise de constaté qu'une alimentation avait finalement était commandée par les professeurs. Ce qui était normalement convenu, c'était que j'utilise l'ancienne du PFE de 2015 (qui marche très bien au passage). Mais apparemment, une nouvelle alimentation, plus discrète et esthétique a été jugée de bon goût, si jamais le projet venait à aboutir. J'approuve cette idée. Je poursuivrait ainsi mes prototypes avec l'ancienne alimentation et je la remplacerai par la nouvelle à la toute fin du projet, comme ceci le scanner aura une alimentation toute neuve ! Pouvant fournir du 24,7 ampère et du 12 volts pour trois devices, je devrait surement faire une petite carte Electronique pour adapté les valeurs à certains composants, de sortent que, tout comme avec l'alimentation actuelle, le scanner ne soit alimenté que par une seule prise secteur (cela est tout de même plus pratique).


Pour la semaine prochaine l'ordre du jour est donc en partie, celui qui aurait dû être réalisé cette semaine, à savoir comprendre et maîtriser parfaitement le capteur de mesure de distance (il faut impérativement comprendre l'origine du problème de relevé de mon test). Ainsi que scanner dans différentes conditions de luminosités, sur différents objets, de différentes matières et couleurs, etc... Avec les deux types de scanners. Je répertorierai ainsi les différents résultats.


Semaine 8 : avancement sur le scan Kinect, test de scan d'objet transparents et un SVG laborieux

Lors de cette semaine, j'ai décidé de laisser un peu de coté le scanner à capteur de mesure de distance pour privilégier celui utilisant la Kinect. Pour plusieurs raisons : la première étant que j'avais terminé en quasi totalité la partie mécanique du premier scanner. Pour être au même niveau d'avancement avec les deux scanner, il fallait donc que je focalise sur la structure mécanique du second. De plus un groupe d'IMA 3 ayant un projet similaire pourrait éventuellement avancé sur ce système. Il était donc plus judicieux de leur laissé expérimenté certains aspects de ce scanner, et éventuellement recueillir leur impressions, pour éviter de faire les même erreur que eux auraient pu faire. Enfin, la kinect étant plus prometteuse au niveau de mes tests que le capteur de mesure de distance, je me charge alors de développer ce qui a le plus de chance d'être satisfaisant pour le Fabricarium de l'école.

J'ai donc pensé à une système mécanique permettant le scan complet d'un objet. Après en avoir parlé aux professeurs, je garde en tête deux modèles différents mais, au moins sur le papier, réalisables (bien qu'assez complexe). Je vais tenter de les expliquer clairement, bien que ce soit assez compliqué de décrire à l'écrit un système mécanique complexe. L'idée, je le rappelle est de faire s'élever la caméra et de faire en même temps, tourner l'objet à scanner sur lui même. Contrairement à ce que j'avais annoncé au début de ce projet, je ne ferais pas tourner la caméra autour de l'objet. Certes cela me permettrait d'avoir un couple non variable (si la mise en mouvement de la caméra fonctionne une fois, comme à chaque fois les conditions sont les mêmes (le poids de la caméra ne varie pas)), mais les différents tests avec la kinect m'ont montré que moins la caméra bouge, moins le scan est susceptible de planter. Il faudra donc que je trouve un moyen de limiter le couple au niveau de la mise en rotation de l'objet. Le couple variera en fonction du poids de l'objet c'est indéniable, mais on peut toujours limiter l'influence de ce dernier avec par exemple un roulement à bille ou un autre système ayant un couple "négligeable" face au couple proposé par le NEMA 17.

Pour ce faire, j'ai donc pensé, comme précisé précédemment, à deux structures. Je vais en tester une et si elle ne fonctionne pas, je tenterais avec l'autre en espérant obtenir un réussite.

La première structure est donc deux arc de cercle, soutenant chacun à leur extrémité, une des extrémité de la caméra kinect. Ces deux arcs de cercle serait entraînés par deux roues dentées (elles mêmes entraînées par un des NEMA). Afin d'avoir une trajectoire précise, les deux arc de cercles, suivraient une "gouttière" creusée dans la structure fixe du scanner. Cela est censé amélioré la stabilité et la rigidité de l'ensemble.

La seconde structure à laquelle j'ai pensé, serais deux "gouttières" parallèles sur lesquelles viendraient glisser les extrémités de la caméra. Cette fois ci la caméra serait directement entraînées par le moteur, avec par exemple deux courroie reliés aux moteurs et à chaque coté de la caméra (l'avantage est que comme la caméra s'lève de manière homogène, l'élévation de chaque coin de la kinect peut être régie par un seul et unique moteur.

Dans les deux cas, la difficulté sera de limiter les frottements au niveau de gouttières. La rotation de l'objet en question est censé être la même, peu importe le modèle de structure utilisé.

Je me suis donc orienté vers la seconde méthode, de manière arbitraire, il fallait bien en tester une en premier. Pour cela, j'ai utilisé le logiciel inkscape, sur lequel j'avais déjà fais quelques fichiers SVG en PeiP ou même en IMA3 et 4, mais pour des formes très très simplistes (comme le disque, découpé en guise de test au début du projet, servant de plateau rotation à l'objet pour le scanner à capteur de mesure de distance ou encore la découpe de la guitare en IMA3, étant finalement qu'un simple trait, contournant une image de guitare trouvé sur internet). Sans le savoir ,e je venait de me lancer dans une tâche qui allait me faire perdre beaucoup de temps... En effet, utilisant ce logiciel pour la première fois pour des formes complexes, je m'y suis pris de la mauvaise façon. Je me contentait d’effacer les trait de construction superflus en redessinant par dessus un rectangle blanc ( symbolisant une gomme et un écrasement des traits). Le résultat, au moment de l'enregistrement en svg était correct

corruption du fichier sur le logiciel

Cependant, une fois lancé dans le logiciel Trotec (nécessaire à la découpe laser), celui ci laissé apparent l'ensemble des traits que je pensais effacés (voir image 2)

Je n'ai bien entendu, pas lancé la découpe, celle ci aurait était une catastrophe car chacun des traits présent sur le fichiers, aurait était une ligne de découpe. Je me serai retrouvais avec une collection de petit morceaux de bois inutilisables...

J'ai alors décidé de recommencer ce même fichier, sur un logiciel que je maîtrise bien plus : Photoshop. En effet, j'ai pas mal d'heure d'apprentissage sur ce logiciel de retouche photos, très utile également pour créer des formes particulière, qui une fois rendu en format pdf, sont exploitables par ma découpeuse laser. Ainsi le soir j'ai passé quelques heures à créer à la perfection ce dont j'avais besoin

Pourtant, lorsque j'ai voulu le découper au FAB. Impossible ! Le fichier bien qu’apparaissant normalement sur les logiciel de visionnage de pdf, était totalement bancal lors de l'exploitation par Trotec. Soit les traits étaient discontinues pour une raison inconnue, soit il s'estompaient petit à petit jusqu'à disparaître, ou encore il passé d'un rouge 255 à une variation en niveau de gris inexploitable par le logiciel... Chaque fermeture et réouverture du fichier était un peu comme lorsqu'on se sert dans la boîte de chocolat que nous a offert notre tante à pâques : on ne sait pas sur quoi on va tomber mais on sait d'avance que ce ne sera pas bon !

Après avoir ainsi perdu de précieuses heures, je commençait à désespérer quand Rodolphe Astori m'a appris que ONSHAPE (pour rappel c'est le logiciel sur lequel je modélise mes pièces en 3D pour ce projet), permet de rendre les faces des objets en fichier DXF, vectorisé et exploitable pour une découpe laser ! Si j'avais su...


La fin de la semaine m'a permis de faire de nombreux tests avec la kinect. J'ai pu scanner différentes formes, différentes matières, de différentes manières possibles et dans des conditions différentes. J'i pu ainsi en découvrir un peu plus sur les différentes erreur à ne pas faire. J'ai alors eu l'idée de faire une vidéo récapitulative de toutes les erreurs possibles et leur conséquences. Cette vidéo permettra aux futurs utilisateurs du scanner, de ne pas tomber dans les éventuels pièges dans lesquels je me suis aventuré. A l'heure actuelle cette vidéo n'est pas encore disponible, je pense la réaliser pendant les vacances d'avril, lorsque je serais persuadé d'avoir exploité toutes les éventuelles failles possibles. Ayant quelques expériences en termes de montage vidéo, je pense que la forme ne posera pas de problème. Le tout est d'arrivé à faire une compilation des erreurs assez claire et judicieuse.

Le test qui aura le plus de conséquence sur mon orientation de solution de structure mécanique est sans doute le test que j'ai réalisé sur transparence. J'ai effectivement emprunté une boite transparente disponible en salle E302 et j'y aies placé le premier objet que j'avais sous la main. Il s'est avéré que c'était le buste de moi même que j'avais imprimé auparavant. Je décide alors de refaire un scan de ma personne mais cette fois ci en tenant dans les mains, la boîte transparente et contenant mon buste imprimé et opaque. Le résultat est assez surprenant ! L'aspect transparent est presque ignoré de la caméra (hormis pour les endroits opaques (comme les arrêtes d’encastrement entre le couverte et le réceptacle)). C'est ainsi que j'en conclu que si le support sur lequel l'objet à scanné était transparent, la caméra pourrait également scanner en dessous de l'objet et la retouche en post scan avec skanect serait facilitée (le support étant ignoré en théorie, l'objet peut donc être imprimé sans avoir besoin de supprimé quoi que ce soit comme partie scannée parasite)


boite transparente
boite transparente ignorée partiellement au rendu
boite transparente ignorée partiellement durant le scan


Ce que j'ai réussi à tirer comme conclusion de mes différents scan avec la kinect :

- Si on scan en commençant par sa base et en positionnant la caméra plus bas que l'objet, la détection de ce dernier est plus facile.

- si à l'inverse on positionne la caméra plus haut que l'objet à scanné, on a de forte chance de scanner la table/ le support sur lequel est posé l'objet

- si l'objet à scanné est trop prêt d'un mur par exemple, si le mur est détecté, la caméra est perdue et le scan est inexploitable (nuage nucléaire de point)

- le scanner, ignore totalement (dans la mesure d'une opacité non excessive) les objet transparent. Ainsi un scan de moi tenant une boite transparente avec mon buste scanné à l'intérieur, donne comme résultat : "moi faisant léviter un buste de moi".


J'ai ainsi pu tirer comme conclusion qu'il fallait que le scan commence en bas de l'objet et que la caméra monte progressivement. L'objet doit être surélevé par rapport à la caméra et loin de toute structure (mur, table, autre objet, ...). De plus, il serait judicieux d'avoir un support transparents, ce qui permettrait d’ignoré le support et de scanné l'objet en entier et même en vue du dessous.

Semaine 9 : Chasse au trésor et découpe/collage et limites de la découpeuse laser

A court d'idée d'objets transparents, pouvant faire mon support d'objet, je décide alors d'aller faire un tour du coté de V2. Les magasins de bricolage sont souvent une bonne source d'idée et d'inspiration. Je n'y ai pas trouvais mon bonheur mais je savais quoi chercher ! Après avoir fait quelques magasins, j'ai opté pour une boule (deux hémisphère transparentes). J'ai également prix un verre et une bouteille de pulvérisateur translucide (le fameux "pchi-pchit" du jargon familial).

Puisque j'étais dans la collecte d'objet, j'ai alors décidé de faire un petit aller retour dans la réserve du fabricarium, pour éventuellement tomber sur un accessoire ou une pièce, permettant de faire naître une idée. BINGO ! J'ai pu trouver une ancienne roue dentée avec son jeu de courroie, idéale pour aller avec les roues dentées dont je disposé déjà avec le pillage du projet des anciens IMA5. Je modéliserait et imprimerai en 3D rapidement un moyeu, pour combler le creux au centre de cette roue et faire une liaison axe/roue dentée (partie blanche sur la photo).

roue dentée


J'ai également pu récolter des axes en métal, lisses et filetés, et des boulons, dont je me savais pas encore à ce moment ce que l'allais en faire mais ce genre d’accessoire est toujours utile ! J'ai aussi pu récupérer pas mal de pièces d'un ancien projet du FAB, probablement abandonné et laissé "pour pièces". Je me suis donc vu augmenter mon stock de roulement à bille. Effectivement étant donné la spécificité de mon cahier des charges et la nécessité de limiter au maximum les frottements, ces RAB seront d'une grande utilité, quelque soit la solution finale choisie.

J'ai aussi modélisé une pièce permettant le raccord entre le goulot du pchi-pchit et le moteur. Cette pièce a été modélisée en quelques minutes, de part sa simplicité et aussi par le fait que je sois de plus en plus à l'aise avec ONSHAPE. M'être forcé à utilisé ce logiciel de conception au début, me fait gagner énormément de temps désormais.


Finalement, en cherchant un peu dans l'ancien PFE de la placeuse de composant CMS, j'ai également trouvé un très gros roulement à bille. Cette pièce allait me permettre de mettre mon objet en rotation, en limitant au maximum les frottements ! Je venais de trouver une nouvelle pièce du puzzle. Grâce à cette pièce, je peux limiter le couple induit par le poids de l'objet à scanner : l'effort demandé pour faire tourner l'objet sera moindre et négligeable devant le couple proposé par le NEMA 17. J'en profiterai pour coller, à l'aide d'une colle de contact, une des chutes de courroie récupérée au FAB. Ceci va permettre une rotation précise de l'objet. En effet, une rotation du moteur Nema 17 avec une petite poulie, va engendré une rotation plus petit du roulement à billes, bien plus gros. Je n'ai pas compté précisément le nombre de dents mais je dirais que pour une rotation complète de la partie externe du roulement à billes, il faut environ 7 rotations complètes de la roue dentée attaché au moteur. Nous avons ainsi un gain de précisions avec cette différence de taille de roue. Il est en effet, selon moi, plus judicieux de faire tourner l'engrenage extérieur pour gagner en rapport de rotation. Si je décidais de faire tourner l'engrenage central (en donc via encastrement l'objet à scanner, je serais un peu moins précis car le rapport de taille entre cette pièce et la roue collée au moteur serai proche de 1.

Remarque : finalement grâce à ce roulement à billes géant, je n'ai plus de liaison directe avec le moteur et mon support transparent sera plutôt une des deux hémisphère car plus grande et donc plus facilement rattachable à la partie externe du RàB.


J'ai ensuite aussi choisi de refaire l'intégralité des modèles pour la découpe laser en fichier DXF pour les découper. En quelques minutes mon fichier était fait et j'avais réalisé le travail sur lequel j'avais buté 3 jours la semaine précédente à cause de mon inexpérience et des erreurs d'interprétation de Trotec...

Ceci fait j'ai alors pu procéder à la découpe de mes pièces... ENFIN !

Voici les différentes pièces que j'ai pu dessiner sur ONSHAPE et ensuite découper :

- Un "modèle d'engrenage"

- un "simple disque" (j'explique un peu plus loin son intérêt)

- un "bras denté", permettant l'élévation de la caméra et entraîné par les engrenages cités précédement

- une "face latérale provisoire" de la structure mécanique globale

Selon Rodolphe, il est plus judicieux de collé deux "modèles d'engrenage" ensemble, et de rajouter de chaque coté de ceux ci un disque d'un diamètre un peu plus grand. La double épaisseur d'engrenage permet de conserver une certaine marge d'erreur (le bois étant un peu dilaté et ainsi pas totalement plat). Les deux disques latéraux quand à eux, servent de guide/tuteur, si le bras denté a tendance à vouloir sortir de l'engrenage (toujours à cause d'une planche "voilée"), alors les disques servent à empêcher un désencastrement.

structure globale

La colle à bois étant en "rupture de stock" au Fabricarium, j'ai donc pris un peu de mon temps pour aller en acheté. Désormais, je désignerai par le terme de "roue dentée", le collage des deux disque et de la double épaisseur d'engrenage.

piece découpées


Finalement après quelques minutes de collage, séchage et d'assemblage, je peux désormais voir à quoi ma structure pourrait ressembler.


C'est assez abstrait mais je pense que l'on comprend l'idée générale. Une caméra s'élève, attachée à chacune de ses extrémités à des bras dentés. Ces dernières sont entraînés par deux roues dentées, elles même entraînées, grâce à un système d'axe et de jeux de poulie/courroie, par un moteur. J'ai choisi de tester cette première méthode de structure en premier car elle possède un avantage non négligeable : tout le système alimentation/Electronique/moteur/courroie/etc... peut être concentré au même endroit (judicieusement, en dessous de l'axe des roues dentées). Ce qui évite de trop grandes longueur de fil. De plus tout ce système est au "sol" (j'entends par la à un niveau 0 sur l'axe z) et aucun déséquilibre n'est possible. Au contraire le poids améliore la stabilisation. La seconde structure mécanique, quant à elle, est certes un peu plus complexe en terme de gestion d'équilibre, de répartition des tractions de la caméras selon les extrémités, de longueurs de câbles et de gestion des frottements. J'ai donc décidé de commencer par la première méthode de structure.

NB : J'essaie tant bien que mal d'expliquer de manière concise ma démarche, de mon faible statut d'étudiant IMA. Je m'excuse par avance pour la non clarté de certains passages (il est difficile de d'écrire à l'écrit, un système mécanique). De plus certains termes mécaniques ne sont probablement pas tout à fait corrects, je m'excuse alors également auprès des mécaniciens qui pourrait lire ce wiki, et qui risquent de frôler une attaque à chacune de mes descriptions.

Semaine 10 : poursuite de l'élaboration de la structure mécanique, retour sur un peu d’électronique et une nouvelle formation machine

Cette semaine j'ai décidé de poursuivre ma structure mécanique, entamée les semaines précédentes. Ayant ma structure globale, il fallait que je découpe dans les faces latérales, une "gouttière" guidant les bras portant la Kinect. Pour ce faire j'ai utilisé les moyens du bord. J'ai tout posé à plat pour faire une vue d'ensemble. J'ai mis la roue dentée à l'endroit ou elle est censée être et j'y ait fait glisser le bras petit à petit pour maintenir la caméra dans le position que je souhaité. J'ai pris soin de dessiner à divers position les dernier grand de la roue, pour me souvenirs de leur position. J'ai ensuite percé un petit trou dans le bras pour y faire passer une mine de feutre. J'ai alors recommencé la procédure en respectant bien de passer par les positions sauvegardées la première fois. Le feutre traçant lui même ça trajectoire, j'avais au final une allure approximative de gouttière.


Une fois ceci réalisé, j'ai alors pris des mesures que j'ai tenté de faire les plus précises possible malgré la faible précision des tracés, afin de rester fidèle à la trajectoire voulue. Le relevé des mesures fut assez laborieux mais j'ai a la fin tout de même obtenu un résultat correct. Ma face latérale étant trop petite (j’avais sous estimé la taille de la gouttière) j'ai alors remodélisé une face de prototype pour faire des tests et éviter de regaspiller du bois.

gouttiere découpé


Malheureusement le bois étant voilé, la découpe de ma glissière fut non précise et la découpe censés être uniforme de 8mm de diamètre sur toute sa longueur ne l'était pas. L'axe ne coulissait pas régulièrement, voire même pas du tout à certains endroits... C'est à ce moment là que je compris que je devrais peut être me formé sur une des machine du second lieu, permettant de travailler sur du bois plus épais et donc plus rigide. J'y reviendrai quelques lignes plus bas. Je décide alors de laisser de côté le travail du bois pour cette semaine, j'y reviendrai plus tard.


Je me décide alors à travailler sur le support d'objet, celui qui sera mis en rotation avec un roulement à bille. Je rappelle que nous avions décidé qu'il soit transparent. La semaine précédente je m'étais dit qu'utiliser l'hémisphère transparente était la solution la plus adaptée (de par sa taille, permettant d'être assemblé à la partie externe du gros roulement à billes). Cependant il fallait que je le découpe. N'ayant aucun moyen de savoir la matière dont était faite cette pièce, j'ignorais si la découpeuse laser pouvait s'en charger. Rodolphe m'a dit que je pouvais tenter le coup tout de même. "Si ça ne convient pas, tu le saura tout de suite, il y aura de grosses flammes" me dira-t-il... AH ? Pas de souci alors ! rire sarcastique

Je décide alors de m'y risquer. C'est assez simple d'un point de vue dessin puisque c'est une simple rond (de diamètre égale à la partie externe du RàB) à découper. Cependant la découpe devant être extrêmement précise au sommet de l'hémisphère, sans aucun moyen de calibrer précisément la découpeuse laser en ce point précis, je dû y aller à tâtons. Après moult vérification j'étais quasi certain d'avoir placé le centre du cercle de découpe au sommet de l'hémisphère. Je lance ensuite la découpe. Pas de flammes. Une légère fumée, mais pas dramatique pour le filtre de la découpeuse laser.

découpe de la sphère


Cependant, la matière était un calvaire à découper. En effet, une fois le laser en mouvement, le plastique se découpait, puis fondait sous la chaleur engendré par le foyer du laser. Ainsi, le disque à découper, se ressoudait grossièrement en quelques secondes... J'ai dû faire une nombre de passages assez important (une vingtaines environ) pour que je vois enfin ce fameux disque tombé au centre de l'hémisphère. Le résultats n'est pas parfait, de part les nombreuses fontes causées par les multiples passages, mais ça fera l'affaire ! J'ai décidé de coller ma nouvelle pièce ainsi obtenue aux roulement à billes, vulgairement au pistolet à colle. Pourquoi ? Tout simplement parce que la rigidité me permettra de faire mes différents tests tout en étant détachable assez facilement en forçant un peu. Si j'y allé à la colle forte dès le début, une mauvaise mise à niveau ou un mauvais centrage aurait était irréversible.

Je décide ensuite de découpé un disque dans la plaque de plexiglas de la salle E302. En effet, l'hémisphère ainsi obtenue était cause et il me fallait un plateau pour poser l'objet au dessus. J'en profiterais pour découper un second disque un peu plus petit, au cas où pour une raison ou une autre je décidais de troquer mon hémisphère contre le verre ou le récipient du pchipchit ou contre tout objet transparent nécessitant un disque de plexi plus petit. J'ai ensuite fixé le disque à l’hémisphère via une un boulon, liant une petite encoche de l'hémisphère au disque percé. C'est modulable, résistant et n'engendre pas de fixation irréversible.

ceci marque la fin de l'avancement de la partie mécanique de mon projet pour cette semaine.


Aussi je décide de m'attarder un peu sur la partie Electronique dont j'aurais besoin tôt ou tard pour le scanner. Je me suis donc remis à étudier le contrôleur moteur TB6560 3A dans le but de le faire fonctionner (je n'y était pas parvenu la fois dernière). Sachant que une des boutons poussoirs était endommagé, j'ai donc refait, proprement la soudure de ce dernier. Après plusieurs test et divers configurations, il ne fonctionnait toujours pas correctement... J'ai donc demandé de l'aide à Monsieur Boé. Mon aisance en électronique étant comparable à celle d'une huître, je me suis dit qu'il s'agissait sûrement d'une erreur bête de ma part. Le moeur ne présentait aucune résistance, comme si il n'était même pas alimenté. Nous avons donc tenté divers configuration, étudié le montage,.. (aussi attendu que l'alim se remette en route après que j'ai fait un magnifique court circuit après avoir voulue relevé une simple tension...) mais rien n'y faisait. Il y avait bien des PWM là où il devait y en avoir, etc...

Notre attention fut attiré vers un module ayant une chaleur bien trop importante pour être normale. Cette pièce était censé prendre une tension allant jusque 34 V et en sortir une de 5. En entrée nous avion bien environ 18 V, mais 0 en sortie. Alexandre Boé et Xavier Redon m'ont donc donné un nouveau module, similaire devant remplacer la pièce que nous pensions défectueuse. Sur leurs conseils, je vais donc gaiement voir Thierry Flamant pour lui demander si il ne peut pas faire quelque chose pour moi.

capa court circuitée


Il examina rapidement ma pièce et le contrôleur moteur et me dit que "parfois, les pannes ne sont pas toujours là où on pense qu'elles sont". Le voilà muni de son multimètre, à examiner chacune des partie du TB6560. Et là, démonstration de son niveau en détection de pannes : en 30 secondes il repère une capacité donc les deux branches forment un court circuit, à cause d'une bavure de la soudure. Il rectifie ça ni une ni deux , et me dit d'aller de nouveau tester mon montage. Ça marche ! Sans aucun souci ! La pièce que nous pensions déflecteur et qui chauffait anormalement n'était en réalité qu'une conséquence de ce court circuit de capacité ! (A noter qu'avec un bouton poussoir cassé et une capa mal soudée, le contrôleur moteur n'avais pas vraiment décidé de me faciliter la tâche !) J'upload donc un code "bateau" pour vérifier le bon fonctionnement de l'ensemble : tout était parfait ! Voici le code en question m'ayant servi à mettre en rotation les moteurs comme sur la vidéo qui suit, preuve du bon fonctionnement de l'ensemble :

// définitions des entrées sorties sur l'arduino
const int stepPin = 5;
const int dirPin = 2;
const int enPin = 8;

void setup() {
pinMode(stepPin,OUTPUT);
pinMode(dirPin,OUTPUT);
pinMode(enPin,OUTPUT);
digitalWrite(enPin,LOW);
}

void loop() {
  digitalWrite(dirPin,HIGH); // autorise le moteur à tourner
  for(int x = 0; x < 800; x++) {
    digitalWrite(stepPin,HIGH);
    delayMicroseconds(500);
    digitalWrite(stepPin,LOW);
    delayMicroseconds(500);
  }
  delay(1000); // wait 1 second
  digitalWrite(dirPin,LOW); //changement de sens de rotation
  for(int x = 0; x < 800; x++) {
    digitalWrite(stepPin,HIGH);
    delayMicroseconds(500);
    digitalWrite(stepPin,LOW);
    delayMicroseconds(500);
   }
  delay(1000);
}


[nom du module qui prend du jusque 34 v et sort du 5] [photo soudure / carte elect schema/ module qu'on pensait defectueux / sa datasheet] [vidéo des moteurs qui turne]


Enfin, étant confronté à certaines limites de la découpeuse laser, comme le fait de devoir collé des pièces entre elles car trop peu épaisses (pour rappel, la découpeuse laser à une utilisation conseillée ne dépassant pas 5 mm d'épaisseur pour du bois). Cette faible épaisseur engendre aussi au bois, une tendance à se bonder. Ce qui ne m'arrange pas du tout.

Aussi, j'ai alors décidé de suivre une formation Fabricarium de 2 heures sur une autre machine, disponible au 2nd lieu (nom du 2ème Fabricarium, au rdc du batiment B) : la SHOPBOT.

Pour faire simple, cette machine fait comme la découpeuse laser mais avec une fraiseuse et non une technologie laser. Ceci a pour inconvénient d'être bien moins précis (0.01 millimètre en théorie mais face à l'usure de la fraise et au bavures dues à la réaction du bois, nous avons plus une certitudes de précision de l'ordre de 0.1 mm, pas plus). L'avantage en revanche c'est quelle nous permet de travaille sur des surface de bois beaucoup plus grande en longueur et largeur (environ 2m * 1.5m contre 1.1m * 0.6m pour la découpeuse laser) mais surtout en épaisseur (la taille du foret, soit environ 20 cm, contre 5 mm pour la découpeuse du FAB). Inutile de préciser que, par le manque de système de sécurité, et par l'aspect "découvert" de la ShopBot, la découpe est bien plus dangereuse que pour sa sœur du Fabricarium.

Cela nous permet de travailler sur un bois plus épais, plus résistant et ainsi ayant subit moins de déformations, problématiques dans la cadre d’engrenages et de gouttières comme c'est mon cas. De plus, nous avons ainsi la possibilité de creuser et ainsi faire bien plus facilement certains modèles complexes, qu'avec la découpeuse laser qui nécessite beaucoup de collages.

De plus la modélisation des fichiers de découpes peut se faire sur ONSHAPE également ! Le fichier doit être vectorisé également mais ne contient pas de jeu de couleurs comme sur la Trotec. Le fichier doit être rendu en .DXF de préférence (le SVG n'est d'ailleurs pas accepté, ce qui est assez surprenant étant donné que c'est un format de fichier vectorisé très répandu). Le temps de modélisation et de dessin est donc le même que pour la petite sœur de la SHOPBOT. En revanche, ensuite, c'est chacune des formes distinctives qui doit être paramétré selon la découpe souhaitée. La préparation à la découpe est donc plus longue et plus minutieuse. La découpe est très rapide bien qu'évidemment un peu plus chronophage qu'avec la technologie laser. Le résultats est très satisfaisant ! Présentant lui aussi cses limites bien entendu, mais ce sera amplement suffisant pour ce que je souhaite en faire !

[photo shopbot]

Cette formation me servira sans doute à la fin de mon projet, lorsque j'en aurais fini avec les prototype et que je souhaitrais une version finale rigide et que je saurai fonctionnelle. Ainsi, la formation est faite et je pourrais disposer de la SHOPBOT quand bon me semblera. De plus, étant le seul IMA formé sur cette machine, je pourrais éventuellement dépanner certains camarades nécessitant une découpe spécifique pour leur projets respectifs.

Semaine 11 : tentative de eagle, beaucoup de wiki et enfin la solution !

Cette semaine un fois de plus je me suis chargé de mettre à jour mon wiki. Beaucoup de donnée mis en ligne pour une bonne prise de recul sur mon projet !

découverte de eagle avec mes composants
tentative peu fructueuse

Ensuite j'ai d'abord tenté une création de PCB pour mon scanner avec capteurs de mesure de distance. J'y ai passé pas mal de temps car je cherchais avant tout à apprendre à maîtriser le logiciel Eagle. Ayant déjà un peu d'expérience sur Altium, je souhaitais maîtriser un nouveau software. Tout comme je m'étais forcé à le faire avec Onshape à la place de solidworks en début de projet pour la modélisation 3D. Eagle possède un atout : la grande variété de ces librairies qui permettent une importation rapide des composants. Encore faut-il les trouver et être sûrs qu'il s'agit là des bons composants et de leur bonne version ! J'ai ainsi pu commencer une ébauche de PCB notamment avec le schematics de mon arduino pro Micro ainsi que mes deux contrôleurs moteurs. Je ne me suis pas plus attardé que ça dessus, je reviendrais plus tard sur ce point. Effectivement, ne connaissant pas la version finale et les composants du scanner que je souhaite créer, je suis eu être en train de perdre mon temps pour une carte qui me sea inutile. Cependant cette petite séance de prise en main de Eagle m'a permis d'en découvrir les fondement et de me faire une première idée du logiciel.


La grosse avancée de cette semaine fut vendredi ! En effet, Madame Sophie Baranowski s'est proposé pour nous faire visiter une salle anéchoïque. Curieux, j'ai donc souhaité y participer. Quel rapport avec mon projet ? J'y viens ! Effectivement une fois sur place et la salle visité, madame Baranowski en à pofité pour nous faire visiter le labo annexe. Ce labo est spécialisé dans l'étude des ondes électromagnétiques. On y trouve plein de mécaniqmes parfois un peu farfelus, permettant d'études les ondes dans diverses configuration. Et là... une mécanisme présent dans un coin de la salle, visiblement à l'abandon, contenait exactement ce dont j'avais besoin ! Une système permettant de faire coulisser un capteur le long d'une arche en bois ! Eureka ! Autant dire que le reste de la visite ne fut pas forcément mon centre d'intérêt ! Je me suis empressé de regarder ce système avec attention pour en comprendre le principe. C'est d'une simplicité affligente mais il fallait y penser : 4 roulement à blles situé de par et d'autre de la structure en bois, permettent un coulissement à couple faibles. La voîlà ma solution à tous mes problèmes !


système présent en salle de CEM, "wagon" de roulement à billes
système présent en salle de CEM, structure globale


Ni une ni deux, je me suis alors empressé de dessiner chez moi ce qui pourrait être la version finale de mon projet ! Un moteur avec une roue cranté metterais en rotation un objet grâce à la courroie collé sur le roulement à billes. Et un autre moteur permettrais de mettre la caméra en mouvement le long d'une arche. Le tout était de savoir comment... en effet le modèle présent dans le laboratoire était prévu pour bouger manuellement, contrairement à moi, ou l'ensemble se doit d'être autonome et indépendant de toute intervention de l'utilisateur. J'ai alors songé à un moteur situé en haut de l'arc de cercle, mais trop de cables seront nécessaires et risquerait de venir perturbé le bon déplacement de la caméra. Pire encore, ceux ci pourrait pendre et être scanné par la kinect, ce qui fausserait totalement le résultat final... La semaine prochaine j'aurais un gros travail de test et de recherches à faire dessus. Je devrais certainement demander conseil à des membres du Fabricarium, ou à des professeurs, plus qualifiés que moi d'un point de vue mécanique.


[photo dessin de mon montage final, comment je le vois]

Semaine 12 : mise en attente capteur de mesure de distance, priorité de la structure méca pour la kinect !

J'ai décidé cette semaine de mettre de côté le scanner avec capteur de mesure de distance pour en privilégier celui avec la kinect. En effet, dans un premier temps, n’ayant pas la bonne connectique pour le capteur, j’ai passer un long moment à bricoler un système de jumper que je pensais viable mais qui n'envoyait aucune donnée logique. Aussi, et surtout, je savais, de part l’existence de modèle similaire sur le net, que ce système était assez peu précis et qu’il ne permettait pas un scan complet de l’objet. En effet,la non prise en compte de la vue du dessus engendrait un manque de données non négligeable. Par exemple, un bol serait scanné de la même manière qu’un hémisphère inférieur plein. A cela, s’ajoute le fait que je prends réellement conscience de la quantité de travail qu’il me reste. N'avançant pas aussi vite que prévu, je comprend que je serai tôt ou tard contraint de faire un choix entre un des deux types de scanner. Comme des modèles de ce type existent déjà sur internet, il y a beaucoup de ressources disponibles et je reste toujours autant animé par l’envie de créer quelque chose de nouveau, qui n’existe pas encore. Ce qui est difficile étant donné l’explosion de ces types de scanners récemment. De plus, je pense avoir trouvé ce qui se rapproche le plus de ma version finale du scanner utilisant une kinect, de part le déblocage de la zone obscure sur la réalisation du système mécanique. Prenant en compte tous les paramètres cités précédemment, j’ai alors choisi de privilégier momentanément le scanner utilisant la KINECT et de revenir plus tard sur le modèle via capteur de mesure de distance.


validation partie meca par rodoplhe, dessin fait, piece leroy merlin achetée... y a plus qu'à ! on va modéliser les différentes pieces, faire inventaire et let's go !

dessin fait avec tim au fab

impression en filaflex

modélisation tim couroie

il faut modéliser découpe bois shopbot assemblage pc 2e scanner code 2eme scanner

collage courroie apres en avoir parlé a alexandre boé

Semaine 13 : une découpe laborieuse à la shopbot ...

Pour être tout à fait honnête, cette semaine ne fut pas la plus glorieuse. En effet, ayant eu jusqu'à présent pas mal de réussite dans mes recherches et mes tests, cette semaine m'a rappelé



probleme decoupe shopbot trp petit mais pas d'autrew crenaux alors on fera avec

Semaine 14

Cette semaine étant précédé de celles des vacances ainsi qui suivi par la semaine des soutenances, sans oublié le fait qu'elle est parsemé de jour férié, j'ai pu avancé énormément et finalisé la partie mécanique.

Bien que conscient dès le départ de la tâche qui m’était demandé, j’ai clairement sous estimé la partie mécanique du projet.

L’idée de base est pourtant simple. Faire élever un objet le long d’un rail. Bien plus dur à concevoir qu’il n’y paraît, d’autant plus quand on y ajoute la quantité de contraintes imposée par les limites de la caméra et de skanect. L’arche L’arche devant être extrêmement précise et uniforme, tout en ayant un certaine rigidité, il était essentiel de passer par la shopbot. Une version plus élaborée que celle actuelle aurait dû être découpée mais plusieurs imprévus cumulés (évoqués un peu plus loin dans le rapport), ont conduit à un modèle très prototypé, comme celui présent actuellement. Le rail Le rail élévateur de caméra fut sans doute la partie la plus délicate. Il fallait un système rigide, capable de maintenir une caméra de plusieurs centaines de grammes, tout en étant le plus léger possible afin d'éviter de demander trop de couple au moteur NEMA. Pour ce faire, j’ai utilisé une partie en bois de peuplier, rigide et léger, découpée à la découpeuse laser ainsi que des pièces en alu, plus légères que l’acier.

Il fallait que cette partie ne génère que très peu de frottement sur l’arche pour effectuer un mouvement fluide et précis pour la stabilité de la caméra. C’est pourquoi le choix des roulements à billes était selon moi le plus judicieux et le plus approprié à la situation. Le système de courroie, roue, moteurs Cette part m’a également demandé mûres réflexions.Transmettre un mouvement sur une distance aussi grande, en prenant en compte l’accumulation de tous les différents jeux, etc… La courroie de récupération d’un ancien PFE, raffistolée, me paraissait être une solution intéressante pour limiter les dépenses. Le système de roulettes et de roues crantées également disponibles un peu partout au fabricarium m’ont donc fait choisir ce type de matériel. A noter que j’ai, une fois de plus, tenté d’utiliser les inconvénients du système à mon avantage. En effet, la courroie collée étant trop épaisse pour passer dans une des roulettes, je me suis arrangé pour que celle ci maintienne la caméra à quelques centimètres au dessus de la fin de course de la caméra. Ceci permet d’éviter un choc violent dû à la descente libre de la caméra dans le cas d’une coupure d'alimentation des moteurs lorsque la caméra est en élévation.

Le caisson de base Clairement, la partie la moins plaisante à faire puisque ne disposant pas de la shopbot durant les vacances ainsi que la semaine de jours fériés, j’ai dû réaliser tout ceci la main avec mes outils personnels. Pourtant, cette partie est essentielle puisqu’elle contient toute la partie électronique du projet, maintient les différentes pièces du projet ensemble, et fait contrepoids lors du déplacement de la caméra. Le résultat n’est pas très propre (évidemment incomparable avec la précision d’une shopbot ou d’une découpe laser) mais m’aura au moins permis d’apprendre à me servir d’outils dont j’ignorais l’existence il y a encore quelques semaines ! Le support de plateau Partie inspirée du premier type de scanner, elle permet un scan sans détection de support de part son aspect translucide, ignoré par la caméra. L’addition de deux systèmes de roulement à bille assure la rotation en toute circonstance, avec un couple presque négligeable

j'en ai également profité pour rédiger le rappoert

Cette partie sera mieux rédigé dans le semaine.

Documents Rendus

Rapport de projet : File:P67_Dufresne.pdf

Fichiers : File:Dufresne_p67.zip ‎