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

Automatic Soldering System Project

2016-03-04T14:04:46Z

Pletouse : Ajout généraux et ajout des liens des codes sources

__TOC__
 
=Placeur de composants sur PCB=
==Présentation du projet==
Durant le début de l'été, nous avons eu l'idée de proposer un projet de soudure automatique. Ce projet avait pour but de concevoir un système permettant l'automatisation des soudures sur une carte électronique à composants traversants. Après des échanges avec le responsable des projet de 5éme année, M. Vantroys, nous avons finalement abandonné notre projet au profit d'un autre projet assez proche.

L'idée du nouveau projet est de proposer un système de Pick & Place de composants CMS sur une carte électronique sur laquelle de la crème à braser est préalablement déposée sur les pastilles. Pour mener à bien ce projet, nous avons été épaulé par M. Redon, M. Vantroys et M. Boé. En plus de nos encadrants école, nous avons travaillé en étroite collaboration avec M. Flamen, responsable du service électronique de Polytech Lille ainsi qu'avec M. Astori, enseignant en Conception Mécanique et responsable du FabLab de Polytech Lille. Nous tenons par ailleurs également à remercier chaleureusement Antoine, contributeur actif au Fablab de Polytech Lille, pour son partage d'expérience à propos de la création de son imprimante 3D RepRap, projet similaire au notre.
===Définitions des objectifs===
*Prendre un composant
**Stocker les composants à déposer sur la carte et identifier leur position
**Maintenir le composant par aspiration
*Repérer la position et l’orientation de la carte
*Déplacer le composant
**Le déplacer en translation selon les axes X, Y et Z
**L’orienter correctement sur les pastilles (rotation autour de Z)
*Déposer le composant
**S’assurer que l’outil d’aspiration n’endommage ni la carte, ni le composant lors de la dépose -> détecter le contact entre le composant et la carte
*Connaître la position désirée pour la dépose du composant
**Récupérer les fichiers provenant du logiciel de CAO et les transformer en déplacement de la machine
**Permettre à l’utilisateur d’avoir une interface visuelle (sur ordinateur) indiquant l’état des éléments de la machine et permettant leur calibrage
===Liste des tâches===
*Créer l’infrastructure mécanique de la machine (châssis)
**Fabrication du châssis
**Design des pièces mobiles et impression 3D de ces pièces au FabLab (chariot comportant l’outil d’aspiration et “guides tubes” assurant la transformation de la rotation des moteurs en mouvement de translation (glissières) sur des barres métalliques)
**Assembler l’outil d’aspiration au chariot
*Concevoir la commande d’aspiration par pompe
*Organiser la commande des moteurs du système pour l’asservissement en position de la machine
**Étude et prise en main des drivers pour les moteurs Pas à Pas
*Réalisation de l’interface commande-puissance
*Réaliser la conversion des données de position (relatives) de l’emplacement souhaités des composants en mouvements pour la machine
**Concevoir l’interface de récupération des données du fichier Gerber de l’utilisateur
**Caractérisation des différents repères (repère de la machine, repère de l’outil et repère de la carte) et établir le lien entres eux
**Détecter l’origine du repère de la carte au moyen d’une caméra fixe
===Planning prévisionnel de répartition du travail===
{| class="wikitable alternance centre"
|-
! scope="row" | Semaine 39 (21/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 40 (28/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 41 (05/10)
| Dimensionnement des éléments du système et recherche du matériel à commander en tenant compte des contraintes de coût
|-
! scope="row" | Semaine 42 (12/10)
| Achat du matériel pour le châssis de la machine (bois, tiges métalliques...) et pré-assemblage / Conception des pièces mécaniques à imprimer au FabLab
|-
! scope="row" | Semaine 43 (19/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position
|-
! scope="row" | Semaine 44 (26/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 45 (02/11)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de la commande des moteurs et du repérage caméra
|-
! scope="row" | Semaine 46 (09/11)
| Dans l'attente de la réception du matériel commandé : Fabrication du châssis - assemblage des pièces / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 47 (16/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 48 (23/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 49 (30/11)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 50 (07/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 51 (14/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 52 (21/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 53 (28/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
|}

===Retour sur les directives des encadrants===
====M. Flamen====
[[Fichier:Exemple composant cms.jpg|200px|thumb|right|Exemple de composants CMS]]
Dans un premier temps, pour mieux définir les objectifs de notre projet, nous avons pris rendez vous avec M. Flamen. M. Flamen est le responsable du service électronique de PolytechLille. Il est le principal intéressé par notre projet car celui-ci (le projet) permettrait de disposer de la chaîne complète de fabrication de cartes électroniques CMS (composants montés en surface).

Cette rencontre avec M. Flamen nous a permis de déterminer certaines précisions, comme:
* La précision maximale demandé n'excédera pas 0,2 mm (précision de classe 5, qui est celle de la graveuse de carte du service EEI).

===Liste de matériel===
====Matériel disponible====
*Support
** 3 Tiges de 1 mètre [Reçu le 2015-10-12]
** 1 Tasseau de 2m70 (découpé pour fabriquer les supports des tiges) [Reçu le 2015-10-12]
** 1 Planche en bois pour effectuer le support du projet [Reçu le 2015-10-12]
*Motorisation
**2 Moteurs Pas à Pas type NEMA 17 (pour axes X et Y) [http://www.gotronic.fr/art-moteur-17hs15-0404s-18354.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas (pour rotation autour de Z) [http://www.gotronic.fr/art-moteur-24byj48-19028.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas avec glissière intégrée (pour translation selon Z) [http://www.gotronic.fr/art-moteur-pas-a-pas-a-glissiere-800180001-21817.htm][Reçu le 2015-11-09]
**4 drivers pour moteur Pas à Pas bipolaire [http://www.gotronic.fr/art-driver-de-moteur-pas-a-pas-a4988-1182-21718.htm][Reçu le 2015-11-09]
*Outil d'aspiration
**Aiguille manipulant le composant [http://www.gotronic.fr/art-jeu-de-4-aiguilles-eso12-7428.htm][Reçu le 2015-11-09]
**Tube flexible [http://fr.rs-online.com/web/p/tubes-flexibles/7989985/][Reçu le 2015-11-09]
*Châssis mécanique
**2 Courroies crantées [http://fr.rs-online.com/web/p/courroies-crantees/4749614/][Reçu le 2015-11-09]
**4 Poulies crantées [http://fr.rs-online.com/web/p/poulies-pour-courroies-crantees/0182565/][Reçu le 2015-11-09]
*2 Courroies crantées plus grandes [Reçu le 2015-12-27]
====Matériel manquant====
* Rien pour le moment

==Fabrication de l'infrastructure mécanique==
[[Fichier:assp_usinage1.jpg|200px|thumb|left|Usinage des pylônes à la perceuse à colonne]]
[[Fichier:assp_usinage2.jpg|200px|thumb|right|Tour conventionnel utilisé pour le perçage]]
[[Fichier:assp_usinage3.jpg|200px|thumb|left|Marquages sur le support pour la pose de pylônes]]
[[Fichier:assp_usinage4.jpg|200px|thumb|right|Etat de la maquette avant la fixation finale]]
Notre projet comprend une partie extrêmement importante de conception. Sur conseils de M. Astori, nous avons donc décidé d'utiliser une organisation particulière. Le principe de cette organisation est de créer des pièces (on parle ici uniquement de leur impression à l'imprimante 3D et de la phase de conception sous Catia) rapidement, avec une faible taux de remplissage (de l'ordre de 20 à 30%). Le but de cette méthode est de créer un nombre de pièces plus important, permettant plus facilement rectifications en fonction des remarques que nous tirons du montage.

===La partie usinage===
Nous avons commencé par acheter une support contre-plaqué en bois. Sur ce support, nous avons disposé quatre pylônes reliés deux à deux par un axe métallique. Nous avons donc découpé à la scie à chantourner plusieurs linteaux de bois pour fabriquer les pylônes. Ensuite, nous avons usiné les pylônes à l'aide d'une perceuse à colonne pour leur permettre de recevoir l'axe métallique.

Ensuite, nous avons eu la surprise de recevoir des poulies non percées. Nous avons donc dû les percer. Nous avons percé les deux premières à l'aide de la perceuse à colonne. Le désavantage de cet outil est son imprécision sur la largeur de perçage. De plus, il n'était pas possible d'y ajouter un mécanisme permettant son maintien au moteur. Fort heureusement, nous avons eu la chance d'être aidés par l'atelier mécanique. Ainsi, nous avons usiné les deux dernières poulies à l'aide d'un tour conventionnel (sous la supervision du responsable de l'atelier mécanique). Nous avons ensuite, toujours avec l'aide de M.Yohann Dhondt, percé les deux poulies selon un axe perpendiculaire au précédent et créé un filetage pour permettre l'insertion d'une vis sans tête pour assurer la fixation au moteur.

Pour des raisons pratiques et esthétiques, nous avons demandé à la menuiserie de Polytech Lille de corriger nos pylônes pour assurer leur perpendicularité. Cette correction a été effectuée par M. Perraux et M. Parent à l'aide d'une scie à bande. Par la suite, nous avons marqué le support pour faciliter le perçage et l'ajustement des pylônes. Une fois les marquages, nous avons percé le support et les pylônes pour assurer une bonne fixation.

Cependant, nous avons été contraints de mettre en place de nouveaux pylônes qui, pour des questions d’organisation, n’ont pas pu être rectifiés par le service menuiserie. Nous avons donc essayé de les découper au mieux en prenant en compte leur torsion.

===La partie impression 3D===
====Pièces "guide axe" mobiles====
[[Fichier:assp_impression1.png|200px|thumb|left|Version 1 et 2 du guide axe avec moteur]]
[[Fichier:assp_impression2.png|180px|thumb|right|Guide axe antagoniste (sans moteur)]]
Nous avons commencé par créer les premières versions des pièces mobiles se fixant sur les barres métalliques, qui permettent le déplacement selon l'axe X, et permettent d'embarquer le moteur pour le déplacement selon Y. Nous les avons créées à l'aide du logiciel Catia. Les cotes imposées sur le schéma sont celles fournies par la documentation et par mesure des axes métalliques au pied à coulisse.

La deuxième pièce est très identique à la première à la différence près qu'elle n'embarque pas de moteur. Elle embarque uniquement une poulie permettant le passage de la courroie de transport en Y. Cette version, bien que fonctionnelle, n'a pas eu (pour le moment) l'amélioration apportée par la deuxième version de la pièce 1 (c'est à dire la réduction de surface de contact).

Nous nous sommes aperçu après l'impression que la documentation comprenait une erreur importante sur la taille des moteurs, nous obligeant à réimprimer une deuxième pièce. Nous avons profité de la deuxième impression pour réduire la surface de contact entre l'axe X de la pièce et l'axe métallique X.

Après tests sur la maquette, nous avons, malgré tout constaté les problèmes de frottements et de résistance à l’avancement que ces pièces engendrent sur certaines parties de nos axes métalliques. En effet, nos deux axes X ayant un parallélisme imparfait, le choix de notre liaison pivot glissant en bloquant la rotation autour de l’axe n’est pas adapté.

Nous avons donc modifié ces pièces en transformant la liaison “tube - cyllindre” par une liaison “roue incurvée - cylindre”, à la manière par exemple d’un rail de roller coaster (montagnes russes). Nous avons également doublé les moteurs sur l’axe X, un entraînement est donc créé sur les deux chariots, permettant une translation selon l’axe X plus fluide et plus homogène.

[[Fichier:ASSP_guide_axe_final.jpg|180px|thumb|right|Version finale des guides axes pour l'axe X]]
[[Fichier:ASSP_chariot.jpg|180px|thumb|left|Photo du chariot réalisé]]

====Conception du chariot comportant l'outil====

Le chariot est la partie la plus complexe de la maquette. Il doit assurer un grand nombre de fonctions. Il embarque un moteur pour la translation en Z, un moteur pour la rotation en Z, un système permettant d’adapter un préhenseur (dans notre cas: une seringue) au système à pression pneumatique et un système permettant de détecter la force appliquée pendant la pose du CMS.

Tout d’abord, son mouvement de translation avec l’axe Y est assuré par le même système de poulie que les guides axes. La translation en Z est assurée par un moteur engrènant une vis sans fin. Cette vis lie un solide qui assure alors une liaison glissière. Une pièce imprimée encastrée à ce solide nous permet de lier notre arrivée de pression négative à notre seringue.

Pour permettre une rotation selon l’axe Z, nous avons intégré un logement pour placer un moteur lié à un engrenage. Cet engrenage est destiné à venir faire tourner la pièce centrale (la pièce en rouge sur la photo suivante) à l’aide d’un engrenage interne.

Le chariot créé comporte également la solution choisie pour détecter un contact entre l’aiguille et un objet. En effet, nous n’avons pas assez de place pour intégrer des capteurs fin de course sur notre système moteur-glissière assurant la translation en Z. Cependant, ce dont nous avons besoin pour cette fonctionnalité “Détecter le contact entre le composant et la carte afin de ne pas les endommager” est réalisé par un capteur de position linéaire type potentiomètre linéaire. En effet, par un système de ressort intégré dans le chariot, nous pouvons obtenir la petite distance dont la pièce maintenant le moteur-glissière Z s’est déplacée et ainsi, la force exercée sur la carte/composant par l’aiguille.

[[Fichier:ASSP_photo_maquette_finale.JPG|450px|thumb|center|Photo de l'infrastructure mécanique finale et des éléments assemblés]]

==Motorisation et asservissement en position==
===Besoins et choix des moteurs===
Nous avons besoin de déplacer notre chariot comportant l'outil d'aspiration qui manipule les composants selon les 3 axes de l'espace X, Y et Z. Afin d'assurer les translations dans le plan (X,Y), nous nous sommes orientés vers un système moteur-poulie-courroie sur chacun de ces 2 axes. Nous avons besoin d'une précision en position de l'ordre de 0,2mm et n'avons pas un besoin en couple important, ni d'un asservissement en vitesse spécifique.

Nous avons donc choisi d'utiliser des moteurs Pas à Pas, qui offrent les avantages d'être précis en terme de position angulaire, de pouvoir adapter cette précision en les commandant en micro-pas et surtout de pouvoir réaliser l'asservissement en position sans capteurs. En effet, nous nous baserons sur le comptage du nombre de pas que l'on a fait effectuer au moteur, en supposant qu'aucun pas n'est sauté durant le déplacement. En effet, dans notre application la charge a entraîner est suffisamment faible et le déplacement se fera a une vitesse suffisamment lente afin d'assurer cette hypothèse.

Dans une seconde version, pour être sûr du positionnement et pour palier aux imprécisions (type jeux sur la maquette...) sur la position initiale, la position de la poulie et son diamètre, nous mettrons en place un système d'ajustement via une caméra, où l'utilisateur viendra valider le placement du composant avant dépose sur la carte.

Le déplacement de position est alors déduit ainsi : <math>\Delta X = \mu_{micropas} * \theta_{Pas_{nominal}} * R_{poulie} * \Delta {N_{Pas}}</math>

avec <math>\theta_{Pas_{nominal}}</math> le pas angulaire de nos moteurs en radian (ici, 1,8°=0,031415 rad) ,<math>\mu_{micropas}</math> le facteur de micro-pas choisi (typiquement 1/2, 1/4, voire 1/8), <math>R_{poulie}</math> le rayon primitif de la poulie crantée en mm (ici 7,15mm) et <math>\Delta {N_{Pas}}</math> le nombre de pas demandé (dans un sens ou dans un autre).

Ceci nous assure donc en théorie, de disposer d’une résolution en déplacement d’une précision de l’ordre de ΔXmin_théorique = 0,028 mm en commandant nos moteurs en 8ème de pas. Ceci est conforme au cahier des charges en terme de précision pour poser du CMS Classe 5, nécessitant une précision de 0,2mm, pour les déplacements en X et en Y.

Pour enfin connaître la position absolue, il s'agit de connaître la position initiale du chariot. Ceci est réalisé avec des capteurs "fin de course", type contacteurs à lamelles. En effet, nous effectuons avant le déplacement une “mise à zéro” en terme de position, en commandant le déplacement du chariot jusqu’à atteindre les contacteurs en X = 0 et en Y = 0.
Les capteurs de positions qui sont disposés de part et d’autre de chaque axe (début et fin de course), sont également utilisés en tant que sécurité : si un contact est détecté, les moteurs s’arrêtent, afin de ne pas endommager ces derniers ou la maquette.

===Commande des moteurs Pas à Pas===

[[Fichier:assp_schema_bipolar_stepper_4.png|140px|thumb|left|Schéma symbolisant les phases et l'arbre du moteur Pas à Pas bipolaire]]
[[Fichier:assp_schema_bipolar_stepper.jpg|300px|thumb|right|Schéma de la séquence d'alimentation complète du moteur bipolaire, en pas complet]]

Le principal inconvénient des moteurs Pas à Pas réside dans leur commande. En effet, un moteur Pas à Pas est un moteur particulier sans balai et alimenté par une alimentation continue. Il comporte plusieurs bobines permettant de créer un champ magnétique à l'intérieur et ainsi d'orienter des aimants fixés au rotor dans la direction du champ magnétique créé, ce qui provoque la rotation de l'arbre. On utilise le terme Pas à Pas car le champ magnétique créé à l'intérieur se fait par incréments. Ainsi pour faire tourner l'arbre entièrement, il faut effectuer l'alimentation des bobines pour une position 1, puis position 2, et ainsi de suite, selon la géométrie et la technologie du moteur utilisées.

Ainsi, son contrôle s'effectue par une séquence d'alimentation spécifique de ses différentes phases. Dans notre cas, nous avons choisi des moteurs bipolaires (de type Hybride, c'est à dire combinant les avantages des technologies "à aimant permanent" et à "réluctance variable"). Le sens de rotation de ces moteurs dépend de l'ordre d'alimentation des 2 bobines, ainsi que du sens du courant.

Ce pilotage peut s'effectuer au moyen d'une électronique de puissance type pont en H, sur laquelle on pilote les séquences de commutations des différentes cellules de commutation (transistor + diode en sens inverse en parallèle). Cependant une telle structure est compliquée à mettre en place au niveau des séquences, car elle n'intègre pas directement de limitation active du courant délivré dans la bobine et surtout car elle n'intègre pas directement de variation de courant afin de contrôler le moteur en micro-pas.

Présentant des prix très faibles (environ 5€) pour l'économie de temps et la simplicité d'utilisation qu'ils représentent, nous avons donc cherché des solutions de drivers adaptés à nos moteurs. Basé sur le circuit A4988 d'Allegro, nous nous sommes tournés vers ce driver pour moteur bipolaire (Pololu A4988 Stepper Motor Driver Carrier). Son principe est simple : il intègre directement cette structure de pont en H et les séquences d'alimentation. Il permet ainsi de faire effectuer au moteur un pas en envoyant une impulsion (front montant) sur sa pin STEP, dans le sens de rotation défini par l'état (haut ou bas) de sa pin DIR.

[[Fichier:assp_driver_pololu_pinout.png|380px|thumb|centre|Schéma du fonctionnement et du branchement du driver]]

Ce driver réalise également l'interface commande-puissance, il comporte une alimentation séparée pour le circuit logique (5V) et l'alimentation de puissance des moteurs (ici 12V). Il est très important pour éviter la surchauffe et l'endommagement des moteurs de contrôler le courant envoyé dans ses bobines. Nous limitons ainsi activement ce courant grâce au driver au moyen d'un potentiomètre à régler sur ce dernier. Nous avons réglé cette valeur par rapport aux courants nominaux par phase de nos moteurs.

L'avantage majeur de ce driver est qu'il comporte une solution de fonctionnement en micro-pas directement. Par l'état de ses pins MS1, MS2 et MS3, il nous permet de piloter du pas complet, au 1/16 de pas (maximum). Nous ne piloterons pas jusqu'au 1/16 de pas pour des soucis de stabilité du couple mécanique et pour éviter de sauter des pas, 1/4 voire 1/8 de pas devrait être suffisant. Et en effet, au gré des différents tests, le pilotage en 8ème de pas a montré un fonctionnement correct et stable.

Ainsi, nous pilotons toutes ces différentes entrées par le biais d'un Arduino Mega. Plus tard, cet Arduino Mega servira d'interface entre la consigne de position envoyée depuis l'application PC et les moteurs.

==Création de l'outil de manipulation par aspiration==

[[Fichier:ASSP_schema_pneumatique.png|220px|thumb|right|Schéma du fonctionnement du circuit pneumatique]]

L'outil qui viendra attraper et déposer les composants sera composé d'une aiguille fine qui les maintiendra par aspiration. Le système sera donc composé d'une pompe à vide, type pompe d'aquariophilie, peu couteuse, car l'aspiration nécessaire pour maintenir un composant est vraiment très faible. Ce genre de pompe se commande en tout ou rien au moyen d'un interrupteur manuel. Afin de ne pas alterner cycles d'allumage de la pompe pour éviter de l'endommager et surtout d'attendre le temps d'établissement du débit à chaque fois, lors des phases aspiration-dépose, nous utiliserons un distributeur pneumatique qui viendra envoyer ou non la dépression dans le tuyau d'air.

Niveau matériel pour cette partie, nous avons pour le moment réuni le distributeur, les tuyaux et l'aiguille. Nous devrions recevoir la pompe sous peu de temps.

Après réception, nous avons constaté l’inconvénient de ce genre de pompe : son arrivée d’air (coté aspiration donc) n’est pas accessible et connectable. Il s’agit en effet d’une large membrane souple et perméable, en matière type “feutre”. Nous nous sommes donc procuré un tube à effet Venturi, qui “transforme” une pression entrante positive (“souffle”) en une pression sortante négative (“aspiration”).

De par sa conception et par le principe physique mis en oeuvre, le tube à effet Venturi nécessite une pression et un débit suffisamment élevés, que notre pompe d’aquariophilie ne nous offre pas. Cependant, après discussion avec Thierry Flamen, la salle du service EEI possèdera dans un futur proche un raccordement en air comprimé. Ainsi, pour une utilisation au service EEI, il suffira de connecter notre câble d’arrivée d’air à ce raccordement. Dans l’attente des travaux, un compresseur à air peut tout à fait être utilisé.

Afin de commander ou non l’aspiration dans l’aiguille, nous utilisons un distributeur électro-pneumatique. Le distributeur devant être alimenté avec une tension de 24V, nous utilisons un optocoupleur en guise d’interrupteur commandé, piloté au moyen d’une sortie d’un Arduino.

==Commande et lecture des éléments du système via Arduino==
===Description des fonctions réalisées par l'Arduino Mega===
Afin de relier les divers éléments du système à l’application pour l’utilisateur, nous utilisons un Arduino Mega. En effet, ce dernier est utilisé pour jouer le rôle d’interface entre les ordres donnés par l’application PC et le contrôle des actionneurs / lecture des capteurs.

Voici les tâches dont se charge l’Arduino en terme de sorties :

*Contrôler la commande d’aspiration des composants
*Permettre d’envoyer les ordres aux drivers qui commandent les 5 moteurs, à savoir :
**2 moteurs pour la translation selon l’axe X
**1 moteur pour la translation selon l’axe Y
**1 moteur-glissière pour la translation selon l’axe Z
**1 moteur pour la rotation autour de Z

Pour chacun des drivers, 6 sorties logiques sont à commander :
1 bit pour l’activation du moteur (Enable),
1 bit pour le choix du sens de rotation (Dir),
1 bit pour exécuter les pas (Step) et
3 bits de sélection du micro-pas (MS1, MS2, MS3)

Voici les tâches dont se charge l’Arduino en terme d’entrées :

*Lecture de l’état des 6 capteurs fin de courses (contacteurs à lamelles, appuyés ou bien non appuyés) disposés pour X1_Min, X2_Min, Y_Min, X1_Max, X2_Max et Y_Max.
*Conversion et lecture de la tension analogique, image de la position du potentiomètre linéaire, représentant la force appliquée sur l’aiguille selon l’axe Z

L’Arduino permet ainsi à l’application d’effectuer les fonctions d’écriture (surnommées ‘set’) qui se chargent de :

*donner une consigne de nombre de pas au moteur sélectionné, par rapport à une position d’origine
*choisir le facteur de micro-pas sur le moteur sélectionné (pas complet, ½ pas, ¼ de pas, ⅛ de pas ou 1/16 de pas)
*commander l’optocoupleur relié au distributeur pneumatique pour l’allumage ou l’extinction de l’aspiration dans l’aiguille
*choisir la limite maximale de force que l’aiguille peut appliquer sur l’axe Z. Ceci est réalisé en définissant une limite de position du potentiomètre au delà de laquelle nous arrêtons de commander le moteur Z
*choisir la vitesse du moteur sélectionné, en définissant le temps en ms que nous attendons entre deux pas
*verrouiller ou déverrouiller en position le moteur sélectionné, en envoyant ou pas le courant dans les bobines des moteurs, provoquant un couple de maintien ou non

Pour que l’application PC puisse connaître les paramètres programmés sur l’Arduino et l’état des capteurs, l’Arduino permet aussi d’effectuer les fonctions de lecture (que nous avons surnommées ‘get’) et qui communique :

*l’état de de verrouillage en position des moteurs
*la position d’un moteur sélectionné par rapport à l’origine
*le facteur de micro-pas du moteur sélectionné
*l’état de la consigne d’allumage de l’aspiration
*la limite maximale de force que l’aiguille peut appliquer sur l’axe Z choisie
*l’état des capteurs fin de course
*la valeur convertie par l’ADC de la tension sur le potentiomètre
*la vitesse des moteurs
*la version du logiciel utilisé sur l’Arduino Mega

Dans le fonctionnement interne de l’Arduino, il s’assure pour chaque requête de déplacement que l’action demandée est réalisable. Le programme vérifie en effet que les contacteurs ne sont pas enclenchés tout au long du déplacement pour X et Y, ou que le potentiomètre n’a pas dépassé la valeur maximale qui a été fixée. Dans le cas contraire, l’action sur les moteurs est stoppée et l’Arduino communique un code d’erreur. Un code d’erreur est aussi communiqué en cas de jeu de paramètres demandés incorrect lors d’un appel à chaque fonction.

Par ailleurs, les codes du programme C implémenté sur l’Arduino sont disponibles sur GitHub à [https://github.com/henyxia/ASSP_Mega cette adresse] et sur [https://github.com/henyxia/ASSP_Mega le GitLab de Polytech Lille]

===Protocole de communication entre le logiciel et l'Arduino===
Nous avons été amenés à concevoir un protocole de communication pour assurer l’exécution des ordres et la coopération entre l’application et l’Arduino. Ils communiquent via le port série et nous avons optimisé le protocole pour le rendre le plus compact possible afin de limiter le nombre de communications.

[[Fichier:ASSP_mega_task_flowchart.png|200px|thumb|right|Principe de fonctionnement du programme sur l'Arduino]]

Nous disposons de 2 types de fonctions : les fonctions d’écriture (‘set’) et les fonctions de lecture (‘get’). Les fonctions “d’actions” (‘set’) retournent un code de retour à la fin de chaque action, disant si elle s’est terminée correctement ou si une erreur est survenue, comme le déclenchement d’un contact ou la saisie d’un paramètre incorrect. Les fonctions de lecture (‘get’) retournent quant à elles l’information demandée.

====Les trames de base====
{| class="wikitable"
|+ Commande d'initialisation d'une tâche (PC->Mega)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Paramètre
| colspan="4" |Fonction appelée
|}
{| class="wikitable"
|+ Commande de réponse d'une tâche (Mega->PC)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Donnée dépendant de la fonction
| colspan="4" | Code de retour
|}
Si le code de retour est différent de 0, les trames de retour 2 et 3 ne sont pas envoyées
{| class="wikitable"
|+ Liste des codes de retour
! scope="col" colspan="5" | Code retourné
! scope="col" rowspan="2" | Nom dans le header
! scope="col" rowspan="2" | Action à prendre
! scope="col" rowspan="2" | Description du code
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| CMD_OK
| Aucune
| La commande s'est exécutée correctement
|-
| 0
| 0
| 0
| 1
| 0x01
| CMD_NOT_KNOWN
| Report immédiat
| La commande demandée n'est pas connue
|-
| 0
| 0
| 1
| 0
| 0x02
| CMD_DEST_UNREACHABLE
| Report immédiat
| L'appel à la commande setDest a le paramètre dest trop grand sur le moteur choisi
|-
| 0
| 0
| 1
| 1
| 0x03
| CMD_LOCK_MIN_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son minimum
|-
| 0
| 1
| 0
| 0
| 0x04
| CMD_LOCK_MAX_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son maximum
|-
| 0
| 0
| 1
| 1
| 0x05
| CMD_LOCK_MIN_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son minimum
|-
| 0
| 1
| 1
| 0
| 0x06
| CMD_LOCK_MAX_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son maximum
|-
| 0
| 1
| 1
| 1
| 0x07
| CMD_LOCK_MIN_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son minimum
|-
| 1
| 0
| 0
| 0
| 0x08
| CMD_LOCK_MAX_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son maximum
|-
| 1
| 0
| 0
| 1
| 0x09
| CMD_LOCK_Z
| Report immédiat ou aucun
| L'aiguille a touché un objet et a dépassé la force maximum à appliquer dessus
|-
| 1
| 0
| 1
| 0
| 0x0A
| WAIT_FOR_NEXT_FRAME
| Report immédiat ou aucun
| La fonction appelée a été comprise, l'Arduino est en attente de la trame suivante.
|-
| 1
| 0
| 1
| 1
| 0x0B
| WAIT_FOR_IT_1
| Aucun
| La réponse est partielle, il manque encore une trame.
|-
| 1
| 1
| 0
| 0
| 0x0C
| WAIT_FOR_IT_2
| Aucun
| La réponse est partielle, il manque encore deux trames.
|}

====Liste des fonctions d'écriture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Paramètre 2
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| setDest
| selectedMotor[2bits]
| destination[16bits]
| Donne la consigne de position en seizième de pas par rapport à l'origine
|-
| 0
| 0
| 0
| 1
| 0x01
| setMS
| selectedMotor[2bits]
| microStep[3bits]
| Donne la consigne du nombre de micropas par tour pour un moteur
|-
| 0
| 0
| 1
| 0
| 0x02
| setPump
| onOff[1bit]
| ∅
| Donne la consigne d'allumage ou d'extinction de la pompe à vide
|-
| 0
| 0
| 1
| 1
| 0x03
| setADC
| adcLevel[10bits]
| ∅
| Donne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 0
| 1
| 0
| 1
| 0x05
| setSpeed
| selectedMotor[2bits]
| delayStep[8bits]
| Donne le temps en ms à attendre entre 2 pas (<=> la vitesse du moteur)
|-
| 0
| 1
| 1
| 0
| 0x06
| setMotLocked
| lockedOnOff[1bit], selectedMotor[2bits]
| ∅
| Verrouille ou déverrouille en position le moteur sélectionné (<=> couple de maintien ou non)
|}
{| class="wikitable"
|+ Détails sur la construction des fonctions d'écriture
! scope="col" rowspan="2" | Fonction appelée
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| setDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="8" align="center" | destination[15:8]
| colspan="8" align="center" | destination[7:0]
|-
| setMS
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="5" align="center" | ∅
| colspan="3" align="center" | microStep[2:0]
| colspan="8" align="center" | ∅
|-
| setPump
| colspan="3" align="center" | ∅
| align="center" | onOff
| colspan="16" align="center" | ∅
|-
| setADC
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| setSpeed
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|-
| setMotLocked
| colspan="1" align="center" | ∅
| align="center" | onOff
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="16" align="center" | ∅
|}

====Liste des fonctions de lecture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 1
| 1
| 1
| 0x07
| getMotLocked
| ∅
| Retourne l'état du verrouillage en position de tous les moteurs
|-
| 1
| 0
| 0
| 0
| 0x08
| getDest
| selectedMotor[2bits]
| Retourne la position d'un moteur donné en seizième de pas par rapport à l'origine
|-
| 1
| 0
| 0
| 1
| 0x09
| getMS
| ∅
| Retourne la consigne du nombre de micropas par tour pour tous les moteurs
|-
| 1
| 0
| 1
| 0
| 0x0A
| getPump
| ∅
| Retourne la consigne d'allumage actuelle de la pompe à vide
|-
| 1
| 0
| 1
| 1
| 0x0B
| getADC
| ∅
| Retourne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 1
| 1
| 0
| 0
| 0x0C
| getContact
| ∅
| Retourne l'état des contacteurs à lamelles (appuyés ou non)
|-
| 1
| 1
| 0
| 1
| 0x0D
| getADCvalue
| selectedPin[2bits]
| Retourne la valeur convertie par l'ADC de la pin analogique sélectionnée
|-
| 1
| 1
| 1
| 0
| 0x0E
| getSpeed
| selectedMotor[2bits]
| Retourne le délai entre 2 pas choisis pour le moteur sélectionné
|-
| 1
| 1
| 1
| 1
| 0x0F
| getVersion
| ∅
| Retourne la version du logiciel utilisée sur l'Arduino Mega (Actuelle: 0.1)
|}
{| class="wikitable"
|+ Détails de la construction des trames de lecture
! scope="col" rowspan="3" | Fonction appelée
! scope="col" colspan="4" | Appel (PC->Mega)
! scope="col" colspan="24" | Retour (Mega->PC)
|-
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| getMotorLocked
| colspan="4" align="center" | ∅
| lockedRotZ
| lockedZ
| lockedY
| lockedX
| colspan="8" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | dest[15:8]
| colspan="8" align="center" | dest[7:0]
|-
| getMS
| colspan="4" align="center" | ∅
| msY[0]
| colspan="3" align="center" | msX[2:0]
| colspan="3" align="center" | msR[2:0]
| colspan="3" align="center" | msZ[2:0]
| colspan="2" align="center" | msY[2:1]
| colspan="8" align="center" | ∅
|-
| getPump
| colspan="3" align="center" | ∅
| onOff
| colspan="4" align="center" | ∅
| colspan="8" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getADC
| colspan="4" align="center" | ∅
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| getContact
| colspan="4" align="center" | ∅
| isMinX1
| isMaxX1
| isMinX2
| isMaxX2
| colspan="6" align="center" | ∅
| isMinY
| isMaxY
| colspan="8" align="center" | ∅
|-
| getADCvalue
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedPin[1:0]
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcValue[9:8]
| colspan="8" align="center" | adcValue[7:0]
| colspan="8" align="center" | ∅
|-
| getSpeed
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|-
| getVersion
| colspan="4" align="center" | ∅
| colspan="4" align="center" | minorVersion[3:0]
| colspan="8" align="center" | majorVersion[7:0]
| colspan="8" align="center" | ∅
|}

==Conception du logiciel d'interfaçage utilisateur==
===Définition du cadre===
Un des buts de ce projet est de concevoir une application permettant de contrôler les différents éléments du projet. Pour cela nous, l'application doit être capable de lire des fichiers standards de création de carte électronique (aussi appelés fichiers Gerber). De plus, nous souhaitions que l'application puisse être utilisé sur n'importe quelle plateforme. Pour cela, nous avons choisi de la développer sous [http://www.qt.io/ Qt]. L’environnement de travail Qt nous permet d'utiliser des objets permettant l'accès à n'importe quel type de matériel sans se soucier de la plateforme de destination. Pour la communication avec les éléments de commande (comme les moteurs) nous avons choisi de n'envoyer des ordres qu'à travers l'Arduino Mega.

Comme l’intégralité de notre travail est placé sous le drapeau de l’open source, nous avons souhaité permettre à n’importe qui de pouvoir compiler notre application sur son ordinateur, et cela quelque soit son système d’exploitation. Pour permettre la réalisation de cet objectif, nous avons choisi un framework parmis ceux permettant cette inter-opérabilité. Son code source est d’ailleurs disponible sur GitHug à [http://github.com/henyxia/ASSP l’adresse suivante]

Les collections d’objets et de librairies (aussi appelés framework) multi-OS se comptent sur les doigts de la main et ont tous leurs avantages et leurs inconvénients. Parmis les plus connus (wxWidgets, GTK+, FLTK, FOX, …), nous avons choisi de prendre Qt. Ce framework a l’avantage d’intégrer des interfaces multiplateformes pour le port série et la Webcam.

Nous noterons quand même le coté négatif de ce choix: le développement de la partie du port série a pris plus de temps que prévu. En effet, la gestion du buffer pour le port série est assez mal expliquée et semble être peu indépendante du système d’exploitation. Pour palier à ce problème, nous avons choisi d’utiliser un protocole de communication octet à octet avec accusé d’émission et de réception.

===Création d'une interface intuitive===
Pour permettre à un utilisateur lambda de pouvoir utiliser notre interface, nous avons essayé de la rendre la plus intuitive possible. Pour cela, nous avons décomposé en trois zones distinctes les différentes informations. La première partie comporte une fenêtre OpenGL permettant la génération du rendu des fichiers GERBERs ouverts. Le deuxième volet est une fenêtre permettant le retour d’erreur et l’affichage d’informations sur l’état de l’application ou de la communication. Enfin, la troisième permet de visualiser en temps réel les variables de l’Arduino MEGA et d’ordonner des consignes.

==Fin du projet==
Au terme d’un semestre consacré majoritairement au développement de ce projet de fin d’étude, nous sommes réellement heureux et fiers des avancées qui ont été accomplies. Les difficultés rencontrées étaient souvent de natures différentes du fait de la multidisciplinarité de ce projet. Cependant, une quantité importante de travail, ainsi qu’un suivi de la part de nos encadrants nous ont permis d’atteindre la majorité de nos objectifs.

Bien que ce projet avait pour vocation d’être intégré au terme du semestre, il reste quand même utile pour le pôle EEI. Il pourra en effet être repris comme futur projet en IMA et ainsi achever l'automatisation des tâches, l'ajout d'une vision caméra et l’interface utilisateur.

Fichier:ASSP interface.JPG

2016-03-04T10:47:18Z

Pletouse :

Fichier:ASSP photo maquette finale.JPG

2016-03-04T10:45:41Z

Pletouse :

Fichier:ASSP schema detection contact.JPG

2016-03-04T10:44:41Z

Pletouse :

Fichier:ASSP chariot.jpg

2016-03-04T10:40:30Z

Pletouse :

Fichier:ASSP guide axe final.jpg

2016-03-04T10:39:24Z

Pletouse :

Fichier:ASSP schema pneumatique.png

2016-03-04T10:30:45Z

Pletouse :

Automatic Soldering System Project

2016-02-17T03:38:43Z

Pletouse : /* Création d'un système sûr pour Arduino Mega */ Ajout setMotLocked et getMotLocked

__TOC__
 
=Placeur de composants sur PCB=
==Présentation du projet==
Durant le début de l'été, nous avons eu l'idée de proposer un projet de soudure automatique. Ce projet avait pour but de concevoir un système permettant l'automatisation des soudures sur une carte électronique à composants traversants. Après des échanges avec le responsable des projet de 5éme année, M. Vantroys, nous avons finalement abandonné notre projet au profit d'un autre projet assez proche.

L'idée du nouveau projet est de proposer un système de Pick & Place de composants CMS sur une carte électronique sur laquelle de la crème à braser est préalablement déposée sur les pastilles. Pour mener à bien ce projet, nous avons été épaulé par M. Redon, M. Vantroys et M. Boé. En plus de nos encadrants école, nous avons travaillé en étroite collaboration avec M. Flamen, responsable du service électronique de Polytech Lille ainsi qu'avec M. Astori, enseignant en Conception Mécanique et responsable du FabLab de Polytech Lille. Nous tenons par ailleurs également à remercier chaleureusement Antoine, contributeur actif au Fablab de Polytech Lille, pour son partage d'expérience à propos de la création de son imprimante 3D RepRap, projet similaire au notre.
===Définitions des objectifs===
*Prendre un composant
**Stocker les composants à déposer sur la carte et identifier leur position
**Maintenir le composant par aspiration
*Repérer la position et l’orientation de la carte
*Déplacer le composant
**Le déplacer en translation selon les axes X, Y et Z
**L’orienter correctement sur les pastilles (rotation autour de Z)
*Déposer le composant
**S’assurer que l’outil d’aspiration n’endommage ni la carte, ni le composant lors de la dépose -> détecter le contact entre le composant et la carte
*Connaître la position désirée pour la dépose du composant
**Récupérer les fichiers provenant du logiciel de CAO et les transformer en déplacement de la machine
**Permettre à l’utilisateur d’avoir une interface visuelle (sur ordinateur) indiquant l’état des éléments de la machine et permettant leur calibrage
===Liste des tâches===
*Créer l’infrastructure mécanique de la machine (châssis)
**Fabrication du châssis
**Design des pièces mobiles et impression 3D de ces pièces au FabLab (chariot comportant l’outil d’aspiration et “guides tubes” assurant la transformation de la rotation des moteurs en mouvement de translation (glissières) sur des barres métalliques)
**Assembler l’outil d’aspiration au chariot
*Concevoir la commande d’aspiration par pompe
*Organiser la commande des moteurs du système pour l’asservissement en position de la machine
**Étude et prise en main des drivers pour les moteurs Pas à Pas
*Réalisation de l’interface commande-puissance
*Réaliser la conversion des données de position (relatives) de l’emplacement souhaités des composants en mouvements pour la machine
**Concevoir l’interface de récupération des données du fichier Gerber de l’utilisateur
**Caractérisation des différents repères (repère de la machine, repère de l’outil et repère de la carte) et établir le lien entres eux
**Détecter l’origine du repère de la carte au moyen d’une caméra fixe
===Planning prévisionnel de répartition du travail===
{| class="wikitable alternance centre"
|-
! scope="row" | Semaine 39 (21/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 40 (28/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 41 (05/10)
| Dimensionnement des éléments du système et recherche du matériel à commander en tenant compte des contraintes de coût
|-
! scope="row" | Semaine 42 (12/10)
| Achat du matériel pour le châssis de la machine (bois, tiges métalliques...) et pré-assemblage / Conception des pièces mécaniques à imprimer au FabLab
|-
! scope="row" | Semaine 43 (19/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position
|-
! scope="row" | Semaine 44 (26/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 45 (02/11)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de la commande des moteurs et du repérage caméra
|-
! scope="row" | Semaine 46 (09/11)
| Dans l'attente de la réception du matériel commandé : Fabrication du châssis - assemblage des pièces / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 47 (16/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 48 (23/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 49 (30/11)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 50 (07/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 51 (14/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 52 (21/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 53 (28/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 01 (04/01)
|
|-
! scope="row" | Semaine 02 (11/01)
|
|-
! scope="row" | Semaine 03 (18/01)
|
|-
! scope="row" | Semaine 04 (25/01)
|
|-
! scope="row" | Semaine 05 (01/02)
|
|-
! scope="row" | Semaine 06 (08/02)
|
|-
! scope="row" | Semaine 07 (15/02)
|
|-
! scope="row" | Semaine 08 (22/02)
|
|-
|}

===Retour sur les directives des encadrants===
====M. Flamen====
[[Fichier:Exemple composant cms.jpg|200px|thumb|right|Exemple de composants CMS]]
Dans un premier temps, pour mieux définir les objectifs de notre projet, nous avons pris rendez vous avec M. Flamen. M. Flamen est le responsable du service électronique de PolytechLille. Il est le principal intéressé par notre projet car celui-ci (le projet) permettrait de disposer de la chaîne complète de fabrication de cartes électroniques CMS (composants montés en surface).

Cette rencontre avec M. Flamen nous a permis de déterminer certaines précisions, comme:
* La précision maximale demandé n'excédera pas 0,2 mm (précision de classe 5, qui est celle de la graveuse de carte du service EEI).

===Liste de matériel===
====Matériel disponible====
*Support
** 3 Tiges de 1 mètre [Reçu le 2015-10-12]
** 1 Tasseau de 2m70 (découpé pour fabriquer les supports des tiges) [Reçu le 2015-10-12]
** 1 Planche en bois pour effectuer le support du projet [Reçu le 2015-10-12]
*Motorisation
**2 Moteurs Pas à Pas type NEMA 17 (pour axes X et Y) [http://www.gotronic.fr/art-moteur-17hs15-0404s-18354.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas (pour rotation autour de Z) [http://www.gotronic.fr/art-moteur-24byj48-19028.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas avec glissière intégrée (pour translation selon Z) [http://www.gotronic.fr/art-moteur-pas-a-pas-a-glissiere-800180001-21817.htm][Reçu le 2015-11-09]
**4 drivers pour moteur Pas à Pas bipolaire [http://www.gotronic.fr/art-driver-de-moteur-pas-a-pas-a4988-1182-21718.htm][Reçu le 2015-11-09]
*Outil d'aspiration
**Aiguille manipulant le composant [http://www.gotronic.fr/art-jeu-de-4-aiguilles-eso12-7428.htm][Reçu le 2015-11-09]
**Tube flexible [http://fr.rs-online.com/web/p/tubes-flexibles/7989985/][Reçu le 2015-11-09]
*Châssis mécanique
**2 Courroies crantées [http://fr.rs-online.com/web/p/courroies-crantees/4749614/][Reçu le 2015-11-09]
**4 Poulies crantées [http://fr.rs-online.com/web/p/poulies-pour-courroies-crantees/0182565/][Reçu le 2015-11-09]
*2 Courroies crantées plus grandes [Reçu le 2015-12-27]
====Matériel manquant====
* Rien pour le moment

==Fabrication de l'infrastructure mécanique==
[[Fichier:assp_usinage1.jpg|200px|thumb|left|Usinage des pylônes à la perceuse à colonne]]
[[Fichier:assp_usinage2.jpg|200px|thumb|right|Tour conventionnel utilisé pour le perçage]]
[[Fichier:assp_usinage3.jpg|200px|thumb|left|Marquages sur le support pour la pose de pylônes]]
[[Fichier:assp_usinage4.jpg|200px|thumb|right|Etat de la maquette avant la fixation finale]]
Notre projet comprend une partie extrêmement importante de conception. Sur conseils de M. Astori, nous avons donc décidé d'utiliser une organisation plus particulière. Le principe de cette organisation est de créer des pièces (on parle ici uniquement de leur impression à l'imprimante 3D et de la phase de conception sous Catia) rapidement, avec une faible taux de remplissage (de l'ordre de 30%). Le but de cette méthode est de créer un nombre de pièces plus important, permettant plus facilement rectifications en fonction des remarques que nous tirons du montage.

===La partie usinage===
Nous avons commencé par acheter une support contreplaqué en bois. Sur ce support, nous avons disposé quatre pylônes reliés deux à deux par un axe métallique. Nous avons donc découpé à la scie à chantourner plusieurs linteaux de bois pour fabriquer les pylônes. Ensuite, nous avons usiné les pylônes à l'aide d'une perceuse à colonne pour leur permettre de recevoir l'axe métallique.

Ensuite, nous avons eu la surprise de recevoir des poulies non percées. Nous avons donc du les percer. Nous avons percé les deux premières à l'aide de la perceuse à colonne. Le désavantage de cet outil est son imprécision sur la largeur de perçage. De plus, il n'était pas possible d'y ajouter un mécanisme permettant son maintien au moteur. Par conséquent, nous avons eu la chance d'être aidé par l'atelier mécanique. Ainsi, nous avons usiné les deux dernières poulies à l'aide d'un tour conventionnel (sous la supervision du responsable de l'atelier mécanique). Nous avons ensuite, toujours avec l'aide de M.Yoan Dhont, percé les deux poulies selon un axe perpendiculaire au précédent et créé un filetage pour permettre l'insertion d'une vis sans tête pour assurer la fixation au moteur.

Pour des raisons pratiques et esthétiques, nous avons demandé à la menuiserie de Polytech Lille de corriger nos pylônes pour assurer leur perpendicularité. Cette correction a été effectuée par M. David [TODO] et M. JP [TODO] à l'aide d'une scie à bande. Par la suite, nous avons marqué le support pour faciliter le perçage et l'ajustement des pylônes. Une fois les marquages, nous avons percé le support et les pylônes pour assurer une bonne fixation.

===La partie impression===
[[Fichier:assp_impression1.png|200px|thumb|left|Version 1 et 2 du guide axe avec moteur]]
[[Fichier:assp_impression2.png|180px|thumb|right|Guide axe antagoniste (sans moteur)]]
[[Fichier:assp_impression3.png|200px|thumb|left|Guide de poulie et garde moteur]]
Nous avons commencé par créé un chariot permettant le déplacement selon l'axe X, et permettant d'embarquer le moteur pour le déplacement selon Y. Nous l'avons créé à l'aide du logiciel Catia. Les cotes imposés sur le schéma sont celles fournies par la documentation et par mesure des axes métalliques au pieds à coulisse.

Après impression, nous nous sommes aperçu que la documentation comprenait une erreur importante sur la taille des moteurs, nous obligeant à réimprimer une deuxième pièce. Nous avons profiter de la deuxième impression pour réduire la surface de contexte entre l'axe X de la pièce et l'axe métallique X.

La deuxième pièce est très identique à la première à la différence près qu'elle n'embarque pas de moteur. Elle embarque uniquement une poulie permettant le passage de la courroie de transport en Y. Cette version, bien que fonctionnelle, n'a pas eu (pour le moment) l'amélioration apportée par la deuxième version de la pièce 1 (c'est à dire la réduction de surface de contact).

Les deux dernières pièces sont des pièces de support pour permettre au moteur de l'axe X et à la poulie de l'axe X de se maintenir sur leur pylône respectif. Le support de poulie n'a tenu que deux jours avant de rendre l'âme. Nous avons donc remplacé de façon temporaire son axe par une longue vis à bois. Le support de moteur n'a, lui, pas cassé, mais nécessite d'être imprimer une deuxième fois car la documentation du moteur était incorrecte (encore une fois).

Quelques jours avant la pré soutenance, les pièces semblent fonctionnelles. Une amélioration peut être apportée dans un second temps en modifiant les guide d'axe par des poulies (imprimées à l'imprimante 3D) permettant de suivre plus fidèlement l'axe métallique. Ce système sera développé durant les semaines suivants la pré soutenance.

==Motorisation et asservissement en position==
===Besoins et choix des moteurs===
Nous avons besoin de déplacer notre chariot comportant l'outil d'aspiration qui manipule les composants selon les 3 axes de l'espace X, Y et Z. Afin d'assurer les translations dans le plan (X,Y), nous nous sommes orienté vers un système moteur-poulie-courroie sur chacun de ces 2 axes. Nous avons besoin d'une précision en position de l'ordre de 0,2mm et n'avons pas un besoin en couple important, ni d'un asservissement en vitesse spécifique.

Nous avons donc choisi d'utiliser des moteurs Pas à Pas, qui offrent les avantages d'être précis en terme de position angulaire, de pouvoir adapter cette précision en les commandant en micro-pas et surtout de pouvoir réaliser l'asservissement en position sans capteurs. En effet, nous nous baserons sur le comptage du nombre de pas que l'on a fait effectuer au moteur, en supposant qu'aucun pas n'est sauté durant le déplacement. En effet, dans notre application la charge a entrainer est suffisamment faible et le déplacement se fera a une vitesse suffisamment basse afin d'assurer cette hypothèse.

Dans une seconde version, pour être sûr du positionnement et pour palier aux imprécisions (type jeux sur la maquette...) sur la position initiale, la position de la poulie et son diamètre, nous mettrons en place un système d'ajustement via une caméra, où l'utilisateur viendra valider le placement du composant avant dépose sur la carte.

Le déplacement de position est alors déduit ainsi : <math>\Delta X = \mu_{micropas} * \theta_{Pas_{nominal}} * R_{poulie} * \Delta {N_{Pas}}</math>

avec <math>\theta_{Pas_{nominal}}</math> le pas angulaire de nos moteurs en radian (ici, 1,8°=0,031415 rad) ,<math>\mu_{micropas}</math> le facteur de micro-pas choisi (typiquement 1/2, 1/4, voire 1/8), <math>R_{poulie}</math> le rayon du moyen de la poulie crantée en mm (ici 7,15mm) et <math>\Delta {N_{Pas}}</math> le nombre de pas demandé (dans un sens ou dans un autre).

Pour enfin connaitre la position absolue, il s'agit de connaitre la position initiale du chariot. Ceci sera réalisé avec des capteurs "fin de course", type contacteurs à lamelles.

===Commande des moteurs Pas à Pas===

[[Fichier:assp_schema_bipolar_stepper_4.png|140px|thumb|left|Schéma symbolisant les phases et l'arbre du moteur Pas à Pas bipolaire]]
[[Fichier:assp_schema_bipolar_stepper.jpg|300px|thumb|right|Schéma de la séquence d'alimentation complète du moteur bipolaire, en pas complet]]

Le principal inconvénient des moteurs Pas à Pas réside dans la commande de ceux-ci. En effet, un moteur Pas à Pas est un moteur particulier sans balai et alimenté par une alimentation continue. Il comporte plusieurs bobines permettant de créer un champ magnétique à l'intérieur et ainsi d'orienter des aimants fixés au rotor dans la direction du champ magnétique crée, ce qui provoque la rotation de l'arbre. On utilise le terme Pas à Pas car le champ magnétique crée à l'intérieur se fait par incréments. Ainsi pour faire tourner l'arbre entièrement, il faut effectuer l'alimentation des bobines pour une position 1, puis position 2, et ainsi de suite, selon la géométrie et la technologie du moteur utilisées.

Ainsi, le contrôle de celui ci s'effectue par une séquence d'alimentation spécifique de ses différentes phases. Dans notre cas, nous avons choisi des moteurs bipolaires (de type Hybride, c'est à dire combinant les avantages des technologies "à aimant permanent" et à "réluctance variable"). Le sens de rotation des ces moteurs dépend de l'ordre d'alimentation des 2 bobines, ainsi que du sens du courant.

Ce pilotage peut s'effectuer au moyen d'une électronique de puissance type pont en H, sur laquelle on pilote les séquences de commutation des différentes cellules de commutation (transistor + diode en sens inverse en parallèle). Cependant une telle structure est compliquée à mettre en place au niveau des séquences, n'intègre pas directement de limitation active du courant délivré dans la bobine et surtout n'intègre pas directement de variation de courant afin de contrôler le moteur en micro-pas.

Présentant des prix très faibles (environ 5€) pour l'économie de temps et la simplicité d'utilisation qu'ils représentent, nous avons donc cherché des solutions de drivers adaptés à nos moteurs. Basé sur le circuit A4988 d'Allegro, nous nous sommes tourné vers ce driver pour moteur bipolaire (Pololu A4988 Stepper Motor Driver Carrier). Son principe est simple : il intègre directement cette structure de pont en H et les séquences d'alimentation. Il permet ainsi de faire effectuer au moteur un pas en envoyant une impulsion (front montant) sur sa pin STEP, dans le sens défini par l'état (haut ou bas) de sa pin DIR.

[[Fichier:assp_driver_pololu_pinout.png|380px|thumb|centre|Schéma du fonctionnement et du branchement du driver]]

Ce driver réalise également l'interface commande-puissance, il comporte une alimentation séparée pour le circuit logique (5V) et l'alimentation de puissance des moteurs (ici 12V). Il est très important pour éviter la surchauffe et l'endommagement des moteurs de contrôler le courant envoyé dans ses bobines. Nous limitons ainsi activement ce courant grâce au driver au moyen d'un potentiomètre à régler sur ce dernier. Nous avons réglé cette valeur par rapport aux courants nominaux par phase de nos moteurs.

L'avantage majeur de ce driver est qu'il comporte une solution de fonctionnement en micro-pas directement. Par l'état de ses pins MS1, MS2 et MS3, il nous permet de piloter du pas complet, au 1/16 de pas (maximum). Nous ne piloterons pas jusqu'au 1/16 de pas pour des soucis de stabilité du couple mécanique et pour éviter de sauter des pas, 1/4 voire 1/8 de pas devrait être suffisant. Le choix du micropas maximum sera à déterminer avec les tests sur la machine.

Ainsi, nous pilotons toutes ces différentes entrées par le biais d'un Arduino Mega. Plus tard, cet Arduino Mega servira d'interface entre la consigne de position envoyée depuis l'application PC et les moteurs.

[[Fichier:|200px|thumb|right|Photo de la partie commande des moteurs]]

==Création de l'outil de manipulation par aspiration==

L'outil qui viendra attraper et déposer les composants sera composé d'une aiguille fine qui les maintiendra par aspiration. Le système sera donc composé d'une pompe à vide, type pompe d'aquariophilie, peu couteuse, car l'aspiration nécessaire pour maintenir un composant est vraiment très faible. Ce genre de pompe se commande en tout ou rien au moyen d'un interrupteur manuel. Afin de ne pas alterner cycles d'allumage de la pompe pour éviter de l'endommager et surtout d'attendre le temps d'établissement du débit à chaque fois, lors des phases aspiration-dépose, nous utiliserons un distributeur pneumatique qui viendra envoyer ou non la dépression dans le tuyau d'air.

Une partie majeure du travail va consister en la conception de la pièce mécanique, le chariot, qui intégrera les moteurs pour effectuer la translation et la rotation autour de Z, un capteur piézoélectrique qui permettra la détection du contact entre le composant et la carte et qui intégrera un espace prévu à cet effet pour maintenir le tuyau et l'aiguille. Ce chariot sera adaptable au reste du châssis et comportera une partie qui le fixe à la courroie.

Niveau matériel pour cette partie, nous avons pour le moment réuni le distributeur, les tuyaux et l'aiguille. Nous devrions recevoir la pompe sous peu de temps.

==Conception du logiciel==
===Définition du cadre===
Un des buts de ce projet est de concevoir une application permettant de contrôler les différents éléments du projet. Pour cela nous, l'application doit être capable de lire des fichiers standards de création de carte électronique (aussi appelés fichiers Gerber). De plus, nous souhaitions que l'application puisse être utilisé sur n'importe quelle plateforme. Pour cela, nous avons choisi de la développer sous [http://www.qt.io/ Qt]. L’environnement de travail Qt nous permet d'utiliser des objets permettant l'accès à n'importe quel type de matériel sans se soucier de la plateforme de destination. Pour la communication avec les éléments de commande (comme les moteurs) nous avons choisi de n'envoyer des ordres qu'à travers l'Arduino Mega.
===La communication entre le logiciel et l'Arduino Mega===
==Création d'un système sûr pour Arduino Mega==
L'application de bureau que nous avons créé va, comme expliqué précédemment, communiqué avec un Arduino Mega. Cet Arduino s'occupera de la commande de la partie du puissance du reste du système. Ces fonctions sont:
* Commander des moteurs sur les axes X, Y et Z
* Commander de la rotation selon Z
* Contrôler de la pompe
* Définir les paramètres avancés des moteurs (vitesse, précision des micropas)
* S'assurer de ne pas commander un ordre endommageant la machine
===Le protocole de communication===
[[Fichier:ASSP_mega_task_flowchart.png|200px|thumb|right]]Pour permettre de réaliser ces fonctions, l'application communique à travers le port série avec l'Arduino Mega. Le protocole utilisé est rendant le plus compact possible pour limiter le nombre de communications.
L'Arduino Mega ne fonctionne que par tâches (comme décris sur le schéma à droite). La seule possibilité pour l'Arduino de ne pas être dans cette exécution de tâches est d'être interrompu par un contact à lamelle souple (que nous considérons comme prioritaire). Dans ce cas, l'Arduino reste bloqué dans la fonction appelé par l'interruption jusqu'à temps que l'utilisateur valide manuellement la déverrouillage (ce qui permet d'éviter que le système ne puisse s’abîmer).
====Les trames de base====
{| class="wikitable"
|+ Commande d'initialisation d'une tâche (PC->Mega)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Paramètre
| colspan="4" |Fonction appelée
|}
{| class="wikitable"
|+ Commande de réponse d'une tâche (Mega->PC)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Donnée dépendant de la fonction
| colspan="4" | Code de retour
|}
Si le code de retour est différent de 0, les trames de retour 2 et 3 ne sont pas envoyées
{| class="wikitable"
|+ Liste des codes de retour
! scope="col" colspan="5" | Code retourné
! scope="col" rowspan="2" | Nom dans le header
! scope="col" rowspan="2" | Action à prendre
! scope="col" rowspan="2" | Description du code
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| CMD_OK
| Aucune
| La commande s'est exécutée correctement
|-
| 0
| 0
| 0
| 1
| 0x01
| CMD_NOT_KNOWN
| Report immédiat
| La commande demandée n'est pas connue
|-
| 0
| 0
| 1
| 0
| 0x02
| CMD_DEST_UNREACHABLE
| Report immédiat
| L'appel à la commande setDest a le paramètre dest trop grand sur le moteur choisi
|-
| 0
| 0
| 1
| 1
| 0x03
| CMD_LOCK_MIN_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son minimum
|-
| 0
| 1
| 0
| 0
| 0x04
| CMD_LOCK_MAX_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son maximum
|-
| 0
| 0
| 1
| 1
| 0x05
| CMD_LOCK_MIN_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son minimum
|-
| 0
| 1
| 1
| 0
| 0x06
| CMD_LOCK_MAX_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son maximum
|-
| 0
| 1
| 1
| 1
| 0x07
| CMD_LOCK_MIN_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son minimum
|-
| 1
| 0
| 0
| 0
| 0x08
| CMD_LOCK_MAX_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son maximum
|-
| 1
| 0
| 0
| 1
| 0x09
| CMD_LOCK_Z
| Report immédiat ou aucun
| L'aiguille a touché un objet et a dépassé la force maximum à appliquer dessus
|-
| 1
| 0
| 1
| 0
| 0x0A
| WAIT_FOR_NEXT_FRAME
| Report immédiat ou aucun
| La fonction appelée a été comprise, l'Arduino est en attente de la trame suivante.
|}

====Liste des fonctions d'écriture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Paramètre 2
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| setDest
| selectedMotor[2bits]
| destination[16bits]
| Donne la consigne de position en seizième de pas par rapport à l'origine
|-
| 0
| 0
| 0
| 1
| 0x01
| setMS
| selectedMotor[2bits]
| microStep[3bits]
| Donne la consigne du nombre de micropas par tour pour un moteur
|-
| 0
| 0
| 1
| 0
| 0x02
| setPump
| onOff[1bit]
| ∅
| Donne la consigne d'allumage ou d'extinction de la pompe à vide
|-
| 0
| 0
| 1
| 1
| 0x03
| setADC
| adcLevel[10bits]
| ∅
| Donne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 0
| 1
| 0
| 0
| 0x04
| setRelease
| lockToRelease[3bits]
| ∅
| Donne la consigne de déverrouillage d'un nœud précédemment verrouillé
|-
| 0
| 1
| 0
| 1
| 0x05
| setSpeed
| selectedMotor[2bits]
| delayStep[8bits]
| Donne le temps en ms à attendre entre 2 pas (<=> la vitesse du moteur)
|-
| 0
| 1
| 1
| 0
| 0x06
| setMotLocked
| lockedOnOff[1bit], selectedMotor[2bits]
| ∅
| Verrouille ou déverrouille en position le moteur sélectionné (<=> couple de maintien ou non)
|}
{| class="wikitable"
|+ Détails sur la construction des fonctions d'écriture
! scope="col" rowspan="2" | Fonction appelée
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| setDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="8" align="center" | destination[15:8]
| colspan="8" align="center" | destination[7:0]
|-
| setMS
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="5" align="center" | ∅
| colspan="3" align="center" | microStep[2:0]
| colspan="8" align="center" | ∅
|-
| setPump
| colspan="3" align="center" | ∅
| align="center" | onOff
| colspan="16" align="center" | ∅
|-
| setADC
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| setRelease
| align="center" | ∅
| colspan="3" align="center" | lockToRelease[2:0]
| colspan="16" align="center" | ∅
|-
| setSpeed
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|-
| setMotLocked
| colspan="1" align="center" | ∅
| align="center" | onOff
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="16" align="center" | ∅
|}

====Liste des fonctions de lecture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 1
| 1
| 1
| 0x07
| getMotLocked
| ∅
| Retourne l'état du verrouillage en position de tous les moteurs
|-
| 1
| 0
| 0
| 0
| 0x08
| getDest
| selectedMotor[2bits]
| Retourne la position d'un moteur donné en seizième de pas par rapport à l'origine
|-
| 1
| 0
| 0
| 1
| 0x09
| getMS
| ∅
| Retourne la consigne du nombre de micropas par tour pour tous les moteurs
|-
| 1
| 0
| 1
| 0
| 0x0A
| getPump
| ∅
| Retourne la consigne d'allumage actuelle de la pompe à vide
|-
| 1
| 0
| 1
| 1
| 0x0B
| getADC
| ∅
| Retourne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 1
| 1
| 0
| 0
| 0x0C
| getRelease
| ∅
| Retourne l'état de verrouillage des nœuds
|-
| 1
| 1
| 0
| 1
| 0x0D
| getADCvalue
| selectedPin[2bits]
| Retourne la valeur convertie par l'ADC de la pin analogique sélectionnée
|-
| 1
| 1
| 1
| 0
| 0x0E
| getSpeed
| selectedMotor[2bits]
| Retourne le délai entre 2 pas choisis pour le moteur sélectionné
|-
| 1
| 1
| 1
| 1
| 0x0F
| getVersion
| ∅
| Retourne la version du logiciel utilisée sur l'Arduino Mega (Actuelle: 0.1)
|}
{| class="wikitable"
|+ Détails de la construction des trames de lecture
! scope="col" rowspan="3" | Fonction appelée
! scope="col" colspan="4" | Appel (PC->Mega)
! scope="col" colspan="24" | Retour (Mega->PC)
|-
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| getMotorLocked
| colspan="4" align="center" | ∅
| lockedRotZ
| lockedZ
| lockedY
| lockedX
| colspan="8" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | dest[15:8]
| colspan="8" align="center" | dest[7:0]
|-
| getMS
| colspan="4" align="center" | ∅
| msY[0]
| colspan="3" align="center" | msX[2:0]
| colspan="3" align="center" | msR[2:0]
| colspan="3" align="center" | msZ[2:0]
| colspan="2" align="center" | msY[2:1]
| colspan="8" align="center" | ∅
|-
| getPump
| colspan="3" align="center" | ∅
| onOff
| colspan="4" align="center" | ∅
| colspan="8" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getADC
| colspan="4" align="center" | ∅
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| getRelease
| colspan="4" align="center" | ∅
| lockMinX1
| lockMaxX1
| lockMinX2
| lockMaxX2
| colspan="6" align="center" | ∅
| lockMinY
| lockMaxY
| colspan="8" align="center" | ∅
|-
| getADCvalue
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedPin[1:0]
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcValue[9:8]
| colspan="8" align="center" | adcValue[7:0]
| colspan="8" align="center" | ∅
|-
| getSpeed
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|-
| getVersion
| colspan="4" align="center" | ∅
| colspan="4" align="center" | minorVersion[3:0]
| colspan="8" align="center" | majorVersion[7:0]
| colspan="8" align="center" | ∅
|}

Automatic Soldering System Project

2016-02-15T03:21:57Z

Pletouse : /* Liste des fonctions de lecture */ Ajout de getSpeed

__TOC__
 
=Placeur de composants sur PCB=
==Présentation du projet==
Durant le début de l'été, nous avons eu l'idée de proposer un projet de soudure automatique. Ce projet avait pour but de concevoir un système permettant l'automatisation des soudures sur une carte électronique à composants traversants. Après des échanges avec le responsable des projet de 5éme année, M. Vantroys, nous avons finalement abandonné notre projet au profit d'un autre projet assez proche.

L'idée du nouveau projet est de proposer un système de Pick & Place de composants CMS sur une carte électronique sur laquelle de la crème à braser est préalablement déposée sur les pastilles. Pour mener à bien ce projet, nous avons été épaulé par M. Redon, M. Vantroys et M. Boé. En plus de nos encadrants école, nous avons travaillé en étroite collaboration avec M. Flamen, responsable du service électronique de Polytech Lille ainsi qu'avec M. Astori, enseignant en Conception Mécanique et responsable du FabLab de Polytech Lille. Nous tenons par ailleurs également à remercier chaleureusement Antoine, contributeur actif au Fablab de Polytech Lille, pour son partage d'expérience à propos de la création de son imprimante 3D RepRap, projet similaire au notre.
===Définitions des objectifs===
*Prendre un composant
**Stocker les composants à déposer sur la carte et identifier leur position
**Maintenir le composant par aspiration
*Repérer la position et l’orientation de la carte
*Déplacer le composant
**Le déplacer en translation selon les axes X, Y et Z
**L’orienter correctement sur les pastilles (rotation autour de Z)
*Déposer le composant
**S’assurer que l’outil d’aspiration n’endommage ni la carte, ni le composant lors de la dépose -> détecter le contact entre le composant et la carte
*Connaître la position désirée pour la dépose du composant
**Récupérer les fichiers provenant du logiciel de CAO et les transformer en déplacement de la machine
**Permettre à l’utilisateur d’avoir une interface visuelle (sur ordinateur) indiquant l’état des éléments de la machine et permettant leur calibrage
===Liste des tâches===
*Créer l’infrastructure mécanique de la machine (châssis)
**Fabrication du châssis
**Design des pièces mobiles et impression 3D de ces pièces au FabLab (chariot comportant l’outil d’aspiration et “guides tubes” assurant la transformation de la rotation des moteurs en mouvement de translation (glissières) sur des barres métalliques)
**Assembler l’outil d’aspiration au chariot
*Concevoir la commande d’aspiration par pompe
*Organiser la commande des moteurs du système pour l’asservissement en position de la machine
**Étude et prise en main des drivers pour les moteurs Pas à Pas
*Réalisation de l’interface commande-puissance
*Réaliser la conversion des données de position (relatives) de l’emplacement souhaités des composants en mouvements pour la machine
**Concevoir l’interface de récupération des données du fichier Gerber de l’utilisateur
**Caractérisation des différents repères (repère de la machine, repère de l’outil et repère de la carte) et établir le lien entres eux
**Détecter l’origine du repère de la carte au moyen d’une caméra fixe
===Planning prévisionnel de répartition du travail===
{| class="wikitable alternance centre"
|-
! scope="row" | Semaine 39 (21/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 40 (28/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 41 (05/10)
| Dimensionnement des éléments du système et recherche du matériel à commander en tenant compte des contraintes de coût
|-
! scope="row" | Semaine 42 (12/10)
| Achat du matériel pour le châssis de la machine (bois, tiges métalliques...) et pré-assemblage / Conception des pièces mécaniques à imprimer au FabLab
|-
! scope="row" | Semaine 43 (19/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position
|-
! scope="row" | Semaine 44 (26/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 45 (02/11)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de la commande des moteurs et du repérage caméra
|-
! scope="row" | Semaine 46 (09/11)
| Dans l'attente de la réception du matériel commandé : Fabrication du châssis - assemblage des pièces / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 47 (16/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 48 (23/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 49 (30/11)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 50 (07/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 51 (14/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 52 (21/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 53 (28/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 01 (04/01)
|
|-
! scope="row" | Semaine 02 (11/01)
|
|-
! scope="row" | Semaine 03 (18/01)
|
|-
! scope="row" | Semaine 04 (25/01)
|
|-
! scope="row" | Semaine 05 (01/02)
|
|-
! scope="row" | Semaine 06 (08/02)
|
|-
! scope="row" | Semaine 07 (15/02)
|
|-
! scope="row" | Semaine 08 (22/02)
|
|-
|}

===Retour sur les directives des encadrants===
====M. Flamen====
[[Fichier:Exemple composant cms.jpg|200px|thumb|right|Exemple de composants CMS]]
Dans un premier temps, pour mieux définir les objectifs de notre projet, nous avons pris rendez vous avec M. Flamen. M. Flamen est le responsable du service électronique de PolytechLille. Il est le principal intéressé par notre projet car celui-ci (le projet) permettrait de disposer de la chaîne complète de fabrication de cartes électroniques CMS (composants montés en surface).

Cette rencontre avec M. Flamen nous a permis de déterminer certaines précisions, comme:
* La précision maximale demandé n'excédera pas 0,2 mm (précision de classe 5, qui est celle de la graveuse de carte du service EEI).

===Liste de matériel===
====Matériel disponible====
*Support
** 3 Tiges de 1 mètre [Reçu le 2015-10-12]
** 1 Tasseau de 2m70 (découpé pour fabriquer les supports des tiges) [Reçu le 2015-10-12]
** 1 Planche en bois pour effectuer le support du projet [Reçu le 2015-10-12]
*Motorisation
**2 Moteurs Pas à Pas type NEMA 17 (pour axes X et Y) [http://www.gotronic.fr/art-moteur-17hs15-0404s-18354.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas (pour rotation autour de Z) [http://www.gotronic.fr/art-moteur-24byj48-19028.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas avec glissière intégrée (pour translation selon Z) [http://www.gotronic.fr/art-moteur-pas-a-pas-a-glissiere-800180001-21817.htm][Reçu le 2015-11-09]
**4 drivers pour moteur Pas à Pas bipolaire [http://www.gotronic.fr/art-driver-de-moteur-pas-a-pas-a4988-1182-21718.htm][Reçu le 2015-11-09]
*Outil d'aspiration
**Aiguille manipulant le composant [http://www.gotronic.fr/art-jeu-de-4-aiguilles-eso12-7428.htm][Reçu le 2015-11-09]
**Tube flexible [http://fr.rs-online.com/web/p/tubes-flexibles/7989985/][Reçu le 2015-11-09]
*Châssis mécanique
**2 Courroies crantées [http://fr.rs-online.com/web/p/courroies-crantees/4749614/][Reçu le 2015-11-09]
**4 Poulies crantées [http://fr.rs-online.com/web/p/poulies-pour-courroies-crantees/0182565/][Reçu le 2015-11-09]
*2 Courroies crantées plus grandes [Reçu le 2015-12-27]
====Matériel manquant====
* Rien pour le moment

==Fabrication de l'infrastructure mécanique==
[[Fichier:assp_usinage1.jpg|200px|thumb|left|Usinage des pylônes à la perceuse à colonne]]
[[Fichier:assp_usinage2.jpg|200px|thumb|right|Tour conventionnel utilisé pour le perçage]]
[[Fichier:assp_usinage3.jpg|200px|thumb|left|Marquages sur le support pour la pose de pylônes]]
[[Fichier:assp_usinage4.jpg|200px|thumb|right|Etat de la maquette avant la fixation finale]]
Notre projet comprend une partie extrêmement importante de conception. Sur conseils de M. Astori, nous avons donc décidé d'utiliser une organisation plus particulière. Le principe de cette organisation est de créer des pièces (on parle ici uniquement de leur impression à l'imprimante 3D et de la phase de conception sous Catia) rapidement, avec une faible taux de remplissage (de l'ordre de 30%). Le but de cette méthode est de créer un nombre de pièces plus important, permettant plus facilement rectifications en fonction des remarques que nous tirons du montage.

===La partie usinage===
Nous avons commencé par acheter une support contreplaqué en bois. Sur ce support, nous avons disposé quatre pylônes reliés deux à deux par un axe métallique. Nous avons donc découpé à la scie à chantourner plusieurs linteaux de bois pour fabriquer les pylônes. Ensuite, nous avons usiné les pylônes à l'aide d'une perceuse à colonne pour leur permettre de recevoir l'axe métallique.

Ensuite, nous avons eu la surprise de recevoir des poulies non percées. Nous avons donc du les percer. Nous avons percé les deux premières à l'aide de la perceuse à colonne. Le désavantage de cet outil est son imprécision sur la largeur de perçage. De plus, il n'était pas possible d'y ajouter un mécanisme permettant son maintien au moteur. Par conséquent, nous avons eu la chance d'être aidé par l'atelier mécanique. Ainsi, nous avons usiné les deux dernières poulies à l'aide d'un tour conventionnel (sous la supervision du responsable de l'atelier mécanique). Nous avons ensuite, toujours avec l'aide de M.Yoan Dhont, percé les deux poulies selon un axe perpendiculaire au précédent et créé un filetage pour permettre l'insertion d'une vis sans tête pour assurer la fixation au moteur.

Pour des raisons pratiques et esthétiques, nous avons demandé à la menuiserie de Polytech Lille de corriger nos pylônes pour assurer leur perpendicularité. Cette correction a été effectuée par M. David [TODO] et M. JP [TODO] à l'aide d'une scie à bande. Par la suite, nous avons marqué le support pour faciliter le perçage et l'ajustement des pylônes. Une fois les marquages, nous avons percé le support et les pylônes pour assurer une bonne fixation.

===La partie impression===
[[Fichier:assp_impression1.png|200px|thumb|left|Version 1 et 2 du guide axe avec moteur]]
[[Fichier:assp_impression2.png|180px|thumb|right|Guide axe antagoniste (sans moteur)]]
[[Fichier:assp_impression3.png|200px|thumb|left|Guide de poulie et garde moteur]]
Nous avons commencé par créé un chariot permettant le déplacement selon l'axe X, et permettant d'embarquer le moteur pour le déplacement selon Y. Nous l'avons créé à l'aide du logiciel Catia. Les cotes imposés sur le schéma sont celles fournies par la documentation et par mesure des axes métalliques au pieds à coulisse.

Après impression, nous nous sommes aperçu que la documentation comprenait une erreur importante sur la taille des moteurs, nous obligeant à réimprimer une deuxième pièce. Nous avons profiter de la deuxième impression pour réduire la surface de contexte entre l'axe X de la pièce et l'axe métallique X.

La deuxième pièce est très identique à la première à la différence près qu'elle n'embarque pas de moteur. Elle embarque uniquement une poulie permettant le passage de la courroie de transport en Y. Cette version, bien que fonctionnelle, n'a pas eu (pour le moment) l'amélioration apportée par la deuxième version de la pièce 1 (c'est à dire la réduction de surface de contact).

Les deux dernières pièces sont des pièces de support pour permettre au moteur de l'axe X et à la poulie de l'axe X de se maintenir sur leur pylône respectif. Le support de poulie n'a tenu que deux jours avant de rendre l'âme. Nous avons donc remplacé de façon temporaire son axe par une longue vis à bois. Le support de moteur n'a, lui, pas cassé, mais nécessite d'être imprimer une deuxième fois car la documentation du moteur était incorrecte (encore une fois).

Quelques jours avant la pré soutenance, les pièces semblent fonctionnelles. Une amélioration peut être apportée dans un second temps en modifiant les guide d'axe par des poulies (imprimées à l'imprimante 3D) permettant de suivre plus fidèlement l'axe métallique. Ce système sera développé durant les semaines suivants la pré soutenance.

==Motorisation et asservissement en position==
===Besoins et choix des moteurs===
Nous avons besoin de déplacer notre chariot comportant l'outil d'aspiration qui manipule les composants selon les 3 axes de l'espace X, Y et Z. Afin d'assurer les translations dans le plan (X,Y), nous nous sommes orienté vers un système moteur-poulie-courroie sur chacun de ces 2 axes. Nous avons besoin d'une précision en position de l'ordre de 0,2mm et n'avons pas un besoin en couple important, ni d'un asservissement en vitesse spécifique.

Nous avons donc choisi d'utiliser des moteurs Pas à Pas, qui offrent les avantages d'être précis en terme de position angulaire, de pouvoir adapter cette précision en les commandant en micro-pas et surtout de pouvoir réaliser l'asservissement en position sans capteurs. En effet, nous nous baserons sur le comptage du nombre de pas que l'on a fait effectuer au moteur, en supposant qu'aucun pas n'est sauté durant le déplacement. En effet, dans notre application la charge a entrainer est suffisamment faible et le déplacement se fera a une vitesse suffisamment basse afin d'assurer cette hypothèse.

Dans une seconde version, pour être sûr du positionnement et pour palier aux imprécisions (type jeux sur la maquette...) sur la position initiale, la position de la poulie et son diamètre, nous mettrons en place un système d'ajustement via une caméra, où l'utilisateur viendra valider le placement du composant avant dépose sur la carte.

Le déplacement de position est alors déduit ainsi : <math>\Delta X = \mu_{micropas} * \theta_{Pas_{nominal}} * R_{poulie} * \Delta {N_{Pas}}</math>

avec <math>\theta_{Pas_{nominal}}</math> le pas angulaire de nos moteurs en radian (ici, 1,8°=0,031415 rad) ,<math>\mu_{micropas}</math> le facteur de micro-pas choisi (typiquement 1/2, 1/4, voire 1/8), <math>R_{poulie}</math> le rayon du moyen de la poulie crantée en mm (ici 7,15mm) et <math>\Delta {N_{Pas}}</math> le nombre de pas demandé (dans un sens ou dans un autre).

Pour enfin connaitre la position absolue, il s'agit de connaitre la position initiale du chariot. Ceci sera réalisé avec des capteurs "fin de course", type contacteurs à lamelles.

===Commande des moteurs Pas à Pas===

[[Fichier:assp_schema_bipolar_stepper_4.png|140px|thumb|left|Schéma symbolisant les phases et l'arbre du moteur Pas à Pas bipolaire]]
[[Fichier:assp_schema_bipolar_stepper.jpg|300px|thumb|right|Schéma de la séquence d'alimentation complète du moteur bipolaire, en pas complet]]

Le principal inconvénient des moteurs Pas à Pas réside dans la commande de ceux-ci. En effet, un moteur Pas à Pas est un moteur particulier sans balai et alimenté par une alimentation continue. Il comporte plusieurs bobines permettant de créer un champ magnétique à l'intérieur et ainsi d'orienter des aimants fixés au rotor dans la direction du champ magnétique crée, ce qui provoque la rotation de l'arbre. On utilise le terme Pas à Pas car le champ magnétique crée à l'intérieur se fait par incréments. Ainsi pour faire tourner l'arbre entièrement, il faut effectuer l'alimentation des bobines pour une position 1, puis position 2, et ainsi de suite, selon la géométrie et la technologie du moteur utilisées.

Ainsi, le contrôle de celui ci s'effectue par une séquence d'alimentation spécifique de ses différentes phases. Dans notre cas, nous avons choisi des moteurs bipolaires (de type Hybride, c'est à dire combinant les avantages des technologies "à aimant permanent" et à "réluctance variable"). Le sens de rotation des ces moteurs dépend de l'ordre d'alimentation des 2 bobines, ainsi que du sens du courant.

Ce pilotage peut s'effectuer au moyen d'une électronique de puissance type pont en H, sur laquelle on pilote les séquences de commutation des différentes cellules de commutation (transistor + diode en sens inverse en parallèle). Cependant une telle structure est compliquée à mettre en place au niveau des séquences, n'intègre pas directement de limitation active du courant délivré dans la bobine et surtout n'intègre pas directement de variation de courant afin de contrôler le moteur en micro-pas.

Présentant des prix très faibles (environ 5€) pour l'économie de temps et la simplicité d'utilisation qu'ils représentent, nous avons donc cherché des solutions de drivers adaptés à nos moteurs. Basé sur le circuit A4988 d'Allegro, nous nous sommes tourné vers ce driver pour moteur bipolaire (Pololu A4988 Stepper Motor Driver Carrier). Son principe est simple : il intègre directement cette structure de pont en H et les séquences d'alimentation. Il permet ainsi de faire effectuer au moteur un pas en envoyant une impulsion (front montant) sur sa pin STEP, dans le sens défini par l'état (haut ou bas) de sa pin DIR.

[[Fichier:assp_driver_pololu_pinout.png|380px|thumb|centre|Schéma du fonctionnement et du branchement du driver]]

Ce driver réalise également l'interface commande-puissance, il comporte une alimentation séparée pour le circuit logique (5V) et l'alimentation de puissance des moteurs (ici 12V). Il est très important pour éviter la surchauffe et l'endommagement des moteurs de contrôler le courant envoyé dans ses bobines. Nous limitons ainsi activement ce courant grâce au driver au moyen d'un potentiomètre à régler sur ce dernier. Nous avons réglé cette valeur par rapport aux courants nominaux par phase de nos moteurs.

L'avantage majeur de ce driver est qu'il comporte une solution de fonctionnement en micro-pas directement. Par l'état de ses pins MS1, MS2 et MS3, il nous permet de piloter du pas complet, au 1/16 de pas (maximum). Nous ne piloterons pas jusqu'au 1/16 de pas pour des soucis de stabilité du couple mécanique et pour éviter de sauter des pas, 1/4 voire 1/8 de pas devrait être suffisant. Le choix du micropas maximum sera à déterminer avec les tests sur la machine.

Ainsi, nous pilotons toutes ces différentes entrées par le biais d'un Arduino Mega. Plus tard, cet Arduino Mega servira d'interface entre la consigne de position envoyée depuis l'application PC et les moteurs.

[[Fichier:|200px|thumb|right|Photo de la partie commande des moteurs]]

==Création de l'outil de manipulation par aspiration==

L'outil qui viendra attraper et déposer les composants sera composé d'une aiguille fine qui les maintiendra par aspiration. Le système sera donc composé d'une pompe à vide, type pompe d'aquariophilie, peu couteuse, car l'aspiration nécessaire pour maintenir un composant est vraiment très faible. Ce genre de pompe se commande en tout ou rien au moyen d'un interrupteur manuel. Afin de ne pas alterner cycles d'allumage de la pompe pour éviter de l'endommager et surtout d'attendre le temps d'établissement du débit à chaque fois, lors des phases aspiration-dépose, nous utiliserons un distributeur pneumatique qui viendra envoyer ou non la dépression dans le tuyau d'air.

Une partie majeure du travail va consister en la conception de la pièce mécanique, le chariot, qui intégrera les moteurs pour effectuer la translation et la rotation autour de Z, un capteur piézoélectrique qui permettra la détection du contact entre le composant et la carte et qui intégrera un espace prévu à cet effet pour maintenir le tuyau et l'aiguille. Ce chariot sera adaptable au reste du châssis et comportera une partie qui le fixe à la courroie.

Niveau matériel pour cette partie, nous avons pour le moment réuni le distributeur, les tuyaux et l'aiguille. Nous devrions recevoir la pompe sous peu de temps.

==Conception du logiciel==
===Définition du cadre===
Un des buts de ce projet est de concevoir une application permettant de contrôler les différents éléments du projet. Pour cela nous, l'application doit être capable de lire des fichiers standards de création de carte électronique (aussi appelés fichiers Gerber). De plus, nous souhaitions que l'application puisse être utilisé sur n'importe quelle plateforme. Pour cela, nous avons choisi de la développer sous [http://www.qt.io/ Qt]. L’environnement de travail Qt nous permet d'utiliser des objets permettant l'accès à n'importe quel type de matériel sans se soucier de la plateforme de destination. Pour la communication avec les éléments de commande (comme les moteurs) nous avons choisi de n'envoyer des ordres qu'à travers l'Arduino Mega.
===La communication entre le logiciel et l'Arduino Mega===
==Création d'un système sûr pour Arduino Mega==
L'application de bureau que nous avons créé va, comme expliqué précédemment, communiqué avec un Arduino Mega. Cet Arduino s'occupera de la commande de la partie du puissance du reste du système. Ces fonctions sont:
* Commander des moteurs sur les axes X, Y et Z
* Commander de la rotation selon Z
* Contrôler de la pompe
* Définir les paramètres avancés des moteurs (vitesse, précision des micropas)
* S'assurer de ne pas commander un ordre endommageant la machine
===Le protocole de communication===
[[Fichier:ASSP_mega_task_flowchart.png|200px|thumb|right]]Pour permettre de réaliser ces fonctions, l'application communique à travers le port série avec l'Arduino Mega. Le protocole utilisé est rendant le plus compact possible pour limiter le nombre de communications.
L'Arduino Mega ne fonctionne que par tâches (comme décris sur le schéma à droite). La seule possibilité pour l'Arduino de ne pas être dans cette exécution de tâches est d'être interrompu par un contact à lamelle souple (que nous considérons comme prioritaire). Dans ce cas, l'Arduino reste bloqué dans la fonction appelé par l'interruption jusqu'à temps que l'utilisateur valide manuellement la déverrouillage (ce qui permet d'éviter que le système ne puisse s’abîmer).
====Les trames de base====
{| class="wikitable"
|+ Commande d'initialisation d'une tâche (PC->Mega)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Paramètre
| colspan="4" |Fonction appelée
|}
{| class="wikitable"
|+ Commande de réponse d'une tâche (Mega->PC)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Donnée dépendant de la fonction
| colspan="4" | Code de retour
|}
Si le code de retour est différent de 0, les trames de retour 2 et 3 ne sont pas envoyées
{| class="wikitable"
|+ Liste des codes de retour
! scope="col" colspan="5" | Code retourné
! scope="col" rowspan="2" | Nom dans le header
! scope="col" rowspan="2" | Action à prendre
! scope="col" rowspan="2" | Description du code
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| CMD_OK
| Aucune
| La commande s'est exécutée correctement
|-
| 0
| 0
| 0
| 1
| 0x01
| CMD_NOT_KNOWN
| Report immédiat
| La commande demandée n'est pas connue
|-
| 0
| 0
| 1
| 0
| 0x02
| CMD_DEST_UNREACHABLE
| Report immédiat
| L'appel à la commande setDest a le paramètre dest trop grand sur le moteur choisi
|-
| 0
| 0
| 1
| 1
| 0x03
| CMD_LOCK_MIN_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son minimum
|-
| 0
| 1
| 0
| 0
| 0x04
| CMD_LOCK_MAX_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son maximum
|-
| 0
| 0
| 1
| 1
| 0x05
| CMD_LOCK_MIN_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son minimum
|-
| 0
| 1
| 1
| 0
| 0x06
| CMD_LOCK_MAX_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son maximum
|-
| 0
| 1
| 1
| 1
| 0x07
| CMD_LOCK_MIN_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son minimum
|-
| 1
| 0
| 0
| 0
| 0x08
| CMD_LOCK_MAX_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son maximum
|-
| 1
| 0
| 0
| 1
| 0x09
| CMD_LOCK_Z
| Report immédiat ou aucun
| L'aiguille a touché un objet et a dépassé la force maximum à appliquer dessus
|-
| 1
| 0
| 1
| 0
| 0x0A
| WAIT_FOR_NEXT_FRAME
| Report immédiat ou aucun
| La fonction appelée a été comprise, l'Arduino est en attente de la trame suivante.
|}

====Liste des fonctions d'écriture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Paramètre 2
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| setDest
| selectedMotor[2bits]
| destination[16bits]
| Donne la consigne de position en seizième de pas par rapport à l'origine
|-
| 0
| 0
| 0
| 1
| 0x01
| setMS
| selectedMotor[2bits]
| microStep[3bits]
| Donne la consigne du nombre de micropas par tour pour un moteur
|-
| 0
| 0
| 1
| 0
| 0x02
| setPump
| onOff[1bit]
| ∅
| Donne la consigne d'allumage ou d'extinction de la pompe à vide
|-
| 0
| 0
| 1
| 1
| 0x03
| setADC
| adcLevel[10bits]
| ∅
| Donne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 0
| 1
| 0
| 0
| 0x04
| setRelease
| lockToRelease[3bits]
| ∅
| Donne la consigne de déverrouillage d'un nœud précédemment verrouillé
|-
| 0
| 1
| 0
| 1
| 0x05
| setSpeed
| selectedMotor[2bits]
| delayStep[8bits]
| Donne le temps en ms à attendre entre 2 pas (<=> la vitesse du moteur)
|}
{| class="wikitable"
|+ Détails sur la construction des fonctions d'écriture
! scope="col" rowspan="2" | Fonction appelée
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| setDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="8" align="center" | destination[15:8]
| colspan="8" align="center" | destination[7:0]
|-
| setMS
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="5" align="center" | ∅
| colspan="3" align="center" | microStep[2:0]
| colspan="8" align="center" | ∅
|-
| setPump
| colspan="3" align="center" | ∅
| align="center" | onOff
| colspan="16" align="center" | ∅
|-
| setADC
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| setRelease
| align="center" | ∅
| colspan="3" align="center" | lockToRelease[2:0]
| colspan="16" align="center" | ∅
|-
| setSpeed
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|}

====Liste des fonctions de lecture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 1
| 0
| 0
| 0
| 0x08
| getDest
| selectedMotor[2bits]
| Retourne la position d'un moteur donné en seizième de pas par rapport à l'origine
|-
| 1
| 0
| 0
| 1
| 0x09
| getMS
| ∅
| Retourne la consigne du nombre de micropas par tour pour tous les moteurs
|-
| 1
| 0
| 1
| 0
| 0x0A
| getPump
| ∅
| Retourne la consigne d'allumage actuelle de la pompe à vide
|-
| 1
| 0
| 1
| 1
| 0x0B
| getADC
| ∅
| Retourne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 1
| 1
| 0
| 0
| 0x0C
| getRelease
| ∅
| Retourne l'état de verrouillage des nœuds
|-
| 1
| 1
| 0
| 0
| 0x0D
| getADCvalue
| selectedPin[2bits]
| Retourne la valeur convertie par l'ADC de la pin analogique sélectionnée
|-
| 1
| 1
| 0
| 1
| 0x0E
| getSpeed
| selectedMotor[2bits]
| Retourne le délai entre 2 pas choisis pour le moteur sélectionné
|}
{| class="wikitable"
|+ Détails de la construction des trames de lecture
! scope="col" rowspan="3" | Fonction appelée
! scope="col" colspan="4" | Appel (PC->Mega)
! scope="col" colspan="24" | Retour (Mega->PC)
|-
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| getDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | dest[15:8]
| colspan="8" align="center" | dest[7:0]
|-
| getMS
| colspan="4" align="center" | ∅
| msY[0]
| colspan="3" align="center" | msX[2:0]
| colspan="3" align="center" | msR[2:0]
| colspan="3" align="center" | msZ[2:0]
| colspan="2" align="center" | msY[2:1]
| colspan="8" align="center" | ∅
|-
| getPump
| colspan="3" align="center" | ∅
| onOff
| colspan="4" align="center" | ∅
| colspan="8" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getADC
| colspan="4" align="center" | ∅
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| getRelease
| colspan="4" align="center" | ∅
| lockMinX1
| lockMaxX1
| lockMinX2
| lockMaxX2
| colspan="6" align="center" | ∅
| lockMinY
| lockMaxY
| colspan="8" align="center" | ∅
|-
| getADCvalue
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedPin[1:0]
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcValue[9:8]
| colspan="8" align="center" | adcValue[7:0]
| colspan="8" align="center" | ∅
|-
| getSpeed
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|}

Automatic Soldering System Project

2016-02-11T13:22:48Z

Pletouse : /* Le protocole de communication */ Protocole des trames simplifié

__TOC__
 
=Placeur de composants sur PCB=
==Présentation du projet==
Durant le début de l'été, nous avons eu l'idée de proposer un projet de soudure automatique. Ce projet avait pour but de concevoir un système permettant l'automatisation des soudures sur une carte électronique à composants traversants. Après des échanges avec le responsable des projet de 5éme année, M. Vantroys, nous avons finalement abandonné notre projet au profit d'un autre projet assez proche.

L'idée du nouveau projet est de proposer un système de Pick & Place de composants CMS sur une carte électronique sur laquelle de la crème à braser est préalablement déposée sur les pastilles. Pour mener à bien ce projet, nous avons été épaulé par M. Redon, M. Vantroys et M. Boé. En plus de nos encadrants école, nous avons travaillé en étroite collaboration avec M. Flamen, responsable du service électronique de Polytech Lille ainsi qu'avec M. Astori, enseignant en Conception Mécanique et responsable du FabLab de Polytech Lille. Nous tenons par ailleurs également à remercier chaleureusement Antoine, contributeur actif au Fablab de Polytech Lille, pour son partage d'expérience à propos de la création de son imprimante 3D RepRap, projet similaire au notre.
===Définitions des objectifs===
*Prendre un composant
**Stocker les composants à déposer sur la carte et identifier leur position
**Maintenir le composant par aspiration
*Repérer la position et l’orientation de la carte
*Déplacer le composant
**Le déplacer en translation selon les axes X, Y et Z
**L’orienter correctement sur les pastilles (rotation autour de Z)
*Déposer le composant
**S’assurer que l’outil d’aspiration n’endommage ni la carte, ni le composant lors de la dépose -> détecter le contact entre le composant et la carte
*Connaître la position désirée pour la dépose du composant
**Récupérer les fichiers provenant du logiciel de CAO et les transformer en déplacement de la machine
**Permettre à l’utilisateur d’avoir une interface visuelle (sur ordinateur) indiquant l’état des éléments de la machine et permettant leur calibrage
===Liste des tâches===
*Créer l’infrastructure mécanique de la machine (châssis)
**Fabrication du châssis
**Design des pièces mobiles et impression 3D de ces pièces au FabLab (chariot comportant l’outil d’aspiration et “guides tubes” assurant la transformation de la rotation des moteurs en mouvement de translation (glissières) sur des barres métalliques)
**Assembler l’outil d’aspiration au chariot
*Concevoir la commande d’aspiration par pompe
*Organiser la commande des moteurs du système pour l’asservissement en position de la machine
**Étude et prise en main des drivers pour les moteurs Pas à Pas
*Réalisation de l’interface commande-puissance
*Réaliser la conversion des données de position (relatives) de l’emplacement souhaités des composants en mouvements pour la machine
**Concevoir l’interface de récupération des données du fichier Gerber de l’utilisateur
**Caractérisation des différents repères (repère de la machine, repère de l’outil et repère de la carte) et établir le lien entres eux
**Détecter l’origine du repère de la carte au moyen d’une caméra fixe
===Planning prévisionnel de répartition du travail===
{| class="wikitable alternance centre"
|-
! scope="row" | Semaine 39 (21/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 40 (28/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 41 (05/10)
| Dimensionnement des éléments du système et recherche du matériel à commander en tenant compte des contraintes de coût
|-
! scope="row" | Semaine 42 (12/10)
| Achat du matériel pour le châssis de la machine (bois, tiges métalliques...) et pré-assemblage / Conception des pièces mécaniques à imprimer au FabLab
|-
! scope="row" | Semaine 43 (19/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position
|-
! scope="row" | Semaine 44 (26/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 45 (02/11)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de la commande des moteurs et du repérage caméra
|-
! scope="row" | Semaine 46 (09/11)
| Dans l'attente de la réception du matériel commandé : Fabrication du châssis - assemblage des pièces / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 47 (16/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 48 (23/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 49 (30/11)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 50 (07/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 51 (14/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 52 (21/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 53 (28/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 01 (04/01)
|
|-
! scope="row" | Semaine 02 (11/01)
|
|-
! scope="row" | Semaine 03 (18/01)
|
|-
! scope="row" | Semaine 04 (25/01)
|
|-
! scope="row" | Semaine 05 (01/02)
|
|-
! scope="row" | Semaine 06 (08/02)
|
|-
! scope="row" | Semaine 07 (15/02)
|
|-
! scope="row" | Semaine 08 (22/02)
|
|-
|}

===Retour sur les directives des encadrants===
====M. Flamen====
[[Fichier:Exemple composant cms.jpg|200px|thumb|right|Exemple de composants CMS]]
Dans un premier temps, pour mieux définir les objectifs de notre projet, nous avons pris rendez vous avec M. Flamen. M. Flamen est le responsable du service électronique de PolytechLille. Il est le principal intéressé par notre projet car celui-ci (le projet) permettrait de disposer de la chaîne complète de fabrication de cartes électroniques CMS (composants montés en surface).

Cette rencontre avec M. Flamen nous a permis de déterminer certaines précisions, comme:
* La précision maximale demandé n'excédera pas 0,2 mm (précision de classe 5, qui est celle de la graveuse de carte du service EEI).

===Liste de matériel===
====Matériel disponible====
*Support
** 3 Tiges de 1 mètre [Reçu le 2015-10-12]
** 1 Tasseau de 2m70 (découpé pour fabriquer les supports des tiges) [Reçu le 2015-10-12]
** 1 Planche en bois pour effectuer le support du projet [Reçu le 2015-10-12]
*Motorisation
**2 Moteurs Pas à Pas type NEMA 17 (pour axes X et Y) [http://www.gotronic.fr/art-moteur-17hs15-0404s-18354.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas (pour rotation autour de Z) [http://www.gotronic.fr/art-moteur-24byj48-19028.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas avec glissière intégrée (pour translation selon Z) [http://www.gotronic.fr/art-moteur-pas-a-pas-a-glissiere-800180001-21817.htm][Reçu le 2015-11-09]
**4 drivers pour moteur Pas à Pas bipolaire [http://www.gotronic.fr/art-driver-de-moteur-pas-a-pas-a4988-1182-21718.htm][Reçu le 2015-11-09]
*Outil d'aspiration
**Aiguille manipulant le composant [http://www.gotronic.fr/art-jeu-de-4-aiguilles-eso12-7428.htm][Reçu le 2015-11-09]
**Tube flexible [http://fr.rs-online.com/web/p/tubes-flexibles/7989985/][Reçu le 2015-11-09]
*Châssis mécanique
**2 Courroies crantées [http://fr.rs-online.com/web/p/courroies-crantees/4749614/][Reçu le 2015-11-09]
**4 Poulies crantées [http://fr.rs-online.com/web/p/poulies-pour-courroies-crantees/0182565/][Reçu le 2015-11-09]
*2 Courroies crantées plus grandes [Reçu le 2015-12-27]
====Matériel manquant====
* Rien pour le moment

==Fabrication de l'infrastructure mécanique==
[[Fichier:assp_usinage1.jpg|200px|thumb|left|Usinage des pylônes à la perceuse à colonne]]
[[Fichier:assp_usinage2.jpg|200px|thumb|right|Tour conventionnel utilisé pour le perçage]]
[[Fichier:assp_usinage3.jpg|200px|thumb|left|Marquages sur le support pour la pose de pylônes]]
[[Fichier:assp_usinage4.jpg|200px|thumb|right|Etat de la maquette avant la fixation finale]]
Notre projet comprend une partie extrêmement importante de conception. Sur conseils de M. Astori, nous avons donc décidé d'utiliser une organisation plus particulière. Le principe de cette organisation est de créer des pièces (on parle ici uniquement de leur impression à l'imprimante 3D et de la phase de conception sous Catia) rapidement, avec une faible taux de remplissage (de l'ordre de 30%). Le but de cette méthode est de créer un nombre de pièces plus important, permettant plus facilement rectifications en fonction des remarques que nous tirons du montage.

===La partie usinage===
Nous avons commencé par acheter une support contreplaqué en bois. Sur ce support, nous avons disposé quatre pylônes reliés deux à deux par un axe métallique. Nous avons donc découpé à la scie à chantourner plusieurs linteaux de bois pour fabriquer les pylônes. Ensuite, nous avons usiné les pylônes à l'aide d'une perceuse à colonne pour leur permettre de recevoir l'axe métallique.

Ensuite, nous avons eu la surprise de recevoir des poulies non percées. Nous avons donc du les percer. Nous avons percé les deux premières à l'aide de la perceuse à colonne. Le désavantage de cet outil est son imprécision sur la largeur de perçage. De plus, il n'était pas possible d'y ajouter un mécanisme permettant son maintien au moteur. Par conséquent, nous avons eu la chance d'être aidé par l'atelier mécanique. Ainsi, nous avons usiné les deux dernières poulies à l'aide d'un tour conventionnel (sous la supervision du responsable de l'atelier mécanique). Nous avons ensuite, toujours avec l'aide de M.Yoan Dhont, percé les deux poulies selon un axe perpendiculaire au précédent et créé un filetage pour permettre l'insertion d'une vis sans tête pour assurer la fixation au moteur.

Pour des raisons pratiques et esthétiques, nous avons demandé à la menuiserie de Polytech Lille de corriger nos pylônes pour assurer leur perpendicularité. Cette correction a été effectuée par M. David [TODO] et M. JP [TODO] à l'aide d'une scie à bande. Par la suite, nous avons marqué le support pour faciliter le perçage et l'ajustement des pylônes. Une fois les marquages, nous avons percé le support et les pylônes pour assurer une bonne fixation.

===La partie impression===
[[Fichier:assp_impression1.png|200px|thumb|left|Version 1 et 2 du guide axe avec moteur]]
[[Fichier:assp_impression2.png|180px|thumb|right|Guide axe antagoniste (sans moteur)]]
[[Fichier:assp_impression3.png|200px|thumb|left|Guide de poulie et garde moteur]]
Nous avons commencé par créé un chariot permettant le déplacement selon l'axe X, et permettant d'embarquer le moteur pour le déplacement selon Y. Nous l'avons créé à l'aide du logiciel Catia. Les cotes imposés sur le schéma sont celles fournies par la documentation et par mesure des axes métalliques au pieds à coulisse.

Après impression, nous nous sommes aperçu que la documentation comprenait une erreur importante sur la taille des moteurs, nous obligeant à réimprimer une deuxième pièce. Nous avons profiter de la deuxième impression pour réduire la surface de contexte entre l'axe X de la pièce et l'axe métallique X.

La deuxième pièce est très identique à la première à la différence près qu'elle n'embarque pas de moteur. Elle embarque uniquement une poulie permettant le passage de la courroie de transport en Y. Cette version, bien que fonctionnelle, n'a pas eu (pour le moment) l'amélioration apportée par la deuxième version de la pièce 1 (c'est à dire la réduction de surface de contact).

Les deux dernières pièces sont des pièces de support pour permettre au moteur de l'axe X et à la poulie de l'axe X de se maintenir sur leur pylône respectif. Le support de poulie n'a tenu que deux jours avant de rendre l'âme. Nous avons donc remplacé de façon temporaire son axe par une longue vis à bois. Le support de moteur n'a, lui, pas cassé, mais nécessite d'être imprimer une deuxième fois car la documentation du moteur était incorrecte (encore une fois).

Quelques jours avant la pré soutenance, les pièces semblent fonctionnelles. Une amélioration peut être apportée dans un second temps en modifiant les guide d'axe par des poulies (imprimées à l'imprimante 3D) permettant de suivre plus fidèlement l'axe métallique. Ce système sera développé durant les semaines suivants la pré soutenance.

==Motorisation et asservissement en position==
===Besoins et choix des moteurs===
Nous avons besoin de déplacer notre chariot comportant l'outil d'aspiration qui manipule les composants selon les 3 axes de l'espace X, Y et Z. Afin d'assurer les translations dans le plan (X,Y), nous nous sommes orienté vers un système moteur-poulie-courroie sur chacun de ces 2 axes. Nous avons besoin d'une précision en position de l'ordre de 0,2mm et n'avons pas un besoin en couple important, ni d'un asservissement en vitesse spécifique.

Nous avons donc choisi d'utiliser des moteurs Pas à Pas, qui offrent les avantages d'être précis en terme de position angulaire, de pouvoir adapter cette précision en les commandant en micro-pas et surtout de pouvoir réaliser l'asservissement en position sans capteurs. En effet, nous nous baserons sur le comptage du nombre de pas que l'on a fait effectuer au moteur, en supposant qu'aucun pas n'est sauté durant le déplacement. En effet, dans notre application la charge a entrainer est suffisamment faible et le déplacement se fera a une vitesse suffisamment basse afin d'assurer cette hypothèse.

Dans une seconde version, pour être sûr du positionnement et pour palier aux imprécisions (type jeux sur la maquette...) sur la position initiale, la position de la poulie et son diamètre, nous mettrons en place un système d'ajustement via une caméra, où l'utilisateur viendra valider le placement du composant avant dépose sur la carte.

Le déplacement de position est alors déduit ainsi : <math>\Delta X = \mu_{micropas} * \theta_{Pas_{nominal}} * R_{poulie} * \Delta {N_{Pas}}</math>

avec <math>\theta_{Pas_{nominal}}</math> le pas angulaire de nos moteurs en radian (ici, 1,8°=0,031415 rad) ,<math>\mu_{micropas}</math> le facteur de micro-pas choisi (typiquement 1/2, 1/4, voire 1/8), <math>R_{poulie}</math> le rayon du moyen de la poulie crantée en mm (ici 7,15mm) et <math>\Delta {N_{Pas}}</math> le nombre de pas demandé (dans un sens ou dans un autre).

Pour enfin connaitre la position absolue, il s'agit de connaitre la position initiale du chariot. Ceci sera réalisé avec des capteurs "fin de course", type contacteurs à lamelles.

===Commande des moteurs Pas à Pas===

[[Fichier:assp_schema_bipolar_stepper_4.png|140px|thumb|left|Schéma symbolisant les phases et l'arbre du moteur Pas à Pas bipolaire]]
[[Fichier:assp_schema_bipolar_stepper.jpg|300px|thumb|right|Schéma de la séquence d'alimentation complète du moteur bipolaire, en pas complet]]

Le principal inconvénient des moteurs Pas à Pas réside dans la commande de ceux-ci. En effet, un moteur Pas à Pas est un moteur particulier sans balai et alimenté par une alimentation continue. Il comporte plusieurs bobines permettant de créer un champ magnétique à l'intérieur et ainsi d'orienter des aimants fixés au rotor dans la direction du champ magnétique crée, ce qui provoque la rotation de l'arbre. On utilise le terme Pas à Pas car le champ magnétique crée à l'intérieur se fait par incréments. Ainsi pour faire tourner l'arbre entièrement, il faut effectuer l'alimentation des bobines pour une position 1, puis position 2, et ainsi de suite, selon la géométrie et la technologie du moteur utilisées.

Ainsi, le contrôle de celui ci s'effectue par une séquence d'alimentation spécifique de ses différentes phases. Dans notre cas, nous avons choisi des moteurs bipolaires (de type Hybride, c'est à dire combinant les avantages des technologies "à aimant permanent" et à "réluctance variable"). Le sens de rotation des ces moteurs dépend de l'ordre d'alimentation des 2 bobines, ainsi que du sens du courant.

Ce pilotage peut s'effectuer au moyen d'une électronique de puissance type pont en H, sur laquelle on pilote les séquences de commutation des différentes cellules de commutation (transistor + diode en sens inverse en parallèle). Cependant une telle structure est compliquée à mettre en place au niveau des séquences, n'intègre pas directement de limitation active du courant délivré dans la bobine et surtout n'intègre pas directement de variation de courant afin de contrôler le moteur en micro-pas.

Présentant des prix très faibles (environ 5€) pour l'économie de temps et la simplicité d'utilisation qu'ils représentent, nous avons donc cherché des solutions de drivers adaptés à nos moteurs. Basé sur le circuit A4988 d'Allegro, nous nous sommes tourné vers ce driver pour moteur bipolaire (Pololu A4988 Stepper Motor Driver Carrier). Son principe est simple : il intègre directement cette structure de pont en H et les séquences d'alimentation. Il permet ainsi de faire effectuer au moteur un pas en envoyant une impulsion (front montant) sur sa pin STEP, dans le sens défini par l'état (haut ou bas) de sa pin DIR.

[[Fichier:assp_driver_pololu_pinout.png|380px|thumb|centre|Schéma du fonctionnement et du branchement du driver]]

Ce driver réalise également l'interface commande-puissance, il comporte une alimentation séparée pour le circuit logique (5V) et l'alimentation de puissance des moteurs (ici 12V). Il est très important pour éviter la surchauffe et l'endommagement des moteurs de contrôler le courant envoyé dans ses bobines. Nous limitons ainsi activement ce courant grâce au driver au moyen d'un potentiomètre à régler sur ce dernier. Nous avons réglé cette valeur par rapport aux courants nominaux par phase de nos moteurs.

L'avantage majeur de ce driver est qu'il comporte une solution de fonctionnement en micro-pas directement. Par l'état de ses pins MS1, MS2 et MS3, il nous permet de piloter du pas complet, au 1/16 de pas (maximum). Nous ne piloterons pas jusqu'au 1/16 de pas pour des soucis de stabilité du couple mécanique et pour éviter de sauter des pas, 1/4 voire 1/8 de pas devrait être suffisant. Le choix du micropas maximum sera à déterminer avec les tests sur la machine.

Ainsi, nous pilotons toutes ces différentes entrées par le biais d'un Arduino Mega. Plus tard, cet Arduino Mega servira d'interface entre la consigne de position envoyée depuis l'application PC et les moteurs.

[[Fichier:|200px|thumb|right|Photo de la partie commande des moteurs]]

==Création de l'outil de manipulation par aspiration==

L'outil qui viendra attraper et déposer les composants sera composé d'une aiguille fine qui les maintiendra par aspiration. Le système sera donc composé d'une pompe à vide, type pompe d'aquariophilie, peu couteuse, car l'aspiration nécessaire pour maintenir un composant est vraiment très faible. Ce genre de pompe se commande en tout ou rien au moyen d'un interrupteur manuel. Afin de ne pas alterner cycles d'allumage de la pompe pour éviter de l'endommager et surtout d'attendre le temps d'établissement du débit à chaque fois, lors des phases aspiration-dépose, nous utiliserons un distributeur pneumatique qui viendra envoyer ou non la dépression dans le tuyau d'air.

Une partie majeure du travail va consister en la conception de la pièce mécanique, le chariot, qui intégrera les moteurs pour effectuer la translation et la rotation autour de Z, un capteur piézoélectrique qui permettra la détection du contact entre le composant et la carte et qui intégrera un espace prévu à cet effet pour maintenir le tuyau et l'aiguille. Ce chariot sera adaptable au reste du châssis et comportera une partie qui le fixe à la courroie.

Niveau matériel pour cette partie, nous avons pour le moment réuni le distributeur, les tuyaux et l'aiguille. Nous devrions recevoir la pompe sous peu de temps.

==Conception du logiciel==
===Définition du cadre===
Un des buts de ce projet est de concevoir une application permettant de contrôler les différents éléments du projet. Pour cela nous, l'application doit être capable de lire des fichiers standards de création de carte électronique (aussi appelés fichiers Gerber). De plus, nous souhaitions que l'application puisse être utilisé sur n'importe quelle plateforme. Pour cela, nous avons choisi de la développer sous [http://www.qt.io/ Qt]. L’environnement de travail Qt nous permet d'utiliser des objets permettant l'accès à n'importe quel type de matériel sans se soucier de la plateforme de destination. Pour la communication avec les éléments de commande (comme les moteurs) nous avons choisi de n'envoyer des ordres qu'à travers l'Arduino Mega.
===La communication entre le logiciel et l'Arduino Mega===
==Création d'un système sûr pour Arduino Mega==
L'application de bureau que nous avons créé va, comme expliqué précédemment, communiqué avec un Arduino Mega. Cet Arduino s'occupera de la commande de la partie du puissance du reste du système. Ces fonctions sont:
* Commander des moteurs sur les axes X, Y et Z
* Commander de la rotation selon Z
* Contrôler de la pompe
* Définir les paramètres avancés des moteurs (vitesse, précision des micropas)
* S'assurer de ne pas commander un ordre endommageant la machine
===Le protocole de communication===
[[Fichier:ASSP_mega_task_flowchart.png|200px|thumb|right]]Pour permettre de réaliser ces fonctions, l'application communique à travers le port série avec l'Arduino Mega. Le protocole utilisé est rendant le plus compact possible pour limiter le nombre de communications.
L'Arduino Mega ne fonctionne que par tâches (comme décris sur le schéma à droite). La seule possibilité pour l'Arduino de ne pas être dans cette exécution de tâches est d'être interrompu par un contact à lamelle souple (que nous considérons comme prioritaire). Dans ce cas, l'Arduino reste bloqué dans la fonction appelé par l'interruption jusqu'à temps que l'utilisateur valide manuellement la déverrouillage (ce qui permet d'éviter que le système ne puisse s’abîmer).
====Les trames de base====
{| class="wikitable"
|+ Commande d'initialisation d'une tâche (PC->Mega)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Paramètre
| colspan="4" |Fonction appelée
|}
{| class="wikitable"
|+ Commande de réponse d'une tâche (Mega->PC)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Donnée dépendant de la fonction
| colspan="4" | Code de retour
|}
Si le code de retour est différent de 0, les trames de retour 2 et 3 ne sont pas envoyées
{| class="wikitable"
|+ Liste des codes de retour
! scope="col" colspan="5" | Code retourné
! scope="col" rowspan="2" | Nom dans le header
! scope="col" rowspan="2" | Action à prendre
! scope="col" rowspan="2" | Description du code
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| CMD_OK
| Aucune
| La commande s'est exécutée correctement
|-
| 0
| 0
| 0
| 1
| 0x01
| CMD_NOT_KNOWN
| Report immédiat
| La commande demandée n'est pas connue
|-
| 0
| 0
| 1
| 0
| 0x02
| CMD_DEST_UNREACHABLE
| Report immédiat
| L'appel à la commande setDest a le paramètre dest trop grand sur le moteur choisi
|-
| 0
| 0
| 1
| 1
| 0x03
| CMD_LOCK_MIN_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son minimum
|-
| 0
| 1
| 0
| 0
| 0x04
| CMD_LOCK_MAX_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son maximum
|-
| 0
| 0
| 1
| 1
| 0x05
| CMD_LOCK_MIN_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son minimum
|-
| 0
| 1
| 1
| 0
| 0x06
| CMD_LOCK_MAX_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son maximum
|-
| 0
| 1
| 1
| 1
| 0x07
| CMD_LOCK_MIN_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son minimum
|-
| 1
| 0
| 0
| 0
| 0x08
| CMD_LOCK_MAX_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son maximum
|-
| 1
| 0
| 0
| 1
| 0x09
| CMD_LOCK_Z
| Report immédiat ou aucun
| L'aiguille a touché un objet et a dépassé la force maximum à appliquer dessus
|-
| 1
| 0
| 1
| 0
| 0x0A
| WAIT_FOR_NEXT_FRAME
| Report immédiat ou aucun
| La fonction appelée a été comprise, l'Arduino est en attente de la trame suivante.
|}

====Liste des fonctions d'écriture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Paramètre 2
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| setDest
| selectedMotor[2bits]
| destination[16bits]
| Donne la consigne de position en seizième de pas par rapport à l'origine
|-
| 0
| 0
| 0
| 1
| 0x01
| setMS
| selectedMotor[2bits]
| microStep[3bits]
| Donne la consigne du nombre de micropas par tour pour un moteur
|-
| 0
| 0
| 1
| 0
| 0x02
| setPump
| onOff[1bit]
| ∅
| Donne la consigne d'allumage ou d'extinction de la pompe à vide
|-
| 0
| 0
| 1
| 1
| 0x03
| setADC
| adcLevel[10bits]
| ∅
| Donne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 0
| 1
| 0
| 0
| 0x04
| setRelease
| lockToRelease[3bits]
| ∅
| Donne la consigne de déverrouillage d'un nœud précédemment verrouillé
|-
| 0
| 1
| 0
| 1
| 0x05
| setSpeed
| selectedMotor[2bits]
| delayStep[8bits]
| Donne le temps en ms à attendre entre 2 pas (<=> la vitesse du moteur)
|}
{| class="wikitable"
|+ Détails sur la construction des fonctions d'écriture
! scope="col" rowspan="2" | Fonction appelée
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| setDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="8" align="center" | destination[15:8]
| colspan="8" align="center" | destination[7:0]
|-
| setMS
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="5" align="center" | ∅
| colspan="3" align="center" | microStep[2:0]
| colspan="8" align="center" | ∅
|-
| setPump
| colspan="3" align="center" | ∅
| align="center" | onOff
| colspan="16" align="center" | ∅
|-
| setADC
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| setRelease
| align="center" | ∅
| colspan="3" align="center" | lockToRelease[2:0]
| colspan="16" align="center" | ∅
|-
| setSpeed
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|}

====Liste des fonctions de lecture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 1
| 0
| 0
| 0
| 0x08
| getDest
| selectedMotor[2bits]
| Retourne la position d'un moteur donné en seizième de pas par rapport à l'origine
|-
| 1
| 0
| 0
| 1
| 0x09
| getMS
| ∅
| Retourne la consigne du nombre de micropas par tour pour tous les moteurs
|-
| 1
| 0
| 1
| 0
| 0x0A
| getPump
| ∅
| Retourne la consigne d'allumage actuelle de la pompe à vide
|-
| 1
| 0
| 1
| 1
| 0x0B
| getADC
| ∅
| Retourne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 1
| 1
| 0
| 0
| 0x0C
| getRelease
| ∅
| Retourne l'état de verrouillage des nœuds
|-
| 1
| 1
| 0
| 0
| 0x0D
| getADCvalue
| selectedPin[2bits]
| Retourne la valeur convertie par l'ADC de la pin analogique selectionnée
|}
{| class="wikitable"
|+ Détails de la construction des trames de lecture
! scope="col" rowspan="3" | Fonction appelée
! scope="col" colspan="4" | Appel (PC->Mega)
! scope="col" colspan="24" | Retour (Mega->PC)
|-
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| getDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | dest[15:8]
| colspan="8" align="center" | dest[7:0]
|-
| getMS
| colspan="4" align="center" | ∅
| msY[0]
| colspan="3" align="center" | msX[2:0]
| colspan="3" align="center" | msR[2:0]
| colspan="3" align="center" | msZ[2:0]
| colspan="2" align="center" | msY[2:1]
| colspan="8" align="center" | ∅
|-
| getPump
| colspan="3" align="center" | ∅
| onOff
| colspan="4" align="center" | ∅
| colspan="8" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getADC
| colspan="4" align="center" | ∅
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| getRelease
| colspan="4" align="center" | ∅
| lockMinX1
| lockMaxX1
| lockMinX2
| lockMaxX2
| colspan="6" align="center" | ∅
| lockMinY
| lockMaxY
| colspan="8" align="center" | ∅
|-
| getADCvalue
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedPin[1:0]
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcValue[9:8]
| colspan="8" align="center" | adcValue[7:0]
| colspan="8" align="center" | ∅
|}

Automatic Soldering System Project

2016-02-11T07:30:04Z

Pletouse : /* Le protocole de communication */ Ajout codes retour et fonctions

__TOC__
 
=Placeur de composants sur PCB=
==Présentation du projet==
Durant le début de l'été, nous avons eu l'idée de proposer un projet de soudure automatique. Ce projet avait pour but de concevoir un système permettant l'automatisation des soudures sur une carte électronique à composants traversants. Après des échanges avec le responsable des projet de 5éme année, M. Vantroys, nous avons finalement abandonné notre projet au profit d'un autre projet assez proche.

L'idée du nouveau projet est de proposer un système de Pick & Place de composants CMS sur une carte électronique sur laquelle de la crème à braser est préalablement déposée sur les pastilles. Pour mener à bien ce projet, nous avons été épaulé par M. Redon, M. Vantroys et M. Boé. En plus de nos encadrants école, nous avons travaillé en étroite collaboration avec M. Flamen, responsable du service électronique de Polytech Lille ainsi qu'avec M. Astori, enseignant en Conception Mécanique et responsable du FabLab de Polytech Lille. Nous tenons par ailleurs également à remercier chaleureusement Antoine, contributeur actif au Fablab de Polytech Lille, pour son partage d'expérience à propos de la création de son imprimante 3D RepRap, projet similaire au notre.
===Définitions des objectifs===
*Prendre un composant
**Stocker les composants à déposer sur la carte et identifier leur position
**Maintenir le composant par aspiration
*Repérer la position et l’orientation de la carte
*Déplacer le composant
**Le déplacer en translation selon les axes X, Y et Z
**L’orienter correctement sur les pastilles (rotation autour de Z)
*Déposer le composant
**S’assurer que l’outil d’aspiration n’endommage ni la carte, ni le composant lors de la dépose -> détecter le contact entre le composant et la carte
*Connaître la position désirée pour la dépose du composant
**Récupérer les fichiers provenant du logiciel de CAO et les transformer en déplacement de la machine
**Permettre à l’utilisateur d’avoir une interface visuelle (sur ordinateur) indiquant l’état des éléments de la machine et permettant leur calibrage
===Liste des tâches===
*Créer l’infrastructure mécanique de la machine (châssis)
**Fabrication du châssis
**Design des pièces mobiles et impression 3D de ces pièces au FabLab (chariot comportant l’outil d’aspiration et “guides tubes” assurant la transformation de la rotation des moteurs en mouvement de translation (glissières) sur des barres métalliques)
**Assembler l’outil d’aspiration au chariot
*Concevoir la commande d’aspiration par pompe
*Organiser la commande des moteurs du système pour l’asservissement en position de la machine
**Étude et prise en main des drivers pour les moteurs Pas à Pas
*Réalisation de l’interface commande-puissance
*Réaliser la conversion des données de position (relatives) de l’emplacement souhaités des composants en mouvements pour la machine
**Concevoir l’interface de récupération des données du fichier Gerber de l’utilisateur
**Caractérisation des différents repères (repère de la machine, repère de l’outil et repère de la carte) et établir le lien entres eux
**Détecter l’origine du repère de la carte au moyen d’une caméra fixe
===Planning prévisionnel de répartition du travail===
{| class="wikitable alternance centre"
|-
! scope="row" | Semaine 39 (21/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 40 (28/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 41 (05/10)
| Dimensionnement des éléments du système et recherche du matériel à commander en tenant compte des contraintes de coût
|-
! scope="row" | Semaine 42 (12/10)
| Achat du matériel pour le châssis de la machine (bois, tiges métalliques...) et pré-assemblage / Conception des pièces mécaniques à imprimer au FabLab
|-
! scope="row" | Semaine 43 (19/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position
|-
! scope="row" | Semaine 44 (26/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 45 (02/11)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de la commande des moteurs et du repérage caméra
|-
! scope="row" | Semaine 46 (09/11)
| Dans l'attente de la réception du matériel commandé : Fabrication du châssis - assemblage des pièces / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 47 (16/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 48 (23/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 49 (30/11)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 50 (07/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 51 (14/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 52 (21/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 53 (28/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 01 (04/01)
|
|-
! scope="row" | Semaine 02 (11/01)
|
|-
! scope="row" | Semaine 03 (18/01)
|
|-
! scope="row" | Semaine 04 (25/01)
|
|-
! scope="row" | Semaine 05 (01/02)
|
|-
! scope="row" | Semaine 06 (08/02)
|
|-
! scope="row" | Semaine 07 (15/02)
|
|-
! scope="row" | Semaine 08 (22/02)
|
|-
|}

===Retour sur les directives des encadrants===
====M. Flamen====
[[Fichier:Exemple composant cms.jpg|200px|thumb|right|Exemple de composants CMS]]
Dans un premier temps, pour mieux définir les objectifs de notre projet, nous avons pris rendez vous avec M. Flamen. M. Flamen est le responsable du service électronique de PolytechLille. Il est le principal intéressé par notre projet car celui-ci (le projet) permettrait de disposer de la chaîne complète de fabrication de cartes électroniques CMS (composants montés en surface).

Cette rencontre avec M. Flamen nous a permis de déterminer certaines précisions, comme:
* La précision maximale demandé n'excédera pas 0,2 mm (précision de classe 5, qui est celle de la graveuse de carte du service EEI).

===Liste de matériel===
====Matériel disponible====
*Support
** 3 Tiges de 1 mètre [Reçu le 2015-10-12]
** 1 Tasseau de 2m70 (découpé pour fabriquer les supports des tiges) [Reçu le 2015-10-12]
** 1 Planche en bois pour effectuer le support du projet [Reçu le 2015-10-12]
*Motorisation
**2 Moteurs Pas à Pas type NEMA 17 (pour axes X et Y) [http://www.gotronic.fr/art-moteur-17hs15-0404s-18354.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas (pour rotation autour de Z) [http://www.gotronic.fr/art-moteur-24byj48-19028.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas avec glissière intégrée (pour translation selon Z) [http://www.gotronic.fr/art-moteur-pas-a-pas-a-glissiere-800180001-21817.htm][Reçu le 2015-11-09]
**4 drivers pour moteur Pas à Pas bipolaire [http://www.gotronic.fr/art-driver-de-moteur-pas-a-pas-a4988-1182-21718.htm][Reçu le 2015-11-09]
*Outil d'aspiration
**Aiguille manipulant le composant [http://www.gotronic.fr/art-jeu-de-4-aiguilles-eso12-7428.htm][Reçu le 2015-11-09]
**Tube flexible [http://fr.rs-online.com/web/p/tubes-flexibles/7989985/][Reçu le 2015-11-09]
*Châssis mécanique
**2 Courroies crantées [http://fr.rs-online.com/web/p/courroies-crantees/4749614/][Reçu le 2015-11-09]
**4 Poulies crantées [http://fr.rs-online.com/web/p/poulies-pour-courroies-crantees/0182565/][Reçu le 2015-11-09]
*2 Courroies crantées plus grandes [Reçu le 2015-12-27]
====Matériel manquant====
* Rien pour le moment

==Fabrication de l'infrastructure mécanique==
[[Fichier:assp_usinage1.jpg|200px|thumb|left|Usinage des pylônes à la perceuse à colonne]]
[[Fichier:assp_usinage2.jpg|200px|thumb|right|Tour conventionnel utilisé pour le perçage]]
[[Fichier:assp_usinage3.jpg|200px|thumb|left|Marquages sur le support pour la pose de pylônes]]
[[Fichier:assp_usinage4.jpg|200px|thumb|right|Etat de la maquette avant la fixation finale]]
Notre projet comprend une partie extrêmement importante de conception. Sur conseils de M. Astori, nous avons donc décidé d'utiliser une organisation plus particulière. Le principe de cette organisation est de créer des pièces (on parle ici uniquement de leur impression à l'imprimante 3D et de la phase de conception sous Catia) rapidement, avec une faible taux de remplissage (de l'ordre de 30%). Le but de cette méthode est de créer un nombre de pièces plus important, permettant plus facilement rectifications en fonction des remarques que nous tirons du montage.

===La partie usinage===
Nous avons commencé par acheter une support contreplaqué en bois. Sur ce support, nous avons disposé quatre pylônes reliés deux à deux par un axe métallique. Nous avons donc découpé à la scie à chantourner plusieurs linteaux de bois pour fabriquer les pylônes. Ensuite, nous avons usiné les pylônes à l'aide d'une perceuse à colonne pour leur permettre de recevoir l'axe métallique.

Ensuite, nous avons eu la surprise de recevoir des poulies non percées. Nous avons donc du les percer. Nous avons percé les deux premières à l'aide de la perceuse à colonne. Le désavantage de cet outil est son imprécision sur la largeur de perçage. De plus, il n'était pas possible d'y ajouter un mécanisme permettant son maintien au moteur. Par conséquent, nous avons eu la chance d'être aidé par l'atelier mécanique. Ainsi, nous avons usiné les deux dernières poulies à l'aide d'un tour conventionnel (sous la supervision du responsable de l'atelier mécanique). Nous avons ensuite, toujours avec l'aide de M.Yoan Dhont, percé les deux poulies selon un axe perpendiculaire au précédent et créé un filetage pour permettre l'insertion d'une vis sans tête pour assurer la fixation au moteur.

Pour des raisons pratiques et esthétiques, nous avons demandé à la menuiserie de Polytech Lille de corriger nos pylônes pour assurer leur perpendicularité. Cette correction a été effectuée par M. David [TODO] et M. JP [TODO] à l'aide d'une scie à bande. Par la suite, nous avons marqué le support pour faciliter le perçage et l'ajustement des pylônes. Une fois les marquages, nous avons percé le support et les pylônes pour assurer une bonne fixation.

===La partie impression===
[[Fichier:assp_impression1.png|200px|thumb|left|Version 1 et 2 du guide axe avec moteur]]
[[Fichier:assp_impression2.png|180px|thumb|right|Guide axe antagoniste (sans moteur)]]
[[Fichier:assp_impression3.png|200px|thumb|left|Guide de poulie et garde moteur]]
Nous avons commencé par créé un chariot permettant le déplacement selon l'axe X, et permettant d'embarquer le moteur pour le déplacement selon Y. Nous l'avons créé à l'aide du logiciel Catia. Les cotes imposés sur le schéma sont celles fournies par la documentation et par mesure des axes métalliques au pieds à coulisse.

Après impression, nous nous sommes aperçu que la documentation comprenait une erreur importante sur la taille des moteurs, nous obligeant à réimprimer une deuxième pièce. Nous avons profiter de la deuxième impression pour réduire la surface de contexte entre l'axe X de la pièce et l'axe métallique X.

La deuxième pièce est très identique à la première à la différence près qu'elle n'embarque pas de moteur. Elle embarque uniquement une poulie permettant le passage de la courroie de transport en Y. Cette version, bien que fonctionnelle, n'a pas eu (pour le moment) l'amélioration apportée par la deuxième version de la pièce 1 (c'est à dire la réduction de surface de contact).

Les deux dernières pièces sont des pièces de support pour permettre au moteur de l'axe X et à la poulie de l'axe X de se maintenir sur leur pylône respectif. Le support de poulie n'a tenu que deux jours avant de rendre l'âme. Nous avons donc remplacé de façon temporaire son axe par une longue vis à bois. Le support de moteur n'a, lui, pas cassé, mais nécessite d'être imprimer une deuxième fois car la documentation du moteur était incorrecte (encore une fois).

Quelques jours avant la pré soutenance, les pièces semblent fonctionnelles. Une amélioration peut être apportée dans un second temps en modifiant les guide d'axe par des poulies (imprimées à l'imprimante 3D) permettant de suivre plus fidèlement l'axe métallique. Ce système sera développé durant les semaines suivants la pré soutenance.

==Motorisation et asservissement en position==
===Besoins et choix des moteurs===
Nous avons besoin de déplacer notre chariot comportant l'outil d'aspiration qui manipule les composants selon les 3 axes de l'espace X, Y et Z. Afin d'assurer les translations dans le plan (X,Y), nous nous sommes orienté vers un système moteur-poulie-courroie sur chacun de ces 2 axes. Nous avons besoin d'une précision en position de l'ordre de 0,2mm et n'avons pas un besoin en couple important, ni d'un asservissement en vitesse spécifique.

Nous avons donc choisi d'utiliser des moteurs Pas à Pas, qui offrent les avantages d'être précis en terme de position angulaire, de pouvoir adapter cette précision en les commandant en micro-pas et surtout de pouvoir réaliser l'asservissement en position sans capteurs. En effet, nous nous baserons sur le comptage du nombre de pas que l'on a fait effectuer au moteur, en supposant qu'aucun pas n'est sauté durant le déplacement. En effet, dans notre application la charge a entrainer est suffisamment faible et le déplacement se fera a une vitesse suffisamment basse afin d'assurer cette hypothèse.

Dans une seconde version, pour être sûr du positionnement et pour palier aux imprécisions (type jeux sur la maquette...) sur la position initiale, la position de la poulie et son diamètre, nous mettrons en place un système d'ajustement via une caméra, où l'utilisateur viendra valider le placement du composant avant dépose sur la carte.

Le déplacement de position est alors déduit ainsi : <math>\Delta X = \mu_{micropas} * \theta_{Pas_{nominal}} * R_{poulie} * \Delta {N_{Pas}}</math>

avec <math>\theta_{Pas_{nominal}}</math> le pas angulaire de nos moteurs en radian (ici, 1,8°=0,031415 rad) ,<math>\mu_{micropas}</math> le facteur de micro-pas choisi (typiquement 1/2, 1/4, voire 1/8), <math>R_{poulie}</math> le rayon du moyen de la poulie crantée en mm (ici 7,15mm) et <math>\Delta {N_{Pas}}</math> le nombre de pas demandé (dans un sens ou dans un autre).

Pour enfin connaitre la position absolue, il s'agit de connaitre la position initiale du chariot. Ceci sera réalisé avec des capteurs "fin de course", type contacteurs à lamelles.

===Commande des moteurs Pas à Pas===

[[Fichier:assp_schema_bipolar_stepper_4.png|140px|thumb|left|Schéma symbolisant les phases et l'arbre du moteur Pas à Pas bipolaire]]
[[Fichier:assp_schema_bipolar_stepper.jpg|300px|thumb|right|Schéma de la séquence d'alimentation complète du moteur bipolaire, en pas complet]]

Le principal inconvénient des moteurs Pas à Pas réside dans la commande de ceux-ci. En effet, un moteur Pas à Pas est un moteur particulier sans balai et alimenté par une alimentation continue. Il comporte plusieurs bobines permettant de créer un champ magnétique à l'intérieur et ainsi d'orienter des aimants fixés au rotor dans la direction du champ magnétique crée, ce qui provoque la rotation de l'arbre. On utilise le terme Pas à Pas car le champ magnétique crée à l'intérieur se fait par incréments. Ainsi pour faire tourner l'arbre entièrement, il faut effectuer l'alimentation des bobines pour une position 1, puis position 2, et ainsi de suite, selon la géométrie et la technologie du moteur utilisées.

Ainsi, le contrôle de celui ci s'effectue par une séquence d'alimentation spécifique de ses différentes phases. Dans notre cas, nous avons choisi des moteurs bipolaires (de type Hybride, c'est à dire combinant les avantages des technologies "à aimant permanent" et à "réluctance variable"). Le sens de rotation des ces moteurs dépend de l'ordre d'alimentation des 2 bobines, ainsi que du sens du courant.

Ce pilotage peut s'effectuer au moyen d'une électronique de puissance type pont en H, sur laquelle on pilote les séquences de commutation des différentes cellules de commutation (transistor + diode en sens inverse en parallèle). Cependant une telle structure est compliquée à mettre en place au niveau des séquences, n'intègre pas directement de limitation active du courant délivré dans la bobine et surtout n'intègre pas directement de variation de courant afin de contrôler le moteur en micro-pas.

Présentant des prix très faibles (environ 5€) pour l'économie de temps et la simplicité d'utilisation qu'ils représentent, nous avons donc cherché des solutions de drivers adaptés à nos moteurs. Basé sur le circuit A4988 d'Allegro, nous nous sommes tourné vers ce driver pour moteur bipolaire (Pololu A4988 Stepper Motor Driver Carrier). Son principe est simple : il intègre directement cette structure de pont en H et les séquences d'alimentation. Il permet ainsi de faire effectuer au moteur un pas en envoyant une impulsion (front montant) sur sa pin STEP, dans le sens défini par l'état (haut ou bas) de sa pin DIR.

[[Fichier:assp_driver_pololu_pinout.png|380px|thumb|centre|Schéma du fonctionnement et du branchement du driver]]

Ce driver réalise également l'interface commande-puissance, il comporte une alimentation séparée pour le circuit logique (5V) et l'alimentation de puissance des moteurs (ici 12V). Il est très important pour éviter la surchauffe et l'endommagement des moteurs de contrôler le courant envoyé dans ses bobines. Nous limitons ainsi activement ce courant grâce au driver au moyen d'un potentiomètre à régler sur ce dernier. Nous avons réglé cette valeur par rapport aux courants nominaux par phase de nos moteurs.

L'avantage majeur de ce driver est qu'il comporte une solution de fonctionnement en micro-pas directement. Par l'état de ses pins MS1, MS2 et MS3, il nous permet de piloter du pas complet, au 1/16 de pas (maximum). Nous ne piloterons pas jusqu'au 1/16 de pas pour des soucis de stabilité du couple mécanique et pour éviter de sauter des pas, 1/4 voire 1/8 de pas devrait être suffisant. Le choix du micropas maximum sera à déterminer avec les tests sur la machine.

Ainsi, nous pilotons toutes ces différentes entrées par le biais d'un Arduino Mega. Plus tard, cet Arduino Mega servira d'interface entre la consigne de position envoyée depuis l'application PC et les moteurs.

[[Fichier:|200px|thumb|right|Photo de la partie commande des moteurs]]

==Création de l'outil de manipulation par aspiration==

L'outil qui viendra attraper et déposer les composants sera composé d'une aiguille fine qui les maintiendra par aspiration. Le système sera donc composé d'une pompe à vide, type pompe d'aquariophilie, peu couteuse, car l'aspiration nécessaire pour maintenir un composant est vraiment très faible. Ce genre de pompe se commande en tout ou rien au moyen d'un interrupteur manuel. Afin de ne pas alterner cycles d'allumage de la pompe pour éviter de l'endommager et surtout d'attendre le temps d'établissement du débit à chaque fois, lors des phases aspiration-dépose, nous utiliserons un distributeur pneumatique qui viendra envoyer ou non la dépression dans le tuyau d'air.

Une partie majeure du travail va consister en la conception de la pièce mécanique, le chariot, qui intégrera les moteurs pour effectuer la translation et la rotation autour de Z, un capteur piézoélectrique qui permettra la détection du contact entre le composant et la carte et qui intégrera un espace prévu à cet effet pour maintenir le tuyau et l'aiguille. Ce chariot sera adaptable au reste du châssis et comportera une partie qui le fixe à la courroie.

Niveau matériel pour cette partie, nous avons pour le moment réuni le distributeur, les tuyaux et l'aiguille. Nous devrions recevoir la pompe sous peu de temps.

==Conception du logiciel==
===Définition du cadre===
Un des buts de ce projet est de concevoir une application permettant de contrôler les différents éléments du projet. Pour cela nous, l'application doit être capable de lire des fichiers standards de création de carte électronique (aussi appelés fichiers Gerber). De plus, nous souhaitions que l'application puisse être utilisé sur n'importe quelle plateforme. Pour cela, nous avons choisi de la développer sous [http://www.qt.io/ Qt]. L’environnement de travail Qt nous permet d'utiliser des objets permettant l'accès à n'importe quel type de matériel sans se soucier de la plateforme de destination. Pour la communication avec les éléments de commande (comme les moteurs) nous avons choisi de n'envoyer des ordres qu'à travers l'Arduino Mega.
===La communication entre le logiciel et l'Arduino Mega===
==Création d'un système sûr pour Arduino Mega==
L'application de bureau que nous avons créé va, comme expliqué précédemment, communiqué avec un Arduino Mega. Cet Arduino s'occupera de la commande de la partie du puissance du reste du système. Ces fonctions sont:
* Commander des moteurs sur les axes X, Y et Z
* Commander de la rotation selon Z
* Contrôler de la pompe
* Définir les paramètres avancés des moteurs (vitesse, précision des micropas)
* S'assurer de ne pas commander un ordre endommageant la machine
===Le protocole de communication===
[[Fichier:ASSP_mega_task_flowchart.png|200px|thumb|right]]Pour permettre de réaliser ces fonctions, l'application communique à travers le port série avec l'Arduino Mega. Le protocole utilisé est rendant le plus compact possible pour limiter le nombre de communications.
L'Arduino Mega ne fonctionne que par tâches (comme décris sur le schéma à droite). La seule possibilité pour l'Arduino de ne pas être dans cette exécution de tâches est d'être interrompu par un contact à lamelle souple (que nous considérons comme prioritaire). Dans ce cas, l'Arduino reste bloqué dans la fonction appelé par l'interruption jusqu'à temps que l'utilisateur valide manuellement la déverrouillage (ce qui permet d'éviter que le système ne puisse s’abîmer).
====Les trames de base====
{| class="wikitable"
|+ Commande d'initialisation d'une tâche (PC->Mega)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Paramètre
| colspan="4" |Fonction appelée
|}
{| class="wikitable"
|+ Commande de réponse d'une tâche (Mega->PC)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Donnée dépendant de la fonction
| colspan="4" | Code de retour
|}
Si le code de retour est différent de 0, les trames de retour 2 et 3 ne sont pas envoyées
{| class="wikitable"
|+ Liste des codes de retour
! scope="col" colspan="5" | Code retourné
! scope="col" rowspan="2" | Nom dans le header
! scope="col" rowspan="2" | Action à prendre
! scope="col" rowspan="2" | Description du code
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| CMD_OK
| Aucune
| La commande s'est exécutée correctement
|-
| 0
| 0
| 0
| 1
| 0x01
| CMD_NOT_KNOWN
| Report immédiat
| La commande demandée n'est pas connue
|-
| 0
| 0
| 1
| 0
| 0x02
| CMD_DEST_UNREACHABLE
| Report immédiat
| L'appel à la commande setDest a le paramètre dest trop grand sur le moteur choisi
|-
| 0
| 0
| 1
| 1
| 0x03
| CMD_LOCK_MIN_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son minimum
|-
| 0
| 1
| 0
| 0
| 0x04
| CMD_LOCK_MAX_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son maximum
|-
| 0
| 0
| 1
| 1
| 0x05
| CMD_LOCK_MIN_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son minimum
|-
| 0
| 1
| 1
| 0
| 0x06
| CMD_LOCK_MAX_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son maximum
|-
| 0
| 1
| 1
| 1
| 0x07
| CMD_LOCK_MIN_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son minimum
|-
| 1
| 0
| 0
| 0
| 0x08
| CMD_LOCK_MAX_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son maximum
|-
| 1
| 0
| 0
| 1
| 0x09
| CMD_LOCK_Z
| Report immédiat ou aucun
| L'aiguille a touché un objet et a dépassé la force maximum à appliquer dessus
|-
| 1
| 0
| 1
| 0
| 0x0A
| WAIT_FOR_NEXT_FRAME
| Report immédiat ou aucun
| La fonction appelée a été comprise, l'Arduino est en attente de la trame suivante.
|}

====Liste des fonctions d'écriture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Paramètre 2
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| setDest
| selectedMotor[2bits]
| destination[16bits]
| Donne la consigne de position en seizième de pas par rapport à l'origine
|-
| 0
| 0
| 0
| 1
| 0x01
| setMS
| selectedMotor[2bits]
| microStep[3bits]
| Donne la consigne du nombre de micropas par tour pour un moteur
|-
| 0
| 0
| 1
| 0
| 0x02
| setPump
| onOff[1bit]
| ∅
| Donne la consigne d'allumage ou d'extinction de la pompe à vide
|-
| 0
| 0
| 1
| 1
| 0x03
| setADC
| adcLevel[10bits]
| ∅
| Donne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 0
| 1
| 0
| 0
| 0x04
| setRelease
| lockToRelease[3bits]
| ∅
| Donne la consigne de déverrouillage d'un nœud précédemment verrouillé
|-
| 0
| 1
| 0
| 1
| 0x05
| setSpeed
| selectedMotor[2bits]
| delayStep[8bits]
| Donne le temps en ms à attendre entre 2 pas (<=> la vitesse du moteur)
|}
{| class="wikitable"
|+ Détails sur la construction des fonctions d'écriture
! scope="col" rowspan="2" | Fonction appelée
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| setDest
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | destination[15:8]
| colspan="8" align="center" | destination[7:0]
|-
| setMS
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="3" align="center" | microStep[2:0]
| colspan="5" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| setPump
| align="center" | onOff
| colspan="3" align="center" | ∅
| colspan="16" align="center" | ∅
|-
| setADC
| colspan="2" align="center" | adcLevel[9:8]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| setRelease
| align="center" | ∅
| colspan="3" align="center" | lockToRelease[2:0]
| colspan="16" align="center" | ∅
|-
| setSpeed
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|}

====Liste des fonctions de lecture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 1
| 0
| 0
| 0
| 0x08
| getDest
| selectedMotor[2bits]
| Retourne la position d'un moteur donné en seizième de pas par rapport à l'origine
|-
| 1
| 0
| 0
| 1
| 0x09
| getMS
| ∅
| Retourne la consigne du nombre de micropas par tour pour tous les moteurs
|-
| 1
| 0
| 1
| 0
| 0x0A
| getPump
| ∅
| Retourne la consigne d'allumage actuelle de la pompe à vide
|-
| 1
| 0
| 1
| 1
| 0x0B
| getADC
| ∅
| Retourne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 1
| 1
| 0
| 0
| 0x0C
| getRelease
| ∅
| Retourne l'état de verrouillage des nœuds
|-
| 1
| 1
| 0
| 0
| 0x0D
| getADCvalue
| selectedPin[2bits]
| Retourne la valeur convertie par l'ADC de la pin analogique selectionnée
|}
{| class="wikitable"
|+ Détails de la construction des trames de lecture
! scope="col" rowspan="3" | Fonction appelée
! scope="col" colspan="4" | Appel (PC->Mega)
! scope="col" colspan="24" | Retour (Mega->PC)
|-
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| getDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | dest[15:8]
| colspan="8" align="center" | dest[7:0]
|-
| getMS
| colspan="4" align="center" | ∅
| msY[0]
| colspan="3" align="center" | msX[2:0]
| colspan="3" align="center" | msR[2:0]
| colspan="3" align="center" | msZ[2:0]
| colspan="2" align="center" | msY[2:1]
| colspan="8" align="center" | ∅
|-
| getPump
| colspan="4" align="center" | ∅
| onOff
| colspan="3" align="center" | ∅
| colspan="8" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getADC
| colspan="4" align="center" | ∅
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| getRelease
| colspan="4" align="center" | ∅
| lockMinX1
| lockMaxX1
| lockMinX2
| lockMaxX2
| lockMinY
| lockMaxY
| colspan="6" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getADCvalue
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedPin[1:0]
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcValue[9:8]
| colspan="8" align="center" | adcValue[7:0]
| colspan="8" align="center" | ∅
|}

Automatic Soldering System Project

2016-02-09T23:56:02Z

Pletouse : /* Le protocole de communication */ Ajout code erreur aiguille

__TOC__
 
=Placeur de composants sur PCB=
==Présentation du projet==
Durant le début de l'été, nous avons eu l'idée de proposer un projet de soudure automatique. Ce projet avait pour but de concevoir un système permettant l'automatisation des soudures sur une carte électronique à composants traversants. Après des échanges avec le responsable des projet de 5éme année, M. Vantroys, nous avons finalement abandonné notre projet au profit d'un autre projet assez proche.

L'idée du nouveau projet est de proposer un système de Pick & Place de composants CMS sur une carte électronique sur laquelle de la crème à braser est préalablement déposée sur les pastilles. Pour mener à bien ce projet, nous avons été épaulé par M. Redon, M. Vantroys et M. Boé. En plus de nos encadrants école, nous avons travaillé en étroite collaboration avec M. Flamen, responsable du service électronique de Polytech Lille ainsi qu'avec M. Astori, enseignant en Conception Mécanique et responsable du FabLab de Polytech Lille. Nous tenons par ailleurs également à remercier chaleureusement Antoine, contributeur actif au Fablab de Polytech Lille, pour son partage d'expérience à propos de la création de son imprimante 3D RepRap, projet similaire au notre.
===Définitions des objectifs===
*Prendre un composant
**Stocker les composants à déposer sur la carte et identifier leur position
**Maintenir le composant par aspiration
*Repérer la position et l’orientation de la carte
*Déplacer le composant
**Le déplacer en translation selon les axes X, Y et Z
**L’orienter correctement sur les pastilles (rotation autour de Z)
*Déposer le composant
**S’assurer que l’outil d’aspiration n’endommage ni la carte, ni le composant lors de la dépose -> détecter le contact entre le composant et la carte
*Connaître la position désirée pour la dépose du composant
**Récupérer les fichiers provenant du logiciel de CAO et les transformer en déplacement de la machine
**Permettre à l’utilisateur d’avoir une interface visuelle (sur ordinateur) indiquant l’état des éléments de la machine et permettant leur calibrage
===Liste des tâches===
*Créer l’infrastructure mécanique de la machine (châssis)
**Fabrication du châssis
**Design des pièces mobiles et impression 3D de ces pièces au FabLab (chariot comportant l’outil d’aspiration et “guides tubes” assurant la transformation de la rotation des moteurs en mouvement de translation (glissières) sur des barres métalliques)
**Assembler l’outil d’aspiration au chariot
*Concevoir la commande d’aspiration par pompe
*Organiser la commande des moteurs du système pour l’asservissement en position de la machine
**Étude et prise en main des drivers pour les moteurs Pas à Pas
*Réalisation de l’interface commande-puissance
*Réaliser la conversion des données de position (relatives) de l’emplacement souhaités des composants en mouvements pour la machine
**Concevoir l’interface de récupération des données du fichier Gerber de l’utilisateur
**Caractérisation des différents repères (repère de la machine, repère de l’outil et repère de la carte) et établir le lien entres eux
**Détecter l’origine du repère de la carte au moyen d’une caméra fixe
===Planning prévisionnel de répartition du travail===
{| class="wikitable alternance centre"
|-
! scope="row" | Semaine 39 (21/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 40 (28/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 41 (05/10)
| Dimensionnement des éléments du système et recherche du matériel à commander en tenant compte des contraintes de coût
|-
! scope="row" | Semaine 42 (12/10)
| Achat du matériel pour le châssis de la machine (bois, tiges métalliques...) et pré-assemblage / Conception des pièces mécaniques à imprimer au FabLab
|-
! scope="row" | Semaine 43 (19/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position
|-
! scope="row" | Semaine 44 (26/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 45 (02/11)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de la commande des moteurs et du repérage caméra
|-
! scope="row" | Semaine 46 (09/11)
| Dans l'attente de la réception du matériel commandé : Fabrication du châssis - assemblage des pièces / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 47 (16/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 48 (23/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 49 (30/11)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 50 (07/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 51 (14/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 52 (21/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 53 (28/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 01 (04/01)
|
|-
! scope="row" | Semaine 02 (11/01)
|
|-
! scope="row" | Semaine 03 (18/01)
|
|-
! scope="row" | Semaine 04 (25/01)
|
|-
! scope="row" | Semaine 05 (01/02)
|
|-
! scope="row" | Semaine 06 (08/02)
|
|-
! scope="row" | Semaine 07 (15/02)
|
|-
! scope="row" | Semaine 08 (22/02)
|
|-
|}

===Retour sur les directives des encadrants===
====M. Flamen====
[[Fichier:Exemple composant cms.jpg|200px|thumb|right|Exemple de composants CMS]]
Dans un premier temps, pour mieux définir les objectifs de notre projet, nous avons pris rendez vous avec M. Flamen. M. Flamen est le responsable du service électronique de PolytechLille. Il est le principal intéressé par notre projet car celui-ci (le projet) permettrait de disposer de la chaîne complète de fabrication de cartes électroniques CMS (composants montés en surface).

Cette rencontre avec M. Flamen nous a permis de déterminer certaines précisions, comme:
* La précision maximale demandé n'excédera pas 0,2 mm (précision de classe 5, qui est celle de la graveuse de carte du service EEI).

===Liste de matériel===
====Matériel disponible====
*Support
** 3 Tiges de 1 mètre [Reçu le 2015-10-12]
** 1 Tasseau de 2m70 (découpé pour fabriquer les supports des tiges) [Reçu le 2015-10-12]
** 1 Planche en bois pour effectuer le support du projet [Reçu le 2015-10-12]
*Motorisation
**2 Moteurs Pas à Pas type NEMA 17 (pour axes X et Y) [http://www.gotronic.fr/art-moteur-17hs15-0404s-18354.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas (pour rotation autour de Z) [http://www.gotronic.fr/art-moteur-24byj48-19028.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas avec glissière intégrée (pour translation selon Z) [http://www.gotronic.fr/art-moteur-pas-a-pas-a-glissiere-800180001-21817.htm][Reçu le 2015-11-09]
**4 drivers pour moteur Pas à Pas bipolaire [http://www.gotronic.fr/art-driver-de-moteur-pas-a-pas-a4988-1182-21718.htm][Reçu le 2015-11-09]
*Outil d'aspiration
**Aiguille manipulant le composant [http://www.gotronic.fr/art-jeu-de-4-aiguilles-eso12-7428.htm][Reçu le 2015-11-09]
**Tube flexible [http://fr.rs-online.com/web/p/tubes-flexibles/7989985/][Reçu le 2015-11-09]
*Châssis mécanique
**2 Courroies crantées [http://fr.rs-online.com/web/p/courroies-crantees/4749614/][Reçu le 2015-11-09]
**4 Poulies crantées [http://fr.rs-online.com/web/p/poulies-pour-courroies-crantees/0182565/][Reçu le 2015-11-09]
*2 Courroies crantées plus grandes [Reçu le 2015-12-27]
====Matériel manquant====
* Rien pour le moment

==Fabrication de l'infrastructure mécanique==
[[Fichier:assp_usinage1.jpg|200px|thumb|left|Usinage des pylônes à la perceuse à colonne]]
[[Fichier:assp_usinage2.jpg|200px|thumb|right|Tour conventionnel utilisé pour le perçage]]
[[Fichier:assp_usinage3.jpg|200px|thumb|left|Marquages sur le support pour la pose de pylônes]]
[[Fichier:assp_usinage4.jpg|200px|thumb|right|Etat de la maquette avant la fixation finale]]
Notre projet comprend une partie extrêmement importante de conception. Sur conseils de M. Astori, nous avons donc décidé d'utiliser une organisation plus particulière. Le principe de cette organisation est de créer des pièces (on parle ici uniquement de leur impression à l'imprimante 3D et de la phase de conception sous Catia) rapidement, avec une faible taux de remplissage (de l'ordre de 30%). Le but de cette méthode est de créer un nombre de pièces plus important, permettant plus facilement rectifications en fonction des remarques que nous tirons du montage.

===La partie usinage===
Nous avons commencé par acheter une support contreplaqué en bois. Sur ce support, nous avons disposé quatre pylônes reliés deux à deux par un axe métallique. Nous avons donc découpé à la scie à chantourner plusieurs linteaux de bois pour fabriquer les pylônes. Ensuite, nous avons usiné les pylônes à l'aide d'une perceuse à colonne pour leur permettre de recevoir l'axe métallique.

Ensuite, nous avons eu la surprise de recevoir des poulies non percées. Nous avons donc du les percer. Nous avons percé les deux premières à l'aide de la perceuse à colonne. Le désavantage de cet outil est son imprécision sur la largeur de perçage. De plus, il n'était pas possible d'y ajouter un mécanisme permettant son maintien au moteur. Par conséquent, nous avons eu la chance d'être aidé par l'atelier mécanique. Ainsi, nous avons usiné les deux dernières poulies à l'aide d'un tour conventionnel (sous la supervision du responsable de l'atelier mécanique). Nous avons ensuite, toujours avec l'aide de M.Yoan Dhont, percé les deux poulies selon un axe perpendiculaire au précédent et créé un filetage pour permettre l'insertion d'une vis sans tête pour assurer la fixation au moteur.

Pour des raisons pratiques et esthétiques, nous avons demandé à la menuiserie de Polytech Lille de corriger nos pylônes pour assurer leur perpendicularité. Cette correction a été effectuée par M. David [TODO] et M. JP [TODO] à l'aide d'une scie à bande. Par la suite, nous avons marqué le support pour faciliter le perçage et l'ajustement des pylônes. Une fois les marquages, nous avons percé le support et les pylônes pour assurer une bonne fixation.

===La partie impression===
[[Fichier:assp_impression1.png|200px|thumb|left|Version 1 et 2 du guide axe avec moteur]]
[[Fichier:assp_impression2.png|180px|thumb|right|Guide axe antagoniste (sans moteur)]]
[[Fichier:assp_impression3.png|200px|thumb|left|Guide de poulie et garde moteur]]
Nous avons commencé par créé un chariot permettant le déplacement selon l'axe X, et permettant d'embarquer le moteur pour le déplacement selon Y. Nous l'avons créé à l'aide du logiciel Catia. Les cotes imposés sur le schéma sont celles fournies par la documentation et par mesure des axes métalliques au pieds à coulisse.

Après impression, nous nous sommes aperçu que la documentation comprenait une erreur importante sur la taille des moteurs, nous obligeant à réimprimer une deuxième pièce. Nous avons profiter de la deuxième impression pour réduire la surface de contexte entre l'axe X de la pièce et l'axe métallique X.

La deuxième pièce est très identique à la première à la différence près qu'elle n'embarque pas de moteur. Elle embarque uniquement une poulie permettant le passage de la courroie de transport en Y. Cette version, bien que fonctionnelle, n'a pas eu (pour le moment) l'amélioration apportée par la deuxième version de la pièce 1 (c'est à dire la réduction de surface de contact).

Les deux dernières pièces sont des pièces de support pour permettre au moteur de l'axe X et à la poulie de l'axe X de se maintenir sur leur pylône respectif. Le support de poulie n'a tenu que deux jours avant de rendre l'âme. Nous avons donc remplacé de façon temporaire son axe par une longue vis à bois. Le support de moteur n'a, lui, pas cassé, mais nécessite d'être imprimer une deuxième fois car la documentation du moteur était incorrecte (encore une fois).

Quelques jours avant la pré soutenance, les pièces semblent fonctionnelles. Une amélioration peut être apportée dans un second temps en modifiant les guide d'axe par des poulies (imprimées à l'imprimante 3D) permettant de suivre plus fidèlement l'axe métallique. Ce système sera développé durant les semaines suivants la pré soutenance.

==Motorisation et asservissement en position==
===Besoins et choix des moteurs===
Nous avons besoin de déplacer notre chariot comportant l'outil d'aspiration qui manipule les composants selon les 3 axes de l'espace X, Y et Z. Afin d'assurer les translations dans le plan (X,Y), nous nous sommes orienté vers un système moteur-poulie-courroie sur chacun de ces 2 axes. Nous avons besoin d'une précision en position de l'ordre de 0,2mm et n'avons pas un besoin en couple important, ni d'un asservissement en vitesse spécifique.

Nous avons donc choisi d'utiliser des moteurs Pas à Pas, qui offrent les avantages d'être précis en terme de position angulaire, de pouvoir adapter cette précision en les commandant en micro-pas et surtout de pouvoir réaliser l'asservissement en position sans capteurs. En effet, nous nous baserons sur le comptage du nombre de pas que l'on a fait effectuer au moteur, en supposant qu'aucun pas n'est sauté durant le déplacement. En effet, dans notre application la charge a entrainer est suffisamment faible et le déplacement se fera a une vitesse suffisamment basse afin d'assurer cette hypothèse.

Dans une seconde version, pour être sûr du positionnement et pour palier aux imprécisions (type jeux sur la maquette...) sur la position initiale, la position de la poulie et son diamètre, nous mettrons en place un système d'ajustement via une caméra, où l'utilisateur viendra valider le placement du composant avant dépose sur la carte.

Le déplacement de position est alors déduit ainsi : <math>\Delta X = \mu_{micropas} * \theta_{Pas_{nominal}} * R_{poulie} * \Delta {N_{Pas}}</math>

avec <math>\theta_{Pas_{nominal}}</math> le pas angulaire de nos moteurs en radian (ici, 1,8°=0,031415 rad) ,<math>\mu_{micropas}</math> le facteur de micro-pas choisi (typiquement 1/2, 1/4, voire 1/8), <math>R_{poulie}</math> le rayon du moyen de la poulie crantée en mm (ici 7,15mm) et <math>\Delta {N_{Pas}}</math> le nombre de pas demandé (dans un sens ou dans un autre).

Pour enfin connaitre la position absolue, il s'agit de connaitre la position initiale du chariot. Ceci sera réalisé avec des capteurs "fin de course", type contacteurs à lamelles.

===Commande des moteurs Pas à Pas===

[[Fichier:assp_schema_bipolar_stepper_4.png|140px|thumb|left|Schéma symbolisant les phases et l'arbre du moteur Pas à Pas bipolaire]]
[[Fichier:assp_schema_bipolar_stepper.jpg|300px|thumb|right|Schéma de la séquence d'alimentation complète du moteur bipolaire, en pas complet]]

Le principal inconvénient des moteurs Pas à Pas réside dans la commande de ceux-ci. En effet, un moteur Pas à Pas est un moteur particulier sans balai et alimenté par une alimentation continue. Il comporte plusieurs bobines permettant de créer un champ magnétique à l'intérieur et ainsi d'orienter des aimants fixés au rotor dans la direction du champ magnétique crée, ce qui provoque la rotation de l'arbre. On utilise le terme Pas à Pas car le champ magnétique crée à l'intérieur se fait par incréments. Ainsi pour faire tourner l'arbre entièrement, il faut effectuer l'alimentation des bobines pour une position 1, puis position 2, et ainsi de suite, selon la géométrie et la technologie du moteur utilisées.

Ainsi, le contrôle de celui ci s'effectue par une séquence d'alimentation spécifique de ses différentes phases. Dans notre cas, nous avons choisi des moteurs bipolaires (de type Hybride, c'est à dire combinant les avantages des technologies "à aimant permanent" et à "réluctance variable"). Le sens de rotation des ces moteurs dépend de l'ordre d'alimentation des 2 bobines, ainsi que du sens du courant.

Ce pilotage peut s'effectuer au moyen d'une électronique de puissance type pont en H, sur laquelle on pilote les séquences de commutation des différentes cellules de commutation (transistor + diode en sens inverse en parallèle). Cependant une telle structure est compliquée à mettre en place au niveau des séquences, n'intègre pas directement de limitation active du courant délivré dans la bobine et surtout n'intègre pas directement de variation de courant afin de contrôler le moteur en micro-pas.

Présentant des prix très faibles (environ 5€) pour l'économie de temps et la simplicité d'utilisation qu'ils représentent, nous avons donc cherché des solutions de drivers adaptés à nos moteurs. Basé sur le circuit A4988 d'Allegro, nous nous sommes tourné vers ce driver pour moteur bipolaire (Pololu A4988 Stepper Motor Driver Carrier). Son principe est simple : il intègre directement cette structure de pont en H et les séquences d'alimentation. Il permet ainsi de faire effectuer au moteur un pas en envoyant une impulsion (front montant) sur sa pin STEP, dans le sens défini par l'état (haut ou bas) de sa pin DIR.

[[Fichier:assp_driver_pololu_pinout.png|380px|thumb|centre|Schéma du fonctionnement et du branchement du driver]]

Ce driver réalise également l'interface commande-puissance, il comporte une alimentation séparée pour le circuit logique (5V) et l'alimentation de puissance des moteurs (ici 12V). Il est très important pour éviter la surchauffe et l'endommagement des moteurs de contrôler le courant envoyé dans ses bobines. Nous limitons ainsi activement ce courant grâce au driver au moyen d'un potentiomètre à régler sur ce dernier. Nous avons réglé cette valeur par rapport aux courants nominaux par phase de nos moteurs.

L'avantage majeur de ce driver est qu'il comporte une solution de fonctionnement en micro-pas directement. Par l'état de ses pins MS1, MS2 et MS3, il nous permet de piloter du pas complet, au 1/16 de pas (maximum). Nous ne piloterons pas jusqu'au 1/16 de pas pour des soucis de stabilité du couple mécanique et pour éviter de sauter des pas, 1/4 voire 1/8 de pas devrait être suffisant. Le choix du micropas maximum sera à déterminer avec les tests sur la machine.

Ainsi, nous pilotons toutes ces différentes entrées par le biais d'un Arduino Mega. Plus tard, cet Arduino Mega servira d'interface entre la consigne de position envoyée depuis l'application PC et les moteurs.

[[Fichier:|200px|thumb|right|Photo de la partie commande des moteurs]]

==Création de l'outil de manipulation par aspiration==

L'outil qui viendra attraper et déposer les composants sera composé d'une aiguille fine qui les maintiendra par aspiration. Le système sera donc composé d'une pompe à vide, type pompe d'aquariophilie, peu couteuse, car l'aspiration nécessaire pour maintenir un composant est vraiment très faible. Ce genre de pompe se commande en tout ou rien au moyen d'un interrupteur manuel. Afin de ne pas alterner cycles d'allumage de la pompe pour éviter de l'endommager et surtout d'attendre le temps d'établissement du débit à chaque fois, lors des phases aspiration-dépose, nous utiliserons un distributeur pneumatique qui viendra envoyer ou non la dépression dans le tuyau d'air.

Une partie majeure du travail va consister en la conception de la pièce mécanique, le chariot, qui intégrera les moteurs pour effectuer la translation et la rotation autour de Z, un capteur piézoélectrique qui permettra la détection du contact entre le composant et la carte et qui intégrera un espace prévu à cet effet pour maintenir le tuyau et l'aiguille. Ce chariot sera adaptable au reste du châssis et comportera une partie qui le fixe à la courroie.

Niveau matériel pour cette partie, nous avons pour le moment réuni le distributeur, les tuyaux et l'aiguille. Nous devrions recevoir la pompe sous peu de temps.

==Conception du logiciel==
===Définition du cadre===
Un des buts de ce projet est de concevoir une application permettant de contrôler les différents éléments du projet. Pour cela nous, l'application doit être capable de lire des fichiers standards de création de carte électronique (aussi appelés fichiers Gerber). De plus, nous souhaitions que l'application puisse être utilisé sur n'importe quelle plateforme. Pour cela, nous avons choisi de la développer sous [http://www.qt.io/ Qt]. L’environnement de travail Qt nous permet d'utiliser des objets permettant l'accès à n'importe quel type de matériel sans se soucier de la plateforme de destination. Pour la communication avec les éléments de commande (comme les moteurs) nous avons choisi de n'envoyer des ordres qu'à travers l'Arduino Mega.
===La communication entre le logiciel et l'Arduino Mega===
==Création d'un système sûr pour Arduino Mega==
L'application de bureau que nous avons créé va, comme expliqué précédemment, communiqué avec un Arduino Mega. Cet Arduino s'occupera de la commande de la partie du puissance du reste du système. Ces fonctions sont:
* Commander des moteurs sur les axes X, Y et Z
* Commander de la rotation selon Z
* Contrôler de la pompe
* Définir les paramètres avancés des moteurs (vitesse, précision des micropas)
* S'assurer de ne pas commander un ordre endommageant la machine
===Le protocole de communication===
[[Fichier:ASSP_mega_task_flowchart.png|200px|thumb|right]]Pour permettre de réaliser ces fonctions, l'application communique à travers le port série avec l'Arduino Mega. Le protocole utilisé est rendant le plus compact possible pour limiter le nombre de communications.
L'Arduino Mega ne fonctionne que par tâches (comme décris sur le schéma à droite). La seule possibilité pour l'Arduino de ne pas être dans cette exécution de tâches est d'être interrompu par un contact à lamelle souple (que nous considérons comme prioritaire). Dans ce cas, l'Arduino reste bloqué dans la fonction appelé par l'interruption jusqu'à temps que l'utilisateur valide manuellement la déverrouillage (ce qui permet d'éviter que le système ne puisse s’abîmer).
====Les trames de base====
{| class="wikitable"
|+ Commande d'initialisation d'une tâche (PC->Mega)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Paramètre
| colspan="4" |Fonction appelée
|}
{| class="wikitable"
|+ Commande de réponse d'une tâche (Mega->PC)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Donnée dépendant de la fonction
| colspan="4" | Code de retour
|}
Si le code de retour est différent de 0, les trames de retour 2 et 3 ne sont pas envoyées
{| class="wikitable"
|+ Liste des codes de retour
! scope="col" colspan="5" | Code retourné
! scope="col" rowspan="2" | Nom dans le header
! scope="col" rowspan="2" | Action à prendre
! scope="col" rowspan="2" | Description du code
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| CMD_OK
| Aucune
| La commande s'est exécutée correctement
|-
| 0
| 0
| 0
| 1
| 0x01
| CMD_NOT_KNOWN
| Report immédiat
| La commande demandée n'est pas connue
|-
| 0
| 0
| 1
| 0
| 0x02
| CMD_DEST_UNREACHABLE
| Report immédiat
| L'appel à la commande setDest a le paramètre dest trop grand sur le moteur choisi
|-
| 0
| 0
| 1
| 1
| 0x03
| CMD_LOCK_MIN_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son minimum
|-
| 0
| 1
| 0
| 0
| 0x04
| CMD_LOCK_MAX_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son maximum
|-
| 0
| 0
| 1
| 1
| 0x05
| CMD_LOCK_MIN_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son minimum
|-
| 0
| 1
| 1
| 0
| 0x06
| CMD_LOCK_MAX_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son maximum
|-
| 0
| 1
| 1
| 1
| 0x07
| CMD_LOCK_MIN_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son minimum
|-
| 1
| 0
| 0
| 0
| 0x08
| CMD_LOCK_MAX_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son maximum
|-
| 1
| 0
| 0
| 1
| 0x09
| CMD_LOCK_Z
| Report immédiat ou aucun
| L'aiguille a touché un objet et a dépassé la force maximum à appliquer dessus
|}

====Liste des fonctions d'écriture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Paramètre 2
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| setDest
| selectedMotor[2bits]
| destination[16bits]
| Donne la consigne de position en seizième de pas par rapport à l'origine
|-
| 0
| 0
| 0
| 1
| 0x01
| setMS
| selectedMotor[2bits]
| microStep[3bits]
| Donne la consigne du nombre de micropas par tour pour un moteur
|-
| 0
| 0
| 1
| 0
| 0x02
| setPump
| onOff[1bit]
| ∅
| Donne la consigne d'allumage ou d'extinction de la pompe à vide
|-
| 0
| 0
| 1
| 1
| 0x03
| setADC
| adcLevel[10bits]
| ∅
| Donne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 0
| 1
| 0
| 0
| 0x04
| setRelease
| lockToRelease[3bits]
| ∅
| Donne la consigne de déverrouillage d'un nœud précédemment verrouillé
|-
| 0
| 1
| 0
| 1
| 0x05
| setSpeed
| selectedMotor[2bits]
| delayStep[8bits]
| Donne le temps en ms à attendre entre 2 pas (<=> la vitesse du moteur)
|}
{| class="wikitable"
|+ Détails sur la construction des fonctions d'écriture
! scope="col" rowspan="2" | Fonction appelée
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| setDest
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | destination[15:8]
| colspan="8" align="center" | destination[7:0]
|-
| setMS
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="3" align="center" | microStep[2:0]
| colspan="5" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| setPump
| align="center" | onOff
| colspan="3" align="center" | ∅
| colspan="16" align="center" | ∅
|-
| setADC
| colspan="2" align="center" | adcLevel[9:8]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| setRelease
| align="center" | ∅
| colspan="3" align="center" | lockToRelease[2:0]
| colspan="16" align="center" | ∅
|-
| setSpeed
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|}

====Liste des fonctions de lecture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 1
| 0
| 0
| 0
| 0x08
| getDest
| selectedMotor[2bits]
| Retourne la position d'un moteur donné en seizième de pas par rapport à l'origine
|-
| 1
| 0
| 0
| 1
| 0x09
| getMS
| ∅
| Retourne la consigne du nombre de micropas par tour pour tous les moteurs
|-
| 1
| 0
| 1
| 0
| 0x0A
| getPump
| ∅
| Retourne la consigne d'allumage actuelle de la pompe à vide
|-
| 1
| 0
| 1
| 1
| 0x0B
| getADC
| ∅
| Retourne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 1
| 1
| 0
| 0
| 0x0C
| getRelease
| ∅
| Retourne l'état de verrouillage des nœuds
|}
{| class="wikitable"
|+ Détails de la construction des trames de lecture
! scope="col" rowspan="3" | Fonction appelée
! scope="col" colspan="4" | Appel (PC->Mega)
! scope="col" colspan="24" | Retour (Mega->PC)
|-
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| getDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | dest[15:8]
| colspan="8" align="center" | dest[7:0]
|-
| getMS
| colspan="4" align="center" | ∅
| msY[0]
| colspan="3" align="center" | msX[2:0]
| colspan="3" align="center" | msR[2:0]
| colspan="3" align="center" | msZ[2:0]
| colspan="2" align="center" | msY[2:1]
| colspan="8" align="center" | ∅
|-
| getPump
| colspan="4" align="center" | ∅
| onOff
| colspan="3" align="center" | ∅
| colspan="8" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getADC
| colspan="4" align="center" | ∅
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| getRelease
| colspan="4" align="center" | ∅
| lockMinX1
| lockMaxX1
| lockMinX2
| lockMaxX2
| lockMinY
| lockMaxY
| colspan="6" align="center" | ∅
| colspan="8" align="center" | ∅
|}

Automatic Soldering System Project

2016-02-09T23:32:28Z

Pletouse : /* Liste des fonctions d'écriture */ Corrigé code appelé setSpeed

__TOC__
 
=Placeur de composants sur PCB=
==Présentation du projet==
Durant le début de l'été, nous avons eu l'idée de proposer un projet de soudure automatique. Ce projet avait pour but de concevoir un système permettant l'automatisation des soudures sur une carte électronique à composants traversants. Après des échanges avec le responsable des projet de 5éme année, M. Vantroys, nous avons finalement abandonné notre projet au profit d'un autre projet assez proche.

L'idée du nouveau projet est de proposer un système de Pick & Place de composants CMS sur une carte électronique sur laquelle de la crème à braser est préalablement déposée sur les pastilles. Pour mener à bien ce projet, nous avons été épaulé par M. Redon, M. Vantroys et M. Boé. En plus de nos encadrants école, nous avons travaillé en étroite collaboration avec M. Flamen, responsable du service électronique de Polytech Lille ainsi qu'avec M. Astori, enseignant en Conception Mécanique et responsable du FabLab de Polytech Lille. Nous tenons par ailleurs également à remercier chaleureusement Antoine, contributeur actif au Fablab de Polytech Lille, pour son partage d'expérience à propos de la création de son imprimante 3D RepRap, projet similaire au notre.
===Définitions des objectifs===
*Prendre un composant
**Stocker les composants à déposer sur la carte et identifier leur position
**Maintenir le composant par aspiration
*Repérer la position et l’orientation de la carte
*Déplacer le composant
**Le déplacer en translation selon les axes X, Y et Z
**L’orienter correctement sur les pastilles (rotation autour de Z)
*Déposer le composant
**S’assurer que l’outil d’aspiration n’endommage ni la carte, ni le composant lors de la dépose -> détecter le contact entre le composant et la carte
*Connaître la position désirée pour la dépose du composant
**Récupérer les fichiers provenant du logiciel de CAO et les transformer en déplacement de la machine
**Permettre à l’utilisateur d’avoir une interface visuelle (sur ordinateur) indiquant l’état des éléments de la machine et permettant leur calibrage
===Liste des tâches===
*Créer l’infrastructure mécanique de la machine (châssis)
**Fabrication du châssis
**Design des pièces mobiles et impression 3D de ces pièces au FabLab (chariot comportant l’outil d’aspiration et “guides tubes” assurant la transformation de la rotation des moteurs en mouvement de translation (glissières) sur des barres métalliques)
**Assembler l’outil d’aspiration au chariot
*Concevoir la commande d’aspiration par pompe
*Organiser la commande des moteurs du système pour l’asservissement en position de la machine
**Étude et prise en main des drivers pour les moteurs Pas à Pas
*Réalisation de l’interface commande-puissance
*Réaliser la conversion des données de position (relatives) de l’emplacement souhaités des composants en mouvements pour la machine
**Concevoir l’interface de récupération des données du fichier Gerber de l’utilisateur
**Caractérisation des différents repères (repère de la machine, repère de l’outil et repère de la carte) et établir le lien entres eux
**Détecter l’origine du repère de la carte au moyen d’une caméra fixe
===Planning prévisionnel de répartition du travail===
{| class="wikitable alternance centre"
|-
! scope="row" | Semaine 39 (21/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 40 (28/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 41 (05/10)
| Dimensionnement des éléments du système et recherche du matériel à commander en tenant compte des contraintes de coût
|-
! scope="row" | Semaine 42 (12/10)
| Achat du matériel pour le châssis de la machine (bois, tiges métalliques...) et pré-assemblage / Conception des pièces mécaniques à imprimer au FabLab
|-
! scope="row" | Semaine 43 (19/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position
|-
! scope="row" | Semaine 44 (26/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 45 (02/11)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de la commande des moteurs et du repérage caméra
|-
! scope="row" | Semaine 46 (09/11)
| Dans l'attente de la réception du matériel commandé : Fabrication du châssis - assemblage des pièces / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 47 (16/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 48 (23/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 49 (30/11)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 50 (07/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 51 (14/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 52 (21/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 53 (28/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 01 (04/01)
|
|-
! scope="row" | Semaine 02 (11/01)
|
|-
! scope="row" | Semaine 03 (18/01)
|
|-
! scope="row" | Semaine 04 (25/01)
|
|-
! scope="row" | Semaine 05 (01/02)
|
|-
! scope="row" | Semaine 06 (08/02)
|
|-
! scope="row" | Semaine 07 (15/02)
|
|-
! scope="row" | Semaine 08 (22/02)
|
|-
|}

===Retour sur les directives des encadrants===
====M. Flamen====
[[Fichier:Exemple composant cms.jpg|200px|thumb|right|Exemple de composants CMS]]
Dans un premier temps, pour mieux définir les objectifs de notre projet, nous avons pris rendez vous avec M. Flamen. M. Flamen est le responsable du service électronique de PolytechLille. Il est le principal intéressé par notre projet car celui-ci (le projet) permettrait de disposer de la chaîne complète de fabrication de cartes électroniques CMS (composants montés en surface).

Cette rencontre avec M. Flamen nous a permis de déterminer certaines précisions, comme:
* La précision maximale demandé n'excédera pas 0,2 mm (précision de classe 5, qui est celle de la graveuse de carte du service EEI).

===Liste de matériel===
====Matériel disponible====
*Support
** 3 Tiges de 1 mètre [Reçu le 2015-10-12]
** 1 Tasseau de 2m70 (découpé pour fabriquer les supports des tiges) [Reçu le 2015-10-12]
** 1 Planche en bois pour effectuer le support du projet [Reçu le 2015-10-12]
*Motorisation
**2 Moteurs Pas à Pas type NEMA 17 (pour axes X et Y) [http://www.gotronic.fr/art-moteur-17hs15-0404s-18354.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas (pour rotation autour de Z) [http://www.gotronic.fr/art-moteur-24byj48-19028.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas avec glissière intégrée (pour translation selon Z) [http://www.gotronic.fr/art-moteur-pas-a-pas-a-glissiere-800180001-21817.htm][Reçu le 2015-11-09]
**4 drivers pour moteur Pas à Pas bipolaire [http://www.gotronic.fr/art-driver-de-moteur-pas-a-pas-a4988-1182-21718.htm][Reçu le 2015-11-09]
*Outil d'aspiration
**Aiguille manipulant le composant [http://www.gotronic.fr/art-jeu-de-4-aiguilles-eso12-7428.htm][Reçu le 2015-11-09]
**Tube flexible [http://fr.rs-online.com/web/p/tubes-flexibles/7989985/][Reçu le 2015-11-09]
*Châssis mécanique
**2 Courroies crantées [http://fr.rs-online.com/web/p/courroies-crantees/4749614/][Reçu le 2015-11-09]
**4 Poulies crantées [http://fr.rs-online.com/web/p/poulies-pour-courroies-crantees/0182565/][Reçu le 2015-11-09]
*2 Courroies crantées plus grandes [Reçu le 2015-12-27]
====Matériel manquant====
* Rien pour le moment

==Fabrication de l'infrastructure mécanique==
[[Fichier:assp_usinage1.jpg|200px|thumb|left|Usinage des pylônes à la perceuse à colonne]]
[[Fichier:assp_usinage2.jpg|200px|thumb|right|Tour conventionnel utilisé pour le perçage]]
[[Fichier:assp_usinage3.jpg|200px|thumb|left|Marquages sur le support pour la pose de pylônes]]
[[Fichier:assp_usinage4.jpg|200px|thumb|right|Etat de la maquette avant la fixation finale]]
Notre projet comprend une partie extrêmement importante de conception. Sur conseils de M. Astori, nous avons donc décidé d'utiliser une organisation plus particulière. Le principe de cette organisation est de créer des pièces (on parle ici uniquement de leur impression à l'imprimante 3D et de la phase de conception sous Catia) rapidement, avec une faible taux de remplissage (de l'ordre de 30%). Le but de cette méthode est de créer un nombre de pièces plus important, permettant plus facilement rectifications en fonction des remarques que nous tirons du montage.

===La partie usinage===
Nous avons commencé par acheter une support contreplaqué en bois. Sur ce support, nous avons disposé quatre pylônes reliés deux à deux par un axe métallique. Nous avons donc découpé à la scie à chantourner plusieurs linteaux de bois pour fabriquer les pylônes. Ensuite, nous avons usiné les pylônes à l'aide d'une perceuse à colonne pour leur permettre de recevoir l'axe métallique.

Ensuite, nous avons eu la surprise de recevoir des poulies non percées. Nous avons donc du les percer. Nous avons percé les deux premières à l'aide de la perceuse à colonne. Le désavantage de cet outil est son imprécision sur la largeur de perçage. De plus, il n'était pas possible d'y ajouter un mécanisme permettant son maintien au moteur. Par conséquent, nous avons eu la chance d'être aidé par l'atelier mécanique. Ainsi, nous avons usiné les deux dernières poulies à l'aide d'un tour conventionnel (sous la supervision du responsable de l'atelier mécanique). Nous avons ensuite, toujours avec l'aide de M.Yoan Dhont, percé les deux poulies selon un axe perpendiculaire au précédent et créé un filetage pour permettre l'insertion d'une vis sans tête pour assurer la fixation au moteur.

Pour des raisons pratiques et esthétiques, nous avons demandé à la menuiserie de Polytech Lille de corriger nos pylônes pour assurer leur perpendicularité. Cette correction a été effectuée par M. David [TODO] et M. JP [TODO] à l'aide d'une scie à bande. Par la suite, nous avons marqué le support pour faciliter le perçage et l'ajustement des pylônes. Une fois les marquages, nous avons percé le support et les pylônes pour assurer une bonne fixation.

===La partie impression===
[[Fichier:assp_impression1.png|200px|thumb|left|Version 1 et 2 du guide axe avec moteur]]
[[Fichier:assp_impression2.png|180px|thumb|right|Guide axe antagoniste (sans moteur)]]
[[Fichier:assp_impression3.png|200px|thumb|left|Guide de poulie et garde moteur]]
Nous avons commencé par créé un chariot permettant le déplacement selon l'axe X, et permettant d'embarquer le moteur pour le déplacement selon Y. Nous l'avons créé à l'aide du logiciel Catia. Les cotes imposés sur le schéma sont celles fournies par la documentation et par mesure des axes métalliques au pieds à coulisse.

Après impression, nous nous sommes aperçu que la documentation comprenait une erreur importante sur la taille des moteurs, nous obligeant à réimprimer une deuxième pièce. Nous avons profiter de la deuxième impression pour réduire la surface de contexte entre l'axe X de la pièce et l'axe métallique X.

La deuxième pièce est très identique à la première à la différence près qu'elle n'embarque pas de moteur. Elle embarque uniquement une poulie permettant le passage de la courroie de transport en Y. Cette version, bien que fonctionnelle, n'a pas eu (pour le moment) l'amélioration apportée par la deuxième version de la pièce 1 (c'est à dire la réduction de surface de contact).

Les deux dernières pièces sont des pièces de support pour permettre au moteur de l'axe X et à la poulie de l'axe X de se maintenir sur leur pylône respectif. Le support de poulie n'a tenu que deux jours avant de rendre l'âme. Nous avons donc remplacé de façon temporaire son axe par une longue vis à bois. Le support de moteur n'a, lui, pas cassé, mais nécessite d'être imprimer une deuxième fois car la documentation du moteur était incorrecte (encore une fois).

Quelques jours avant la pré soutenance, les pièces semblent fonctionnelles. Une amélioration peut être apportée dans un second temps en modifiant les guide d'axe par des poulies (imprimées à l'imprimante 3D) permettant de suivre plus fidèlement l'axe métallique. Ce système sera développé durant les semaines suivants la pré soutenance.

==Motorisation et asservissement en position==
===Besoins et choix des moteurs===
Nous avons besoin de déplacer notre chariot comportant l'outil d'aspiration qui manipule les composants selon les 3 axes de l'espace X, Y et Z. Afin d'assurer les translations dans le plan (X,Y), nous nous sommes orienté vers un système moteur-poulie-courroie sur chacun de ces 2 axes. Nous avons besoin d'une précision en position de l'ordre de 0,2mm et n'avons pas un besoin en couple important, ni d'un asservissement en vitesse spécifique.

Nous avons donc choisi d'utiliser des moteurs Pas à Pas, qui offrent les avantages d'être précis en terme de position angulaire, de pouvoir adapter cette précision en les commandant en micro-pas et surtout de pouvoir réaliser l'asservissement en position sans capteurs. En effet, nous nous baserons sur le comptage du nombre de pas que l'on a fait effectuer au moteur, en supposant qu'aucun pas n'est sauté durant le déplacement. En effet, dans notre application la charge a entrainer est suffisamment faible et le déplacement se fera a une vitesse suffisamment basse afin d'assurer cette hypothèse.

Dans une seconde version, pour être sûr du positionnement et pour palier aux imprécisions (type jeux sur la maquette...) sur la position initiale, la position de la poulie et son diamètre, nous mettrons en place un système d'ajustement via une caméra, où l'utilisateur viendra valider le placement du composant avant dépose sur la carte.

Le déplacement de position est alors déduit ainsi : <math>\Delta X = \mu_{micropas} * \theta_{Pas_{nominal}} * R_{poulie} * \Delta {N_{Pas}}</math>

avec <math>\theta_{Pas_{nominal}}</math> le pas angulaire de nos moteurs en radian (ici, 1,8°=0,031415 rad) ,<math>\mu_{micropas}</math> le facteur de micro-pas choisi (typiquement 1/2, 1/4, voire 1/8), <math>R_{poulie}</math> le rayon du moyen de la poulie crantée en mm (ici 7,15mm) et <math>\Delta {N_{Pas}}</math> le nombre de pas demandé (dans un sens ou dans un autre).

Pour enfin connaitre la position absolue, il s'agit de connaitre la position initiale du chariot. Ceci sera réalisé avec des capteurs "fin de course", type contacteurs à lamelles.

===Commande des moteurs Pas à Pas===

[[Fichier:assp_schema_bipolar_stepper_4.png|140px|thumb|left|Schéma symbolisant les phases et l'arbre du moteur Pas à Pas bipolaire]]
[[Fichier:assp_schema_bipolar_stepper.jpg|300px|thumb|right|Schéma de la séquence d'alimentation complète du moteur bipolaire, en pas complet]]

Le principal inconvénient des moteurs Pas à Pas réside dans la commande de ceux-ci. En effet, un moteur Pas à Pas est un moteur particulier sans balai et alimenté par une alimentation continue. Il comporte plusieurs bobines permettant de créer un champ magnétique à l'intérieur et ainsi d'orienter des aimants fixés au rotor dans la direction du champ magnétique crée, ce qui provoque la rotation de l'arbre. On utilise le terme Pas à Pas car le champ magnétique crée à l'intérieur se fait par incréments. Ainsi pour faire tourner l'arbre entièrement, il faut effectuer l'alimentation des bobines pour une position 1, puis position 2, et ainsi de suite, selon la géométrie et la technologie du moteur utilisées.

Ainsi, le contrôle de celui ci s'effectue par une séquence d'alimentation spécifique de ses différentes phases. Dans notre cas, nous avons choisi des moteurs bipolaires (de type Hybride, c'est à dire combinant les avantages des technologies "à aimant permanent" et à "réluctance variable"). Le sens de rotation des ces moteurs dépend de l'ordre d'alimentation des 2 bobines, ainsi que du sens du courant.

Ce pilotage peut s'effectuer au moyen d'une électronique de puissance type pont en H, sur laquelle on pilote les séquences de commutation des différentes cellules de commutation (transistor + diode en sens inverse en parallèle). Cependant une telle structure est compliquée à mettre en place au niveau des séquences, n'intègre pas directement de limitation active du courant délivré dans la bobine et surtout n'intègre pas directement de variation de courant afin de contrôler le moteur en micro-pas.

Présentant des prix très faibles (environ 5€) pour l'économie de temps et la simplicité d'utilisation qu'ils représentent, nous avons donc cherché des solutions de drivers adaptés à nos moteurs. Basé sur le circuit A4988 d'Allegro, nous nous sommes tourné vers ce driver pour moteur bipolaire (Pololu A4988 Stepper Motor Driver Carrier). Son principe est simple : il intègre directement cette structure de pont en H et les séquences d'alimentation. Il permet ainsi de faire effectuer au moteur un pas en envoyant une impulsion (front montant) sur sa pin STEP, dans le sens défini par l'état (haut ou bas) de sa pin DIR.

[[Fichier:assp_driver_pololu_pinout.png|380px|thumb|centre|Schéma du fonctionnement et du branchement du driver]]

Ce driver réalise également l'interface commande-puissance, il comporte une alimentation séparée pour le circuit logique (5V) et l'alimentation de puissance des moteurs (ici 12V). Il est très important pour éviter la surchauffe et l'endommagement des moteurs de contrôler le courant envoyé dans ses bobines. Nous limitons ainsi activement ce courant grâce au driver au moyen d'un potentiomètre à régler sur ce dernier. Nous avons réglé cette valeur par rapport aux courants nominaux par phase de nos moteurs.

L'avantage majeur de ce driver est qu'il comporte une solution de fonctionnement en micro-pas directement. Par l'état de ses pins MS1, MS2 et MS3, il nous permet de piloter du pas complet, au 1/16 de pas (maximum). Nous ne piloterons pas jusqu'au 1/16 de pas pour des soucis de stabilité du couple mécanique et pour éviter de sauter des pas, 1/4 voire 1/8 de pas devrait être suffisant. Le choix du micropas maximum sera à déterminer avec les tests sur la machine.

Ainsi, nous pilotons toutes ces différentes entrées par le biais d'un Arduino Mega. Plus tard, cet Arduino Mega servira d'interface entre la consigne de position envoyée depuis l'application PC et les moteurs.

[[Fichier:|200px|thumb|right|Photo de la partie commande des moteurs]]

==Création de l'outil de manipulation par aspiration==

L'outil qui viendra attraper et déposer les composants sera composé d'une aiguille fine qui les maintiendra par aspiration. Le système sera donc composé d'une pompe à vide, type pompe d'aquariophilie, peu couteuse, car l'aspiration nécessaire pour maintenir un composant est vraiment très faible. Ce genre de pompe se commande en tout ou rien au moyen d'un interrupteur manuel. Afin de ne pas alterner cycles d'allumage de la pompe pour éviter de l'endommager et surtout d'attendre le temps d'établissement du débit à chaque fois, lors des phases aspiration-dépose, nous utiliserons un distributeur pneumatique qui viendra envoyer ou non la dépression dans le tuyau d'air.

Une partie majeure du travail va consister en la conception de la pièce mécanique, le chariot, qui intégrera les moteurs pour effectuer la translation et la rotation autour de Z, un capteur piézoélectrique qui permettra la détection du contact entre le composant et la carte et qui intégrera un espace prévu à cet effet pour maintenir le tuyau et l'aiguille. Ce chariot sera adaptable au reste du châssis et comportera une partie qui le fixe à la courroie.

Niveau matériel pour cette partie, nous avons pour le moment réuni le distributeur, les tuyaux et l'aiguille. Nous devrions recevoir la pompe sous peu de temps.

==Conception du logiciel==
===Définition du cadre===
Un des buts de ce projet est de concevoir une application permettant de contrôler les différents éléments du projet. Pour cela nous, l'application doit être capable de lire des fichiers standards de création de carte électronique (aussi appelés fichiers Gerber). De plus, nous souhaitions que l'application puisse être utilisé sur n'importe quelle plateforme. Pour cela, nous avons choisi de la développer sous [http://www.qt.io/ Qt]. L’environnement de travail Qt nous permet d'utiliser des objets permettant l'accès à n'importe quel type de matériel sans se soucier de la plateforme de destination. Pour la communication avec les éléments de commande (comme les moteurs) nous avons choisi de n'envoyer des ordres qu'à travers l'Arduino Mega.
===La communication entre le logiciel et l'Arduino Mega===
==Création d'un système sûr pour Arduino Mega==
L'application de bureau que nous avons créé va, comme expliqué précédemment, communiqué avec un Arduino Mega. Cet Arduino s'occupera de la commande de la partie du puissance du reste du système. Ces fonctions sont:
* Commander des moteurs sur les axes X, Y et Z
* Commander de la rotation selon Z
* Contrôler de la pompe
* Définir les paramètres avancés des moteurs (vitesse, précision des micropas)
* S'assurer de ne pas commander un ordre endommageant la machine
===Le protocole de communication===
[[Fichier:ASSP_mega_task_flowchart.png|200px|thumb|right]]Pour permettre de réaliser ces fonctions, l'application communique à travers le port série avec l'Arduino Mega. Le protocole utilisé est rendant le plus compact possible pour limiter le nombre de communications.
L'Arduino Mega ne fonctionne que par tâches (comme décris sur le schéma à droite). La seule possibilité pour l'Arduino de ne pas être dans cette exécution de tâches est d'être interrompu par un contact à lamelle souple (que nous considérons comme prioritaire). Dans ce cas, l'Arduino reste bloqué dans la fonction appelé par l'interruption jusqu'à temps que l'utilisateur valide manuellement la déverrouillage (ce qui permet d'éviter que le système ne puisse s’abîmer).
====Les trames de base====
{| class="wikitable"
|+ Commande d'initialisation d'une tâche (PC->Mega)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Paramètre
| colspan="4" |Fonction appelée
|}
{| class="wikitable"
|+ Commande de réponse d'une tâche (Mega->PC)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Donnée dépendant de la fonction
| colspan="4" | Code de retour
|}
Si le code de retour est différent de 0, les trames de retour 2 et 3 ne sont pas envoyées
{| class="wikitable"
|+ Liste des codes de retour
! scope="col" colspan="5" | Code retourné
! scope="col" rowspan="2" | Nom dans le header
! scope="col" rowspan="2" | Action à prendre
! scope="col" rowspan="2" | Description du code
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| CMD_OK
| Aucune
| La commande s'est exécutée correctement
|-
| 0
| 0
| 0
| 1
| 0x01
| CMD_NOT_KNOWN
| Report immédiat
| La commande demandée n'est pas connue
|-
| 0
| 0
| 1
| 0
| 0x02
| CMD_DEST_UNREACHABLE
| Report immédiat
| L'appel à la commande setDest a le paramètre dest trop grand sur le moteur choisi
|-
| 0
| 0
| 1
| 1
| 0x03
| CMD_LOCK_MIN_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son minimum
|-
| 0
| 1
| 0
| 0
| 0x04
| CMD_LOCK_MAX_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son maximum
|-
| 0
| 0
| 1
| 1
| 0x05
| CMD_LOCK_MIN_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son minimum
|-
| 0
| 1
| 1
| 0
| 0x06
| CMD_LOCK_MAX_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son maximum
|-
| 0
| 1
| 1
| 1
| 0x07
| CMD_LOCK_MIN_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son minimum
|-
| 1
| 0
| 0
| 0
| 0x08
| CMD_LOCK_MAX_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son maximum
|}

====Liste des fonctions d'écriture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Paramètre 2
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| setDest
| selectedMotor[2bits]
| destination[16bits]
| Donne la consigne de position en seizième de pas par rapport à l'origine
|-
| 0
| 0
| 0
| 1
| 0x01
| setMS
| selectedMotor[2bits]
| microStep[3bits]
| Donne la consigne du nombre de micropas par tour pour un moteur
|-
| 0
| 0
| 1
| 0
| 0x02
| setPump
| onOff[1bit]
| ∅
| Donne la consigne d'allumage ou d'extinction de la pompe à vide
|-
| 0
| 0
| 1
| 1
| 0x03
| setADC
| adcLevel[10bits]
| ∅
| Donne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 0
| 1
| 0
| 0
| 0x04
| setRelease
| lockToRelease[3bits]
| ∅
| Donne la consigne de déverrouillage d'un nœud précédemment verrouillé
|-
| 1
| 1
| 0
| 1
| 0x05
| setSpeed
| selectedMotor[2bits]
| delayStep[8bits]
| Donne le temps en ms à attendre entre 2 pas (<=> la vitesse du moteur)
|}
{| class="wikitable"
|+ Détails sur la construction des fonctions d'écriture
! scope="col" rowspan="2" | Fonction appelée
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| setDest
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | destination[15:8]
| colspan="8" align="center" | destination[7:0]
|-
| setMS
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="3" align="center" | microStep[2:0]
| colspan="5" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| setPump
| align="center" | onOff
| colspan="3" align="center" | ∅
| colspan="16" align="center" | ∅
|-
| setADC
| colspan="2" align="center" | adcLevel[9:8]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| setRelease
| align="center" | ∅
| colspan="3" align="center" | lockToRelease[2:0]
| colspan="16" align="center" | ∅
|-
| setSpeed
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|}

====Liste des fonctions de lecture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 1
| 0
| 0
| 0
| 0x08
| getDest
| selectedMotor[2bits]
| Retourne la position d'un moteur donné en seizième de pas par rapport à l'origine
|-
| 1
| 0
| 0
| 1
| 0x09
| getMS
| ∅
| Retourne la consigne du nombre de micropas par tour pour tous les moteurs
|-
| 1
| 0
| 1
| 0
| 0x0A
| getPump
| ∅
| Retourne la consigne d'allumage actuelle de la pompe à vide
|-
| 1
| 0
| 1
| 1
| 0x0B
| getADC
| ∅
| Retourne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 1
| 1
| 0
| 0
| 0x0C
| getRelease
| ∅
| Retourne l'état de verrouillage des nœuds
|}
{| class="wikitable"
|+ Détails de la construction des trames de lecture
! scope="col" rowspan="3" | Fonction appelée
! scope="col" colspan="4" | Appel (PC->Mega)
! scope="col" colspan="24" | Retour (Mega->PC)
|-
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| getDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | dest[15:8]
| colspan="8" align="center" | dest[7:0]
|-
| getMS
| colspan="4" align="center" | ∅
| msY[0]
| colspan="3" align="center" | msX[2:0]
| colspan="3" align="center" | msR[2:0]
| colspan="3" align="center" | msZ[2:0]
| colspan="2" align="center" | msY[2:1]
| colspan="8" align="center" | ∅
|-
| getPump
| colspan="4" align="center" | ∅
| onOff
| colspan="3" align="center" | ∅
| colspan="8" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getADC
| colspan="4" align="center" | ∅
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| getRelease
| colspan="4" align="center" | ∅
| lockMinX1
| lockMaxX1
| lockMinX2
| lockMaxX2
| lockMinY
| lockMaxY
| colspan="6" align="center" | ∅
| colspan="8" align="center" | ∅
|}

Automatic Soldering System Project

2016-02-09T18:07:44Z

Pletouse : /* Liste des fonctions d'écriture */ Ajout de setSpeed

__TOC__
 
=Placeur de composants sur PCB=
==Présentation du projet==
Durant le début de l'été, nous avons eu l'idée de proposer un projet de soudure automatique. Ce projet avait pour but de concevoir un système permettant l'automatisation des soudures sur une carte électronique à composants traversants. Après des échanges avec le responsable des projet de 5éme année, M. Vantroys, nous avons finalement abandonné notre projet au profit d'un autre projet assez proche.

L'idée du nouveau projet est de proposer un système de Pick & Place de composants CMS sur une carte électronique sur laquelle de la crème à braser est préalablement déposée sur les pastilles. Pour mener à bien ce projet, nous avons été épaulé par M. Redon, M. Vantroys et M. Boé. En plus de nos encadrants école, nous avons travaillé en étroite collaboration avec M. Flamen, responsable du service électronique de Polytech Lille ainsi qu'avec M. Astori, enseignant en Conception Mécanique et responsable du FabLab de Polytech Lille. Nous tenons par ailleurs également à remercier chaleureusement Antoine, contributeur actif au Fablab de Polytech Lille, pour son partage d'expérience à propos de la création de son imprimante 3D RepRap, projet similaire au notre.
===Définitions des objectifs===
*Prendre un composant
**Stocker les composants à déposer sur la carte et identifier leur position
**Maintenir le composant par aspiration
*Repérer la position et l’orientation de la carte
*Déplacer le composant
**Le déplacer en translation selon les axes X, Y et Z
**L’orienter correctement sur les pastilles (rotation autour de Z)
*Déposer le composant
**S’assurer que l’outil d’aspiration n’endommage ni la carte, ni le composant lors de la dépose -> détecter le contact entre le composant et la carte
*Connaître la position désirée pour la dépose du composant
**Récupérer les fichiers provenant du logiciel de CAO et les transformer en déplacement de la machine
**Permettre à l’utilisateur d’avoir une interface visuelle (sur ordinateur) indiquant l’état des éléments de la machine et permettant leur calibrage
===Liste des tâches===
*Créer l’infrastructure mécanique de la machine (châssis)
**Fabrication du châssis
**Design des pièces mobiles et impression 3D de ces pièces au FabLab (chariot comportant l’outil d’aspiration et “guides tubes” assurant la transformation de la rotation des moteurs en mouvement de translation (glissières) sur des barres métalliques)
**Assembler l’outil d’aspiration au chariot
*Concevoir la commande d’aspiration par pompe
*Organiser la commande des moteurs du système pour l’asservissement en position de la machine
**Étude et prise en main des drivers pour les moteurs Pas à Pas
*Réalisation de l’interface commande-puissance
*Réaliser la conversion des données de position (relatives) de l’emplacement souhaités des composants en mouvements pour la machine
**Concevoir l’interface de récupération des données du fichier Gerber de l’utilisateur
**Caractérisation des différents repères (repère de la machine, repère de l’outil et repère de la carte) et établir le lien entres eux
**Détecter l’origine du repère de la carte au moyen d’une caméra fixe
===Planning prévisionnel de répartition du travail===
{| class="wikitable alternance centre"
|-
! scope="row" | Semaine 39 (21/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 40 (28/09)
| Brainstorming et réunions avec les encadrants de projet afin de définir les objectifs / Étude de faisabilité
|-
! scope="row" | Semaine 41 (05/10)
| Dimensionnement des éléments du système et recherche du matériel à commander en tenant compte des contraintes de coût
|-
! scope="row" | Semaine 42 (12/10)
| Achat du matériel pour le châssis de la machine (bois, tiges métalliques...) et pré-assemblage / Conception des pièces mécaniques à imprimer au FabLab
|-
! scope="row" | Semaine 43 (19/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position
|-
! scope="row" | Semaine 44 (26/10)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 45 (02/11)
| Dans l'attente de la réception du matériel commandé : Conception des pièces mécaniques à imprimer au FabLab / Développement de l'application PC / Étude de la commande des moteurs et du repérage caméra
|-
! scope="row" | Semaine 46 (09/11)
| Dans l'attente de la réception du matériel commandé : Fabrication du châssis - assemblage des pièces / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 47 (16/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 48 (23/11)
| Dans l'attente de la réception du matériel commandé : Impression 3D des pièces mécaniques / Développement de l'application PC / Étude de l'asservissement en position et du repérage caméra
|-
! scope="row" | Semaine 49 (30/11)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 50 (07/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 51 (14/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 52 (21/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 53 (28/12)
| Réception espérée du matériel : Montage de la maquette / Prise en main et calibrage des éléments / Tests
|-
! scope="row" | Semaine 01 (04/01)
|
|-
! scope="row" | Semaine 02 (11/01)
|
|-
! scope="row" | Semaine 03 (18/01)
|
|-
! scope="row" | Semaine 04 (25/01)
|
|-
! scope="row" | Semaine 05 (01/02)
|
|-
! scope="row" | Semaine 06 (08/02)
|
|-
! scope="row" | Semaine 07 (15/02)
|
|-
! scope="row" | Semaine 08 (22/02)
|
|-
|}

===Retour sur les directives des encadrants===
====M. Flamen====
[[Fichier:Exemple composant cms.jpg|200px|thumb|right|Exemple de composants CMS]]
Dans un premier temps, pour mieux définir les objectifs de notre projet, nous avons pris rendez vous avec M. Flamen. M. Flamen est le responsable du service électronique de PolytechLille. Il est le principal intéressé par notre projet car celui-ci (le projet) permettrait de disposer de la chaîne complète de fabrication de cartes électroniques CMS (composants montés en surface).

Cette rencontre avec M. Flamen nous a permis de déterminer certaines précisions, comme:
* La précision maximale demandé n'excédera pas 0,2 mm (précision de classe 5, qui est celle de la graveuse de carte du service EEI).

===Liste de matériel===
====Matériel disponible====
*Support
** 3 Tiges de 1 mètre [Reçu le 2015-10-12]
** 1 Tasseau de 2m70 (découpé pour fabriquer les supports des tiges) [Reçu le 2015-10-12]
** 1 Planche en bois pour effectuer le support du projet [Reçu le 2015-10-12]
*Motorisation
**2 Moteurs Pas à Pas type NEMA 17 (pour axes X et Y) [http://www.gotronic.fr/art-moteur-17hs15-0404s-18354.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas (pour rotation autour de Z) [http://www.gotronic.fr/art-moteur-24byj48-19028.htm][Reçu le 2015-11-09]
**1 Moteur Pas à Pas avec glissière intégrée (pour translation selon Z) [http://www.gotronic.fr/art-moteur-pas-a-pas-a-glissiere-800180001-21817.htm][Reçu le 2015-11-09]
**4 drivers pour moteur Pas à Pas bipolaire [http://www.gotronic.fr/art-driver-de-moteur-pas-a-pas-a4988-1182-21718.htm][Reçu le 2015-11-09]
*Outil d'aspiration
**Aiguille manipulant le composant [http://www.gotronic.fr/art-jeu-de-4-aiguilles-eso12-7428.htm][Reçu le 2015-11-09]
**Tube flexible [http://fr.rs-online.com/web/p/tubes-flexibles/7989985/][Reçu le 2015-11-09]
*Châssis mécanique
**2 Courroies crantées [http://fr.rs-online.com/web/p/courroies-crantees/4749614/][Reçu le 2015-11-09]
**4 Poulies crantées [http://fr.rs-online.com/web/p/poulies-pour-courroies-crantees/0182565/][Reçu le 2015-11-09]
*2 Courroies crantées plus grandes [Reçu le 2015-12-27]
====Matériel manquant====
* Rien pour le moment

==Fabrication de l'infrastructure mécanique==
[[Fichier:assp_usinage1.jpg|200px|thumb|left|Usinage des pylônes à la perceuse à colonne]]
[[Fichier:assp_usinage2.jpg|200px|thumb|right|Tour conventionnel utilisé pour le perçage]]
[[Fichier:assp_usinage3.jpg|200px|thumb|left|Marquages sur le support pour la pose de pylônes]]
[[Fichier:assp_usinage4.jpg|200px|thumb|right|Etat de la maquette avant la fixation finale]]
Notre projet comprend une partie extrêmement importante de conception. Sur conseils de M. Astori, nous avons donc décidé d'utiliser une organisation plus particulière. Le principe de cette organisation est de créer des pièces (on parle ici uniquement de leur impression à l'imprimante 3D et de la phase de conception sous Catia) rapidement, avec une faible taux de remplissage (de l'ordre de 30%). Le but de cette méthode est de créer un nombre de pièces plus important, permettant plus facilement rectifications en fonction des remarques que nous tirons du montage.

===La partie usinage===
Nous avons commencé par acheter une support contreplaqué en bois. Sur ce support, nous avons disposé quatre pylônes reliés deux à deux par un axe métallique. Nous avons donc découpé à la scie à chantourner plusieurs linteaux de bois pour fabriquer les pylônes. Ensuite, nous avons usiné les pylônes à l'aide d'une perceuse à colonne pour leur permettre de recevoir l'axe métallique.

Ensuite, nous avons eu la surprise de recevoir des poulies non percées. Nous avons donc du les percer. Nous avons percé les deux premières à l'aide de la perceuse à colonne. Le désavantage de cet outil est son imprécision sur la largeur de perçage. De plus, il n'était pas possible d'y ajouter un mécanisme permettant son maintien au moteur. Par conséquent, nous avons eu la chance d'être aidé par l'atelier mécanique. Ainsi, nous avons usiné les deux dernières poulies à l'aide d'un tour conventionnel (sous la supervision du responsable de l'atelier mécanique). Nous avons ensuite, toujours avec l'aide de M.Yoan Dhont, percé les deux poulies selon un axe perpendiculaire au précédent et créé un filetage pour permettre l'insertion d'une vis sans tête pour assurer la fixation au moteur.

Pour des raisons pratiques et esthétiques, nous avons demandé à la menuiserie de Polytech Lille de corriger nos pylônes pour assurer leur perpendicularité. Cette correction a été effectuée par M. David [TODO] et M. JP [TODO] à l'aide d'une scie à bande. Par la suite, nous avons marqué le support pour faciliter le perçage et l'ajustement des pylônes. Une fois les marquages, nous avons percé le support et les pylônes pour assurer une bonne fixation.

===La partie impression===
[[Fichier:assp_impression1.png|200px|thumb|left|Version 1 et 2 du guide axe avec moteur]]
[[Fichier:assp_impression2.png|180px|thumb|right|Guide axe antagoniste (sans moteur)]]
[[Fichier:assp_impression3.png|200px|thumb|left|Guide de poulie et garde moteur]]
Nous avons commencé par créé un chariot permettant le déplacement selon l'axe X, et permettant d'embarquer le moteur pour le déplacement selon Y. Nous l'avons créé à l'aide du logiciel Catia. Les cotes imposés sur le schéma sont celles fournies par la documentation et par mesure des axes métalliques au pieds à coulisse.

Après impression, nous nous sommes aperçu que la documentation comprenait une erreur importante sur la taille des moteurs, nous obligeant à réimprimer une deuxième pièce. Nous avons profiter de la deuxième impression pour réduire la surface de contexte entre l'axe X de la pièce et l'axe métallique X.

La deuxième pièce est très identique à la première à la différence près qu'elle n'embarque pas de moteur. Elle embarque uniquement une poulie permettant le passage de la courroie de transport en Y. Cette version, bien que fonctionnelle, n'a pas eu (pour le moment) l'amélioration apportée par la deuxième version de la pièce 1 (c'est à dire la réduction de surface de contact).

Les deux dernières pièces sont des pièces de support pour permettre au moteur de l'axe X et à la poulie de l'axe X de se maintenir sur leur pylône respectif. Le support de poulie n'a tenu que deux jours avant de rendre l'âme. Nous avons donc remplacé de façon temporaire son axe par une longue vis à bois. Le support de moteur n'a, lui, pas cassé, mais nécessite d'être imprimer une deuxième fois car la documentation du moteur était incorrecte (encore une fois).

Quelques jours avant la pré soutenance, les pièces semblent fonctionnelles. Une amélioration peut être apportée dans un second temps en modifiant les guide d'axe par des poulies (imprimées à l'imprimante 3D) permettant de suivre plus fidèlement l'axe métallique. Ce système sera développé durant les semaines suivants la pré soutenance.

==Motorisation et asservissement en position==
===Besoins et choix des moteurs===
Nous avons besoin de déplacer notre chariot comportant l'outil d'aspiration qui manipule les composants selon les 3 axes de l'espace X, Y et Z. Afin d'assurer les translations dans le plan (X,Y), nous nous sommes orienté vers un système moteur-poulie-courroie sur chacun de ces 2 axes. Nous avons besoin d'une précision en position de l'ordre de 0,2mm et n'avons pas un besoin en couple important, ni d'un asservissement en vitesse spécifique.

Nous avons donc choisi d'utiliser des moteurs Pas à Pas, qui offrent les avantages d'être précis en terme de position angulaire, de pouvoir adapter cette précision en les commandant en micro-pas et surtout de pouvoir réaliser l'asservissement en position sans capteurs. En effet, nous nous baserons sur le comptage du nombre de pas que l'on a fait effectuer au moteur, en supposant qu'aucun pas n'est sauté durant le déplacement. En effet, dans notre application la charge a entrainer est suffisamment faible et le déplacement se fera a une vitesse suffisamment basse afin d'assurer cette hypothèse.

Dans une seconde version, pour être sûr du positionnement et pour palier aux imprécisions (type jeux sur la maquette...) sur la position initiale, la position de la poulie et son diamètre, nous mettrons en place un système d'ajustement via une caméra, où l'utilisateur viendra valider le placement du composant avant dépose sur la carte.

Le déplacement de position est alors déduit ainsi : <math>\Delta X = \mu_{micropas} * \theta_{Pas_{nominal}} * R_{poulie} * \Delta {N_{Pas}}</math>

avec <math>\theta_{Pas_{nominal}}</math> le pas angulaire de nos moteurs en radian (ici, 1,8°=0,031415 rad) ,<math>\mu_{micropas}</math> le facteur de micro-pas choisi (typiquement 1/2, 1/4, voire 1/8), <math>R_{poulie}</math> le rayon du moyen de la poulie crantée en mm (ici 7,15mm) et <math>\Delta {N_{Pas}}</math> le nombre de pas demandé (dans un sens ou dans un autre).

Pour enfin connaitre la position absolue, il s'agit de connaitre la position initiale du chariot. Ceci sera réalisé avec des capteurs "fin de course", type contacteurs à lamelles.

===Commande des moteurs Pas à Pas===

[[Fichier:assp_schema_bipolar_stepper_4.png|140px|thumb|left|Schéma symbolisant les phases et l'arbre du moteur Pas à Pas bipolaire]]
[[Fichier:assp_schema_bipolar_stepper.jpg|300px|thumb|right|Schéma de la séquence d'alimentation complète du moteur bipolaire, en pas complet]]

Le principal inconvénient des moteurs Pas à Pas réside dans la commande de ceux-ci. En effet, un moteur Pas à Pas est un moteur particulier sans balai et alimenté par une alimentation continue. Il comporte plusieurs bobines permettant de créer un champ magnétique à l'intérieur et ainsi d'orienter des aimants fixés au rotor dans la direction du champ magnétique crée, ce qui provoque la rotation de l'arbre. On utilise le terme Pas à Pas car le champ magnétique crée à l'intérieur se fait par incréments. Ainsi pour faire tourner l'arbre entièrement, il faut effectuer l'alimentation des bobines pour une position 1, puis position 2, et ainsi de suite, selon la géométrie et la technologie du moteur utilisées.

Ainsi, le contrôle de celui ci s'effectue par une séquence d'alimentation spécifique de ses différentes phases. Dans notre cas, nous avons choisi des moteurs bipolaires (de type Hybride, c'est à dire combinant les avantages des technologies "à aimant permanent" et à "réluctance variable"). Le sens de rotation des ces moteurs dépend de l'ordre d'alimentation des 2 bobines, ainsi que du sens du courant.

Ce pilotage peut s'effectuer au moyen d'une électronique de puissance type pont en H, sur laquelle on pilote les séquences de commutation des différentes cellules de commutation (transistor + diode en sens inverse en parallèle). Cependant une telle structure est compliquée à mettre en place au niveau des séquences, n'intègre pas directement de limitation active du courant délivré dans la bobine et surtout n'intègre pas directement de variation de courant afin de contrôler le moteur en micro-pas.

Présentant des prix très faibles (environ 5€) pour l'économie de temps et la simplicité d'utilisation qu'ils représentent, nous avons donc cherché des solutions de drivers adaptés à nos moteurs. Basé sur le circuit A4988 d'Allegro, nous nous sommes tourné vers ce driver pour moteur bipolaire (Pololu A4988 Stepper Motor Driver Carrier). Son principe est simple : il intègre directement cette structure de pont en H et les séquences d'alimentation. Il permet ainsi de faire effectuer au moteur un pas en envoyant une impulsion (front montant) sur sa pin STEP, dans le sens défini par l'état (haut ou bas) de sa pin DIR.

[[Fichier:assp_driver_pololu_pinout.png|380px|thumb|centre|Schéma du fonctionnement et du branchement du driver]]

Ce driver réalise également l'interface commande-puissance, il comporte une alimentation séparée pour le circuit logique (5V) et l'alimentation de puissance des moteurs (ici 12V). Il est très important pour éviter la surchauffe et l'endommagement des moteurs de contrôler le courant envoyé dans ses bobines. Nous limitons ainsi activement ce courant grâce au driver au moyen d'un potentiomètre à régler sur ce dernier. Nous avons réglé cette valeur par rapport aux courants nominaux par phase de nos moteurs.

L'avantage majeur de ce driver est qu'il comporte une solution de fonctionnement en micro-pas directement. Par l'état de ses pins MS1, MS2 et MS3, il nous permet de piloter du pas complet, au 1/16 de pas (maximum). Nous ne piloterons pas jusqu'au 1/16 de pas pour des soucis de stabilité du couple mécanique et pour éviter de sauter des pas, 1/4 voire 1/8 de pas devrait être suffisant. Le choix du micropas maximum sera à déterminer avec les tests sur la machine.

Ainsi, nous pilotons toutes ces différentes entrées par le biais d'un Arduino Mega. Plus tard, cet Arduino Mega servira d'interface entre la consigne de position envoyée depuis l'application PC et les moteurs.

[[Fichier:|200px|thumb|right|Photo de la partie commande des moteurs]]

==Création de l'outil de manipulation par aspiration==

L'outil qui viendra attraper et déposer les composants sera composé d'une aiguille fine qui les maintiendra par aspiration. Le système sera donc composé d'une pompe à vide, type pompe d'aquariophilie, peu couteuse, car l'aspiration nécessaire pour maintenir un composant est vraiment très faible. Ce genre de pompe se commande en tout ou rien au moyen d'un interrupteur manuel. Afin de ne pas alterner cycles d'allumage de la pompe pour éviter de l'endommager et surtout d'attendre le temps d'établissement du débit à chaque fois, lors des phases aspiration-dépose, nous utiliserons un distributeur pneumatique qui viendra envoyer ou non la dépression dans le tuyau d'air.

Une partie majeure du travail va consister en la conception de la pièce mécanique, le chariot, qui intégrera les moteurs pour effectuer la translation et la rotation autour de Z, un capteur piézoélectrique qui permettra la détection du contact entre le composant et la carte et qui intégrera un espace prévu à cet effet pour maintenir le tuyau et l'aiguille. Ce chariot sera adaptable au reste du châssis et comportera une partie qui le fixe à la courroie.

Niveau matériel pour cette partie, nous avons pour le moment réuni le distributeur, les tuyaux et l'aiguille. Nous devrions recevoir la pompe sous peu de temps.

==Conception du logiciel==
===Définition du cadre===
Un des buts de ce projet est de concevoir une application permettant de contrôler les différents éléments du projet. Pour cela nous, l'application doit être capable de lire des fichiers standards de création de carte électronique (aussi appelés fichiers Gerber). De plus, nous souhaitions que l'application puisse être utilisé sur n'importe quelle plateforme. Pour cela, nous avons choisi de la développer sous [http://www.qt.io/ Qt]. L’environnement de travail Qt nous permet d'utiliser des objets permettant l'accès à n'importe quel type de matériel sans se soucier de la plateforme de destination. Pour la communication avec les éléments de commande (comme les moteurs) nous avons choisi de n'envoyer des ordres qu'à travers l'Arduino Mega.
===La communication entre le logiciel et l'Arduino Mega===
==Création d'un système sûr pour Arduino Mega==
L'application de bureau que nous avons créé va, comme expliqué précédemment, communiqué avec un Arduino Mega. Cet Arduino s'occupera de la commande de la partie du puissance du reste du système. Ces fonctions sont:
* Commander des moteurs sur les axes X, Y et Z
* Commander de la rotation selon Z
* Contrôler de la pompe
* Définir les paramètres avancés des moteurs (vitesse, précision des micropas)
* S'assurer de ne pas commander un ordre endommageant la machine
===Le protocole de communication===
[[Fichier:ASSP_mega_task_flowchart.png|200px|thumb|right]]Pour permettre de réaliser ces fonctions, l'application communique à travers le port série avec l'Arduino Mega. Le protocole utilisé est rendant le plus compact possible pour limiter le nombre de communications.
L'Arduino Mega ne fonctionne que par tâches (comme décris sur le schéma à droite). La seule possibilité pour l'Arduino de ne pas être dans cette exécution de tâches est d'être interrompu par un contact à lamelle souple (que nous considérons comme prioritaire). Dans ce cas, l'Arduino reste bloqué dans la fonction appelé par l'interruption jusqu'à temps que l'utilisateur valide manuellement la déverrouillage (ce qui permet d'éviter que le système ne puisse s’abîmer).
====Les trames de base====
{| class="wikitable"
|+ Commande d'initialisation d'une tâche (PC->Mega)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Paramètre
| colspan="4" |Fonction appelée
|}
{| class="wikitable"
|+ Commande de réponse d'une tâche (Mega->PC)
|-
! scope="row" | Bits
|7
|6
|5
|4
|3
|2
|1
|0
|-
! scope="row" | Data
| colspan="4" | Donnée dépendant de la fonction
| colspan="4" | Code de retour
|}
Si le code de retour est différent de 0, les trames de retour 2 et 3 ne sont pas envoyées
{| class="wikitable"
|+ Liste des codes de retour
! scope="col" colspan="5" | Code retourné
! scope="col" rowspan="2" | Nom dans le header
! scope="col" rowspan="2" | Action à prendre
! scope="col" rowspan="2" | Description du code
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| CMD_OK
| Aucune
| La commande s'est exécutée correctement
|-
| 0
| 0
| 0
| 1
| 0x01
| CMD_NOT_KNOWN
| Report immédiat
| La commande demandée n'est pas connue
|-
| 0
| 0
| 1
| 0
| 0x02
| CMD_DEST_UNREACHABLE
| Report immédiat
| L'appel à la commande setDest a le paramètre dest trop grand sur le moteur choisi
|-
| 0
| 0
| 1
| 1
| 0x03
| CMD_LOCK_MIN_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son minimum
|-
| 0
| 1
| 0
| 0
| 0x04
| CMD_LOCK_MAX_X1
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 1 à son maximum
|-
| 0
| 0
| 1
| 1
| 0x05
| CMD_LOCK_MIN_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son minimum
|-
| 0
| 1
| 1
| 0
| 0x06
| CMD_LOCK_MAX_X2
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe X 2 à son maximum
|-
| 0
| 1
| 1
| 1
| 0x07
| CMD_LOCK_MIN_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son minimum
|-
| 1
| 0
| 0
| 0
| 0x08
| CMD_LOCK_MAX_Y
| Report immédiat ou aucun
| Le chariot a déclenché le contact à lamelle souple sur l'axe Y à son maximum
|}

====Liste des fonctions d'écriture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Paramètre 2
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 0
| 0
| 0
| 0
| 0x00
| setDest
| selectedMotor[2bits]
| destination[16bits]
| Donne la consigne de position en seizième de pas par rapport à l'origine
|-
| 0
| 0
| 0
| 1
| 0x01
| setMS
| selectedMotor[2bits]
| microStep[3bits]
| Donne la consigne du nombre de micropas par tour pour un moteur
|-
| 0
| 0
| 1
| 0
| 0x02
| setPump
| onOff[1bit]
| ∅
| Donne la consigne d'allumage ou d'extinction de la pompe à vide
|-
| 0
| 0
| 1
| 1
| 0x03
| setADC
| adcLevel[10bits]
| ∅
| Donne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 0
| 1
| 0
| 0
| 0x04
| setRelease
| lockToRelease[3bits]
| ∅
| Donne la consigne de déverrouillage d'un nœud précédemment verrouillé
|-
| 1
| 1
| 0
| 1
| 0x0D
| setSpeed
| selectedMotor[2bits]
| delayStep[8bits]
| Donne le temps en ms à attendre entre 2 pas (<=> la vitesse du moteur)
|}
{| class="wikitable"
|+ Détails sur la construction des fonctions d'écriture
! scope="col" rowspan="2" | Fonction appelée
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| setDest
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | destination[15:8]
| colspan="8" align="center" | destination[7:0]
|-
| setMS
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="3" align="center" | microStep[2:0]
| colspan="5" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| setPump
| align="center" | onOff
| colspan="3" align="center" | ∅
| colspan="16" align="center" | ∅
|-
| setADC
| colspan="2" align="center" | adcLevel[9:8]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| setRelease
| align="center" | ∅
| colspan="3" align="center" | lockToRelease[2:0]
| colspan="16" align="center" | ∅
|-
| setSpeed
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="2" align="center" | ∅
| colspan="8" align="center" | delayStep[7:0]
| colspan="8" align="center" | ∅
|}

====Liste des fonctions de lecture====
{| class="wikitable"
|+ Liste des fonctions
! scope="col" colspan="5" | Fonction appelée
! scope="col" rowspan="2" | Nom de la fonction
! scope="col" rowspan="2" | Paramètre 1
! scope="col" rowspan="2" | Description fonction
|-
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | Hex
|-
| 1
| 0
| 0
| 0
| 0x08
| getDest
| selectedMotor[2bits]
| Retourne la position d'un moteur donné en seizième de pas par rapport à l'origine
|-
| 1
| 0
| 0
| 1
| 0x09
| getMS
| ∅
| Retourne la consigne du nombre de micropas par tour pour tous les moteurs
|-
| 1
| 0
| 1
| 0
| 0x0A
| getPump
| ∅
| Retourne la consigne d'allumage actuelle de la pompe à vide
|-
| 1
| 0
| 1
| 1
| 0x0B
| getADC
| ∅
| Retourne la consigne d'allumage de la valeur maximale lisible par l'ADC
|-
| 1
| 1
| 0
| 0
| 0x0C
| getRelease
| ∅
| Retourne l'état de verrouillage des nœuds
|}
{| class="wikitable"
|+ Détails de la construction des trames de lecture
! scope="col" rowspan="3" | Fonction appelée
! scope="col" colspan="4" | Appel (PC->Mega)
! scope="col" colspan="24" | Retour (Mega->PC)
|-
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="4" | Trame 1
! scope="col" colspan="8" | Trame 2
! scope="col" colspan="8" | Trame 3
|-
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
! scope="col" | b7
! scope="col" | b6
! scope="col" | b5
! scope="col" | b4
! scope="col" | b3
! scope="col" | b2
! scope="col" | b1
! scope="col" | b0
|-
| getDest
| colspan="2" align="center" | ∅
| colspan="2" align="center" | selectedMotor[1:0]
| colspan="4" align="center" | ∅
| colspan="8" align="center" | dest[15:8]
| colspan="8" align="center" | dest[7:0]
|-
| getMS
| colspan="4" align="center" | ∅
| msY[0]
| colspan="3" align="center" | msX[2:0]
| colspan="3" align="center" | msR[2:0]
| colspan="3" align="center" | msZ[2:0]
| colspan="2" align="center" | msY[2:1]
| colspan="8" align="center" | ∅
|-
| getPump
| colspan="4" align="center" | ∅
| onOff
| colspan="3" align="center" | ∅
| colspan="8" align="center" | ∅
| colspan="8" align="center" | ∅
|-
| getADC
| colspan="4" align="center" | ∅
| colspan="2" align="center" | ∅
| colspan="2" align="center" | adcLevel[9:8]
| colspan="8" align="center" | adcLevel[7:0]
| colspan="8" align="center" | ∅
|-
| getRelease
| colspan="4" align="center" | ∅
| lockMinX1
| lockMaxX1
| lockMinX2
| lockMaxX2
| lockMinY
| lockMaxY
| colspan="6" align="center" | ∅
| colspan="8" align="center" | ∅
|}

T Shirt d'ambiance connecté

2016-01-21T02:24:06Z

Pletouse : Ajout du sommaire + Présentation

T-Shirt d'ambiance musicale augmentée

=Présentation du projet=
Ce projet de création d'objet connecté part d'une idée toute simple : rendre de la musique visuelle. L'objectif est de créer, pour un utilisateur, un avatar musical reflétant son ambiance sonore du moment.

Visible directement sur son T-shirt par exemple, le projet consiste à animer un visage (smiley) constitué de leds multicolores en fonction du son (à la manière d'un spectroscope). Le son peut être diffusé via un media quelconque (lecteur mp3, téléphone...) possédant une prise jack ou bien par WiFi, puis ressortable vers un casque ou éventuellement une enceinte connectée par exemple.

=Objectifs=
* Acquérir et échantillonner un signal audio (analogique)
* Le traiter en le décomposant selon les fréquences qui le constituent (FFT)
* Commander les matrices de leds NeoPixels en fonction des composantes fréquentielles du son échantillonné

=Solution technique retenue et étude de faisabilité=
==Étude de faisabilité via un Intel Edison==
==Etude de l'utilisation d'un FPGA pour le traitement du son==
==Solution retenue : Arduino !==

Partie Edison
<pre>
#include "mraa/aio.h"
#define GPIO_NUMBER 12
#define GPIO_BASE_OFFSET 2
int init_gpio(mraa_gpio_context* gpios){
int i;
for(i=0; i<GPIO_NUMBER; i++) gpios[i] = NULL;
for(i=0; i<GPIO_NUMBER; i++){
gpios[i] = mraa_gpio_init(GPIO_BASE_OFFSET+i);
if(gpios[i] == NULL){
printf("Unable to get context for pin %d\n", i);
return 1;
}
mraa_gpio_dir(gpios[i], MRAA_GPIO_OUT);
}
return 0;
}
int main(){
uint8_t ret;
uint16_t adc_value = 0;
mraa_aio_context adc_a0 = NULL;
mraa_gpio_context gpio[GPIO_NUMBER];
mraa_init();
adc_a0 = mraa_aio_init(0);
mraa_aio_set_bit(adc_a0, 12); // 12 bits resolution
ret = init_gpio(gpio);
if (adc_a0 == NULL){
printf("Unable to initialize ADC\n");
return 1;
}
if(ret != 0){
printf("Unable to initialize GPIOs\n");
return 2;
}
for (;;){
adc_value = mraa_aio_read(adc_a0);
fprintf(stdout, "ADC A0 read %X - %d\n", adc_value, adc_value);
mraa_gpio_write(gpio[0x0], ((adc_value & 0x001) == 0x001));
mraa_gpio_write(gpio[0x1], ((adc_value & 0x002) == 0x002));
mraa_gpio_write(gpio[0x2], ((adc_value & 0x004) == 0x004));
mraa_gpio_write(gpio[0x3], ((adc_value & 0x008) == 0x008));
mraa_gpio_write(gpio[0x4], ((adc_value & 0x010) == 0x010));
mraa_gpio_write(gpio[0x5], ((adc_value & 0x020) == 0x020));
mraa_gpio_write(gpio[0x6], ((adc_value & 0x040) == 0x040));
mraa_gpio_write(gpio[0x7], ((adc_value & 0x080) == 0x080));
mraa_gpio_write(gpio[0x8], ((adc_value & 0x100) == 0x100));
mraa_gpio_write(gpio[0x9], ((adc_value & 0x200) == 0x200));
mraa_gpio_write(gpio[0xA], ((adc_value & 0x400) == 0x400));
mraa_gpio_write(gpio[0xB], ((adc_value & 0x800) == 0x800));
}
mraa_aio_close(adc_a0);
return MRAA_SUCCESS;
}
</pre>

... and NOPE

Partie Artix 7
NOPE

Partie Arduino
Ultimate tuto, a preview of the simplicity : [http://www.pobot.org/Traitement-du-son-par-FFT-fast.html?lang=fr Free efficient project here]

([http://wiki.openmusiclabs.com/wiki/ArduinoFFT Démo des mathématiques ici :])

T Shirt d'ambiance connecté

2016-01-19T16:38:46Z

Pletouse :

== Partie Edison ==
<pre>
#include "mraa/aio.h"
#define GPIO_NUMBER 12
#define GPIO_BASE_OFFSET 2
int init_gpio(mraa_gpio_context* gpios){
int i;
for(i=0; i<GPIO_NUMBER; i++) gpios[i] = NULL;
for(i=0; i<GPIO_NUMBER; i++){
gpios[i] = mraa_gpio_init(GPIO_BASE_OFFSET+i);
if(gpios[i] == NULL){
printf("Unable to get context for pin %d\n", i);
return 1;
}
mraa_gpio_dir(gpios[i], MRAA_GPIO_OUT);
}
return 0;
}
int main(){
uint8_t ret;
uint16_t adc_value = 0;
mraa_aio_context adc_a0 = NULL;
mraa_gpio_context gpio[GPIO_NUMBER];
mraa_init();
adc_a0 = mraa_aio_init(0);
mraa_aio_set_bit(adc_a0, 12); // 12 bits resolution
ret = init_gpio(gpio);
if (adc_a0 == NULL){
printf("Unable to initialize ADC\n");
return 1;
}
if(ret != 0){
printf("Unable to initialize GPIOs\n");
return 2;
}
for (;;){
adc_value = mraa_aio_read(adc_a0);
fprintf(stdout, "ADC A0 read %X - %d\n", adc_value, adc_value);
mraa_gpio_write(gpio[0x0], ((adc_value & 0x001) == 0x001));
mraa_gpio_write(gpio[0x1], ((adc_value & 0x002) == 0x002));
mraa_gpio_write(gpio[0x2], ((adc_value & 0x004) == 0x004));
mraa_gpio_write(gpio[0x3], ((adc_value & 0x008) == 0x008));
mraa_gpio_write(gpio[0x4], ((adc_value & 0x010) == 0x010));
mraa_gpio_write(gpio[0x5], ((adc_value & 0x020) == 0x020));
mraa_gpio_write(gpio[0x6], ((adc_value & 0x040) == 0x040));
mraa_gpio_write(gpio[0x7], ((adc_value & 0x080) == 0x080));
mraa_gpio_write(gpio[0x8], ((adc_value & 0x100) == 0x100));
mraa_gpio_write(gpio[0x9], ((adc_value & 0x200) == 0x200));
mraa_gpio_write(gpio[0xA], ((adc_value & 0x400) == 0x400));
mraa_gpio_write(gpio[0xB], ((adc_value & 0x800) == 0x800));
}
mraa_aio_close(adc_a0);
return MRAA_SUCCESS;
}
</pre>

... and NOPE

== Partie Artix 7 ==
NOPE

== Partie Arduino ==
Ultimate tuto, a preview of the simplicity : [http://www.pobot.org/Traitement-du-son-par-FFT-fast.html?lang=fr Free efficient project here]

([http://wiki.openmusiclabs.com/wiki/ArduinoFFT Démo des mathématiques ici :])

T Shirt d'ambiance connecté

2016-01-19T16:35:45Z

Pletouse : Abandon de l'Intel Edison, utilisation d'une solution Arduino

Automatic Soldering System Project

2015-12-14T22:27:12Z

Pletouse : /* Création de l'outil de manipulation par aspiration */ Rédaction de la description

Automatic Soldering System Project

2015-12-14T20:17:48Z

Pletouse : /* Placeur de composants sur PCB */ Ajout et corrections mineures

Automatic Soldering System Project

2015-12-14T00:45:28Z

Pletouse : /* Placeur de composants sur PCB */ Ajout Catégorie Motorisation + Ajout Catégorie Outil manip aspiration + Modifications et corrections générales

Fichier:Assp schema bipolar stepper 4.png

2015-12-14T00:39:19Z

Pletouse :

Fichier:Assp schema bipolar stepper 2.jpg

2015-12-14T00:31:26Z

Pletouse :

Fichier:Assp schema bipolar stepper.jpg

2015-12-14T00:12:41Z

Pletouse : Projet P20 IMA5 2015/2016 Schema wiring d'un moteur stepper bipolaire

Projet P20 IMA5 2015/2016
Schema wiring d'un moteur stepper bipolaire

Fichier:Assp driver pololu pinout.png

2015-12-14T00:09:40Z

Pletouse : Projet P20 IMA5 2015/2016 Schéma pinout du driver moteur Pas à Pas Pololu

Projet P20 IMA5 2015/2016
Schéma pinout du driver moteur Pas à Pas Pololu

Automatic Soldering System Project

2015-10-14T15:19:16Z

Pletouse : /* Liste de matériel */ Mise à jour de la liste

Automatic Soldering System Project

2015-10-14T14:51:43Z

Pletouse : Ajout Ebauche de planning prévisionnel

Automatic Soldering System Project

2015-10-08T14:18:28Z

Pletouse : Corrections mineures et mises en forme

Automatic Soldering System Project

2015-10-08T14:15:46Z

Pletouse : Ajout Matériel à commander

Automatic Soldering System Project

2015-10-08T14:07:18Z

Pletouse : Ajout ébauche Cahier des charges + Liste des tâches

Automatic Soldering System Project

2015-10-06T13:56:53Z

Pletouse : Ajout plan wiki - Présentation du projet

Thetweekproject

2015-05-10T21:33:32Z

Pletouse : /* Machine à café */ Corrections générales, compétion des éléments restants et ajout du lien de la vidéo de présentation

=Machine à café=
==Présentation du projet==
===Cahier des charges===
SA
* Broyage des grains déjà torréfiés
** Régulation d’un moteur en vitesse avec charge variable
** Réutilisation des éléments d’une cafetière existante (carte électronique hors d’usage)
*** Étalonnage du débitmètre
*** Analyse du chauffe-eau
*** Calibration de la pompe à eau
** Propulsion de l’eau chauffée
*** Régulation d’une pompe à eau en pression et en débit
*** Régulation du chauffe-eau en température
** Modélisation des éléments du système
SC
* Création d’une interface homme-machine
** Installation d’un RaspberryPi avec un écran tactile
*** Gestion des stocks de café, d’eau et de gobelets
*** Gestion des différents éléments (pompe, compresseur, chauffe eau, …)
** Réalisation d’une interface graphique permettant de :
* Moudre le café
* Sélectionner la quantité d’eau à distribuer (café court ou long)
* Sélectionner un café parmi une présélection de café
** Création d’une application Web et Smartphone
*** Possibilité de noter son café
*** Possibilité de retenir un choix de café particulier
* Création de profils créés à partir de la carte étudiante
** Lecture d’information en NFC sur la carte étudiante
** Création d’une base de données basée sur ces profils
*** Proposition des cafés à partir de ceux les plus commandés et/ou mieux notés
*** Possibilité de retenir certains choix et de les recommander

Commun
* Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
* Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)

===Liste des tâches===
*Caractériser le débitmètre
*Caractériser le chauffe-eau
*Caractériser la pompe
*Détermination du schéma de fonctionnement et éventuels correctifs de régulation
*Réalisation de la carte électronique de commande
*Programmation de l'Arduino pour commander la carte
*Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
**Estimation temps de réponse (temps de transfert à l'Arduino négligeable ?)
*Gestion automatique du café
**Dimensionnement capsule et du dispositif de broyage
**Création d'un système dispenseur de gobelets
***Design d'engrenages pour les gobelets
*Plus de fonctionnalités si temps restant
**Recharge par le Net
**Poison pour diabétique
**Interface beaucoup travaillée
**Packaging pratique

===Matériel disponible===

*Machine à café Nespresso défectueuse en morceaux [fournie en 2014]
**Un débitmètre
**Une pompe à eau
**Un chauffe-eau
**Tubes
**Carte électronique (très sûrement défectueuse)
**Mécanisme d'infusion de capsules de café
**Réservoir d'eau avec valve anti-retour

*Matériel électro-informatique
**Arduino Uno [fourni le 26/1/2015]
**Arduino Léonardo [fourni le 5/2/2015]
**RaspberryPi [http://www.adafruit.com/products/998] [fourni le 28/1/2015]
**Carte SD 16G [fournie le 29/1/2015]
**Capteur de température [http://fr.rs-online.com/web/p/capteurs-de-temperature-et-humidite/0264147/] [fourni le 4/2/2015]
**Thermocouple [http://fr.rs-online.com/web/p/thermocouples/6212287/] [fourni le 4/2/2015]
**Lecteur NFC [http://www.adafruit.com/product/364] [fourni le 4/2/2015]
**Ecran tactile [http://www.gotronic.fr/art-afficheur-tactile-usb-2-8-dfr0275-21547.htm] [fourni le 18/03/2015]

*Matériel électronique de puissance
**Contacteurs de puissance (max 32A, 400V) (x2)
**Coffrets d'isolation électrique (x2) (achetés le 09/02/2015)
**Cables électriques (section 2,5 mm2) (achetés le 09/02/2015)
**Boitier interrupteur (achetés le 09/02/2015)

===Matériel manquant===

*Broyeur de café [http://www.maxicoffee.com/moulin-cafe-inoxnoir-gvx2-krups-p-9323-3_68.html?osCsid=e4t6v05n7lctvtod3ehggr0g05]

===Répartition du travail===
{| class="wikitable alternance centre"
|+ Titre
|-
|
! scope="col" | Lundi 14-16h
! scope="col" | Mercredi 14-18h
! scope="col" | Jeudi 10-12h
|-
! scope="row" | Semaine 5
| 26/01 - Organisation et répartition du projet
| 28/01 - Caractériser le débitmètre et gérer les pièces manquantes
| 29/01 - Caractériser le chauffe eau et la pompe
|-
! scope="row" | Semaine 6
| 02/02 - Détermination du schéma de fonctionnement et du plan de régulation
| 04/02 - Réalisation de la carte électronique
| 05/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 7
| 09/02 - Réalisation de la carte électronique
| 11/02 - Réalisation de la carte électronique
| 12/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 8
| 16/02 - Gestion automatique du café
| 18/02 - Gestion automatique du café
| 19/02 - Gestion automatique du café
|-
! scope="row" | Semaine 9
| 23/02 - Gestion automatique du café
| 25/02 - Gestion automatique du café
| 26/02 - Gestion automatique du café
|-
! scope="row" | Semaine 11
| 09/03 - Gestion automatique du café
| 11/03 - Gestion automatique du café
| 12/03 - Gestion automatique du café
|-
! scope="row" | Semaine 12
| 16/03 - Gestion automatique du café
| 18/03 - Gestion automatique du café
| 19/03 - Gestion automatique du café
|-
! scope="row" | Semaine 13
| 23/03 - Gestion automatique du café
| 25/03 - Gestion automatique du café
| 26/03 - Gestion automatique du café
|-
! scope="row" | Semaine 14
| 30/03 - Gestion automatique du café
| 01/04 - Gestion automatique du café
| 02/04 - Gestion automatique du café
|-
! scope="row" | Semaine 15
| Férié
| 08/04 - Gestion automatique du café
| 09/04 - Gestion automatique du café
|-
! scope="row" | Semaine 16
| 13/04 - Gestion automatique du café
| 15/04 - Gestion automatique du café
| 16/04 - Gestion automatique du café
|-
! scope="row" | Semaine 17
| 20/04 - Gestion automatique du café
| 22/04 - Gestion automatique du café
| 23/04 - Gestion automatique du café
|}

En somme, les prévisions pour les différentes parties sont de:
*8 H pour la prise en main du matériel actuel
*14 H pour la réalisation de la carte électronique de commande
*70 H pour la gestion automatique du café

==Etude préalable==
===Caractérisation du débitmètre===
Lors de la première séance "pratique", nous avons étudié le comportement du débitmètre.

Après recherches, nous avons appris qu'il en existe deux types. Le premier type est assimilable à une résistance variable dont la valeur dépend du débit. Le deuxième type se comporte comme un type tout ou rien qui effectue un contact entre deux des pins lorsque l'ailette interne fait un tour. Le débit est donc déduit par la fréquence des impulsions que délivre le débitmètre.

Notre débitmètre est un composant crée par Digmesa, dont la fiche constructeur est disponible [http://www.pollin.de/shop/downloads/D180051D.PDF ici]. Il s'agit d'un débitmètre à turbine, du deuxième type.

Le montage à droite permet de récupérer les impulsions du débitmètre sous forme TTL.

[[Fichier:Schéma_Montage_Débitmètre.JPG|250px|thumb|right|Schéma du montage permettant de récupérer les impulsions du débitmètre]]

Le volume d'eau mesuré s'exprime alors sous cette forme : <math>V = n * \frac{1}{Kdeb}</math> avec n le nombre d'impulsions, V le volume en L et Kdeb la constante fournie dans la doc constructeur Kdeb = 1925 impulsions/L.

Le débit n'est pas une grandeur mesurée directement avec notre débitmètre, mais elle est déduite en choisissant un temps <math>\Delta t</math> suffisamment court pour considérer le débit "instantané".
L'expression du débit "pseudo-instantané" est alors la suivante : <math>\frac{\Delta V}{\Delta t} = \frac{1}{Kdeb} * \frac{\Delta n}{\Delta t} </math> avec <math>\Delta n</math> la variation du nombre d'impulsion pendant le <math>\Delta t</math>.

Obtenir le débit est ici utile car, d'après les informations collectées, le temps d'extraction du café doit être contrôlé (entre 20s à 25s) et le café doit être de 5cl pour un ristretto et de 12cl pour un lungo.

Il est important de noter aussi que ce capteur a une influence sur la pression : en effet, il peut induire une perte de pression (au maximum) de 0,43 bar.

===Réalisation interface commande - puissance===
Afin de pouvoir séparer circuit de commande et alimentation de puissance, nous utiliserons un optocoupleur et des contacteurs pour l'alimentation de la pompe et du chauffe-eau (tout deux alimentés en 230V alternatif 50 Hz). L'optocoupleur est utilisé afin de bénéficier d'une isolation galvanique entre les deux parties, pour plus de sécurité.

La commande d'alimentation est envoyée par l'Arduino à l'optocoupleur. L'optocoupleur commande alors le contacteur (relais de puissance), ce qui alimente l'élément choisi.

L'optocoupleur utilisé est sous forme de circuit "prêt à utiliser" (ET-OPTO AC-OUT 4 dont la fiche constructeur est disponible [http://www.tellab.it/open2b/var/catalog/product/files/57.pdf ici]) qui dispose de quatre optocoupleurs isolés. Nous en utiliserons un pour commander la pompe (OCT0) et un deuxième pour commander le chauffe-eau (OCT1). L'objectif d'une des séances a été d'établir ce dispositif d'alimentation, de comprendre le fonctionnement de l'optocoupleur dont nous disposons et de mapper les optocoupleurs aux sorties de l'Arduino.

Par la suite, nous avons été contraint de changer de type de commande. En effet, la carte d'octocoupleurs permettait la commande mais n'était pas capable de couper le contacteur. Cela est du au principe même du fonctionnement du contacteur. En effet,le contacteur est composé d'une bobine (entre A1 et A2) qui vient attirer un bloc aimanté de façon à créer un contact entre les six broches de puissance (connecteurs 1 à 6). Le problème était que cette bobine demandait un courant trop important que l'octocoupleur gérait mal en rendant impossible la coupure de la bobine.

Pour palier à ce problème, nous avons choisi d'utiliser une carte de commande d'octocoupleurs commandant des relais (ET-OPTO RELAY4, dont la fiche constructeur est disponible [http://www.micro4you.com/files/ETT/ET-OPTO-RELAY4.pdf ici]). Après vérification à l'aide de la documentation technique des relais, nous avons constaté que ceux-ci sont bien capable de couper la commande des contacteurs.

===Fabrication d'un Shield Arduino===
Nous avons donc été amené à créer un shield Arduino avec une carte de prototypage rapide qui réalise les fonctions suivantes :

* intégrer un connecteur 10 broches compatible pour :
** relier la sortie digitale IO 2 à l'optocoupleur OCT0 qui commandera l'alimentation de la Pompe
** relier la sortie digitale IO 3 à l'optocoupleur OCT1 qui commandera l'alimentation du Chauffe eau
* intégrer le circuit de récupération des impulsions du débitmètre TTL et échantillonner ce signal sur l'entrée digitale IO8
* disposer d'une fonction "Boutons Arrêt d'urgence/Commande manuelle" pour la pompe et le chauffe eau.

===Caractérisation de la pompe===
La pompe récupérée est un composant fabriqué par Invensys, dont la fiche constructeur est disponible à [http://www.toolbox.robertshaw.com/appliance/linkedElements/WaterPumps.pdf cette adresse].
Il s'agit d'une pompe à piston qui permet de délivrer une pression allant jusqu'à 19 bar au maximum. Cette pression est fonction du débit en sortie de la pompe, selon la caractéristique à droite.
[[Fichier:Caractéristique_Pompe_Invensys_CP4.JPG‎|250px|thumb|right|Caractéristique Pression/Débit de la pompe]]

Elle se commande en "tout ou rien" et est alimentée en 230 V alternatif 50Hz.
Le paramètre permettant de fixer le point de fonctionnement sur le graphique précédent est la section du tuyau en sortie. Nous n'avons pas la main sur ce paramètre étant donné que nous possédons déjà le système de tuyaux avec les embouts adaptés de section S = 3 mm². En revanche, nous la commanderons en décidant du temps d'allumage.
Il s'agit maintenant de déterminer à quels moments et combien de temps il faut alimenter la pompe, sachant qu'il faut que l'extraction dure entre 20s et 25s et que le chauffe eau induit un retard à déterminer.

'''Séance pratique :'''

Lors d'une séance de manipulation de la pompe, nous l'avons commandé au moyen de l'Arduino pendant plusieurs durées pré-établies (2s, 5s et 10s) afin de déterminer si elle possède un régime transitoire négligeable. Nous avons ensuite relevé le volume d'eau qu'elle avait délivré grâce à une éprouvette graduée. Plusieurs séries de mesures ont été effectuées à chaque fois.
Lors de cette manip, le tuyau de sortie n'était pas connecté au chauffe-eau afin que la mesure ne soit pas influencée, il donnait directement dans l'éprouvette. Cette manipulation nous a également permis de tester notre débitmètre et notre manière d'échantillonner le signal qu'il nous fournit, en comparant le volume déduit par celui ci et le volume réel relevé avec l'éprouvette.

Ainsi, nous avons déterminé que quelque soit le temps d'allumage (pour une durée supérieure à 2s), la pompe fournit un débit constant de 5,2 mL/s = 0,312 cc/min.

===Étalonnage du capteur de température du chauffe-eau===
Afin de réguler le chauffe eau en température, nous avons besoin de connaître le fonctionnement du capteur de température intégré sur celui ci.
Il s'agit en fait d'une thermistance (résistance variable dont la valeur de la résistance dépend de la température), ici à coefficient de température négatif (CTN).

Il n'y a visiblement pas de référence constructeur dessus. Nous avons donc décidé d'effectuer un étalonnage de celle ci. Il existe un dispositif en salle électronique comportant des capteurs de températures déjà étalonnés disposés sur une plaque qui peut être chauffée par un chauffage électrique. Nous avons "collé" avec de la pâte thermique notre thermistance sur cette plaque et effectué un relevé de la résistance en fonction de la température indiquée par les capteurs déjà présents. Le problème est que le chauffage ne pouvait pas être régulé, il continue de chauffer tant qu'on l'alimente. N'ayant donc pas de valeur de température stabilisée, à cause de l'inertie thermique, les valeurs de résistances relevées sont complètement non significatives.
Cette manipulation aura tout de même soulevé un point à prendre en compte : le capteur de température étant en métal, il faudra déterminer l'inertie qu'il induit dans la mesure et si celle ci est négligeable, sinon, comment faire avec.

Le soucis pour une approximation linéaire est que la plage de température est trop importante. En effet, la température de l'eau pour le café doit être entre 88°C et 90°C, mais on doit aussi pouvoir utiliser le capteur à une température de 65°C pour prévoir un mode "économie d'énergie", lorsque la machine n'est pas utilisée pendant 10min par exemple.
Après recherches, la loi d'évolution de la résistance en fonction de la température est de la forme : <math>{1 \over {T}} = A + B \ln(R_{Th}) + C (\ln(R_{Th}))^3 \,</math>

Autre idée : simplement l'étalonner la thermistance au moyen d'un bain d'eau que l'on peut chauffer et d'une sonde de température précise.

Après relevé de l'évolution de la résistance en fonction de la température au moyen du bain marie, nous avons constaté et vérifié que notre sonde de température se comporte comme une sonde standardisée PT100. Nous avons trouvé une fiche constructeur de ces sondes standardisées qui vérifie les caractéristiques de notre capteur ([http://search.murata.co.jp/Ceramy/CatalogAction.do?sHinnm=?&nbsp&sNHinnm=NCP15WF104D03RC&sNhin_key=NCP15WF104D03RC&sLang=en&sParam=series+U0120L0770S0416A1161 lien]). Sur la plage de température que nous avons besoin d'utiliser (25°C - 105°C), nous pouvons négliger le terme en ln^3, ainsi l'équation régissant la résistance en fonction de la température peut s'exprimer ainsi :
<math>{R_{Th}}={R_0} \times\exp\left(\beta\times\left({1 \over {T}} - {1 \over {T_0}}\right)\right) \,</math> avec <math>{R_0}</math> = 100 kOhm la résistance de référence à <math>T_0</math>= 25°C, <math>\beta</math> = 4334 Kelvin le coefficient fourni par le constructeur pour l'approximation sur la plage 25°C-100°C.

Ainsi, la représentation des données pour récupérer la température est la suivante : au moyen d'un pont diviseur, nous récupérons une tension sur l'Arduino image de la résistance et donc de la température avec la relation ci-dessus.
Nous ne pouvons pas inclure dans le code directement un calcul avec la fonction exponentielle, cela prendrait , entre autres, trop de temps de calcul et ne serait pas optimisé étant donné que l'on connait la résolution du CAN de l'Arduino. Pour cela, nous passons par un tableau de conversion sur 256 valeurs calculé au moyen de cette [https://docs.google.com/spreadsheets/d/185WP8sv1Ryd4hWDlqnpToG-fiC0yVxaIgjR2ey1FG68/edit?usp=sharing feuille de calcul]. Voici un schéma de principe :

Coté Arduino : Tension aux bornes de Rth(V) ---CAN---> Valeur sur 10 bits ---TableauDeConversion---> Valeur sur 8 bits

La Raspberry (ou le PC) récupère ensuite cette valeur sur 8 bits et en déduit la température avec la connaissance du "pas" entre 2 températures : <math>Pas = {(105-25)\over 255}</math>

Coté Raspberry : Valeur sur 8 bits ---> 25 + (Valeur * Pas) ---> Température en °C

Cette méthode permet d'alléger le temps de traitement sur l'Arduino et surtout de ne pas perdre en précision et résolution à cause de la transmission de l'information "température", qui s'effectue sur 8 bits.

===Caractérisation du chauffe eau===
Le chauffe eau que nous avons récupéré est de type thermoblock. Il s'agit en fait d'une résistance chauffante autour de laquelle se situe un serpentin dans lequel l'eau circule, le tout étant isolé dans un châssis en métal.
Les principaux avantages de ce système thermoblock est qu'il conserve très bien la chaleur et qu'il permet de ne chauffer que la quantité d'eau nécessaire, la petite quantité qui passe à l'intérieur. On peut alors considérer l'échange thermique entre le chauffage et l'eau quasi instantané et uniforme. L'inconvénient majeur est en revanche, comme pour tout système thermique, l'inertie thermique importante qu'il possède, notamment due à son corps en métal.

Nous n'avons pas trouvé de données constructeur sur ce chauffe eau. La seule information inscrite est la puissance électrique qu'il absorbe : 1200 W.
Il sera alimenté, comme pour la pompe, en 230V alternatif 50Hz, en tout ou rien. Il s'agit maintenant d'estimer ses caractéristiques (inertie, temps caractéristiques, gains en température en fonction de l'entrée) afin de mettre en place un plan de régulation adapté. Ne possédant aucune information sur ce système, nous ne procéderons pas à une étude théorique thermique qui serait trop approximative compte tenu de la géométrie du système et trop fastidieuse à mettre en place. Nous avons choisi de procéder par identification, en relevant les courbes d'évolution de la température, pour différents temps de commande.

'''Résultats :'''

A chaque fois, la réponse peut s'exprimer de la façon suivante : on constate un temps de retard pur au démarrage dû à l'inertie, puis une évolution s’apparentant à celle d'une réponse à système du 1er ordre. On peut écrire la fonction de transfert du système sous cette forme : <math>H(P) = \frac{K}{1+\tau P} e^{- T_{r} P}</math> (modèle de Broïda)

[[Fichier:Commande_2s.png|350px|vignette|right|upright=1.25|Réponse en température pour 2s d'alimentation]]

[[Fichier:Commande_5s.png|350px|vignette|left|upright=1.25|Réponse en température pour 5s d'alimentation]]

[[Fichier:Commande_10s+pompe.png|350px|vignette|centre|upright=1.25|Réponse en température pour 10s d'alimentation, puis arrivée d'eau à t=75s]]

Remarque : On peut observer sur le 2ème graph l'influence du passage de l'eau dans le thermoblock sur la température. Celui ci se traduit comme une perturbation avec un comportement type 1er ordre sur le thermoblock. Avec ces paramètres (temps, gain), on pourra par la suite estimer la compensation à ajouter afin de maintenir la température du thermoblock constante malgré la chauffe de l'eau.

Ainsi, on peut récapituler ceci dans le tableau suivant :

{| class="wikitable"
|-
! Temps de commande
! Gain en température K
! Temps de retard Tr
! Temps de réponse à 5%
|-
| 2 s
| 4,3 °C
| 5,2 s
| 14 s
|-
| 5 s
| 12 °C
| 5,2 s
| 25 s
|-
| 10 s
| 24 °C
| 5,2 s
| 37 s
|-
|}

On remarque un gain en température en fonction du temps d'allumage quasi constant dans ces intervalles d'environ 2,4°C par seconde, ainsi que le temps de retard est bien constant.

===Détermination du plan de régulation===
Rappelons le cahier des charges de la régulation :

* chauffer l'eau à 90°C, avec comme erreur acceptable +/- 2°C (conformément aux informations recueillies)
* pas de dépassement de la consigne : en effet, le système conservant très bien la chaleur, attendre qu'il se refroidisse serait trop long et surtout, si il y a dépassement après 100°C, on crée un générateur de vapeur... ce qui est bien sûr très dangereux pour le système et pour la sécurité de l'utilisateur
* avoir un temps de réponse acceptable pour l'utilisateur (actuellement, à titre d'exemple, pour la cafetière Nespresso, l'étape de chauffe n'excède en général pas 60s)
* mode économie d'énergie : la machine est destinée à être utilisée publiquement, par des utilisations ponctuelles et pas uniformément réparties dans le temps, il est donc important que la machine ne gaspille pas de l'énergie lorsqu'elle n'est pas utilisée. Ainsi, le bon compromis serait que la température soit maintenue à environ 50°C après 10min d'inutilisation.

'''Choix de la régulation :'''

[[Fichier:Grafcet_AutoHeat.JPG‎|400px|thumb|right|Grafcet illustrant le principe de l'algorithme de régulation de la température]]
Ici ne possèdant pas de commande réglable, nous ne pouvons pas choisir une régulation continue de type PID ou prédicteur de Smith, car on commande le thermoblock via un relais. Une commande MLI n'est pas envisageable dans notre cas, à cause du faible "pouvoir de commutation" des contacteurs de puissance que nous avons récupéré. Une simple régulation Tout ou Rien type thermostat ne serait pas suffisante, car ceci engendrerait des dépassements et des oscillations fortes autour de la température de consigne compte tenu du rapport Temps caractéristique sur Temps de retard du système <math>\frac{\tau}{T_{r}} \approx 1,66</math>. Nous nous situons donc dans le cas "Régulation par Boucles multiples" d'après la méthode de Broïda.

Dans notre cas d'utilisation, un algorithme par boucles multiples, basé sur des commandes Tout ou Rien, est possible et peut satisfaire au cahier des charges. En effet, la consigne ne change pas d'ordre de grandeur : il faudra toujours chauffer l'eau dans un intervalle compris entre 88°C et 92°C. On propose alors l'algorithme suivant :

Principe :
* 1) Chauffe Initiale : Au début de la phase de chauffe, on réalise une chauffe importante (15 s), l'objectif étant d'approcher grossièrement la température auprès de la température de consigne et qu'elle se soit stabilisée (attente de 12s) avant de passer à l'étape de chauffe par palier.
* 2) Chauffe par palier : Il s'agit ici d'effectuer ensuite une succession de "petites" chauffes jusqu'à être dans la plage de température acceptable, tout en tenant compte de l'inertie thermique. Ces successions de chauffe sont définies ici par 2s de chauffe, puis 6s d'attente de l'établissement de la température avant de déterminer si on reste dans la phase Chauffe par palier ou si on entre dans la phase Maintien au chaud. La température de seuil a été déterminée à 82°C, pour prendre en compte le phénomène d'inertie.
* 3) Maintien au chaud : On se situe alors proche ou dans la plage de température. Il s'agit alors d'effectuer des petites chauffes ponctuelles permettant de maintenir la température dans l'intervalle (refroidissement par le milieu ambiant). Cette étape prend également en compte le maintien au chaud lorsque de l'eau passe à travers le chauffe eau et fait donc chuter sa température (compensation plus forte : cycle de 3s de chauffe puis 3s d'attente). On peut, à partir de cette étape, commander la pompe pour élaborer un café si un café a été demandé.

Un avantage de la chauffe palier par palier permet d'attendre que la chaleur s'établisse uniformément dans le thermoblock. Ceci permet de limiter les problèmes d'inerties thermiques, y compris celui de notre capteur (sans mettre ces paliers d'attente, ce que l'on observerait en température ne serait pas nécessairement la température au coeur du thermoblock).

[[Fichier:Mode_Auto.png|400px|vignette|right|upright=1|Evolution de la température du chauffe eau avec la régulation]]

'''Résultats de la régulation'''

On constate sur le graphique à droite les 3 étapes de chauffe : les étapes 1 et 2 s'effectuant ici entre 0s et environ 80s puis l'étape de maintien après cette date. La température évolue ainsi de façon presque linéaire pendant les étapes 1 et 2, puis reste dans la plage 88°C-92°C.
A t=140s, la pompe est commandée dans cette exemple afin de pouvoir visualiser le maintien en température lorsque l'eau circule.

On remarque donc que cette régulation valide les 2 premiers critères du cahier des charges (chauffer l'eau dans la plage et pas de dépassement de cette plage). Cependant, le temps de réponse avant de pouvoir élaborer un café est un peu plus long (environ 80s).

==Déroulement du projet==
===Avancement des différents objectifs===
Les différents objectifs et leur avancement sont résumés dans le tableau suivant
{| class="wikitable"
|-
! Objectif
! Etat
! Commentaire
|-
! Étalonnage du débitmètre
| Fini
| La documentation est fournie dans le Wiki, et le shield Arduino permet son utilisation
|-
! Analyse du chauffe-eau
| Fini
| Le chauffe-eau est maintenant caractérisé. Le retard dans la commande ainsi que la commande tout ou rien complexifie grandement son utilisation mais une solution a été trouvée et fonctionne parfaitement, comme indiqué dans le wiki.
|-
! Calibration de la pompe à eau
| Fini
| La documentation est aussi fournie dans le wiki, et le shield Arduino permet son utilisation en temps réel.
|-
! Régulation du chauffe-eau en température
| Fini
| Le modèle équivalent a été déterminé, comme indiqué dans le wiki, et les tests semblent confirmer le bon fonctionnement. Les derniers tests complémentaires ont prouvés que la régulation s'effectue correctement même lors d'un pompage.
|-
! Régulation d’une pompe à eau en pression et en débit
| Fini
| Le comportement de la pompe a été caractérisé et l'utilisation des nouvelles pièces créées au Fabricarium n'engendre pas de perturbations trop importantes.
|-
! Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
| Fini
| L'utilisation d'une carte de puissance couplée avec deux contacteurs et un shield arduino réalisé par nos soins rempli parfaitement cet objectif
|-
! Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)
| Fini
| Le shield Arduino que nous avons réalisé permet aussi de lire les différents capteurs
|-
! Programmation de l'Arduino pour commander la carte
| Fini
| Pour finir il est nécessaire d'utiliser deux Arduinos mais tout les deux sont programmés
|-
! Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
| Fini
| La partie NFC est réalisée par un des deux Arduinos, l'interface tactile est encore en cours de réalisation. Bonne nouvelle ! Les tests ont montrés que le temps de réponse entre les Arduinos et le RaspberryPi sont négligeables devant le temps d’échantillonnage. L'écran fonctionne parfaitement et permet de sélectionner la quantité de café désirée.
|-
! Dimensionnement capsule et du dispositif de broyage
| Fini à 80 %
| Les capsules et la chambre de la capsule ont été complètement étudiés. Un système complet à été créé pour ne plus être contraint à l'utilisation du système propriétaire. Trois pièces ont été créé à l'aide du logiciel de CAO Catia. La création de ces pièces en métal est pour le moment impossible (Notre contact aux Arts&Métiers est indisponible, peut-être le responsable des machines-outils de la section mécanique peut nous aider à réaliser certaines pièces). Nous nous sommes rabattus sur la création des pièces en PLA à l'aide de l'imprimante 3D WitBox du fabricarium. Les trois pièces principales sont terminées, ce qui pourrait permettre d'en faire un démonstration. La pièce de liaison est fonctionnelle, ce qui nous permet d'adapter notre tuyau de pompe aux trois pièces précédentes. Par manque de temps, il ne sera pas possible de montrer le fonctionnement automatique des pièces.
|-
! Création d'un système dispenseur de gobelets
| Fini à 0%
| Le système ne sera pas créé par manque de temps.
|}

===La programmation des différents éléments===
Pour la partie programmation, le défi résidait dans le fait de faire communiquer tout les éléments à l'aide d'un seul programme. Pour cela, nous avons subdivisé les fonctions principales dans différents modules. Ceci nous permettait entre autre de minimiser le nombre d'éléments reliés à la partie "puissance" du projet (détaillé plus loin)

Le code source du projet est disponible sur [http://www.github.com GitHub], et les liens vers les différents programmes sont les suivants
{| class="wikitable"
|-
!
! Lien
|-
! Shiled Arduino NFC
| [https://github.com/henyxia/tweekd_nfc]
|-
! Shield Arduino de puissance
| [https://github.com/henyxia/tweekd_hvc]
|-
! Interface en ligne de commande
| [https://github.com/henyxia/tweekd]
|}
====Le Shield Arduino NFC====
L'objectif de l'utilisation du Shield NFC est de permettre à un utilisateur de payer un café, et donc de s'identifier sur la machine, à l'aide de carte Lille 1. Pour cela, nous nous sommes premièrement orientés sur l'utilisation de l'IDE Arduino et de la librairie dédiée au [https://github.com/Seeed-Studio/PN532 PN532]. Puis, nous avons décidé de passer à un langage C pour avoir une meilleure visibilité sur les registres. Par conséquent, nous avons utilisé le compilateur avr-g++ pour compiler le projet. Il nous a donc était nécessaire de transposer une partie des fichiers C et C++ pour les rendre utilisables avec notre programme C.

La communication se fait par système de questions-réponses. Le serveur sur la Raspberry envoie une demande de données, et l'Arduino répond en conséquence. La seule difficulté a résidé dans la problématique des données à envoyer pour l'identification. Les cartes de Lille 1 sont des cartes NFC Mifare Classic 1K. Elles sont composées de 16 secteurs de 4 fois 16 bytes. Le secteur qui nous intéresse est le douzième secteur, qui est encodé en utilisant les clés NFC publiques (donc accessible par tout le monde). Les clés publiques en question sont :

{| class="wikitable"
|-
!
! Clé
|-
! A
| A0A1A2A3A4A5
|-
! B
| B0B1B2B3B4B5
|}

Ce douzième secteur contient, pour les carte étudiantes, l'INE, suivi du numéro étudiant (sur 8 chiffres), suivi du prénom, suivi d'un point puis du nom. Nous avons d'abord envisagé d'utiliser le nom et le prénom, cependant cela posait le problème des personnes avec le même patronymes. De plus, il arrivait que le nom de l'étudiant soit tronqué pour rester dans l'espace alloué au secteur 12. Par conséquent, nous utilisons le numéro d'étudiant, qui est toujours au même endroit sur le secteur. Le logiciel compare alors ce numéro à une liste d'étudiant.

Par soucis de sécurité, nous n'avons pas de liste donnant une correspondance directe entre un numéro d'étudiant et son nom. En effet, la liste utilisée est un enchaînement de nom et de numéro étudiant encodé avec l'algorithme MD5. Pour récupérer le nom, il nous suffit alors de comparer le numéro étudiant que nous récupérons (que nous encodons en MD5) avec la liste. Ceci nous assure une confidentialité relative, dépendante directement de la robustesse de la non réversibilité du MD5.

Une fois la reconnaissance des cartes étudiantes terminées, nous avons essayé d'inclure les cartes Lille 1 dédiées au personnel. La première question que nous nous sommes posé est comment pouvons nous faire la différence, au niveau du lecteur, entre une carte étudiante et une carte du personnel. Nous avons remarqué que les cartes du personnel comporte, sur leur douzième secteur, deux fois le numéro de personnel (sur 6 chiffres). La répétition du numéro de personnel se situe à l'endroit où se situe le nom de l'étudiant sur la carte de l'étudiant. Le test est donc assez facile à réaliser. L'autre problème est : comment lié un numéro de personnel à un nom ? Nous n'avons pas encore résolu ce problème car cette table de liaison n'est pas accessible à PolytechLille. Éventuellement, si nous arrivons à accomplir tous les objectifs du projet, nous envisagerons de contacter les responsables de Lille 1 pour obtenir cette table de correspondance.

====L'interface en ligne de commande utilisateur====
Durant les phases de test, nous avons créé une interface en ligne de commande. Celle-ci permettait d'envoyer directement des commandes au HVC, comme l'allumage du chauffe-eau pendant un certain nombre de secondes; ou encore le pompage. Cette interface est restée en utilisation jusqu'à deux semaines avant la fin du projet, car elle nous permettait d'effectuer un suivi très simple de l'état des capteurs. Par la suite, à partir du commit [https://github.com/henyxia/tweekd/commit/ac55328a023270dc55e5e5a99c2bc9a3a1873885 ac55328], nous nous sommes orienté vers l'utilisation de l'écran fournis.

Durant la période où nous utilisions l'interface en ligne de commande, nous nous servions de celle-ci car elle nous fournissait des informations comme le PID. Cette information nous permettait de tuer le programme principal ainsi que tous ces fils lorsque celui ci plantait. Il affichait aussi le volume pompé, la dernière température relevée, l'identifiant lu par le lecteur NFC et la date à laquelle cette lecture s'était produite. Elle affichait aussi les dernières entrées du journal, avec des couleurs indiquant leur niveau d'importance (Debug, Info, Warning ou Error).

====L'interface utilisateur finale====
Pour l'interface utilisateur finale, nous nous reposons sur un module d'affichage [http://www.robopeak.com/docs/doku.php?id=product-rpusbdisp RPUSBDisp] de la société RoboPeak. Avant de se lancer dans la phase de programmation de l'interface, il nous a d'abord fallut rendre utilisable l'écran par le RaspberryPi. Pour cela, il a fallut créer un module chargeable par le noyau Linux. Une fois ce module créé, nous nous sommes rendu compte le noyau Linux que nous utilisions (celui fournis avec Raspbian) ne contenait pas les symboles nécessaires au chargement du module. Nous avons alors recompilé le noyau Linux avec les symboles manquants. La compilation s'est avérée assez compliqué car pour éviter de faire de la cross compilation (ce qui aurait surement augmenter le taux d'échec de compilation) nous avons compilé le noyau directement à partir de la RaspberryPi ce qui, malgré son overclooking, était très long (une compilation prenait approximativement une nuit complète). Après quatre tentatives, nous avons réussi à obtenir un noyau fonctionnel.

[[Fichier:RPUSBDisp1.jpg|200px|thumb|right|Premier BMP affiché avec succès sur l'écran]] Une fois l'écran utilisable, nous nous sommes lancés dans le développement de l'interface. Nous avons choisi, dans une optique de performance, de n'utiliser que la librairie X11. Le premier objectif était de réussir à afficher une image sur l'écran. Le format d'image utilisé était le BMP car il n'est pas compressé et peut être lu sans autres calculs. Après de petits cafouillages (liés au fait que le BMP représente une couleur de 0 à 255 et X11 de 0 à 65535) nous avons réussi à faire afficher notre première image. Cependant, le point négatif est que l'image est affichée en une trentaine de secondes. Nous sommes donc en train de travailler sur un moyen de faire afficher des images plus rapidement.

Après de longues recherches, nous nous sommes rendus compte qu'il n'était pas possible de réaliser une interface temps réel avec cet écran si l'on utilisait la librairie X11. En effet, celle ne communique pas assez rapidement avec l'écran (les recordes d'écriture étant de ~17 secondes par images avec X11). Le constructeur préconise en fait une utilisation à travers une interface USB. Cette interface, décrite dans ce [http://www.robopeak.com/data/doc/rpusbdisp/RPUD03-rpusbdisp_interface_protocol-enUS.1.0.pdf manuel] nous oblige à réécrire notre interface homme machine.

[[Fichier:RGB565.gif|320px|thumb|left|Représentation des données en RGB565]] Le [https://github.com/henyxia/tweekd_gui/blob/master/main.c lien suivant] est une démonstration de la première commande que nous avons réussi à envoyer à travers la librairie USB. Nous avons ensuite essayé d'afficher une image sur l'écran. Pour cela, il a été nécessaire de créer un type de fichier intermédiaire car l'écran n'est pas capable de lire la plupart des formats d'images classiques. Pour rendre la conversion plus simple, nous avons choisi le type BMP comme fichier image source. Le type BMP organise la description des images de façon simple. Le fichier commence par un en-tête qui comporte des informations comme l'adresse de début de l'image, le nombre de bits par pixel et d'autres informations qui ne nous servent pas. Une fois ces deux informations récupérés (nous n'utilisons que des images à 24 bits par pixel, soit 8 bits pour le rouge, 8 bits pour le vert et 8 bits pour le bleu) nous convertissons notre image dans le format lisible par l'écran, qui est le RGB565. Ce format compresse (avec pertes) la précision des couleurs pour que celle-ci soit ordonnée avec 5 bits pour le rouge, 6 bits pour le vert et 5 bits pour le bleu. Nous rendre plus pratique cette conversion, nous avons créé un [https://github.com/henyxia/bmp2rgb565 programme] permettant l'automatisation de ce processus. Une fois ce programme utilisé (à travers le Makefile du projet principal), l'image est envoyé à l'écran. Après chronométrage, nous arrivons à un temps moyen de 1,2 secondes pour afficher une image intégralement. Ce temps est bien inférieur aux 17 secondes de la librairie X11, mais est aussi légèrement éloigné des 25 images par secondes promises par le vendeur (Ce taux de rafraîchissement n'étant atteignable que si nous ne générons des carrés de couleurs). Cependant ce temps de réponse est largement suffisant pour l'utilisation que nous souhaitons en faire.

Nous nous sommes donc penché sur l'utilisation de l'interface tactile de l'écran. C'est une lecture USB par interruption qui nous donne si l'écran est actuellement pressé, et si oui où la pression est effectuée. Donc, pour permettre au programme de comprendre quelle fonction appeler lors d'un appui sur l'écran, nous avons créé un autre format de fichier. Celui ci, aussi issu du BMP, est une liste de pixel en nuance de gris. Donc, chaque pixel est représenté par une valeur comprise entre 0 et 255. En fonction de la valeur, le programme principal appelle la fonction en conséquence. De façon analogue à la conversion de BMP et RGB565, nous avons créé un programme permettant de convertir les BMP en suite de bytes correspondant aux pixels. Ce programme ce trouve à [https://github.com/henyxia/bmp2map l'adresse suivante].

==Conclusion==
===Vidéo de présentation===
Nous pensons enregistrer la vidéo pendant les vacances à l'aide d'une caméra professionnelle.

La vidéo du projet est disponible à [https://www.youtube.com/watch?v=GXPjxfLEy3o cette adresse].

Thetweekproject

2015-05-10T20:34:37Z

Pletouse : /* Détermination du plan de régulation */ Recadrage de l'image

=Machine à café=
==Présentation du projet==
===Cahier des charges===
SA
* Broyage des grains déjà torréfiés
** Régulation d’un moteur en vitesse avec charge variable
** Réutilisation des éléments d’une cafetière existante (carte électronique hors d’usage)
*** Étalonnage du débitmètre
*** Analyse du chauffe-eau
*** Calibration de la pompe à eau
** Propulsion de l’eau chauffée
*** Régulation d’une pompe à eau en pression et en débit
*** Régulation du chauffe-eau en température
** Modélisation des éléments du système
SC
* Création d’une interface homme-machine
** Installation d’un RaspberryPi avec un écran tactile
*** Gestion des stocks de café, d’eau et de gobelets
*** Gestion des différents éléments (pompe, compresseur, chauffe eau, …)
** Réalisation d’une interface graphique permettant de :
* Moudre le café
* Sélectionner la quantité d’eau à distribuer (café court ou long)
* Sélectionner un café parmi une présélection de café
** Création d’une application Web et Smartphone
*** Possibilité de noter son café
*** Possibilité de retenir un choix de café particulier
* Création de profils créés à partir de la carte étudiante
** Lecture d’information en NFC sur la carte étudiante
** Création d’une base de données basée sur ces profils
*** Proposition des cafés à partir de ceux les plus commandés et/ou mieux notés
*** Possibilité de retenir certains choix et de les recommander

Commun
* Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
* Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)

===Liste des tâches===
*Caractériser le débitmètre
*Caractériser le chauffe-eau
*Caractériser la pompe
*Détermination du schéma de fonctionnement et éventuels correctifs de régulation
*Réalisation de la carte électronique de commande
*Programmation de l'Arduino pour commander la carte
*Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
**Estimation temps de réponse (temps de transfert à l'Arduino négligeable ?)
*Gestion automatique du café
**Dimensionnement capsule et du dispositif de broyage
**Création d'un système dispenseur de gobelets
***Design d'engrenages pour les gobelets
*Plus de fonctionnalités si temps restant
**Recharge par le Net
**Poison pour diabétique
**Interface beaucoup travaillée
**Packaging pratique

===Matériel disponible===

*Machine à café Nespresso défectueuse en morceaux [fournie en 2014]
**Un débitmètre
**Une pompe à eau
**Un chauffe-eau
**Tubes
**Carte électronique (très sûrement défectueuse)
**Mécanisme d'infusion de capsules de café
**Réservoir d'eau avec valve anti-retour

*Matériel électro-informatique
**Arduino Uno [fourni le 26/1/2015]
**Arduino Léonardo [fourni le 5/2/2015]
**RaspberryPi [http://www.adafruit.com/products/998] [fourni le 28/1/2015]
**Carte SD 16G [fournie le 29/1/2015]
**Capteur de température [http://fr.rs-online.com/web/p/capteurs-de-temperature-et-humidite/0264147/] [fourni le 4/2/2015]
**Thermocouple [http://fr.rs-online.com/web/p/thermocouples/6212287/] [fourni le 4/2/2015]
**Lecteur NFC [http://www.adafruit.com/product/364] [fourni le 4/2/2015]
**Ecran tactile [http://www.gotronic.fr/art-afficheur-tactile-usb-2-8-dfr0275-21547.htm] [fourni le 18/03/2015]

*Matériel électronique de puissance
**Contacteurs de puissance (max 32A, 400V) (x2)
**Coffrets d'isolation électrique (x2) (achetés le 09/02/2015)
**Cables électriques (section 2,5 mm2) (achetés le 09/02/2015)
**Boitier interrupteur (achetés le 09/02/2015)

===Matériel manquant===

*Broyeur de café [http://www.maxicoffee.com/moulin-cafe-inoxnoir-gvx2-krups-p-9323-3_68.html?osCsid=e4t6v05n7lctvtod3ehggr0g05]

===Répartition du travail===
{| class="wikitable alternance centre"
|+ Titre
|-
|
! scope="col" | Lundi 14-16h
! scope="col" | Mercredi 14-18h
! scope="col" | Jeudi 10-12h
|-
! scope="row" | Semaine 5
| 26/01 - Organisation et répartition du projet
| 28/01 - Caractériser le débitmètre et gérer les pièces manquantes
| 29/01 - Caractériser le chauffe eau et la pompe
|-
! scope="row" | Semaine 6
| 02/02 - Détermination du schéma de fonctionnement et du plan de régulation
| 04/02 - Réalisation de la carte électronique
| 05/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 7
| 09/02 - Réalisation de la carte électronique
| 11/02 - Réalisation de la carte électronique
| 12/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 8
| 16/02 - Gestion automatique du café
| 18/02 - Gestion automatique du café
| 19/02 - Gestion automatique du café
|-
! scope="row" | Semaine 9
| 23/02 - Gestion automatique du café
| 25/02 - Gestion automatique du café
| 26/02 - Gestion automatique du café
|-
! scope="row" | Semaine 11
| 09/03 - Gestion automatique du café
| 11/03 - Gestion automatique du café
| 12/03 - Gestion automatique du café
|-
! scope="row" | Semaine 12
| 16/03 - Gestion automatique du café
| 18/03 - Gestion automatique du café
| 19/03 - Gestion automatique du café
|-
! scope="row" | Semaine 13
| 23/03 - Gestion automatique du café
| 25/03 - Gestion automatique du café
| 26/03 - Gestion automatique du café
|-
! scope="row" | Semaine 14
| 30/03 - Gestion automatique du café
| 01/04 - Gestion automatique du café
| 02/04 - Gestion automatique du café
|-
! scope="row" | Semaine 15
| Férié
| 08/04 - Gestion automatique du café
| 09/04 - Gestion automatique du café
|-
! scope="row" | Semaine 16
| 13/04 - Gestion automatique du café
| 15/04 - Gestion automatique du café
| 16/04 - Gestion automatique du café
|-
! scope="row" | Semaine 17
| 20/04 - Gestion automatique du café
| 22/04 - Gestion automatique du café
| 23/04 - Gestion automatique du café
|}

En somme, les prévisions pour les différentes parties sont de:
*8 H pour la prise en main du matériel actuel
*14 H pour la réalisation de la carte électronique de commande
*70 H pour la gestion automatique du café

==Etude préalable==
===Caractérisation du débitmètre===
Lors de la première séance "pratique", nous avons étudié le comportement du débitmètre.

Après recherches, nous avons appris qu'il en existe deux types. Le premier type est assimilable à une résistance variable dont la valeur dépend du débit. Le deuxième type se comporte comme un type tout ou rien qui effectue un contact entre deux des pins lorsque l'ailette interne fait un tour. Le débit est donc déduit par la fréquence des impulsions que délivre le débitmètre.

Notre débitmètre est un composant crée par Digmesa, dont la fiche constructeur est disponible [http://www.pollin.de/shop/downloads/D180051D.PDF ici]. Il s'agit d'un débitmètre à turbine, du deuxième type.

Le montage à droite permet de récupérer les impulsions du débitmètre sous forme TTL.

[[Fichier:Schéma_Montage_Débitmètre.JPG|250px|thumb|right|Schéma du montage permettant de récupérer les impulsions du débitmètre]]

Le volume d'eau mesuré s'exprime alors sous cette forme : <math>V = n * \frac{1}{Kdeb}</math> avec n le nombre d'impulsions, V le volume en L et Kdeb la constante fournie dans la doc constructeur Kdeb = 1925 impulsions/L.

Le débit n'est pas une grandeur mesurée directement avec notre débitmètre, mais elle est déduite en choisissant un temps <math>\Delta t</math> suffisamment court pour considérer le débit "instantané".
L'expression du débit "pseudo-instantané" est alors la suivante : <math>\frac{\Delta V}{\Delta t} = \frac{1}{Kdeb} * \frac{\Delta n}{\Delta t} </math> avec <math>\Delta n</math> la variation du nombre d'impulsion pendant le <math>\Delta t</math>.

Obtenir le débit est ici utile car, d'après les informations collectées, le temps d'extraction du café doit être contrôlé (entre 20s à 25s) et le café doit être de 5cl pour un ristretto et de 12cl pour un lungo.

Il est important de noter aussi que ce capteur a une influence sur la pression : en effet, il peut induire une perte de pression (au maximum) de 0,43 bar.

===Réalisation interface commande - puissance===
Afin de pouvoir séparer circuit de commande et alimentation de puissance, nous utiliserons un optocoupleur et des contacteurs pour l'alimentation de la pompe et du chauffe-eau (tout deux alimentés en 230V alternatif 50 Hz). L'optocoupleur est utilisé afin de bénéficier d'une isolation galvanique entre les deux parties, pour plus de sécurité.

La commande d'alimentation est envoyée par l'Arduino à l'optocoupleur. L'optocoupleur commande alors le contacteur (relais de puissance), ce qui alimente l'élément choisi.

L'optocoupleur utilisé est sous forme de circuit "prêt à utiliser" (ET-OPTO AC-OUT 4 dont la fiche constructeur est disponible [http://www.tellab.it/open2b/var/catalog/product/files/57.pdf ici]) qui dispose de quatre optocoupleurs isolés. Nous en utiliserons un pour commander la pompe (OCT0) et un deuxième pour commander le chauffe-eau (OCT1). L'objectif d'une des séances a été d'établir ce dispositif d'alimentation, de comprendre le fonctionnement de l'optocoupleur dont nous disposons et de mapper les optocoupleurs aux sorties de l'Arduino.

Par la suite, nous avons été contraint de changer de type de commande. En effet, la carte d'octocoupleurs permettait la commande mais n'était pas capable de couper le contacteur. Cela est du au principe même du fonctionnement du contacteur. En effet,le contacteur est composé d'une bobine (entre A1 et A2) qui vient attirer un bloc aimanté de façon à créer un contact entre les six broches de puissance (connecteurs 1 à 6). Le problème était que cette bobine demandait un courant trop important que l'octocoupleur gérait mal en rendant impossible la coupure de la bobine.

Pour palier à ce problème, nous avons choisi d'utiliser une carte de commande d'octocoupleurs commandant des relais (ET-OPTO RELAY4, dont la fiche constructeur est disponible [http://www.micro4you.com/files/ETT/ET-OPTO-RELAY4.pdf ici]). Après vérification à l'aide de la documentation technique des relais, nous avons constaté que ceux-ci sont bien capable de couper la commande des contacteurs.

===Fabrication d'un Shield Arduino===
Nous avons donc été amené à créer un shield Arduino avec une carte de prototypage rapide qui réalise les fonctions suivantes :

* intégrer un connecteur 10 broches compatible pour :
** relier la sortie digitale IO 2 à l'optocoupleur OCT0 qui commandera l'alimentation de la Pompe
** relier la sortie digitale IO 3 à l'optocoupleur OCT1 qui commandera l'alimentation du Chauffe eau
* intégrer le circuit de récupération des impulsions du débitmètre TTL et échantillonner ce signal sur l'entrée digitale IO8
* disposer d'une fonction "Boutons Arrêt d'urgence/Commande manuelle" pour la pompe et le chauffe eau.

===Caractérisation de la pompe===
La pompe récupérée est un composant fabriqué par Invensys, dont la fiche constructeur est disponible à [http://www.toolbox.robertshaw.com/appliance/linkedElements/WaterPumps.pdf cette adresse].
Il s'agit d'une pompe à piston qui permet de délivrer une pression allant jusqu'à 19 bar au maximum. Cette pression est fonction du débit en sortie de la pompe, selon la caractéristique à droite.
[[Fichier:Caractéristique_Pompe_Invensys_CP4.JPG‎|250px|thumb|right|Caractéristique Pression/Débit de la pompe]]

Elle se commande en "tout ou rien" et est alimentée en 230 V alternatif 50Hz.
Le paramètre permettant de fixer le point de fonctionnement sur le graphique précédent est la section du tuyau en sortie. Nous n'avons pas la main sur ce paramètre étant donné que nous possédons déjà le système de tuyaux avec les embouts adaptés de section S = 3 mm². En revanche, nous la commanderons en décidant du temps d'allumage.
Il s'agit maintenant de déterminer à quels moments et combien de temps il faut alimenter la pompe, sachant qu'il faut que l'extraction dure entre 20s et 25s et que le chauffe eau induit un retard à déterminer.

'''Séance pratique :'''

Lors d'une séance de manipulation de la pompe, nous l'avons commandé au moyen de l'Arduino pendant plusieurs durées pré-établies (2s, 5s et 10s) afin de déterminer si elle possède un régime transitoire négligeable. Nous avons ensuite relevé le volume d'eau qu'elle avait délivré grâce à une éprouvette graduée. Plusieurs séries de mesures ont été effectuées à chaque fois.
Lors de cette manip, le tuyau de sortie n'était pas connecté au chauffe-eau afin que la mesure ne soit pas influencée, il donnait directement dans l'éprouvette. Cette manipulation nous a également permis de tester notre débitmètre et notre manière d'échantillonner le signal qu'il nous fournit, en comparant le volume déduit par celui ci et le volume réel relevé avec l'éprouvette.

Ainsi, nous avons déterminé que quelque soit le temps d'allumage (pour une durée supérieure à 2s), la pompe fournit un débit constant de 5,2 mL/s = 0,312 cc/min.

===Étalonnage du capteur de température du chauffe-eau===
Afin de réguler le chauffe eau en température, nous avons besoin de connaître le fonctionnement du capteur de température intégré sur celui ci.
Il s'agit en fait d'une thermistance (résistance variable dont la valeur de la résistance dépend de la température), ici à coefficient de température négatif (CTN).

Il n'y a visiblement pas de référence constructeur dessus. Nous avons donc décidé d'effectuer un étalonnage de celle ci. Il existe un dispositif en salle électronique comportant des capteurs de températures déjà étalonnés disposés sur une plaque qui peut être chauffée par un chauffage électrique. Nous avons "collé" avec de la pâte thermique notre thermistance sur cette plaque et effectué un relevé de la résistance en fonction de la température indiquée par les capteurs déjà présents. Le problème est que le chauffage ne pouvait pas être régulé, il continue de chauffer tant qu'on l'alimente. N'ayant donc pas de valeur de température stabilisée, à cause de l'inertie thermique, les valeurs de résistances relevées sont complètement non significatives.
Cette manipulation aura tout de même soulevé un point à prendre en compte : le capteur de température étant en métal, il faudra déterminer l'inertie qu'il induit dans la mesure et si celle ci est négligeable, sinon, comment faire avec.

Le soucis pour une approximation linéaire est que la plage de température est trop importante. En effet, la température de l'eau pour le café doit être entre 88°C et 90°C, mais on doit aussi pouvoir utiliser le capteur à une température de 65°C pour prévoir un mode "économie d'énergie", lorsque la machine n'est pas utilisée pendant 10min par exemple.
Après recherches, la loi d'évolution de la résistance en fonction de la température est de la forme : <math>{1 \over {T}} = A + B \ln(R_{Th}) + C (\ln(R_{Th}))^3 \,</math>

Autre idée : simplement l'étalonner la thermistance au moyen d'un bain d'eau que l'on peut chauffer et d'une sonde de température précise.

Après relevé de l'évolution de la résistance en fonction de la température au moyen du bain marie, nous avons constaté et vérifié que notre sonde de température se comporte comme une sonde standardisée PT100. Nous avons trouvé une fiche constructeur de ces sondes standardisées qui vérifie les caractéristiques de notre capteur ([http://search.murata.co.jp/Ceramy/CatalogAction.do?sHinnm=?&nbsp&sNHinnm=NCP15WF104D03RC&sNhin_key=NCP15WF104D03RC&sLang=en&sParam=series+U0120L0770S0416A1161 lien]). Sur la plage de température que nous avons besoin d'utiliser (25°C - 105°C), nous pouvons négliger le terme en ln^3, ainsi l'équation régissant la résistance en fonction de la température peut s'exprimer ainsi :
<math>{R_{Th}}={R_0} \times\exp\left(\beta\times\left({1 \over {T}} - {1 \over {T_0}}\right)\right) \,</math> avec <math>{R_0}</math> = 100 kOhm la résistance de référence à <math>T_0</math>= 25°C, <math>\beta</math> = 4334 Kelvin le coefficient fourni par le constructeur pour l'approximation sur la plage 25°C-100°C.

Ainsi, la représentation des données pour récupérer la température est la suivante : au moyen d'un pont diviseur, nous récupérons une tension sur l'Arduino image de la résistance et donc de la température avec la relation ci-dessus.
Nous ne pouvons pas inclure dans le code directement un calcul avec la fonction exponentielle, cela prendrait , entre autres, trop de temps de calcul et ne serait pas optimisé étant donné que l'on connait la résolution du CAN de l'Arduino. Pour cela, nous passons par un tableau de conversion sur 256 valeurs calculé au moyen de cette [https://docs.google.com/spreadsheets/d/185WP8sv1Ryd4hWDlqnpToG-fiC0yVxaIgjR2ey1FG68/edit?usp=sharing feuille de calcul]. Voici un schéma de principe :

Coté Arduino : Tension aux bornes de Rth(V) ---CAN---> Valeur sur 10 bits ---TableauDeConversion---> Valeur sur 8 bits

La Raspberry (ou le PC) récupère ensuite cette valeur sur 8 bits et en déduit la température avec la connaissance du "pas" entre 2 températures : <math>Pas = {(105-25)\over 255}</math>

Coté Raspberry : Valeur sur 8 bits ---> 25 + (Valeur * Pas) ---> Température en °C

Cette méthode permet d'alléger le temps de traitement sur l'Arduino et surtout de ne pas perdre en précision et résolution à cause de la transmission de l'information "température", qui s'effectue sur 8 bits.

===Caractérisation du chauffe eau===
Le chauffe eau que nous avons récupéré est de type thermoblock. Il s'agit en fait d'une résistance chauffante autour de laquelle se situe un serpentin dans lequel l'eau circule, le tout étant isolé dans un châssis en métal.
Les principaux avantages de ce système thermoblock est qu'il conserve très bien la chaleur et qu'il permet de ne chauffer que la quantité d'eau nécessaire, la petite quantité qui passe à l'intérieur. On peut alors considérer l'échange thermique entre le chauffage et l'eau quasi instantané et uniforme. L'inconvénient majeur est en revanche, comme pour tout système thermique, l'inertie thermique importante qu'il possède, notamment due à son corps en métal.

Nous n'avons pas trouvé de données constructeur sur ce chauffe eau. La seule information inscrite est la puissance électrique qu'il absorbe : 1200 W.
Il sera alimenté, comme pour la pompe, en 230V alternatif 50Hz, en tout ou rien. Il s'agit maintenant d'estimer ses caractéristiques (inertie, temps caractéristiques, gains en température en fonction de l'entrée) afin de mettre en place un plan de régulation adapté. Ne possédant aucune information sur ce système, nous ne procéderons pas à une étude théorique thermique qui serait trop approximative compte tenu de la géométrie du système et trop fastidieuse à mettre en place. Nous avons choisi de procéder par identification, en relevant les courbes d'évolution de la température, pour différents temps de commande.

'''Résultats :'''

A chaque fois, la réponse peut s'exprimer de la façon suivante : on constate un temps de retard pur au démarrage dû à l'inertie, puis une évolution s’apparentant à celle d'une réponse à système du 1er ordre. On peut écrire la fonction de transfert du système sous cette forme : <math>H(P) = \frac{K}{1+\tau P} e^{- T_{r} P}</math> (modèle de Broïda)

[[Fichier:Commande_2s.png|350px|vignette|right|upright=1.25|Réponse en température pour 2s d'alimentation]]

[[Fichier:Commande_5s.png|350px|vignette|left|upright=1.25|Réponse en température pour 5s d'alimentation]]

[[Fichier:Commande_10s+pompe.png|350px|vignette|centre|upright=1.25|Réponse en température pour 10s d'alimentation, puis arrivée d'eau à t=75s]]

Remarque : On peut observer sur le 2ème graph l'influence du passage de l'eau dans le thermoblock sur la température. Celui ci se traduit comme une perturbation avec un comportement type 1er ordre sur le thermoblock. Avec ces paramètres (temps, gain), on pourra par la suite estimer la compensation à ajouter afin de maintenir la température du thermoblock constante malgré la chauffe de l'eau.

Ainsi, on peut récapituler ceci dans le tableau suivant :

{| class="wikitable"
|-
! Temps de commande
! Gain en température K
! Temps de retard Tr
! Temps caractéristique <math>\tau</math>
|-
| 2 s
|
|
|
|-
| 5 s
|
|
|
|-
| 10 s
|
|
|
|-
|}

===Détermination du plan de régulation===
Rappelons le cahier des charges de la régulation :

* chauffer l'eau à 90°C, avec comme erreur acceptable +/- 2°C (conformément aux informations recueillies)
* pas de dépassement de la consigne : en effet, le système conservant très bien la chaleur, attendre qu'il se refroidisse serait trop long et surtout, si il y a dépassement après 100°C, on crée un générateur de vapeur... ce qui est bien sûr très dangereux pour le système et pour la sécurité de l'utilisateur
* avoir un temps de réponse acceptable pour l'utilisateur (actuellement, à titre d'exemple, pour la cafetière Nespresso, l'étape de chauffe n'excède en général pas 60s)
* mode économie d'énergie : la machine est destinée à être utilisée publiquement, par des utilisations ponctuelles et pas uniformément réparties dans le temps, il est donc important que la machine ne gaspille pas de l'énergie lorsqu'elle n'est pas utilisée. Ainsi, le bon compromis serait que la température soit maintenue à environ 50°C après 10min d'inutilisation.

'''Choix de la régulation :'''

[[Fichier:Grafcet_AutoHeat.JPG‎|400px|thumb|right|Grafcet illustrant le principe de l'algorithme de régulation de la température]]
Ici ne possèdant pas de commande réglable, nous ne pouvons pas choisir une régulation continue de type PID ou prédicteur de Smith, car on commande le thermoblock via un relais. Une commande MLI n'est pas envisageable dans notre cas, à cause du faible "pouvoir de commutation" des contacteurs de puissance que nous avons récupéré. Une simple régulation Tout ou Rien type thermostat ne serait pas suffisante, car ceci engendrerait des dépassements et des oscillations fortes autour de la température de consigne compte tenu du rapport Temps caractéristique sur Temps de retard du système <math>\frac{\tau}{T_{r}} \approx 1,66</math>. Nous nous situons donc dans le cas "Régulation par Boucles multiples" d'après la méthode de Broïda.

Dans notre cas d'utilisation, un algorithme par boucles multiples, basé sur des commandes Tout ou Rien, est possible et peut satisfaire au cahier des charges. En effet, la consigne ne change pas d'ordre de grandeur : il faudra toujours chauffer l'eau dans un intervalle compris entre 88°C et 92°C. On propose alors l'algorithme suivant :

Principe :
* 1) Chauffe Initiale : Au début de la phase de chauffe, on réalise une chauffe importante (15 s), l'objectif étant d'approcher grossièrement la température auprès de la température de consigne et qu'elle se soit stabilisée (attente de 12s) avant de passer à l'étape de chauffe par palier.
* 2) Chauffe par palier : Il s'agit ici d'effectuer ensuite une succession de "petites" chauffes jusqu'à être dans la plage de température acceptable, tout en tenant compte de l'inertie thermique. Ces successions de chauffe sont définies ici par 2s de chauffe, puis 6s d'attente de l'établissement de la température avant de déterminer si on reste dans la phase Chauffe par palier ou si on entre dans la phase Maintien au chaud. La température de seuil a été déterminée à 82°C, pour prendre en compte le phénomène d'inertie.
* 3) Maintien au chaud : On se situe alors proche ou dans la plage de température. Il s'agit alors d'effectuer des petites chauffes ponctuelles permettant de maintenir la température dans l'intervalle (refroidissement par le milieu ambiant). Cette étape prend également en compte le maintien au chaud lorsque de l'eau passe à travers le chauffe eau et fait donc chuter sa température (compensation plus forte : cycle de 3s de chauffe puis 3s d'attente). On peut, à partir de cette étape, commander la pompe pour élaborer un café si un café a été demandé.

Un avantage de la chauffe palier par palier permet d'attendre que la chaleur s'établisse uniformément dans le thermoblock. Ceci permet de limiter les problèmes d'inerties thermiques, y compris celui de notre capteur (sans mettre ces paliers d'attente, ce que l'on observerait en température ne serait pas nécessairement la température au coeur du thermoblock).

[[Fichier:Mode_Auto.png|400px|vignette|right|upright=1|Evolution de la température du chauffe eau avec la régulation]]

'''Résultats de la régulation'''

On constate sur le graphique à droite les 3 étapes de chauffe : les étapes 1 et 2 s'effectuant ici entre 0s et environ 80s puis l'étape de maintien après cette date. La température évolue ainsi de façon presque linéaire pendant les étapes 1 et 2, puis reste dans la plage 88°C-92°C.
A t=140s, la pompe est commandée dans cette exemple afin de pouvoir visualiser le maintien en température lorsque l'eau circule.

On remarque donc que cette régulation valide les 2 premiers critères du cahier des charges (chauffer l'eau dans la plage et pas de dépassement de cette plage). Cependant, le temps de réponse avant de pouvoir élaborer un café est un peu plus long (environ 80s).

===Réalisation de la carte électronique===
===Construction de la gestion automatique du café===

==Déroulement du projet==
===Avancement des différents objectifs===
Les différents objectifs et leur avancement sont résumés dans le tableau suivant
{| class="wikitable"
|-
! Objectif
! Etat
! Commentaire
|-
! Étalonnage du débitmètre
| Fini
| La documentation est fournie dans le Wiki, et le shield Arduino permet son utilisation
|-
! Analyse du chauffe-eau
| Fini
| Le chauffe-eau est maintenant complètement caractérisé et suit une loi linéaire sur l'intervalle que nous utilisons. Le retard dans la commande ainsi que la commande tout ou rien complexifie grandement son utilisation mais une solution a été trouvée et fonctionne parfaitement, comme indiqué dans le wiki (à rédiger)
|-
! Calibration de la pompe à eau
| Fini
| La documentation est aussi fournie dans le wiki, et le shield Arduino permet son utilisation en temps réel.
|-
! Régulation du chauffe-eau en température
| Fini
| Le modèle équivalent a été déterminé, comme indiqué dans le wiki, et les tests semblent confirmer le bon fonctionnement. Les derniers tests complémentaires ont prouvés que la régulation s'effectue correctement même lors d'un pompage.
|-
! Régulation d’une pompe à eau en pression et en débit
| Fini
| Le comportement de la pompe a été complètement caractérisé et l'utilisation des nouvelles pièces créées au Fabricarium n'engendre pas de perturbations trop importantes.
|-
! Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
| Fini
| L'utilisation d'une carte de puissance couplée avec deux contacteur et un shield arduino réalisé par nos soins rempli parfaitement cet objectif
|-
! Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)
| Fini
| Le shield Arduino que nous avons réalisé permet aussi de lire les différents capteurs
|-
! Programmation de l'Arduino pour commander la carte
| Fini
| Pour finir il est nécessaire d'utiliser deux Arduinos mais tout les deux sont programmés
|-
! Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
| Fini
| La partie NFC est réalisée par un des deux Arduinos, l'interface tactile est encore en cours de réalisation. Bonne nouvelle ! Les tests ont montrés que le temps de réponse entre les Arduinos et le RaspberryPi sont négligeables devant le temps d’échantillonnage. L'écran fonctionne parfaitement et permet de sélectionner la quantité de café désirée.
|-
! Dimensionnement capsule et du dispositif de broyage
| Fini à 80 %
| Les capsules et la chambre de la capsule ont été complètement étudiés. Un système complet à été créé pour ne plus être contraint à l'utilisation du système propriétaire. Trois pièces ont été créé à l'aide du logiciel de CAO Catia. La création de ces pièces en métal est pour le moment impossible (Notre contact aux Arts&Métiers est indisponible, peut-être le responsable des machines-outils de la section mécanique peut nous aider à réaliser certaines pièces). Nous nous sommes rabattus sur la création des pièces en PLA à l'aide de l'imprimante 3D WitBox du fabricarium. Les trois pièces principales sont terminées, ce qui pourrait permettre d'en faire un démonstration. La pièce de liaison est fonctionnelle, ce qui nous permet d'adapter notre tuyau de pompe aux trois pièces précédentes. Par manque de temps, il ne sera pas possible de montrer le fonctionnement automatique des pièces.
|-
! Création d'un système dispenseur de gobelets
| Fini à 0%
| Le système ne sera pas créé par manque de temps.
|}

===La programmation des différents éléments===
Pour la partie programmation, le défi résidait dans le fait de faire communiquer tout les éléments à l'aide d'un seul programme. Pour cela, nous avons subdivisé les fonctions principales dans différents modules. Ceci nous permettait entre autre de minimiser le nombre d'éléments reliés à la partie "puissance" du projet (détaillé plus loin)

Le code source du projet est disponible sur [http://www.github.com GitHub], et les liens vers les différents programmes sont les suivants
{| class="wikitable"
|-
!
! Lien
|-
! Shiled Arduino NFC
| [https://github.com/henyxia/tweekd_nfc]
|-
! Shield Arduino de puissance
| [https://github.com/henyxia/tweekd_hvc]
|-
! Interface en ligne de commande
| [https://github.com/henyxia/tweekd]
|}
====Le Shield Arduino NFC====
L'objectif de l'utilisation du Shield NFC est de permettre à un utilisateur de payer un café, et donc de s'identifier sur la machine, à l'aide de carte Lille 1. Pour cela, nous nous sommes premièrement orientés sur l'utilisation de l'IDE Arduino et de la librairie dédiée au [https://github.com/Seeed-Studio/PN532 PN532]. Puis, nous avons décidé de passer à un langage C pour avoir une meilleure visibilité sur les registres. Par conséquent, nous avons utilisé le compilateur avr-g++ pour compiler le projet. Il nous a donc était nécessaire de transposer une partie des fichiers C et C++ pour les rendre utilisables avec notre programme C.

La communication se fait par système de questions-réponses. Le serveur sur la Raspberry envoie une demande de données, et l'Arduino répond en conséquence. La seule difficulté a résidé dans la problématique des données à envoyer pour l'identification. Les cartes de Lille 1 sont des cartes NFC Mifare Classic 1K. Elles sont composées de 16 secteurs de 4 fois 16 bytes. Le secteur qui nous intéresse est le douzième secteur, qui est encodé en utilisant les clés NFC publiques (donc accessible par tout le monde). Les clés publiques en question sont :

{| class="wikitable"
|-
!
! Clé
|-
! A
| A0A1A2A3A4A5
|-
! B
| B0B1B2B3B4B5
|}

Ce douzième secteur contient, pour les carte étudiantes, l'INE, suivi du numéro étudiant (sur 8 chiffres), suivi du prénom, suivi d'un point puis du nom. Nous avons d'abord envisagé d'utiliser le nom et le prénom, cependant cela posait le problème des personnes avec le même patronymes. De plus, il arrivait que le nom de l'étudiant soit tronqué pour rester dans l'espace alloué au secteur 12. Par conséquent, nous utilisons le numéro d'étudiant, qui est toujours au même endroit sur le secteur. Le logiciel compare alors ce numéro à une liste d'étudiant.

Par soucis de sécurité, nous n'avons pas de liste donnant une correspondance directe entre un numéro d'étudiant et son nom. En effet, la liste utilisée est un enchaînement de nom et de numéro étudiant encodé avec l'algorithme MD5. Pour récupérer le nom, il nous suffit alors de comparer le numéro étudiant que nous récupérons (que nous encodons en MD5) avec la liste. Ceci nous assure une confidentialité relative, dépendante directement de la robustesse de la non réversibilité du MD5.

Une fois la reconnaissance des cartes étudiantes terminées, nous avons essayé de d'inclure les cartes Lille 1 dédiées au personnel. La première question que nous nous sommes posée est comment pouvons nous faire la différence, au niveau du lecteur, entre une carte étudiante et une carte du personnel. Nous avons remarqué que les cartes du personnel comporte, sur leur douzième secteur, deux fois le numéro de personnel (sur 6 chiffres). La répétition du numéro de personnel se situe à l'endroit où se situe le nom de l'étudiant sur la carte de l'étudiant. Le test est donc assez facile à réaliser. L'autre problème est : comment lié un numéro de personnel à un nom ? Nous n'avons pas encore résolu ce problème car cette table de liaison n'est pas accessible à PolytechLille. Éventuellement, si nous arrivons à accomplir tous les objectifs du projet, nous envisagerons de contacter les responsables de Lille 1 pour obtenir cette table de correspondance.

====Le Shield Arduino de puissance====
====L'interface en ligne de commande utilisateur====
Durant les phases de test, nous avons créé une interface en ligne de commande. Celle-ci permettait d'envoyer directement des commandes au HVC, comme l'allumage du chauffe-eau pendant un certain nombre de secondes; ou encore le pompage. Cette interface est restée en utilisation jusqu'à deux semaines avant la fin du projet, car elle nous permettait d'effectuer un suivit très simple de l'état des capteurs. Par la suite, à partir du commit [https://github.com/henyxia/tweekd/commit/ac55328a023270dc55e5e5a99c2bc9a3a1873885 ac55328], nous nous sommes orienté vers l'utilisation de l'écran fournis.

Durant la période où nous utilisions l'interface en ligne de commande, nous nous servions de celle-ci car elle nous fournissait des informations comme le PID. Cette information nous permettait de tuer le programme principal ainsi que tous ces fils lorsque celui ci plantait. Il affichait aussi le volume pompé, la dernière température relevée, l'identifiant lu par le lecteur NFC et la date à laquelle cette lecture s'était produite. Elle affichait aussi les dernières entrées du journal, avec des couleurs indiquant leur niveau d'importance (Debug, Info, Warning ou Error).

INSERER UNE IMAGE DE L'INTERFACE ICI

====L'interface utilisateur finale====
Pour l'interface utilisateur finale, nous nous reposons sur un module d'affichage [http://www.robopeak.com/docs/doku.php?id=product-rpusbdisp RPUSBDisp] de la société RoboPeak. Avant de se lancer dans la phase de programmation de l'interface, il nous a d'abord fallut rendre utilisable l'écran par le RaspberryPi. Pour cela, il a fallut créer un module chargeable par le noyau Linux. Une fois ce module créé, nous nous sommes rendu compte le noyau Linux que nous utilisions (celui fournis avec Raspbian) ne contenait pas les symboles nécessaires au chargement du module. Nous avons alors recompilé le noyau Linux avec les symboles manquants. La compilation s'est avérée assez compliquée car pour éviter de faire de la cross compilation (ce qui aurait surement augmenter le taux d'échec de compilation) nous avons compilé le noyau directement à partir de la RaspberryPi ce qui, malgré son overclooking, était très long (une compilation prenait approximativement une nuit complète). Après quatre tentatives, nous avons réussi à obtenir un noyau fonctionnel.

[[Fichier:RPUSBDisp1.jpg|200px|thumb|right|Premier BMP affiché avec succès sur l'écran]] Une fois l'écran utilisable, nous nous sommes lancés dans le développement de l'interface. Nous avons choisi, dans une optique de performance, de n'utiliser que la librairie X11. Le premier objectif était de réussir à afficher une image sur l'écran. Le format d'image utilisé était le BMP car il n'est pas compressé et peut être lu sans autres calculs. Après de petits cafouillages (liés au fait que le BMP représente une couleur de 0 à 255 et X11 de 0 à 65535) nous avons réussi à faire afficher notre première image. Cependant, le point négatif est que l'image est affichée en une trentaine de secondes. Nous sommes donc en train de travailler sur un moyen de faire afficher des images plus rapidement.

Après de longues recherches, nous nous sommes rendus compte qu'il n'était pas possible de réaliser une interface temps réel avec cet écran si l'on utilisait la librairie X11. En effet, celle ne communique pas assez rapidement avec l'écran (les recordes d'écriture étant de ~17 secondes par images avec X11). Le constructeur préconise en fait une utilisation à travers une interface USB. Cette interface, décrite dans ce [http://www.robopeak.com/data/doc/rpusbdisp/RPUD03-rpusbdisp_interface_protocol-enUS.1.0.pdf manuel] nous oblige à réécrire notre interface homme machine.

[[Fichier:RGB565.gif|320px|thumb|left|Représentation des données en RGB565]] Le [https://github.com/henyxia/tweekd_gui/blob/master/main.c lien suivant] est une démonstration de la première commande que nous avons réussi à envoyer à travers la librairie USB. Nous avons ensuite essayé d'afficher une image sur l'écran. Pour cela, il a été nécessaire de créer un type de fichier intermédiaire car l'écran n'est pas capable de lire la plupart des formats d'images classiques. Pour rendre la conversion plus simple, nous avons choisi le type BMP comme fichier image source. Le type BMP organise la description des images de façon simple. Le fichier commence par une en-tête qui comporte des informations comme l'adresse de début de l'image, le nombre de bits par pixel et d'autres informations qui ne nous servent pas. Une fois ces deux informations récupérés (nous n'utilisons que des images à 24 bits par pixel, soit 8 b bits pour le rouge, 8 bits pour le vert et 8 bits pour le bleu) nous convertissons notre image dans le format lisible par l'écran, qui est le RGB565. Ce format compresse (avec pertes) la précision des couleurs pour que celle-ci soit ordonnée avec 5 bits pour le rouge, 6 bits pour le vert et 5 bits pour le bleu. Nous rendre plus pratique cette conversion, nous avons créé un [https://github.com/henyxia/bmp2rgb565 programme] permettant l'automatisation de ce processus. Une fois ce programme utilisé (à travers le Makefile du projet principal), l'image est envoyé à l'écran. Après chronométrage, nous arrivons à un temps moyen de 1,2 secondes pour afficher une image intégralement. Ce temps est bien supérieur aux 17 secondes de la librairie X11, mais est aussi légèrement éloigné des 25 images par secondes promises par le vendeur (Ce taux de rafraîchissement n'étant atteignable que si nous ne générons des carrés de couleurs). Cependant ce temps de réponse est largement suffisant pour l'utilisation que nous souhaitons en faire.

Nous nous sommes donc penché sur l'utilisation de l'interface tactile de l'écran. C'est une lecture USB par interruption qui nous donne si l'écran est actuellement pressé, et si oui où la pression est effectuée. Donc, pour permettre au programme de comprendre quelle fonction appeler lors d'un appuie sur l'écran, nous créé un autre format de fichier. Celui ci, aussi issu du BMP, est une liste de pixel en nuance de gris. Donc, chaque pixel est représenté par une valeur comprise entre 0 et 255. En fonction de la valeur, le programme principal appelle la fonction en conséquence. De façon analogue à la conversion de BMP et RGB565, nous avons créé un programme permettant de convertir les BMP en suite de bytes correspondant aux pixels. Ce programme ce trouve à [https://github.com/henyxia/bmp2map l'adresse suivante].

==Conclusion==
===Vidéo de présentation===
Nous pensons enregistrer la vidéo pendant les vacances à l'aide d'une caméra professionnelle.

Thetweekproject

2015-05-10T20:29:24Z

Pletouse : /* Détermination du plan de régulation */ Ajout explications régulation + résultats

=Machine à café=
==Présentation du projet==
===Cahier des charges===
SA
* Broyage des grains déjà torréfiés
** Régulation d’un moteur en vitesse avec charge variable
** Réutilisation des éléments d’une cafetière existante (carte électronique hors d’usage)
*** Étalonnage du débitmètre
*** Analyse du chauffe-eau
*** Calibration de la pompe à eau
** Propulsion de l’eau chauffée
*** Régulation d’une pompe à eau en pression et en débit
*** Régulation du chauffe-eau en température
** Modélisation des éléments du système
SC
* Création d’une interface homme-machine
** Installation d’un RaspberryPi avec un écran tactile
*** Gestion des stocks de café, d’eau et de gobelets
*** Gestion des différents éléments (pompe, compresseur, chauffe eau, …)
** Réalisation d’une interface graphique permettant de :
* Moudre le café
* Sélectionner la quantité d’eau à distribuer (café court ou long)
* Sélectionner un café parmi une présélection de café
** Création d’une application Web et Smartphone
*** Possibilité de noter son café
*** Possibilité de retenir un choix de café particulier
* Création de profils créés à partir de la carte étudiante
** Lecture d’information en NFC sur la carte étudiante
** Création d’une base de données basée sur ces profils
*** Proposition des cafés à partir de ceux les plus commandés et/ou mieux notés
*** Possibilité de retenir certains choix et de les recommander

Commun
* Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
* Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)

===Liste des tâches===
*Caractériser le débitmètre
*Caractériser le chauffe-eau
*Caractériser la pompe
*Détermination du schéma de fonctionnement et éventuels correctifs de régulation
*Réalisation de la carte électronique de commande
*Programmation de l'Arduino pour commander la carte
*Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
**Estimation temps de réponse (temps de transfert à l'Arduino négligeable ?)
*Gestion automatique du café
**Dimensionnement capsule et du dispositif de broyage
**Création d'un système dispenseur de gobelets
***Design d'engrenages pour les gobelets
*Plus de fonctionnalités si temps restant
**Recharge par le Net
**Poison pour diabétique
**Interface beaucoup travaillée
**Packaging pratique

===Matériel disponible===

*Machine à café Nespresso défectueuse en morceaux [fournie en 2014]
**Un débitmètre
**Une pompe à eau
**Un chauffe-eau
**Tubes
**Carte électronique (très sûrement défectueuse)
**Mécanisme d'infusion de capsules de café
**Réservoir d'eau avec valve anti-retour

*Matériel électro-informatique
**Arduino Uno [fourni le 26/1/2015]
**Arduino Léonardo [fourni le 5/2/2015]
**RaspberryPi [http://www.adafruit.com/products/998] [fourni le 28/1/2015]
**Carte SD 16G [fournie le 29/1/2015]
**Capteur de température [http://fr.rs-online.com/web/p/capteurs-de-temperature-et-humidite/0264147/] [fourni le 4/2/2015]
**Thermocouple [http://fr.rs-online.com/web/p/thermocouples/6212287/] [fourni le 4/2/2015]
**Lecteur NFC [http://www.adafruit.com/product/364] [fourni le 4/2/2015]
**Ecran tactile [http://www.gotronic.fr/art-afficheur-tactile-usb-2-8-dfr0275-21547.htm] [fourni le 18/03/2015]

*Matériel électronique de puissance
**Contacteurs de puissance (max 32A, 400V) (x2)
**Coffrets d'isolation électrique (x2) (achetés le 09/02/2015)
**Cables électriques (section 2,5 mm2) (achetés le 09/02/2015)
**Boitier interrupteur (achetés le 09/02/2015)

===Matériel manquant===

*Broyeur de café [http://www.maxicoffee.com/moulin-cafe-inoxnoir-gvx2-krups-p-9323-3_68.html?osCsid=e4t6v05n7lctvtod3ehggr0g05]

===Répartition du travail===
{| class="wikitable alternance centre"
|+ Titre
|-
|
! scope="col" | Lundi 14-16h
! scope="col" | Mercredi 14-18h
! scope="col" | Jeudi 10-12h
|-
! scope="row" | Semaine 5
| 26/01 - Organisation et répartition du projet
| 28/01 - Caractériser le débitmètre et gérer les pièces manquantes
| 29/01 - Caractériser le chauffe eau et la pompe
|-
! scope="row" | Semaine 6
| 02/02 - Détermination du schéma de fonctionnement et du plan de régulation
| 04/02 - Réalisation de la carte électronique
| 05/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 7
| 09/02 - Réalisation de la carte électronique
| 11/02 - Réalisation de la carte électronique
| 12/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 8
| 16/02 - Gestion automatique du café
| 18/02 - Gestion automatique du café
| 19/02 - Gestion automatique du café
|-
! scope="row" | Semaine 9
| 23/02 - Gestion automatique du café
| 25/02 - Gestion automatique du café
| 26/02 - Gestion automatique du café
|-
! scope="row" | Semaine 11
| 09/03 - Gestion automatique du café
| 11/03 - Gestion automatique du café
| 12/03 - Gestion automatique du café
|-
! scope="row" | Semaine 12
| 16/03 - Gestion automatique du café
| 18/03 - Gestion automatique du café
| 19/03 - Gestion automatique du café
|-
! scope="row" | Semaine 13
| 23/03 - Gestion automatique du café
| 25/03 - Gestion automatique du café
| 26/03 - Gestion automatique du café
|-
! scope="row" | Semaine 14
| 30/03 - Gestion automatique du café
| 01/04 - Gestion automatique du café
| 02/04 - Gestion automatique du café
|-
! scope="row" | Semaine 15
| Férié
| 08/04 - Gestion automatique du café
| 09/04 - Gestion automatique du café
|-
! scope="row" | Semaine 16
| 13/04 - Gestion automatique du café
| 15/04 - Gestion automatique du café
| 16/04 - Gestion automatique du café
|-
! scope="row" | Semaine 17
| 20/04 - Gestion automatique du café
| 22/04 - Gestion automatique du café
| 23/04 - Gestion automatique du café
|}

En somme, les prévisions pour les différentes parties sont de:
*8 H pour la prise en main du matériel actuel
*14 H pour la réalisation de la carte électronique de commande
*70 H pour la gestion automatique du café

==Etude préalable==
===Caractérisation du débitmètre===
Lors de la première séance "pratique", nous avons étudié le comportement du débitmètre.

Après recherches, nous avons appris qu'il en existe deux types. Le premier type est assimilable à une résistance variable dont la valeur dépend du débit. Le deuxième type se comporte comme un type tout ou rien qui effectue un contact entre deux des pins lorsque l'ailette interne fait un tour. Le débit est donc déduit par la fréquence des impulsions que délivre le débitmètre.

Notre débitmètre est un composant crée par Digmesa, dont la fiche constructeur est disponible [http://www.pollin.de/shop/downloads/D180051D.PDF ici]. Il s'agit d'un débitmètre à turbine, du deuxième type.

Le montage à droite permet de récupérer les impulsions du débitmètre sous forme TTL.

[[Fichier:Schéma_Montage_Débitmètre.JPG|250px|thumb|right|Schéma du montage permettant de récupérer les impulsions du débitmètre]]

Le volume d'eau mesuré s'exprime alors sous cette forme : <math>V = n * \frac{1}{Kdeb}</math> avec n le nombre d'impulsions, V le volume en L et Kdeb la constante fournie dans la doc constructeur Kdeb = 1925 impulsions/L.

Le débit n'est pas une grandeur mesurée directement avec notre débitmètre, mais elle est déduite en choisissant un temps <math>\Delta t</math> suffisamment court pour considérer le débit "instantané".
L'expression du débit "pseudo-instantané" est alors la suivante : <math>\frac{\Delta V}{\Delta t} = \frac{1}{Kdeb} * \frac{\Delta n}{\Delta t} </math> avec <math>\Delta n</math> la variation du nombre d'impulsion pendant le <math>\Delta t</math>.

Obtenir le débit est ici utile car, d'après les informations collectées, le temps d'extraction du café doit être contrôlé (entre 20s à 25s) et le café doit être de 5cl pour un ristretto et de 12cl pour un lungo.

Il est important de noter aussi que ce capteur a une influence sur la pression : en effet, il peut induire une perte de pression (au maximum) de 0,43 bar.

===Réalisation interface commande - puissance===
Afin de pouvoir séparer circuit de commande et alimentation de puissance, nous utiliserons un optocoupleur et des contacteurs pour l'alimentation de la pompe et du chauffe-eau (tout deux alimentés en 230V alternatif 50 Hz). L'optocoupleur est utilisé afin de bénéficier d'une isolation galvanique entre les deux parties, pour plus de sécurité.

La commande d'alimentation est envoyée par l'Arduino à l'optocoupleur. L'optocoupleur commande alors le contacteur (relais de puissance), ce qui alimente l'élément choisi.

L'optocoupleur utilisé est sous forme de circuit "prêt à utiliser" (ET-OPTO AC-OUT 4 dont la fiche constructeur est disponible [http://www.tellab.it/open2b/var/catalog/product/files/57.pdf ici]) qui dispose de quatre optocoupleurs isolés. Nous en utiliserons un pour commander la pompe (OCT0) et un deuxième pour commander le chauffe-eau (OCT1). L'objectif d'une des séances a été d'établir ce dispositif d'alimentation, de comprendre le fonctionnement de l'optocoupleur dont nous disposons et de mapper les optocoupleurs aux sorties de l'Arduino.

Par la suite, nous avons été contraint de changer de type de commande. En effet, la carte d'octocoupleurs permettait la commande mais n'était pas capable de couper le contacteur. Cela est du au principe même du fonctionnement du contacteur. En effet,le contacteur est composé d'une bobine (entre A1 et A2) qui vient attirer un bloc aimanté de façon à créer un contact entre les six broches de puissance (connecteurs 1 à 6). Le problème était que cette bobine demandait un courant trop important que l'octocoupleur gérait mal en rendant impossible la coupure de la bobine.

Pour palier à ce problème, nous avons choisi d'utiliser une carte de commande d'octocoupleurs commandant des relais (ET-OPTO RELAY4, dont la fiche constructeur est disponible [http://www.micro4you.com/files/ETT/ET-OPTO-RELAY4.pdf ici]). Après vérification à l'aide de la documentation technique des relais, nous avons constaté que ceux-ci sont bien capable de couper la commande des contacteurs.

===Fabrication d'un Shield Arduino===
Nous avons donc été amené à créer un shield Arduino avec une carte de prototypage rapide qui réalise les fonctions suivantes :

* intégrer un connecteur 10 broches compatible pour :
** relier la sortie digitale IO 2 à l'optocoupleur OCT0 qui commandera l'alimentation de la Pompe
** relier la sortie digitale IO 3 à l'optocoupleur OCT1 qui commandera l'alimentation du Chauffe eau
* intégrer le circuit de récupération des impulsions du débitmètre TTL et échantillonner ce signal sur l'entrée digitale IO8
* disposer d'une fonction "Boutons Arrêt d'urgence/Commande manuelle" pour la pompe et le chauffe eau.

===Caractérisation de la pompe===
La pompe récupérée est un composant fabriqué par Invensys, dont la fiche constructeur est disponible à [http://www.toolbox.robertshaw.com/appliance/linkedElements/WaterPumps.pdf cette adresse].
Il s'agit d'une pompe à piston qui permet de délivrer une pression allant jusqu'à 19 bar au maximum. Cette pression est fonction du débit en sortie de la pompe, selon la caractéristique à droite.
[[Fichier:Caractéristique_Pompe_Invensys_CP4.JPG‎|250px|thumb|right|Caractéristique Pression/Débit de la pompe]]

Elle se commande en "tout ou rien" et est alimentée en 230 V alternatif 50Hz.
Le paramètre permettant de fixer le point de fonctionnement sur le graphique précédent est la section du tuyau en sortie. Nous n'avons pas la main sur ce paramètre étant donné que nous possédons déjà le système de tuyaux avec les embouts adaptés de section S = 3 mm². En revanche, nous la commanderons en décidant du temps d'allumage.
Il s'agit maintenant de déterminer à quels moments et combien de temps il faut alimenter la pompe, sachant qu'il faut que l'extraction dure entre 20s et 25s et que le chauffe eau induit un retard à déterminer.

'''Séance pratique :'''

Lors d'une séance de manipulation de la pompe, nous l'avons commandé au moyen de l'Arduino pendant plusieurs durées pré-établies (2s, 5s et 10s) afin de déterminer si elle possède un régime transitoire négligeable. Nous avons ensuite relevé le volume d'eau qu'elle avait délivré grâce à une éprouvette graduée. Plusieurs séries de mesures ont été effectuées à chaque fois.
Lors de cette manip, le tuyau de sortie n'était pas connecté au chauffe-eau afin que la mesure ne soit pas influencée, il donnait directement dans l'éprouvette. Cette manipulation nous a également permis de tester notre débitmètre et notre manière d'échantillonner le signal qu'il nous fournit, en comparant le volume déduit par celui ci et le volume réel relevé avec l'éprouvette.

Ainsi, nous avons déterminé que quelque soit le temps d'allumage (pour une durée supérieure à 2s), la pompe fournit un débit constant de 5,2 mL/s = 0,312 cc/min.

===Étalonnage du capteur de température du chauffe-eau===
Afin de réguler le chauffe eau en température, nous avons besoin de connaître le fonctionnement du capteur de température intégré sur celui ci.
Il s'agit en fait d'une thermistance (résistance variable dont la valeur de la résistance dépend de la température), ici à coefficient de température négatif (CTN).

Il n'y a visiblement pas de référence constructeur dessus. Nous avons donc décidé d'effectuer un étalonnage de celle ci. Il existe un dispositif en salle électronique comportant des capteurs de températures déjà étalonnés disposés sur une plaque qui peut être chauffée par un chauffage électrique. Nous avons "collé" avec de la pâte thermique notre thermistance sur cette plaque et effectué un relevé de la résistance en fonction de la température indiquée par les capteurs déjà présents. Le problème est que le chauffage ne pouvait pas être régulé, il continue de chauffer tant qu'on l'alimente. N'ayant donc pas de valeur de température stabilisée, à cause de l'inertie thermique, les valeurs de résistances relevées sont complètement non significatives.
Cette manipulation aura tout de même soulevé un point à prendre en compte : le capteur de température étant en métal, il faudra déterminer l'inertie qu'il induit dans la mesure et si celle ci est négligeable, sinon, comment faire avec.

Le soucis pour une approximation linéaire est que la plage de température est trop importante. En effet, la température de l'eau pour le café doit être entre 88°C et 90°C, mais on doit aussi pouvoir utiliser le capteur à une température de 65°C pour prévoir un mode "économie d'énergie", lorsque la machine n'est pas utilisée pendant 10min par exemple.
Après recherches, la loi d'évolution de la résistance en fonction de la température est de la forme : <math>{1 \over {T}} = A + B \ln(R_{Th}) + C (\ln(R_{Th}))^3 \,</math>

Autre idée : simplement l'étalonner la thermistance au moyen d'un bain d'eau que l'on peut chauffer et d'une sonde de température précise.

Après relevé de l'évolution de la résistance en fonction de la température au moyen du bain marie, nous avons constaté et vérifié que notre sonde de température se comporte comme une sonde standardisée PT100. Nous avons trouvé une fiche constructeur de ces sondes standardisées qui vérifie les caractéristiques de notre capteur ([http://search.murata.co.jp/Ceramy/CatalogAction.do?sHinnm=?&nbsp&sNHinnm=NCP15WF104D03RC&sNhin_key=NCP15WF104D03RC&sLang=en&sParam=series+U0120L0770S0416A1161 lien]). Sur la plage de température que nous avons besoin d'utiliser (25°C - 105°C), nous pouvons négliger le terme en ln^3, ainsi l'équation régissant la résistance en fonction de la température peut s'exprimer ainsi :
<math>{R_{Th}}={R_0} \times\exp\left(\beta\times\left({1 \over {T}} - {1 \over {T_0}}\right)\right) \,</math> avec <math>{R_0}</math> = 100 kOhm la résistance de référence à <math>T_0</math>= 25°C, <math>\beta</math> = 4334 Kelvin le coefficient fourni par le constructeur pour l'approximation sur la plage 25°C-100°C.

Ainsi, la représentation des données pour récupérer la température est la suivante : au moyen d'un pont diviseur, nous récupérons une tension sur l'Arduino image de la résistance et donc de la température avec la relation ci-dessus.
Nous ne pouvons pas inclure dans le code directement un calcul avec la fonction exponentielle, cela prendrait , entre autres, trop de temps de calcul et ne serait pas optimisé étant donné que l'on connait la résolution du CAN de l'Arduino. Pour cela, nous passons par un tableau de conversion sur 256 valeurs calculé au moyen de cette [https://docs.google.com/spreadsheets/d/185WP8sv1Ryd4hWDlqnpToG-fiC0yVxaIgjR2ey1FG68/edit?usp=sharing feuille de calcul]. Voici un schéma de principe :

Coté Arduino : Tension aux bornes de Rth(V) ---CAN---> Valeur sur 10 bits ---TableauDeConversion---> Valeur sur 8 bits

La Raspberry (ou le PC) récupère ensuite cette valeur sur 8 bits et en déduit la température avec la connaissance du "pas" entre 2 températures : <math>Pas = {(105-25)\over 255}</math>

Coté Raspberry : Valeur sur 8 bits ---> 25 + (Valeur * Pas) ---> Température en °C

Cette méthode permet d'alléger le temps de traitement sur l'Arduino et surtout de ne pas perdre en précision et résolution à cause de la transmission de l'information "température", qui s'effectue sur 8 bits.

===Caractérisation du chauffe eau===
Le chauffe eau que nous avons récupéré est de type thermoblock. Il s'agit en fait d'une résistance chauffante autour de laquelle se situe un serpentin dans lequel l'eau circule, le tout étant isolé dans un châssis en métal.
Les principaux avantages de ce système thermoblock est qu'il conserve très bien la chaleur et qu'il permet de ne chauffer que la quantité d'eau nécessaire, la petite quantité qui passe à l'intérieur. On peut alors considérer l'échange thermique entre le chauffage et l'eau quasi instantané et uniforme. L'inconvénient majeur est en revanche, comme pour tout système thermique, l'inertie thermique importante qu'il possède, notamment due à son corps en métal.

Nous n'avons pas trouvé de données constructeur sur ce chauffe eau. La seule information inscrite est la puissance électrique qu'il absorbe : 1200 W.
Il sera alimenté, comme pour la pompe, en 230V alternatif 50Hz, en tout ou rien. Il s'agit maintenant d'estimer ses caractéristiques (inertie, temps caractéristiques, gains en température en fonction de l'entrée) afin de mettre en place un plan de régulation adapté. Ne possédant aucune information sur ce système, nous ne procéderons pas à une étude théorique thermique qui serait trop approximative compte tenu de la géométrie du système et trop fastidieuse à mettre en place. Nous avons choisi de procéder par identification, en relevant les courbes d'évolution de la température, pour différents temps de commande.

'''Résultats :'''

A chaque fois, la réponse peut s'exprimer de la façon suivante : on constate un temps de retard pur au démarrage dû à l'inertie, puis une évolution s’apparentant à celle d'une réponse à système du 1er ordre. On peut écrire la fonction de transfert du système sous cette forme : <math>H(P) = \frac{K}{1+\tau P} e^{- T_{r} P}</math> (modèle de Broïda)

[[Fichier:Commande_2s.png|350px|vignette|right|upright=1.25|Réponse en température pour 2s d'alimentation]]

[[Fichier:Commande_5s.png|350px|vignette|left|upright=1.25|Réponse en température pour 5s d'alimentation]]

[[Fichier:Commande_10s+pompe.png|350px|vignette|centre|upright=1.25|Réponse en température pour 10s d'alimentation, puis arrivée d'eau à t=75s]]

Remarque : On peut observer sur le 2ème graph l'influence du passage de l'eau dans le thermoblock sur la température. Celui ci se traduit comme une perturbation avec un comportement type 1er ordre sur le thermoblock. Avec ces paramètres (temps, gain), on pourra par la suite estimer la compensation à ajouter afin de maintenir la température du thermoblock constante malgré la chauffe de l'eau.

Ainsi, on peut récapituler ceci dans le tableau suivant :

{| class="wikitable"
|-
! Temps de commande
! Gain en température K
! Temps de retard Tr
! Temps caractéristique <math>\tau</math>
|-
| 2 s
|
|
|
|-
| 5 s
|
|
|
|-
| 10 s
|
|
|
|-
|}

===Détermination du plan de régulation===
Rappelons le cahier des charges de la régulation :

* chauffer l'eau à 90°C, avec comme erreur acceptable +/- 2°C (conformément aux informations recueillies)
* pas de dépassement de la consigne : en effet, le système conservant très bien la chaleur, attendre qu'il se refroidisse serait trop long et surtout, si il y a dépassement après 100°C, on crée un générateur de vapeur... ce qui est bien sûr très dangereux pour le système et pour la sécurité de l'utilisateur
* avoir un temps de réponse acceptable pour l'utilisateur (actuellement, à titre d'exemple, pour la cafetière Nespresso, l'étape de chauffe n'excède en général pas 60s)
* mode économie d'énergie : la machine est destinée à être utilisée publiquement, par des utilisations ponctuelles et pas uniformément réparties dans le temps, il est donc important que la machine ne gaspille pas de l'énergie lorsqu'elle n'est pas utilisée. Ainsi, le bon compromis serait que la température soit maintenue à environ 50°C après 10min d'inutilisation.

'''Choix de la régulation :'''

Ici ne possèdant pas de commande réglable, nous ne pouvons pas choisir une régulation continue de type PID ou prédicteur de Smith, car on commande le thermoblock via un relais. Une commande MLI n'est pas envisageable dans notre cas, à cause du faible "pouvoir de commutation" des contacteurs de puissance que nous avons récupéré. Une simple régulation Tout ou Rien type thermostat ne serait pas suffisante, car ceci engendrerait des dépassements et des oscillations fortes autour de la température de consigne compte tenu du rapport Temps caractéristique sur Temps de retard du système <math>\frac{\tau}{T_{r}} \approx 1,66</math>. Nous nous situons donc dans le cas "Régulation par Boucles multiples" d'après la méthode de Broïda.

[[Fichier:Grafcet_AutoHeat.JPG‎|400px|thumb|right|Grafcet illustrant le principe de l'algorithme de régulation de la température]]
Dans notre cas d'utilisation, un algorithme par boucles multiples, basé sur des commandes Tout ou Rien, est possible et peut satisfaire au cahier des charges. En effet, la consigne ne change pas d'ordre de grandeur : il faudra toujours chauffer l'eau dans un intervalle compris entre 88°C et 92°C. On propose alors l'algorithme suivant :

Principe :
* 1) Chauffe Initiale : Au début de la phase de chauffe, on réalise une chauffe importante (15 s), l'objectif étant d'approcher grossièrement la température auprès de la température de consigne et qu'elle se soit stabilisée (attente de 12s) avant de passer à l'étape de chauffe par palier.
* 2) Chauffe par palier : Il s'agit ici d'effectuer ensuite une succession de "petites" chauffes jusqu'à être dans la plage de température acceptable, tout en tenant compte de l'inertie thermique. Ces successions de chauffe sont définies ici par 2s de chauffe, puis 6s d'attente de l'établissement de la température avant de déterminer si on reste dans la phase Chauffe par palier ou si on entre dans la phase Maintien au chaud. La température de seuil a été déterminée à 82°C, pour prendre en compte le phénomène d'inertie.
* 3) Maintien au chaud : On se situe alors proche ou dans la plage de température. Il s'agit alors d'effectuer des petites chauffes ponctuelles permettant de maintenir la température dans l'intervalle (refroidissement par le milieu ambiant). Cette étape prend également en compte le maintien au chaud lorsque de l'eau passe à travers le chauffe eau et fait donc chuter sa température (compensation plus forte : cycle de 3s de chauffe puis 3s d'attente). On peut, à partir de cette étape, commander la pompe pour élaborer un café si un café a été demandé.

Un avantage de la chauffe palier par palier permet d'attendre que la chaleur s'établisse uniformément dans le thermoblock. Ceci permet de limiter les problèmes d'inerties thermiques, y compris celui de notre capteur (sans mettre ces paliers d'attente, ce que l'on observerait en température ne serait pas nécessairement la température au coeur du thermoblock).

'''Résultats de la régulation'''

[[Fichier:Mode_Auto.png|400px|thumb|right|Evolution de la température du chauffe eau avec la régulation]]

On constate sur le graphique à droite que les 3 étapes de chauffe : les étapes 1 et 2 s'effectuant ici entre 0s et environ 80s puis l'étape de maintien après cette date. La température évolue ainsi de façon presque linéaire pendant les étapes 1 et 2, puis reste dans la plage 88°C-92°C. A t=140s, la pompe est commandée dans cette exemple afin de pouvoir visualiser le maintien en température lorsque l'eau circule. On remarque donc que cette régulation valide les 2 premiers critères du cahier des charges (chauffer l'eau dans la plage et pas de dépassement de cette plage). Cependant, le temps de réponse avant de pouvoir élaborer un café est un peu plus long (environ 80s).

===Réalisation de la carte électronique===
===Construction de la gestion automatique du café===

==Déroulement du projet==
===Avancement des différents objectifs===
Les différents objectifs et leur avancement sont résumés dans le tableau suivant
{| class="wikitable"
|-
! Objectif
! Etat
! Commentaire
|-
! Étalonnage du débitmètre
| Fini
| La documentation est fournie dans le Wiki, et le shield Arduino permet son utilisation
|-
! Analyse du chauffe-eau
| Fini
| Le chauffe-eau est maintenant complètement caractérisé et suit une loi linéaire sur l'intervalle que nous utilisons. Le retard dans la commande ainsi que la commande tout ou rien complexifie grandement son utilisation mais une solution a été trouvée et fonctionne parfaitement, comme indiqué dans le wiki (à rédiger)
|-
! Calibration de la pompe à eau
| Fini
| La documentation est aussi fournie dans le wiki, et le shield Arduino permet son utilisation en temps réel.
|-
! Régulation du chauffe-eau en température
| Fini
| Le modèle équivalent a été déterminé, comme indiqué dans le wiki, et les tests semblent confirmer le bon fonctionnement. Les derniers tests complémentaires ont prouvés que la régulation s'effectue correctement même lors d'un pompage.
|-
! Régulation d’une pompe à eau en pression et en débit
| Fini
| Le comportement de la pompe a été complètement caractérisé et l'utilisation des nouvelles pièces créées au Fabricarium n'engendre pas de perturbations trop importantes.
|-
! Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
| Fini
| L'utilisation d'une carte de puissance couplée avec deux contacteur et un shield arduino réalisé par nos soins rempli parfaitement cet objectif
|-
! Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)
| Fini
| Le shield Arduino que nous avons réalisé permet aussi de lire les différents capteurs
|-
! Programmation de l'Arduino pour commander la carte
| Fini
| Pour finir il est nécessaire d'utiliser deux Arduinos mais tout les deux sont programmés
|-
! Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
| Fini
| La partie NFC est réalisée par un des deux Arduinos, l'interface tactile est encore en cours de réalisation. Bonne nouvelle ! Les tests ont montrés que le temps de réponse entre les Arduinos et le RaspberryPi sont négligeables devant le temps d’échantillonnage. L'écran fonctionne parfaitement et permet de sélectionner la quantité de café désirée.
|-
! Dimensionnement capsule et du dispositif de broyage
| Fini à 80 %
| Les capsules et la chambre de la capsule ont été complètement étudiés. Un système complet à été créé pour ne plus être contraint à l'utilisation du système propriétaire. Trois pièces ont été créé à l'aide du logiciel de CAO Catia. La création de ces pièces en métal est pour le moment impossible (Notre contact aux Arts&Métiers est indisponible, peut-être le responsable des machines-outils de la section mécanique peut nous aider à réaliser certaines pièces). Nous nous sommes rabattus sur la création des pièces en PLA à l'aide de l'imprimante 3D WitBox du fabricarium. Les trois pièces principales sont terminées, ce qui pourrait permettre d'en faire un démonstration. La pièce de liaison est fonctionnelle, ce qui nous permet d'adapter notre tuyau de pompe aux trois pièces précédentes. Par manque de temps, il ne sera pas possible de montrer le fonctionnement automatique des pièces.
|-
! Création d'un système dispenseur de gobelets
| Fini à 0%
| Le système ne sera pas créé par manque de temps.
|}

===La programmation des différents éléments===
Pour la partie programmation, le défi résidait dans le fait de faire communiquer tout les éléments à l'aide d'un seul programme. Pour cela, nous avons subdivisé les fonctions principales dans différents modules. Ceci nous permettait entre autre de minimiser le nombre d'éléments reliés à la partie "puissance" du projet (détaillé plus loin)

Le code source du projet est disponible sur [http://www.github.com GitHub], et les liens vers les différents programmes sont les suivants
{| class="wikitable"
|-
!
! Lien
|-
! Shiled Arduino NFC
| [https://github.com/henyxia/tweekd_nfc]
|-
! Shield Arduino de puissance
| [https://github.com/henyxia/tweekd_hvc]
|-
! Interface en ligne de commande
| [https://github.com/henyxia/tweekd]
|}
====Le Shield Arduino NFC====
L'objectif de l'utilisation du Shield NFC est de permettre à un utilisateur de payer un café, et donc de s'identifier sur la machine, à l'aide de carte Lille 1. Pour cela, nous nous sommes premièrement orientés sur l'utilisation de l'IDE Arduino et de la librairie dédiée au [https://github.com/Seeed-Studio/PN532 PN532]. Puis, nous avons décidé de passer à un langage C pour avoir une meilleure visibilité sur les registres. Par conséquent, nous avons utilisé le compilateur avr-g++ pour compiler le projet. Il nous a donc était nécessaire de transposer une partie des fichiers C et C++ pour les rendre utilisables avec notre programme C.

La communication se fait par système de questions-réponses. Le serveur sur la Raspberry envoie une demande de données, et l'Arduino répond en conséquence. La seule difficulté a résidé dans la problématique des données à envoyer pour l'identification. Les cartes de Lille 1 sont des cartes NFC Mifare Classic 1K. Elles sont composées de 16 secteurs de 4 fois 16 bytes. Le secteur qui nous intéresse est le douzième secteur, qui est encodé en utilisant les clés NFC publiques (donc accessible par tout le monde). Les clés publiques en question sont :

{| class="wikitable"
|-
!
! Clé
|-
! A
| A0A1A2A3A4A5
|-
! B
| B0B1B2B3B4B5
|}

Ce douzième secteur contient, pour les carte étudiantes, l'INE, suivi du numéro étudiant (sur 8 chiffres), suivi du prénom, suivi d'un point puis du nom. Nous avons d'abord envisagé d'utiliser le nom et le prénom, cependant cela posait le problème des personnes avec le même patronymes. De plus, il arrivait que le nom de l'étudiant soit tronqué pour rester dans l'espace alloué au secteur 12. Par conséquent, nous utilisons le numéro d'étudiant, qui est toujours au même endroit sur le secteur. Le logiciel compare alors ce numéro à une liste d'étudiant.

Par soucis de sécurité, nous n'avons pas de liste donnant une correspondance directe entre un numéro d'étudiant et son nom. En effet, la liste utilisée est un enchaînement de nom et de numéro étudiant encodé avec l'algorithme MD5. Pour récupérer le nom, il nous suffit alors de comparer le numéro étudiant que nous récupérons (que nous encodons en MD5) avec la liste. Ceci nous assure une confidentialité relative, dépendante directement de la robustesse de la non réversibilité du MD5.

Une fois la reconnaissance des cartes étudiantes terminées, nous avons essayé de d'inclure les cartes Lille 1 dédiées au personnel. La première question que nous nous sommes posée est comment pouvons nous faire la différence, au niveau du lecteur, entre une carte étudiante et une carte du personnel. Nous avons remarqué que les cartes du personnel comporte, sur leur douzième secteur, deux fois le numéro de personnel (sur 6 chiffres). La répétition du numéro de personnel se situe à l'endroit où se situe le nom de l'étudiant sur la carte de l'étudiant. Le test est donc assez facile à réaliser. L'autre problème est : comment lié un numéro de personnel à un nom ? Nous n'avons pas encore résolu ce problème car cette table de liaison n'est pas accessible à PolytechLille. Éventuellement, si nous arrivons à accomplir tous les objectifs du projet, nous envisagerons de contacter les responsables de Lille 1 pour obtenir cette table de correspondance.

====Le Shield Arduino de puissance====
====L'interface en ligne de commande utilisateur====
Durant les phases de test, nous avons créé une interface en ligne de commande. Celle-ci permettait d'envoyer directement des commandes au HVC, comme l'allumage du chauffe-eau pendant un certain nombre de secondes; ou encore le pompage. Cette interface est restée en utilisation jusqu'à deux semaines avant la fin du projet, car elle nous permettait d'effectuer un suivit très simple de l'état des capteurs. Par la suite, à partir du commit [https://github.com/henyxia/tweekd/commit/ac55328a023270dc55e5e5a99c2bc9a3a1873885 ac55328], nous nous sommes orienté vers l'utilisation de l'écran fournis.

Durant la période où nous utilisions l'interface en ligne de commande, nous nous servions de celle-ci car elle nous fournissait des informations comme le PID. Cette information nous permettait de tuer le programme principal ainsi que tous ces fils lorsque celui ci plantait. Il affichait aussi le volume pompé, la dernière température relevée, l'identifiant lu par le lecteur NFC et la date à laquelle cette lecture s'était produite. Elle affichait aussi les dernières entrées du journal, avec des couleurs indiquant leur niveau d'importance (Debug, Info, Warning ou Error).

INSERER UNE IMAGE DE L'INTERFACE ICI

====L'interface utilisateur finale====
Pour l'interface utilisateur finale, nous nous reposons sur un module d'affichage [http://www.robopeak.com/docs/doku.php?id=product-rpusbdisp RPUSBDisp] de la société RoboPeak. Avant de se lancer dans la phase de programmation de l'interface, il nous a d'abord fallut rendre utilisable l'écran par le RaspberryPi. Pour cela, il a fallut créer un module chargeable par le noyau Linux. Une fois ce module créé, nous nous sommes rendu compte le noyau Linux que nous utilisions (celui fournis avec Raspbian) ne contenait pas les symboles nécessaires au chargement du module. Nous avons alors recompilé le noyau Linux avec les symboles manquants. La compilation s'est avérée assez compliquée car pour éviter de faire de la cross compilation (ce qui aurait surement augmenter le taux d'échec de compilation) nous avons compilé le noyau directement à partir de la RaspberryPi ce qui, malgré son overclooking, était très long (une compilation prenait approximativement une nuit complète). Après quatre tentatives, nous avons réussi à obtenir un noyau fonctionnel.

[[Fichier:RPUSBDisp1.jpg|200px|thumb|right|Premier BMP affiché avec succès sur l'écran]] Une fois l'écran utilisable, nous nous sommes lancés dans le développement de l'interface. Nous avons choisi, dans une optique de performance, de n'utiliser que la librairie X11. Le premier objectif était de réussir à afficher une image sur l'écran. Le format d'image utilisé était le BMP car il n'est pas compressé et peut être lu sans autres calculs. Après de petits cafouillages (liés au fait que le BMP représente une couleur de 0 à 255 et X11 de 0 à 65535) nous avons réussi à faire afficher notre première image. Cependant, le point négatif est que l'image est affichée en une trentaine de secondes. Nous sommes donc en train de travailler sur un moyen de faire afficher des images plus rapidement.

Après de longues recherches, nous nous sommes rendus compte qu'il n'était pas possible de réaliser une interface temps réel avec cet écran si l'on utilisait la librairie X11. En effet, celle ne communique pas assez rapidement avec l'écran (les recordes d'écriture étant de ~17 secondes par images avec X11). Le constructeur préconise en fait une utilisation à travers une interface USB. Cette interface, décrite dans ce [http://www.robopeak.com/data/doc/rpusbdisp/RPUD03-rpusbdisp_interface_protocol-enUS.1.0.pdf manuel] nous oblige à réécrire notre interface homme machine.

[[Fichier:RGB565.gif|320px|thumb|left|Représentation des données en RGB565]] Le [https://github.com/henyxia/tweekd_gui/blob/master/main.c lien suivant] est une démonstration de la première commande que nous avons réussi à envoyer à travers la librairie USB. Nous avons ensuite essayé d'afficher une image sur l'écran. Pour cela, il a été nécessaire de créer un type de fichier intermédiaire car l'écran n'est pas capable de lire la plupart des formats d'images classiques. Pour rendre la conversion plus simple, nous avons choisi le type BMP comme fichier image source. Le type BMP organise la description des images de façon simple. Le fichier commence par une en-tête qui comporte des informations comme l'adresse de début de l'image, le nombre de bits par pixel et d'autres informations qui ne nous servent pas. Une fois ces deux informations récupérés (nous n'utilisons que des images à 24 bits par pixel, soit 8 b bits pour le rouge, 8 bits pour le vert et 8 bits pour le bleu) nous convertissons notre image dans le format lisible par l'écran, qui est le RGB565. Ce format compresse (avec pertes) la précision des couleurs pour que celle-ci soit ordonnée avec 5 bits pour le rouge, 6 bits pour le vert et 5 bits pour le bleu. Nous rendre plus pratique cette conversion, nous avons créé un [https://github.com/henyxia/bmp2rgb565 programme] permettant l'automatisation de ce processus. Une fois ce programme utilisé (à travers le Makefile du projet principal), l'image est envoyé à l'écran. Après chronométrage, nous arrivons à un temps moyen de 1,2 secondes pour afficher une image intégralement. Ce temps est bien supérieur aux 17 secondes de la librairie X11, mais est aussi légèrement éloigné des 25 images par secondes promises par le vendeur (Ce taux de rafraîchissement n'étant atteignable que si nous ne générons des carrés de couleurs). Cependant ce temps de réponse est largement suffisant pour l'utilisation que nous souhaitons en faire.

Nous nous sommes donc penché sur l'utilisation de l'interface tactile de l'écran. C'est une lecture USB par interruption qui nous donne si l'écran est actuellement pressé, et si oui où la pression est effectuée. Donc, pour permettre au programme de comprendre quelle fonction appeler lors d'un appuie sur l'écran, nous créé un autre format de fichier. Celui ci, aussi issu du BMP, est une liste de pixel en nuance de gris. Donc, chaque pixel est représenté par une valeur comprise entre 0 et 255. En fonction de la valeur, le programme principal appelle la fonction en conséquence. De façon analogue à la conversion de BMP et RGB565, nous avons créé un programme permettant de convertir les BMP en suite de bytes correspondant aux pixels. Ce programme ce trouve à [https://github.com/henyxia/bmp2map l'adresse suivante].

==Conclusion==
===Vidéo de présentation===
Nous pensons enregistrer la vidéo pendant les vacances à l'aide d'une caméra professionnelle.

Fichier:Mode Auto.png

2015-05-10T20:12:51Z

Pletouse :

Fichier:Grafcet AutoHeat.JPG

2015-05-10T16:27:39Z

Pletouse :

Thetweekproject

2015-05-06T19:28:50Z

Pletouse : /* Détermination du schéma de fonctionnement et du plan de régulation */ Rappel cahier des charges + Ajout choix de régulation

=Machine à café=
==Présentation du projet==
===Cahier des charges===
SA
* Broyage des grains déjà torréfiés
** Régulation d’un moteur en vitesse avec charge variable
** Réutilisation des éléments d’une cafetière existante (carte électronique hors d’usage)
*** Étalonnage du débitmètre
*** Analyse du chauffe-eau
*** Calibration de la pompe à eau
** Propulsion de l’eau chauffée
*** Régulation d’une pompe à eau en pression et en débit
*** Régulation du chauffe-eau en température
** Modélisation des éléments du système
SC
* Création d’une interface homme-machine
** Installation d’un RaspberryPi avec un écran tactile
*** Gestion des stocks de café, d’eau et de gobelets
*** Gestion des différents éléments (pompe, compresseur, chauffe eau, …)
** Réalisation d’une interface graphique permettant de :
* Moudre le café
* Sélectionner la quantité d’eau à distribuer (café court ou long)
* Sélectionner un café parmi une présélection de café
** Création d’une application Web et Smartphone
*** Possibilité de noter son café
*** Possibilité de retenir un choix de café particulier
* Création de profils créés à partir de la carte étudiante
** Lecture d’information en NFC sur la carte étudiante
** Création d’une base de données basée sur ces profils
*** Proposition des cafés à partir de ceux les plus commandés et/ou mieux notés
*** Possibilité de retenir certains choix et de les recommander

Commun
* Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
* Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)

===Liste des tâches===
*Caractériser le débitmètre
*Caractériser le chauffe-eau
*Caractériser la pompe
*Détermination du schéma de fonctionnement et éventuels correctifs de régulation
*Réalisation de la carte électronique de commande
*Programmation de l'Arduino pour commander la carte
*Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
**Estimation temps de réponse (temps de transfert à l'Arduino négligeable ?)
*Gestion automatique du café
**Dimensionnement capsule et du dispositif de broyage
**Création d'un système dispenseur de gobelets
***Design d'engrenages pour les gobelets
*Plus de fonctionnalités si temps restant
**Recharge par le Net
**Poison pour diabétique
**Interface beaucoup travaillée
**Packaging pratique

===Matériel disponible===

*Machine à café Nespresso défectueuse en morceaux [fournie en 2014]
**Un débitmètre
**Une pompe à eau
**Un chauffe-eau
**Tubes
**Carte électronique (très sûrement défectueuse)
**Mécanisme d'infusion de capsules de café
**Réservoir d'eau avec valve anti-retour

*Matériel électro-informatique
**Arduino Uno [fourni le 26/1/2015]
**Arduino Léonardo [fourni le 5/2/2015]
**RaspberryPi [http://www.adafruit.com/products/998] [fourni le 28/1/2015]
**Carte SD 16G [fournie le 29/1/2015]
**Capteur de température [http://fr.rs-online.com/web/p/capteurs-de-temperature-et-humidite/0264147/] [fourni le 4/2/2015]
**Thermocouple [http://fr.rs-online.com/web/p/thermocouples/6212287/] [fourni le 4/2/2015]
**Lecteur NFC [http://www.adafruit.com/product/364] [fourni le 4/2/2015]
**Ecran tactile [http://www.gotronic.fr/art-afficheur-tactile-usb-2-8-dfr0275-21547.htm] [fourni le 18/03/2015]

*Matériel électronique de puissance
**Contacteurs de puissance (max 32A, 400V) (x2)
**Coffrets d'isolation électrique (x2) (achetés le 09/02/2015)
**Cables électriques (section 2,5 mm2) (achetés le 09/02/2015)
**Boitier interrupteur (achetés le 09/02/2015)

===Matériel manquant===

*Broyeur de café [http://www.maxicoffee.com/moulin-cafe-inoxnoir-gvx2-krups-p-9323-3_68.html?osCsid=e4t6v05n7lctvtod3ehggr0g05]

===Répartition du travail===
{| class="wikitable alternance centre"
|+ Titre
|-
|
! scope="col" | Lundi 14-16h
! scope="col" | Mercredi 14-18h
! scope="col" | Jeudi 10-12h
|-
! scope="row" | Semaine 5
| 26/01 - Organisation et répartition du projet
| 28/01 - Caractériser le débitmètre et gérer les pièces manquantes
| 29/01 - Caractériser le chauffe eau et la pompe
|-
! scope="row" | Semaine 6
| 02/02 - Détermination du schéma de fonctionnement et du plan de régulation
| 04/02 - Réalisation de la carte électronique
| 05/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 7
| 09/02 - Réalisation de la carte électronique
| 11/02 - Réalisation de la carte électronique
| 12/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 8
| 16/02 - Gestion automatique du café
| 18/02 - Gestion automatique du café
| 19/02 - Gestion automatique du café
|-
! scope="row" | Semaine 9
| 23/02 - Gestion automatique du café
| 25/02 - Gestion automatique du café
| 26/02 - Gestion automatique du café
|-
! scope="row" | Semaine 11
| 09/03 - Gestion automatique du café
| 11/03 - Gestion automatique du café
| 12/03 - Gestion automatique du café
|-
! scope="row" | Semaine 12
| 16/03 - Gestion automatique du café
| 18/03 - Gestion automatique du café
| 19/03 - Gestion automatique du café
|-
! scope="row" | Semaine 13
| 23/03 - Gestion automatique du café
| 25/03 - Gestion automatique du café
| 26/03 - Gestion automatique du café
|-
! scope="row" | Semaine 14
| 30/03 - Gestion automatique du café
| 01/04 - Gestion automatique du café
| 02/04 - Gestion automatique du café
|-
! scope="row" | Semaine 15
| Férié
| 08/04 - Gestion automatique du café
| 09/04 - Gestion automatique du café
|-
! scope="row" | Semaine 16
| 13/04 - Gestion automatique du café
| 15/04 - Gestion automatique du café
| 16/04 - Gestion automatique du café
|-
! scope="row" | Semaine 17
| 20/04 - Gestion automatique du café
| 22/04 - Gestion automatique du café
| 23/04 - Gestion automatique du café
|}

En somme, les prévisions pour les différentes parties sont de:
*8 H pour la prise en main du matériel actuel
*14 H pour la réalisation de la carte électronique de commande
*70 H pour la gestion automatique du café

==Etude préalable==
===Caractérisation du débitmètre===
Lors de la première séance "pratique", nous avons étudié le comportement du débitmètre.

Après recherches, nous avons appris qu'il en existe deux types. Le premier type est assimilable à une résistance variable dont la valeur dépend du débit. Le deuxième type se comporte comme un type tout ou rien qui effectue un contact entre deux des pins lorsque l'ailette interne fait un tour. Le débit est donc déduit par la fréquence des impulsions que délivre le débitmètre.

Notre débitmètre est un composant crée par Digmesa, dont la fiche constructeur est disponible [http://www.pollin.de/shop/downloads/D180051D.PDF ici]. Il s'agit d'un débitmètre à turbine, du deuxième type.

Le montage à droite permet de récupérer les impulsions du débitmètre sous forme TTL.

[[Fichier:Schéma_Montage_Débitmètre.JPG|250px|thumb|right|Schéma du montage permettant de récupérer les impulsions du débitmètre]]

Le volume d'eau mesuré s'exprime alors sous cette forme : <math>V = n * \frac{1}{Kdeb}</math> avec n le nombre d'impulsions, V le volume en L et Kdeb la constante fournie dans la doc constructeur Kdeb = 1925 impulsions/L.

Le débit n'est pas une grandeur mesurée directement avec notre débitmètre, mais elle est déduite en choisissant un temps <math>\Delta t</math> suffisamment court pour considérer le débit "instantané".
L'expression du débit "pseudo-instantané" est alors la suivante : <math>\frac{\Delta V}{\Delta t} = \frac{1}{Kdeb} * \frac{\Delta n}{\Delta t} </math> avec <math>\Delta n</math> la variation du nombre d'impulsion pendant le <math>\Delta t</math>.

Obtenir le débit est ici utile car, d'après les informations collectées, le temps d'extraction du café doit être contrôlé (entre 20s à 25s) et le café doit être de 5cl pour un ristretto et de 12cl pour un lungo.

Il est important de noter aussi que ce capteur a une influence sur la pression : en effet, il peut induire une perte de pression (au maximum) de 0,43 bar.

===Réalisation interface commande - puissance===
Afin de pouvoir séparer circuit de commande et alimentation de puissance, nous utiliserons un optocoupleur et des contacteurs pour l'alimentation de la pompe et du chauffe-eau (tout deux alimentés en 230V alternatif 50 Hz). L'optocoupleur est utilisé afin de bénéficier d'une isolation galvanique entre les deux parties, pour plus de sécurité.

La commande d'alimentation est envoyée par l'Arduino à l'optocoupleur. L'optocoupleur commande alors le contacteur (relais de puissance), ce qui alimente l'élément choisi.

L'optocoupleur utilisé est sous forme de circuit "prêt à utiliser" (ET-OPTO AC-OUT 4 dont la fiche constructeur est disponible [http://www.tellab.it/open2b/var/catalog/product/files/57.pdf ici]) qui dispose de quatre optocoupleurs isolés. Nous en utiliserons un pour commander la pompe (OCT0) et un deuxième pour commander le chauffe-eau (OCT1). L'objectif d'une des séances a été d'établir ce dispositif d'alimentation, de comprendre le fonctionnement de l'optocoupleur dont nous disposons et de mapper les optocoupleurs aux sorties de l'Arduino.

Par la suite, nous avons été contraint de changer de type de commande. En effet, la carte d'octocoupleurs permettait la commande mais n'était pas capable de couper le contacteur. Cela est du au principe même du fonctionnement du contacteur. En effet,le contacteur est composé d'une bobine (entre A1 et A2) qui vient attirer un bloc aimanté de façon à créer un contact entre les six broches de puissance (connecteurs 1 à 6). Le problème était que cette bobine demandait un courant trop important que l'octocoupleur gérait mal en rendant impossible la coupure de la bobine.

Pour palier à ce problème, nous avons choisi d'utiliser une carte de commande d'octocoupleurs commandant des relais (ET-OPTO RELAY4, dont la fiche constructeur est disponible [http://www.micro4you.com/files/ETT/ET-OPTO-RELAY4.pdf ici]). Après vérification à l'aide de la documentation technique des relais, nous avons constaté que ceux-ci sont bien capable de couper la commande des contacteurs.

===Fabrication d'un Shield Arduino===
Nous avons donc été amené à créer un shield Arduino avec une carte de prototypage rapide qui réalise les fonctions suivantes :

* intégrer un connecteur 10 broches compatible pour :
** relier la sortie digitale IO 2 à l'optocoupleur OCT0 qui commandera l'alimentation de la Pompe
** relier la sortie digitale IO 3 à l'optocoupleur OCT1 qui commandera l'alimentation du Chauffe eau
* intégrer le circuit de récupération des impulsions du débitmètre TTL et échantillonner ce signal sur l'entrée digitale IO8
* disposer d'une fonction "Boutons Arrêt d'urgence/Commande manuelle" pour la pompe et le chauffe eau.

===Caractérisation de la pompe===
La pompe récupérée est un composant fabriqué par Invensys, dont la fiche constructeur est disponible à [http://www.toolbox.robertshaw.com/appliance/linkedElements/WaterPumps.pdf cette adresse].
Il s'agit d'une pompe à piston qui permet de délivrer une pression allant jusqu'à 19 bar au maximum. Cette pression est fonction du débit en sortie de la pompe, selon la caractéristique à droite.
[[Fichier:Caractéristique_Pompe_Invensys_CP4.JPG‎|250px|thumb|right|Caractéristique Pression/Débit de la pompe]]

Elle se commande en "tout ou rien" et est alimentée en 230 V alternatif 50Hz.
Le paramètre permettant de fixer le point de fonctionnement sur le graphique précédent est la section du tuyau en sortie. Nous n'avons pas la main sur ce paramètre étant donné que nous possédons déjà le système de tuyaux avec les embouts adaptés de section S = 3 mm². En revanche, nous la commanderons en décidant du temps d'allumage.
Il s'agit maintenant de déterminer à quels moments et combien de temps il faut alimenter la pompe, sachant qu'il faut que l'extraction dure entre 20s et 25s et que le chauffe eau induit un retard à déterminer.

'''Séance pratique :'''

Lors d'une séance de manipulation de la pompe, nous l'avons commandé au moyen de l'Arduino pendant plusieurs durées pré-établies (2s, 5s et 10s) afin de déterminer si elle possède un régime transitoire négligeable. Nous avons ensuite relevé le volume d'eau qu'elle avait délivré grâce à une éprouvette graduée. Plusieurs séries de mesures ont été effectuées à chaque fois.
Lors de cette manip, le tuyau de sortie n'était pas connecté au chauffe-eau afin que la mesure ne soit pas influencée, il donnait directement dans l'éprouvette. Cette manipulation nous a également permis de tester notre débitmètre et notre manière d'échantillonner le signal qu'il nous fournit, en comparant le volume déduit par celui ci et le volume réel relevé avec l'éprouvette.

Ainsi, nous avons déterminé que quelque soit le temps d'allumage (pour une durée supérieure à 2s), la pompe fournit un débit constant de 5,2 mL/s = 0,312 cc/min.

===Étalonnage du capteur de température du chauffe-eau===
Afin de réguler le chauffe eau en température, nous avons besoin de connaître le fonctionnement du capteur de température intégré sur celui ci.
Il s'agit en fait d'une thermistance (résistance variable dont la valeur de la résistance dépend de la température), ici à coefficient de température négatif (CTN).

Il n'y a visiblement pas de référence constructeur dessus. Nous avons donc décidé d'effectuer un étalonnage de celle ci. Il existe un dispositif en salle électronique comportant des capteurs de températures déjà étalonnés disposés sur une plaque qui peut être chauffée par un chauffage électrique. Nous avons "collé" avec de la pâte thermique notre thermistance sur cette plaque et effectué un relevé de la résistance en fonction de la température indiquée par les capteurs déjà présents. Le problème est que le chauffage ne pouvait pas être régulé, il continue de chauffer tant qu'on l'alimente. N'ayant donc pas de valeur de température stabilisée, à cause de l'inertie thermique, les valeurs de résistances relevées sont complètement non significatives.
Cette manipulation aura tout de même soulevé un point à prendre en compte : le capteur de température étant en métal, il faudra déterminer l'inertie qu'il induit dans la mesure et si celle ci est négligeable, sinon, comment faire avec.

Le soucis pour une approximation linéaire est que la plage de température est trop importante. En effet, la température de l'eau pour le café doit être entre 88°C et 90°C, mais on doit aussi pouvoir utiliser le capteur à une température de 65°C pour prévoir un mode "économie d'énergie", lorsque la machine n'est pas utilisée pendant 10min par exemple.
Après recherches, la loi d'évolution de la résistance en fonction de la température est de la forme : <math>{1 \over {T}} = A + B \ln(R_{Th}) + C (\ln(R_{Th}))^3 \,</math>

Autre idée : simplement l'étalonner la thermistance au moyen d'un bain d'eau que l'on peut chauffer et d'une sonde de température précise.

Après relevé de l'évolution de la résistance en fonction de la température au moyen du bain marie, nous avons constaté et vérifié que notre sonde de température se comporte comme une sonde standardisée PT100. Nous avons trouvé une fiche constructeur de ces sondes standardisées qui vérifie les caractéristiques de notre capteur ([http://search.murata.co.jp/Ceramy/CatalogAction.do?sHinnm=?&nbsp&sNHinnm=NCP15WF104D03RC&sNhin_key=NCP15WF104D03RC&sLang=en&sParam=series+U0120L0770S0416A1161 lien]). Sur la plage de température que nous avons besoin d'utiliser (25°C - 105°C), nous pouvons négliger le terme en ln^3, ainsi l'équation régissant la résistance en fonction de la température peut s'exprimer ainsi :
<math>{R_{Th}}={R_0} \times\exp\left(\beta\times\left({1 \over {T}} - {1 \over {T_0}}\right)\right) \,</math> avec <math>{R_0}</math> = 100 kOhm la résistance de référence à <math>T_0</math>= 25°C, <math>\beta</math> = 4334 Kelvin le coefficient fourni par le constructeur pour l'approximation sur la plage 25°C-100°C.

Ainsi, la représentation des données pour récupérer la température est la suivante : au moyen d'un pont diviseur, nous récupérons une tension sur l'Arduino image de la résistance et donc de la température avec la relation ci-dessus.
Nous ne pouvons pas inclure dans le code directement un calcul avec la fonction exponentielle, cela prendrait , entre autres, trop de temps de calcul et ne serait pas optimisé étant donné que l'on connait la résolution du CAN de l'Arduino. Pour cela, nous passons par un tableau de conversion sur 256 valeurs calculé au moyen de cette [https://docs.google.com/spreadsheets/d/185WP8sv1Ryd4hWDlqnpToG-fiC0yVxaIgjR2ey1FG68/edit?usp=sharing feuille de calcul]. Voici un schéma de principe :

Coté Arduino : Tension aux bornes de Rth(V) ---CAN---> Valeur sur 10 bits ---TableauDeConversion---> Valeur sur 8 bits

La Raspberry (ou le PC) récupère ensuite cette valeur sur 8 bits et en déduit la température avec la connaissance du "pas" entre 2 températures : <math>Pas = {(105-25)\over 255}</math>

Coté Raspberry : Valeur sur 8 bits ---> 25 + (Valeur * Pas) ---> Température en °C

Cette méthode permet d'alléger le temps de traitement sur l'Arduino et surtout de ne pas perdre en précision et résolution à cause de la transmission de l'information "température", qui s'effectue sur 8 bits.

===Caractérisation du chauffe eau===
Le chauffe eau que nous avons récupéré est de type thermoblock. Il s'agit en fait d'une résistance chauffante autour de laquelle se situe un serpentin dans lequel l'eau circule, le tout étant isolé dans un châssis en métal.
Les principaux avantages de ce système thermoblock est qu'il conserve très bien la chaleur et qu'il permet de ne chauffer que la quantité d'eau nécessaire, la petite quantité qui passe à l'intérieur. On peut alors considérer l'échange thermique entre le chauffage et l'eau quasi instantané et uniforme. L'inconvénient majeur est en revanche, comme pour tout système thermique, l'inertie thermique importante qu'il possède, notamment due à son corps en métal.

Nous n'avons pas trouvé de données constructeur sur ce chauffe eau. La seule information inscrite est la puissance électrique qu'il absorbe : 1200 W.
Il sera alimenté, comme pour la pompe, en 230V alternatif 50Hz, en tout ou rien. Il s'agit maintenant d'estimer ses caractéristiques (inertie, temps caractéristiques, gains en température en fonction de l'entrée) afin de mettre en place un plan de régulation adapté. Ne possédant aucune information sur ce système, nous ne procéderons pas à une étude théorique thermique qui serait trop approximative compte tenu de la géométrie du système et trop fastidieuse à mettre en place. Nous avons choisi de procéder par identification, en relevant les courbes d'évolution de la température, pour différents temps de commande.

'''Résultats :'''

A chaque fois, la réponse peut s'exprimer de la façon suivante : on constate un temps de retard pur au démarrage dû à l'inertie, puis une évolution s’apparentant à celle d'une réponse à système du 1er ordre. On peut écrire la fonction de transfert du système sous cette forme : <math>H(P) = \frac{K}{1+\tau P} e^{- T_{r} P}</math> (modèle de Broïda)

[[Fichier:Commande_2s.png|350px|vignette|right|upright=1.25|Réponse en température pour 2s d'alimentation]]

[[Fichier:Commande_5s.png|350px|vignette|left|upright=1.25|Réponse en température pour 5s d'alimentation]]

[[Fichier:Commande_10s+pompe.png|350px|vignette|centre|upright=1.25|Réponse en température pour 10s d'alimentation, puis arrivée d'eau à t=75s]]

Remarque : On peut observer sur le 2ème graph l'influence du passage de l'eau dans le thermoblock sur la température. Celui ci se traduit comme une perturbation avec un comportement type 1er ordre sur le thermoblock. Avec ces paramètres (temps, gain), on pourra par la suite estimer la compensation à ajouter afin de maintenir la température du thermoblock constante malgré la chauffe de l'eau.

Ainsi, on peut récapituler ceci dans le tableau suivant :

{| class="wikitable"
|-
! Temps de commande
! Gain en température K
! Temps de retard Tr
! Temps caractéristique <math>\tau</math>
|-
| 2 s
|
|
|
|-
| 5 s
|
|
|
|-
| 10 s
|
|
|
|-
|}

===Détermination du plan de régulation===
Rappelons le cahier des charges de la régulation :

* chauffer l'eau à 90°C, avec comme erreur acceptable +/- 2°C (conformément aux informations recueillies)
* pas de dépassement de la consigne : en effet, le système conservant très bien la chaleur, attendre qu'il se refroidisse serait trop long et surtout, si il y a dépassement après 100°C, on crée un générateur de vapeur... ce qui est bien sûr très dangereux pour le système et pour la sécurité de l'utilisateur
* avoir un temps de réponse acceptable pour l'utilisateur (actuellement, à titre d'exemple, pour la cafetière Nespresso, l'étape de chauffe n'excède en général pas 60s)
* mode économie d'énergie : la machine est destinée à être utilisée publiquement, par des utilisations ponctuelles et pas uniformément réparties dans le temps, il est donc important que la machine ne gaspille pas de l'énergie lorsqu'elle n'est pas utilisée. Ainsi, le bon compromis serait que la température soit maintenue à environ 50°C après 10min d'inutilisation.

'''Choix de la régulation :'''

Ici ne possèdant pas de commande réglable, nous ne pouvons pas choisir une régulation continue de type PID ou prédicteur de Smith, car on commande le thermoblock via un relais. Une commande MLI n'est pas envisageable dans notre cas, à cause du faible "pouvoir de commutation" des contacteurs de puissance que nous avons récupéré. Une simple régulation Tout ou Rien type thermostat ne serait pas suffisante, car ceci engendrerait des dépassements et des oscillations fortes autour de la température de consigne compte tenu du rapport Temps caractéristique sur Temps de retard du système <math>\frac{\tau}{T_{r}} \approx 1,66</math>. Nous nous situons donc dans le cas "Régulation par Boucles multiples" d'après la méthode de Broïda.

Un algorithme basé sur des alimentations Tout ou Rien est suffisant ici. En effet, la consigne ne change pas d'ordre de grandeur : il faudra toujours chauffer l'eau dans un intervalle compris entre 88°C et 92°C. On propose alors l'algorithme suivant :
''insérer image grafcet''

Principe :

Avantage : chauffer palier par palier permet d'attendre que la chaleur s'établisse uniformément dans le thermoblock. Ceci permet de limiter très fortement le problème d'inertie thermique de notre capteur (sans mettre ces paliers d'attente, ce que l'on observerait en température ne serait pas nécessairement la température au coeur du thermoblock)

===Réalisation de la carte électronique===
===Construction de la gestion automatique du café===

==Déroulement du projet==
===Avancement des différents objectifs===
Les différents objectifs et leur avancement sont résumés dans le tableau suivant
{| class="wikitable"
|-
! Objectif
! Etat
! Commentaire
|-
! Étalonnage du débitmètre
| Fini
| La documentation est fournie dans le Wiki, et le shield Arduino permet son utilisation
|-
! Analyse du chauffe-eau
| Fini
| Le chauffe-eau est maintenant complètement caractérisé et suit une loi linéaire sur l'intervalle que nous utilisons. Le retard dans la commande ainsi que la commande tout ou rien complexifie grandement son utilisation mais une solution a été trouvée et fonctionne parfaitement, comme indiqué dans le wiki (à rédiger)
|-
! Calibration de la pompe à eau
| Fini
| La documentation est aussi fournie dans le wiki, et le shield Arduino permet son utilisation en temps réel.
|-
! Régulation du chauffe-eau en température
| Terminé à 90 %
| Le modèle équivalent a été déterminé, comme indiqué dans le wiki (à rédiger), et les tests semblent confirmer le bon fonctionnement. Il manque encore quelques tests pour que la régulation soit totalement validée.
|-
! Régulation d’une pompe à eau en pression et en débit
| Terminé à 50 %
| Le comportement de la pompe a été complétement caractérisé mais l'utilisation des nouvelles pièces créées au Fabricarium risque d'engendrer une augmentation de la pression et donc un modèle à redéfinir.
|-
! Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
| Fini
| L'utilisation d'une carte de puissance couplée avec deux contacteur et un shield arduino réalisé par nos soins rempli parfaitement cet objectif
|-
! Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)
| Fini
| Le shield Arduino que nous avons réalisé permet aussi de lire les différents capteurs
|-
! Programmation de l'Arduino pour commander la carte
| Fini
| Pour finir il est nécessaire d'utiliser deux Arduinos mais tout les deux sont programmés
|-
! Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
| Fini à 60 %
| La partie NFC est réalisée par un des deux Arduinos, l'interface tactile est encore en cours de réalisation. Bonne nouvelle ! Les tests ont montrés que le temps de réponse entre les Arduinos et le RaspberryPi sont négligeables devant le temps d’échantillonnage.
|-
! Dimensionnement capsule et du dispositif de broyage
| Fini à 80 %
| Les capsules et la chambre de la capsule ont été complètement étudiés. Un système complet à été créé pour ne plus être contraint à l'utilisation du système propriétaire. Trois pièces ont été créé à l'aide du logiciel de CAO Catia. La création de ces pièces en métal est pour le moment impossible (Notre contact aux Arts&Métiers est indisponible, peut-être le responsable des machines-outils de la section mécanique peut nous aider à réaliser certaines pièces). Nous nous sommes rabattus sur la création des pièces en PLA à l'aide de l'imprimante 3D WitBox du fabricarium. Les trois pièces principales sont terminées, ce qui pourrait permettre d'en faire un démonstration. La pièce de liaison est fonctionnelle, ce qui nous permet d'adapter notre tuyau de pompe aux trois pièces précédentes.
|-
! Création d'un système dispenseur de gobelets
| Fini à 0%
| Le système n'est pas encore créé
|}

===La programmation des différents éléments===
Pour la partie programmation, le défi résidait dans le fait de faire communiquer tout les éléments à l'aide d'un seul programme. Pour cela, nous avons subdivisé les fonctions principales dans différents modules. Ceci nous permettait entre autre de minimiser le nombre d'éléments reliés à la partie "puissance" du projet (détaillé plus loin)

Le code source du projet est disponible sur [http://www.github.com GitHub], et les liens vers les différents programmes sont les suivants
{| class="wikitable"
|-
!
! Lien
|-
! Shiled Arduino NFC
| [https://github.com/henyxia/tweekd_nfc]
|-
! Shield Arduino de puissance
| [https://github.com/henyxia/tweekd_hvc]
|-
! Interface en ligne de commande
| [https://github.com/henyxia/tweekd]
|-
! Interface graphique finale
| [https://github.com/henyxia/tweekd_gui]
|}
====Le Shield Arduino NFC====
L'objectif de l'utilisation du Shield NFC est de permettre à un utilisateur de payer un café, et donc de s'identifier sur la machine, à l'aide de carte Lille 1. Pour cela, nous nous sommes premièrement orientés sur l'utilisation de l'IDE Arduino et de la librairie dédiée au [https://github.com/Seeed-Studio/PN532 PN532]. Puis, nous avons décidé de passer à un langage C pour avoir une meilleure visibilité sur les registres. Par conséquent, nous avons utilisé le compilateur avr-g++ pour compiler le projet. Il nous a donc était nécessaire de transposer une partie des fichiers C et C++ pour les rendre utilisables avec notre programme C.

La communication se fait par système de questions-réponses. Le serveur sur la Raspberry envoie une demande de données, et l'Arduino répond en conséquence. La seule difficulté a résidé dans la problématique des données à envoyer pour l'identification. Les cartes de Lille 1 sont des cartes NFC Mifare Classic 1K. Elles sont composées de 16 secteurs de 4 fois 16 bytes. Le secteur qui nous intéresse est le douzième secteur, qui est encodé en utilisant les clés NFC publiques (donc accessible par tout le monde). Les clés publiques en question sont :

{| class="wikitable"
|-
!
! Clé
|-
! A
| A0A1A2A3A4A5
|-
! B
| B0B1B2B3B4B5
|}

Ce douzième secteur contient, pour les carte étudiantes, l'INE, suivi du numéro étudiant (sur 8 chiffres), suivi du prénom, suivi d'un point puis du nom. Nous avons d'abord envisagé d'utiliser le nom et le prénom, cependant cela posait le problème des personnes avec le même patronymes. De plus, il arrivait que le nom de l'étudiant soit tronqué pour rester dans l'espace alloué au secteur 12. Par conséquent, nous utilisons le numéro d'étudiant, qui est toujours au même endroit sur le secteur. Le logiciel compare alors ce numéro à une liste d'étudiant.

Par soucis de sécurité, nous n'avons pas de liste donnant une correspondance directe entre un numéro d'étudiant et son nom. En effet, la liste utilisée est un enchaînement de nom et de numéro étudiant encodé avec l'algorithme MD5. Pour récupérer le nom, il nous suffit alors de comparer le numéro étudiant que nous récupérons (que nous encodons en MD5) avec la liste. Ceci nous assure une confidentialité relative, dépendante directement de la robustesse de la non réversibilité du MD5.

Une fois la reconnaissance des cartes étudiantes terminées, nous avons essayé de d'inclure les cartes Lille 1 dédiées au personnel. La première question que nous nous sommes posée est comment pouvons nous faire la différence, au niveau du lecteur, entre une carte étudiante et une carte du personnel. Nous avons remarqué que les cartes du personnel comporte, sur leur douzième secteur, deux fois le numéro de personnel (sur 6 chiffres). La répétition du numéro de personnel se situe à l'endroit où se situe le nom de l'étudiant sur la carte de l'étudiant. Le test est donc assez facile à réaliser. L'autre problème est : comment lié un numéro de personnel à un nom ? Nous n'avons pas encore résolu ce problème car cette table de liaison n'est pas accessible à PolytechLille. Éventuellement, si nous arrivons à accomplir tous les objectifs du projet, nous envisagerons de contacter les responsables de Lille 1 pour obtenir cette table de correspondance.

====Le Shield Arduino de puissance====
====L'interface en ligne de commande utilisateur====
====L'interface utilisateur finale====
Pour l'interface utilisateur finale, nous nous reposons sur un module d'affichage [http://www.robopeak.com/docs/doku.php?id=product-rpusbdisp RPUSBDisp] de la société RoboPeak. Avant de se lancer dans la phase de programmation de l'interface, il nous a d'abord fallut rendre utilisable l'écran par le RaspberryPi. Pour cela, il a fallut créer un module chargeable par le noyau Linux. Une fois ce module créé, nous nous sommes rendu compte le noyau Linux que nous utilisions (celui fournis avec Raspbian) ne contenait pas les symboles nécessaires au chargement du module. Nous avons alors recompilé le noyau Linux avec les symboles manquants. La compilation s'est avérée assez compliquée car pour éviter de faire de la cross compilation (ce qui aurait surement augmenter le taux d'échec de compilation) nous avons compilé le noyau directement à partir de la RaspberryPi ce qui, malgré son overclooking, était très long (une compilation prenait approximativement une nuit complète). Après quatre tentatives, nous avons réussi à obtenir un noyau fonctionnel.

[[Fichier:RPUSBDisp1.jpg|200px|thumb|right|Premier BMP affiché avec succès sur l'écran]] Une fois l'écran utilisable, nous nous sommes lancés dans le développement de l'interface. Nous avons choisi, dans une optique de performance, de n'utiliser que la librairie X11. Le premier objectif était de réussir à afficher une image sur l'écran. Le format d'image utilisé était le BMP car il n'est pas compréssé et peut être lu sans autres calculs. Après de petits cafouillages (liés au fait que le BMP représente une couleur de 0 à 255 et X11 de 0 à 65535) nous avons réussi à faire afficher notre première image. Cependant, le point négatif est que l'image est affichée en une trentaine de secondes. Nous sommes donc en train de travailler sur un moyen de faire afficher des images plus rapidement.

Après de longues recherches, nous nous sommes rendus compte qu'il n'était pas possible de réaliser une interface temps réel avec cet écran si l'on utilisait la librairie X11. En effet, celle ne communique pas assez rapidement avec l'écran (les recordes d'écriture étant de ~17 secondes par images avec X11). Le constructeur préconise en fait une utilisation à travers une interface USB. Cette interface, décrite dans ce [http://www.robopeak.com/data/doc/rpusbdisp/RPUD03-rpusbdisp_interface_protocol-enUS.1.0.pdf manuel] nous oblige à réécrire notre interface homme machine.

==Conclusion==
===Vidéo de présentation===
Nous pensons enregistrer la vidéo pendant les vacances à l'aide d'une caméra professionnelle.

Thetweekproject

2015-05-06T18:11:49Z

Pletouse : /* Caractérisation du chauffe eau */ Ajout explications + courbes

=Machine à café=
==Présentation du projet==
===Cahier des charges===
SA
* Broyage des grains déjà torréfiés
** Régulation d’un moteur en vitesse avec charge variable
** Réutilisation des éléments d’une cafetière existante (carte électronique hors d’usage)
*** Étalonnage du débitmètre
*** Analyse du chauffe-eau
*** Calibration de la pompe à eau
** Propulsion de l’eau chauffée
*** Régulation d’une pompe à eau en pression et en débit
*** Régulation du chauffe-eau en température
** Modélisation des éléments du système
SC
* Création d’une interface homme-machine
** Installation d’un RaspberryPi avec un écran tactile
*** Gestion des stocks de café, d’eau et de gobelets
*** Gestion des différents éléments (pompe, compresseur, chauffe eau, …)
** Réalisation d’une interface graphique permettant de :
* Moudre le café
* Sélectionner la quantité d’eau à distribuer (café court ou long)
* Sélectionner un café parmi une présélection de café
** Création d’une application Web et Smartphone
*** Possibilité de noter son café
*** Possibilité de retenir un choix de café particulier
* Création de profils créés à partir de la carte étudiante
** Lecture d’information en NFC sur la carte étudiante
** Création d’une base de données basée sur ces profils
*** Proposition des cafés à partir de ceux les plus commandés et/ou mieux notés
*** Possibilité de retenir certains choix et de les recommander

Commun
* Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
* Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)

===Liste des tâches===
*Caractériser le débitmètre
*Caractériser le chauffe-eau
*Caractériser la pompe
*Détermination du schéma de fonctionnement et éventuels correctifs de régulation
*Réalisation de la carte électronique de commande
*Programmation de l'Arduino pour commander la carte
*Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
**Estimation temps de réponse (temps de transfert à l'Arduino négligeable ?)
*Gestion automatique du café
**Dimensionnement capsule et du dispositif de broyage
**Création d'un système dispenseur de gobelets
***Design d'engrenages pour les gobelets
*Plus de fonctionnalités si temps restant
**Recharge par le Net
**Poison pour diabétique
**Interface beaucoup travaillée
**Packaging pratique

===Matériel disponible===

*Machine à café Nespresso défectueuse en morceaux [fournie en 2014]
**Un débitmètre
**Une pompe à eau
**Un chauffe-eau
**Tubes
**Carte électronique (très sûrement défectueuse)
**Mécanisme d'infusion de capsules de café
**Réservoir d'eau avec valve anti-retour

*Matériel électro-informatique
**Arduino Uno [fourni le 26/1/2015]
**Arduino Léonardo [fourni le 5/2/2015]
**RaspberryPi [http://www.adafruit.com/products/998] [fourni le 28/1/2015]
**Carte SD 16G [fournie le 29/1/2015]
**Capteur de température [http://fr.rs-online.com/web/p/capteurs-de-temperature-et-humidite/0264147/] [fourni le 4/2/2015]
**Thermocouple [http://fr.rs-online.com/web/p/thermocouples/6212287/] [fourni le 4/2/2015]
**Lecteur NFC [http://www.adafruit.com/product/364] [fourni le 4/2/2015]
**Ecran tactile [http://www.gotronic.fr/art-afficheur-tactile-usb-2-8-dfr0275-21547.htm] [fourni le 18/03/2015]

*Matériel électronique de puissance
**Contacteurs de puissance (max 32A, 400V) (x2)
**Coffrets d'isolation électrique (x2) (achetés le 09/02/2015)
**Cables électriques (section 2,5 mm2) (achetés le 09/02/2015)
**Boitier interrupteur (achetés le 09/02/2015)

===Matériel manquant===

*Broyeur de café [http://www.maxicoffee.com/moulin-cafe-inoxnoir-gvx2-krups-p-9323-3_68.html?osCsid=e4t6v05n7lctvtod3ehggr0g05]

===Répartition du travail===
{| class="wikitable alternance centre"
|+ Titre
|-
|
! scope="col" | Lundi 14-16h
! scope="col" | Mercredi 14-18h
! scope="col" | Jeudi 10-12h
|-
! scope="row" | Semaine 5
| 26/01 - Organisation et répartition du projet
| 28/01 - Caractériser le débitmètre et gérer les pièces manquantes
| 29/01 - Caractériser le chauffe eau et la pompe
|-
! scope="row" | Semaine 6
| 02/02 - Détermination du schéma de fonctionnement et du plan de régulation
| 04/02 - Réalisation de la carte électronique
| 05/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 7
| 09/02 - Réalisation de la carte électronique
| 11/02 - Réalisation de la carte électronique
| 12/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 8
| 16/02 - Gestion automatique du café
| 18/02 - Gestion automatique du café
| 19/02 - Gestion automatique du café
|-
! scope="row" | Semaine 9
| 23/02 - Gestion automatique du café
| 25/02 - Gestion automatique du café
| 26/02 - Gestion automatique du café
|-
! scope="row" | Semaine 11
| 09/03 - Gestion automatique du café
| 11/03 - Gestion automatique du café
| 12/03 - Gestion automatique du café
|-
! scope="row" | Semaine 12
| 16/03 - Gestion automatique du café
| 18/03 - Gestion automatique du café
| 19/03 - Gestion automatique du café
|-
! scope="row" | Semaine 13
| 23/03 - Gestion automatique du café
| 25/03 - Gestion automatique du café
| 26/03 - Gestion automatique du café
|-
! scope="row" | Semaine 14
| 30/03 - Gestion automatique du café
| 01/04 - Gestion automatique du café
| 02/04 - Gestion automatique du café
|-
! scope="row" | Semaine 15
| Férié
| 08/04 - Gestion automatique du café
| 09/04 - Gestion automatique du café
|-
! scope="row" | Semaine 16
| 13/04 - Gestion automatique du café
| 15/04 - Gestion automatique du café
| 16/04 - Gestion automatique du café
|-
! scope="row" | Semaine 17
| 20/04 - Gestion automatique du café
| 22/04 - Gestion automatique du café
| 23/04 - Gestion automatique du café
|}

En somme, les prévisions pour les différentes parties sont de:
*8 H pour la prise en main du matériel actuel
*14 H pour la réalisation de la carte électronique de commande
*70 H pour la gestion automatique du café

==Etude préalable==
===Caractérisation du débitmètre===
Lors de la première séance "pratique", nous avons étudié le comportement du débitmètre.

Après recherches, nous avons appris qu'il en existe deux types. Le premier type est assimilable à une résistance variable dont la valeur dépend du débit. Le deuxième type se comporte comme un type tout ou rien qui effectue un contact entre deux des pins lorsque l'ailette interne fait un tour. Le débit est donc déduit par la fréquence des impulsions que délivre le débitmètre.

Notre débitmètre est un composant crée par Digmesa, dont la fiche constructeur est disponible [http://www.pollin.de/shop/downloads/D180051D.PDF ici]. Il s'agit d'un débitmètre à turbine, du deuxième type.

Le montage à droite permet de récupérer les impulsions du débitmètre sous forme TTL.

[[Fichier:Schéma_Montage_Débitmètre.JPG|250px|thumb|right|Schéma du montage permettant de récupérer les impulsions du débitmètre]]

Le volume d'eau mesuré s'exprime alors sous cette forme : <math>V = n * \frac{1}{Kdeb}</math> avec n le nombre d'impulsions, V le volume en L et Kdeb la constante fournie dans la doc constructeur Kdeb = 1925 impulsions/L.

Le débit n'est pas une grandeur mesurée directement avec notre débitmètre, mais elle est déduite en choisissant un temps <math>\Delta t</math> suffisamment court pour considérer le débit "instantané".
L'expression du débit "pseudo-instantané" est alors la suivante : <math>\frac{\Delta V}{\Delta t} = \frac{1}{Kdeb} * \frac{\Delta n}{\Delta t} </math> avec <math>\Delta n</math> la variation du nombre d'impulsion pendant le <math>\Delta t</math>.

Obtenir le débit est ici utile car, d'après les informations collectées, le temps d'extraction du café doit être contrôlé (entre 20s à 25s) et le café doit être de 5cl pour un ristretto et de 12cl pour un lungo.

Il est important de noter aussi que ce capteur a une influence sur la pression : en effet, il peut induire une perte de pression (au maximum) de 0,43 bar.

===Réalisation interface commande - puissance===
Afin de pouvoir séparer circuit de commande et alimentation de puissance, nous utiliserons un optocoupleur et des contacteurs pour l'alimentation de la pompe et du chauffe-eau (tout deux alimentés en 230V alternatif 50 Hz). L'optocoupleur est utilisé afin de bénéficier d'une isolation galvanique entre les deux parties, pour plus de sécurité.

La commande d'alimentation est envoyée par l'Arduino à l'optocoupleur. L'optocoupleur commande alors le contacteur (relais de puissance), ce qui alimente l'élément choisi.

L'optocoupleur utilisé est sous forme de circuit "prêt à utiliser" (ET-OPTO AC-OUT 4 dont la fiche constructeur est disponible [http://www.tellab.it/open2b/var/catalog/product/files/57.pdf ici]) qui dispose de quatre optocoupleurs isolés. Nous en utiliserons un pour commander la pompe (OCT0) et un deuxième pour commander le chauffe-eau (OCT1). L'objectif d'une des séances a été d'établir ce dispositif d'alimentation, de comprendre le fonctionnement de l'optocoupleur dont nous disposons et de mapper les optocoupleurs aux sorties de l'Arduino.

Par la suite, nous avons été contraint de changer de type de commande. En effet, la carte d'octocoupleurs permettait la commande mais n'était pas capable de couper le contacteur. Cela est du au principe même du fonctionnement du contacteur. En effet,le contacteur est composé d'une bobine (entre A1 et A2) qui vient attirer un bloc aimanté de façon à créer un contact entre les six broches de puissance (connecteurs 1 à 6). Le problème était que cette bobine demandait un courant trop important que l'octocoupleur gérait mal en rendant impossible la coupure de la bobine.

Pour palier à ce problème, nous avons choisi d'utiliser une carte de commande d'octocoupleurs commandant des relais (ET-OPTO RELAY4, dont la fiche constructeur est disponible [http://www.micro4you.com/files/ETT/ET-OPTO-RELAY4.pdf ici]). Après vérification à l'aide de la documentation technique des relais, nous avons constaté que ceux-ci sont bien capable de couper la commande des contacteurs.

===Fabrication d'un Shield Arduino===
Nous avons donc été amené à créer un shield Arduino avec une carte de prototypage rapide qui réalise les fonctions suivantes :

* intégrer un connecteur 10 broches compatible pour :
** relier la sortie digitale IO 2 à l'optocoupleur OCT0 qui commandera l'alimentation de la Pompe
** relier la sortie digitale IO 3 à l'optocoupleur OCT1 qui commandera l'alimentation du Chauffe eau
* intégrer le circuit de récupération des impulsions du débitmètre TTL et échantillonner ce signal sur l'entrée digitale IO8
* disposer d'une fonction "Boutons Arrêt d'urgence/Commande manuelle" pour la pompe et le chauffe eau.

===Caractérisation de la pompe===
La pompe récupérée est un composant fabriqué par Invensys, dont la fiche constructeur est disponible à [http://www.toolbox.robertshaw.com/appliance/linkedElements/WaterPumps.pdf cette adresse].
Il s'agit d'une pompe à piston qui permet de délivrer une pression allant jusqu'à 19 bar au maximum. Cette pression est fonction du débit en sortie de la pompe, selon la caractéristique à droite.
[[Fichier:Caractéristique_Pompe_Invensys_CP4.JPG‎|250px|thumb|right|Caractéristique Pression/Débit de la pompe]]

Elle se commande en "tout ou rien" et est alimentée en 230 V alternatif 50Hz.
Le paramètre permettant de fixer le point de fonctionnement sur le graphique précédent est la section du tuyau en sortie. Nous n'avons pas la main sur ce paramètre étant donné que nous possédons déjà le système de tuyaux avec les embouts adaptés de section S = 3 mm². En revanche, nous la commanderons en décidant du temps d'allumage.
Il s'agit maintenant de déterminer à quels moments et combien de temps il faut alimenter la pompe, sachant qu'il faut que l'extraction dure entre 20s et 25s et que le chauffe eau induit un retard à déterminer.

'''Séance pratique :'''

Lors d'une séance de manipulation de la pompe, nous l'avons commandé au moyen de l'Arduino pendant plusieurs durées pré-établies (2s, 5s et 10s) afin de déterminer si elle possède un régime transitoire négligeable. Nous avons ensuite relevé le volume d'eau qu'elle avait délivré grâce à une éprouvette graduée. Plusieurs séries de mesures ont été effectuées à chaque fois.
Lors de cette manip, le tuyau de sortie n'était pas connecté au chauffe-eau afin que la mesure ne soit pas influencée, il donnait directement dans l'éprouvette. Cette manipulation nous a également permis de tester notre débitmètre et notre manière d'échantillonner le signal qu'il nous fournit, en comparant le volume déduit par celui ci et le volume réel relevé avec l'éprouvette.

Ainsi, nous avons déterminé que quelque soit le temps d'allumage (pour une durée supérieure à 2s), la pompe fournit un débit constant de 5,2 mL/s = 0,312 cc/min.

===Étalonnage du capteur de température du chauffe-eau===
Afin de réguler le chauffe eau en température, nous avons besoin de connaître le fonctionnement du capteur de température intégré sur celui ci.
Il s'agit en fait d'une thermistance (résistance variable dont la valeur de la résistance dépend de la température), ici à coefficient de température négatif (CTN).

Il n'y a visiblement pas de référence constructeur dessus. Nous avons donc décidé d'effectuer un étalonnage de celle ci. Il existe un dispositif en salle électronique comportant des capteurs de températures déjà étalonnés disposés sur une plaque qui peut être chauffée par un chauffage électrique. Nous avons "collé" avec de la pâte thermique notre thermistance sur cette plaque et effectué un relevé de la résistance en fonction de la température indiquée par les capteurs déjà présents. Le problème est que le chauffage ne pouvait pas être régulé, il continue de chauffer tant qu'on l'alimente. N'ayant donc pas de valeur de température stabilisée, à cause de l'inertie thermique, les valeurs de résistances relevées sont complètement non significatives.
Cette manipulation aura tout de même soulevé un point à prendre en compte : le capteur de température étant en métal, il faudra déterminer l'inertie qu'il induit dans la mesure et si celle ci est négligeable, sinon, comment faire avec.

Le soucis pour une approximation linéaire est que la plage de température est trop importante. En effet, la température de l'eau pour le café doit être entre 88°C et 90°C, mais on doit aussi pouvoir utiliser le capteur à une température de 65°C pour prévoir un mode "économie d'énergie", lorsque la machine n'est pas utilisée pendant 10min par exemple.
Après recherches, la loi d'évolution de la résistance en fonction de la température est de la forme : <math>{1 \over {T}} = A + B \ln(R_{Th}) + C (\ln(R_{Th}))^3 \,</math>

Autre idée : simplement l'étalonner la thermistance au moyen d'un bain d'eau que l'on peut chauffer et d'une sonde de température précise.

Après relevé de l'évolution de la résistance en fonction de la température au moyen du bain marie, nous avons constaté et vérifié que notre sonde de température se comporte comme une sonde standardisée PT100. Nous avons trouvé une fiche constructeur de ces sondes standardisées qui vérifie les caractéristiques de notre capteur ([http://search.murata.co.jp/Ceramy/CatalogAction.do?sHinnm=?&nbsp&sNHinnm=NCP15WF104D03RC&sNhin_key=NCP15WF104D03RC&sLang=en&sParam=series+U0120L0770S0416A1161 lien]). Sur la plage de température que nous avons besoin d'utiliser (25°C - 105°C), nous pouvons négliger le terme en ln^3, ainsi l'équation régissant la résistance en fonction de la température peut s'exprimer ainsi :
<math>{R_{Th}}={R_0} \times\exp\left(\beta\times\left({1 \over {T}} - {1 \over {T_0}}\right)\right) \,</math> avec <math>{R_0}</math> = 100 kOhm la résistance de référence à <math>T_0</math>= 25°C, <math>\beta</math> = 4334 Kelvin le coefficient fourni par le constructeur pour l'approximation sur la plage 25°C-100°C.

Ainsi, la représentation des données pour récupérer la température est la suivante : au moyen d'un pont diviseur, nous récupérons une tension sur l'Arduino image de la résistance et donc de la température avec la relation ci-dessus.
Nous ne pouvons pas inclure dans le code directement un calcul avec la fonction exponentielle, cela prendrait , entre autres, trop de temps de calcul et ne serait pas optimisé étant donné que l'on connait la résolution du CAN de l'Arduino. Pour cela, nous passons par un tableau de conversion sur 256 valeurs calculé au moyen de cette [https://docs.google.com/spreadsheets/d/185WP8sv1Ryd4hWDlqnpToG-fiC0yVxaIgjR2ey1FG68/edit?usp=sharing feuille de calcul]. Voici un schéma de principe :

Coté Arduino : Tension aux bornes de Rth(V) ---CAN---> Valeur sur 10 bits ---TableauDeConversion---> Valeur sur 8 bits

La Raspberry (ou le PC) récupère ensuite cette valeur sur 8 bits et en déduit la température avec la connaissance du "pas" entre 2 températures : <math>Pas = {(105-25)\over 255}</math>

Coté Raspberry : Valeur sur 8 bits ---> 25 + (Valeur * Pas) ---> Température en °C

Cette méthode permet d'alléger le temps de traitement sur l'Arduino et surtout de ne pas perdre en précision et résolution à cause de la transmission de l'information "température", qui s'effectue sur 8 bits.

===Caractérisation du chauffe eau===
Le chauffe eau que nous avons récupéré est de type thermoblock. Il s'agit en fait d'une résistance chauffante autour de laquelle se situe un serpentin dans lequel l'eau circule, le tout étant isolé dans un châssis en métal.
Les principaux avantages de ce système thermoblock est qu'il conserve très bien la chaleur et qu'il permet de ne chauffer que la quantité d'eau nécessaire, la petite quantité qui passe à l'intérieur. On peut alors considérer l'échange thermique entre le chauffage et l'eau quasi instantané et uniforme. L'inconvénient majeur est en revanche, comme pour tout système thermique, l'inertie thermique importante qu'il possède, notamment due à son corps en métal.

Nous n'avons pas trouvé de données constructeur sur ce chauffe eau. La seule information inscrite est la puissance électrique qu'il absorbe : 1200 W.
Il sera alimenté, comme pour la pompe, en 230V alternatif 50Hz, en tout ou rien. Il s'agit maintenant d'estimer ses caractéristiques (inertie, temps caractéristiques, gains en température en fonction de l'entrée) afin de mettre en place un plan de régulation adapté. Ne possédant aucune information sur ce système, nous ne procéderons pas à une étude théorique thermique qui serait trop approximative compte tenu de la géométrie du système et trop fastidieuse à mettre en place. Nous avons choisi de procéder par identification, en relevant les courbes d'évolution de la température, pour différents temps de commande.

'''Résultats :'''

A chaque fois, la réponse peut s'exprimer de la façon suivante : on constate un temps de retard pur au démarrage dû à l'inertie, puis une évolution s’apparentant à celle d'une réponse à système du 1er ordre. On peut écrire la fonction de transfert du système sous cette forme : <math>H(P) = \frac{K}{1+\tau P} e^{- T_{r} P}</math> (modèle de Broïda)

[[Fichier:Commande_2s.png|350px|vignette|right|upright=1.25|Réponse en température pour 2s d'alimentation]]

[[Fichier:Commande_5s.png|350px|vignette|left|upright=1.25|Réponse en température pour 5s d'alimentation]]

[[Fichier:Commande_10s+pompe.png|350px|vignette|centre|upright=1.25|Réponse en température pour 10s d'alimentation, puis arrivée d'eau à t=75s]]

Remarque : On peut observer sur le 2ème graph l'influence du passage de l'eau dans le thermoblock sur la température. Celui ci se traduit comme une perturbation avec un comportement type 1er ordre sur le thermoblock. Avec ces paramètres (temps, gain), on pourra par la suite estimer la compensation à ajouter afin de maintenir la température du thermoblock constante malgré la chauffe de l'eau.

Ainsi, on peut récapituler ceci dans le tableau suivant :

{| class="wikitable"
|-
! Temps de commande
! Gain en température K
! Temps de retard Tr
! Temps caractéristique <math>\tau</math>
|-
| 2 s
|
|
|
|-
| 5 s
|
|
|
|-
| 10 s
|
|
|
|-
|}

===Détermination du schéma de fonctionnement et du plan de régulation===
===Réalisation de la carte électronique===
===Construction de la gestion automatique du café===

==Déroulement du projet==
===Avancement des différents objectifs===
Les différents objectifs et leur avancement sont résumés dans le tableau suivant
{| class="wikitable"
|-
! Objectif
! Etat
! Commentaire
|-
! Étalonnage du débitmètre
| Fini
| La documentation est fournie dans le Wiki, et le shield Arduino permet son utilisation
|-
! Analyse du chauffe-eau
| Fini
| Le chauffe-eau est maintenant complètement caractérisé et suit une loi linéaire sur l'intervalle que nous utilisons. Le retard dans la commande ainsi que la commande tout ou rien complexifie grandement son utilisation mais une solution a été trouvée et fonctionne parfaitement, comme indiqué dans le wiki (à rédiger)
|-
! Calibration de la pompe à eau
| Fini
| La documentation est aussi fournie dans le wiki, et le shield Arduino permet son utilisation en temps réel.
|-
! Régulation du chauffe-eau en température
| Terminé à 90 %
| Le modèle équivalent a été déterminé, comme indiqué dans le wiki (à rédiger), et les tests semblent confirmer le bon fonctionnement. Il manque encore quelques tests pour que la régulation soit totalement validée.
|-
! Régulation d’une pompe à eau en pression et en débit
| Terminé à 50 %
| Le comportement de la pompe a été complétement caractérisé mais l'utilisation des nouvelles pièces créées au Fabricarium risque d'engendrer une augmentation de la pression et donc un modèle à redéfinir.
|-
! Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
| Fini
| L'utilisation d'une carte de puissance couplée avec deux contacteur et un shield arduino réalisé par nos soins rempli parfaitement cet objectif
|-
! Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)
| Fini
| Le shield Arduino que nous avons réalisé permet aussi de lire les différents capteurs
|-
! Programmation de l'Arduino pour commander la carte
| Fini
| Pour finir il est nécessaire d'utiliser deux Arduinos mais tout les deux sont programmés
|-
! Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
| Fini à 60 %
| La partie NFC est réalisée par un des deux Arduinos, l'interface tactile est encore en cours de réalisation. Bonne nouvelle ! Les tests ont montrés que le temps de réponse entre les Arduinos et le RaspberryPi sont négligeables devant le temps d’échantillonnage.
|-
! Dimensionnement capsule et du dispositif de broyage
| Fini à 80 %
| Les capsules et la chambre de la capsule ont été complètement étudiés. Un système complet à été créé pour ne plus être contraint à l'utilisation du système propriétaire. Trois pièces ont été créé à l'aide du logiciel de CAO Catia. La création de ces pièces en métal est pour le moment impossible (Notre contact aux Arts&Métiers est indisponible, peut-être le responsable des machines-outils de la section mécanique peut nous aider à réaliser certaines pièces). Nous nous sommes rabattus sur la création des pièces en PLA à l'aide de l'imprimante 3D WitBox du fabricarium. Les trois pièces principales sont terminées, ce qui pourrait permettre d'en faire un démonstration. La pièce de liaison est fonctionnelle, ce qui nous permet d'adapter notre tuyau de pompe aux trois pièces précédentes.
|-
! Création d'un système dispenseur de gobelets
| Fini à 0%
| Le système n'est pas encore créé
|}

===La programmation des différents éléments===
Pour la partie programmation, le défi résidait dans le fait de faire communiquer tout les éléments à l'aide d'un seul programme. Pour cela, nous avons subdivisé les fonctions principales dans différents modules. Ceci nous permettait entre autre de minimiser le nombre d'éléments reliés à la partie "puissance" du projet (détaillé plus loin)

Le code source du projet est disponible sur [http://www.github.com GitHub], et les liens vers les différents programmes sont les suivants
{| class="wikitable"
|-
!
! Lien
|-
! Shiled Arduino NFC
| [https://github.com/henyxia/tweekd_nfc]
|-
! Shield Arduino de puissance
| [https://github.com/henyxia/tweekd_hvc]
|-
! Interface en ligne de commande
| [https://github.com/henyxia/tweekd]
|-
! Interface graphique finale
| [https://github.com/henyxia/tweekd_gui]
|}
====Le Shield Arduino NFC====
L'objectif de l'utilisation du Shield NFC est de permettre à un utilisateur de payer un café, et donc de s'identifier sur la machine, à l'aide de carte Lille 1. Pour cela, nous nous sommes premièrement orientés sur l'utilisation de l'IDE Arduino et de la librairie dédiée au [https://github.com/Seeed-Studio/PN532 PN532]. Puis, nous avons décidé de passer à un langage C pour avoir une meilleure visibilité sur les registres. Par conséquent, nous avons utilisé le compilateur avr-g++ pour compiler le projet. Il nous a donc était nécessaire de transposer une partie des fichiers C et C++ pour les rendre utilisables avec notre programme C.

La communication se fait par système de questions-réponses. Le serveur sur la Raspberry envoie une demande de données, et l'Arduino répond en conséquence. La seule difficulté a résidé dans la problématique des données à envoyer pour l'identification. Les cartes de Lille 1 sont des cartes NFC Mifare Classic 1K. Elles sont composées de 16 secteurs de 4 fois 16 bytes. Le secteur qui nous intéresse est le douzième secteur, qui est encodé en utilisant les clés NFC publiques (donc accessible par tout le monde). Les clés publiques en question sont :

{| class="wikitable"
|-
!
! Clé
|-
! A
| A0A1A2A3A4A5
|-
! B
| B0B1B2B3B4B5
|}

Ce douzième secteur contient, pour les carte étudiantes, l'INE, suivi du numéro étudiant (sur 8 chiffres), suivi du prénom, suivi d'un point puis du nom. Nous avons d'abord envisagé d'utiliser le nom et le prénom, cependant cela posait le problème des personnes avec le même patronymes. De plus, il arrivait que le nom de l'étudiant soit tronqué pour rester dans l'espace alloué au secteur 12. Par conséquent, nous utilisons le numéro d'étudiant, qui est toujours au même endroit sur le secteur. Le logiciel compare alors ce numéro à une liste d'étudiant.

Par soucis de sécurité, nous n'avons pas de liste donnant une correspondance directe entre un numéro d'étudiant et son nom. En effet, la liste utilisée est un enchaînement de nom et de numéro étudiant encodé avec l'algorithme MD5. Pour récupérer le nom, il nous suffit alors de comparer le numéro étudiant que nous récupérons (que nous encodons en MD5) avec la liste. Ceci nous assure une confidentialité relative, dépendante directement de la robustesse de la non réversibilité du MD5.

Une fois la reconnaissance des cartes étudiantes terminées, nous avons essayé de d'inclure les cartes Lille 1 dédiées au personnel. La première question que nous nous sommes posée est comment pouvons nous faire la différence, au niveau du lecteur, entre une carte étudiante et une carte du personnel. Nous avons remarqué que les cartes du personnel comporte, sur leur douzième secteur, deux fois le numéro de personnel (sur 6 chiffres). La répétition du numéro de personnel se situe à l'endroit où se situe le nom de l'étudiant sur la carte de l'étudiant. Le test est donc assez facile à réaliser. L'autre problème est : comment lié un numéro de personnel à un nom ? Nous n'avons pas encore résolu ce problème car cette table de liaison n'est pas accessible à PolytechLille. Éventuellement, si nous arrivons à accomplir tous les objectifs du projet, nous envisagerons de contacter les responsables de Lille 1 pour obtenir cette table de correspondance.

====Le Shield Arduino de puissance====
====L'interface en ligne de commande utilisateur====
====L'interface utilisateur finale====
Pour l'interface utilisateur finale, nous nous reposons sur un module d'affichage [http://www.robopeak.com/docs/doku.php?id=product-rpusbdisp RPUSBDisp] de la société RoboPeak. Avant de se lancer dans la phase de programmation de l'interface, il nous a d'abord fallut rendre utilisable l'écran par le RaspberryPi. Pour cela, il a fallut créer un module chargeable par le noyau Linux. Une fois ce module créé, nous nous sommes rendu compte le noyau Linux que nous utilisions (celui fournis avec Raspbian) ne contenait pas les symboles nécessaires au chargement du module. Nous avons alors recompilé le noyau Linux avec les symboles manquants. La compilation s'est avérée assez compliquée car pour éviter de faire de la cross compilation (ce qui aurait surement augmenter le taux d'échec de compilation) nous avons compilé le noyau directement à partir de la RaspberryPi ce qui, malgré son overclooking, était très long (une compilation prenait approximativement une nuit complète). Après quatre tentatives, nous avons réussi à obtenir un noyau fonctionnel.

[[Fichier:RPUSBDisp1.jpg|200px|thumb|right|Premier BMP affiché avec succès sur l'écran]] Une fois l'écran utilisable, nous nous sommes lancés dans le développement de l'interface. Nous avons choisi, dans une optique de performance, de n'utiliser que la librairie X11. Le premier objectif était de réussir à afficher une image sur l'écran. Le format d'image utilisé était le BMP car il n'est pas compréssé et peut être lu sans autres calculs. Après de petits cafouillages (liés au fait que le BMP représente une couleur de 0 à 255 et X11 de 0 à 65535) nous avons réussi à faire afficher notre première image. Cependant, le point négatif est que l'image est affichée en une trentaine de secondes. Nous sommes donc en train de travailler sur un moyen de faire afficher des images plus rapidement.

Après de longues recherches, nous nous sommes rendus compte qu'il n'était pas possible de réaliser une interface temps réel avec cet écran si l'on utilisait la librairie X11. En effet, celle ne communique pas assez rapidement avec l'écran (les recordes d'écriture étant de ~17 secondes par images avec X11). Le constructeur préconise en fait une utilisation à travers une interface USB. Cette interface, décrite dans ce [http://www.robopeak.com/data/doc/rpusbdisp/RPUD03-rpusbdisp_interface_protocol-enUS.1.0.pdf manuel] nous oblige à réécrire notre interface homme machine.

==Conclusion==
===Vidéo de présentation===
Nous pensons enregistrer la vidéo pendant les vacances à l'aide d'une caméra professionnelle.

Fichier:Commande 10s+pompe.png

2015-05-06T17:19:58Z

Pletouse :

Fichier:Commande 5s.png

2015-05-06T17:18:24Z

Pletouse :

Fichier:Commande 2s.png

2015-05-06T17:17:31Z

Pletouse :

Thetweekproject

2015-05-06T15:06:47Z

Pletouse : /* Etude préalable */ Ajouts données manquantes et correctifs généraux

=Machine à café=
==Présentation du projet==
===Cahier des charges===
SA
* Broyage des grains déjà torréfiés
** Régulation d’un moteur en vitesse avec charge variable
** Réutilisation des éléments d’une cafetière existante (carte électronique hors d’usage)
*** Étalonnage du débitmètre
*** Analyse du chauffe-eau
*** Calibration de la pompe à eau
** Propulsion de l’eau chauffée
*** Régulation d’une pompe à eau en pression et en débit
*** Régulation du chauffe-eau en température
** Modélisation des éléments du système
SC
* Création d’une interface homme-machine
** Installation d’un RaspberryPi avec un écran tactile
*** Gestion des stocks de café, d’eau et de gobelets
*** Gestion des différents éléments (pompe, compresseur, chauffe eau, …)
** Réalisation d’une interface graphique permettant de :
* Moudre le café
* Sélectionner la quantité d’eau à distribuer (café court ou long)
* Sélectionner un café parmi une présélection de café
** Création d’une application Web et Smartphone
*** Possibilité de noter son café
*** Possibilité de retenir un choix de café particulier
* Création de profils créés à partir de la carte étudiante
** Lecture d’information en NFC sur la carte étudiante
** Création d’une base de données basée sur ces profils
*** Proposition des cafés à partir de ceux les plus commandés et/ou mieux notés
*** Possibilité de retenir certains choix et de les recommander

Commun
* Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
* Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)

===Liste des tâches===
*Caractériser le débitmètre
*Caractériser le chauffe-eau
*Caractériser la pompe
*Détermination du schéma de fonctionnement et éventuels correctifs de régulation
*Réalisation de la carte électronique de commande
*Programmation de l'Arduino pour commander la carte
*Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
**Estimation temps de réponse (temps de transfert à l'Arduino négligeable ?)
*Gestion automatique du café
**Dimensionnement capsule et du dispositif de broyage
**Création d'un système dispenseur de gobelets
***Design d'engrenages pour les gobelets
*Plus de fonctionnalités si temps restant
**Recharge par le Net
**Poison pour diabétique
**Interface beaucoup travaillée
**Packaging pratique

===Matériel disponible===

*Machine à café Nespresso défectueuse en morceaux [fournie en 2014]
**Un débitmètre
**Une pompe à eau
**Un chauffe-eau
**Tubes
**Carte électronique (très sûrement défectueuse)
**Mécanisme d'infusion de capsules de café
**Réservoir d'eau avec valve anti-retour

*Matériel électro-informatique
**Arduino Uno [fourni le 26/1/2015]
**Arduino Léonardo [fourni le 5/2/2015]
**RaspberryPi [http://www.adafruit.com/products/998] [fourni le 28/1/2015]
**Carte SD 16G [fournie le 29/1/2015]
**Capteur de température [http://fr.rs-online.com/web/p/capteurs-de-temperature-et-humidite/0264147/] [fourni le 4/2/2015]
**Thermocouple [http://fr.rs-online.com/web/p/thermocouples/6212287/] [fourni le 4/2/2015]
**Lecteur NFC [http://www.adafruit.com/product/364] [fourni le 4/2/2015]
**Ecran tactile [http://www.gotronic.fr/art-afficheur-tactile-usb-2-8-dfr0275-21547.htm] [fourni le 18/03/2015]

*Matériel électronique de puissance
**Contacteurs de puissance (max 32A, 400V) (x2)
**Coffrets d'isolation électrique (x2) (achetés le 09/02/2015)
**Cables électriques (section 2,5 mm2) (achetés le 09/02/2015)
**Boitier interrupteur (achetés le 09/02/2015)

===Matériel manquant===

*Broyeur de café [http://www.maxicoffee.com/moulin-cafe-inoxnoir-gvx2-krups-p-9323-3_68.html?osCsid=e4t6v05n7lctvtod3ehggr0g05]

===Répartition du travail===
{| class="wikitable alternance centre"
|+ Titre
|-
|
! scope="col" | Lundi 14-16h
! scope="col" | Mercredi 14-18h
! scope="col" | Jeudi 10-12h
|-
! scope="row" | Semaine 5
| 26/01 - Organisation et répartition du projet
| 28/01 - Caractériser le débitmètre et gérer les pièces manquantes
| 29/01 - Caractériser le chauffe eau et la pompe
|-
! scope="row" | Semaine 6
| 02/02 - Détermination du schéma de fonctionnement et du plan de régulation
| 04/02 - Réalisation de la carte électronique
| 05/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 7
| 09/02 - Réalisation de la carte électronique
| 11/02 - Réalisation de la carte électronique
| 12/02 - Réalisation de la carte électronique
|-
! scope="row" | Semaine 8
| 16/02 - Gestion automatique du café
| 18/02 - Gestion automatique du café
| 19/02 - Gestion automatique du café
|-
! scope="row" | Semaine 9
| 23/02 - Gestion automatique du café
| 25/02 - Gestion automatique du café
| 26/02 - Gestion automatique du café
|-
! scope="row" | Semaine 11
| 09/03 - Gestion automatique du café
| 11/03 - Gestion automatique du café
| 12/03 - Gestion automatique du café
|-
! scope="row" | Semaine 12
| 16/03 - Gestion automatique du café
| 18/03 - Gestion automatique du café
| 19/03 - Gestion automatique du café
|-
! scope="row" | Semaine 13
| 23/03 - Gestion automatique du café
| 25/03 - Gestion automatique du café
| 26/03 - Gestion automatique du café
|-
! scope="row" | Semaine 14
| 30/03 - Gestion automatique du café
| 01/04 - Gestion automatique du café
| 02/04 - Gestion automatique du café
|-
! scope="row" | Semaine 15
| Férié
| 08/04 - Gestion automatique du café
| 09/04 - Gestion automatique du café
|-
! scope="row" | Semaine 16
| 13/04 - Gestion automatique du café
| 15/04 - Gestion automatique du café
| 16/04 - Gestion automatique du café
|-
! scope="row" | Semaine 17
| 20/04 - Gestion automatique du café
| 22/04 - Gestion automatique du café
| 23/04 - Gestion automatique du café
|}

En somme, les prévisions pour les différentes parties sont de:
*8 H pour la prise en main du matériel actuel
*14 H pour la réalisation de la carte électronique de commande
*70 H pour la gestion automatique du café

==Etude préalable==
===Caractérisation du débitmètre===
Lors de la première séance "pratique", nous avons étudié le comportement du débitmètre.

Après recherches, nous avons appris qu'il en existe deux types. Le premier type est assimilable à une résistance variable dont la valeur dépend du débit. Le deuxième type se comporte comme un type tout ou rien qui effectue un contact entre deux des pins lorsque l'ailette interne fait un tour. Le débit est donc déduit par la fréquence des impulsions que délivre le débitmètre.

Notre débitmètre est un composant crée par Digmesa, dont la fiche constructeur est disponible [http://www.pollin.de/shop/downloads/D180051D.PDF ici]. Il s'agit d'un débitmètre à turbine, du deuxième type.

Le montage à droite permet de récupérer les impulsions du débitmètre sous forme TTL.

[[Fichier:Schéma_Montage_Débitmètre.JPG|250px|thumb|right|Schéma du montage permettant de récupérer les impulsions du débitmètre]]

Le volume d'eau mesuré s'exprime alors sous cette forme : <math>V = n * \frac{1}{Kdeb}</math> avec n le nombre d'impulsions, V le volume en L et Kdeb la constante fournie dans la doc constructeur Kdeb = 1925 impulsions/L.

Le débit n'est pas une grandeur mesurée directement avec notre débitmètre, mais elle est déduite en choisissant un temps <math>\Delta t</math> suffisamment court pour considérer le débit "instantané".
L'expression du débit "pseudo-instantané" est alors la suivante : <math>\frac{\Delta V}{\Delta t} = \frac{1}{Kdeb} * \frac{\Delta n}{\Delta t} </math> avec <math>\Delta n</math> la variation du nombre d'impulsion pendant le <math>\Delta t</math>.

Obtenir le débit est ici utile car, d'après les informations collectées, le temps d'extraction du café doit être contrôlé (entre 20s à 25s) et le café doit être de 5cl pour un ristretto et de 12cl pour un lungo.

Il est important de noter aussi que ce capteur a une influence sur la pression : en effet, il peut induire une perte de pression (au maximum) de 0,43 bar.

===Réalisation interface commande - puissance===
Afin de pouvoir séparer circuit de commande et alimentation de puissance, nous utiliserons un optocoupleur et des contacteurs pour l'alimentation de la pompe et du chauffe-eau (tout deux alimentés en 230V alternatif 50 Hz). L'optocoupleur est utilisé afin de bénéficier d'une isolation galvanique entre les deux parties, pour plus de sécurité.

La commande d'alimentation est envoyée par l'Arduino à l'optocoupleur. L'optocoupleur commande alors le contacteur (relais de puissance), ce qui alimente l'élément choisi.

L'optocoupleur utilisé est sous forme de circuit "prêt à utiliser" (ET-OPTO AC-OUT 4 dont la fiche constructeur est disponible [http://www.tellab.it/open2b/var/catalog/product/files/57.pdf ici]) qui dispose de quatre optocoupleurs isolés. Nous en utiliserons un pour commander la pompe (OCT0) et un deuxième pour commander le chauffe-eau (OCT1). L'objectif d'une des séances a été d'établir ce dispositif d'alimentation, de comprendre le fonctionnement de l'optocoupleur dont nous disposons et de mapper les optocoupleurs aux sorties de l'Arduino.

Par la suite, nous avons été contraint de changer de type de commande. En effet, la carte d'octocoupleurs permettait la commande mais n'était pas capable de couper le contacteur. Cela est du au principe même du fonctionnement du contacteur. En effet,le contacteur est composé d'une bobine (entre A1 et A2) qui vient attirer un bloc aimanté de façon à créer un contact entre les six broches de puissance (connecteurs 1 à 6). Le problème était que cette bobine demandait un courant trop important que l'octocoupleur gérait mal en rendant impossible la coupure de la bobine.

Pour palier à ce problème, nous avons choisi d'utiliser une carte de commande d'octocoupleurs commandant des relais (ET-OPTO RELAY4, dont la fiche constructeur est disponible [http://www.micro4you.com/files/ETT/ET-OPTO-RELAY4.pdf ici]). Après vérification à l'aide de la documentation technique des relais, nous avons constaté que ceux-ci sont bien capable de couper la commande des contacteurs.

===Fabrication d'un Shield Arduino===
Nous avons donc été amené à créer un shield Arduino avec une carte de prototypage rapide qui réalise les fonctions suivantes :

* intégrer un connecteur 10 broches compatible pour :
** relier la sortie digitale IO 2 à l'optocoupleur OCT0 qui commandera l'alimentation de la Pompe
** relier la sortie digitale IO 3 à l'optocoupleur OCT1 qui commandera l'alimentation du Chauffe eau
* intégrer le circuit de récupération des impulsions du débitmètre TTL et échantillonner ce signal sur l'entrée digitale IO8
* disposer d'une fonction "Boutons Arrêt d'urgence/Commande manuelle" pour la pompe et le chauffe eau.

===Caractérisation de la pompe===
La pompe récupérée est un composant fabriqué par Invensys, dont la fiche constructeur est disponible à [http://www.toolbox.robertshaw.com/appliance/linkedElements/WaterPumps.pdf cette adresse].
Il s'agit d'une pompe à piston qui permet de délivrer une pression allant jusqu'à 19 bar au maximum. Cette pression est fonction du débit en sortie de la pompe, selon la caractéristique à droite.
[[Fichier:Caractéristique_Pompe_Invensys_CP4.JPG‎|250px|thumb|right|Caractéristique Pression/Débit de la pompe]]

Elle se commande en "tout ou rien" et est alimentée en 230 V alternatif 50Hz.
Le paramètre permettant de fixer le point de fonctionnement sur le graphique précédent est la section du tuyau en sortie. Nous n'avons pas la main sur ce paramètre étant donné que nous possédons déjà le système de tuyaux avec les embouts adaptés de section S = 3 mm². En revanche, nous la commanderons en décidant du temps d'allumage.
Il s'agit maintenant de déterminer à quels moments et combien de temps il faut alimenter la pompe, sachant qu'il faut que l'extraction dure entre 20s et 25s et que le chauffe eau induit un retard à déterminer.

'''Séance pratique :'''

Lors d'une séance de manipulation de la pompe, nous l'avons commandé au moyen de l'Arduino pendant plusieurs durées pré-établies (2s, 5s et 10s) afin de déterminer si elle possède un régime transitoire négligeable. Nous avons ensuite relevé le volume d'eau qu'elle avait délivré grâce à une éprouvette graduée. Plusieurs séries de mesures ont été effectuées à chaque fois.
Lors de cette manip, le tuyau de sortie n'était pas connecté au chauffe-eau afin que la mesure ne soit pas influencée, il donnait directement dans l'éprouvette. Cette manipulation nous a également permis de tester notre débitmètre et notre manière d'échantillonner le signal qu'il nous fournit, en comparant le volume déduit par celui ci et le volume réel relevé avec l'éprouvette.

Ainsi, nous avons déterminé que quelque soit le temps d'allumage (pour une durée supérieure à 2s), la pompe fournit un débit constant de 5,2 mL/s = 0,312 cc/min.

===Étalonnage du capteur de température du chauffe-eau===
Afin de réguler le chauffe eau en température, nous avons besoin de connaître le fonctionnement du capteur de température intégré sur celui ci.
Il s'agit en fait d'une thermistance (résistance variable dont la valeur de la résistance dépend de la température), ici à coefficient de température négatif (CTN).

Il n'y a visiblement pas de référence constructeur dessus. Nous avons donc décidé d'effectuer un étalonnage de celle ci. Il existe un dispositif en salle électronique comportant des capteurs de températures déjà étalonnés disposés sur une plaque qui peut être chauffée par un chauffage électrique. Nous avons "collé" avec de la pâte thermique notre thermistance sur cette plaque et effectué un relevé de la résistance en fonction de la température indiquée par les capteurs déjà présents. Le problème est que le chauffage ne pouvait pas être régulé, il continue de chauffer tant qu'on l'alimente. N'ayant donc pas de valeur de température stabilisée, à cause de l'inertie thermique, les valeurs de résistances relevées sont complètement non significatives.
Cette manipulation aura tout de même soulevé un point à prendre en compte : le capteur de température étant en métal, il faudra déterminer l'inertie qu'il induit dans la mesure et si celle ci est négligeable, sinon, comment faire avec.

Le soucis pour une approximation linéaire est que la plage de température est trop importante. En effet, la température de l'eau pour le café doit être entre 88°C et 90°C, mais on doit aussi pouvoir utiliser le capteur à une température de 65°C pour prévoir un mode "économie d'énergie", lorsque la machine n'est pas utilisée pendant 10min par exemple.
Après recherches, la loi d'évolution de la résistance en fonction de la température est de la forme : <math>{1 \over {T}} = A + B \ln(R_{Th}) + C (\ln(R_{Th}))^3 \,</math>

Autre idée : simplement l'étalonner la thermistance au moyen d'un bain d'eau que l'on peut chauffer et d'une sonde de température précise.

Après relevé de l'évolution de la résistance en fonction de la température au moyen du bain marie, nous avons constaté et vérifié que notre sonde de température se comporte comme une sonde standardisée PT100. Nous avons trouvé une fiche constructeur de ces sondes standardisées qui vérifie les caractéristiques de notre capteur ([http://search.murata.co.jp/Ceramy/CatalogAction.do?sHinnm=?&nbsp&sNHinnm=NCP15WF104D03RC&sNhin_key=NCP15WF104D03RC&sLang=en&sParam=series+U0120L0770S0416A1161 lien]). Sur la plage de température que nous avons besoin d'utiliser (25°C - 105°C), nous pouvons négliger le terme en ln^3, ainsi l'équation régissant la résistance en fonction de la température peut s'exprimer ainsi :
<math>{R_{Th}}={R_0} \times\exp\left(\beta\times\left({1 \over {T}} - {1 \over {T_0}}\right)\right) \,</math> avec <math>{R_0}</math> = 100 kOhm la résistance de référence à <math>T_0</math>= 25°C, <math>\beta</math> = 4334 Kelvin le coefficient fourni par le constructeur pour l'approximation sur la plage 25°C-100°C.

Ainsi, la représentation des données pour récupérer la température est la suivante : au moyen d'un pont diviseur, nous récupérons une tension sur l'Arduino image de la résistance et donc de la température avec la relation ci-dessus.
Nous ne pouvons pas inclure dans le code directement un calcul avec la fonction exponentielle, cela prendrait , entre autres, trop de temps de calcul et ne serait pas optimisé étant donné que l'on connait la résolution du CAN de l'Arduino. Pour cela, nous passons par un tableau de conversion sur 256 valeurs calculé au moyen de cette [https://docs.google.com/spreadsheets/d/185WP8sv1Ryd4hWDlqnpToG-fiC0yVxaIgjR2ey1FG68/edit?usp=sharing feuille de calcul]. Voici un schéma de principe :

Coté Arduino : Tension aux bornes de Rth(V) ---CAN---> Valeur sur 10 bits ---TableauDeConversion---> Valeur sur 8 bits

La Raspberry (ou le PC) récupère ensuite cette valeur sur 8 bits et en déduit la température avec la connaissance du "pas" entre 2 températures : <math>Pas = {(105-25)\over 255}</math>

Coté Raspberry : Valeur sur 8 bits ---> 25 + (Valeur * Pas) ---> Température en °C

Cette méthode permet d'alléger le temps de traitement sur l'Arduino et surtout de ne pas perdre en précision et résolution à cause de la transmission de l'information "température", qui s'effectue sur 8 bits.

===Caractérisation du chauffe eau===
===Détermination du schéma de fonctionnement et du plan de régulation===
===Réalisation de la carte électronique===
===Construction de la gestion automatique du café===

==Déroulement du projet==
===Avancement des différents objectifs===
Les différents objectifs et leur avancement sont résumés dans le tableau suivant
{| class="wikitable"
|-
! Objectif
! Etat
! Commentaire
|-
! Étalonnage du débitmètre
| Fini
| La documentation est fournie dans le Wiki, et le shield Arduino permet son utilisation
|-
! Analyse du chauffe-eau
| Fini
| Le chauffe-eau est maintenant complètement caractérisé et suit une loi linéaire sur l'intervalle que nous utilisons. Le retard dans la commande ainsi que la commande tout ou rien complexifie grandement son utilisation mais une solution a été trouvée et fonctionne parfaitement, comme indiqué dans le wiki (à rédiger)
|-
! Calibration de la pompe à eau
| Fini
| La documentation est aussi fournie dans le wiki, et le shield Arduino permet son utilisation en temps réel.
|-
! Régulation du chauffe-eau en température
| Terminé à 90 %
| Le modèle équivalent a été déterminé, comme indiqué dans le wiki (à rédiger), et les tests semblent confirmer le bon fonctionnement. Il manque encore quelques tests pour que la régulation soit totalement validée.
|-
! Régulation d’une pompe à eau en pression et en débit
| Terminé à 50 %
| Le comportement de la pompe a été complétement caractérisé mais l'utilisation des nouvelles pièces créées au Fabricarium risque d'engendrer une augmentation de la pression et donc un modèle à redéfinir.
|-
! Création d’une carte permettant la commande des différents éléments de la machine à café (pompe, chauffe-eau, et d’autres sorties)
| Fini
| L'utilisation d'une carte de puissance couplée avec deux contacteur et un shield arduino réalisé par nos soins rempli parfaitement cet objectif
|-
! Création d’une carte permettant de faire l’acquisition des différents capteurs (comme le débitmètre)
| Fini
| Le shield Arduino que nous avons réalisé permet aussi de lire les différents capteurs
|-
! Programmation de l'Arduino pour commander la carte
| Fini
| Pour finir il est nécessaire d'utiliser deux Arduinos mais tout les deux sont programmés
|-
! Programmation du RaspberryPi pour l'interface tactile et la lecture NFC
| Fini à 60 %
| La partie NFC est réalisée par un des deux Arduinos, l'interface tactile est encore en cours de réalisation. Bonne nouvelle ! Les tests ont montrés que le temps de réponse entre les Arduinos et le RaspberryPi sont négligeables devant le temps d’échantillonnage.
|-
! Dimensionnement capsule et du dispositif de broyage
| Fini à 80 %
| Les capsules et la chambre de la capsule ont été complètement étudiés. Un système complet à été créé pour ne plus être contraint à l'utilisation du système propriétaire. Trois pièces ont été créé à l'aide du logiciel de CAO Catia. La création de ces pièces en métal est pour le moment impossible (Notre contact aux Arts&Métiers est indisponible, peut-être le responsable des machines-outils de la section mécanique peut nous aider à réaliser certaines pièces). Nous nous sommes rabattus sur la création des pièces en PLA à l'aide de l'imprimante 3D WitBox du fabricarium. Les trois pièces principales sont terminées, ce qui pourrait permettre d'en faire un démonstration. La pièce de liaison est fonctionnelle, ce qui nous permet d'adapter notre tuyau de pompe aux trois pièces précédentes.
|-
! Création d'un système dispenseur de gobelets
| Fini à 0%
| Le système n'est pas encore créé
|}

===La programmation des différents éléments===
Pour la partie programmation, le défi résidait dans le fait de faire communiquer tout les éléments à l'aide d'un seul programme. Pour cela, nous avons subdivisé les fonctions principales dans différents modules. Ceci nous permettait entre autre de minimiser le nombre d'éléments reliés à la partie "puissance" du projet (détaillé plus loin)

Le code source du projet est disponible sur [http://www.github.com GitHub], et les liens vers les différents programmes sont les suivants
{| class="wikitable"
|-
!
! Lien
|-
! Shiled Arduino NFC
| [https://github.com/henyxia/tweekd_nfc]
|-
! Shield Arduino de puissance
| [https://github.com/henyxia/tweekd_hvc]
|-
! Interface en ligne de commande
| [https://github.com/henyxia/tweekd]
|-
! Interface graphique finale
| [https://github.com/henyxia/tweekd_gui]
|}
====Le Shield Arduino NFC====
L'objectif de l'utilisation du Shield NFC est de permettre à un utilisateur de payer un café, et donc de s'identifier sur la machine, à l'aide de carte Lille 1. Pour cela, nous nous sommes premièrement orientés sur l'utilisation de l'IDE Arduino et de la librairie dédiée au [https://github.com/Seeed-Studio/PN532 PN532]. Puis, nous avons décidé de passer à un langage C pour avoir une meilleure visibilité sur les registres. Par conséquent, nous avons utilisé le compilateur avr-g++ pour compiler le projet. Il nous a donc était nécessaire de transposer une partie des fichiers C et C++ pour les rendre utilisables avec notre programme C.

La communication se fait par système de questions-réponses. Le serveur sur la Raspberry envoie une demande de données, et l'Arduino répond en conséquence. La seule difficulté a résidé dans la problématique des données à envoyer pour l'identification. Les cartes de Lille 1 sont des cartes NFC Mifare Classic 1K. Elles sont composées de 16 secteurs de 4 fois 16 bytes. Le secteur qui nous intéresse est le douzième secteur, qui est encodé en utilisant les clés NFC publiques (donc accessible par tout le monde). Les clés publiques en question sont :

{| class="wikitable"
|-
!
! Clé
|-
! A
| A0A1A2A3A4A5
|-
! B
| B0B1B2B3B4B5
|}

Ce douzième secteur contient, pour les carte étudiantes, l'INE, suivi du numéro étudiant (sur 8 chiffres), suivi du prénom, suivi d'un point puis du nom. Nous avons d'abord envisagé d'utiliser le nom et le prénom, cependant cela posait le problème des personnes avec le même patronymes. De plus, il arrivait que le nom de l'étudiant soit tronqué pour rester dans l'espace alloué au secteur 12. Par conséquent, nous utilisons le numéro d'étudiant, qui est toujours au même endroit sur le secteur. Le logiciel compare alors ce numéro à une liste d'étudiant.

Par soucis de sécurité, nous n'avons pas de liste donnant une correspondance directe entre un numéro d'étudiant et son nom. En effet, la liste utilisée est un enchaînement de nom et de numéro étudiant encodé avec l'algorithme MD5. Pour récupérer le nom, il nous suffit alors de comparer le numéro étudiant que nous récupérons (que nous encodons en MD5) avec la liste. Ceci nous assure une confidentialité relative, dépendante directement de la robustesse de la non réversibilité du MD5.

Une fois la reconnaissance des cartes étudiantes terminées, nous avons essayé de d'inclure les cartes Lille 1 dédiées au personnel. La première question que nous nous sommes posée est comment pouvons nous faire la différence, au niveau du lecteur, entre une carte étudiante et une carte du personnel. Nous avons remarqué que les cartes du personnel comporte, sur leur douzième secteur, deux fois le numéro de personnel (sur 6 chiffres). La répétition du numéro de personnel se situe à l'endroit où se situe le nom de l'étudiant sur la carte de l'étudiant. Le test est donc assez facile à réaliser. L'autre problème est : comment lié un numéro de personnel à un nom ? Nous n'avons pas encore résolu ce problème car cette table de liaison n'est pas accessible à PolytechLille. Éventuellement, si nous arrivons à accomplir tous les objectifs du projet, nous envisagerons de contacter les responsables de Lille 1 pour obtenir cette table de correspondance.

====Le Shield Arduino de puissance====
====L'interface en ligne de commande utilisateur====
====L'interface utilisateur finale====
Pour l'interface utilisateur finale, nous nous reposons sur un module d'affichage [http://www.robopeak.com/docs/doku.php?id=product-rpusbdisp RPUSBDisp] de la société RoboPeak. Avant de se lancer dans la phase de programmation de l'interface, il nous a d'abord fallut rendre utilisable l'écran par le RaspberryPi. Pour cela, il a fallut créer un module chargeable par le noyau Linux. Une fois ce module créé, nous nous sommes rendu compte le noyau Linux que nous utilisions (celui fournis avec Raspbian) ne contenait pas les symboles nécessaires au chargement du module. Nous avons alors recompilé le noyau Linux avec les symboles manquants. La compilation s'est avérée assez compliquée car pour éviter de faire de la cross compilation (ce qui aurait surement augmenter le taux d'échec de compilation) nous avons compilé le noyau directement à partir de la RaspberryPi ce qui, malgré son overclooking, était très long (une compilation prenait approximativement une nuit complète). Après quatre tentatives, nous avons réussi à obtenir un noyau fonctionnel.

[[Fichier:RPUSBDisp1.jpg|200px|thumb|right|Premier BMP affiché avec succès sur l'écran]] Une fois l'écran utilisable, nous nous sommes lancés dans le développement de l'interface. Nous avons choisi, dans une optique de performance, de n'utiliser que la librairie X11. Le premier objectif était de réussir à afficher une image sur l'écran. Le format d'image utilisé était le BMP car il n'est pas compréssé et peut être lu sans autres calculs. Après de petits cafouillages (liés au fait que le BMP représente une couleur de 0 à 255 et X11 de 0 à 65535) nous avons réussi à faire afficher notre première image. Cependant, le point négatif est que l'image est affichée en une trentaine de secondes. Nous sommes donc en train de travailler sur un moyen de faire afficher des images plus rapidement.

Après de longues recherches, nous nous sommes rendus compte qu'il n'était pas possible de réaliser une interface temps réel avec cet écran si l'on utilisait la librairie X11. En effet, celle ne communique pas assez rapidement avec l'écran (les recordes d'écriture étant de ~17 secondes par images avec X11). Le constructeur préconise en fait une utilisation à travers une interface USB. Cette interface, décrite dans ce [http://www.robopeak.com/data/doc/rpusbdisp/RPUD03-rpusbdisp_interface_protocol-enUS.1.0.pdf manuel] nous oblige à réécrire notre interface homme machine.

==Conclusion==
===Vidéo de présentation===
Nous pensons enregistrer la vidéo pendant les vacances à l'aide d'une caméra professionnelle.

Thetweekproject

2015-03-18T22:27:49Z

Pletouse : /* Matériel */ Ajout "Ecran tactile fourni le 18/03/2015"

Thetweekproject

2015-03-15T18:23:10Z

Pletouse : /* Étalonnage du capteur de température du chauffe-eau */ Lien de la feuille de calcul corrigé

Thetweekproject

2015-03-15T18:16:44Z

Pletouse : /* Déoulement du projet */ Il manquait le "r" de "Déroulement"...

Thetweekproject

2015-03-15T18:15:36Z

Pletouse : /* Étalonnage du capteur de température du chauffe-eau */ Ajout explications pour récupération de l'information "température"

Thetweekproject

2015-02-23T22:30:59Z

Pletouse : /* Etude préalable */ Ajout Catégorie Etalonnage du capteur de température

Thetweekproject

2015-02-23T21:47:21Z

Pletouse : /* Caractérisation de la pompe */

Thetweekproject

2015-02-23T21:46:49Z

Pletouse : /* Caractérisation de la pompe */

Thetweekproject

2015-02-23T21:44:16Z

Pletouse : /* Caractérisation de la pompe */ Ajout Infos collectées sur la pompe + résumé XP

Fichier:Caractéristique Pompe Invensys CP4.JPG

2015-02-23T20:55:33Z

Pletouse :