Version du 8 avril 2018 à 16:26

Présentation générale

• Nom du projet : Automatisation de l'assemblage de Lego

• Résumé : Le but de notre projet est de recycler une imprimante 3D de façon à ce qu'elle assemble des Lego selon un modèle dessiné par l'utilisateur sur une application web.

• Etudiants : Justine SENELLART et Eloi ZALCZER

Description

Le projet sera composé d'une imprimante 3D associée à un réservoir. Il fonctionnera avec une application web nous permettant de dessiné le modèle que l'on désire.

• Imprimante 3D

Il nous faudra modifier la tête d'impression de l'imprimante pour qu'elle puisse récupérer les pièces de Lego et les déposer sur la plaque. Il nous faudra étudier le Gcode de l'imprimante et voir si on peut l'adapter à notre application.

• Application web

L'application web sera séparée en deux parties:

• • Une partie permettant à l'utilisateur de dessiner le modèle qu'il désire réaliser
  • Une partie permettant à l'utilisateur de renseigner les pièces présentes dans le réservoir (position, couleur, quantité...)

Objectifs

On peut décomposer le projet en plusieurs partie:

Partie mécanique

• Adaptation d'une base d'imprimante 3D
• Réalisation d'un réservoir pour les pièces de Lego

Partie électronique

• Utilisation d'un Arduino pour gérer l'imprimante 3D

Partie informatique

• Réalisation d'une application web
• Etude et possible modification du gcode de l'imprimante 3D
• Réalisation d'une application pour gérer le remplissage du réservoir

Analyse du projet

Positionnement par rapport à l'existant

Notre projet possède assez peu de concurrents, la majorité d'entre eux étant des réalisations personnelles trouvables sur YouTube. Pour l'élaboration de ce projet nous nous sommes inspiré du bricasso.

Analyse du premier concurrent

Une projet similaire au notre s'appelle Bricasso [1]. Il s'agit d'un projet réalisé en Lego Mindstorm EV3.

Cette imprimante scanne un dessin papier et l'imprime en LEGO en plaçant des pièces de couleurs correspondantes. Il possèdes beaucoup de limitations dont notre projet s’affranchira : impression uniquement en 2D, un seul type de pièces, absence de connectivité.

Cependant, ce projet contient de très bonnes idées dont nous allons nous inspirer, notamment pour la tête d’impression.

Analyse du second concurrent

Au niveau de l’application WEB, notre principal concurrent serait le logiciel Lego Digital Designer qui permet de créer en 3D des objets LEGO et de les exporter sous différents formats. Ce logiciel est très complet, cependant il ne contient pas toutes les fonctionnalités dont nous aurons besoin pour notre projet. Il permet d’utiliser toutes les pièces LEGO existantes alors que seules certaines seront utilisables dans notre projet. À terme, nous voulons essayer de mettre en place une compatibilité entre notre application et le logiciel, mais les formats d’export sont très mal documentés et ce sera difficile.

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

Justine, jeune elfe d’IMA4, souhaite construire des objets en LEGO pour les assembler en un robot. Elle souhaite concevoir ses LEGO en cours de réseau au lieu de travailler, mais ne dispose pas du matériel nécessaire. Une fois rentrée chez elle le soir, elle n’a pas le temps de s’en occuper car elle doit travailler son espagnol. Depuis n’importe quel ordinateur, Justine peut construire son modèle et l’enregistrer. Une fois rentrée chez elle, elle branche son imprimante LEGO et son objet se construit sans aucune intervention de sa part. Son imprimante ira chercher les pièces désirées (spécifiques à son modèle) dans le réservoir et va ensuite aller les placer sur la plaque LEGO servant de support. Le réservoir possédant 5 rails différents il est possible d'utiliser des pièces de 5 couleurs différentes. Le choix des pièces étant limité par la taille du réservoir on utilisera donc des pièces carrées LEGO 1x1.

Réponse aux questions difficiles

Comment démarrer l'imprimante à distance ?

L'impression pourra être déclenchée depuis l'application Web lorsque l'imprimante est allumée et connectée. Le processus d'impression sera divisé en plusieurs parties :

Avant ces étapes, un message est affiché à l'utilisateur pour lui rappeler de bien positionner la plaque d'impression. L'imprimante ne vérifie pas que la plaque est bien positionnée avant de lancer le processus. Si l'utilisateur valide cette étape, la processus continue.

• Connexion à l'imprimante : L'application tente de se connecter à l'Arduino de l'imprimante via Wifi. L'adresse IP de l'Arduino devra être renseignée par l'utilisateur mais pourra être enregistrée en préférences. Si la connexion échoue, un message d'erreur est affiché à l'utilisateur. Si la connexion réussit, l'impression se lance.

• Envoi des données : après la première connexion, l'application envoie les données du projet à l'Arduino.

• Impression : l'imprimante positionne la tête d'impression et lance le processus.

Comment sera calibrée la plaque d’impression ?

La plaque d'impression utilisée sera fournie avec l'imprimante. Il s'agira d'une plaque LEGO classique, ses dimensions seront donc parfaitement connues. Si l'utilisateur décide de créer un projet de dimensions inférieures dans l'application web, le coin de la plaque sera utilisé.

Étant donné que la plaque sur laquelle sera "imprimé" l'objet fait partie de l'objet il nous faut trouver un moyen pour qu'elle soit toujours à la bonne position. Nous avons pensé à réaliser un coin contre lequel un des coin de la plaque sera bloqué (comme sur un massicot pour bloquer les feuilles de papiers). L'utilisateur devra s'assurer que la plaque est dans le bon sens et qu'elle repose bien contre le coin.

Comment la plaque va se fixer sur le sol ?

Il nous faut un système qui permette de récupérer et d'installer la plaque facilement tout en s'assurant qu'elle reste en place lors de l'utilisation de l'imprimante. On pourra donc utiliser un système d'aimants en en mettant à chaque coin et au milieu de la plaque pour qu'elle reste fixée durant l'utilisation et que l'utilisateur puisse l'enlever une fois le projet terminé.

Préparation du projet

Cahier des charges

Le projet est séparé en deux parties principales : l'application Web qui permettra de créer le modèle, le sauvegarder, et l'envoyer vers l'imprimante, et l'imprimante elle-même. Les cahiers des charges de ces deux parties sont très différents et nous permettent d'aborder de nombreux aspects de la formation IMA. La liaison entre les deux se fera via un protocole qui sera précisé plus tard, grâce à un Raspberry Pi connecté à l'Arduino Mega de l'imprimante. Nous aurions voulu utiliser un module Wifi pour Arduino, cependant le bouclier contrôleur moteur ne nous permet pas d'en utiliser un.

Application Web

L'application Web fonctionne en Cloud, sur un principe proche de Google Drive. Les projets sont sauvegardés sur une base de données centralisée et accessible depuis n'importe où via un login. Une fois créés, les projets peuvent être envoyés en local vers l'imprimante.

• Partie Frontend
  • Proposer une interface paramétrable de création du modèle, en trois dimensions. Cette interface doit permettre de placer les pièces selon des règles de placement adaptées, de les faire tourner et les supprimer.
  • Gérer les différents types et couleurs de pièces possibles.
  • Permettre d'envoyer le modèle créé vers l'imprimante via un protocole à définir.
  • Permettre de créer un nouveau projet, ouvrir un projet existant, supprimer un projet.
  • Permettre à l'utilisateur de s'authentifier (optionnel).

• Partie Backend
  • Mettre en place une base de données permettant de gérer les projets.
  • Mettre en place une base de données permettant de gérer les utilisateurs.
  • Proposer une API facilement utilisable par l'application, en tirant parti des différentes méthodes HTTP et en utilisant les bons codes de retour.

Choix techniques : matériel et logiciel

Choix matériel

Réutilisation d'une imprimante 3D Prusa i3 [2].

Réservoir

• Réalisation d'un "toboggan" en polystyrène
  
• Une face en plexiglas pour vérifier le remplissage

prototype de tête d'impression

Tête d'impression

• Dans un premier temps elle sera réalisée en Lego pour la modularité
  
• La version finale pourra être réalisée en impression 3D

Plaque d'impression

• La plaque d'impression sera une plaque Lego
  
• Elle sera maintenu avec des aimants
  
• Le coin de calibrage pourra être réalisé en plexiglas ou en bois

Informatique

• Arduino Mega pour contrôler l'imprimante
• Raspberry Pi3 pour le serveur
• ESP8266 pour la communication entre le serveur et l'Arduino

Choix logiciel

L'architecture choisie pour l'application web est basée sur trois éléments : l'utilisateur, le serveur de sauvegarde et l'imprimante. Nous avons jugé essentiel d'utiliser un serveur de sauvegarde sur un modèle type Google Drive, car un des intérêts du projet est de pouvoir concevoir son modèle depuis n'importe où. Ce serveur sera donc accessible en ligne à tout moment via un système de connexion. Depuis cette application web, l'utilisateur aura la possibilité de se connecter à son imprimante en fournissant son adresse IP. Les données seront alors transmises sous forme d'un paquet POST ou JSON. A la réception du paquet, l'imprimante lancera l'impression de l'objet.

Backend

• Node.js : API RESTful
  
• PostgreSQL : Base de données projets et utilisateurs

Frontend

• HTML5/CSS3/JS
  
• Utilisation de la balise canvas pour la conception du schéma.

Arduino

• (provisoire)
• Utilisation du logiciel Marlin pour le contrôle de l'imprimante [3]

• Réutilisation de la base du projet [4]

• Base de l'imprimante [5]

Liste des tâches à effectuer

Adaptation de l'imprimante 3D

Pour notre projet, il est nécessaire d'adapter l'imprimante 3D pour qu'elle puisse effectuer les tâches nécessaires. Le bras de l'imprimante bouge selon les axes x et z et le plateau de l'imprimante selon l'axe y.

Plateau de l'imprimante

Le plateau actuel est une planche de bois de 22*22cm et d'une épaisseur de 0,5cm. Cette surface correspond à toute la surface que la tête d'impression peut atteindre. Il nous faut donc agrandir ce plateau pour pouvoir y mettre le réservoir de pièces. On doit donc couper un rectangle d'environ 22*30cm en bois pour le nouveau plateau de l'imprimante.

Réservoir de pièces

schéma d'un rail réservoir

Ce dessin représente un rail du réservoir. Chaque rail peut recevoir une quinzaine de pièces d'un type précis. On va donc réaliser un réservoir pouvant recevoir 6 types de pièces donc contenant 6 rails. Les pièces que nous allons utiliser pour notre projet sont des pièces de Lego 1x1 qui mesurent 0,8*0,8cm.

Tête d'impression

La tête en Lego n'étant pas très solide, il est plus judicieux de la réaliser en impression 3D. Cependant notre tête à besoin d'une articulation pour "lâcher" les pièces il nous faut donc trouver un moyen de réaliser cette articulation en impression 3D.

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

Prologue

Nous avons commencé la partie développement web largement en amont, pour être sûrs que ce ne soit pas un facteur limitant à notre avancée. Nous avons commencé par la partie Front End, avec la programmation de l'application de modélisation. Celle-ci se présente sous la forme d'un canvas 2d, quadrillé comme une plaque LEGO, et d'un certain nombre de boutons.

Afin de modéliser une utilisation réaliste, nous avons effectué certains choix pour le prototype de l'application.

• Trois types de pièces disponibles (1x1, 1x2, 2x2)
• Nombre de calques paramétrable, dimensions max 20x20x5
• Coloration des pièces en fonction de leur calque

Les fonctionnalités déjà réalisées lors du début du projet étaient :

• Placement et suppression de pièces
• Rotation des pièces
• Changement de calque
• Règles de placement basiques

Semaine 1

Application Web

Lors de la première semaine, nous avons commencé la partie communication de l'application web. Du côté Back End, nous avons établi une première version élémentaire de l'API RESTful, capable de recevoir et répondre des messages simples à des requêtes HTTP. Nous avons réussi à mettre en place la communication entre l'application et le serveur, et à transmettre les données de toutes les pièces en JSON. Plus tard dans la semaine, nous avons implémenté la majorité des fonctionnalités de l'API et mis en place la base de données sur le Raspberry Pi. A la fin de la première semaine, nous étions en mesure de charger la liste des pièces depuis la BDD, charger la liste des projets et sauvegarder un projet. Du côté Front End, nous avons avancé sur le protocole d'envoi des données vers l'imprimante. Pour commencer, nous avons formaté les données sous un simple format URL-encoded. A terme, l'objectif est de les envoyer également en JSON pour plus de simplicité et de clarté. Un problème que nous allons devoir réussir à contourner est la contrainte CORS de même origine pour les requêtes HTTP, qui risque de nous empêcher d'envoyer des requêtes à l'imprimante. Nous réussirons peut-être à nous affranchir de cette contrainte en configurant correctement l'imprimante.

Imprimante 3D

état de l'imprimante 3D

Cette première semaine a été dédié à tester l'imprimante 3D que nous avons récupéré d'un ancien projet et à la remettre en état. En effet, l'imprimante que nous allons utiliser n'a pas été terminé par ses précédents utilisateurs: certaines pièces ne sont pas ou mal fixées et la courroie de l'axe x n'est pas correctement tendue. Nous avons donc lu le wiki du projet de l'imprimante à chocolat pour voir comment fonctionne l'imprimante et nous l'avons testé en remettant l'imprimante en position initiale. On constate donc que les 4 moteurs et les 3 capteurs de fin de course fonctionnent correctement cependant, le capteur de fin de course de l'axe z est mal fixé et mal positionné: la pièce ne l'actionne pas et le fait descendre en même temps qu'elle descend. Une fois que nous étions assurés que l'imprimante fonctionnait correctement, nous avons commencé à nous occuper de la partie mécanique en elle même en fixant des pièces non fixées notamment le plateau d'impression et en retendant la courroie qui est actuellement maintenue avec du scotch. Il nous reste donc à trouver une solution plus solide pour la courroie, un moyen pour fixer le capteur de fin de course de l'axe x et à fixer quelques pièces.

De plus, nous avons commencé à réfléchir à comment modifié cette imprimante pour l'adapter à notre projet: notre problème est de savoir où l'on pourra positionner le réservoir pour que l'imprimante puisse aller chercher les pièces. Nous avions prévu de le mettre sur le côté de l'imprimante cependant il ne sera pas possible d'utiliser cette disposition car l'axe x est trop petit et le "bras" ne pourra pas l'atteindre. Une autre solution est d'agrandir le plateau de l'imprimante pour installer le réservoir dessus il faudra donc faire attention à sa taille et son positionnement. Cette solution réduira l'espace disponible pour monter les Lego car il faut tout de même positionner le réservoir de manière à ce que le bras puisse l'atteindre. Et il nous faut aussi trouver un moyen de fixer notre "tête d'impression".

Semaine 2

Application Web

Durant la seconde semaine, nous nous sommes concentrés sur la partie Backend de l'application. Après avoir établi une première version de l'API, la plus grande partie de la séance de mercredi a été dédiée à du débug et de l'harmonisation de données. A la fin de cette séance, toutes les fonctionnalités marchaient, avec une erreur subsistant sur le chargement de projets. Cette erreur était due à un aspect du MCD que nous avions oublié mais a été réglée rapidement en fin de semaine. L'aspect backend opérationnel, nous avons ensuite pu nous concentrer sur le cahier des charges de l'application (règles de placement, types de pièces, gestion des couleurs, gestion du réservoir, gestion des utilisateurs...).

Partie mécanique

Durant cette séance, nous avons recherché les fichiers .stl permettant d'imprimer les pièces nécessaires à la finalisation de l'imprimante 3D. Les clips permettant de tenir la courroie de l'axe x ont été imprimés par M. Redon. Nous nous sommes ensuite intéressé au réservoir de pièces: dans un premier temps nous avons pris les mesures nécessaires pour sa construction : taille du plateau et taille des pièces Lego. Nous avons ensuite réaliser un dessin à l'échelle 1:1 de manière à visualiser plus facilement le travail à effectuer sur le réservoir.

Semaine 3

Application Web

L'objectif de la seconde semaine était de finir de débuguer les sauvegardes/ouvertures de projets, puis de travailler sur le frontend et notamment les règles de placement des pièces. A la fin de la séance de mercredi, il restait encore un problème de sauvegarde sur les pièces non carrées, mais le reste fonctionnait correctement. Le même problème était présent sur les règles de placement car il s'agit d'une mauvaise représentation des coordonnées de la pièce, qui sont gérées par une seule fonction. Plusieurs solutions s'offrent à nous pour régler ce problème, parmi lesquelles nous devront choisir. La plus simple serait simplement d'imposer une rotation de la pièce en fonction de son orientation, ce qui ne correspondrait pas au système de coordonnées utilisé mais devrait fonctionner. La plus compliquée consisterait à reprendre la globalité du système de coordonnées du projet. Par ailleurs, les règles de placement ont été nettement améliorées. Nous avons également implémenté un effet de transparence sur les calques de niveau supérieur au calque en édition, qui permet de mieux visualiser le projet.

Partie mécanique

Durant cette semaine, nous nous sommes concentré sur le "toboggan" à pièce. Dans un premier temps, nous avons réalisé un schéma ainsi qu'une maquette en carton de la pièce de manière à mieux la visualiser. Suite à une discussion avec M. Redon nous avons décider de réaliser en impression 3D. Nous avons donc réalisé la modélisation 3D de la pièce pour qu'il puisse l'imprimer.

conception 3D du réservoir

Semaine 4

Application Web

Cette semaine a été l'occasion de continuer à débugger le projet, et de refaire certaines parties qui avaient été trop vite passées en début de projet. Une bonne partie du code fonctionnel a été réécrite pour factoriser plus les tâches et optimiser l'exécution. En outre, nous nous sommes rendus compte que notre projet risquait de présenter des problèmes d'optimisation pour des projets comportant plusieurs dizaines ou centaines de pièces. En effet, en mode suppression, nous sommes obligés de parcourir le tableau des pièces à chaque déplacement de souris pour placer correctement le masque indicateur de suppression. La première optimisation que nous avons ajoutée à cette partie est de considérer uniquement les pièces ayant une distance inférieure ou égale à 4 cases de la pièce, la taille maximale d'une pièce étant de 2 cases. Cependant, nous sommes obligés de parcourir la totalité du tableau car ce dernier n'est pas trié. Nous avons alors envisagé d'autres structures de données, mais aucune ne semble vraiment donner de meilleur résultat à l'exception d'un tableau à double entrée, mais dont le gain serait probablement très faible. La meilleure solution semble donc d'essayer d'alléger le fonctionnel au plus possible, ce qui sera un objectif de la semaine prochaine. Pour parfaire les règles de placement des pièces, qui sont pour l'instant complètement buguées, il nous faudra également un moyen efficace de parcourir le tableau et d'effectuer des vérifications sur les pièces.

Nous avons commencé (certes trop tard) à mettre par écrit les choix d'implémentation de l'application, ce qui nous permettra de gagner du temps à l'avenir. Une fois l'application de base totalement fonctionnelle, soit après l'implémentation des nouvelles règles de placement, nous pourrons nous attaquer aux nouvelles étapes de développement que sont la gestion des couleurs et du réservoir. Il y aura probablement dans les prochaines semaines une partie d'étude technologique pour l'implémentation du serveur d'impression sur la Raspberry Pi.

Partie mécanique

Pièce en 1 bloc

Pièce en 2 blocs

Il a fallut effectuer des modifications sur le réservoir qui n'avait pas le comportement attendu. De plus, nous avons effectué les modélisations 3D de deux systèmes différents pour réaliser la tête de déplacement des pièces. Le problème est de savoir comment réaliser l'articulation qui permettra à la pièce de se plier afin que les pièces. Suite à une discussion avec M.Boé et M.Redon deux méthodes ont été retenues: un système en un bloc avec une articulation faite à partir d'un cylindre évidé avec à l'intérieur un autre cylindre et un système en deux parties dont le mouvement aura lieu autour d'une vis.

Semaine 5

Partie Informatique

La principale avancée de la partie informatique lors de cette semaine a été l'implémentation de la gestion des couleurs. Jusqu'à maintenant, pour faciliter le debug, les couleur des pièces dépendait de leur position en z. Une pièce située sur le calque 0 était nécessairement rouge, verte sur le calque 1, bleue sur le calque 2 etc... Dans la version finale de l'application, l'utilisateur doit bien entendu pouvoir choisir la couleur de chacune des pièces qu'il place pour créer le design de son choix.

Deux solutions s'offraient à nous : la première était de construire une base de données de couleurs située sur le serveur, la seconde était d'appeler systématiquement une des nombreuses API LEGO en ligne. Pour des raisons de légèreté et de simplicité, nous avons opté pour la première solution. Néanmoins, pour construire notre base de données, nous avons utilisé un fichier JSON obtenu depuis l'API Rebrickable, que nous avons ensuite parsé grâce à un script Python. Nous nous sommes retrouvés avec une liste de plus de 120 références de couleurs, que nous avons jugée trop importante pour des raisons évidentes (le choix se fait par un menu déroulant...). Nous avons donc réduit la liste à une sélection de 16 couleurs que nous avons jugées les plus élémentaires. Une fois la base de données construite, nous avons du construire le service sur l'API permettant de récupérer la liste des couleurs, et établir la gestion des codes couleur HTML. Nous voulions à priori les stocker sous forme d'entiers, mais pour des raisons de simplicité nous avons fini par utiliser des champs varchar. Enfin, la gestion des couleurs dans la partie frontend n'a pas été longue à implémenter car la couleur n'a aucune influence sur l'état d'une pièce ou sur quelconque autre fonction.

Le reste de cette semaine a été consacré à du débug, et différents essais. Nous avons pas exemple envisagé d'implémenter un système de undo/redo, mais une fois la gestion des raccourcis clavier implémentée, nous nous sommes rendus compte que ce n'était pas prioritaire et avons mis l'idée en pause.

Partie Mécanique

Suite à l'impression de la tête de déplacement des pièces ainsi que du réservoir, nous avons effectué des tests à la main pour nous assurer du bon fonctionnement de ces derniers. Nous avons ensuite préparé le dessin de découpe de la nouvelle plaque de l'imprimante pour pouvoir installer le réservoir dessus. Pour cela, nous avons remplacé le plateau actuel par une plaque de carton puis en fixant un crayon à la place de la tête d'impression, nous avons "dessiner" la zone atteignable par celle-ci. Suite à ça, nous nous sommes aperçu que les clips qui permettent de maintenir la courroie empêchent la tête de parcourir tout l'axe x. Il nous faut donc soit refaire des clips, soit refaire un support de pour le capteur de fin de course qui ne peut plus être atteint.

Semaine 6

Partie Informatique

La suite logique de l'implémentation des couleurs est la gestion du réservoir de pièces. En effet, maintenant que l'utilisateur peut choisir la couleur de ses pièces dans l'application, il doit pouvoir utiliser les pièces physiques de son choix et renseigner leur position dans le réservoir pour que l'imprimante sache où aller les chercher. La gestion du réservoir est une partie importante du développement, et nous n'avons fait que commencer cette semaine. En effet, nous nous sommes retrouvés confrontés à un problème qui nous a pris quelque temps à résoudre.

Pour que l'utilisateur puisse renseigner la position de ses pièces, il nous fallait construire une liste des pièces uniques présentes dans le projet. Les pièces sont caractérisées par plusieurs paramètres : leur taille en x, leur taille en y et leur couleur. Nous avons trouvé facilement plusieurs méthodes, à base d'un tableau de doublons intermédiaire, permettant d'extraire les éléments uniques d'un tableau, cependant ces méthodes ne fonctionnaient qu'avec une seule variable (qui servait de valeur clé dans le tableau intermédiaire). Cette solution ne convenait donc pas à notre projet. Nous avons alors tenté la même approche avec des objets, en définissant un nouvel objet par pièce et en vérifiant si l'objet était déjà présent dans le tableau de doublons. Cependant, cette solution ne fonctionne pas à cause du principe même de la programmation orientée objet : deux objets ayant les mêmes valeurs ne sont pas le même objet pour autant. Après plusieurs tentatives, la solution la plus simple que nous avons trouvée est d'appeler une méthode JSON.stringify sur chaque objet pièce, et de construire un tableau de doublons avec les chaînes de caractères ainsi obtenues. Ainsi, nous pouvions comparer les pièces avec une méthode native javascript comme Array.has().

Ce problème réglé, il reste à développer le frontend pour permettre à l'utilisateur de renseigner la position de chaque pièce, puis à générer la requête qui sera envoyée à l'imprimante. Une fois que ces étapes seront finies, il ne restera que l'amélioration des règles de placement à implémenter dans l'application web et nous pourrons attaquer le côté imprimante.

Partie Mécanique

Pour pouvoir fixer le réservoir sur la base de l'imprimante il nous faut un plateau de 30cm*22cm. Nous avons donc été au Fabricarium pour découper notre nouveau plateau dans du contreplaqué de 5mm d'épaisseur. Une fois la base imprimée il nous a fallu trouver un nouveau moyen pour la fixer à l'imprimante : les vis utilisées précédemment ont été sciées et l'une d'entre elle ne rentrait plus dans les écrous. Maintenant que la base de l'imprimante est prête nous avons préparé la découpe de la plaque Lego qui servira de base à l'objet créé.

Semaine 7

Partie Informatique

L'application Web étant à peu près fonctionnelle, nous avons décidé de nous attaquer au serveur d'impression. Suite à une discussion avec les tuteurs de projet, nous avons choisi d'utiliser également Node.js pour le serveur et la génération du G-Code. Le serveur tournera sur une Raspberry (probablement la même que l'autre serveur pour les tests) qui communiquera avec l'Arduino via le port série. La première étape de ce travail a consisté à générer les données envoyées via HTTP par l'application Web au serveur. Ces données sont générées dans le fichier print.js grâce à des méthodes urlencode fournies par Javascript. Une fois les données générées, ces dernières sont envoyées via XMLHttpRequest (XHR), pour le moment à une adresse IP factice. La fenêtre d'impression permettra à l'avenir de rentrer l'adresse IP de l'imprimante, qui sera par défaut égale à l'adresse IP du serveur de l'application.

Nous avons donc créé un second serveur dans le répertoire printer_serveur. Ce dernier implémente uniquement le framework Express pour la gestion des requêtes POST, et un fichier gcode.js pour la génération du G-Code. Ce dernier est généré par la fonction generate. Son fonctionnement est simple : après une remise à zéro de la tête d'impression (code G28), le G-Code suit le même schéma pour chaque pièce à placer.

• Relever la tête d'impression de 2cm pour ne pas risquer de heurter le plateau ou une pièce déjà placée;
• Se déplacer à la position du réservoir souhaité;
• Descendre pour attraper la pièce, puis remonter;
• Se déplacer à la position de la pièce;
• Descendre puis avancer de 1cm dans la direction X pour lâcher la pièce.

Les valeurs de G-Code générées pour le moment sont arbitraires, et un des objectifs des séances prochaines sera d'effectuer une batterie de tests sur l'imprimante pour déterminer les bonnes valeurs de développement.

De plus, nous pensons finalement que la solution d'envoyer les données en URLEncoded est moins pratique que d'utiliser du JSON. Étant donné que nous utilisons Node.js pour le serveur d'impression, il est plus simple d'utiliser JSON comme pour les fonctions accédant l'API de notre application. Cette modification sera au programme de la séance prochaine.

Partie Mécanique

Support EndstopY

Support EndstopZ

Durant cette semaine nous avons découpé la plaque Lego qui nous servira de base au montage de la construction et nous avons réfléchi à une manière pour que la plaque reste stable sur la base en bois mais pour que l'on puisse toujours l'enlever facilement. Deux solutions sont possibles: réaliser des rails qui seront ensuite collés sur la base en bois ou graver la base de manière à enlever quelques millimètres de bois de la forme de la plaque.
Nous avons aussi réalisé les modélisations 3D des pièces permettant de maintenir les capteurs de fin de course de l'imprimante qui étaient jusqu'à présent fixés avec des zip.

Semaine 8

Partie Informatique

Il était prévu de profiter de cette semaine pour faire des essais sur l'imprimante 3D et vérifier la cohérence des valeurs de Gcode générées. Pour diverses raisons, nous avons décidé de décaler ces tests à la semaine suivante et de nous occuper plutôt de finir l'application. La semaine dernière en effet, les valeurs de Gcode étaient générées arbitrairement pour tester l'algorithme. Nous nous sommes donc occupés d'effectuer cette génération à partir du schéma entré par l'utilisateur dans l'application.

Comme prévu, nous avons modifié le fonctionnement de print.js pour transmettre les données en JSON plutôt qu'en URL-encoded. Cette partie en elle-même a posé plusieurs problèmes. Le premier était une simple erreur d'inattention sur l'en-tête du fichier qui causait une mauvaise réception. Le second était que la requête d'impression s'effectue sur une adresse différente de celle du serveur (port 4000 au lieu de 3000). Par défaut, les requêtes cross-origine ne sont pas autorisées. Il nous a donc fallu rajouter quelques lignes au code du serveur pour qu'il émette les bons en-têtes et autorise les requêtes CORS (Cross-Origin Resource Sharing). Une fois ces deux problèmes réglé, nous avons facilement pu générer le Gcode, et nous espérons pouvoir le tester rapidement.

Pour ce faire, en fin de séance, nous avons commencé à étudier le firmware Marlin en nous inspirant du projet cité plus haut. Grâce à leur Wiki, nous avons facilement pu comprendre le fonctionnement du firmware et les modifications à apporter. En fin de séance, nous avons voulu compiler mais un problème de librairie nous en a empêchés. Ce sera donc le premier objectif de la prochaine séance.

Partie Mécanique

Suite à l'impression des supports de capteur nous les avons placé sur l'imprimante et nous avons effectué des tests pour s'assurer que les différents éléments arrivent bien à actionner les capteurs. Durant ces tests nous nous sommes rendu compte que le support pour le capteur en x était trop épais et que le support de la tête d'impression ne n'atteint pas le capteur. Il nous a donc fallu limer le support de manière à ce que le capteur de fin de course puisse être actionné.
Suite à ça un des dissipateur thermique des contrôleurs moteur est tombé nous sommes donc parti voir Thierry Flamen de manière à trouver une solution pour que les dissipateurs thermiques restent en place: il a donc utilisé un scotch thermique double face et il a sécurisé le tout avec un fil de nylon noué avec un nœud de cabestan.

Semaine 9

Partie Informatique

Cette semaine a été l'occasion de mettre enfin en commun le partie mécanique et la partie informatique. Pour ce faire, nous avons décidé d'utiliser notre propre carte Arduino Mega afin de ne pas déprogrammer celle du projet original. Nous avons tenté de recompiler le Framework Marlin à partir du code du projet précédent, cependant un problème de librairies nous a empêchés de compiler. Nous avons alors décidé d'utiliser la dernière version de Marlin. Après avoir fait toutes les modifications de la configuration en prenant soin de bien réutiliser les mêmes valeurs, nous avons téléversé le code sur la carte Arduino.

Lorsque nous avons testé la carte ainsi programmée, l'écran de l'imprimante ne s'allumait pas. Avant de nous plonger dans une étude plus approfondie des paramètres de configuration, nous avons alors décidé d'utiliser la carte du projet original. L'objectif était alors d'envoyer un G-code par la liaison USB-Série afin de faire bouger l'imprimante. Nous avons testé divers G-Code, sans parvenir à faire bouger la tête d'impression. Cependant, la carte répondait à notre message par une série de codes de format <buffer XX XX XX XX .....>. Nous n'avons pas encore eu le temps de nous intéresser à la signification ni à la raison de ces messages, et ce sera un des objectifs de la séance prochaine. Plusieurs articles en ligne expliquent comment effectuer une impression depuis le port série, il ne devrait donc pas être trop difficile de trouver réponse à nos questions.

Par ailleurs, nous avons profité de la séance du lundi pour (enfin) débugger les règles de placement des pièces. Ces dernières sont maintenant parfaitement fonctionnelles pour les pièces de taille 1x1. Nous avons décidé d'abandonner pour le moment le support des autres pièces car elles ne seront de toute façon pas compatibles avec l'imprimante. Les modifications nécessaires de l'application devraient être faites dans la semaine prochaine.

Partie Mécanique

Nous avons réalisé les dessins des cales qui permettront de faire en sorte que le plateau et le réservoir soient toujours à la même place sur le support et qu'ils ne bougent pas lors de l'utilisation de l'imprimante. Une fois les dessins de découpe effectués, les cales ont été découpées dans du bois avec la découpeuse laser puis elles ont été fixées à la base de l'imprimante. Des tests de mouvement de l'imprimante ont été effectués pour s'assurer que tout reste correctement en place et qu'il n'y a pas de problème lorsque le réservoir est rempli.

Semaine 10

Partie Informatique

Durant cette semaine, nous n'avons pas apporté de modification à l'application Web : cette dernière est désormais à peu près fonctionnelle et nous avons préféré nous concentrer sur l'interface application/imprimante. Pour ce faire, nous avons repris à partir des problèmes que nous avions eus la semaine précédente avec Marlin. En premier lieu, nous avons réussi à recompiler le firmware utilisé par le projet d'il y a deux ans, et avons donc décidé d'utiliser cette version qui a l'avantage d'être plus légère (136 fichiers contre 279 pour la version la plus récente). En téléversant ce code sur notre propre carte Arduino Mega, nous avons déjà obtenu le premier signe rassurant : l'écran LCD s'allume et Marlin démarre correctement.

A force de recherches et de tests, nous avons réussi à identifier l'origine des différents problèmes de communication série que nous avions. Ces derniers étaient principalement dus à des erreurs de notre part liées à une mauvaise compréhension du système. Les données envoyées par l'imprimante étaient jusqu'à maintenant mal interprétées et nous n'avions pas imposé de délai avant l'envoi de la première commande, ce qui faisait que l'imprimante l'ignorait. Une fois ces erreurs corrigées, nous avons pu recevoir et afficher correctement les messages de démarrage de l'imprimante et ainsi mieux comprendre son fonctionnement.

Lors de son démarrage, le firmware Marlin envoie une série d'informations sur le port série par rapport à sa configuration, comme par exemple la taille du buffer ou le réglage du filament. Une fois toutes ces données envoyées, l'imprimante entre en écoute des commandes de l'utilisateur. Lors de la réception d'une commande, le firmware répond par un message adapté ainsi que le message "ok" dès que la commande est exécutée. Sachant cela, nous avons beaucoup de nouvelles choses à implémenter dans le code côté serveur :

• Attente du démarrage, pour l'instant implémentée avec un setTimeout;
• Attente du message "ok" après chaque commande pour éviter de surcharger le buffer;
• Détection d'erreurs, envoi du code de réponse HTML en fonction de la réponse de l'imprimante.

Ces implémentations seront l'objet de la semaine prochaine, ainsi que des tests sur l'imprimante.

Partie mécanique

Partie commune

En fin de séance, nous avons réalisé une série de tests avec le système presque complet (la Raspberry Pi était hors ligne). Chacun des essais a été réalisé avec les deux cartes Arduino : celle programmée par nos soins et celle du projet original.

- Move to Origin (Code G28) : la commande fonctionne sur les deux cartes - Mouvement selon les trois axes (Code G1 X10 Y10 Z10) : la commande ne fonctionne sur aucune des deux cartes - Mouvement selon un axe (Code G1 (X10|Y10|Z10)) : la commande ne fonctionne sur aucune des deux cartes

Lorsque nous tentions de déplacer l'imprimante sur un axe, le message était systématiquement le suivant : endstop reached. Cependant, aucun des capteurs de fin de course n'était activé. Nous supposons qu'il s'agit d'un problème de calibration de l'imprimante, qui pourrait être corrigé à l'aide d'une commande G90 ou G91 (Set to Absolute/Relative Positioning). Nous testerons ces commandes la semaine prochaine.

En outre, la comportement de l'Arduino est parfois surprenant. Lorsque l'on branche le câble USB-série sur l'Arduino avant d'alimenter le système, il tente d'alimenter les moteurs via l'alimentation de l'Arduino et n'a donc pas assez de puissance. Lorsque l'on branche le câble après le démarrage, l'alimentation se fait correctement. Cependant, lorsque le port série est ouvert par le programme, le firmware Marlin redémarre (affichage du logo Marlin sur l'écran). Nous ne savons pas vraiment à quoi ce comportement est dû mais nous tenterons d'investiguer par la suite. Quoi qu'il en soit, le système est utilisable tel quel.

Documents Rendus