Distribution de pièces pour la robotique manufacturière

Sommaire

Présentation projet

Cahier des charges  (Bête à corne / Diagramme Pieuvre)

– Diagramme FAST

– Achats et appareils utilisés

– Partie programmation

– Arduino

– Staublie / Cognex

– Partie test

– Conclusion

Partie Intégration d’un capteur de détection pièce

1) Présentation du projet

2) Cahier des charges 

Diagramme pieuvre

tableau détaillants les fonctions primaires et secondaire à réaliser

RepèresFonctionscritères
FP1Stocker les pièces par couleurs dans des compartimentsArchitecture et milieu
FP2Libérer les pièces de façon aléatoireArduino et architecture
FC1Doit tenir dans la zone de travailcompact
FC2Doit être programmable par un pcProgrammable
FC3Doit fonctionner automatiquementautonome

3) Diagramme FAST

Avec la réalisation de ce diagramme Fast, nous avons le détails des fonctions primaires et comment les réaliser.

4) Achats et appareils utilisés

Voici le détail des achats réalisé dans le cadre du projet du support de pièce pour le Robot STAUBLI.p

5) Partie programmation

(La majeure partie des programmes ne sont pas compatible avec WordPass. M. CUDEL possède les programmes originaux.)

a) côté réservoir ( Arduino )

Ci-dessous le grafcet détaillant le fonctionnement du programme Arduino pour la libération des pièces de façon aléatoire.

Ci dessous le programmes Arduino qui s’occupe de la libération des pièces de façon aléatoire.

b) côté Robot/Vision

1)In sight Cognex

Voici le tableur de la partie vision sur le logiciel « In sight ». La caméra utilisé est une caméra couleur. Les programmes In-sight n’étant pas compatible avec WordPress, nous avons décidé de mettre les programmes sous forme de captures d’écrans.

détection de la couleur + coordonnées d’une pièce bleu sur le tapis.

détection de la couleur + coordonnées d’une pièce verte sur le tapis.

détection de la couleur + coordonnées d’une pièce rouge sur le tapis.

2) Staubli

Pour des raisons de non compatibilité, les programmes sont mis sous formes de captures d’écrans.
Nous retrouvons trois programmes pour les prises pièces des trois couleurs Et un programme qui simule la caméra Cognex (envois de coordonnées X,Y et la couleur présente(B,G,R)) . N’ayant pas réussit à connecter la partie Staubli à la partie In-sight, nous avons décidé de simuler la caméra directement sur le logiciel Staubli avec les même chaines de caractères.

6) Partie TEST

a) côté réservoir ( Arduino )

Voici une vidéo qui montre le bon fonctionnement du réservoir de pièce. Nous pouvons voir que la libération des pièces se fais de façon aléatoire et qu’il n’est pas possibles d’avoir deux pièces identiques à la suite. Si aucune chute de pièce est détectée au bout de 5 secondes, le moteur s’arrête.

b) côté Robot/Vision

7) Conclusion

Ce projet fut très intéressant, il nous a permis d’appliquer les connaissances de In-sight et Staubli vu en cours directement sur un projet concret.

Je vois quelques points à travailler pour améliorer ce projet notamment:
– Passer sur un automate serait une bonne idée
– surveillé la consommation des moteurs (passer sur des moteurs à courant continu pour limiter la consommation)
– Minimiser la chauffe des moteurs pour pouvoir faire tourner l’installation pendant une période plus longues.

Intégration d’un capteur de détection pièce

A côté du projet précédent, qui est un plan incliné pour la distribution de pièces pour la robotique manufacturière, nous avons procédé à l’intégration d’un capteur pouvant détecter la présence d’une pièce. Ce capteur est intégré au sein de la pince robot, au niveau des mors.

Mors de la pince robot

Ce capteur sera un simple interrupteur cylindrique intégré à l’un des mors. Cette intégration devra être étudiée à l’IUT Lab.

Le câblage de celui-ci est de préférence unipolaire, ce qui comprend une alimentation et un retour d’information. Pour effectuer ce câblage il faut utiliser les connecteurs J1203 sur l’avant bras du robot et J1202 sur le pied ainsi que sur la CPU. Les connecteurs à utiliser seront de la marques Binder Connector dans la gamme miniature. Ils seront de 19 broches en M16. Le format mâle est appliqué à l’avant bras et à la CPU. Tandis que le format femelle est adapté au connecteur sur le pied.

MARHEM Rémi

ENGGASSER Geoffrey

ROOS Hugo

MULLER Lucas


Ruche connectée & SigFox

Sommaire

  • Introduction
  • Cahier des charges
  • Solutions techniques mises en œuvre
    • Mesure du poids de la ruche
    • Mesure de la température et du taux d’humidité
    • Mesure de la fréquence des sons de la ruche
    • Transmission des données
    • Autonomie du système et optimisation de la consommation
    • Intégration des composants
    • Mise en œuvre d’une interface utilisateur
  • État des lieux du projet, et amélioration possibles
  • Conclusion

Introduction

A l’heure actuelle, de nombreux modèles de balances connectées pour ruches sont disponibles sur le marché. Ces balances présentent parfois des fonctionnalités supplémentaires, par exemple une station-météo intégrée, un antivol GPS, etc. Le prix de ces systèmes est assez élevé et ces modèles sont principalement destinés à des professionnels. C’est pour ces raisons que nous avons choisi de réaliser notre propre balance connectée, intégrant d’autres fonctionnalités.

Premièrement, dans la gestion d’une ruche, la température et le taux d’humidité internes sont très importants.  Ces deux grandeurs, informe directement l’apiculteur sur la santé de la colonie. Ensuite, nous avons choisi de mesurer les fréquence du bourdonnement des abeilles à l’intérieur de la ruche afin de pouvoir détecter un essaimage.

Cahier des charges

Solutions techniques mises en œuvre

Mesure du poids de la ruche

Nous avons choisi d’utiliser quatre capteurs de force en pont de Wheatstone, pouvant mesurer jusqu’à 50 Kg chacun. Ces capteurs sont connectés en parallèles, le poids maximal mesurable est donc de 200 Kg. La précision donnée par le constructeur est de ± 25 grammes. Les mesures sont effectuées par une carte programmable Arduino.

https://www.gotronic.fr/ori-capteur-de-force-50-kg-czl635-50-17601.jpg
Capteur de force

Un amplificateur – convertisseur est nécessaire pour effectuer les mesures. Le composant choisi est un amplificateur HX711. Il permet de convertir la valeur analogique de la masse mesurée en donnée numérique, transmise ensuite à la carte Arduino par communication série.

Amplificateur pour Cellule de Force HX711 - RobotShop
HX711

Il est nécessaire d’effectuer une calibration de ces capteurs, au moyen d’un code fourni par le fabriquant de l’amplificateur, utilisant une bibliothèque spécifique afin de simplifier la programmation.

Mesure de la température et du taux d’humidité

Pour mesurer la température et l’humidité à l’intérieur de la ruche, un capteur comportant ces deux fonctions est utilisé. Il s’agit d’un capteur AM2320. Ce capteur est capable de mesurer une température de -40°C à +80°C avec une précision de ±0,5°C, et un taux d’humidité allant de 0% à 99,9% avec une précision de ±3%. Il communique par un bus I2C avec la carte Arduino. Ce bus comporte deux voies, une voie d’horloge (SCL) et une voie de données (SCL). C’est un protocole standardisé très répandu dans les applications électroniques. Concernant la programmation, l’utilisation d’une bibliothèque fournie par Adafruit inclus toutes les fonctions nécessaires à la programmation.

https://www.gotronic.fr/ori-capteur-de-t-et-d-humidite-am2320-27959.jpg
AM2320

Mesure de la fréquence des sons de la ruche

               La fréquence des sons produits par les abeilles ne s’obtient pas directement par lecture de la valeur d’un capteur. Le capteur utilisé est un micro à électret amplifié ADA1063. Il dispose d’une sortie analogique. Pour obtenir la valeur de la fréquence, il est nécessaire d’effectuer une FFT (Fast Fourier Transform) sur un certain nombre d’échantillons de la sortie analogique du capteur. On choisit 128 échantillons (limite maximale pour Arduino) et une fréquence d’échantillonnage de 1212Hz, nécessaire pour mesurer des fréquences jusqu’à 600Hz. Le calcul de cette FFT est effectué par une bibliothèque Arduino (arduinoFFT). Ce calcul à ensuite été testé en utilisant un générateur de fréquences sonores sur smartphone. En faisant varier le générateur entre 50Hz et 600Hz, toutes les mesures obtenues sont justes, avec une tolérance de ± 4Hz. Cette plage de fréquences mesurables est donc tout à fait en adéquation avec la plage de fréquence des sons des abeilles, comme indiqué dans Abeille & Cie N°165.

ADA1063

Transmission des données

Pour transmettre les données issues de la ruche à l’apiculteur, nous avons choisi d’utiliser le réseau Sigfox. C’est un réseau de communication basse puissance (868Mhz) qui présente beaucoup d’avantages.

  • Avantages :
    • Basse puissance (non perturbant pour les abeilles)
    • Basse consommation
    • Couverture réseau très importante en France
    • 14 émissions par jour
    • Bidirectionnel (Émission / Réception)
  • Inconvénients :
    • Abonnement nécessaire (3€/an selon Sigfox).
    • Transmissions « lentes » en raison de la basse fréquence.

Plusieurs modèles de modules Sigfox existent.  Pour notre application, nous avons choisi d’utiliser une carte programmable Arduino MKR FOX 1200 qui intègre un moule de communication Sigfox. Cette carte est particulièrement adaptée au développement de ce type d’application, en raison de sa faible consommation, de son encombrement réduit, et de son coût.

Carte Arduino MKR FOX 1200 ABX00014 Arduino - Cartes MKR | GO TRONIC
Arduino MKR FOX 1200

Un abonnement d’un an au service Sigfox est inclus avec la carte programmable, qui s’active automatiquement dès le troisième message transmis sur Sigfox. Il sera donc nécessaire de renouveler par la suite cet abonnement.

Arduino fourni une bibliothèque Sigfox, proposant des fonctions simples pour envoyer des messages sur le réseau Sigfox. Le programme final effectue donc les mesures de poids, de température, de taux d’humidité, calcul la fréquence du son produits par les abeilles, et transmet ces données actualisées toutes les 20 minutes.

Alimentation, autonomie du système et optimisation de la consommation

Dans le but de diminuer la consommation du système, et donc d’augmenter son autonomie, plusieurs solutions sont mises en œuvre. D’une part, la programmation sous Arduino permet de réduire la consommation de deux façons. Premièrement, la carte utilisée est capable d’être « endormie » lorsqu’elle n’est pas utilisée. De la même façon, l’amplificateur HX711 peut lui aussi être mis en veille lorsqu’il n’est pas utilisé, grâce à sa bibliothèque. Passer cet amplificateur en veille réduit la consommation de 20mA.

Ensuite, il est nécessaire d’utiliser un régulateur de tension linéaire 5V, pour abaisser la tension de la batterie 12V en 5V. Dans un premier temps, nous avons utilisé un régulateur LM1085, qui consommé 10mA à vide. Nous l’avons finalement remplacé par un régulateur LM78L05, dans un boitier TO-92. La consommation à vide mesurée de ce régulateur est de 3,2mA, ce qui a permit de réduire encore la consommation de 6,8mA.

Des mesures de consommation en fonctionnement typique du système ont été effectuées. Ce fonctionnement est décomposé en 3 phases : « Sleep » lorsque la carte Arduino et l’amplificateur HX711 sont en veille entre deux transmissions, « Mesure » lorsque la carte Arduino effectue les mesures des différents capteurs et calcule la fréquence et « Emission », lorsque les données sont émises sur Sigfox. Pour un cycle, la phase « Mesures » dure 5 secondes, et la phase Emission dure 10 secondes. La phase « Sleep » dure tout le reste du temps, soit : 20min – 5s – 10s = 1195s.

Les consommations dans ces différentes phases, sont les suivantes :

  • Sleep : 16 mA (pendant 1195s)
  • Mesure : 44 mA (pendant 5s)
  • Emission : 59 mA (pendant 10s)

Afin de réduire encore ces consommations, la led Power implantée sur la carte Arduino, et allumée en permanence, a été dessoudée. A l’aide du schéma électronique fourni par Arduino, nous avions calculé que cette led consommait environ 10mA. Ce calcul a été confirmé par de nouvelles mesures de consommation. Supprimer cette led permet d’abaisser la consommation de 9mA. On obtient donc les mesures suivantes :

  • Sleep : 7 mA (pendant 1195s)
  • Mesure : 35 mA (pendant 5s)
  • Emission : 50 mA (pendant 10s)

Sur une heure, cela correspond à une consommation moyenne de 7,5mA/h soit 0,2A/h par jour.

Concernant la batterie, nous avons utilisé une batterie au plomb, que nous avions en stock à l’IUT. C’est une batterie 12V, 9Ah. Avec cette batterie, l’autonomie maximale du système est donc de 45 jours. Néanmoins le principal inconvénient de cette batterie est son encombrement. Elle mesure 15,1cm x 10,2cm x 6,5cm, et pèse 2,7Kg.

Intégration des composants

Afin de connecter les différents composants électroniques entre eux, nous avons réalisé un circuit imprimé dans le laboratoire d’électronique de l’IUT. Ce circuit permet d’accueillir le régulateur de tension, la carte Arduino et l’amplificateur HX711. Des borniers y sont aussi implantés, permettant de faciliter la connexion de l’alimentation, des capteurs de force, le micro et le capteur de température et d’humidité. Ce circuit imprimé ainsi que la batterie, sont placés dans un coffret plastique d’électricien.

Boitier électronique

Les étudiants en Génie Mécanique et Productique, ont réalisé le support de ruche intégrant les quatre capteurs de force.

Support de pesée

Mise en œuvre d’une interface utilisateur

               Une interface utilisateur a été mise en œuvre, afin de faciliter la lecture et le suivi des données.  Elle a été réalisée en utilisant Node Red. Elle est composée de trois onglets :

  • Synoptique : Dernières mesures, heure de la dernière transmission, graphique de l’évolution du poids sur 24h, météo en temps réel à l’emplacement de la balance.
  • Graphiques : Graphiques de l’évolution du poids sur 24h et sur 7 jours, de la fréquence sur 24h, de la température et du taux d’humidité sur 24h.
  • Historique : Tableau regroupant les données des 1000 dernières transmissions.

Pour ce premier prototype, nous avons choisi d’héberger cette interface sur un Raspberry Pi, en réseau local. Cela signifie qu’il est uniquement possible d’accéder à l’interface lorsque l’on est connecté sur le même réseau que le Raspberry Pi. Nous avons réalisé ce choix afin de ne pas être dépendants d’un service d’hébergement de serveur Web. Il est possible d’associer plusieurs balances à la même interface.

État des lieux du projet

Un grand nombre des fonctions définies par le cahier des charges ont pu être mises en œuvre. Premièrement, l’acquisition des données, que ce soit les données issues de la ruche, ou bien les données météorologiques récupérées sur Internet les fonctions attendues ont été mise en place. Ensuite, la transmission des données est bien autonome en utilisant le réseau Sigfox, et est régulier toutes les 20min. Néanmoins, nous n’avons pas encore mis en marche une transmission de données événementielles. L’interface utilisateur n’est pas sur un site Web et ne nécessite donc pas de système de connexion par mot de passe. De plus, les données sont actualisées à chaque nouvelle transmission, et il est possible de suivre l’évolution chronologique des différentes grandeurs. L’autonomie du système est inférieure à celle fixée par le cahier des charges, et nous n’avons pas encore pu tenter d’implanter des cellules photovoltaïques. Pour finir, l’objectif de coût du projet est respecté : le coût de tous les composants (support exclu) permettant de réaliser cette balance est d’environ 220€.

Conclusion

Pour conclure, ce projet nous a permis tout d’abord de découvrir ou d’approfondir nos connaissances en matière d’apiculture, notamment l’importance de la température et du taux d’humidité interne à la ruche, ainsi que la « signification » des signaux sonores d’une colonie d’abeilles. Ces informations permettent à l’apiculteur, amateur ou professionnel, de mieux suivre et soigner ses colonies.

Les principales fonctions du cahier des charges ont été mises en œuvre. La balance est placée sous une ruche depuis maintenant deux semaines. Les mesures effectuées sont toujours cohérentes avec l’environnement et les conditions météorologiques. Néanmoins, il est nécessaire d’effectuer des tests sur une plus longue période.

De nombreuses améliorations peuvent tout de même déjà être envisagées, en particulier au sujet de l’autonomie du système, et de son encombrement. Parvenir à rendre accessible l’interface utilisateur depuis le Web est aussi un point à travailler.

Simon RAPP

Loyna WALTER

Hugo KLEIN

Anthony LITTERST


Automatisation d’une Brasserie

SOMMAIRE

  • Introduction
  • Analyse fonctionnelle
  • Réalisation du projet
  • Réalisation de la bière
  • Conclusion

Introduction

La bière est une boisson alcoolisée millénaire obtenu par fermentation d’un moût végétal. Chaque pays revendique un savoir-faire unique.

Pour produire une bière, il faut 5 ingrédients :

  • De l’eau
  • Du malt
  • Du houblon
  • De la levure
  • Du sucre

Il y a ensuite plusieurs étapes de la production à respecter pour réussir sa bière :

  • Le concassage
  • L’empâtage
  • Le rinçage
  • L’houblonnage
  • Le refroidissement
  • La fermentation
  • L’embouteillage

Premièrement, dans la fabrication d’une bière, la température et le temps de cuissons sont très importants et à respecter. Ensuite, selon la recette de bière souhaitée, nous ajoutons différents ingrédients (houblon et malt), cela déterminera le goût, le degré d’alcool et la couleur de la bière.

De nos jours, de nombreux modèles de micro-brasseries pour la création de différentes bières sont disponibles sur le marché. Le prix de ces systèmes est assez élevé et ces modèles sont principalement destinés à des professionnels. Les étudiants des années précédentes ont débuté la réalisation d’une micro-brasserie à l’IUT. Nous avons décidé de reprendre leurs travaux en intégrant des améliorations.

Analyse fonctionnelle

Un projet de bière avait déjà été fait initialement en 2019. Nous avons donc pour objectif de partir de leur maquette de projet et de reprogrammer la brasserie. Ainsi que d’automatiser le rinçage afin de simplifier cette étape. 

Nous avons pas eu assez de temps pour réaliser la partie mécanique donc ni électrique et programmation. Le cahier des charges est de faire une bière blonde tout en respectant des paliers de températures. Nous avons alors régulé la température avec un automate Siemens S7-1200.

Le diagramme bête à cornes :
Paliers de températures à respecter :
Ingrédient Bière Blonde :

Réalisation du projet

Armoire Électrique :

L’armoire était déjà câblée. Seul l’automate était à remplacer par un nouveau. Il fallait donc optimiser les branchements, sertir des fils, et rendre l’armoire fonctionnelle pour le projet.

Les contacteurs utilisés ont les fonctions suivantes :

  • KVAR  =     Mise sous tension
    variateur
  • KA0     =    Relais de maintien du
    disjoncteur de la
    partie puissance
  • KA2     =    Fin de course bas
  • KA1     =    Fin de course haut
  • KAdef  =    Défauts
  • KADE   =    Descendre la pâle
  • KDET   =  Chauffage
  • KAMO =  Monter la pâle

Câblage de l’automate :

Les étapes que nous avons suivi :
  1. Placer le nouvel automate SIMENS S7-1200
  2. Câbler selon l’ancien schéma
  3. Noter les modifications effectuées

Programmation de l’automate :

Nous avons repris le Grafcet du mode de marche (GMA) déjà réalisé par les anciens élèves.

Par la suite, nous avons fait un Grafcet qui décrit les étapes du programme:

Pour respecter les différents paliers de température, nous avons utilisé des régulateurs PID (Proportionnel Intégral Dérivé)

Paliers de température :

Création de l’IHM :

L’IHM à trois vues principales ainsi que quatre vues des recettes existantes:

  • Blonde
  • Blanche
  • Rousse
  • Brune
Exemple d’une vue de l’IHM:

La page d’accueil possède un switch auto/manuel ainsi qu’un bouton de départ/arrêt cycle. Nous avons aussi une page de gestion avec des boutons qui valident les étapes que le brasseur doit effectuer (ex: grain, rinçage). Ainsi que des voyants/afficheurs sur la valeur de la température par rapport aux différents paliers. La dernière page est le regroupement des recettes des 4 bières proposées.

Réalisation de la bière

1. Le concassage

Concasser les grains permet de mieux faire infuser le malt dans l’eau durant le brassage.

Pour notre bière blonde, nous avons utilisé :

  • 2,7kg de malt Pale
  • 180g de malt Vienna
  • 180g de flocon d’avoine

2. L’empâtage

Cela consiste à mélanger et faire chauffer les grains de malt concassés à de l’eau, afin d’obtenir une pâte appelée la « drêche » et de faire chauffer le tout.

3. Le rinçage

La drêche contient des protéines dénaturées et des polyphénols qui sont responsables du trouble permanent et d’une mauvaise stabilité dans le temps de la bière. La quantité d’eau de rinçage doit être calculée au préalable et adaptée aux pertes liées à l’évaporation. Plus la drêche va être lavée, plus la composition du moût récupéré (sucres) sera diluée.

4. L’ houblonnage

Le houblonnage, également appelé aromatisation, est l’étape de la fabrication de la bière consistant à faire bouillir du houblon dans le moût afin de donner du goût à la bière. Les Houblons utilisés:

  • 55g de houblon Cascade
  • 13g de houblon Mosaïc

Recette: Faire cuire jusqu’à ébullition pendant 1h l’houblon Cascade puis 10 min avant la fin de l’heure, ajout de l’houblon Mosaïc.

5. Le refroidissement

Le refroidissement est réalisé en faisant passer le moût dans un serpentin de cuivre muni d’un système de refroidissement à eau. Instrument indispensable afin de descendre rapidement la température du moût après ébullition. On utilise souvent un échangeur à plaques ou bien un serpentin refroidisseur.

6. La fermentation

Cette étape consiste à ensemencer le moût avec une certaine quantité de levures afin que ces levures transforment les sucres présents en alcool et en CO2 (GAZ de fermentation). Puis laisser la cuve à température ambiante durant 3 semaines.

7. L’embouteillage

La dernière étape du brassage : l’embouteillage. La mise en bouteille est l’étape ultime, celle qui termine votre brassage et qui va permettre à votre bière d’évoluer en ajoutant du sucre. Ensuite, il va falloir attendre 3 semaines pour enfin pouvoir la déguster.

Conclusion

Ce projet nous a permis de mettre en pratique les notions de supervisions et d’automatismes que nous avions reçu durant l’année. Et nous à permis de mieux programmer des régulateurs PID, de nous familiariser avec des schémas électriques ainsi que d’apprendre à manager notre temps pour respecter la durée de fermentation de la bière.

Ce projet à été assez lucratif pour nous. Nous avons pu découvrir l’univers complexe de la fabrication de bière ainsi que d’avoir la chance de goûter notre propre bière.

Comme solution futur nous proposons :
  • Une automatisation de la phase de filtrage
  • Une intégration du capteur de température à la cuve
  • L’intégration d’un afficheur plus performant
  • Réaliser un système de refroidissement automatique

Groupe de projet :

Loyna WALTER

Anthony LITTERST

Hugo KLEIN

Silon RAPP


Banc de vision & convoyeur

Améliorer le projet du banc de vision déjà commencé, afin de le rendre plus ergonomique, facile d’utilisation et plus présentable lors de journées des carrières et journées portes ouvertes. Le Banc de vision s’inscrit dans le savoir-faire d’un apprenant en DUT Génie électrique et informatique industrielle. C’est une maquette miniaturisée d’une ligne de supervision, pour le traitement de matières d’œuvre, défilant sur le convoyeur.

Banc de vision & convoyeur

1. Étude du projet

Besoin du projet et objectifs : Pour ce projet il fallait modifier la partie hardware et software du banc ainsi que la structure même du banc.

Pour la partie hardware, nous voulions changer le câblage et la disposition de ce dernier.
Pour la partie software, nous voulions garder le corps principal du programme et ne modifier que la partie qui concerne l’avancement du tapis.
Enfin pour l’esthétique de la structure, il fallait la rendre plus portable et beaucoup plus sympathique à présenter.

2. Diagrammes Fonctionnels

Pour cette étude, nous avons réalisé deux diagrammes : Une bête à corne ainsi qu’un diagramme pieuvre.

3. Modification de la structure

Pour la modification de la structure, nous avons repris une ancienne maquette que nous avons entièrement refait. On a utilisé l’IUT Lab pour « reconstruire » notre structure.

Nous avons découper les barres en aluminium afin de les adapter à une largeur convenable pour notre banc, nous avons également découper les planches, recréer une vraie structure capable de pouvoir accueillir notre tapis roulant.

Pour ce qui est du câblage, nous sommes rester sur quelque chose de relativement simple, pour la partie commande, nous avons le driver qui va commander le moteur pas à pas pour l’avance du convoyeur, puis l’arduino qui va permettre de gérer ce driver, les leds et caméras.

Nous avons ensuite créer un synoptique pour nous aider dans le câblage, relativement simple comme il se compose de deux alimentations, un driver, un moteur pas à pas, un arduino, une caméra et deux bandeaux de leds.

Pour le câblage, nous avions anciennement tout regrouper sur une platine carrée placée sous la structure. Nous avons gardé la même approche sauf que nous avons adapter la platine pour notre structure. On est passé d’un carré à un rectangle et on a aussi enlevé quelques composants du câblage qui ne nous servaient plus.

Ancienne platine de câblage
Nouvelle platine de câblage

Comme on peut le voir ci dessus, nous avons grandement réduis ce câblage malgré le fait qu’il manque quelques éléments.

4. Modification du Programme

Pour ce qui est du programme, nous voulions garder le même étant donné qu’il fonctionne correctement. Seulement nous voulons changer la partie commande du moteur. Au lieu de gérer le moteur via des boucles on veut gérer ce dernier via les timers de l’arduino. C’est à dire à l’aide d’interruptions.

Malheureusement, ce programme ne suffisait pas et ne marchait pas pour gérer le moteur à l’aide d’interruptions.


Maquette didactique : Train épicycloïdal

Remerciements

Nous souhaitons dans un premier temps remercier l’IUT de Mulhouse, pour nous avoir permis de réaliser ce projet.

Nous remercions également tous nos professeurs pour les connaissances qu’ils nous ont transmis durant ces deux années de DUT GEII et GMP, M.Steger, M.Cudel, M.Tessier et M.Stoeffel pour l’accompagnement dont nous avons bénéficié tout au long du projet.

Les membres du projet sont les suivants :

  • LAEMLIN Maëlis ( élève de GMP )
  • FRITSCH Louise ( élève de GMP )
  • IERACI Hugo ( élève de GEII )
  • LATARD Nino ( élève de GEII )

Sommaire

  1. Visualisation du besoin
  2. Description/Constitution
  3. Choix du type de train épicycloïdal
  4. Choix du type de maquette
  5. Choix de l’orientation de la maquette
  6. Hypothèse : type de mesure
  7. Implantation des capteurs
  8. Présentation de la maquette complète
  9. Aperçu du programme
  10. Gantt prévisionnel
  11. Gantt final
  12. Conclusion
  13. Annexe : Vidéo

1 / Visualisation du besoin

2/ Description/Constitution

3/ Choix du type de train épicycloïdal

4/ Choix du type de maquette

5/ Choix de l’orientation de la maquette

6/ Hypothèse: type de mesure

7/ Implantation des capteurs

8/ Présentation de la maquette complète

9/ Aperçu du programme

10/ Gantt prévisionnel

11/ Gantt final

12/ Conclusion

13/ Annexe: Vidéo


RLI – SUPERVISION

INTRODUCTION

Durant notre cours d’Etude et réalisation, nous avons choisi le projet « Supervision de la salle de TP B018 ». Il est en effet possible de contrôler certains équipements électriques présents dans la salle directement depuis notre ordinateur.

Pour ce faire, nous allons procéder par étapes. Nous allons débuter par une étude complète de la salle afin de déterminer quels équipements pourront être supervisable. Ensuite, nous étudierons le moyen de communication entre notre ordinateur et les équipements et mettrons en place cette communication. Enfin, nous créerons une supervision claire et intuitive permettant à une personne ne faisant pas partie du projet de pouvoir contrôler les différents équipements facilement.

Une fois cette partie terminée, nous pourrons également mettre en place une serveur OPC UA qui nous permettra un contrôle plus rapide des équipements ainsi que la possibilité d’accéder à un navigateur internet depuis notre supervision.

ETUDE DE LA SALLE

Pour débuter ce projet, il était nécessaire d’étudier l’ensemble de la salle afin de sélectionner les équipements les plus pertinents à notre projet. Il a en effet fallu choisir les installations compatibles à la communication via le logiciel Indusoft.

Voici quelques équipements que nous avons choisi de superviser :

Maquette de voiture

Multiprise Netio

Banc de supervision

CONNEXION DES EQUIPEMENTS

Afin de connecter les coupleurs d’entrées et les équipements à notre supervision Indusoft, nous avons ajouté un driver MOTCP-MODBUS qui nous permettra de connecter la plupart de nos équipements. Chacune de nos variables devaient être connectées à la bonne adresse IP ainsi qu’à la bonne adresse d’entrée/sortie.

Fiche de driver MOTCP

Pour connecter notre supervision aux serveurs OPC UA et OPC DA, il nous fallait trouver l’adresse de ce serveur sur Indusoft. Ensuite, nous utilisions le logiciel KSP Client qui nous permettait de trouver l’adresse de chaque entrée et sortie des équipements reliés aux serveurs.

Table de connexion OPC UA

SUPERVISION DE LA SALLE

Il était important de créer une supervision de la salle simple à utiliser et intuitive. Ainsi, une personne n’ayant aucun lien à notre projet peut contrôler la salle sans difficultés. Nous avons donc créé une interface simple avec une navigation claire et simple entre les simulations des équipements.

Voici quelques pages de la supervision sur Indusoft :

Page d’accueil de NOTRE supervision

Supervision d’une voiture

Représentation du serveur OPC

MISE EN PLACE D’UN SERVEUR OPC UA

Pour finir notre projet, nous avons mis en place un serveur OPC UA. Nous avons utilisé un projet Automation Studio qui nous avons téléversé dans un automate. Cela nous a permis de créer le serveur. Nous pouvions alors visualiser les données présentes dans le serveur comme une horloge ou la mesure de la température du CPU.

Supervision du serveur OPC UA

Avec ce serveur, nous pouvions également permettre à l’utilisateur d’entrer un lien http et de naviguer sur le web dans l’interface de la supervision. Nous avons aussi ajouté des boutons dans lesquels nous avons prédéfinis des liens internet communiquant avec des sites crées spécifiquement sur le serveur OPC.

Interface lié au navigateur internet

CONCLUSION

Durant ce projet, nous avons put créer une supervision facile à utiliser et pouvant contrôler un grand nombre d’équipements présents dans la salle de TP. Pour cela, nous avons travaillé sur la connexion Modbus ainsi que sur les connexions OPC. Nous avons également mis en place un serveur OPC UA permettant à l’utilisateur de naviguer sur internet.

Afin d’approfondir ce projet, il pourrait être possible de retravailler sur certains équipements difonctionnels ou dont la communication était impossible via Indusoft. De plus, il serait possible de changer certains équipements liés à la multiprise Netio. Nous pouvons imaginer brancher un petit ventilateur, un panneau led affichant un message (GEII par exemple) ou bien un écran.

Pour finir, nous remercions Monsieur Merckle qui nous a guidé et aidé durant ce projet.

Equipe: HEGE Baptiste ; DOULA Zinedine ; JERBI Mohamed Amine


RLI – MOTEURS PAP

Introduction

Pour le projet d’ER du semestre 4, notre groupe a décidé de choisir comme thème l’exploitation de moteurs pas-à-pas, notamment via une maquette qui reprend la réalité des équipements en industrie.

Cette maquette est composée uniquement d’équipements industriels de marque B&R, une marque proposant des équipements d’automatisme et de supervision industrielle.

Elle permet dans un milieu éducatif, d’apprendre le fonctionnement d’un automate et, dans un milieu industriel, de contrôler des équipements, tout en offrant une mobilité élevée. Elle est composée d’un IHM (Interface Homme Machine) qui permet de créer un lien entre l’Homme et la Machine pour que l’Homme puisse contrôler et surveiller la Machine, d’un variateur qui sera l’intermédiaire entre l’IHM et les équipements, de boutons, d’un moteur PAP intégré et un capteur RFID.

Buts du projet

Exploiter au maximum les capacités des équipements de la maquette, pour pouvoir utiliser toutes ses fonctionnalités, et qu’elle puisse contrôler des moteurs PAP.

On cherche à comprendre les différentes chose qui puissent être faites avec la maquette, et comprendre comment contrôler les môteurs fournis.

Description des équipements hors maquette

Dans notre cas, nous avons dû utiliser des équipements externes à la maquette pour pouvoir exploiter la maquette au maximum. Nous disposons donc de 2 moteurs pas à pas externes.

Exploitation d’un moteur PAP via logiciel Automation Studio

Une fois que le variateur est mis en place et qu’il est bien relié au moteur il est possible d’effectuer un test afin de verifier qu’il n’y ait aucun problème avec ces derniers. Pour ce faire, il faut s’assurer que la CPU soit bien en mode RUN. Une fois que tout est prêt, il suffit d’être dans le centre de test afin de voir le bon fonctionnement de toute l’installation.

v

Une fois la phase de test faite, l’ajout de la librairie qui permet la programmation du moteur grâce à un bloc de fonction. Ce dernier contient toutes les variables permettant d’effectuer une action grâce au moteur.

Bloc de fonctionnement moteur PAP

Le moteur est donc controllé via des variable comme Update, MyVelocity, Home… COntenues dans la librairie.

Exploitation du moteur intégré

Tout d’abord nous avons voulu exploiter le moteur pas à pas présent sur la maquette. Nous n’avons réussi que à faire tourner le moteur partiellement : le moteur ne tournait pas continuellement.

Ceci est un problème auquel nous n’avons pas pu remédier.

Le problème provient des paramètres du moteur dans le logiciel Automation Studio, car le moteur se déplace avec des positionnements angulaires, et ce type de position nécessite plus de paramétrages, que nous n’avons pas pu faire.

Automate à partir d’un automate

Nous avons alors décidé avec l’aide et l’autorisation de Mr MERCKLE de relier le variateur de la maquette à deux autres variateurs qui sont externes à la maquette. Les modules E/S des deux variateurs sont chacun liés à un moteur.

Voici une capture du système vu sur logiciel :

Il faut faire attention à ne pas oublier d’insérer les variateurs, les modules E/S, les moteurs PAP, ainsi que les librairies pour chaque moteur (nous avons pu les ajouter à l’aide du tutoriel de MERCKLE).

Exploitation des boutons

Afin d’exploiter au maximum le module, nous avons décidé dans un premier temps d’ouvrir les pages de chaque moteur et une page générale avec les 3 boutons physiques. Cependant, il était impossible, car les fonctionnalités du module restaient un minimum limité.

Pour exploiter tout de même les boutons, nous avons décidé de donner comme utilité aux boutons, le contrôle des équipements. Il y a de nombreuses possibilités (en fonction des équipements) dans notre cas (moteur PàP), car à l’aide des boutons nous pouvons faire de nombreuses actions : changer de direction, allumer le moteur, lancer la rotation du moteur, Remettre à 0 la valeur de la position, actualiser les valeurs des variables moteurs (UPDATE), etc…

Voici un schéma démonstratif des nombreuses possibilités :

Simplification de l’interface

our pouvoir utiliser simplement et efficacement le moteur, nous avons mis en place une interface avec 4 pages au total :

– 1 page d’accueil avec bouton Général et Moteur 1/2

Page 1 de l’IHM

– 1 page générale (ensemble des moteurs)

Page 2 de l’IHM

– 1 page pour chaque moteur et toutes leurs fonctionnalités.

Page 3 de l’IHM
Page 4 de l’IHM

Les boutons entourés d’un rectangle noir ont un voyant qui peut s’illuminer de 2 couleurs : Rouge si une variable n’est pas à jour ou n’est pas prête, et Vert si une variable est à jour ou prête.

Exemple 1 : Si le moteur est allumé, le cadre du bouton POWER sera Vert. Si le moteur est éteint, le cadre sera Rouge.

Exemple 2 : Si la position est remise à 0 en cliquant sur RESET POSITION, le cadre de ce bouton sera Vert, sinon ce sera Rouge.

Dans notre cas, les variables UPDATE (qui actualise les valeurs de la variable) sont affectées aux boutons physiques, comme dans l’exemple du schéma dans la partie « Module de boutons ».

Support de maquette sur-mesure

Pour utiliser confortablement la maquette, nous avons crée un support sur-mesure afin de consolider l’ensemble et de le transporter sans s’inquiéter d’abimer un câble ou un composant.

En effet, les câbles lorsque la maquette est posée sur une surface plate, se frottent contre celle-ci, et avec le temps, risquent de s’abimer et donc de causer des problèmes sur le fonctionnement global de la maquette.

Le support permet de tenir la maquette inclinée, offrant une meilleure vue de l’ensemble et principalement de l’IHM.

Capteur RFID

Ce capteur aurait donné d’autres fonctionnalités à cette maquette : possibilité de se connecter à un utilisateur précis via ce capteur, activer ou désactiver le mode Manuel, allumer/éteindre les moteurs, faire office d’arrêt de secours, etc…

Nous pouvions exploiter le capteur RFID, pour permettre seulement aux utilisateurs munis d’un badge à induction, d’utiliser l’interface de la maquette.

Mais malheureusement nous ne disposions pas de badges à induction lors de la réalisation de notre projet.

Couplage des deux moteurs

Capture d’un bloc fonction permettant le couplage des moteurs Les 2 moteurs tournant individuellement, montrent le bon fonctionnement de ces derniers. Suite à cela, une nouvelle exploitation aurait pu être faite : Le couplage des moteurs. Cela consiste à faire tourner un des moteurs grâce à la rotation effectuée par l’autre.

Plus précisément, lorsque le premier moteur dit « Moteur maitre » est en rotation grâce à la programmation d’un bloc de fonction prévue pour le couplage des deux, le deuxième dit « Moteur esclave » sera entrainé par la rotation du premier. La programmation de ce bloc permettrait de choisir les sens de rotation du deuxième moteur en fonction du premier.

Avec les bonnes valeurs le premier moteur pourrait faire tourner le deuxième moteur dans le même sens, ou bien dans le sens opposé.

Conclusion

Le but de ce projet étant d’exploiter un maximum la maquette, nous avons pu en exploiter 70%. Les exploitations éventuelles comme celles du couplage, et le changement de pages avec les boutons physiques auraient peut-être été faites avec légèrement plus de temps.

Avec une recherche plus détaillée et plus d’éléments, une exploitation du capteur RFID aurait pu être faite, mais le résultat final est que l’on connaît son utilité et son fonctionnement, et que sa mise en place du aurait certainement été rapide.

Nous tenons a remercier comme il se doit Mr. MERCKLE pour son soutien et son apport de connaissance qui nous a énormément aidé à mener à bien ce projet, et Mr. DE SABBATA pour l’aide à l’IUT Lab lors de la réalisation de la maquette.


RLI – MOTEURS ASYNCHRONES

Système permettant la commande des moteurs asynchrones

INTRODUCTION

Pour notre projet d’étude et réalisation, nous avons choisis de réaliser la « Commande de moteurs asynchrones ». La possibilité de contrôler des moteurs asynchrones sur un système peut nous permettre d’imaginer de multiples idées d’améliorations par la suite.  

Mais avant cela il fallait tout d’abord  faire tourner ces moteurs correctement, telle était notre objectif de base, mais voulant aller plus loin nous envisagions de faire le couplage des moteurs asynchrones. 

Ce projet consiste à aboutir un précédent projet effectuer par des étudiants de l’an passé qui n’ont malheureusement pas pu finir ce dernier pour cause de crise sanitaire. On a donc pris la relève et en partant des études qu’ils ont pu réaliser, nous avons dû finaliser le projet.  

Il a fallu reprendre les documents rédigés par ce groupe pour, au préalable, nous familiariser avec ce projet et ainsi pouvoir travailler dans des conditions idéales au bon développement et finalisation de ce projet.  

Études réalisées 

Plusieurs études ont été effectuer afin de faciliter la réalisation du câblage.

À l’aide du logiciel QElectrotech, nous avons pu réaliser un schéma électrique au propre.  

Schéma électrique

Nous avons pratiquement obtenu un résultat avec tous les symboles normalisés, cependant, certains symboles tels que le variateur et les colonnes lumineuses ne sont pas disponible dans le logiciel. Il n’y a donc pas pu avoir intégration de ces derniers sur le schéma. Pour pallier cela, des blocs explicatifs ont été rajoutés pour combler le vide. 

Par ailleurs, après plusieurs vérifications, nous avons réalisé un schéma de câblage.

Schéma de câblage
Schéma de câblage tableau électrique.

Voulant avoir un retour sur l’état de notre système, nous avons dû faire une étude sur les colonnes lumineuses afin de pouvoir les intégrer au système.

Cela se traduit tout d’abord de la réalisation d’un code couleur.

Code couleur colonne lumineuse

Il faut savoir que les colonnes lumineuses comportent plusieurs câbles de différentes couleurs. Il a donc fallu trouver à quelles entrées du variateur devaient être relié chacun de ces câbles.  

Tableau récapitulatif des liens colonnes/variateurs

Notre système est alimenté en 230 V, c’est pourquoi il a fallu étudier comment coupler chacun des moteurs. La plaque signalétique du moteur (voir annexe) nous indique que pour une alimentation en 230 V, le moteur doit être couplé en triangle. Pour coupler le moteur en triangle, il est indiqué sur le couvercle des moteurs que pour avoir un couplage triangle, il faut placer des barres de cuivres comme sur l’image suivante. 

Plaque signalétique du moteur 
Couplage triangle d’un moteur

Réalisation du câblage 

Notre câblage, c’est dérouler en deux parties. La première partie consistait à câbler la partie du bas de notre tableau électrique.

Tableau électrique mis à notre disposition au départ
Câblage contacteurs, disjoncteurs, boutons M/AU par l’intermédiaire de borniers

Une fois ce câblage réaliser, nous avons pu effectuer un test permettant de vérifier le bon fonctionnement de notre câblage mais aussi de ces composants. Pour réaliser ce test, nous avons directement alimenter cette perte du système à partir d’une prise secteur.

Première partie de câblage réaliser

Le test réussis avec succès, nous avons alors pu continuer notre câblage et donc passer à la deuxième partie.

Câblage permettant de lier la partie du haut et la partie du bas de notre tableau électrique.
Câblage du moteur
Système complètement terminer

Développement d’un programme  

Le programme nous permet de contrôler un moteur sur plusieurs plans. L’affichage ci-dessous est l’interface homme-machine permettant le contrôle du moteur par un individu. Entre autres, avoir la main sur sa vitesse de rotation, à l’aide du potentiomètre, mais également sur son sens de rotation et son arrêt.

Conclusion 

Durant ce projet, nous avons dû effectuer un contrôle des moteurs asynchrones sur notre système.

Afin de réaliser au mieux ce projet, nous avons dû anticiper le matériel nécessaire, réaliser un schéma électrique adapté à notre système, réaliser également un schéma de câblage pour par la suite câbler le système de la manière la plus optimale. Par ailleurs, une étude sur la partie programmation a été effectué de pouvoir réaliser les tests adéquats.

Une amélioration possible à ce projet pourrait être la réalisation d’un programme permettant le couplage des deux moteurs asynchrones. 

Pour finir, nous voulons remercier Mr. Merckle pour son aide, ses conseils, sa présence tout au long de notre projet. 

Equipe: YAGOUB Walid ; ZAID EL KHIL Nathan ; DEKKARI Younes

 


RLI – MOTEURS CC

Remerciements

Nous voudrions premièrement remercier M. MERCKLE, notre professeur d’Etude et Réalisation qui nous aura de nombreuse fois aidé dans ce projet. Mais également M. De SABBATA sans qui nous n’aurions pas eu accès aux outils nécessaire pour réaliser ce projet. Et enfin M. VERRON qui nous aura lui aussi grandement aidé lors de la réalisation des circuits imprimés.

La finalité de ce projet est de permettre le contrôle de 2 moteurs Courant Continu à partir d’une visualisation sur un ordinateur.

Figure 1: Système final

Voici le cahier des charges de ce projet :

  • Etudier la borne moteur ainsi que les capteurs.
  • Réaliser un schéma de la maquette
  • Choisir et commander le matériel manquant (s’il y en a)
  • Elaborer un programme test
  • Développer une application complète.

Matériel

Pour réaliser ce projet, voici le matériel que nous avions à disposition :

Maquette
L’objectif premier étant la réalisation de la maquette (sans celle-ci, impossible de pouvoir effectuer le moindre test), il était donc impératif de la commencer le plus tôt possible.
Nous avons alors réalisé une première maquette pour supporter les moteurs, ainsi que souder des câbles aux moteurs afin de permettre leur connexion à l’automate.

Programmation

Dans ce projet, la programmation a pour but d’apporter à l’utilisateur une interface de commande
fiable, ergonomique et intuitive.
La première étape était le design de la visualisation

1 : Cette zone permet de revenir au
menu principal.
Elle montre également les erreurs de
surintensité potentielles, l’état du
module et également la date et heure
actuelle.
2 : Il est possible de commander les
moteurs à partir de ces boutons,
sliders, et champs d’entrées.
3 : La représentation physique des
moteurs est visualisable dans cet
espace. Par soucis de temps il n’a pas
été possible de développer cette
fonctionnalité, elle reste cependant

La visualisation devra supporter plusieurs types de commandes :

  • Une commande manuelle permettant de contrôler chaque moteur indépendamment par
    modulation d’impulsion (PWM) avec en plus, la possibilité de choisir le sens de rotation.
  • Une commande temporelle, capable de faire tourner chaque moteur pour un temps donné (en
    utilisant pour base de temps celle de l’automate)
  • Une commande asservie qui utilisera des capteurs de proximité pour détecter le nombre de tours
    que fera chaque moteur.

Electronique


La partie électronique du projet à pour rôle d’assurer le bon fonctionnement de la maquette et
de permettre une utilisation fiable.
L’électronique est elle-même répartie en deux parties :

  • Motorisation
  • Capteur

Motorisation
La motorisation s’articule autour des deux moteurs et des ports de contrôle du module
automate. Chaque moteur à une tension d’alimentation de 24V et un courant absorbé à vide d’environ 80mA, le module automate ayant une limite de courant de 3,5A par moteur, le système aurait été capable normalement d’actionner les moteurs sans difficulté.
Toutes fois, en raison du pique de courant demandé par les moteurs au démarrage, il nous était impossible de lancer les moteurs (Voir Problème Rencontrés).
Pour résoudre ce problème, nous avons alors connecté une résistance de 5,6Ohm en série de chaque moteur pour réduire le pique de courant et ainsi permettre le démarrage des moteurs.

Capteur
Les capteurs ont pour but de retourner les informations sur la position/Vitesse des moteurs à la manière d’un encodeur et/ou codeur incrémental.
Nous utilisons pour ce projet des capteurs Infra-RougeIR (TCRT5000L) ainsi que des disques amovibles ayant une découpe particulière suivant la manière dont on veut se servir des capteurs (position initial,
vitesse, sens, …).

Conclusion

Atteinte des objectifs
La date de fin de projet étant maintenant passée, il était essentiel de faire un point entre les attentes et la réalisation effectuée.

En reprenant depuis le début, l’étude de la borne moteurs ainsi que celle des capteurs a été une grande réussite car sans cette étape, nous n’aurions pas pu aller aussi loin.

La structure physique du projet (support + électronique) a elle aussi été une réussite. Cette structure permet d’obtenir une grande facilité d’utilisation, de plus, son côté modulable permet de remanier ce projet dans son entièreté, il est donc très aisé de rajouter des composants ou modules afin d’ajouter de nouvelles fonctionnalités.

Pour finir, il reste l’aspect software (programmation + interface utilisateur). Tout n’a pas pu être entièrement complété, comme la détermination de la vitesse de chaque moteur, ou bien la représentation de la position et rotation sur la visualisation. Cependant, les objectifs clés, tels que la commande manuelle, temporelle ou bien asservie ont, eux, été réalisé.

Ce projet n’aura donc pas été réalisé à 100% mais une grande majorité aura elle, bien été faîtes. Ces quelques éléments manquants pourront par la suite faire place à une phase d’amélioration de ce projet.

Améliorations

Nous avons jusqu’ici réalisé une grande majorité de nos objectifs. Cependant, il reste de nombreuses améliorations à apporter à ce projet.

La maquette a été conçue de sorte que chaque moteur puisse être utilisé avec 2 capteurs. Il est donc désormais possible de déterminer la vitesse de rotation d’un moteur et de l’afficher sur une page de la visualisation. On pourrait également créer une nouvelle commande de moteur avec cette fois la vitesse pour ordre.

Sur les visualisations déjà créées (Voir Figure 3) on retrouve un emplacement central destiné à représenter la position et rotation en temps réelle des moteurs. Par soucis de temps, cet objectif n’aura
pas été atteint mais peut néanmoins servir d’améliorations à ce projet.

Et enfin, l’amélioration la plus ambitieuse, serait la conception puis réalisation d’un bras robotisé a 2 axes de rotation. Ce bras permettrait le déplacement sur axe à 2 dimensions. Il pourrait par exemple
tenir un marqueur et dessiner sur un support que ce soit par commande manuelle ou bien par une succession d’instructions prédéfinies.


EXTENSION D’UNE ARCHITECTURE CANOPEN SUR SERVEUR OPC DA

SOMMAIRE

  1. INTRODUCTION
  2. CANopen
  3. etc…

1. INTRODUCTION

Durant ce projet, nous allons devoir compléter l’architecture d’un serveur OPC DA. Ce serveur OPC existant déjà, nous allons y ajouter des équipements CANopen que nous allons pouvoir superviser à distance. Pour cela, nous avons différentes tâches à effectuer pour pouvoir finaliser le projet.
Tout d’abord, il faut savoir que nous allons utiliser le logiciel Automation Studio qui est un logiciel de conception de circuits, de simulation et de documentation de projets. Nous utiliserons également le logiciel InTouch nous permettant de faire de la supervision industrielle et de commander notre système à distance.

2. CANopen

Le protocole CAN, initialement créé pour le marché de l’automobile, est un Bus qui priorise les messages sans altérer ou détruire la requête. Il intègre la 2ème couche du modèle OSI alors que la plupart des protocoles se limitent à la 1ère couche.
Ensuite, nous allons mettre en place le module CANopen sur notre système et le paramètrer. CANopen permet de garder un profil standard dans les systèmes de contrôle industriel. Il convient aux automates en temps réel car c’est une solution efficace destinée aux applications industrielles.
Sur ce module, nous allons y brancher quatre équipements de différents fabricants. Nous commencerons donc par un équipement d’un fabricant en le paramétrant pour le tester grâce au server OPC puis en y ajoutant une supervision. Nous répéterons cette opération avec 4 equipements (Entrée/Sortie) de 4 fabricants différents et un dernier équipement qui sera un variateur.

Représentation du modèle OSI pour les couches relatives à CANopen (couche 7). Les couches 1 et 2 étants relatives au bus CAN.
Le concept CANopen repose sur un dictionnaire d’objets renseigné par l’interface de communication et appliqué aux entrées/sorties de l’équipement.
Schéma de principe du serveur de communication multi-protocoles. Il échange des données avec le process via différents protocoles industriels (Ethernet et bus de terrain). Les clients, type supervision, peuvent visualiser et piloter les variables du serveur indépendamment des protocoles utilisés.
Concrètement, le serveur OPC multi-protocoles est un API B&R avec des coupleurs maîtres en CANopen, Profibus, ASI, IO-Link etc.
Voilà l’état du projet au départ. L’automate, via le réseau Powerlink, pilote un module d’extension déporté. Ce module dispose, à gauche, d’un coupleur CANopen Maître avec un 1er coupleur esclave (I/O B&R).
L’état du projet final fait apparaître 4 équipements supplémentaires
(WAGO, PROFACE, SCHNEIDER, ALTIVAR) en plus des I/O B&R

APPLICATION DE SUPERVISION D’ÉQUIPEMENTS

Introduction

Notre projet consistait en la gestion de tout les équipements de la salle contrôlable en Modbus. Dans le cadre des études et réalisations des semestres 3 et 4, nous avons eu l’occasion de développer une application de test et de contrôle de l’ensemble des équipements présents dans la salle B018 (salle de Réseaux), par le biais du protocole Modbus/TCP avec une visualisation VNC. Pour mener à bien ce projet nous avons eu recours au logiciel Automation Studio qui nous a permis d’effectuer les différents essais et applications.

Comme le montre ce schéma, on va se servir d’une interface qui apparaîtra sur le PC, cependant tout le programme sera exécuté dans l’automate à l’adresse 200.200.200.175 qui, lui, contrôlera les équipements et nous permettra d’avoir une visualisation sous VNC (l’automate est serveur VNC, le PC, lui, est client VNC). La liste des équipements est la suivante, accompagnés de leur adresse IP dans la salle.

Intitulé : Modules : @IP :
Colonne Lumineuse MOXA .252 :2
Lampes Fluocompactes WAGO .215
Portique 206 WAGO .214/.219
RECDIGIT WAGO .210 :6
JANITZA JANITZA .251
WAGO 352 WAGO .179/.189/.199
BC0087 B&R .243/.244/.245
CIE-H10 SOLLAE .240
WAGO 841 WAGO .216/.217/.218
WAGO 315 WAGO .210 :9
CPU CP3586 .176
Modélisation du réseaux Modbus

Fonctionnement Modbus

Généralités

Le Client, par l’intermédiaire d’une trame requête, va envoyer des informations aux serveurs, dans notre cas, nos équipements. Les serveurs, à leur tour, vont répondre par le biais d’une trame réponse pour envoyer les informations demandées ou les actions demandées.

Avec Automation Studio, pour gérer la communication Modbus, nous allons créer les équipements et leurs attribuer une adresse IP. Au niveau de la configuration, nous allons créer des blocs qui seront composés d’un ou plusieurs « channels ». Ainsi, ces « channels » apparaîtront dans la gestion des entrées et sorties et auront donc une variable associée.

Modes de fonctionnement

Les échanges entre l’automate Client et les équipements serveur peuvent se faire de plusieurs façon, suivant le mode sélectionné lors de la configuration. Cyclique, Non-Cyclique ou bien Send Once.

Mode cyclique :

En mode cyclique, la communication est toujours active et va renvoyer constamment la valeur. On peut ici voir lorsque la valeur est a 1 on envoie 1.

Mode non-cyclique :

En mode non-cyclique, il y aura une valeur (ici, le bouton) qui va décider d’activer ou non la communication. Lorsqu’elle est active, elle fonctionne comme en mode cyclique. Lorsqu’elle est désactivée, la communication s’arrête et la valeur va se figer. La LED va donc rester allumer jusqu’à l’ordre d’arrêt.

Mode Send Once :

En mode « SendOnce », grâce au petit bout de programme (ci-dessus), nous n’occuperons la communication que lors de l’envoi (ou de la réception). En effet, quand « SendOnce » passe à 1, nous envoyons nos valeurs. Dans notre cas, vu qu’on veut envoyer la valeur de notre bouton, nous allons attendre un front sur celui-ci. Quand un front sera détecté, nous allons faire passer « SendOnce » à 1, ce qui permettra d’envoyer la valeur que le bouton aura pris. « SendOnce » ne repassera pas à 0 automatiquement, c’est pourquoi, on attend l’acquittement, qui passe à 1 seulement si les valeurs sont bien reçues par l’équipement. Une fois l’acquittement reçu, on remettra « SendOnce » à 0. Quant à l’acquittement, il repassera automatiquement à 0.

Visualisation

Nous pouvons voir ci-dessus, le menu général de notre tableau de bord. Un simple clic sur n’importe quel équipement vous amènera à une page détaillée. Nous avons disposé des témoins lumineux sur chaque équipement afin de vérifier l’état de celui-ci, repérés par leur adresse IP. Nous avons aussi regroupé les appareils similaires entre eux par souci d’ergonomie.

Par exemple lorsqu’on cliquera sur « Colonne Led » on aura la page ci-dessous (à gauche) qui permet de contrôler les trois lumières, une lumière par bouton. Et si l’on clique sur « Wago 841 » on aura la page ci-dessous (à droite) qui permet de contrôler 3 Wago différent et donc de contrôler leur sorties ainsi que de visualiser leurs entrées.

Module Janitza

Le module Janitza est un appareil de mesures intégré dans le réseau électrique de la salle de classe. Il est capable de mesurer des dizaines de grandeurs physiques. Nous l’avons configuré pour en transmettre 22 sur notre visualisation. Celle-ci affiche ces grandeurs selon deux modes de fonctionnement :

Le mode de visualisation en « temps réel », où l’évolution sur les graphiques se fait en continu par rapport aux mesures. Cela est réalisé grâce à la lecture des ports du Janitza associé à chaque grandeur physique.

Le mode de visualisation « historique », où les graphiques sont figés, représentant une évolution ayant eu lieu dans le passé. Ce mode de visualisation est plus pratique pour étudier ces mesures, et est permis grâce à la lecture d’un tableau préalablement rempli et donc les valeurs ont été stockées sans avoir été écrasées.

Nous avons configuré cet appareil de telle sorte à ce qu’il puisse nous communiquer :
La fréquence du réseau
Les intensités des courants sur chacune des trois phases
Les tensions entre chacune des phases et entre chacune de ces phases avec le neutre
Les puissances réelles, actives, réactives et le cos φ sur chacune des phases

Ainsi, il convenait de pouvoir visualiser toutes ces mesures grâce à notre application VNC. Voici un extrait de notre visualisation en temps réel :

Comme l’indique l’échelle à l’horizontale, les mesures en continu s’étalent sur 5 minutes avant de progresser en écrasant les mesures les plus anciennes : le fonctionnement est dit « dynamique »

Ci-dessous, vous pouvez vous apercevoir que les valeurs relevées sur les graphiques (partie de droite) correspondent, en temps réel, avec celle qu’indique le module Janitza via ses ports, chacun associés à une grandeur physique (partie de gauche – visualisation en mode monitoring du mapping du Janitza).

Ensuite, la visualisation « historique » consiste en la lecture de tables, une pour chaque grandeur physique, servant de lieu de stockage aux variables.

Ainsi, sur le graphique suivant vous pouvons observer un graphique en cours de remplissage :

Graphique affichant la lecture du tableau en cours de remplissage
Voici la table associée au fréquence, en cours de remplissage, comme en atteste les cases encore vide au moment de la capture, à partir de la 17ème case. Ainsi, le graphique plus haut se rempli au rythme de celui-ci et arrêtera de progresser au même moment

Module NetIO4ALL

Un autre appareil était directement lié au module Janitza, il s’agit de la multiprise NetIO4All. Cette multiprise est commandable à distance, et permets d’appliquer des charges supplémentaires sur le réseau. Grâce à cet appareil on a pu effectuer des tests en envoyant des charges sur le réseau et en observer l’impact sur les mesures du Janitza, vérifiant que l’on pouvait observer les modifications sur nos graphiques.

A gauche, la page d’accueil de la commande de l’appareil sur l’application VNC. A droite, une photographie de l’appareil.

Il convenait de configurer quatre commandes sur chacun des quatre Channels (les quatre prises) du module :
Une commande ON/OFF classique
Une commande ON DELAY, lançant le système pour un temps bien précis
Une commande OFF DELAY, eteignant le système pour un temps bien précis
Une commande TOGGLE, lançant le système lorsqu’il est éteint et l’éteignant lorsqu’il est en fonctionnement
De plus, pour les deux modes DELAY, nous devons pouvoir choisir le délai grâce à une fenêtre d’écriture numérique et un bouton UPDATE pour valider notre choix.

Ensuite, nous avons trois fenêtres d’affichage en temps réel pour les valeurs suivante : le courant, la puissance et l’énergie générés par la prise commandée.

Conclusion

Cette application répond maintenant au cahier des charges lié au projet. Elle permettra de rapidement voir l’état des équipements en ModbusTCP, et ainsi les nouveaux étudiant pourront rapidement voir les équipements Modbus de la salle, ainsi que ce que l’on peut faire avec ce protocole. En effet pour expliquer quelque chose comme un protocole c’est beaucoup plus agréable d’avoir un exemple, de plus il est possible d’observer les trames sous Wireshark. Cependant, pour éviter d’avoir trop de problème, l’automate n’accepte qu’un seul client VNC à la fois.

Ce projet se sera révélé très intéressant car il nous aura permis d’encore plus explorer les réseaux d’automates industriels. En effet, les TP ont été beaucoup moins poussés que le projet que nous avons fait. De plus, nous avions, lors du semestre 2, pu installer et configurer des automates. Ces deux projets, en plus des cours, nous donnent un véritable bagage pour le domaine de l’automatisme industriel.

Pour finir, nous tenons à remercier, bien évidemment, M.MERCKLE pour sa présence et, surtout, sa disponibilité nous permettant de parfois trouver des solutions à nos problèmes grâce à ses connaissances qui étaient plus étendues sur le sujet.


PILOTAGE SYNCHRONISÉ DE MOTEURS ASYNCHRONES

Synthèse du projet de pilotage synchronisé de moteurs asynchrones

Sommaire

  1. Introduction
  2. Cahier des charges
    1. Bête a corne
    2. Diagramme pieuvre et Tableau des fonctions
  3. Étude de l’installation
    1. Ancienne installation
    2. Installation actuelle
  4. Développement du pilotage synchronisé
    1. Moteur asynchrone
    2. Moteur Pas à Pas
    3. Servomoteurs
  5. Conclusion
  6. Annexe

1.Introduction

Dans le cadre de notre projet d’étude et réalisation, nous avons réalisé un projet permettant la commande synchronisé de deux moteurs asynchrones. Ce projet à été fait durant le Semestre 3 et 4. Nous avons eu pour objectif d’élaborer un banc d’expérimentation et de démonstration du contrôle de mouvement synchronisé basé sur deux moteurs asynchrones. Lors de ce projet nous avons 2 grandes parties qui ce sont dégagées. Nous avions une première partie sur l’étude et la réalisation de l’installation. Celle-ci consistait à étudier l’ancienne installation ayant seulement un moteur asynchrone, puis dans un second temps réaliser l’installation complète ayant deux moteurs asynchrones. La seconde partie concerne le développement des commandes pour les moteurs asynchrones. Pour cela nous avons tous d’abord étudié et développé des commandes de base sur différents types de moteurs. Puis dans un second temps nous avons développé les commandes et la visualisation des moteurs asynchrones avec leurs colonnes lumineuses.

Récapitulatif de l’ensemble de l’installation avant/après

Cahier des charges

Bête a corne

Ce projet doit permettre la synchronisation du mouvement de deux moteurs asynchrones grâce au contrôles de commandes

Diagramme pieuvre et Tableau des fonctions

FP1: Contrôle de mouvement synchronisé des moteurs : Pouvoir contrôlé la synchronisation des moteurs

FP2: Opérateurs : Permettre une utilisation facile des commande

FC1: Alimentation 230V triphasé : Alimenter l’installation en 230V triphasé

FC2: Ethernet Powerlink : Communiqué grâce à Ethernet

FC3: Normes : Respecter les normes de protection et de sécurité

FC4: Visualisation des commandes : Avoir une visualisation complète et fonctionnelle

Étude de l’installation

Ancienne installation

Dans un premier temps nous avons étudié l’ancienne installation. Cela avait pour but de comprendre le fonctionnement de l’installation ainsi que de connaître les principaux composants de celle-ci. Par la suite nous avons fait un croquis de l’installation pour avoir un schéma propre et compréhensible.

schéma de l’ancienne installation

A la suite de ce schéma nous avons réalisé plusieurs autres schémas allant de la partie alimentation à la partie commande du moteur. Lors de l’étude de la partie alimentation, nous nous sommes aperçus que certains équipements étant assez anciens ont dû être changés. L’installation est alimentée par un transformateur triphasé produisant du 230V. Le moteur asynchrone est câblé en couplage triangle. Pour la partie commande, nous avons remarqué que la boitier de marche/arrêt est alimenté par une phase du 230V triphasé.

Schéma de l’intérieur du boitier Marche/Arrêt

Sur le schéma ci-dessus nous avons le boitier Marche/Arrêt ainsi que son équipement de sécurité qui sont représenté. Nous pouvons voir que KM1 et KM2 permettent la connexion des différentes phases pour alimenter le variateur du moteur asynchrone. Nous pouvons voir que le contacteur permet de faire la connexion entre la partie puissance et la partie commande de l’ensemble variateur/moteur.

Installation actuelle

Après avoir étudié l’ancienne installation, nous avons conçus le schéma de la nouvelle installation. Celle-ci ressemble à l’ancienne installation avec quelques modifications.

Schéma de la nouvelle installation

L’installation permettra de piloter deux moteurs asynchrones avec deux variateurs. Pour cela nous avons juste à réalisé l’installation en double comme sur le schéma ci-dessus. Les boitiers de Marche/Arrêt ne seront plus alimentés par une phase du 230V triphasé mais ils seront alimentés en 24V. Pour cela nous devons intégrer un transformateur 230/24V. Celui-ci permet d’avoir 230V au primaire et 24V au secondaire. Nous avons rajouté deux disjoncteurs, le premier en amont et le second en aval du transformateur.Cela permet la protection des boitier Marche/Arrêt. Le reste de l’installation reste en 230V triphasé. Son fonctionnement reste similaire à l’ancienne installation. Les deux nouveaux ensembles variateurs/moteurs sont installés sur une même grille, pour avoir les deux ensembles côte à côte.

Développement du pilotage synchronisé

Moteur asynchrone

Nous avons commencé à étudié le pilotage du moteur asynchrone grâce à un ancien projet d’étudiants. Cela nous a permis de prendre en main le logiciel Automation Studio. Par la suite nous avons étudié les commandes existantes permettant de contrôler le moteur en créant une configuration permettant de relier la partie matérielle a la partie logicielle comme on peut le voir dans l’image suivante.

Pour pouvoir interagir avec le moteur, nous avons testé toutes les commandes étant déjà en place sur l’interface Homme-Machine. Nous pouvions par exemple démarrer,arrêter où choisir la vitesse de rotation du moteur. Par la suite nous avons améliorer le programme ainsi que l’interface. Nous avons ajouté et vérifié si toutes les variables étaient correctes et nous les avons fait apparaître sur l’interface.

Visualitation IHM

Ci-dessus nous avons l’interface Homme-Machine du moteur asynchrone. Pour pouvoir démarrer le moteur nous devons suivre quelques étapes. Tous d’abord la variable « MpAxisBasic » doit être activé. Elle permet de contrôlé l’axe du moteur et à été ajouté par nos soins pour pouvoir choisir le type d’axe que nous voulons pour plus tard. Puis la variable « Power » doit être activé ainsi que la variable « Home ». La variable « Power » met le moteur en marche et la variable « Home » met le moteur en position initial. Puis nous mettons en marche la variable « Move Velocity » qui va faire tourner le moteur si une valeur est donnée. Nous avons un graphique qui trace l’évolution de la vitesse du moteur en fonction du temps. Par la suite nous avons rajouté 2 nouvelles variables une pour la décélération et une pour l’accélération. Nous pouvions donc entrer une valeur dans ces deux variables et voir que le graphique changeait selon les valeurs rentrées. Pour arrêter le moteur nous avions la variable « Stop » et si un problème survenait nous avons la variable « ErrorReset » qui permettait de remettre à zéro toutes les variables pour pouvoir redémarrer le moteur.

Moteur Pas à Pas

Après avoir étudié le moteur asynchrone, nous nous sommes intéressés aux moteurs Pas à Pas. Nous nous sommes aidés de l’interface faite précédemment pour cette partie. Dans cette partie nous devions créer et utilisé une visualisation comportant 2 couplages. Nous aurions le choix entre un couplage linéaire et un couplage CAM entre les deux moteurs. Nous avons réutilisé le programme et les blocs utilisé dans la partie précédente pour vérifier le bon fonctionnement des moteurs. Pour la suite de cette partie nous avons créer 2 blocs permettant de contrôler un moteur chacun et un troisième bloc pour gérer le couplage entre les deux moteurs.

2 blocs MpAxis_0 et MpAxis_1 pour la commandes de 2 axes et un bloc MpAxisCouplig pour le couplage entre les 2 axes

Le premier bloc nommé « MpAxisBasic_0 » permet de contrôle l’axe d’un des deux moteurs, celui-ci servira d’axe maître. Les 3 variables les plus importantes de ce bloc sont encadrer en rouge. La première variable « gMpLinkAxe2 » permet de gérer la mise en route du moteur maître. La seconde variable « AxisPar2 » quand à elle permet de gérer les réglages du moteur (sens de rotation,vitesse de rotation…). Puis la dernière variable « gAxis03 » permet l’identification de notre axe maître par rapport à l’axe esclave. Nous avons un second bloc similaire appelé « MpAxisBasic_1 » qui permet de contrôler le second moteur.

Le second bloc nommé « MpAxisCoupling » permet de contrôlé l’axe et le couplage du moteur esclave. Nous aurons le choix entre le couplage linéaire ou le couplage CAM. Le couplage linéaire ressemble à des roues dentées de son fonctionnement donc nous choisissons la vitesse de multiplication de l’axe esclave par rapport à l’axe maître. Cette axe suis les besoins de l’axe maître mais est plus difficile à mettre en place pour un mouvement balancier. Contrairement au couplage linéaire, le couplage CAM est quand à lui beaucoup plus performant. Ce couplage permet d’utilisé n’importe qu’elle sens de manière précise et efficace. Les 3 variables les plus importantes sont aussi encadrées en rouges. La première variable « gMpLinkAxe1 » permet de gérer la mise en route du moteur esclave. La seconde variable « AxisPar3 » quand à elle permet de gérer les réglages du couplage. Puis la dernière variable « gMpLinkAxe2 » permet la représentation de l’axe maître que l’axe esclave va devoir suivre.

Après avoir crée les différents blocs nous avons introduit les nouvelles variables sur l’interface. Nous avons une partie pour activer et commander l’axe maître. Puis nous avons une seconde partie pour activer l’axe esclave. Pour finir nous avons une partie permettant de voir si les moteurs sont prêt à être couplés puis nous pouvons choisir entre les 2 couplages différents. Nous pouvons donc choisir de contrôler les moteurs de manière séparé ou de manière couplé.

IHM des moteurs Pas à Pas

Pour pouvoir démarrer les moteurs nous devons refaire les mêmes étapes énoncés dans la partie moteur asynchrone. Puis pour choisir le couplage nous avons la variable « GEAR » qui est la variable pour avoir le couplage linéaire et nous avons la variable « CAM » qui est pour la couplage CAM. Nous avons 2 entrée numériques qui sont « NUM » et « DEN » qui permettent de rentrer 2 valeurs une au numérateur et l’autre au dénominateur pour calculé un rapport de transformation. Puis pour prendre en compte les nouveaux réglages fait nous avons la variable « UPDATE ».

Servomoteurs

Nous allons étudié un dernier type de moteurs. Ces moteurs sont des servomoteurs. Un servomoteur est un système produisant un mouvement grâce à une commande externe. Pour cette partie nous allons nous aidés des blocs de la partie précédentes. Nous gardons les mêmes variables, les seuls qui changent sont les variables encadrées en rouge.

Bloc MpAxisBasic_0

Le bloc nommé « MpAxisBasic_0 » permet de contrôlé l’axe maître. Celui-ci sera un axe virtuel contrairement à la partie précédente où nous avons un axe maître réel. La première variable nommée « gAxisBasic » permet de contrôlé les différentes commandes de l’axe. La seconde variable « AxisPar » permet de contrôlé les différents réglages concernant le moteur. Pour la dernière variable « gVAxis01 », celle-ci permet d’identifiée l’axe que nous allons contrôler. Pour cette variable nous allons utilisé l’axe virtuel. Nous avons 2 autres blocs nommé « MpAxisBasic_1 et MpAxisBasic_2 », qui sont similaire au bloc ci-dessus mais permettent de contrôler les axes réels des servomoteur 1 et servomoteur 2.

Bloc MpAxisCoupling_1

Le bloc ci-dessus nommé « MpAxisCoupling_1 » nous permet de faire le couplage entre deux axes. Nous avons la première variable « gAxisBasic_2 » cette variable représente l’axe esclave d’un des moteurs. La second variable « AxisPar4 » celle-ci permet de choisir les réglages de l’axe. La dernière variable « gAxisBasic » représente l’axe maître que va devoir suivre l’axe esclave. Nous avons un second bloc de couplage pour le second servomoteurs ayant les variables différentes mais un fonctionnement similaire.

Pour la partie visualisation nous avons réutilisé IHM de la partie précédente que nous avons amélioré et ajouté les différentes variables nécessaires.

IHM des servomoteurs

Nous avons ajouté une partie maître pour nous permettre d’allumer et de contrôler l’axe virtuel. Le reste des variables restent les mêmes et les étapes pour allumer les moteurs sont identiques à toutes les parties. Nous avons juste à active la partie maître en premier si nous voulons que les moteurs suivent l’axe virtuel.

Conclusion


COMMUNICATION OPC UA & ARCHITECTURE RÉSEAU

Remerciements

Nous tenons à chaleureusement remercier notre enseignant de réseaux et notre superviseur de projet Monsieur MERCKLÉ. Pour sa disponibilité lorsque nous avions besoin d’aide et pour son engouement autour du sujet ce qui a boosté notre curiosité et nous a beaucoup motivé pour donner le meilleur de nous-même durant ce travail.

Sommaire

I) Introduction

II) Présentation

II).a) Gestion du projet :

II).b) L’OPC UA ?

II).c) OPC DA / OPC UA:

II).d) Disposition réelle des équipements

III) Réalisation

III).a) Serveur

III).b) Protocole Client 01

III).c) Protocole Client 02

III).d) Protocole Client 05

III).e) UA Expert

IV).a) Pages d’Aide

IV).b) Réalisation du support de la colonne lumineuse

IV).c) Pilotage d’une colonne lumineuse

V) Améliorations

VI) Conclusion

I) Introduction

Ce projet Études & Réalisation du 3ème et 4ème semestre en DUT GEII, traitait le protocole de communication OPC UA (Open Platform Communications Unified Architecture). 

En effet, ce protocole de communication industriel développé par OPC Foundation qui est un regroupement de 5 entreprises fait en 1994, permet la communication au sein d’une machine, entre machines et entre une machine et sa supervision. Il a plusieurs points forts, notamment le fait d’être compatible toutes plateformes (Windows, Linux, Android et Mac). Ce qui permet son utilisation au sein de n’importe quelle entreprise industrielle tout en gardant leurs postes informatiques actuel sans se soucier de l’OS. Ce qui est une restriction en moins et une économie financière en plus.

Ce protocole fonctionne suivant le principe client-serveur avec plusieurs types de clients.

De plus, le fait que les transferts de données se fassent par un et unique protocole et que les connections à différents clients nécessitent plusieurs étapes, tout cela fait que c’est un protocole sécurisé.

L’OPC UA va indéniablement se démocratiser de plus en plus au sein des industries étant donné que nous sommes aux prémices de la 4ème Révolution Industrielle, dans laquelle toutes les machines/objets industriels seront interconnectés entres eux et c’est ce que permettra ce protocole. Protocole qui est d’ailleur standardisé pour permettre l’Industrie 4.0 .

II) Présentation

L’aboutissement de notre projet est la mise en oeuvre d’un tutoriel complet expliquant  l’OPC UA. Ce tutoriel est destiné à notre enseignant Monsieur MERCKLÉ et aux futurs étudiants de DUT/LP SARII car il agit sur le cours traitant du protocole de communication OPC UA dans le but de faciliter sa compréhension au travers d’une prise en main concrète et appuyé par des pages d’aide. Ci-dessous la Bête-à-cornes définissant synthétiquement  notre projet :

II).a) Gestion du projet :

Pour réaliser ce projet nous nous somme fixé durant les heures de TP plusieurs objectifs. Ce projet qui totalise environ 100h de travail a été divisé en plusieurs parties.

Tout d’abord nous avons consacré environ 12h de travail sur la découverte et l’apprentissage du logiciel Automation Studio, afin de comprendre ses fonctionnalitées et son utilisation. Puis nous avons pris connaissance et développé le client 01 sur 14h pour mieux s’approprier et appréhender le protocole OPC UA. Nous avons passé ensuite 10h sur le client 02 qui possédait des outils différents rendant son utilisation plus complexe. Pour finir nous avons étudié et mis en place le client 05 en environ 15h. Nous sommes resté cohérent sur nos objectifs tout au long du projet tout en respectant les temps impartis.

II).b) L’OPC UA?

Présent sur la couche 4 du modèle OSI (Transport), OPC UA contrairement à d’autres protocole est indépendant, il n’est donc pas développé par un fabricant d’automates, mais par OPC Foundation un Consortium industriel de 5 entreprises à but non lucratif (Fisher-Rosemount, Rockwell Software, Opto, Intellution, Intuitive Technology), son développement a commencé en 1994. Il fonctionne classiquement sur le principe client-serveur avec une communication transparente, des capteurs-actionneurs aux systèmes ERP ou au cloud. Le protocole est indépendant de la plateforme et contient de base des mécanismes de sécurité. 

Plus simplement, le but d’OPC UA est d’unifier les communications des appareils et des composants, il est donc compatible avec tous les OS (Mac, Linux, Android et Windows), et avec une grosse partie des appareils : exactement ce qu’il faut dans l’industrie dite “4.0”. Très utilisé chez nos voisins Allemand, il tend à se développer en France (l’entreprise allemande Hager de gestion de l’énergie l’utilise dans ses usines en France par exemple)  et finira inéluctablement par prendre le dessus sur d’anciens protocoles moins universels, car il ne demande pas de changement d’équipements.  

OPC UA est un modèle cohérent, global et normalisé (IEC 62451), il est invisible pour les équipements et permet l’échange de données au sein d’une machine, entre machines et également entre une machine et un système. Via cette unification, les systèmes, les machines et les composants deviennent toutes des ressources pilotées par un superviseur. Là est la pierre angulaire d’OPC UA, l’universalisme dans l’utilisation et la transmission des données, qui permet et permettra à l’industrie de réduire drastiquement ses coûts. 

OPC Foundation a également axé le développement d’OPC UA sur la cyber sécurité, comme vous le verrez tout au long de ce projet le protocole intègre un système d’authentification et d’autorisation utilisateurs, certains utilisateurs auront accès ou non à l’écriture ou à la lecture de données contenues sur le ou les serveurs, bien évidemment les données sont chiffrées et les actions faites par les utilisateurs peuvent être tracées.

Structure du réseau OPC


Le standard de l’OPC UA comporte au minimum un Serveur OPC qui possède le langage propriétaire du matériel ou du logiciel  où il va collecter les informations à exploiter.

Il possède également une application ou Client OPC qui met en oeuvre les spécifications du standard et qui communique avec n’importe quel Serveur  OPC.

Il peut également contenir des informations ou données à exploiter telles que : des valeurs stockées sur des automates, des bases de données ou tout autres fichiers). 

Ce standard est résumé sur le schéma ci-dessous:

II).c) OPC DA/ OPC UA


L’OPC classique, est le prédecesseur de l’OPC UA qui lui mêle les différentes variantes telles que l’OPC DA, AE ou encore  HDA. L’OPC classique utilise DCOM (une technique de communication entre logiciels dans un réseau) pour établir un lien entre serveur et client, alors que l’OPC UA lui utilise différents protocoles de communication comme le TCP/IP ou encore le HTTPS qui permettent l’utilisation de données externes telles que des fichiers excels ou drives. Ces protocoles dépendent du SDK (kit de développement qui dispose d’un convertisseur de langage de programmation en langage machine) qui rend l’utilisation de ces protocoles possible et rend la communication efficace.

L’OPC DA est un groupe de standards qui se focalise sur l’acquisition des données en continu, il est très facile de récupérer la valeur d’une variable et de lui affecter plusieurs éléments comme par exemple une heure d’échantillonnage ou la qualité d’un signal. En revanche les valeurs sont publiques, entraînant une faible sécurité des données notamment pour les variables pilotées. OPC DA est aussi OS dépendant car le protocole est uniquement défini pour windows. Le protocole fonctionne avec une architecture reliant tous les appareils entre eux. 

Le protocole OPC UA reprend le protocole OPC DA classique en corrigeant ses défauts. Cette fois le logiciel est OS indépendant et sécurisé.

II).d) Disposition réelle des équipements

Pour mener à bien ce projet nous avons utilisé plusieurs équipements. Nous avions à notre disposition deux PC pour développer sur le logiciel Automation Studio, Ainsi que deux Automates programmables avec CPU  (automate avec unité de calcul). Chaque automate possède sa propre adresse IP, la CPU 1 a pour adresse : 200.200.200.186 et la CPU 2 : 200.200.200.184. 

Par la suite nous avons ajouté un Coupleur de Bus ou BC (Bus Controller) qui lui a pour adresse 200.200.200.165. La CPU 1 est utilisé pour les clients et communique avec la CPU 2 et le coupleur de bus sur lesquels sont stockés le serveur. Sur les sorties de notre coupleur de bus il y a deux leds branchées, nous verrons ce que nous pouvons en faire…

III) Réalisation

Configuration des Automates 

Au début, nous allons faire tourner les clients en simulation sur un poste, et le serveur en simulation sur un autre,  une fois que ce sera fonctionnel, nous allons faire communiquer le client stocké sur un CPU automate avec le serveur sur un autre CPU automate, enfin, nous ajouterons un coupleur de bus sur lequel tournera également le serveur et dont nous essayerons de piloter les entrées et les sorties.

Etapes de Réalisation 

Il faut bien comprendre que OPC UA est un protocole permettant de donner précisément des droits d’accès ou non à des utilisateurs aux données stockées sur le serveur, par conséquent lorsqu’on lance un projet OPC UA, il y a des pages utilisateurs déjà faites, chacune ayant des droits précis et différents, ainsi qu’une page serveur avec des variables stockées dessus. Par exemple VarX, VarY et VarZ qui s’incrémentent avec le temps via une fonction codée sur le serveur (ce qui peut permettre de vérifier par exemple que l’on récupère bien sur le client les valeurs d’une variable en temps réel si il a cette permission). Mais on peut très bien déclarer nos variables et y accéder. 

Durant ce projet nous avons développé l’accès et la supervision de 3 d’entre eux, le “Client 01”, “Client 02” et le “Client 05”. Le Client 01 utilise des blocs fonctions qui lui permettent uniquement d’écrire ou lire une valeur d’une données du serveur. Il aura accès à la valeur de cette donnée uniquement lorsqu’il en fait la demande. Le Client 2 lui, peut lire une variable mais cette fois ci de manière monitoré, c’est à dire que le serveur lui renvoie la valeur d’une données en temps réel, à un interval de temps défini. Ces deux clients nécessitent que le serveur tourne sur une CPU car il effectue des calculs continu. 

Le Client 05 quant-à-lui est un peu différent, car il sera utilisé pour communiquer avec des matériels n’ayant pas d’unité de calcul, comme un coupleur de bus par exemple. Nous disposons d’un coupleur de bus B&R sur lequel deux leds sont installées, nous tâcherons de pouvoir les allumer et les éteindre à notre guise.

Librairie ASOPCUAC & Bloc fonction

Le projet OPC UA créé contient plusieurs bibliothèques (library), la plus importante et celle que nous utiliserons le plus est “AsOpcUac”, elle contient tous les blocs fonctions (structure) de données utilisées par les clients. 

Durant ce projet, une bonne partie des blocs fonctions présents dans la bibliothèque ont été utilisés, il faut donc bien comprendre ce qu’est un bloc fonction.

Ils sont très utilisés en automatisme, ils sont l’équivalent des structures en programmation classique, c’est un ensemble de programmes ou de fonctions contenu dans un autre élément (ici la liste à gauche). Ils contiennent donc des méthodes qui leurs sont propres et des variables qui peuvent être de type différents et défini en temps que entrée ou sortie. C’est comme un programme dans le programme, ce qui facilite grandement la compréhension du code.

Tous les blocs fonctions utilisées durant le projet sont disponibles en annexe.

III).a) Serveur 

Nous avons d’abord réalisé une visu serveur, afin de visualiser la valeur des variables stockées sur celui-ci.

Déclaration des variables :

Visu du serveur : 

III).b) Protocole du Client 01 

Voici le Protocole donné dans la documentation du Client01 :

L’organigramme est le suivant : 

Nous pouvons voir que les blocs fonctions comportent des variables booléennes d’états, “occupé” (busy) et “terminé” (done), qui permettent de vérifier l’accès aux blocs fonctions. 

Voici dans le détail les explications des actions effectuées par chaque bloc : 

Avant toute choses il nous a fallu modifier la valeur de “ServerEndPointUrl” dans la page de code du client 01, en donnant l’adresse du serveur, ici notre serveur est à l’adresse IP 200.200.200.184.

Nous avons ensuite créé une visu et à l’aide de bouton, un par bloc, nous avons pour chaque bloc fonction, passé à 1 leurs variables booléennes “Execute”.  

Il faut donc, passer par les blocs : 

  • Connect
  • NameSpaceGetIndex
  • NodeGetHandle

Afin de pouvoir lire ou écrire sur une variable stockée sur le serveur. 

Une fois les opérations voulues terminées, pour se déconnecter il faudra passer par les blocs : 

  • NodeReleaseHandle
  • Disconnect

Pour chaque bloc fonction nous avons affiché leurs variables d’état, le voyant de gauche devient orange si le bloc fonction est occupé (busy) et celui de droite devient vert lorsqu’il n’a pas renvoyé d’erreurs (done). 

Le bloc fonction “Connect” contient une variable qui renvoie une valeur qui est l’indice de connexion qui nous est propre (ce qui fait que la connexion peut être retracée comme nous l’avons vu précédemment), nous affichons également la valeur stockée dans “NameSpaceIndex” qui est une valeur propre à la machine sur laquelle nous nous connectons. Si plusieurs clients sont connectés sur la même machine, ils auront le même NameSpaceIndex.

“NodeGetHandle” renvoie également une valeur qui sera propre à la connexion à une variable, la modification par exemple d’une donnée par un utilisateur peut donc également être retracée. 

Lorsque qu’on exécute le bloc Read ou Write, une variable de type “DATE” est renvoyée nous l’avons également affichée, on peut non seulement savoir qui a accédé ou modifié une valeur, mais également quand. 

Coté client nous avons deux variables, VarA et VarB, lorsque nous exécutons un “READ”, VarA et VarB récupère la valeur de la variable VarX stockée sur le serveur. Les valeurs ne se mettent pas à jour automatiquement, il faudra donc exécuter le bloc fonction “READ” dès que l’on veut récupérer la valeur actuelle de VarX.

VarB dans notre visu est un objet dans lequel on peut écrire une valeur lorsque qu’on exécute un “WRITE” la valeur de VarX récupère la valeur de VarB, et VarB s’incrémente de 1. 

Voici la visu créée pour le client 01 :

III).c) Protocole Client 02 

Voici les étapes d’utilisation données dans la documentation technique du client 02 :

Voici l’organigramme du client 02, avec en petit les blocs fonctions similaires au client 01, nous pouvons voir que le bloc Read/Write a été remplacé par 4 autres blocs :

Explication des 4 nouveaux blocs fonctions : 

Le client 02 contrairement au client 01 peut donc, cycliquement lire la valeur d’une variable contenue sur le serveur, c’est à dire qu’une fois qu’il aura fait le lien avec une variable grâce à SubscriptionCreate (ici VarX), il pourra monitorer une variable coté client avec MonitoredItemAdd (ici VarA). 

VarA récupère donc la valeur de VarX à un intervalle de temps donné, défini dans le programme, ici 1 seconde. Toute les secondes, SubscriptionCreate envoie une alerte (uniquement si VarX est modifié, rappelons que VarX s’incrémente en continu sur le serveur. Si sa valeur était constante SubscriptionCreate n’enverrait pas d’alerte), quand MonitoredItemAdd reçoit cette alerte, il déverse la valeur de VarX dans VarA. Ca y est, nous lisons une valeur du serveur cycliquement ! 

Il nous a fallu également modifier la valeur de “ServerEndPointUrl” dans la page de code du client 02, en donnant l’adresse du serveur. Ici notre serveur est aussi à l’adresse IP 200.200.200.184.

Visu du client 02 :

III).d) Protocole Client 05 

Voici les étapes de connexion au client 05 (comme nous les avons utilisées) : 

Comme vous pouvez le voir le protocole de connexion de ce client est quasiment similaire à celui du client 02 il permet cependant de lire une variable sur le serveur et de stocker sa valeur dans une variable monitorée et également d’écrire via celle-ci, le client 05 possède donc une étape Read/Write.  

Pour ce client, nous souhaitons donc piloter les leds branchées (via un “Write”) sur le coupleur de bus, il faudra donc dans le code du client 05 comme pour les précédents définir l’adresse IP sur laquelle on veut se connecter, ici 200.200.200.165. Afin de pouvoir piloter la led en temps réel, il faudra donc qu’on envoie une information cycliquement. Pour ce client nous avons décidé de ne pas utiliser les blocs SubscriptionCreate et MonitoredItemAdd. Pour les shunter et avoir un résultat équivalent, nous avons créé un programme ST “Clock” qui sera appelé cycliquement toutes les 1000ms. 

Dès que la “Clock” s’exécute nous modifions la variable “Execute” du bloc fonction “Write”, ce qui enverra donc cycliquement l’information voulue au serveur (soit ON soit OFF afin de piloter la led).

Avant toutes choses voici les modifications à apporter sur le code afin de se connecter au coupleur de bus : 

Username passe à Anonymous (donné dans l’aide d’AS) : 

On modifie “ServerEndPointUrl”, en donnant l’adresse du serveur, ici notre serveur est notre coupleur de bus à l’adresse IP 200.200.200.165.

Dans le bloc exécutant “GetNameSpaceIndex” la valeur de “NamespaceUri” doit être modifiée (donné dans l’aide d’AS).

Nous sommes maintenant prêt à intégrer notre bloc fonction “Write”. 

Voici l’organigramme du client 05 : 

Un bloc fonction est venu se rajouter : “TranslatePath”, nous vous expliquerons son fonctionnement, mais pour le définir il faut utiliser un autre outil, UA Expert…

III).e) UA Expert

Pour le client 05 et la connexion avec le coupleur nous avons été amené à utiliser UA expert, un logiciel ayant de multiples fonctionnalités, il nous permet par exemple d’accéder aux données du serveur, aux historiques de connexions… Nous l’utiliserons afin de diagnostiquer notre matériel, en accédant à notre coupleur de bus avec UA expert nous pouvons visualiser les chemins d’accès aux entrées et sorties de nos variables et nous pouvons également les piloter. Nous avons donc deux leds branchées sur notre coupleur de bus, ainsi nous pouvons vérifier sur quelle sortie elles sont branchées. Après les avoir tester nous avons pu voir qu’elles étaient branchées sur les sorties “DigitalOutput01” pour la bleue et “DigitalOutput02” pour la blanche.

Le Client 05 qui pilotera les sorties de notre coupleur de bus dispose donc d’un bloc fonction TranslatePath qui convertit un chemin d’accès à une sortie d’un appareil (Relative Path) en un “NodeIDs” compris et utilisable par OPC UA. Dans la documentation technique, il est expliqué comment construire son Relative Path. 

Pour notre led bleue (DigitalOutput01) Le chemin d’accès sera donc : 

‘/2:DeviceSet/2:X20BC008U/2:X2X/2:SubDevices/:ST3/2:ProcessData/2:DigitalOutput01’ 

Et notre ligne de code : 

RelativePath:=‘/2:DeviceSet/2:X20BC008U/2:X2X/2:SubDevices/:ST3/2:ProcessData/2:DigitalOutput01’

Arbre des dossiers du coupleur de bus sur UAexpert, que nous avons dû suivre pour écrire notre RelativePath

Le bloc servant à écrire (Write, voir ci-dessous) est donné dans l’aide, mais bien évidemment des modifications sont à effectuer pour coller à notre système. “StartNodeID_Root.Identifier” prend la valeur 85 (pour Objects, voir image ci-dessus). Ensuite il faut donner notre RelativePath, notons qu’avec la fonction strcat() de la librairie AsString (à ajouter) on peut concaténer des chaînes de caractères et découper le RelativePath pour qu’il soit plus facilement modulable, ce qui peut permettre par exemple de n’avoir qu’à modifier le “01” final en “02” pour se connecter à la sortie numéro 2. Ca y est, nos leds sont pilotables !

Visu client 05 :

IV).a) Pages d’aide

Pour finir, afin de rendre le logiciel que l’on a développé plus compréhensible, nous avons créé des pages d’aide, qui expliquent les protocoles de connexions aux différents clients. 

Dans un premier temps nous avons créé une page d’accueil, puis dans celle-ci nous avons ajouté une aide concernant l’OPC UA et ses fonctionnalités permettant aux utilisateurs de mieux comprendre les étapes communes aux différents clients. Par la suite nous avons également créé une aide pour chaque clients et ainsi détaillés leurs blocs fonctions. Il y a par conséquent une aide pour le client 01, le client 02 et le client 05 qui lui reprend des méthodes du client 02 et dispose d’un renvoie à l’aide de celui-ci. En effet dans le client 05, certaines étapes ne sont pas utilisées car nous les avons contourné étant donné que nous utilisons une méthode différente permettant d’effectuer les mêmes opérations (Clock).

IV).b) Réalisation du support de la colonne lumineuse 

La colonne lumineuse que nous allons piloter est constituée de 4 Leds, un buzzer et un bouton poussoir. Pour assembler les composants et former une colonne lumineuse nous avons élaboré et construit une boîte pouvant contenir l’ensemble des composants et pouvant être directement fixé sur des supports du panneau. 

Voici le rendu final du boîtier, accueillant l’ensemble des équipements (Leds, buzzer, bouton poussoir).

IV).c) Pilotage d’une colonne lumineuse

Nous allons dans cette partie controller une colonne lumineuse constitué de plusieurs entrées (bouton poussoir) et plusieurs sorties (4 Leds et un buzzer). Pour cela il est nécessaire de pouvoir contrôler plusieurs entrée/sortie. 

V) Améliorations

Une fois la découverte de tous les types de clients, à nous de composer. On pourrait imaginer fusionner des clients pour créer le nôtre afin de lui donner des droits bien précis que l’on aurait défini. Dans certaines variantes du client 1, le client peut lire ou écrire des tableaux sur le serveur, on pourrait imaginer, en le fusionnant avec le client 02, lire cycliquement la valeur d’un tableau stocké sur le serveur. 

Enfin on pourrait modifier le serveur afin qu’il effectue d’autres opérations, on pourrait concevoir une calculatrice, à qui on enverrait des valeurs depuis le client et qui effectuerait les opérations sur le serveur. 

On pourrait également rajouter d’autres appareils, communiquer avec d’autres automates qui effectueront des tâches bien précises, ou un autre coupleur de bus, voire même un capteur. OPC UA est de toute manière compatible avec une énorme partie des appareils disponibles dans notre salle de TP.

L’OPC UA tire aussi sa force dans sa sécurité et nous pourrions mettre en place des protocoles de sécurité (définition d’un mot de passe par client, d’un historique de connexion…).

Ce ne sont que des suppositions, peut être que nous déciderons à terme de faire autre chose si d’autres idées nous viennent. Si on peut en faire autant c’est que le protocole OPC UA est tellement vaste et offre tellement de possibilités que l’on aurait de quoi l’explorer et l’analyser pendant des semaines ! 

VI) Conclusion

Nous n’avions jamais entendu parler de ce protocole avant le premier cours d’étude et réalisation, et nous nous rendons compte à terme que nous avons vraiment bien fait de choisir ce projet. En effet, le protocole OPC UA tend tellement à se démocratiser, qu’on pourrait se demander s’il ne va pas devenir un standard dans l’industrie ? 

De part sa sécurité ou encore son utilisation il nous a permis de mieux comprendre l’enjeu des communications client serveur dans l’industrie. Il reste notamment accessible et est appliqué dans de nombreux domaines tels que le pharmaceutique, le pétrole, le gaz ou encore la robotique. 

Nous avons perçu ce projet comme bénéfique car il nous a permis de développer plus de connaissances dans ce domaine et de maîtriser efficacement l’OPC UA. Il nous reste de nombreux points à découvrir ou à approfondir. 

Ce projet rend bien compte de l’importance de la communication et ses protocoles liés au sein de  l’industrie et du basculement vers “l’industrie connectée”.

Annexes

Blocs Fonctions


Banc de vision 2019


INTRODUCTION

Le projet « Banc de Vision » a été effectué en collaboration avec des étudiants GMP. Il a été nécessaire d’allier les compétences des uns et des autres afin de mener à bien ce projet.

Ce banc de vision à été étudié et conçu afin de répondre à différents besoins: il permet d’une part la numérisation d’une pièce de fonderie sous différents angles de vue et facilite d’autre part la détection des défauts de surface éventuels sur une pièce. La structure du banc est commune avec d’autres projets tels que le banc de vision à éclairage multi-spectral et permet donc d’augmenter les possibilités proposées à l’utilisateur.

 


SOMMAIRE

1. DIAGRAMMES
2. CAHIER DES CHARGES
3. LISTE DU MATÉRIEL
4. MOTEUR PAS À PAS
5. CLAVIER 16 TOUCHES
6. CAPTEUR DE FIN DE COURSE
7. PAN-TILT
8. CONCEPTION DES PIECES MECANIQUES
9. CONCLUSION
10. ANNEXES

1. DIAGRAMMES

1.1. DIAGRAMME PIEUVRE

Ce banc de vision s’adresse à quiconque souhaite avoir une première approche de la géométrie d’un pièce de fonderie, en la visionnnant sous différents angles afin de numériser par exemple cette pièce ou de détecter des défauts de surface.

1.2. FONCTIONS

FP1: capturer une pièce de fonderie

FC1: s’adapter aux dimensions des pièces de fonderie

FC2: respecter le budget

FC3: se fixer au châssis prédéfini avec le projet « éclairage multi-spectral »

FC4: assurer une prise de vue sous différents angles et à différentes hauteurs

FC5: Permettre le stockage et le transfert des photos


2. CAHIER DES CHARGES

 

Il est demandé aux élèves l’étude préalable et la conception d’un banc de vision permettant de numériser une pièce (de fonderie par exemple) sous différents angles.

Ce banc est constitué d’une glissière verticale sur laquelle une caméra peut se déplacer de haut en bas et s’incliner grâce à un support pan-tilt. Ce mécanisme doit s’intégrer au sein d’une structure aluminium multifonctions, commune à différents projets.

Le cahier des charges stipule que le banc peut accueillir des pièces de fonderie de 300 mm de longueur, 300 mm de largeur et 400 mm de hauteur. La caméra permettant la prise de clichés doit être située à 400 mm minimum de la pièce à analyser. La pièce peut être posée sur un plateau tournant (autre projet) afin de visualiser toutes ses faces. Si l’on souhaite une vue de la partie haute de la pièce, la caméra pourra être déplacée le long d’un axe afin d’augmenter son altitude de prise de vue. Un moteur pas à pas assure la translation verticale de la caméra.

La capture de la pièce pourra être effectuée soit manuellement, soit à l’aide de programmes préétablis à l’aide d’un clavier de commande.

Afin de ne pas forcer le mécanisme et endommager les différentes pièces, deux butées de fin de course assurent la pérennité de l’ensemble du système.

 

Le diagramme FAST ci-dessous permet de retrouver toutes les fonctions de services , les solutions constructives ainsi que les critères auxquels le banc de vision doit répondre.

 

 


3. LISTE DU MATÉRIEL

Notre première mission a été de sélectionner le matériel nécessaire à nos tests.

  • une carte Arduino Mega
  • un moteur pas à pas de 12V, 1.2A
  • un shielda vis pour faciliter les branchements
  • une alimentation de 230V en entrée et 12V + 5V en sortie est utilisée pour alimenter l’ensemble du banc de vision.
  • un servo-moteur pour le pan-tilt
  • un clavier 16 touches
  • 2 capteurs de fin de course

 


4. MOTEUR PAS À PAS

Qu’est-ce qu’un moteur pas à pas ?

Un moteur pas à pas est un moteur permettant de commander précisément le positionnement de son rotor quel que soit le nombre de tours qu’il a à exécuter. Chaque moteur a un nombre de pas définis par révolution, c’est-à-dire un nombre de secteurs bien déterminé. Dans notre cas chaque pas fait 1,8°,  soit 200 pas pour effectuer un tour de 360°.

Afin d’assurer l’entrainement permettant la translation verticale de la caméra, nous avons utilisé un moteur pas à pas de 12V, 1.2A, un microstep driver permettant l’alimentation en puissance ainsi que la gestion partielle de la rotation du moteur et un Arduino Mega en guise d’électronique de commande.

Voici le schéma simplifié de l’installation:

La carte Arduino transmet un signal carré au micro step driver (partie puissance) qui se charge en interne d’alimenter alternativement chaque bobine du moteur. Plus la durée entre deux impulsions consécutives est courte, plus la vitesse de rotation du moteur est importante.

La cadence de rotation est déterminée par le temps séparant deux impulsions. Plus le temps est court, plus le moteur est rapide, plus le temps est grand, plus le moteur sera lent.

PINs:

  • PUL+/-: vitesse de rotation du moteur en fonction de la cadence des impulsions de l’Arduino
  • DIR+/-: sens de rotation du moteur
  • ENA+/-: alimentation du moteur (désactiver l’alimentation quand le moteur n’est pas en rotation, sinon il surchauffe!)
  • A et B: bobines du moteur

 


5. CLAVIER 16 TOUCHES

Un clavier 16 touches est utilisé afin de permettre aux utilisateurs de contrôler facilement le banc. Il est possible de démarrer des programmes automatiques, mais aussi de commander le banc en mode manuel.

Description des touches:

  • Carré noir: entrer en mode automatique
  • Carré blanc: entrer en mode manuel
  • 0,1,2,3: programmes automatiques
  • 9: trigger photos
  • Flèches Haut/Bas: monter/descendre le banc en mode manuel
  • Flèches Gauche/ Droite: monter/descendre le pan-tilt par pas de 10°
  • Autres touches: non utilisées pour l’instant

 

 

Le clavier fonctionne de la manière suivante:

Il est constitué de lignes et de colonnes, le tout étant relié aux ports de l’Arduino. Les lignes sont connectées sur des sorties et les colonnes sur des entrées. Chaque ligne du clavier est alimentée tour à tour en 5V (balayage).

 

 

Lors d’un appui sur une des touches du clavier, un contact se crée entre une ligne et une colonne et la détection de la touche est effectuée par l’Arduino. L’Arduino n’a plus qu’à réaliser la correspondance entre la ligne alimentée et la colonne d’où vient le signal pour connaître le numéro de la touche enfoncée. Une librairie permet de réaliser ce traitement.

 


6. CAPTEUR DE FIN DE COURSE

Les capteurs de fin de course que nous avons utilisés sont des capteurs infrarouges (E18-DN80K). Ils sont équipés d’un émetteur et d’un récepteur. L’émetteur crée un faisceau lumineux de manière constante. Temps que le faisceau n’est pas réfléchi, cela signifie qu’aucun obstacle n’est présent devant le capteur. Si au contraire le faisceau est réfléchi vers la cellule réceptrice, c’est qu’un obstacle est dans la trajectoire du faisceau. Le capteur transmet alors un signal de 5V continu au port de l’Arduino.

Dans notre cas, nous avons placé deux de ces capteurs sur le banc, un en haut de la glissière et l’autre en bas.

Si le capteur haut détecte un obstacle, il envoie un signal à l’Arduino afin de stopper la montée du plateau. Même principe avec le capteur bas, lorsque le plateau descend.

 


7. PAN-TILT

Afin de permettre à la caméra se s’incliner, nous avons utilisé un support un pan-tilt.

Un servo-moteur de modélisme permet l’inclinaison de celui-ci. Les GMP ont réalisé un support de caméra sur mesure afin d’épouser les formes du servo-moteur.

 

Au niveau de la programmation, nous avons fait le choix de donner au servo-moteur une course maximale de 90° par pas de 10°. Il peut donc se déplacer de l’horizontale à la verticale et inversement.

 


 

 

8. CONCEPTION DES PIECES MECANIQUES

8.1   Choix de conception

 

Le cahier des charges demande d’assurer la prise de vue de clichés dans différents angles et surtout à différentes hauteurs. De ce fait un guidage en translation de la caméra est nécessaire. Plusieurs solutions pouvaient être utilisées :

Guidage en translation par galet                                        Guidage en translation par patin                                   Guidage en translation par profilés ronds

 

Peu importe la choix de conception l’entrainement du plateau s’effectue avec un système poulie cranté / courroie.

Après réflexions c’est le guidage en translation par profilés ronds qui va être utilisé pour des raisons de coût, de faisabilité et d’assemblage. Le chariot (partie qui translate sur les profilés ronds) sera lié sur un profilé rond par une liaison pivot et sur l’autre profilé par une liaison bi-ponctuelle.

 

8.2   Vue d’ensemble

 

Pour avoir un aperçu de l’ensemble, ci-dessous une vue du projet modélisé sur Créo :

 

Parmi tous ces composants certaines pièces ont été achetées soit :

  • Les profilés ronds
  • Les supports d’arbres
  • Les deux poulies
  • Le bâti

 

8.3   Usinage de la plaque support

 

Ci-dessous la plaque support où tout les éléments du banc de vision vont se fixer. L’objectif de cela est de pouvoir avoir une interface amovible qui peut se démonter par l’intermédiaire de 4 vis. Cette plaque à été réalisée sur la machine de découpe jet d’eau dans l’atelier GMP.

 

8.4   Fabrication additive 3D

8.4.1  Conception du chariot

 

Comme dit précédemment, le chariot va coulisser sur deux profilés ronds mais avec deux liaisons différentes :

  • Une liaison pivot glissant d’un côté assurée par une douille à billes
  • Une liaison bi-ponctuelle pour empêcher la rotation de la pivot glissant

Les deux liaisons permettent d’aboutir à une liaison glissière qui correspond bien au mouvement recherché.

 

Nous avons décidé de nous orienter vers la fabrication additive 3D pour faire cette pièce, ci-dessous la conception finale du chariot :

Face avant du chariot                                                                                 Face arrière du chariot

 

Sur la face avant il  y a un trou qui permet par l’intermédiaire d’un boulon de fixer le pantilt qui à été fait également en impression 3D.

 

8.4.2  Support moteur

 

Pour fixer le moteur (qui va entraîner une poulie crantée) à la plaque support, un support à du être réalisé.

Le support répond bien à sa fonction mais plusieurs axes d’améliorations seraient envisageables. En effet la pièce n’est pas rigide et fléchit, il serait nécessaire d’ajouter des renforts sur la pièce ou bien de la faire en métal (Découpe jet d’eau + Pliage).

 

8.4.3  Pan tilt

 

Pour permettre l’inclinaison de la caméra, nous avons utilisé un servomoteur mais aucune interface n’était fournie avec. De ce fait toujours en fabrication additive plastique nous avons réalisé cette interface qui permet d’obtenir des prises de vues dans différents angles.

 

L’ensemble est composé de deux pièces :

  • Une pièce en liaison avec le chariot
  • Une pièce en liaison avec la caméra

Bien que le plastique offre une légèreté incomparable par rapport au métal, des renforts ont été prévus pour éviter toute flexion.

 

Ci-dessous un court aperçu du résultat final, aboutissement du travail effectué par les GEII et les GMP :

 

 


9. CONCLUSION GEII

Nous avons trouvé ce projet très intéressant. Le fait de pouvoir travailler en équipe avec un groupe de GMP très investis dans leur travail était un réel plaisir et nous a permis de mener à bien ce projet.

Ce projet nous a permis de découvrir le fonctionnement d’un moteur pas à pas mais aussi celui d’un clavier et d’un capteur infrarouge. Nous avons aussi pu approfondir nos connaissances en programmation et voir le potentiel impressionnant des cartes Arduino, pourtant vendues à un prix raisonnable. Ces dernières permettent de réaliser des projets aboutis avec une grande liberté et de multiples fonctionnalités.

Nous sommes satisfaits du résultat final et espérons que ce projet pourra évoluer dès l’an prochain!

 


10. ANNEXES

DATASHEET:

LIEN CAPTEUR DE FIN DE COURSE

LIEN CLAVIER 16 TOUCHES

LIEN CODE ARDUINO

LIEN CODE PRÉSENTATION POWER POINT


Banc de Vision à éclairage multi-spectral

Sommaire :

  1. Introduction
  2. Etude du projet
  3. Partie GMP
    1. Les solutions adoptées
    2. La CAO
    3. La réalisation du projet
  4. Partie GEII
    1. L’éclairage
    2. La capture d’images
    3. La motorisation
    4. Les supports des LEDs et le boitier de commande
  5. Conclusion

Introduction :

Le projet de « Banc d’éclairage multi-spectral » fut un projet en collaboration entre le département Génie Mécanique et Productique et le département Génie Electrique et Informatique Industrielle. Il nous a été confié par Monsieur Christophe Cudel, professeur dans le département GEII et responsable des apprentis de ce département.

Ce projet a pour but de prendre des photos en noir et blanc, sous différents spectres sélectionnés, de plusieurs pièces défilant sur un plateau motorisé. Ces différentes vues nous permettrons ensuite de mettre en évidence les défauts de la pièce. Nous pourrons aussi, avec les images de certains spectres, reconstituer une image couleur à partir de ceux-ci.

Pour cela, un groupe de 5 personnes fut constitué, 3 élèves de GMP et 2 élèves de GEII.

Les étudiants de GMP se sont occupés de toute la partie mécanique et du bâti et les étudiants de GEII ont développé toute la partie éclairage, la capture de l’image et la commande du moteur.

Le bâti ci-dessus, situé dans le département GEII, sera notre modèle. Pour notre projet, un bâti similaire a été commandé avec les dimensions adéquats. Il a été décidé que le bâti sera commun avec le projet de « Banc de vision » d’un autre groupe.

Etude du projet :

Pour débuter le projet, nous fûmes, tous les 5, une étude de celui-ci. Nous avons donc commencé par une bête à cornes afin de répondre aux questions : pour qui ? Sur quoi ? Pour quoi ?

Une fois ces questions résolues, nous avons pu établir une analyse fonctionnel du projet.

Le principe découlant de cette analyse est simple. Depuis un boitier de commande, nous commandons l’exécution des tâches suivantes : la couleur de l’éclairage, le nombre de pièces à analyser et le départ du traitement.

Les commandes effectuées depuis la console sont envoyées à l’arduino qui contrôle toute la procédure. Ainsi, en fonction des couleurs et du nombre de pièces choisies,l’arduino va envoyer les informations aux différents actionneurs aux moments voulus.

 

Partie GMP :

Les solutions adoptées :

Pour ce projet, l’idée nous ayant semblé la plus simple à réaliser s’est rapidement avéré être la réalisation d’une plaque circulaire avec des emplacements pour les pièces à photographier, cette solution ne nécessitant qu’un unique moteur, la ou une table se déplaçant sur deux axes en aurait nécessité deux.

Par la même, ce projet devant s’adapter dans un bâti composé de profilés, il nous est rapidement venu à l’idée d’ajouter à ce bâti une barre verticale, au fond au centre de ce bâti, sur laquelle nous pourrions fixer notre caméra et notre éclairage, ce à la verticale du plateau tournant qui emmènerait les pièces sous la caméra.

 

La CAO :

(CAO initiale de notre projet)

(CAO suite à modifications : pignons et roue-dentée ont été inversés – la barre verticale a été décalée sur un des cotés afin de pouvoir modifier le support des LEDs ainsi que le support caméra)

[Transmission entre le moteur qui vient se fixer sous l’adaptateur rouge et le plateau tournant, guidé par l’axe vert fixe dans le bâti, par un système roue dentée (jaune) – pignon (bleu). Nous nécessitons un rapport important de par la faible puissance du moteur que nous avions à utiliser. Les engrenages sont ici inversés (erreur de notre part, corrigé dans la version finale)]

[L’entraxe de l’engrenage est géré à l’aide de trous oblongs dans la plaque maintenant le moteur (en bleu), le pignon étant fixé sur l’adaptateur qui est directement sur la sortie du moteur]

(Cette plaque vient supporter une caméra. Il y a de nombreux trous dans la zone à droite permettant d’accueillir divers modèles de caméra)

[Cette plaque sert à tenir les deux anneaux de LEDs (1 RGB, 1 IR/UV). Sous les anneaux de LEDs sera fixé un diffusant (plaque de plastique semi-transparente)].

 

[Ces deux plaques sont fixées au bâti par des équerres, permettant d’en régler la position en hauteur. On peut voir sur cette image le plus gros des modèles de caméra que nous avions à adapter sur le support, et le plus grand des anneaux de LEDs (en rouge). La caméra peut passer au travers du support de LEDs à l’aide du trou situé en son milieu]

[Le plateau tournant (jaune) peut accueillir deux plateaux différents, avec respectivement six et neuf cases, mis en position par les deux goujons gris]

La réalisation du projet :

Nous n’avons pas eu le temps de réaliser toutes les pièces de notre projet : seul ont été réalisés : le palier lisse venant sur l’axe du plateau tournant pour permettre la rotation de ce dernier, l’adaptateur sortie du moteur, et l’axe du plateau tournant.

 

La partie GEII :

L’éclairage :

Afin d’éclairer le banc de vision, 2 cercles de LEDs furent utilisés. Un premier, petit, composé de 24 LEDs et un second, plus grand, composé de 4 quart de cercle, pour un total de 60 LEDs.

Le premier cercle fut utilisé pour l’éclairage du banc dans les spectres visibles par l’œil humain. Le second cercle aurait dû être utilisé pour l’éclairage du banc dans les spectres invisibles par l’homme, l’infrarouge et l’ultraviolet. Malheureusement, les LEDs infrarouges et ultraviolettes étant relativement chère, le second cercle n’a pas pu être modifier. Il éclairera donc sous le même spectre que le premier.

Les cercles sont composés de LEDs adressables WS2812B. La spécificité de celles-ci est qu’elles sont transmetteuses. C’est à dire qu’une LED, connectée en série avec les autres, va recevoir une trame de n fois 24 bits. Cette trame constitue le paramétrage des LEDs. La première LED va être paramétrée par les premier 24 bit puis, va transmettre le reste de la trame à la LED suivante. Cette opération va se produire le nombre de fois, n, équivalent au nombre de LEDs que possède le cercle paramétré.

Afin de commander nos cercles, nous avons utilisé un arduino UNO, qui sera aussi utilisé pour la capture d’image et la commande du moteur, et la bibliothèque  de fonctions fourni par le constructeur.  Le programme de la gestion de l’éclairage peut être résumé par le diagramme suivant :

L’entièreté des programmes sont disponible en téléchargement ici.

La capture de l’image :

Pour la capture d’images nous avions comme obligation de pouvoir accepter une caméra standard ou une caméra intelligente, pour le projet un caméra cognex. Ces caméra ont la possibilité de prendre des photos grâce à un signal déclencheur, nous avons donc utilisé cela lors de ce projet.

Nous avons intégré le déclenchement de la capture dans le programme de la gestion des éclairages comme le diagramme ci-dessous peut vous le montrer.

Après l’allumage des LEDs dans la couleur souhaité nous envoyant une impulsion, par le biais d’un signal haut puis bas, sur l’entrée de déclenchement de la caméra.

Les caméra étant différentes, un soucis se posa. La caméra standard acceptant un signal de déclenchement de 5V n’a aucun soucis pour fonctionner en étant branchée sur l’arduino. En revanche, la caméra Cognex a un déclenchement plus élevé.

Nous avons donc utilisé un optocoupleur afin de le piloter. Pour cela l’optocoupleur a dû être modifié car le signal sortie était encore trop faible. En effet, l’optocoupleur possédait une résistance de 10kΩ  qui, couplé avec les 10kΩ déjà présent, était beaucoup trop élevé. Pour abaisser cette résistance, nous avons donc rajouté une résistance de 10kΩ  en parallèle à celle de l’optocoupleur.

Cela nous a permis de baisser suffisamment la résistance pour que le signal de déclenchement soit détecté par la caméra.

Le fonctionnement du moteur :

Pour le défilement des pièces nous avons utilisé un moteur pas à pas, contrôlé par l’arduino, via un shield moteur.Ce moteur est composé de deux bobines qui fonctionne de manière alterné afin de faire tourner l’axe. Cette gestion alternative est gérer par le shield moteur, il nous a permis de commander le sens du moteur, sa rotation ainsi que son alimentation.

Lors de l’exécution du programme, l’arduino envoie une demande de rotation au shield moteur via une impulsion en 5V. Celui-ci envoie ensuite la commande au moteur via un signal en 12V.

Cette impulsion faisant tourner le moteur que d’un seul pas, nous avons donc bouclé cette partie de code afin de l’exécuter le nombre de fois nécessaire. Notre programme possédant 2 modes de fonctionnement, le premier permet de traiter 6 pièces et le second 9 pièces, celui-ci devra donc boucler un nombre différent de fois.

Afin de calculer ce nombre nous savions que le moteur possédait 200 pas, nous avons donc divisé ce nombre par le nombre de pièce observées afin de connaitre le nombre de pas à effectuer entre chaque pièce. Lors ce ces calculs, nous avons remarqué un reste dans ces division. Ainsi pour supprimer le décalage qui sera créé, nous avons ajouté une rotation de 2 pas à la fin du programme.

Les supports des LEDs et le boitier de commande :

Les supports des cercles de LEDs n’ayant pas pu être usinés par le GMP par manque de temps, nous les avons donc fait à l’IUT LAB. Pour cela nous les avons dessinés sur le logiciel CorelDraw puis fait découper par une découpeuse/graveuse laser (CNC) sur une plaque de contreplaqué de 5mm. Nous avons aussi découpé les diffusants sur une plaque de plastique transparent de 3mm.

Une fois les pièces finalisées, nous avons vissé/collé les cercles de LEDs sur leur support et mis en  place leurs diffusants.

Nous en avons aussi profité pour créer notre boitier de commande. Pour cela nous avons réutilisé la CNC afin de découper notre boîte dans une planche de contreplaqué de 5mm. Sur la face avant nous avons ajouté des trous afin de pouvoir fixer les différentes commandes sur le boîtier. Nous y avons aussi fait graver la fonction de chaque commande afin que l’interface soit clair pour l’utilisateur et quelques éléments esthétiques pour finalement obtenir ce résultat :

Conclusion :

Lors de ce projet nous avons pu apprendre beaucoup de choses. Nous avons notamment pu découvrir ce qu’était un optocoupleur et comment cela fonctionnait, ou encore comment contrôler un moteur pas à pas grâce à un arduino. La plus grande découverte fut le fonctionnement des LEDs adressables ainsi que la manière de les programmer grâce à sa bibliothèque de fonctions.

Au final, ce projet a pu nous apporter beaucoup de chose, tant en apprentissage qu’en mise en oeuvre de connaissances. Nous avons aussi pu découvrir et utiliser des machines complexes à l’IUT LAB ainsi que leurs logiciel d’exploitation. Tout cela fut très instructif malgré certains points n’ayant pas pu êtres testé en conditions réelles, dû à certaines pièces manquantes.

Ce projet pourrait donc être amélioré de plusieurs façons :

Pour commencer, nous pourrions usiner les différents plateaux initialement pensés.

Ensuite, nous pourrions tester notre programme de commande du moteur et le corriger aux besoins.

Une fois ces éléments fait, nous pourrions installer notre système sur le bâti initial.

Ces étapes importantes faites, nous pourrions refaire le câblage des éléments du projet, afin que notre boîtier de commande ne s’ouvre plus sous la pression des câbles à l’intérieurs.

Nous pourrions aussi le modifier en y ajoutant un bornier. Cela nous facilitera le câblage, le branchement/débranchement et le changement de caméra. Cela isolerait aussi le câblage à l’intérieur du boitier, ce qui nous garantira l’intégrité du câblage de la boite.

 

Nous espérons que ce projet pourra être continué l’année prochaine et que les améliorations citées ci-dessus pourront être mise en oeuvre.


Tracker Solaire

Sommaire

  1. Introduction
  2. Définition du besoin
  3. Analyse solaire
  4. Analyse mécanique
  5. Analyse électrique
  6. Réalisation
  7. Conclusion

 

Introduction

Dans le cadre d’un projet de deuxième année de DUT partagé entre le département GEII et le département GMP, nous travaillons sur un système de tracker solaire. L’objectif du projet est de créer un système asservi capable de suivre la trajectoire du soleil afin de maximiser le rendement de la production d’un panneau solaire. A travers ce document, nous allons présenter les différentes études menées, les problématiques rencontrées et les solutions proposées pour répondre à la problématique du projet.

Notre groupe est ainsi composé de 6 étudiants :

  • Kelian Khassani – GMP
  • Arnaud Zehringer – GMP
  • Timothé Roussel – GMP
  • Boubacar Diallo – GEII
  • Sofian Beldi – GEII
  • Hugo Houillon – GEII

Définition du besoin

La première étape de la réalisation de ce projet est la réalisation du cahier des charges et la définition du besoin ainsi que des différentes contraintes que nous serons amenés à rencontrer.

La but premier de ce projet est d’établir un système permettant pour l’instant à un panneau solaire de suivre la trajectoire du soleil afin de maximiser sa production.

 

Analyse solaire

La trajectoire du soleil se définie selon deux paramètres exprimés en degré :

 

  • L’azimut : Représente la position du soleil selon les 4 points cardinaux

 

  • La hauteur : Représente l’inclinaison du soleil par rapport à l’origine du plan horizontal

 

Les panneaux solaires devront donc être orientés de façon à être perpendiculaire aux rayons du soleil.

 

Afin de déterminer exactement les intervalles de position des panneaux selon ces deux paramètres, nous avons utilisé le site internet SunEarthTool. Ce site permet de calculer automatiquement la position du soleil dans l’année selon des coordonnées GPS.

Nous avons donc renseigné à ce site internet la position à laquelle nous souhaitons installer les panneaux solaires :

Une fois le site choisi, le site nous donne la position du soleil selon les mois de l’année :

 

Nous avons donc pu déterminer que le panneau solaire devra avoir une course de 50 à 310 ° en azimuth et de 20 à 90 ° en hauteur.

Afin d’estimer la production du panneau solaire tracké sur deux axes, nous avons utilisé un second site qui calcule automatiquement la production d’un panneau solaire selon les mois de l’année.

Nous avons renseigné les caractéristiques du panneau dont on dispose :

  • Puissance maximale : 145 W
  • Courant de court-circuit : 4,7 A
  • Tension maximum : 34 V
  • Courant maximum : 4,26 A

Nous avons regardé combien produirai potentiellement un panneau fixe incliné à 35° et combien produirai potentiellement un panneau tracké sur deux axes. Nous avons ensuite comparé les deux tableaux pour voir s’il est rentable d’effectuer un panneau solaire tracké sur deux axes.

 

En moyenne, nous remarquons qu’un système de panneau solaire tracké sur deux axes pourrait produire 30% de plus qu’un panneau fixe et incliné à 30°.

Il faut également faire attention au fait que le tracker ne doive pas consommer plus que le surplus produit par un système tracké pendant le mois le plus défavorable. Il faut donc que le tracker ne consomme pas plus de 1,2 kWh mensuel.

Analyse mécanique

Afin de permettre au panneau solaire de se déplacer sur 2 axes les GMP ont imaginé un système équipé d’un motoréducteur pour suivre l’azimut du soleil et d’un vérin électrique pour suivre la hauteur du soleil.

 

Analyse électrique

Toute l’énergie produite par le panneau solaire est acheminée au travers d’un régulateur de charge qui va s’occuper de charger les batteries correctement.

Pour ce projet, nous avons fait le choix de travailler en 24V. C’est pourquoi, nous avons acheté 2 batteries de 12V 12Ah branchées en série. Le motoréducteur et lé vérin électrique fonctionneront donc en 24V.

D’après l’analyse mécanique et électrique, nous devions trouver un vérin électrique avec les caractéristiques suivantes :

  • Course du vérin : 300mm
  • Force : 900N
  • Tension de fonctionnement : 24V

Nous avons donc acheté le vérin électrique MPP-EC 90kg 300mm 900N 24V.

 

Nous avons également acheté un motoréducteur qui fonctionne en 24V capable de faire tourner l’axe du système du tracker solaire.

 

Afin de capter la position du soleil, nous avons nous avons conçu un système composé de 3 photorésistances qui délivrent une tension analogique en fonction de l’intensité lumineuse. Ces trois photos résistances sont séparées chacune par une paroi opaque. Ce capteur est perpendiculaire aux rayons du soleil lorsque les trois photorésistances mesurent la même valeur d’intensité lumineuse.

 

Nous avons réalisé ce capteur et voici à quoi il ressemble :

 

Une fois que nous savons capter la position du soleil, nous avons donc réfléchi à comment piloter le motoréducteur et le vérin électrique pour orienter le panneau perpendiculairement aux rayons du soleil.

Pour se faire, nous avons décidé de travailler avec des modules Arduino. Premièrement, un Arduino UNO est utilisé pour interpréter les mesures des trois photorésistances. En fonction des valeurs lues, l’arduino va estimer s’il est nécessaire de modifier l’angle du panneau en azimut ou en hauteur. Il va envoyer les informations de commande à un Arduino Motoshield qui lui va piloter le motoréducteur et le vérin électrique.

Le MotorShield pilote les actionneurs en PWM. Il utilise en entrée le courant des batteries pour piloter les actionneurs.

Voici le schéma global de notre installation électrique :

 

 

Voici l’algorithme simplifié de l’Arduino qui va permettre d’orienter le panneau dans la bonne direction :

 

 

Nous avons mis en place un coffret électrique qui contient les batteries, le régulateur de charge et les modules Arduino :

 

Réalisation

Afin d’installer toute la structure du tracker et du panneau solaire, nous avons coulé une petite dalle en béton (1.20m * 0.8m) :

 

Conclusion

Nous n’avons pas pu continuer ce projet, malheureusement il nous manquait des pièces mécaniques, ce qui nous a empêché d’installer toute la structure. Nous laissons à disposition du futur groupe d’étudiant un dossier de conception du système de tracker solaire.

Ce projet nous aura permis d’apprendre à travailler en groupe et également a appréhender un projet : les contraintes qui s’y appliquent, la réalisation d’un cahier des charges, le travail de groupe, les dates limites, etc..

Ne pouvant plus nous rendre à l’université, il nous est impossible de joindre les codes arduino utilisés. Afin d’aider les futurs étudiants à la programmation de l’arduino, il va falloir utiliser une librairie arduino motorshield capable de piloter les actionneurs en PWM. Il faut également savoir lire et interpréter les valeurs analogiques fournies par les photorésistances.

Nous remercions l’ensemble des enseignants ainsi que le personnel de l’UHA qui nous auront permis de réaliser et d’avancer au mieux dans notre projet.

Dossier de conception Tracker Solaire


Réflecteur solaire automatisé

Projet réflecteur solaire automatisé

 

LUCAS Miguel                        KIEFFER Maxime                      NESTELHUT Alexandre

 

 

SOMMAIRE

 

     I.Préparation

              Contexte et principe

              Choix des techniques et du matériel

              Montage du réflecteur

              Recherche des coordonnées solaires

 

     II.Création du support

            Pied et rotation

             Cadre et pivotement

             Montage final (à compléter)

 

     III.Programmation

             Branchements et configuration

             Tests des servomoteurs avec des valeurs données

             Amélioration à l’aide de la carte SD

             Modifications complémentaires

 

     IV.Conclusion et remerciements

 

 

 I.Préparation

 

 1.Contexte et principe

Dans le cadre d’étude et réalisation du troisième semestre du DUT GEII (Génie Électrique et Informatique Industrielle), un projet nous a été confié par notre professeur référent, M. OULD ABDESLAM Djafar, consistant à étudier la mise en place d’un réflecteur solaire et ainsi dans un deuxième temps le réaliser dans le but de faire converger les rayons du soleil vers un point donné (par exemple une maison pour pouvoir chauffer celle-ci) d’une manière autonome.Ce type de réflecteur n’étant pas commercialisé en France, la conception et la programmation se créera de toutes pièces par notre groupe, et pourra aboutir à une présentation pour des entreprises intéressées et ainsi effectuer une potentielle mise sur le marché.

 

 

 

 

Ce réflecteur est composé d’une base solide afin de maintenir la structure stable en cas d’intempéries ou de temps indésirable. Sur celui-ci seront situés un servomoteur et un moteur pas à pas contrôlés par une carte Arduino permettant d’effectuer les rotations nécessaires, à savoir une horizontalement et l’autre verticalement pour que le miroir fixé à la structure puisse se mouvoir dans plusieurs positions et angles possible nécessaires à réflexion des rayons du soleil, ceux-ci devant incider sur un point précis, en l’occurrence ici les fenêtres du bâtiment afin de le chauffer ou d’améliorer sa luminosité de manière écologique.

 

 

2.Choix des techniques et du matériel

 

Nous avons utilisé un moteur pas à pas pour sa rotation continue permettant de faire plusieurs tours pour descendre et remonter le panneau, et inversement le servomoteur qui reste bloqué à son dernier angle lorsque l’on coupe l’alimentation pour pouvoir tourner et rester dans l’orientation voulue.

 

Nous avons utilisé une carte Arduino Uno étant donné que cette dernière est pratique dû à sa simplicité de fonctionnement et sa faible consommation. Pour alimenter le servomoteur ainsi que la carte Arduino, nous avons choisis un adaptateur USB 4 ports étant donné que la puissance délivrée par l’Arduino n’est pas suffisante pour le servomoteur. Une alimentation externe plus puissante est prévue pour le moteur pas à pas.

 

 

3.Montage du réflecteur solaire

 

 

Lors du montage, nous avons constaté que la fixation de base du panneau risquait de subir les aléas de la météo et ainsi fragiliser le réflecteur. Pour régler ce souci, nous avons eu l’idée de renforcer la structure avec des plaques reliées aux coins supérieurs et ainsi de remplacer l’ancien support.

 

 

 

4.Recherches pour les coordonnées solaires

 

Afin de réaliser notre projet, nous avons dû faire des recherches concernant les positions et trajectoires du soleil pour calculer les angles de rotation des servomoteurs, un par rapport au Zénith du Soleil et un par rapport à l’Azimut.

 

Azimut et Zénith (ici hauteur) :

 

 

 

Pour cela, nous avons utilisé de nombreux sites afin de nous renseigner au maximum tels que http://www.solartopo.com ou encore www.sunearthtools.com que nous allons utiliser pour récupérer les données.

 

Au préalable, nous avons calculé la hauteur (Zénith) grâce à une formule trouvée sur le site www.buzzcasonits.blogspot.com pour vérifier que les valeurs soient cohérentes.

 

 

Le meilleur moyen d’avoir les données étant de les récupérer directement sur le site web, nous avons téléchargé le fichier csv pour l’année 2019.

 

 

Par la suite nous avons testé nos hypothèses en vrai, grâce à notre réflecteur et à un Fluke Thermal Imager, muni d’un laser.

 

 

II. Création du support

 

1.Pied et rotation

 

Pour créer le support, nous avons récupéré un bon nombre de pièces. Tout d’abord, pour la base nous avons utilisé un tube rectangulaire muni d’un pied. Nous avons alors mesuré les dimensions du servomoteur puis découper le haut du support aux bonnes dimensions. Pour soutenir le servomoteur, la partie découpée a été pliée. Pour finaliser cette partie nous avons limé les bords afin d’éviter les rayures.

 

 

Ensuite nous avons tracé le schéma pour les parties supérieures du support. Nous avons découpé le tout dans du bois (medium). Ce système sera composé de 2 disques en bois, l’un posé sur l’autre grâce à des billes en verre calées dans un rainure afin d’éviter de mettre tout le poids de la partie supérieure sur le servomoteur

 

 

Après avoir tracé le schéma sur papier nous avons fait une modélisation 3D grâce au logiciel de CAO FreeCAD (logiciel libre totalement gratuit) dans le but de les réaliser grâce à la fraiseuse CNC 3 axes à l’IUTlab ; voici les figures représenter en 3D dans le logiciel :

 

 

 

Malheureusement nous n’avons pas pu réaliser les cylindres à la fraiseuse 3 axes ; nous les avons donc faits « à la main » : pour créer le cylindre ainsi que la gouttière nous avons utilisé la fraiseuse manuelle, pour les parties qui durent être creusée nous avons dégrossi le travail grâce à la perceuse à colonne puis affiné aux ciseaux à bois. Voici le résultat :

 

 

 

 

Pour pouvoir fixer le tout nous avons vissé (temporairement pour avoir un pied stable) une plaque bien plus grande en bois (medium de 5 cm d’épaisseur). Le tout monté donne ce résultat :

 

 

2.Cadre et pivotement

 

Une fois les deux cylindres fixés sur le pied nous sommes passés au second axe qui lui est en deux parties : le support du miroir et l’entraînement du servomoteur :

 

– le support en miroir est entouré d’un cadre en aluminium qui fait le pourtour du miroir, lui étant coincé entre une barre en bois et le cadre justement pour éviter de devoir le percer

 

 

 

-l’entrainement est fait par le servomoteur qui agit sur deux barres reliées entre elles et au miroir, mais le servomoteur manquant de puissance pour soulever le miroir nous allons devoir améliorer ce mécanisme.

 

 

3.Montage final

 

Après de multiples tests, nous avons constaté que le moteur n’était pas assez puissant pour pouvoir faire remonter le panneau. C’est pourquoi nous avons changé notre deuxième axe en utilisant une tige filetée avec un moteur pas à pas.

Contrairement au servomoteur, le moteur pas à pas va fonctionner en nombre de tours et va faire tourner la tige filetée ce qui va provoquer l’inclinaison du miroir.

 

 

Après avoir modifié cet axe, nous avons assemblé les deux parties entre elles grâce à trois vis et deux tiges filetés avec écrous.

 

 

 

III.Programmation

 

1.Branchements du système

 

A savoir : l’Arduino est alimentée grâce au port Vin connecté à l’un des servomoteurs directement branché sur le secteur

 

Configuration carte Arduino Uno

2.Test des servomoteurs avec des valeurs données

 

3.Amélioration à l’aide de la carte SD

 

Une fois que les moteurs tournent nous devons cette fois-ci obtenir les valeurs à leur envoyer à partir d’un fichier texte. Pour ce faire nous avons choisi l’option d’utiliser une carte SD car l’accès à celle-ci est plus simple que si nous devions accéder à la mémoire de l’Arduino. Nous avons donc commandé une extension SD pour notre carte Arduino UNO et branché soigneusement sur celle-ci.

4.Modifications complémentaires

 

 

Suite à l’avancement du projet, nous avons remarqués que notre programme initial ne convenait plus à nos besoins. Nous avons fait des modifications : une par rapport à la récupération de données et l’autre par rapport à une modification faite dans le montage.

 

– Modification pour la récupération de données sur un an : Dans ce cas , nous avons remplacé le fichier sur la carte SD par un fichier ayant les valeurs pour toute l’année, puis nous avons modifié le programme car la lecture sur un an n’est pas pareil que celle sur un jour.

 

 

-Modification pour le fonctionnement du moteur pas à pas

 

Dans ce cas, nous avons remplacé notre servomoteur par un moteur pas à pas donc nous avons changé la formule pour ce dernier. Pour cela nous calculons le nombre de pas de que le moteur doit faire pour obtenir le nombre de tours, ce qui diminuera ou augmentera la distance entre le moteur et le bout de la tige filetée et donc incliner le panneau d’un certain angle

 

 

 

IV.Conclusion et remerciements

 

Nous voulons tout d’abord remercier Mr OULD ABDESLAM Djafar de nous avoir guidé et aidé tout au long du projet. Nous voulons aussi remercier Mr DE SABBATA pour nous avoir donné de nombreux conseils et aussi pour nous avoir autorisé à utiliser l’IUT Lab pour nos besoins. Nous aimerions également remercier Mr WIRA pour son aide concernant la gestion de la carte SD et la lecture du fichier.

Pour conclure, ce projet a été pour nous une expérience importante pour notre cursus car nous avons pu travailler en groupe tout au long de l’année. Nous avons appris à nous partager les tâches, à faire des compromis entre nous pour pouvoir satisfaire au mieux les besoins du projet. De plus cette expérience fut d’autant plus enrichissante car nous avions un projet concret avec une réalisation à la clé qui s’est concrétisée.

Nous pouvons également ajouter à ce projet divers points d’amélioration, que ce soit remplacer les pièces en bois par de l’aluminium pour augmenter sa robustesse, un anémomètre permettant de coucher le panneau en cas de vent fort détecté, une cale pour éviter le redressement quelque peu brusque du retour en position initiale du panneau. Un capteur serait également à prévoir sous le miroir pour l’éviter de descendre trop loin et causer des dégâts.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Mallette qualité de l’énergie

Quentin JACQUEY

Anas BOUHSSINE

Emre TEKIN

Mise en œuvre d’un module WAGO

Rapport de Projet

Introduction

 

Dans le cadre de notre DUT GEII, il nous fallait réaliser un projet pendant notre troisième semestre. Ce projet reposait sur un automate programmable WAGO, celui-ci nous permettrait de réaliser des mesures et une récupération des données de consommations électriques d’une installation.

Nous avons alors dû programmer une interface graphique pour faciliter la prise en main de l’utilisateur.

Finalement, la récupération et affichage des données de l’automate se feront au travers d’un Janitza, un appareil de mesure couplé au WAGO.

 

Afin de mener à bien ce projet, nous avions à notre disposition une mallette, composée de l’automate auquel nous avons ajouté un appareil, tenant le rôle de transformateur 230/24 V afin d’alimenter l’automate. Nous avons également utilisé un Janitza, dont le rôle sera détaillé plus loin.

Sommaire

A. Objectifs

B. Ressources

  1. Avancement

  2. Installation

  3. Mesures

  4. Banque de données

  5. Reprise de toutes les étapes

C. Reprise de la banque de données

D. Difficultés rencontrées

E. Conclusion

F. Annexes

 

A. Objectif

Notre projet WAGO permet de mesurer et analyser une ou plusieurs installations électriques, ce qui permet à l’utilisateur de contrôler ou optimiser sa consommation électrique.

Nous avons comme projet également de transférer les données vers l’automate depuis un Janitza, afin de créer une banque de données qui va permettre de récupérer et stocker les données instantanées dans l’automate venant du Janitza.

B. Ressources

 

Pour notre projet, nous avions à disposition :

  • Automate WAGO (Référence 6028-2186)(Centrale Fastlogger 3G)

  • Module 750-494 Module de mesure

  • Module 750-495 Module de mesure

  • Module 750-600 Module d’extrémité

  • 3 sondes de courants 60V/1A
  • 4 boucles de Rogowski

 

 

 

Nous avons intégré un transformateur 230/24V qui est utilisé comme alimentation.

Nous utilisons comme câbles un câble d’ordinateur recyclé et dénudé. Nous branchons ce câble à la prise de la mallette.

Nous avons également utilisé plusieurs logiciels :

 

  • WAGO Ethernet settings

  • WAGO-IO Check

 

  • Fastlogger

Nous avions envisagé d’utiliser le logiciel Codesys et éventuellement un Raspberry PI afin de créer une base de données où stocker les données.

Nous avons finalement opté pour la solution du Janitza.

Le Janitza est un appareil de mesure  que nous avons utilisé afin de projeter les données récoltées par le Janitza vers notre automate.  Son installation et branchement sont détaillés ci-dessous.

 

C. Avancement

Le schéma ci-dessous démontre le but de notre projet et les différentes étapes de notre projet.

 

Notre projet ce sépare en plusieurs étapes :

  1. L’installation
  2. Les mesures
  3. Programmation envoi des données
  4. Reprise des étapes

Le contenu de chacune de ces étapes ainsi que l’avancement actuel sont développées ci-dessous.

 

1.L’installation

Nous avons dû, en premier lieu, nous approprier le matériel à disposition, et comprendre le fonctionnement de celui-ci en lisant les documentations techniques.

Les branchements de l’automate ont été préalablement effectués, il nous fallait cependant connecter l’automate à une alimentation. Là où les étudiants de l’année précédente avaient utilisé un transformateur externe, nous avons opté pour un transformateur interne à la mallette.  Pour cela, nous avons utilisé un transformateur 230/24V fourni par le professeur. Il nous fallait donc intégrer le transformateur dans la mallette qui nous était fourni. Pour cela, nous avons utilisé un câble d’ordinateur que nous avons dénudé afin de servir de câble d’alimentation reliant la prise de la mallette au transformateur.

Après avoir testé le bon fonctionnement du transformateur et de l’automate, il nous fallait maintenant s’occuper de l’adresse IP de l’automate.

Une adresse nous avait été fournie : 10.95.11.33, préalablement configuré grâce à WAGO Ethernet Settings cette adresse correspond à l’adresse de l’automate dans le réseau UHA.  Pour tester la concordance de l’adresse, nous avons configuré un ordinateur portable sur le même sous-réseau que l’automate à l’adresse : 10.95.11.32.

Après vérification, l’automate a la bonne adresse.

Nous avons également installé FASTLOGGER dans l’automate grâce aux étapes décrites en Annexe 1.

 

2.Mesures

Une fois l’automate correctement configuré, nous avons effectué des mesures grâces à des lampes halogènes.

Nous avons utilisé IO-CHECK pour voir les mesures.

Pour mesurer, nous avons utilisé les sondes de courants sur une seule phase.

Voici les mesures obtenues :

D’abord, avec les lampes à mi-puissance :

Puis avec les lampes à leur puissance maximale:

Grâce à ces mesures, nous nous sommes assurés du bon fonctionnement et du logiciel, et de l’automate.

En effet, nous constatons qu’à leur puissance maximale, les lampes produisent des harmoniques plus importantes et plus nombreuses, ce qui démontre le bon fonctionnement des mesures de notre automate.

 

 

3.Banque de Donnée

 

Pour créer une banque de données, nous envisagions d’utiliser CODESYS ainsi qu’un Raspberry PI. Cependant, nous avons  eu des problèmes vis-à-vis des logiciels. Nous possédions CODESYS 2.3, mais les automates WAGO ne sont pas reconnus comme des cibles du logiciel. Pour résoudre ce problème, nous avons communiqué avec Mr. MARTIN, qui travaille chez WAGO. Mr. MARTIN a répondu à notre demande et nous a donné accès au logiciel avec la référence de notre automate.

Nous avons trouvé la référence correspondante du logiciel qui allait avec notre automate. Nous pouvions désormais nous consacrer à la programmation de la banque de données. Quant au Raspberry PI, nous avions décidé d’abandonner l’idée de l’utiliser. En effet, le logiciel qui nous permettrait d’utiliser le Raspberry PI était payant.  De plus, CODESYS remplissait déjà toutes les fonctions nécessaires à notre projet.

Nous avions besoin d’accéder à la fonction ‘‘root’’ du logiciel Putty afin de pouvoir modifier, supprimer ou ajouter des fonctions dans l’automate. Pour y accéder, il nous fallait un identifiant et un mot de passe, malheureusement aucun des deux ne nous a été donné par les anciens étudiants en charge de ce projet. Nous étions donc obligés de reboot l’automate et refaire alors toutes les étapes décrites précédemment.

 

4.Reprise de étapes

 

Après avoir fait un « reset » de l’automate grâce à ces  étapes (Annexe 2), nous avons perdu toutes les données que contenait l’automate. Nous voulions donc reprendre toutes les étapes. Malheureusement l’adresse IP initiale qui nous a été donnée est fausse. Nous avions donc activement recherché l’adresse IP actuelle de l’automate. Nous avons trouvé comment faire (Annexe 2). L’adresse IP de l’automate est donc désormais 192.168.1.17.

Nous avons également reset les identifiants et mot de passe pour le site Web-Base Management, ce que l’on recherchait. Nous avons défini les mots de passe tel quels:

Identifiant :                  1.user                           2.admin

Mot de passe :            1.wago                         2.user

Nous avions donc dû refaire toutes les étapes précédentes, une fois l’adresse IP de l’automate reconfiguré sur 10.95.11.33.

 

Après que notre automate ait été reconfiguré correctement, nous pouvions reprendre la programmation de la banque de données grâce à Codesys.

Nous avions pour cela configuré le logiciel pour qu’il reconnaisse l’adresse de l’automate.

 

Afin de compiler et charger le programme dans l’automate, nous avions besoin d’un mot de passe qui était :

Mot de passe : user

Ainsi, nous avons réussi à transférer le programme dans l’automate, nous pouvions alors récupérer les données de la consommation électrique des installations.

Le résultat est montré ci-dessous.

Après de nombreux tests, nous avions compris qu’il nous fallait utiliser Fastlogger après avoir discuté au téléphone avec notre contact WAGO.

 

Après avoir eu accès aux pleins pouvoirs sur l’automate grâce à Putty (Annexe 3), nous avons pu accéder à Fastlogger, que nous avions installé précédemment. Ce logiciel nous permet d’accéder directement aux données récoltées dans l’automate.

 

Le logiciel Fastlogger se présente sous cette forme :

 

Après avoir vu un aperçu de ce que donnait la récolte des données.

Fastlogger va nous permettre d’archiver ces données sur un fichier .csv contenu dans la carte mémoire.

Nous allons alors transférer ces données archivées et récoltées sur un serveur FTP donné par l’IUT.

Malheureusement, le serveur FTP était inutilisable, en effet,  la complexité du réseau empêchait d’établir une liaison avec notre automate. Nous avons donc dû abandonner l’idée du serveur.

Nous devions également nous servir d’un module de mesure, le Janitza 96 RM-E. Il s’agit d’un équivalent du Wago que nous utilisons comme centre de mesure. Pour cela, nous avons connecté le Janitza avec l’automate en Modbus TCP/IP afin de récupérer les valeurs mesurées par le Janitza. Le Wago sert alors de centre de collecte des données du Janitza que l’on enregistre sous CSV grâce à un adressage spécifique.  (ANNEXE 4)

 

D. Difficulté rencontré

 

Lors de notre projet, nous avons rencontré certaines difficultés. En effet, la première difficulté fut de trouver le logiciel adapté pour nous permettre de coder notre banque de données. Après avoir trouvé Codesys, la difficulté a été de nous le procurer. La version WAGO n’étant pas disponible sur leur site, nous avons envoyé des mails à notre contact MR. Martin, il nous a envoyé un lien pour le télécharger mais qui ne contenait pas la référence de notre automate. Il nous a alors fallu attendre qu’il nous renvoie le lien contenant le logiciel avec notre référence.

  • Nous avons rencontré des difficultés afin de transférer le programme depuis le logiciel vers l’automate. Nous avons donc essayé plusieurs méthodes. D’abord avec un câble ETHERNET, cela ne marchait pas. Nous avons alors essayé avec un câble RS232, cela ne marchait pas non plus. Enfin nous avons branché l’automate sur le réseau, et nous avons pu nous connecter à lui depuis le logiciel grâce à son adresse IP.
  • Le problème majeur que nous avons rencontré a été l’accès au noyau de l’automate Wago. En effet l’installation du fastlogger doit se faire dans le noyau par le logiciel « Putty ». Ce logiciel comporte 3 utilisateurs. Le premier ne servant à rien est « User » utiliser pour voir les fichiers installé dans le noyau. Le second est « admin » qui peut être utilisé pour accéder au noyau et y transférer certains fichiers. Enfin il y a le super admin « root » qui donne libre accès à toute manipulation du noyau. C’est celui-ci qui était la cause du problème car le mot de passe défaut a été modifier.

La solution est donc de réinstaller le firmware du wago (Annexe 5…) et d’utiliser le mot de passe par défaut.

  • Nous avons eu également l’idée d’utiliser un serveur FTP afin d’y stocker les données. Malheureusement, la connexion de l’automate avec le serveur était impossible, dû à la complexité du réseau UHA (sécurité).
  • Nous avons donc dû utiliser un Janitza 96 Rm-E. La complexité de son utilisation ainsi que celle de la connexion avec notre automate nous a apporté des difficultés sur la compréhension de ceux-ci. Grâce à des recherches fructueuses, nous avons compris son utilisation et nous avons donc pu utiliser le Janitza tel que nous en avions besoin.

 

E. Conclusion

 

Si on devait résumer notre projet, nous pourrions dire que nous avons apporté :

  • Un transformateur interne, afin d’alimenter de manière autonome l’automate
  • Modification des mots de passe des différents logiciels que nous avons dû réinitialiser
  • Installation du Fastlogger dans l’automate, ainsi que son codage et son utilisation
  • Après de nombreux problèmes, l’utilisation du Janitza comme module de mesure et utilisation de notre Wago comme centre de collecte de ces données

Cependant, nous sommes conscients que notre projet aurait pu être amélioré :

En effet, si l’utilisation du serveur FTP, la récolte des données aurait pu être plus ludique et attractive.

Nous aurions pu également créer une interface graphique pour mieux représenter les données récoltées à partir du Janitza.

 

F. Annexes

 

Annexe 1 : Installer FASTLOGGER

  • Copier-coller le fichier .ipk dans le dossier tmp du FTP du contrôleur
  • Ouvrir une connexion SSH sur le contrôleur grâce à Putty [se connecter avec les identifiants suivant : root (utilisateur) et wago (mot de passe)]
  • Sous Putty, ouvrir le dossier tmp (grâce à la commande « cd /tmp »).
    Il faut respecter l’espace entre le ‘d’ et le ‘/’
  • Lancer la commande d’installation :« ipkg install install-fastlogger_1.2.10_arm.ipk ».

Il faut respecter tous les espaces et bien renseigner le nom du fichier y compris l’extension. FASTLOGGER se lance donc.

Annexe 2 : Reset et trouver l’adresse IP

Reset :

  • Appui sur Bouton « RST » pendant 8 secondes, jusqu’à ce que la led « SYS » clignote en orange.
  • Mettre le Switch en mode « Reset ».
  • Attendre 3 secondes le temps que la Led « Sys » soit rouge.

Trouver adresse IP :

  • Mettre le Switch en mode « STOP »
  • Appui sur Bouton « RST » pendant 8 secondes, jusqu’à ce que la led « SYS » clignote en orange
  • L’adresse IP de l’automate est alors : 192.168.1.17

Source : Data sheet 750-8207

 

Annexe 3 : Avoir les pleins droits sur l’automate

 

Sur Putty, rentrer les informations telles quelle :

Un message d’information va s’afficher, cliquer sur « Oui ».

Une boite de dialogue va alors s’afficher :

S’identifier en tant que « root », le mot de passe correspondant est : « user ».

Vous aurez dès lors un accès total sur l’automate, c’est-à-dire que vous pourrez avoir accès aux programmes installés sur l’automate, les modifier, en supprimer, ou en créer.

 

Annexe 4 : Configuration Janitza

 

Configuration de l’adresse IP du Janitza :

Appuyer pendant 5 secondes sur la touche 1 et 2 du janitza pour entrer dans le mode de paramétrage du janitza.

La navigation dans le menu est possible grâce à la touche sur laquelle se trouve une flèche vers la droite et la validation la touche vers le haut.

En navigant dans ce menu, on peut changer l’adresse IP du Janitza dans la sous-section addr où l’adressage ce fait en 4 étapes.

Suite à cela on rentre cette adresse dans la case dédié dans le fastlogger dans l’onglet configuration modbus TCP/IP

Dans l’onglet requête, on ajoute l’adressage spécifique à la valeur que l’on veut.

Dans l’onglet donné on peut visualiser les données et aussi archiver les valeurs que l’on souhaite.

Attention à l’ état !!

Etat 150: Sans réponse

Etat 129: Problème Communication

Etat 0: En fonctionnement

Visualisation des données avec possibilité d’archivage.

 

Attention à l’adressage ! L’adressage fournit dans le noyau du wago est incorrecte et il faut ajouter un par un les adressages de registre que l’on souhaite récupérer retrouvable dans la datasheets du Janitza.

Annexe 5 : Réinstallation Firmware

1.Télécharger ce fichier

http://www.wago.com/public-download/Support/FW/0750-8xxx/WAGO_FW_0750-8xxx_I.ZIP

2.3.4.

5. Insérer la carte SD dans le PFC200 ou la microSD dans le PFC100, puis le redémarrer électriquement. Le lecteur de cartes SD ou microSD clignote orange pendant plusieurs secondes. L’image du noyau est automatiquement chargée dans la mémoire RAM.

Après la séquence d’initialisation, les LEDS SYS et I/O sont vertes fixes. La LED RUN est rouge fixe, le lecteur de cartes SD ne clignote plus.

A ce stade, l’image du noyau est simplement présente en mémoire RAM, il est nécessaire de la copier sur la mémoire Flash interne.

6. Une fois tous cela fait connecter vous à Web-Based Management.

7. Retirer la carte SD ou microSD, puis redémarrer le PFC. Le PFC a été mis à jour. Retourner sur le Web-Based Management afin de vérifier la version du firmware.

8.La carte SD n’est pas utilisable en stockage. Il faut donc la formater.

 

 


Supervision Efficacité Energétique

HEGE Simon

MINERY Loïc

Rapport Efficace Energie

Projet 2018/2019

 

 

 


Sommaire

  1. Remerciements

  2. Introduction

  3. Cahier des Charges

    1. Bêtes à corne
    2. Diagramme pieuvre
    3. Partage des tâches
    4. Schéma de fonctionnement
    5. Environnement logiciel
    6. Environnement matériel
    7. Capteurs utilisés
    8. Comparaison capteurs
      1. Première partie
      2. Deuxième partie
  4. Recensement capteurs

    1. Création d’une interface VBA sur Excel
  5. Logiciel EfficaceEnergie

    1. Prise en main
    2. Création plan IUT
    3. Enregistrement nouveaux capteurs
    4. Compte admin et utilisateur
    5. Analyse de résultats
  6. Conclusion

  7. Annexes

    1. Captures d’écrans Comparaison
    2. Novembre
    3. Septembre
    4. Octobre

Remerciements

Nous tenons à remercier notre professeur référent, M. Ould qui nous a proposé ce projet et nous a guidé tout au long de ses semaines de recherches et de supervision. Nous souhaitons également remercier M.Marco SANGWA qui nous a permis d’utiliser son rapport de stage.

Introduction

Le but principal de ce projet était d’analyser les données de capteurs de la société Distrame afin d’avoir une meilleure efficacité énergétique au sein de l’IUT de Mulhouse. Notre projet Efficacenergie a donc consister en l’installation de capteurs dans l’établissement, puis en leur enregistrement dans le logiciel Efficacenergie afin de relever leurs courbes de consommation ou leurs courbes de température. Nous avons recenser les capteurs existants et nous avons analyser les données des capteurs déjà installés. Nous avons également utilisé le rapport de stage de M. Marco SANGWA, étudiant de l’année passée, qui nous as permis de comprendre le fonctionnement des différents logiciels afin d’installer les capteurs plus facilement et plus rapidement.


Cahier des Charges

Bêtes à corne

 

Diagramme pieuvre

Contraintes majeurs

  • Plan interactif : Le plan devait être clair et intuitif afin de pouvoir effectuer le suivi de la consommation pour chaque capteur.
  • Déclaration des capteurs : Chaque capteur devait être déclaré sur le logiciel wavenet, on lui a attribué ensuite un répéteur si cela était nécessaire.
  • Cohérence des valeurs : Trouver l’origine d’un décalage de ± 9 % entre les relevés des capteurs Distrame et UHA.

Contraintes mineurs

  • Esthétique : L’interface doit être esthétique dans la mesure du possible.
  • Fiabilité : L’interface doit fonctionner correctement ainsi que la déclaration des capteurs dans l’architecture.
  • Simplicité : Elle doit être simple d’utilisation.
  • Sécurité : Mise en place de comptes utilisateur et administrateur.

Partage des tâches

MINERY Loïc :

  • Création plan IUT interactif avec courbes et mesures pour chaque capteur de chaque bâtiment.
  • Comparaison capteurs UHA et Distrame
  • Recensement des capteurs
  • Installation des nouveaux capteurs
  • Powerpoint

HEGE Simon :

  • Création de l’interface pour le recensement des capteurs
  • Recensement des capteurs
  • Comparaison capteurs UHA et Distrame
  • Installation des nouveaux capteurs
  • Rapport

Schéma de fonctionnement

Environnement logiciel

  • Interface Distrame Efficacenergie
  • Logiciel Wavenet monitor
  • Logiciel Diris Digiware

Environnement matériel

  • Capteurs
  • Ordinateurs

Capteurs utilisés

Comparaison capteurs

Première partie

Notre enseignant référent, M. OULD nous a demandé de comparer sur plusieurs mois les valeurs de consommation électriques mesurées par les capteurs de la société DISTRAME et ceux de l’UHA. Nous avons utilisé le logiciel EfficaceEnergie ainsi que le logiciel Diris Digiware de l’UHA, auquel nous avons eu accès grâce au compte utilisateur de M. OULD. Nous avons ainsi comparé les données des capteurs installés dans différents bâtiments.

 

Tableau de la consommation des bâtiments selon le mois

Tableau de la consommation des bâtiments par semaines

 

Nous avons alors remarqué que les capteurs UHA ont toujours des valeurs plus élevées que ceux de DISTRAME sauf au mois de Juillet (valeurs en rouges) où nous constatons que les capteurs UHA du bâtiment A et Générale sont plus élevées que ceux de Distrame.

Nous avons calculé les pourcentages de différences entre les capteurs et il semble qu’en générale, sur trois mois, la différence soit d’environ 9 %.

Conclusion première partie

Nous avons remarqué une différence d’environ 9 % entre les capteurs des deux sociétés. Nous avons alors contacté, par mail et téléphone, M. LALLEMANT, un agent de DISTRAME, pour lui demander s’il avait une explication à cette différence entre les capteurs. Il ne pouvait malheureusement pas nous répondre. Nous avons ensuite contacté par téléphone M. SCHMIDT qui nous a redirigé vers le support de Distrame. Un agent nous a demandé les références de nos capteurs ainsi que celles des compteurs. Il souhaitait aussi connaitre les valeurs de nos boucles de courants, mais nous n’y avons pas accès seul.  Nous lui avons envoyé toutes les informations par mail par deux fois, sans réponse de sa part.


Deuxième partie

Notre enseignant référent nous a demandé, dans un second temps, de comparer les valeurs de consommation électriques des capteurs DISTRAME et UHA mais cette fois sur une période de 6 mois. Ainsi , nous avons comparé les données du mois de juillet 2018 au mois de décembre de la même année afin de vérifier si la différence de 9 % persistait sur une longue période.

Rapport de consommation sur la période juillet-décembre 2018

Consommation bâtiment A

 

La valeur du capteur Distrame de consommation du bâtiment A est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 3.94%.

Nous observons un pic de consommation à environ 200 kWh pour le capteur UHA, à la date du 10 décembre 2018, qui n’est pas présent sur le relevé du capteur Distrame.

Consommation bâtiment B

 

La valeur du capteur Distrame de consommation du bâtiment B est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 3.59%, ce qui est assez proche de la valeur obtenue pour le bâtiment A.

A la date du 10 décembre 2018, nous observons à nouveau un pic de consommation à environ 440 kWh pour le capteur UHA, qui n’est pas présent sur le relevé du capteur Distrame.

Consommation bâtiment C

 

La valeur du capteur Distrame de consommation du bâtiment C est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 2.52%.

 

Nous observons encore un pic de consommation à environ 700 kWh pour le capteur UHA, à la date du 10 décembre 2018, qui n’est pas présent sur le relevé du capteur Distrame. Les relevés sont cohérents.

Consommation bâtiment E

 

La valeur du capteur Distrame de consommation du bâtiment E est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 1.99%, ce qui est beaucoup moins élevé que les valeurs obtenues pour les bâtiments A et B.

 

A la date du 10 décembre 2018, nous observons de nouveau un pic de consommation à environ 760 kWh pour le capteur UHA, qui n’est pas présent sur le relevé du capteur Distrame. Les relevés sont cohérents.

Consommation bâtiments DFGH

 

La valeur du capteur Distrame de consommation des bâtiments D, F, G et H est cette fois-ci moins élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons donc un point de pourcentage négatif de -2.04%.

A la date du 10 décembre 2018, nous observons un pic de consommation à environ 1300 kWh pour le capteur UHA qui n’est pas présent sur le relevé du capteur Distrame.

Consommation logements de fonctions

 

La valeur du capteur Distrame de consommation des logements de fonctions est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous obtenons un point de pourcentage de 1.14%, ce qui qui représente l’écart le plus faible entre les capteurs de l’UHA et ceux de Distrame.

On n’observe pas de pic de consommation au 10 décembre, les deux graphiques semblent équivalents.

Consommation générale de l’IUT

 

La valeur du capteur Distrame de consommation générale est plus élevée que celle du capteur UHA mais les valeurs sont cohérentes. Nous observons un plus grand écart avec un point de pourcentage de 4.74%.

On observe un pic de consommation le 10 décembre 2018 pour environ 3500 kWh.

 

Nous avons remarqué une différence entre les valeurs générales mesurées par les capteurs et celles obtenues en additionnant les valeurs obtenues précédemment. Ainsi, la valeur mesurée par le capteur UHA est plus petite que celle obtenue par la somme alors que la valeur mesurée par le capteur Distrame est plus élevé. Les valeurs obtenues par la somme sont plus cohérentes car plus rapprochées l’une de l’autre.

Conclusion deuxième partie

Nous avons remarqué que les relevés des capteurs UHA et Distrame sont cohérents entre eux. Les valeurs des capteurs Distrame sont généralement plus élevées que celles des capteurs UHA sauf pour les bâtiments D-F-G-H.

Nous avons également remarqué un pic de consommation au 10 décembre 2018, uniquement présent sur les relevés des capteurs UHA. Ce pic n’est pas présent sur le relevé de la consommation des logements de fonctions ni sur les relevés des capteurs Distrame. Il s’est donc produit quelque chose au niveau des capteurs UHA ce jour-là.

Enfin, la moyenne de la différence des pourcentages entre les valeurs obtenues sur 6 mois par les capteurs UHA et Distrame est de 1.99%, en comptant le pourcentage négatif des bâtiments D-F-G-H. On remarque donc que la différence de 9% sur une semaine diminue à 2 % sur 6 mois ce qui est une très bonne chose. Les différents capteurs ne donnent donc pas des valeurs trop différentes.


Recensement capteurs

Tout d’abord, nous avons recensé tous les capteurs non-installés physiquement, car il y en avait des nouveaux et des anciens, puis nous avons vérifiés lesquels étaient déjà enregistrés dans EfficacEnergie. Nous en avons également profité pour vérifier les noms de tous les capteurs sur le logiciel et repérer les doublons, les capteurs obsolètes ou bien tout simplement les capteurs mal déclarés.

Ainsi, nous avons comptés 14 capteurs-émetteurs et 5 répéteurs non-installés physiquement. Sur ces 14 capteurs, 10 sont des capteurs waveflows, 3 sont des nouveaux capteurs et 1 seul est un capteur wavesense. Sur les 3 nouveaux capteurs, nous avons 2 capteurs wavetherms et 1 capteur LEM.

Nous avons également recensé 5 répéteurs dont 2 sont des wavetalks.

Certains capteurs non-installés physiquement étaient déjà enregistrés sur le logiciel EfficacEnergie, nous n’aurons donc pas besoin de les enregistrer mais juste les installer sur un compteur. Ils étaient enregistrés sous le collecteur Ethernet qu’il faudra changer pour le collecteur Webdyn. C’était le cas des WFL3 à 9.

Ensuite, nous avons recensés les capteurs physiquement installés dans l’enceinte de l’IUT. Certains capteurs étaient enregistrés sous le collecteur Ethernet dans le logiciel EfficacEnergie, ils ne donnaient donc aucun relevé sur le logiciel. Ainsi le capteur WFL de la salle B010 n’envoyait aucun résultat depuis avril, date à laquelle il a été mis sur le mauvais collecteur. Afin de les faire fonctionner, nous les avons enregistrés sous le collecteur Webdyn qui reçoit toutes les données et les envois au serveur.

Mise en place du capteur sur le collecteur webdyn

Nous avons aussi remarqué que certain capteur enregistré ne correspondait en réalité à aucun capteur réel, il faudra donc les supprimer.

Capteurs ne relevant aucunes données car n’existant pas physiquement

D’autres capteurs étaient utilisés en double sous deux noms différents, nous allons donc en supprimer un des deux.

Capteurs existants en double


Création d’une interface VBA sur Excel

Cette interface permet de rechercher rapidement l’adresse radio, la localisation ainsi que le type de capteur associés au nom d’un capteur ou répéteur. Elle permet également d’ajouter à tout moment un capteur ou un répéteur en plus.

Tableau Excel recensant les capteurs + Interface

Logiciel EfficaceEnergie

Prise en main

Pour débuter, nous avons créé un fichier à notre nom, dans lequel nous avons créé tous les graphiques et tableau. Afin d’obtenir ces fameux graphiques, nous nous sommes aidés du rapport de projet de l’année dernière ainsi que de l’aide présente sur le logiciel.  Nous avons ainsi créé notre premier graphique.

 

Paramétrages permettant la création d’un graphique

Comparaison de la consommation entre les bâtiments de l’IUT (RGB) et la courbe de consommation générale (Noir)

 

Nous remarquons sur ce graphique que la consommation générale n’est pas l’addition de toutes les consommations mais plutôt leur moyenne.

Après la création d’un graphique nous avons voulu créer un tableau.

Graphique et tableau montrant la consommation du bâtiment B sur une journée (Les graphiques barres ont été remplacés par des graphiques linéaires depuis)


Création plan IUT

Après avoir pris en main le site EfficacEnergie, nous avons été capable de créer une carte de l’IUT avec la position des capteurs et ce qu’ils mesurent. Pour cela, nous nous sommes aidés  du rapport de projet de l’année dernière dans lequel toutes les positions des capteurs étaient précisées. Après vérification, certains capteurs avaient malheureusement été changés de place comme le capteur de température WTH salle B016 qui à été déplacé dans l’amphithéâtre nord et que nous avons donc renommé. Nous avons également nous-mêmes rajouté certains capteurs, comme le capteur de température de la cave A ou bien encore celui du bureau de M.Ould.

Plan interactif de l’IUT

Chaque capteur est ainsi représenté par un point avec son nom sur lequel on peut cliquer afin d’avoir le détail de ses mesures. S’il s’agit d’un capteur de température, il est représenté par un point rouge tandis qu’un capteur de consommation est lui représenté par un point vert. Lorsqu’il s’agit de la consommation de plusieurs bâtiments, le capteur est représenté par une maison.

Détail des mesures du capteur de température du bâtiment A

Enregistrement nouveaux capteurs

Le cahier des charges du projet impliquait d’installer de nouveaux capteurs aussi bien physiquement que sur le logiciel. Ainsi, nous avons installé deux capteurs de température Wavethermes que nous avons appelés respectivement WTH15 et WTH16. Le capteur-transmetteur WTH15 a été installé dans le bureau de M. Ould tandis que le WTH16 à lui été installé dans la cave du bâtiment A par un technicien de l’IUT. Avant de les installer physiquement, nous les avons d’abord configurés dans le logiciel wavenet monitor, permettant de vérifier qu’ils fonctionnent correctement et de créer l’architecture réseau.

Ajout d’un capteur à l’aide de son adresse radio

Capteur assigné par défaut. Mauvaise architecture.

Capteur assigné au waveport. Bonne architecture.

Test du signal du capteur concluant

Puis nous avons rentrés les capteurs dans le logiciel Efficaceenergie grâce à leurs codes. Nous avons ensuite pu effectuer toute sortes de tests comme le test RSSI, qui permet de vérifier le pourcentage de signal qui arrive au collecteur, le test de batteries, qui permet de voir le pourcentage de batteries restantes dans chaque capteurs et transmetteurs, ainsi qu’un test de rapatriement, qui permet d’enregistrer la valeur que le capteur lit à l’instant présent.

Activation du collecteur WebdynRF obligatoire pour ajouter des capteurs

 

Ajout du capteur avec sa période d’échantillonnage

 

Test signal du capteur

 

Test du niveau de batterie

 

Test des valeurs rapatriées depuis le capteur


Compte admin et utilisateur

Nous avons créé un compte admin dans lequel nous pouvons ajouter des capteurs et créer des tableaux et courbes. Le compte utilisateur ne permet pas de créer de courbes mais uniquement de visualiser les relevés dont l’admin a donné les droits de visualisation. Nous ne pouvons malheureusement pas créer de compte où l’on pourrait créer des graphiques mais ne pas avoir accès aux configurations.

Fichiers et paramètres auxquels l’admin à accès

Seul le fichier avec le plan et le paramètre de déconnexion sont accessibles au compte utilisateur

Analyse de résultats

Le capteur WFL salle B010 donnait des courbes inadéquates. En effet, les courbes étaient sous formes de pulsions complètement irréalistes pour une valeur de consommation. Nous avons vérifier son branchement au compteur et cela ne changeant rien, nous avons décidé de l’enlever car il ne servait à rien.

Consommation en janvier 2019

Consommation en avril 2018

Le capteur de température de la cave A marche correctement et on remarque que la température reste bien constante à 16 degrés Celsius.

Température de la cave par jour durant une semaine

Le capteur de température du bureau de M. Ould marche lui aussi correctement et on remarque que la température baisse jusqu’à 18 degrés Celsius le week-end, notamment le dimanche. En effet, l’IUT pour baisser sa consommation ne chauffe pas les salles le week-end. Le dimanche 3 mars, la température dans le bureau reste à 20 degrés Celsius car il y avait les portes ouvertes ce week-end là.

Température du bureau de M.Ould tous les jours sur un mois

Conclusion

Notre projet abouti permet la visualisation et l’analyse des données des capteurs de la société Distrame afin d’avoir une meilleure efficacité énergétique au sein de l’IUT de Mulhouse. La surveillance de la consommation par les intervenants de l’IUT sera aussi plus efficace et rapide grâce à la carte interactive. Cette carte devrait être mise sur grand écran au sein même de l’IUT afin que le public puisse y accéder à tous moment grâce au compte utilisateur. La justesse des données pourrait être améliorée si l’on découvre d’où vient la légère différence entre les capteurs UHA et Distrame. Notre projet a également permis la surveillance de la température de la cave A afin que la bière du projet micro-brasserie automatisée soit toujours à bonne température. Il permettrait également la surveillance de la production énergétique du projet Centrale d’autoconsommation solaire.


Annexes

Septembre

Relevé du capteur de consommation Distrame du bâtiment A

Relevé du capteur de consommation UHA du bâtiment A

Octobre

 

Novembre

 

 

 


Micro-Brasserie solaire automatisée

Sommaire:

Remerciement

Introduction

  1. La passionnante histoire de la bière
    1. Chronologie de la bière
    2. Fabrication
  2. Réalisation des bières de GEII
    1. Première bière: apprentissage de brassage
    2. Deuxième Bière: consommation d’énergie
  3. Automatisation
    1. liste du matériel nécessaire
    2. Motorisation du moulin
    3. motorisation du malaxeur
    4. Asservissement de température
  4. Amélioration possible
  5. Conclusion

Remerciements:

Ce projet n’aurait pu être réalisé sans l’aide d’une multitude de personnes que nous tenons à remercier ici. Parmi elles :

– M. Ould-Abdeslam pour la proposition et le suivi complet de ce projet ainsi que pour les commandes de matériel,

– les techniciens de l’IUT qui nous ont permis d’automatiser le moulin à l’aide d’une simple pièce qui nous manquait,

– M. De Sabatta pour sa patience et ses nombreux conseils,

– M. Hiebel, du lycée Charles de Gaulle à PULVERSHEIM, section “chaudronnerie”, pour la tôle en inox qui nous manquait afin de réaliser notre malaxeur.

Nous tenons également à remercier M. Drouaz qui nous a apporté des conseils pour la fabrication de la bière et qui était présent à chacun de nos brassages ainsi que pour les stérilisations du matériel, ainsi que toutes les personnes qui se sont démenées pour nous trouver des bouteilles de bières refermables ou qui peuvent être encapsulées.

Pour finir, nous remercions l’IUT qui nous a donné le financement pour aboutir et surtout commencer ce magnifique projet.  

Introduction:

Nous sommes deux étudiantes de deuxième année en GEII: Toussaint Raphaëlle et Dusausay Laura.

Dans le cadre de notre scolarité, nous avons choisi, dans notre projet, de créer une microbrasserie, dont l’automatisation exploite l’énergie solaire.

Mais dans un premier temps, laissez-nous vous faire découvrir cet art ancestral à travers son histoire, sa fabrication ainsi que son automatisation.

1.La passionnante histoire de la bière :

    1. Chronologie de la bière

Le principe de la bière est de réaliser une fermentation de céréales. La première a vu le jour à Jericho (à côté de Jérusalem)  en 12 000 avant J.C.

Celui-ci s’est développé partout dans le monde en faisant évoluer sa recette de siècle en siècle.

En 4 000 av JC, en Egypte, la bière était une boisson divine. Plus tard elle gagnera l’Europe en devenant une boisson remplie de vertus médicinales. En 1435 ce sont les prêtres qui ont l’exclusivité de la fabrication de ce breuvage. Puis durant l’ère industrielle Pasteur va faire la découverte de la levure ce qui va révolutionner le mode de préparation. Finalement ce n’est qu’en 1950 que la bière va commencer à être industrialisée.

    1.2 Fabrication

1.2.1 Matières premières

Eau Il faut 6L à 8L pour 1L de bière
malt Orge germé et caramélisé, froment, ou seigle
houblon Pour l’amertume, l’arôme, aseptisation, digestibilité
levure Pour la fermentation alcoolique

Tab 1: Les matières premières de la bière

1.2.2 Les 5 grandes étapes

maltage Le malt crée les enzymes nécessaires à la  création d’alcool lors de la fermentation (déjà fait lors de la commande du malt)
Le brassage On hydrate et chauffe le malt permettant l’activation des enzymes ainsi que l’obtention des sucres
cuisson du moût On filtre la fermentation. Le liquide qui en ressort est chauffé à plusieurs températures avec du houblon et d’autres épices. Cette étape permet de donner du goût à la bière
fermentation Cela désigne la réaction chimique qui transforme le sucre en alcool. L’ajout de levure permet de gérer ce procédé.Celui-ci est fait en 2 temps de repos avec des températures différentes.
la garde Procédé de la gazéification

  Tab 2: Explication des procédés de fabrication

2.Réalisation des bières de GEII

    2.1 Première Bière: apprentissage de brassage

Pour notre projet nous avons commandé une microbrasserie afin de l’automatiser. Mais avant toute chose il fallait que l’on se familiarise avec les différents procédés pour connaître les étapes essentielles à automatiser.

Nous voilà donc parties dans la création de notre Première bière.

2.1.1 Matériel et matières premières

Pour 20L de bière:

Kit Brewferm; Une balance; Un minuteur; Récipient pour le malt concassé; Rallonge électrique; Cotons tiges pour stériliser le robinet des cuves

4,4 kg de malt du kit Brewferm; Houblon du kit Brewferm; Eau (suffisamment pour les différentes phases de cuisson et le refroidissement); Sucre Candy du kit Brewferm; Levure du kit Brewferm

2.1.2 Recette de fabrication

Pour commencer, moudre le malt à l’aide du moulin.

Faire chauffer 20 L d’eau jusqu’à atteindre 52°C. Puis ajouter le malt. Après 15 minutes de cuisson, augmenter la température à 62°C puis attendre 45 minutes. Augmenter la température jusqu’à 72°C puis laisser cuire 15 minutes. Enfin, augmenter la température jusqu’à 78°C et attendre 5 minutes. La phase d’empâtage est terminée, on peut passer à la filtration.

Mettre le contenu de la cuve dans une cuve de filtration puis récupérer le liquide sortant du robinet qu’on remet à nouveau dans la cuve de filtration jusqu’à ce que le liquide devienne plus clair.

Vider le contenu de la cuve par le robinet dans la cuve chauffante jusqu’à atteindre 24 L. Pour cela, ajouter de l’eau à la température de 75°C dans la cuve de filtration et patienter. Une fois la valeur de 24L atteinte, faire chauffer jusqu’à atteindre l’ébullition. Une fois le mélange porté à ébullition mettre la chaussette contenant le houblon et patienter pendant 80 minutes.

Commencer à stériliser le refroidisseur, la cuillère ainsi que la cuve de fermentation.

ATTENTION : une fois stérilisé, il ne faut plus mettre ce matériel en contact avec autre chose que la future bière.

A la fin des 80 minutes de cuisson, enlever la chaussette et passer à la phase de refroidissement.

Brancher un tuyau entre le robinet de la cuve chauffante et le refroidisseur, un tuyau entre le refroidisseur et la cuve de fermentation, brancher un tuyau entre le refroidisseur et le robinet d’eau froide et le dernier tuyau entre le refroidisseur et l’évier dans lequel ressortira l’eau qui sera chaude. Activer l’eau froide avec un gros flux puis ouvrir le robinet de la cuve chauffante pour libérer la bière. Attendre que le processus soit terminé.

Pour terminer, ajouter la levure dans de l’eau suivant les indications de la levure. Ajouter cette levure dans la bière et mélanger sans faire de bulle.

Enfin fermer la cuve de fermentation et ajouter le barboteur, dans celui-ci, mettre un peu d’eau.

ATTENTION : l’eau ne doit pas entrer en contact avec la bière.

Mettre la cuve de fermentation dans une salle à 20°C pendant 2 semainesAprès 2 semaines de fermentation, mettre la cuve dans une salle/cave à 15°C pendant 2 semaines.

Stériliser les bouteilles qui vont contenir la bière 48h avant la mise en bouteille à l’aide de chemipro dilué dans de l’eau. Le jour de la mise en bouteille, faire fondre avec de l’eau 7g/L de sucre puis l’ajouter dans la cuve de fermentation (après avoir stérilisé la cuillère).

Stériliser le robinet de la cuve de fermentation. Mettre les bouteilles stérilisées 10 minutes dans de l’eau bouillante puis mettre la bière dans les bouteilles. Stériliser les capsules et capsuler les bouteilles.

Laisser la bière minimum 2 semaines en bouteilles à température ambiante avant dégustation.

 

2.2 Deuxième Bière : consommation d’énergie

Début juin 2018 l’IUT de Mulhouse a investi dans 2 panneaux solaires. Ils peuvent produire jusqu’à 2,2 kWh.

Fonctionnement d’un panneau solaire:

Un panneau solaire est constitué de cellules dites photovoltaïque. Une cellule est constituée de 2 couches de silicium dopées respectivement P et N. Initialement, cette jonction PN est électriquement neutre. Un photon d’énergie suffisante va créer un trou par arrachement d’un l’électron. Par l’agitation des électrons voisins, ce trou va être comblé en piégeant un électron. À l’échelle de la cellule, le comportement est équivalent à une force électromotrice. Si la jonction est insérée dans un circuit fermé, un courant va circuler. Pour augmenter la puissance disponible, il faut placer plusieurs cellules pour former un panneau solaire. La tension est continue. L’énergie peut alors être stockée dans une batterie, qui joue le rôle de récepteur quand elle se charge, puis de générateur lorsqu’elle débite vers un utilisateur. Si l’utilisateur exploite une tension sinusoïdale, il faut alors intercaler un onduleur.

Lors de l’installation il faut veiller qu’aucun objet faisant de l’ombre soit à proximité du panneau. En effet contre toute attente, lorsqu’une cellule est ombragée, c’est la totalité du panneau qui cesse de produire.  Ainsi, à l’IUT, un arbre cache une partie du panneau et fait perdre 30% de la production.

Lors de la première bière nous n’avons pas pu mesurer la consommation d’énergie dont nous avons besoin lors de la fabrication. C’est lors de la fabrication d’une seconde bière, dont la recette est en annexes 2 et 3, que nous avons mesuré la consommation d’énergie nécessaire. Toute les données de production des panneaux solaire de l’IUT sont envoyées sur la plateforme.

Ainsi nous avons pu voir notre consommation d’énergie.

Lors de la fabrication de cette bière, nous avons mesuré la consommation électrique de tout le processus en utilisant les batteries (stock maximal de 4,8 kWh). Ces batteries conservent l’énergie récupérée grâce au panneau solaire installé à l’extérieur du bâtiment. Nous nous baserons sur la consommation des batteries pour ultérieurement faire une analyse de la consommation d’énergie totale d’un brassage.

Au début du processus les batteries étaient chargées à 89% de la charge maximale. On a fait chauffer de l’eau jusqu’à 80°C avant de la laisser refroidir à 67°C. Une fois à 80°C les batteries étaient à 72% de leur charge maximale. Juste avant la phase de filtration les batteries étaient à 68%. Puis on fait chauffer de l’eau de rinçage, une fois l’eau à 78°C les batteries étaient à 60%. Puis on porte l’eau à ébullition. Au début des 80 minutes de cuisson les batteries étaient à 43% puis à la fin de la cuisson elles étaient à 26%.

Remarque: Lors de cette journée les batteries ont pu se recharger légèrement.

Nous voyons sur la courbe de production des batteries ci-dessus, que de 10 h à 11 h 30 le panneau a produit une puissance jusqu’à 600 W et de 15 h 30 à 16 h la consommation était moindre (cf les encadrés noirs de la Fig 8)

Au bilan, pour faire tout le processus (sans compter la mise en bouteille) on a utilisé 89 % – 26 % = 63 % des batteries. Soit 0,63 x 4,8 kWh = 3 kWh. En toute rigueur, on a remarqué que lors de cette journée, les batteries ont pu se recharger légèrement, ce qui signifie que l’énergie réelle consommée est légèrement supérieure.

Cet essai a montré la faisabilité d’alimenter notre installation par le réseau issu des panneaux solaire.

3. Automatisation :

3.1 Liste du matériel nécessaire :

pour le malaxeur et le moulin Pour le PID de la cuve
Une perceuse 900W/230V Une carte Raspberry Pi avec son écran tactile, son alimentation et une carte SD
Des boulot M6 et M8 en inox Un clavier, souris

Une tige filetée M6 en inox d’une longueure d’un mètre

Une tige filetée M8 en inox d’une longueure d’un mètre

Une LED de roue libre 1N4002
Un fer plat en inox une sonde PT100

Pour la sécurité:

Un transformateur 12V 500mA

Un relais de puissance 12V 300mA

Un relais 5V

Une multiprise et une prise terre

Une carte Arduino Uno avec son câble et une résistance 100 Ohm

3.2 Motorisation du moulin :

Lors de la fabrication de la deuxième bière, nous avons motorisé la rotation du moulin à malt. Pour cela les techniciens de l’IUT nous ont usiné une pièce s’adaptant directement au moulinet du moulin pour ainsi utiliser une perceuse. 

La motorisation du moulin est terminée.

3.3 Motorisation du malaxeur :

Nous avons décidé de créer une pièce totalement en inox pour mélanger la bière de façon autonome.

Le choix de l’inox n’est pas anodin: c’est le seul métal inoxydable, adapté à l’alimentaire, et sans influence sur la saveur de la bière.

De ce fait nous avons réalisé un carré avec un fer plat d’un mètre où nous avons inséré des tiges filetées.

De ce fait lors de la rotation fait par la perceuse le liquide dans la cuve est mélangé de façon homogène.

 

 

3.4 Asservissement de la température :

Afin d’asservir la température, nous avons utilisé une sonde PT100, une carte Arduino Uno, une carte Raspberry Pi, un écran, un relais 5V, un relais 12V, un transformateur, une prise avec terre et la cuve chauffante Brewferm.

Le but est de commander la sonde PT100 à l’aide d’un Raspberry Pi afin que la température soit affichée sur un écran et qu’elle se régule seule suivant le programme de cuisson demandé. La sonde PT100 envoie un signal analogique et le Raspberry Pi ne reçoit que des signaux numériques, c’est pourquoi on ajoute une carte Arduino Uno qui fait office de convertisseur analogique/numérique. La carte Raspberry Pi sera donc reliée à un écran qui affichera le programme de cuisson et la température.

Elle sera aussi reliée à un relais 5V qui sera relié à un relais de puissance 12V. Les deux relais servent de protection à notre matériel. Ce relais de puissance sera relié d’un côté par la cuve chauffante Brewferm, et d’un autre côté par un transformateur qui sera branché au 230V de la prise secteur. 

Nous avons choisi la sonde PT100 grâce à ses caractéristiques :

– une précision d’un dixième de degré : largement suffisant pour notre application,

– gamme de température allant de 0 °C à 100 °C : adaptée à notre température de cuisson qui est de 90 °C,

– temps de réponse inférieure à 1 s : parfaitement cohérent avec notre projet. En effet, la montée en température de notre cuve est environ de 30 minutes pour une élévation de 20 °C. Le temps de réponse du capteur seul est donc négligeable.

3.4.1 Connectique Raspberry Pi → Cuve

 cuve relais de puissance relais 5V Raspy

Pour s’assurer de la sécurité de la cuve ainsi que de l’interface, nous utilisons des relais. 

On va utiliser une triplette avec un arrêt ON/OFF de plus de 3000W pour s’assurer qu’elle supporte les 2000W de la cuve, la perceuse du malaxeur ainsi que les relais. 

Par loi de Joule, 2kW, 230 V aboutit à un courant de 8,7 A. Ce qui nécessite un câble de section 1 mm2. Une fois le branchement réalisé nous pouvons passer à la programmation.

3.4.2 Programmation de la sonde:

Objectif : à travers une interface l’utilisateur choisira les 3 temps de cuisson et les températures associées ainsi que le temps de houblon. De cette façon l’utilisateur peut vaquer à ses occupations en recevant un email à chaque changement de cuisson, pour chaque houblon et fin de cuisson.

Nous avons donc commencé cette partie de l’automatisation par la programmation de la carte Raspberry Pi et de la carte Arduino Uno. La particularité de la sonde PT100, c’est qu’à 0 degrés Celsius celle-ci agit comme une résistance de 100 ohms. Celle-ci est reliée à la carte Arduino à l’aide d’un pont diviseur de tension avec une résistance 100 Ohm afin de faire la conversion analogique/numérique et de sortir une valeur de la température. (Fig 13) Cette valeur de température sera ensuite envoyée au Raspberry Pi. Le Raspberry Pi sera programmé pour recevoir les informations de la sonde dans un premier temps.

Pour l’arduino nous avons fait un programme nous permet de récupérer les valeurs de la sonde qui arrivent sur le port analogique de l’Arduino. Nous recevons les valeurs en millivolts que nous convertissons en degrés Celsius.

Pour ce faire, nous utilisons la fonction map qui permet de faire cette conversion. Pour calibrer la sonde, nous la mettons à 0°C et récupérons la valeur en millivolt. Nous ferons de même pour 100°C. Pour finir nous affichons le résultat en degrés sur la console. 

3.4.3 Programmation du contrôle de la cuve

Nous allons utiliser le  logiciel python pour programmer la cuve. Le principe de fonctionnement est le suivant :

  • Nous contrôlons constamment la température, si elle est trop froide on active le GPIO 12 (pin sur lequel est branché la cuve) donc on allume la cuve, sinon on le désactive pour l’éteindre.
  • Nous avons créé des paliers de température et de houblons
  • Nous utilisons des minuteurs pour savoir si le temps des paliers sont écoulés pour passer au suivant
  • Nous pilotons également 5 autres GPIO qui vont servir à envoyer des mails de suivi à l’utilisateur

Initialisation :

En début de programme toutes les variables, mettrons les GPIO sur FALSE (éteint), nous enregistrons les temps de cuisson et des houblons saisis

Chronomètre:

Nous utilisons le temps instantané sur lequel nous allons ajouter la durée saisie par l’utilisateur. 

Cependant l’utilisateur rentre dans l’interface une durée en minute uniquement, telle que 90 minutes. Ainsi, nous avons créé 2 fonctions permettant de transformer et d’ajouter la saisie des minutes de l’utilisateur, en heure et minute d’arrivée.

ex: il est 13h30, nous saisissons 70 min →  70 minutes c’est 1h et 10 minutes.–> la fonction renvoie heure prévu= 1h, Minute prévu=40

Régulation de la température:

Pour cela, nous avons créé une fonction qui va piloter le GPIO relié à la cuve pour l’activer ou non. Le principe est le suivant : si la température reçue par la sonde est inférieure à la température désirée, on allume la cuve sinon on l’éteint.

Architecture du programme:

Le programme est essentiellement constitué de “while” et de condition ”if”. Pour la première cuisson nous attendons que l’utilisateur lance le programme en appuyant sur le bouton de l’interface. Le programme est fait en deux parties : première cuisson et deuxième cuisson. A chaque fois nous devons attendre que l’utilisateur active la cuisson pour lancer l’algorithme. 

Dès lors, pour la première cuisson, nous allons créer des boucles qui vont s’exécuter tant que la cuisson avec ses paliers ne sont pas arrivées à termes.  A l’intérieur nous y plaçons la condition suivante :

Si la température relevé par la sonde est inférieure ou supérieure à 5°C de la température voulue pour le palier, nous la régulons comme nous avons vu précédemment.

Sinon nous lançons le chronomètre adéquat au palier. Et rentrons dans une boucle “tant que  l’heure instantanée est inférieure à l’heure de fin du chronomètre” , nous relevons la température de la sonde, nous ajustons en conséquence la température et nous relevons l’heure instantanée. Dès qu’on sort du “tant que” nous activons le GPIO adapté pour envoyer un mail puis nous le remettons en état OFF.

Cette condition va être répétée 3 fois soit le nombre de paliers maximum dans la première cuisson.

Lorsque les 3 paliers ont été exécutés, nous envoyons un mail de fin de première cuisson, sortons de tous les “tant que”, et coupons la cuve. 

Pour la deuxième cuisson le principe est similaire mais simplifié car la température reste constante à 90°C.

Ainsi nous allons faire une série de chronomètre avec comme consigne tant que le chronomètre précédent n’est pas écoulé on ne passe pas au suivant. Dès qu’un chronomètre est écoulé nous envoyons un mail, indiquant qu’il faut rajouter un houblon.

3.4.4 Programmation de NodeRed

L’application Node Red se fait en trois étapes distinctes, nous commençons par détecter un changement de front sur l’un des pins du Raspberry Pi (boite bleue). Ce changement de front nous indiquera à quel moment de la cuisson nous nous situons. Ensuite, suivant le pin détecté, on fait une fonction dans laquelle on affiche le message voulu (boite orange). Pour finir, ce message est envoyé par email afin de prévenir l’utilisateur du changement de température dans une cuisson ou alors pour prévenir qu’il faut mettre le houblon (boite verte).

3.4.5 Programmation de l’interface

Voici l’interface utilisée:

La programmation de l’interface se fait plutôt facilement. Il suffit de connaître les lignes de codes qui permettent de faire apparaître un bouton, une liste ou encore un texte et le tour est joué.

Voici des extraits de codes expliqués:

Nous avons choisi d’afficher l’heure  sur l’interface afin de nous éviter d’avoir une montre à côté de nous. Pour cela, nous avons créé une fonction qui permet de récupérer l’heure instantanée du Raspberry Pi. Puis on sélectionne l’endroit où l’on veut l’affiche à l’aide de la fonction “.grid”. On choisit la colonne et la ligne dans lesquelles on veut que l’heure s’affiche. 

Ensuite nous avons différentes zones de textes, ce sont les zones dans lesquelles on a déjà un texte comme “Palier 1”.  Pour cela, nous utilisons un “Label”, nous lui donnons un nom et le plaçons dans l’interface toujours à l’aide de la fonction “.grid”.

Nous avons également créé des “Spinbox” qui représentent les cases dans lesquelles nous choisissons une valeur. Nous décidons de pouvoir avoir des valeurs entre 0 et 150 “from_=0, to=150”, sauf pour la température que nous décidons d’avoir comme minimum 30 (from_=30, to=150). Les trois quarts du programme sont constitués de ces quatre lignes. 

Pour terminer, nous avons ajouté deux boutons : un qui lancera le chronomètre de la première cuisson, et un qui lancera le chronomètre de la deuxième cuisson.

On utilise donc la fonction “Button” dans laquelle nous entrons un texte, qui figurera sur le bouton, ainsi qu’une commande à lancer et sa position dans l’interface. Cette commande se trouve dans le programme qui contrôle la cuve. Ainsi, lors de l’appui sur le bouton de l’interface, le chronomètre ainsi que les fonctions de chauffe se mettent en route grâce à la liaison entre les deux programmes.

Le petit plus de notre interface est d’avoir une barre de menu dans lequel nous avons un seul menu, “Fichier”.

Dans ce menu “Fichier” nous avons créé un sous-menu “Bière blonde” et un sous-menu “Bière Ambrée”. En cliquant sur ces sous-menus, la recette de la bière s’affiche dans la console grâce à la fonction “command=”. Les fonctions “Recette_biere_blonde” et “Recette_biere_ambree” nous permettent tout simplement d’écrire dans la console le texte voulu qui est entre guillemets. Nous avons également ajouté un sous-menu “Quitter” qui permet de fermer l’interface.

4.Améliorations possibles :

 

Pour améliorer ce projet nous pouvons y apporter certaines modifications au niveau de la programmation, du malaxeur ou encore de la sonde.

4.1 La programmation:

Faute de temps, nous n’avons pas pu rassembler les programmes de l’interface et du programme principal. Pour les rassembler il y a 2 solutions. La première c’est de les rassembler tout en gardant 2 programmes différents, un pour le programme principal et un pour le programme de l’interface. La deuxième solution est de mettre les 2 programmes dans un seul et même programme qui lancera tout en même temps, cependant cette solution donnera un programme très long et assez complexe.

4.2 Le malaxeur:

Le malaxeur est prêt mais il n’est pas en place. Pour cela, il faudrait faire un trou dans le couvercle de la cuve afin d’y faire passer la tige filetée qui se logera dans le mandrin de la perceuse. Mais pour tenir la perceuse il faudrait aussi pouvoir

 

4.3 La sonde:

La sonde est programmée mais pour l’instant elle est juste posée dans la cuve. Pour la fixer, il faudrait faire un trou dans le couvercle de la cuve afin d’y faire passer la sonde, mais attention, il faudrait trouver une solution afin qu’elle ne soit pas emportée par le remous du malaxeur.

5. Conclusion

Ce projet fut très enrichissant que ce soit d‘un point de vue technique  que d’un point de vue humain. En effet à travers ce projet nous avons pu rencontrer plusieurs personnes qui nous ont soutenu et partagé leurs savoirs.

Sur le côté technique, l’automatisation de la micro brasserie fut très complet. Nous avons vu la programmation sur 3 supports différents (Raspberry Pi, Node Red, Arduino). Pour la mécanique nous avons pensé, découpé, plié, assemblé différentes pièces. Côté électronique, nous nous sommes occupées des commandes et de l’assemblage des éléments.

La partie énergie nous a sensibilisé au fonctionnement et à la lecture des graphiques fournis par le panneau solaire.

Finalement, ce projet est bien plus qu’un simple projet brassage. C’est un assemblage de savoir faire que nous avons mené à bien grâce à nos connaissances et au partage des savoir-faire. Pour le mener à terme, nous n’avons pas hésité à prendre de notre temps personnel.

Malgré les difficultés rencontrées nous avons réussi à obtenir un système qui fonctionne convenablement.

 


Babyfoot connecté


Equipe de projet 

  • BERRIAT Théodore (2ème année DUT GEII)
  • ENDLE Antoine (2ème année DUT GEII)
  • HALTER Jérôme (2ème année DUT GEII)
  • HUSSON Stuart (2ème année DUT GMP)
  • MARCHAND Louis (2ème année DUT GMP)

LE CONCEPT : PRÉSENTATION GÉNÉRALE

 

Dans le cadre de nos études en Génie Électrique et Informatique Industrielle (GEII), nous sommes ammenés cette année à réaliser un projet en collaboration avec le département Génie Mécanique et Productique (GMP).  Grâce à notre mixité de compétences, notre babyfoot connecté, à donc pour vocation de renforcer l’espace convivial de rencontre et d’échanges entre tous les étudiants de l’IUT de Mulhouse.


Qu’est-ce que le baby foot ?

Pour faire simple, le baby foot c’est une table avec des rebords, 8 barres, des poignées sur chacune de celles-ci, des joueurs et une balle. Il y a une cage de chaque côté du terrain de jeu. Chaque joueur/équipe utilise ses poignées pour faire bouger leurs joueurs afin qu’ils tapent la balle dans la cage adverse. On attaque toujours vers la droite et l’on défend à sa gauche. Il existe différentes sortes de « tables de jeu », que nous appellerons plus communément « baby-foot », qui ont chacune leur caractéristiques propres, c’est pour cela que l’écartement entre les joueurs, leur taille/proportion, le type de barre… diffère selon le modèle de baby-foot utilisé. Le baby foot est joué dans pratiquement le monde entier.
Le jeu est très rapide, amusant et convient à absolument tout le monde, personne n’est exclu. Vous pouvez jouer des années sans jamais être lassé.


Présentation du projet

Nous avons choisi de rénover un baby foot inemployé car son état était défectueux, pour en créer un baby foot connecté performant et confortable à jouer. Notre démarche favorise la convivialité au seins de notre amical à l’IUT de Mulhouse. Aujourd’hui, l’innovation est au cœurs du monde, c’est aussi pourquoi nous sommes particulièrement motivé sur le fait d’innover un objet « banal » et de le transformer en un objet technologique, cela représente en vrai défi technique. Notre baby foot connecté sera principalement équipé d’un Raspberry PI 3, d’un écran, de capteurs et de leds. Il pourra compter les buts inscrits afin de les afficher sur un écran ainsi qu’allumer les leds de la couleur adéquate lors d’un but selon l’équipe l’ayant marqué, et tout cela de façon autonome ! En parallèle, nos collaborateurs du département Génie Mécanique et Productique s’occuperont de la rénovation et de l’esthétique de celui-ci.


Cahier des charges 

Diagramme bête à cornes

Diagramme Pieuvre

 

Nom de la fonction Désignation de la fonction de service
FP1 Permettre à l’utilisateur de simuler une partie de football sur table et de se divertir
FC1 Permettre une interaction à l’utilisateur
FC2 Permettre la détection de buts
FC3 Permettre d’afficher le score et être réglable par l’utilisateur

Diagramme bloc

 

Diagramme d’exigence

 

Budget

Partie Capteurs

Passons à présent à la détection des buts !

Montage électrique :

Nous avons récupéré des capteurs de proximité dans nos entreprises, ce qui nous permettra d’avoir une plus grande durée de vie, ainsi qu’une robustesse accrue. En revanche, ces capteurs n’étaient pas adaptés pour une utilisation sur un microcontrôleur. En effet, ils délivrent un signal comprit entre 12V et 24V, alors que notre Raspberry PI3+ accepte maximum 5V sur le Port GPIO.

Pour se faire, nous avons du faire un Pont diviseur de tension, pour abaisser la tension de 12V à 5V (les 12V proviennent de l’alimentation qu’on leur fournit). Nous avons utilisé une résistance de 220 Ohm ainsi qu’une Diode Zener  5.1 V, on câblera comme ceci :

Voici en image un test que nous avons effectué avec les composants cités si dessus, ainsi qu’une LED pour vérifier la présence de tension de 5V à la sortie du montage  :

(Le capteur est au niveau logique « 1 », c’est à dire qu’il délivre une tension de 12V que l’on abaisse à 5V)

La LED n’est pas grillée, on peut donc se brancher sur le port GPIO de notre Raspberry !

Voici à quoi ressemble notre « adaptateur » une fois soudé. Nous l’avons placé dans une boite pour éviter des contacts avec d’autres fils, faciliter le raccordement, et le protéger du milieu ambiant.

Notre capteur sera alors relié à notre pont diviseur de tension, et la sortie de celui-ci sera reliée sur les PIN numéro 7 et 37 du microcontrôleur. Passons à présent au software, qui nous permettra de compter les buts marqués par chaque équipe.

Programmation :

Nous avons commencé à programmer en langage python sur l’invité de commande du Raspberry, mais nous avons vite remarqué que la gestion de plusieurs événements ainsi que la surveillance simultanée de l’état des capteurs allait être compliqué.
Voici un exemple de code pour détecter le passage au niveau logique « 1 » d’un capteur :

 

 

Nous avons opté pour une autre solution de programmation, beaucoup plus simple et facile à mettre en oeuvre : Node-Red.
On passe donc du code ci dessus à ceci, pour les mêmes fonctionnalités :

 

Présentation de Node Red : 


Node-RED
 est un langage de programmation graphique par assemblage de blocs fonctionnels qui permet de développer des objets connectés (et beaucoup d’autres choses). Node-Red est un projet Open Source (et gratuit) soutenu par IBM. On programme avec Node-RED en liant des fonctions présentées sous la forme de briques, cela réduit fortement le codage. Le flux de données passe d’un traitement à l’autre (d’une fonction à l’autre). Certaines fonctions proposent des paramètres qu’il suffit de définir à l’aide d’une liste de choix ou d’un champ à remplir (par exemple un clé d’API pour un service météo). Il existe plusieurs centaines de bibliothèques dans tous les domaines : enregistrer les données sur une base de données (MySQL, MongoDB…), piloter les E/S d’un Arduino ou d’un Raspberry, ajouter une interface graphique (UI) pour tracer des graphiques, afficher des jauges, commander un relai à l’aide d’un bouton…

 

 

 

 

 

 

Démarrer Node-Red

Pour démarrer Node-Red sur Raspberry dans Menu -> Programmation

On peut également démarrer depuis le Terminal avec la commande

Une fois lancé, nous avons préféré programmer sur ordinateur.
Pour cela,  il suffit de récupérer l’adresse IP de notre Raspberry sur l’invité de commande puis de saisir sur le navigateur internet :

On arrive ensuite sur l’écran de Node-Red

 

Sur la gauche de l’écran se trouvent toutes les fonctions disponibles. Au centre se trouve la zone de programmation. Le panneau de droite regroupe un onglet info regroupant des informations contextuelles (exemple correspondant à la fonction sélectionnée…) et un onglet debug qui renvoie les messages d’erreurs ainsi que les messages de la fonction debug qui se trouve dans les outils output.

A partir de là, nous avons installé les nœuds nécessaires afin de pouvoir répondre à notre cahier des charges initial.

Ce progiciel va donc nous permettre de gérer la détection des buts, la gestion des rubans de LEDS, mais aussi l’affichage du score sur notre afficheur, par exemple.

Voici à quoi ressemble l’ensemble des blocs afin de gérer l’information des capteurs, ainsi que les compteurs des buts marqués par chaque équipe. On va détailler le rôle de chacun si dessous :

On retrouve en première position à gauche l’entrée du port GPIO du Raspberry :

Le bloc suivant intitulé « Rising Edge » va nous permettre de détecter uniquement le front montant du signal du capteur : autrement dit, on ne va pas tester le niveau logique du capteur (0 ou 1) mais le passage de l’état 0 du capteur, à l’état 1. Ceci va nous permettre de n’incrémenter notre compteur de but qu’une seule fois, car il est initialement programmé pour s’incrémenté à chaque changement d’état à son entrée. Sans ce bloc, lors d’une détection de but, notre compteur s’incrémentait de +2 (+1 lors du passage du capteur de 0 à 1, puis une nouvelle fois de +1 en repassant de 1 à 0). Afin d’obtenir ces deux blocs, nous avons du les installer au préalable, comme ci dessous :

Voici le bloc « compteur » qui se situe après le bloc front montant , avec comme paramètres :

  • Name : le nom du compteur
  • Initial Count : Valeur initiale du compteur = 0
  • Default Step : incrément la valeur, par pas de 1
  • Lower Limit : valeur limite basse = 0
  • Upper Limit : valeur limite haute = 10
  • Mode : increment, car on augmente la valeur de 1 but à chaque événement
  • Outputs : une seule sortie à la sortie de ce bloc

En dernière position nous avons un bloc appelé « set msg.count », qui sera utilisé pour transmettre la valeur actuelle des compteurs vers l’affichage sur le dashboard. Nous détailleront cette partie dans la rubrique « Interface »

 

Partie Interface Graphique Node Red

Nous avons tout d’abord commencé par installer le nœud dashboard. Celui ci nous a permit de gérer l’interface graphique à l’aide de différentes commandes. Chacune d’elle est spécifique, vous trouvez le contenu un peu plus bas.

 

 

 

 

 

 

 

 

 

 

 

 

 

1) Conception de la page d’accueil :

  

La page d’accueil est constitué de deux blocs. Le premier bloc « logo » et le second « Réalisation ». Ce sont tous les deux des « templates », c’est à dire que nous allons pouvoir insérer des images, écrire, décider de l’alignement du texte… grâce à la programmation en html.

2) Menu Règles :

On affiche la page des règles avec un scroll :

3) Menu de match : Score 

  • Nœud But Equipe Rouge => Affiche le texte sur l’interface graphique
  • Nœud Score =>  Récupère la valeur du compteur
  • Nœud Compte Equipe Bleu => Permet de disposer la valeur du compteur au centre
  • Nœud Remise à zéro => Lors d’un appui, il envoie l’info au RAZ et ainsi le RAZ injecte 0 dans le nœud de comptage

Avec le bouton de remise à zéro :

Partie Leds 

 

Les leds dans le projet baby-foot connecté auront comme but de clignoter de la couleur respective à celle de l’équipe afin d’avertir l’utilisateur de la présence d’un nouveau but.

 

Pour répondre à ce besoin nous nous sommes tourné vers l’utilisation d’un ruban de led pour la gestion de la taille des zones à éclairer sur le baby-foot.

Les résistances auront pour but de résister au passage du courant dans les transistors.

 

Le fonctionnement d’un transitor :

 

Le transistor dispose de 3 bornes, le collecteur, l’émetteur et la base. Le collecteur et l’émetteur sont techniquement symétriques. Dans notre cas le collecteur sera la couleur du ruban de leds et l’émetteur le 0V, car nous souhaitons émettre aux leds le 0V afin de les faire briller. La base, notre signal de sortie du Raspberry permet de laisser passer ou non la conductivité du collecteur vers l’émetteur en laissant passer les électrons se trouvant dans le transistor grâce à l’envoie d’une faible tension, ici 3,3V.

 

Schéma d’un Transistor NPN avec 0V à la base

Schéma d’un Transistor NPN avec 3,3V à la base

 

Montage électrique :

 

Mesure courant des leds :

  • Bleu : 0.7A
  • Rouge : 0.8A
  • Vert : 0.7A

 

Matériels utilisés :

  • 1 Ruban de leds BRG de 12V
  • 1 Alimentation 12V/2A
  • 3 Transistors 2N4922 NPN 2A
  • 3 Résistances 270 Ohms

 

Pour s’assurer du bon fonctionnement du montage nous avons simuler le signal délivré par le Raspberry à l’aide d’un générateur de tension réglé sur une tension de 3,3V.

 

 

Nous avons élaboré un boitier comprenant le montage précédent.

Voici des photos du résultat final de la boite.

 

Le programme :

 

Voici une vue d’ensemble du programme sur Node-Red permettant le clignotement des leds.

Le programme est composé d’une succession de 4 temporisations de type trigger lancées lors du passage à 1 du capteur détectant un but. Ces temporisations sont reliées aux sorties des leds de la couleur  du but qui fera ainsi clignoter les leds.

 

Le fonctionnement des différentes temporisations en série nous permet de créer différentes impulsions chacune de la valeur de la plus petite temporisation crée. Ce qui entraîne un clignotement des leds pendant une durée de 1s toutes les 125ms dans notre cas.

 

Trigger :

Module de sortie :

 

 

 

Schéma Electrique du Baby-Foot Connecté :

Schéma électrique Baby-Foot Connecté

 

Câblage du Baby-Foot : 

 

Finalisation de la partie Génie Electrique et Informatique Industrielle en vidéo : 

 

Partie GMP

Dans un premier temps, nous avons procédé au démontage et à la rénovation du baby-foot. L’état initial de la structure était exécrable (trous, visseries abimés, bois enfoncé, saletés…) Cette remise en état fut chronophage et couteuse en matériaux (colles, mastic, pâte à réparer, visseries neuves) et en nouveaux outils (forets, mèche à bois). En disposant uniquement d’une soixantaine d’heures de projets, la partie purement mécanique et industrielle du projet fut un réel contre la montre. Malheureusement, malgré de nombreuse heure supplémentaire, le projet n’a pas pu totalement aboutir, notamment à cause de nombreux problèmes au cours du démontage et de la rénovation, bien que les opérations d’usinage et de conception ce sont quant à elles généralement bien déroulés.

Nous allons maintenant vous présenter notre cahier des charges mis en place début décembre, avec les fonctions mises en place et les tâches restants à effectuer :

Cahier des charges (GMP)

FONCTIONS

CRITÈRES

NIVEAUX

FP1 : Assurer une bonne jouabilité du babyfoot

 

Guidage barres de jeu et confort

 

 

Système de palier lisse

Arrêt axial des barres

 

FC1 : Stabiliser le babyfoot

 

Stabiliser

Renforcer les pieds Double pied
Lier les pieds Tige filetée + écrous

 

FC2 : Assurer l’acheminement des balles vers les capteurs

 

Acheminer

 

 

Guider la balle

 

Lattes + tube PVC

 

FC3 : Loger les composants électroniques

 

Logement

Écran Boitier en bois
Capteurs Sur tube PVC

 

FC4 : Doit être esthétique

 

Esthétisme
Design, formes Formes discrètes
Couleurs Toutes

 

FP1 : Assurer une bonne jouabilité du babyfoot

 

Réalisation de paliers lisses afin d’assurer le bon guidage des barres. Après concertation avec les professeurs, l’idée retenue était de réaliser les paliers lisse en laiton pour éviter le contact entre acier et aluminium (peu favorable au glissement). Après consultation avec l’atelier, le délai d’approvisionnement du tube de laiton correspondant à notre besoin était trop important. C’est pourquoi nous avons décidé de réaliser les paliers en aluminium avec bague plastique et utiliser des barres en acier.

 

Présentation du système :

 

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1527&part=4

 

 

 

Modélisation des pièces sous Creo

 

 

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=3https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=2

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1527&part=3

 

 

 

Réalisation de la FAO (Fabrication assistée par ordinateur)

 

 

 

 

Usinage de la pièce avec une commande numérique

 

 

Résultat obtenu :

 

Préparation du flan pour accueillir les 2 pièces

 

 

Perçage de 3 trous diamètre 3.2 pour faire passer les vis d’assemblage M3 du système de guidage.

 

 

Assemble du système de guidage

 

 

Renouvellement des barres : Démontage des barres actuelles, débitage de ronds d’acier Ø15, perçage et mise en place des nouveaux bonhommes. Montage des anneaux de serrage pour bloquer la barre axialement en translation.

 

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1528&part=2

 

 

Nouvelles surfaces de jeux : nouveau tapis et plinthes en bois. Prise de côtes, mise en plan papier puis transmission à GRAUER Construction, spécialiste dans la création de maisons à ossature bois.

Restructuration du fonds de but : « Gamelles » intempestives dus à la forme peu ingénieuse du fond de but : découpe d’une plaque PVC vissées avec un coussinet sur la paroi pour créer un effet d’amortissement.

Rehausse du plateau de jeu : Pour assurer un meilleur confort de jeu avec les nouveaux joueurs plus petits que les anciens modèles, nous avons rehausser le plateau de jeu à l’aide de calles plastiques normalisées fournies par GRAUER Construction.

 

A faire :

  • Découpe & pose du tapis de jeux
  • Ajout de palier cylindrique plastique (type IGUS) pour minimiser le frottement acier-aluminium des barres avec le palier : Bien que la translation des barres dans les paliers soit optimale avec un système correctement lubrifié, cette solution améliorerait d’avantage le confort de jeu.
  • Opération de percage-alesage et montage serré des paliers cylindriques sur 16 pièces déjà réalisées

 

FC1 : Stabiliser le babyfoot

Stabilisation : Ajout de 4 pieds supplémentaires, conception CAO, mise en plan DXF et sous-traité par HUSSON International (Les pièces en bois trop massive ne pouvant pas être usinées à l’atelier)

Nouveau système de solidarisation du bâti : Fixation des pieds deux à deux via une tige filetée. Le maintien de la distance entre les deux mêmes pieds est assuré par une entretoise. L’écart entre les pieds droits et les pieds gauches sont maintenus grâce à un système de contre-écrou.

A faire :

  • Nous avons pu observer une nette amélioration de la stabilité, mais un phénomène de bascule reste présent et problématique pour le confort de jeu et l’endommagement prématuré des composants. Une recherche d’une nouvelle solution ou amélioration du concept est envisageable.

 

FC2 : Acheminer la balle vers les capteurs

 

Goulotte d’alimentation : Assemblage d’une structure bois/PVC permettant de guider la balle de la sortie de but à l’accès de repêche.

 

A faire :

Perfectionnement de la structure, dans de rares positions la balle reste coincée.

FC3 : Logements des composants électroniques

Création d’un logement d’écran : Réalisation d’un logement d’écran en bois permettant le passage des câbles jusqu’au Raspberry

 

Logement des capteurs dans la goulotte PVC : Réalisation d’une rainure dans la goulotte permettant l’insertion des capteurs en position verticale pour une détection de la balle vers le bas.

 

 

FC4 : Doit être esthétique

Visserie non apparente : Réalisation de cache écrou en impression 3D pour cacher la visserie apparente.

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=5

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=4

Habillage : découpe de profil aluminium pour réaliser le haut de but

Ponçage : peinture à réaliser

 

Conclusion : Ce projet fut motivant de par notre intérêt pour le baby-foot mais également dans l’application de nos compétences de génie mécanique. Cependant, il fut trop ambitieux de prévoir la remise à neuf intégrale du baby-foot en 60 heures. Il y aurait Intérêt de reconduire le projet l’année prochaine pour les futurs étudiants de deuxième année : une base fonctionnelle est en place, mais il reste beaucoup de piste d’améliorations pour obtenir un produit optimal. De plus, lors de la création de chaque pièce, par soucis de ne pas abîmer la structure existante et de pouvoir modifier en cas d’échec, chaque pièce a été conçu de manière à pouvoir être démontées facilement, ce qui facilitera la prise en main par d’autres étudiants.

 

État actuel :

 

 


Lanceur de volants de badminton


LANCEUR DE VOLANT POUR BADMINTON

 

 » On ne devient pas champion dans un gymnase. On devient champion grâce à ce qu’on ressent; un désir, un rêve, une vision. On doit avoir du talent et de la technique. Mais le talent doit être plus fort que la technique. « 

Mohammed Ali

 

 



REMERCIEMENTS

 

Nous tenons a remercier nos professeurs tuteurs sans qui ce projet n’aurait certainement pas aboutis. Nous remercions également Mr De Sabbata qui a été présent à chaque étapes du projets ainsi que nos camarades qui ont fait preuve d’une bienveillance exceptionnelle lors de la conception et des tests.

 

 



 

 

Cet article fait office de rapport dans le cadre du cours Etudes et réalisation. Il s’agit de l’étape final de notre projet qu’est, vous l’aurez compris, le lanceur de volant. Ce projet à été choisie par nous même et réalisé sous la tutelle de nos professeurs référents que sont Mr Bazeille et Mr Verrier. Dans la suite de ce développement, nous allons essayer de vous expliquer et illustrer les étapes intrinsèques à notre réalisation, puis nous allons conclure sur une petite démonstration.

 

Objectif: Réaliser un lanceur de volant pour badminton

 

Membres de l’équipe:  Alexandre DARTOIS,  Adin BADIENZI et Marvin DARBOUX

 

Sommaire

 

I) Contextualisation

1) Présentation du projet

2) Gantt

II) Conception

1) Construction mécanique

2) Conception électrique

III) Programmation

IV) Conclusion

 

 

 



 

I) Contextualisation 

 

Tout d’abord comme son nom l’indique notre projet sera un robot qui va lancer des volants à différentes positions du terrain. Il devra idéalement pouvoir faire des routines permettant l’entrainement du joueur. Notre projet n’a pas vraiment de cahier des charge unique car il évolue au fur est à mesure des besoins liées aux contraintes de jeux.

 1) Présentation du projet

Avant de se lancer dans la conception d’un objet tels que celui ci , quelques prérequis sont importants. Par exemple la vitesse d’un lancer de volant qui peut atteindre les 450 km/h ou encore la taille du terrain  étant de 13,40 m sur 5,20 m pour la réalisation des routines. De ce fait il nous est très vite venu l’idée de se servir de deux disques tournant en sens inverse de façons a pouvoir propulser un volant vers un endroit prédéfinis. On s’est aussi inspiré des modèles existants tels que :

–  Le BLK

 

– Le Aliobot Supra

On peut voir que ces 2 lanceur sont vraiment riches en choix d’exercices et de fonctionnement car il peuvent faire énormément de routines ainsi que des routine spéciales crées par le joueur lui même en réglant la vitesse des volant. Mais le plus intéressant est que le BLK peut se connecter via le Bluetooth à un portable et a son application propre pour faire différente routines.

 

De ce fait, l’idée du support viens très rapidement afin de stabiliser le tout et permettre éventuellement de réaliser manuellement les routines. Pour que ce système soit un peu plus optimale voila les premiers objectifs que nous nous sommes fixés :

Le capteur devait servir à l’incrémentation des volants. Il permettait au lanceur de savoir si le volant est effectivement parti ou non. Si oui il devra permettre au lanceur de repositionner un autre volant de façon autonome et aussi de connaitre le nombre de volant que compose sa série. Pour ce faire il fallait bien évidement un support pour les volants et un système permettant de bloquer les volants le temps que le capteur perçoive un volant.

Afin de réaliser ce tour de force on a eu comme matériel droit à :

– Un RasPi 3 Model B

– Des kits de construction mechano ( gentillement fournis par l’iut lab)

– La possibilité de commander des composants sous peine d’accord de nos tuteurs

 


 

2) GANTT

Avant de pouvoir passer à la partie physique de notre projet on a du commencer par une approche plutôt papier sur l’étude de notre système: la répartition des tache, comment aboutir au résultat escompté, etc . Donc pour ce faire on a commencé par faire différentes analyses avec différents logiciel permettant la facilité pour l’avancement de notre projet et des taches a réaliser.

 

  • Première analyse fonctionnelle dit « la Bête a corne » :

Cette première analyse nous a permis d’exprimer le besoin primaire, donc son exigence principal sous forme très simplifiée.

  • Seconde analyse :

Maintenant qu’on a exprimé la fonction principal de notre lanceur on peut passer à une autre analyse qui est le « le MindMap », cette analyse est le fait de représenter les grande idée et partie qui vont constituer un même sujet qui pour nous est notre lanceur de volant:

 

  • Dernière analyse :

Maintenant grâce a notre MindMap on peut faire notre Gantt qui est le fait de planifier toutes les idées trouvé lors de l’analyse précédente en fonction de la durée de notre projet ainsi que d’autres contraintes.

Grace a notre planification on peut voir les durée « prévisionnelle » et surtout la date de début et de fin du projet et de chaque sous partie.Notre projet commença le 30 novembre 2017 et la dernière consacré a celui-ci était le 22 janvier 2018.

 



II) Conception

 

Maintenant que toute l’étude est faite on peut passer au gros du projet qu’est la partie conception d’une structure adéquate pour notre lanceur.

 

1) Conception mécanique 

Avant de pouvoir tester des programmes on doit tout d’abord ce pencher sur une structure permettant de lancer des volants.

Schémas illustrant le mode de fonctionnement

 

D’où Notre choix qui c’est très vite porté sur les méchanos pour la réalisation de la structure à cause de la diversité des composants et outils que présente ces boites(Makeblock). On a commencé dans l’optique que ce que nous réaliserons avec les méchanos sera un prototype pour ensuite créer notre « vrai » réalisation. Dans un premiers temps nous nous sommes concentrés sur la structure:

  • Première réalisation et problèmes associés

Réalisation intermédiaire (I)

On peut voir sur cette image que notre réalisation n’est pas adéquate pour lancer des volants de part ça rigidité qui n’est pas bonne car certaines pièces sont déformé sous le poids de nos moteur et des tremblements du a la rotation des moteur. L’impacte de la mise en route des moteurs provoque un bruit assourdissant à cause de l’écart et des frottements entre les roues dentés.

  • Après ces premiers résultats quelques peut chaotiques, voici ce que nous avions imaginé ensuite

Résultat intermédiaire (II)

On peut voir sur cette image que le second test juste l’aspect externe montre un peu plus de rigidité mais il y a d’autre aspect technique qui on était résolu comme par exemple le niveau des roue qui était du a la mauvaise rigidité de la structure ainsi que l’espace pour le volant ou encore les vibration des moteur qui on était réduite, etc. Donc au vue des aspects résolu on remarque qu’une grande partie était du a la rigidité de la structure. Cependant les 2 plus gros problème sont toujours a résoudre : Les tremblement ainsi que le bruit assourdissant.

Le modèle illustré ci-dessus fait office de premier prototype pour notre lanceur de volant. Bien que plutôt satisfaisant pour effectuer des lancers, on a préférer le solidifier pour le prototype finale, prototype que nous illustrerons dans la partie conception électrique car cette structure comporte des composant qui seront expliqué dans cette partie.


Maintenant que nous disposons d’une structure convenable au lancé on va pouvoir y incorporé des composant qui vont permettre le confort des utilisateurs ainsi que le bon fonctionnement de notre lanceur.

2) Conception électrique

Pour commencer voici un petit schéma qui regroupe les grandes parties qui compose notre lanceur et qui seront implantés dans la structure vu dans la partie conception mécanique :

 

Principe de fonctionnement

 

Nous avons essayé par le biais du schémas ci-dessus de vous illustrer les différents  composants électriques qui ont intervenus lors de la conception du lanceur.Voici une liste non exhaustive des composants que nous avions choisi:

  • dans le cas des moteurs on a opté  pour le 42BYG Stepper
  • dans le cas du capteur Ultrason on a opté pour le Me Ultrasonic sensor
  • pour l’affichage du choix des routines on a choisi le Me TFT LCD screen
  • pour gérer l’ensemble des composants on a choisi le Me Orion
  • pour choisir son mode de jeux on a préférer le Me 4Button

Pourquoi le 42BYG stepper ?

En résumé il s’agissait tout simplement du moteur pas à pas le plus puissant disponible dans les boites Makeblock. Avec sa puissance, on pouvait se rapprocher (avec un système similaire à celui des engrenages) d’un lancer ordinaire de volant par un individus quelconque.  De plus par le biais du contrôleur qui lui est systématiquement associer on pouvait gérer le voltage et l’ampérage, donc agir sur la façons dont allait tourner le moteur ( les roues) .

2H ME Make (contrôleur pas à pas)

Le Me 2H Microstep Driver est une pilote de moteur pas à pas hybride à 2 phases, et adopte l’alimentation de DC 12 ~ 36V. Il est adapté pour piloter le moteur pas à pas hybride à 2 phases avec une tension de 24 ~ 36V et un courant inférieur à 2,0A. Ce pilote utilise la boucle de courant numérique complète pour mettre en œuvre le contrôle de micropas, de sorte que le moteur présente une faible ondulation du couple, une faible vitesse et un fonctionnement fluide, des vibrations et du bruit faibles. Lorsqu’il tourne à grande vitesse, son couple de sortie est relativement élevé et sa précision de positionnement est élevée.

 

Le Me Orion , qu’est ce que c’est ?

Me Orion

Le Makeblock Orion est une sorte de carte mère basée sur Arduino Uno . Il se munit de huit ports RJ25 pour se connecter à tous les autres modules de la série Me (kit Inventor ou séparé sur demande) avec des étiquettes couleur. Il supporte  la plupart des logiciels de programmation (Arduino / Scratch / AduBlock).

 

Maintenant que vous connaissez la plupart des composant qui seront implanté dans notre lanceur voici le résultat final après que chaque composants soit inséré :

On peut voir sûr cette image la structure final avec les solution technique au problème expliqué dans la partie conception mécanique et donc les solution sont pour le bruit on a utilisé une courroie entre l’axe du moteur et celui des roue qui permet d’évité le frottement entre les 2 axes et pour les tremblement on a opté pour des pied qui vont permettre au moteur de ne pas être directement en contacte avec le sol et ainsi limité au maximum les vibrations. On peut voir aussi les composant électrique utilisé comme :  – la carte Me Orion (en haut au milieu)

– les 2 moteur (en bas) et leur driver (en haut)

– l’écran LCD (en haut)

– le capteur (au milieu de l’image)

– la télécommande (a gauche au milieu)

Maintenant que nous avons un prototype opérationnel on peut passez a la partie programmation.

 



III) PROGRAMMATION

 

Avant de ce lancé dans du code pur et dur voici un schéma explicatif de comment notre lanceur fonctionnera et donc de comment le programme sera fait.

Principe de fonctionnement informatique

 

1) Rasberry Pi 3

Qu’est ce que c’est ?

Le Raspberry Pi est un ordinateur à processeur ARM conçu par David Braben, dans le cadre de sa fondation Raspberry Pi2. Cet ordinateur  permet l’exécution de plusieurs variantes du système d’exploitation libre GNU/Linux et des nombreux logiciels compatibles. Il existent actuellement plusieurs versions du Raspberry-Pi. Il est malgré sa taille réduite suffisamment ouvert (ports USB, réseau) et puissant (ARM 700 MHz, 256 Mo de mémoire vive pour le modèle d’origine, 512 Mio sur les dernières versions) pour permettre une grande palette d’utilisations.

Le Raspberry Pi 3 est quant à lui équipé d’un processeur ARM Cortex-A53 quad-core 64 bits (Bradcom BCM2837) fonctionnant à 1.2GHz, de 4 ports USB 2.0, 1Go de mémoire, 1 sortie vidéo HDMI 1.3a, 1 port Ethernet 10/100, 1 prise jack audio/vidéo. La version 3 ajoute le support du Bluetooth 4 BLE (BCM43438) et plus du WiFi 802.11 b/g/n (BCM43438). Enfin, il possède un connecteur CSI permettant de brancher une caméra compatible.

 

Raspi 3

Un problème c’est alors très vite posé. Celui de se servir d’un rasberry Pi pour piloter une cate arduino. Afin de palier à ce problème une solution existe : le Megapi

Megapi Makerblock

Mais on très vite abandonné cette piste faute de matériel. Il fallait se  munir d’un Megapi et coté timing on étais assez limités. On a donc écarté le fait d’inclure le Rasberry Pi dans notre projet.

Nous avons décidé d’utiliser arduino afin de programmer.

2) Arduino (logiciel)

Mais arduino qu’est ce que c’est ?

Le logiciel Arduino (IDE) open source fonctionne sous Windows, Mac OS X et Linux. L’environnement est écrit en Java et basé sur processing avec d’autres logiciels open-source. Il fonctionne également comme compilateur C. Le C est adopté dans le monde entier pour les microprocesseurs. Il offre un bon compromis entre l’effort de développement et l’efficacité du programme.

 

 

Maintenant que le domaine informatique est devenu limpide on va pouvoir passez au code que je vais séparé en plusieurs partie distincte pour que votre compréhension soit plus facile :



Pour commencé on a inséré les librairie qui sont propre a notre carte MeOrion et pour notre moteur pas a pas AccelStepper, ensuite on définie une longueur max pour notre écran LCD et après on a créer des variable qu’on a mit a 0  de base ou d’autre qu’on a juste créer ensuite on a définie chaque composant utilisé :  – MeSerial (écran LCD) connecté au port 5.

– Me4Button(télécommande) connecté au port 8 et on définie ce qui ce passe quand on appuie sur le bouton.

– AccelStepper(Moteur pas à pas) on définie les 2 sens de marche et sur quel variable interne au MeOrion il sont connecté, le FULL2WIRE signifie qu’il n’y a que 2 fil pour un sens.

– MeUltrasonicSensor (capteur Ultrason) connecté au port 6 du MeOrion.

 

 

Maintenant qu’on a définie les librairies, les variables et les composant on peut passez a l’initialisation.



Pour l’initialisation on a juste définie une série d’action que notre lanceur va exécuté. Le mySerial.begin permet de définir la vitesse des bits donc des bauds et les mySerial.print(ln) permette d’écrire sur l’écran LCD. Donc cette série d’action va écrire UHA dans un rectangle ensuite on attend 3 seconde puis efface tous et on écris 3 phrase « Salut … » « Je suis B0-1 … » « Jouons ensemble ! » ensuite on efface tous et on écris « Owww tu vas kiffer » et aprés on efface tous.

 

 

Maintenant que notre initialisation est faite on va passez a la création de la fonction menu.



Pour la fonction menu ces une fonction qui est créé et qui pourra être appelez dans le programme, donc on peut voir que cette fonction est très simple elle permet juste d’écrire les 3 jeux qu’il y a et sur quel bouton il faut appuyé et sur quel bouton appuyé pour retourné au menu.

 

 

Maintenant on peut passez a la boucle infinie.



On peut voir dans cette boucle qu’au début définie ce que signifie appuyé sur le bouton et ensuite comme la variable start a été mise a 0 au début alors on appelle la fonction menu vu précédemment ensuite on passe start à 1 pour pouvoir commencé le programme.

 

 

Maintenant avant de passez a la création des jeux on va commencé par le capteur.



On peut voir que pour le capteur on commence par créer un compteur ensuite il faut que le moteur tourne toujours donc il faut constamment mettre des stepper(1/2).run() ensuite on demande pour que l’écran LCD écrive Nb_de volant suivi de la valeur du compteur. Puis pour un aspect visuelle on dit que pour chaque jeux on veut qu’il écrive le nom de ce jeux.

 

 

Maintenant pour un aspect visuelle on a définie des conditions.



On peut voir que ces condition sont active que quand soit tout les bits poubelle sont à 0 ou a 1 pour explication les bits poubelle sont définie pour l’activation(=1) ou la désactivation(=0) du mode de jeux pour résumé il permette soit que les moteur accélère pour pouvoir commencé le jeux soit qu’il décélère pour pouvoir arrêté le jeux, chaque jeux possède sont bit poubelle. Donc quand un des bits et a 0 alors on écrit que les moteurs vont s’arrêté et donc atteindre 0 tr/min et inversement quand un des bits et a 1 alors le moteur va atteindre 1200 tr/min.

 

 

Maintenant pour notre plus grand plaisir on a créé un événement.



On peut voir pour cette événement qu’il s’active quand le capteur a compté 10 volant et il va écrire sur l’écran « PFF petit joueur ».

 

 

Maintenant on peut passez a la création des jeux.



On peut voir pour la création du jeux 1 qu’on regarde quel bouton a été pressé si ces le bouton 1 alors on est dans le mode_jeux=1 et on incrémente la variable poubelle adéquate ensuite si celle-ci est égal a 1 alors on écrit le nom du jeux et la vitesse des moteurs. Ensuite on définie que la position actuelle des moteur est 0 et on lui donne une vitesse max une accélération et une position a atteindre (comme la position est très grande le moteur ne s’arrêtera pas tout de suite) et on fait cela pour les 2 moteurs.

 

 

Maintenant que la partie accélération et faite il faut passez a la partie décélération.



On peut voir comme je l’ai dit précédemment quand poubelle égal 2 (égal 0 car boucle infinie donc il voit poubelle égal à 0) alors le moteur est en phase de décélération, donc quand on appui de nouveau sur le même jeux la variable s’incrémente et donc on passe en phase de décélération (poubelle=2) dans cette phase on écrit la vitesse du moteur et le nom du jeux ensuite on prend la position du moteur actuelle et on lui dit qu’il a 5 fois cette distance pour s’arrêté.

Voici pour un mode de jeux mais le scénario ce répète a part que les moteur utilisé ne seront pas les même.

 



IV CONCLUSION

 

Quoi de mieux qu’une petite vidéo démonstrative pour conclure ?

 

 

Perspectives d’évolutions:

  • gestion plus effective du temps et des priorités
  • réalisation du vrai lanceur à l’instar d’un prototype
  • réalisation d’un socle pour les volants et choix de moteurs plus puissants

Webographie:


Microscope à bille

 

 

 

 

 

 

Microscope à bille

 

 

 

 

Sommaire :

 

 

Introduction

Cahier des Charges

Ressources

Réalisation du Projet

Perspectives D’améliorations

Conclusion

Remerciements

 

 

 

 

Introduction

 

Lors de cette deuxième année en DUT GEII, je suis amené à réaliser un projet, celui-ci doit être en lien direct avec ma formation ( génie électrique et informatique industrielle ), pour mon cas, il s’agit du projet intitulé « Microscope à bille », ce projet rentre dans le cadre du module « études et réalisations » dont la notation dépend des efforts fournies (avancement du projet), ainsi que le rapport et la vidéo .

Pour mon projet, il m’est demandé d’utiliser une Raspberry Pi 3 mais également de faire une « Conception Assistée par Ordinateur » (CAO) du microscope. Afin de réaliser mon projet, qui consiste à acquérir des images et faire du traitement de donnée, j’utilise « Python » un langage de programmation intégré dans le Raspberry Pi 3.

 

 

Cahier des Charges

 

 

A quoi sert le projet et à qui il sert ?

  

Les différents fonctions et contraintes du projet :

 

 

 

 

Fonctions principales : Le projet doit posséder les bases d’une microscope traditionnelles, en terme d’acquisition d’image, zoom,  réglage de luminosité et travaille d’un échantillon.

 

Contrainte Informatique : J’utilise une Raspberry Pi afin de crée le microscope.  Au delà de ça, il faut une interface visuelle afin de rendre le projet plus intuitif. La prise en main et la maîtrise des différents langages sont nécessaires pour réaliser le projet.

 

Contrainte Conceptuelle : J’utilise Corel Draw afin de réaliser la conception assistée par ordinateur de ma microscope en obtenant en produit final, un appareil peu coûteux et simple d’accès.La prise en main et la maîtrise des notions d’optiques sont nécessaires pour réaliser le projet.

 

Contrainte de ressources : Le budget est limité à 100€.

 

 

Organisation du projet :

 

 

 

 

Ressources

 

 

PICAMERA :

Caméra permettant d’acquérir une image ou faire une vidéo. Dans mon cas, elle est utilisée en tant que lentille d’acquisition d’image. Elle est de très bonne qualité,  en effet elle possède une multitude d’application (réglage de contraste, résolution, qualité…) très facile d’accès.

 

 

 

RASPBERRY PI 3:

C’est un mini-ordinateur qui relie les différents module du microscope. Cette carte contrôle l’écran, les LEDS ainsi que la caméra à travers des langages de programmations notamment le python.

 

 

 

SENSEHAT :

C’est un module qui contient un ensemble de capteur (pression, ultrason, température…), personnellement j’utilise seulement la matrice de LED compatible avec Raspberry Pi pour des raisons d’accessibilité. Ces LEDS sont simples à programmer. Cependant, le flux lumineux qu’elles délivrent est irrégulier après expérience.

 

ECRAN LCD :

Ecran tactile «  7 pouces » permettant de visualiser les images acquises par le microscope.  Il est possible de travailler directement avec le microscope sans avoir besoin d’être à proximité d’un écran d’ordinateur grâce à une interface manipulée avec python.

 

 

BILLE :

C’est utilisé comme une lentille, de 1,92 millimètres de diamètre, qui permet d’agrandir 177 fois l’image de la camera, qui est placé entre la source de lumière et l’échantillon.  La seule problématique est la distance entre la focale et l’échantillon.

 

Réalisation du Projet

 

Programmation : 

Dans un premier temps, l’objectif consiste à acquérir une image à l’aide de la PiCamera. La maîtrise de linux et aussi python est nécessaire avant de débuter l’un est semblable à l’invite commande d’un PC et l’autre est un langage de programmation intégré dans le Raspberry PI. Pour capturer une image, il faut : télécharger la librairie appropriée, déclarée au tout début du programme python. On à ainsi accès aux différents fonctionnalités comme par exemple : le contraste de l’image, la résolution, obtenir une vidéo, image ….

Puis dans un second temps le but est de régler la luminosité délivrée par le sense hat par le biais de la matrice de LED, pour facilité l’observation de l’échantillon. Il faut également installer la librairie pour ce cas.

Ensuite il m’est demandé de mettre au point une interface permettant de manipuler le code de manière tactile via Tkinter. Et pour terminer, faire du traitement d’image avec OpenCv, le travaille ce fait sur les pixels de l’image, le but est d’obtenir un échantillon perceptible pour ensuite l’étudier, avec l’aide du détection de contours et de filtre. 

 

 

Test 1 : observation d’un échantillon de plume d’oiseau avec filtre.

 

 

 

Test 2 : observation d’un échantillon de plume d’oiseau sans filtre.

 

 

Conception :

Pour ce projet, il m’est demandé de faire une CAO de la microscope. Pour ce faire, certains critères doivent être traités en amont, tout d’abord la distance focale entre la bille et la lentille de caméra (quelques millimètres ), ensuite la distance entre l’échantillon et la source de lumière (proche de 2cm), prendre en compte la taille de la nappe (15 cm), un support pour projeter la lumière à un point précis, un support pour tenir l’échantillon et le tout relié au Raspberry pi. Pour la conception, le logiciel utilisé est « CorelDraw ». C’est une conception en 3D utilisant une machine  à découpe laser.

 

Perspectives D’améliorations

 

 

Afin que le projet puisse connaître de meilleur résultat, il est envisageable de travaillé sur la source d’éclairage, l’autotomie ainsi qu’un moyen de support, d’extension pour la Picamera. 

 

Source d’éclairage :  LED Blanche.

   

 

Extension Picamera : Raspberry Pi Camera HDMI Câble Extension

 

Autonomie : Batterie lithium 5 Volts.

 

 

 

Conclusion

 

 

Ce projet m’a permis de découvrir de nouvelles choses comme : la gestion d’un projet, le travail en autonomie, la démarche à suivre pour arriver au bout d’un projet. De plus, cela m’a permis d’approfondir mes connaissances en informatique, en langage python, l’univers de linux ainsi qu’à la conception d’une microscope. 

 

 

Remerciements

 

 

Merci au département GEII de l’IUT de Mulhouse pour le budget et l’apport de matériels.

Nos professeurs encadrants Mr Verrier et Mr Bazeille de m’avoir aidé pour ce projet.


Microscopie sans lentille

  

MICROSCOPE SANS LENTILLE

 

SOMMAIRE

 

INTRODUCTION

PROBLÉMATIQUES

STRATÉGIES

COMPOSANTS

CAO

PROGRAMMATION

VIDÉO

CONCLUSION

POUR ALLER PLUS LOIN…

REMERCIEMENTS

 

INTRODUCTION

 

Durant notre deuxième année de DUT Génie Electrique et Informatique Industrielle nous devions effectuer un projet d’étude et réalisation. Nous avons choisi de réaliser un microscope sans lentille à l’aide d’un Raspberry Pi 3. Pour mener à bien se projet nous étions encadrés par deux professeurs, Mr Verrier et Mr Bazeille et notre équipe était composée de la manière suivante :

  • Arthur Gasser – Chef de Projet
  • Quentin Dijoux – Responsable Programmation
  • Raphaël Jimenez – Responsable Conception Assistée par Ordinateur

Notre microscope devait impérativement être réalisé en utilisant un Raspberry Pi 3 et nous devions le créer à l’aide d’une Conception Assistée par Ordinateur (CAO). Il nous a donc tout d’abord fallut apprendre les bases de la programmation Linux, Unix et de l’univers Raspberry en général. Mais nous avons également dû approfondir certaines notions concernant le domaine de l’optique pour pouvoir dimensionner notre microscope de manière optimale. La capture de l’image zoomée se fait à l’aide d’une RaspiCam Noire V2 et peut être visualisée sur un écran LCD et l’éclairage se fait à l’aide d’un module de leds SenseHat.

Nous avons commencé ce projet le jeudi 30/11/2107 et nous l’avons achever le lundi 22/01/2108. La réalisation d’un microscope géré électroniquement nous intéressait tout particulièrement car les différents aspects de conception et de programmation étaient nouveaux pour nous. Mais ce projet faisait appel à d’autres notions intéressantes comme l’holographie par exemple.

 

PROBLÉMATIQUES

 

Comment programmer efficacement le microscope pour qu’il soit simple d’utilisation ?

Comment dimensionner rigoureusement la CAO pour que les zooms effectués par le microscope soient suffisamment conséquents et nets ?

Nous voyons ressortir ici les deux points principaux de notre projet : CAO et Programmation.

 

STRATÉGIES

 

Ce projet était assez conséquent tant au niveau de la charge de travail qu’au niveau de la difficulté. Nous avons donc relevé le challenge en donnant le meilleur de nous même ! Nos points forts étaient notre motivation et notre bonne répartition des rôles. Nous avons également essayé de communiquer régulièrement avec nos professeurs encadrants afin qu’ils soient tenus au courant des avancements de notre projet et pour qu’ils puissent nous conseiller au mieux.

Nous avons tout d’abord réalisé le cahier des charges fonctionnelles accompagné de différents diagrammes pour bien commencer le projet. Puis nous avons effectué les différentes recherches nécessaires afin de pouvoir démarrer la programmation de la caméra et des leds. Ensuite nous avons étudié un certains nombres de documents afin de pouvoir calculer la future résolution de notre microscope qui nous a permis de le dimensionner et nous avons rédigé les différents documents accompagnant notre projet tout au long de celui-ci. Plus notre projet avançait, plus il était complexe, il a donc fallut travailler en dehors des heures prévues pour les études et réalisations, lors de nos temps libres.

Nous vous invitions à télécharger le PDF suivant afin de visualiser nos différents diagrammes qui nous ont permis de démarrer le projet dans les meilleures conditions possibles (Bête à cornes, MindMap, Pieuvre, Ligne des temps).

Stratégies

 

COMPOSANTS

 

Notre microscope est constitué de plusieurs éléments, nous allons vous les présenter brièvement. Les caractéristiques électroniques de ces composants sont détaillées dans notre Cahier des charges techniques disponible en bas de page.

  • RASPBERRY PI 3 Modèle B

C’est le cœur de notre microscope. En effet cette carte contrôle notre écran, nos leds ainsi que notre caméra. L’entièreté de la programmation a été réalisé sur ce Raspberry et toutes les informations sont centralisées à l’intérieur de ce dernier.

  • ECRAN LCD

Cet écran tactile permet de visualiser les images récupérées à l’aide de notre microscope. Il rajoute énormément de confort car il est possible de travailler directement avec le microscope sans avoir besoin d’être à proximité d’un autre écran. Cependant, travailler sur un écran plus grand reste plus confortable sur le long terme.

  • RASPICAM NOIRE V2

Cette caméra nous permet de capturer nos images zoomées. Elle est de très bonne qualité mais dans le cadre de notre application, comme le nom de notre projet l’indique, nous avons été amené à retirer la lentille présente sur la caméra. Cela est indispensable pour pouvoir réaliser les zooms des images.

  • SENSEHAT

Cette petite carte contient un module leds compatible avec Raspberry, voilà pourquoi nous l’avons choisi pour réaliser l’éclairage dans notre microscope. Ces leds sont pratiques à utiliser et assez simples à programmer. Cependant, le flux lumineux qu’elles délivrent est assez faible. Il est possible d’augmenter la qualité de notre microscope avec des leds plus puissantes.

  • CARTE SD

Nous réalisons des captures ainsi que du traitement d’image, ces opérations sont assez lourdes niveau mémoire. Nous avons donc du ajouter une carte SD de 16go compatible avec Raspberry pour éviter tout problème et pour mener à bien notre projet.

  • ÉCHANTILLON

Enfin, comme dans tout microscope, il faut un échantillon à observer. Comme pour les microscope classique nous observons des échantillons présents sur de simples lames standards.

CAO

 

L’un des points principaux de notre projet était de réaliser une CAO (Conception Assistée par Ordinateur) pour créer notre microscope. Pour cela, nous avons utilisé le logiciel Tinkercad, qui était le plus pratique dans notre cas car c’est un logiciel en ligne, nous pouvions donc travailler chez nous et sur tous les PC de l’IUT (voici un lien vers le site Tinkercad).

Pour une question de praticité, nous avons décidé de réaliser notre microscope en plusieurs pièces pour faciliter le montage ainsi que la maintenance. Dans cette partie, nous allons vous présenter chacune des pièces en détail.

  • SOCLE

Commençons par la base de notre microscope. Ce socle a été conçu afin que la caméra et surtout le capteur soit au milieu du microscope. Il y a également un chemin de câble qui passe en dessus pour que la nappe de la caméra soit protégée et pour la connecter directement au Raspberry de manière efficace. Le Raspberry et l’écran sont donc placés sur la partie avant du socle (la plus grande) pour des questions de confort.

  • MURS/ÉCHANTILLON

Sur ce socle, vient la partie qui permettra d’accueillir l’échantillon. Cette pièce est constituée de 4 murs et sur deux de ces murs, il y a une fente permettant d’introduire l’échantillon dans le microscope à l’aide de la pièce que nous allons voir tout de suite.

  • SUPPORT/ÉCHANTILLON

On place l’échantillon sur cette pièce puis on l’introduit dans le microscope. Tout a été étudié pour que le support soit maintenu par les deux fentes vues précédemment. Cette pièce est de cette forme car l’échantillon ainsi que la lumière doivent arriver jusqu’au capteur située juste en dessous.

  • PROTECTION

Pour que notre écran et notre Raspberry soient protégés contre les chutes. Nous avons réalisé cette pièce permettant de les caler. Sur cette pièce nous avons également réalisé deux trous pour laisser passer les câbles provenant du SenseHat et de l’alimentation mais aussi pour brancher le clavier, la souris et un câble HDMI. Nous avons aussi placé le logo de l’IUT ainsi que nos noms sur le dessus de la pièce.

  • PINHOLE

Cette pièce est entièrement pleine. Mais en son centre, il y a le trou appelé « pinhole » permettant de laisser passer la lumière. Sa taille a été étudiée afin que le phénomène de diffraction soit respecté, nous verrons les détails des phénomènes physiques dans la dernière partie de ce document.

  • FOCALE

Afin que le flux de lumière soit plus conséquent, nous avons ajouté une focale pour concentrer la lumière en un seul point. Cette pièce est donc constituée d’un trou permettant de fixer parfaitement la focale au centre.

  • LEDS/TUYAU

Notre module de leds sera fixé sur cette pièce, nous avons percé un trou afin de laisser passer les câbles du SenseHat. Ces câbles passeront ensuite dans le tuyau et descendront jusqu’au Raspberry.

  • TOIT

Voici la dernière pièce de notre microscope. Il s’agit d’un cube permettant de refermé le montage. Sur cette pièce nous pouvons voir le nom de notre microscope « μSCO-Pi 3D » ainsi que notre logo.

La CAO était une étape très importante du projet, nous avons donc consacré beaucoup de temps pour la réaliser de la manière la plus précise, esthétique et ergonomique. Cependant, le rendu final présentait quelques erreurs de précision que nous avons tenté de corriger au mieux. Nous avons dû peindre notre microscope en noir pour empêcher la lumière extérieure de gêner notre acquisition. Nous avons utilisé l’imprimante 3D (résine) de l’IUT Lab, nous souhaitons donc remercier Mr De Sabbata pour son aide.

Nous vous invitions à télécharger notre Cahier des charges techniques (CDCT) en bas de page dans la rubrique « Pour aller plus loin… » afin de visualiser nos différentes pièces ainsi que le microscope fini sur Tinkercad et après impression.

 

PROGRAMMATION

 

La programmation de notre microscope est réalisée en Python 3. Avant ce projet, nous n’avions aucune connaissance en Python et en Linux, nous avons donc dû nous adapter et apprendre ces différents langages. Nous souhaitions que notre microscope puisse être utilisé par tout le monde, c’est pour cela que nous avons annoté chacun de nos programmes. Nous utilisons trois programmes principaux et nous allons détailler leur contenu.

  • ACQUISITION

La programmation de notre microscope est réalisée en Python 3. Avant ce projet, nous n’avions aucune connaissance en Python et en Linux, nous avons donc dû nous adapter et apprendre ces différents langages. Nous souhaitions que notre microscope puisse être utilisé par tout le monde, c’est pour cela que nous avons annoté chacun de nos programmes. Nous utilisons trois programmes principaux et nous allons détailler leur contenu.

  • RECONSTRUCTION

La capture étant réalisée, il faut maintenant améliorer le rendu de celle-ci. Pour cela veillez cliquer sur le bouton « Reconstruction 2D » afin de lancer le programme correspondant. Ce dernier va réaliser une mise au point numérique à l’aide d’un recalage de pixel. Pour cela, il faut utiliser plusieurs FFT (Fast Fourier Transformer). Ces différents termes peuvent paraître compliqués mais en visualisant la photo une fois reconstruite vous allez très vite comprendre son impact sur l’image que vous avez prise précédemment. Une fois la reconstruction terminée vous pouvez analyser votre image.

  • ANALYSE

Pour ouvrir ce programme il vous suffit d’appuyer sur le bouton correspondant. Une fois le programme lancé, vous pouvez réaliser un certains nombres d’actions :

  • Contouring
  • Zoom
  • Déplacement
  • Annotation
  • Sauvegarde

Pour accéder à ces différentes actions, il vous suffit de lire les instructions présentes sur votre écran.

Vous pouvez retrouver tous nos codes en téléchargement dans la rubrique « Pour aller plus loin… » en bas de page.

 

VIDÉO

 

Dans le cadre du projet nous avons du réaliser une vidéo résumant l’entièreté de celui-ci. Nous n’avons pas réalisé une vidéo classique, en effet, nous avons utilisé une macro sur PowerPoint afin de transformer ce dernier en vidéo full HD puis nous avons rajouté nos voix ainsi qu’une musique en fond. Cette vidéo est disponible juste ici, nous vous invitons à la visionner.

 

 

CONCLUSION

 

Malgré le manque de connaissance, nous nous sommes adaptés très rapidement à l’univers Raspberry. Nous avons réussi à créer un programme assez simple d’utilisation ainsi qu’un CAO précise, nous avons atteints nos objectifs. Nous sommes globalement très satisfaits du rendu final de notre microscope. Le projet était assez complexe mais nous avons redoublé d’effort pour le mener à bien. Nous arrivons à obtenir des images zoomées avec une résolution et une précision correctes. Nous aurions cependant pu avoir de meilleurs résultats avec une source de lumière plus adaptée à la situation et un pinhole plus petit (ce qui était difficilement réalisable). Et avec plus de temps, nous aurions aimé réaliser, en plus de la reconstruction 2D, une reconstruction 3D de nos images mais c’est encore un autre niveau de difficulté.

Mais notre microscope n’est pas encore dans son état final puisque Mr Verrier continuera à travailler sur celui-ci et l’utilisera lors de divers présentations ou événements.

 

POUR ALLER PLUS LOIN…

 

Afin que notre projet soit plus complet et plus détaillé, nous avons rédiger plusieurs documents. Si notre projet vous a intéressé, nous vous invitons à les télécharger. Les différents programmes que nous avons réalisé sont également en téléchargement.

  • Cahier des charges fonctionnelles

Indispensable au bon démarrage du projet, ce cahier des charges définit les différents cadres et objectifs de celui-ci. Il permet de partir dans la bonne direction et de vérifier si tous les membres de l’équipe ont la même vision des moyens à mettre en œuvre pour accomplir les objectifs.

CDCF

  • Cahier des charges techniques

Ce document récapitule les fonctions des composants que nous avons utilisé, la manière dont nous avons effectué notre CAO, les différents calculs de dimensionnement que nous avons du faire et aussi un résumé de la partie programmation.

CDCT

Interface Raspberry

Analyse Raspberry

Interface Moniteur

Analyse Moniteur

Reconstruction

  • Guide d’utilisation et d’installations

Ce guide vous permet de comprendre comment utiliser notre microscope étape par étape mais il vous explique également comment installé les divers logiciels que nous avons installé sur notre Raspberry.

Guide

  • Rapport de nos séances

Ce document permet de visualiser l’avancement de notre projet au fur et à mesure de nos séances de travail.

Rapport des séances

 

REMERCIEMENTS

 

Nos professeurs encadrants pour leurs aides et leurs conseils.

L’IUT ainsi que l’IUT LAB de Mulhouse pour le budget et l’apport de matériels.

 


Anneaux de photodiodes

Anneau photodiodes

 

LITZLER Cédric

ZUGMEYER Adrien

BARETTI Gaetan

 


Sommaire

 

1. Présentation du projet

2. Attributions des rôles

3. Câblage électrique & Réalisation du circuit imprimé

4. Programmation Arduino

5.Programmation Python(Spyder)

6. Serveur MQTT

7.Avancé du projet

8. Conclusion

9.Remerciements

 


1. Présentation du projet

Dans le cadre de notre projet de 2ème année en « Etudes et Réalisations », nous avons mes 2 camarades ainsi que moi-même été amenés à travailler ensemble sur le projet d’un anneau de photodiodes.

Le but de ce projet est de créer un système de mesure qui sera utilisé pour visualiser la direction de l’étirement d’un textile soumis à un test.

Le système sera composé d’une carte Arduino, d’un laser, d’un circuit électrique de forme circulaire, d’une alimentation et de photodiodes. Ce système sera placé au dessus du textile et protégé de la lumière par un tube ou une jupe. Le laser et les photodiodes pointeront en direction du textile et la lumière du laser sera plus ou moins réfléchie par le tissu vers les photodiodes placées sous la forme d’un cercle afin de connaitre l’intensité de l’étirement et la direction des fibres du textile. Ces mesures seront lues via un PC sous forme de tension .

Ci-dessous, voici un premier schéma montrant un peu à quoi va ressembler le résultat final de notre projet ainsi que 2 images de notre maquette actuelle. A cela, il faut encore y rajouter un manche ou un support permettant de fixer le matériel tel que la carte Arduino, les connexions des différents câbles électriques, la pile etc…

 


2. Attributions des rôles

 

LITZLER Cédric:

  • Programmation de la carte Arduino
  • Programmation Python
  • Câblage & conception du schéma électrique
  • Réalisation du câblage électrique de la plaquette finale
  • Rédaction du dossier texte

 

ZUGMEYER Adrien:

  • Etude de la partie électrique: Réalisation du Circuit-Imprimé & Conception du schéma électrique
  • Rédaction du dossier texte
  • Travail sur le support

 

BARETTI Gaetan:

  • Conception du Schéma électrique, Planification & création du serveur MQTT (abandoné)
  • Rédaction du dossier texte
  • Travail sur le support

 

 


3. Câblage électrique

Le projet prévoyait initialement 36 photodiodes mais après une étude plus détaillée de tous le système, nous somme passé à 8 photodiodes pour un soucis de complexité. La difficulté principale réside dans la présence du grand nombre de fils au final. Après s’être documenté sur internet et sur divers sites, j’ai pu dresser le schéma électrique qui permet la liaison des photodiodes avec la carte Arduino. Ce câblage comporte 8 résistances de 1MΩ, la carte Arduino MEGA, 8 photodiodes et beaucoup de fils électriques.

La masse est relié entre la résistance et la photodiode. La photodiode elle, est relié à l’autre entrée de la résistance et relie les entrées analogiques de A0 à A7.

Ci-dessous, le schéma électrique réalisé sur le logiciel kicad:

 

 

 

Réalisation du circuit imprimé:

A l’aide du schéma électrique réalisé sur le logiciel Kicad, nous avons pu nous en servir pour créer le circuit imprimé.

Adrien a donc dû se familiariser avec l’environnement de travail de Kicad ce qui n’a pas été chose aisée car c’est un logiciel qui n’est pas très intuitif. Kicad permet, à partir d’un schéma électrique, de créer un Circuit imprimé en associant les empreintes des composants avec leur noms. Voici le résultat obtenu après plusieurs heures de travail sur le logiciel de création:

 

 

 

 

 

 

 

                                                                                                    Voici a quoi ressemblera le circuit imprimé lorsqu’il sera fini

 

Suite à cela nous avons pu utiliser le laboratoire de Circuit imprimé pour découper le disque puis le percer pour accueillir les pattes des composants électronique, nous avons enfin, pu souder les composants à la carte.

 



4. Codage Arduino

Le codage de la carte Arduino est une étape très importante dans le projet afin de recevoir les valeurs des photodiodes. Après avoir réalisé de nombreuse recherches sur internet sur la façon de construire ce code, j’ai travaillé en plusieurs étapes.

Dans un premier temps j’ai commencé par essayer de piloter 1 seule photodiode puis 4, puis d’ajouter un bouton pour contrôler les acquisitions uniquement lors de son appui dessus. Finalement, j’ai pu supprimer ce bouton n’ayant plus de réel utilité puisque toutes les acquisitions se font maintenant via le logiciel Spyder.

A présent, le programme comporte les 8 photodiodes et fonctionne efficacement.

Le programme utilise la liaison série à 38400 bits/seconde.

 

Le principe général est le suivant:

Les photodiodes relèvent une valeur correspondant à une tension en fonction de la luminosité qu’elles perçoivent. Le programme doit pouvoir lire les valeurs du nombre d’acquisition et de la durée entre 2 acquisitions sur le port série. Ces valeurs saisies par l’utilisateur seront stockés dans des variables dans la mémoire ROM (voir explication de l’utilisation de la mémoire ROM en-dessous du code)

De plus, il doit également pouvoir envoyer les valeurs des photodiodes via le port série de façon à être récupérée grâce à une instruction bien précise sur le logiciel Spyder.

 

 

Le code arduino final:

 




 

Quelques explications importantes:

 

-On commence par déclarer les bibliothèques utilisées.

-On déclare dans un integer constant nommé numReading  la taille du tableau (Ici 6).         Objectif –> Lisser légèrement les valeurs en utilisant les 6 dernières valeurs présentes dans le tableau afin de ne pas avoir a traiter des signaux « parasites ».

-Utilisation de « EEPROM.read(0) » et « EEPROM.read(1) » dans le programme arduino car les variables sont généralement stockés dans un buffer et que les paramètres du nombre d’acquisition et du délai entre 2 acquisitions ne sont transmises qu’une seul fois par le port série. Ecrire ce résultat dans la ROM de la carte Arduino permet donc de préserver cette valeur.

-Ne pas oublier dans la fonction setup l’initiailisation de la communication serie à 38400 et l’initialisation du tableau.

-ReadIndex nous servira à évoluer de 0 à 6 pour lire chaque valeur du tableau.

-Total contient la somme de toutes les valeurs du tableau.

-Average sera la valeur moyenne du tableau (total / numReading).

 

Fonction principale loop():

-On retire de total la valeur actuellement indexée du tableau (afin de faire de la place pour la nouvelle).

-On vient stocker la valeur du potentiomètre dans l’index en cours du tableau.

-On ajoute la valeur au total.

-On augmente l’index de 1 afin de passage à la « case suivante » du tableau.

-Si l’index dépassee 6, alors on le remet à 0. Le tableau évolue de reading[0] à reading[6].

-On calcul la valeur moyenne du tableau reading[].

-On envoit la moyenne au moniteur série.

 

 

 


 

5. Programmation Python (Spyder)

 

Spyder est un environnement de développement pour Python qui intègre de nombreuses bibliothèques à usage scientifique tel que « Matpolib » que nous importons afin de pouvoir tracer notre graphique en forme de polygone.

 

Préparation:

Si le module du port série n’est pas installé, vous obtiendrez ce message d’erreur: “No module named serial”. Cela est dû au fait que le port série n’est pas directement inclut avec python

Pour ce faire il a fallu l’installer  à l’aide de la ligne de commande « pip install pyserial » dans Anaconda Prompt*:

 

*J’ai installé Anaconda Navigator qui regroupe en quelque sorte tous les fichier dont a besoin Spyder pour fonctionner

 

Afin d’accélérer la vitesse de transmission du port série, il a fallu modifier le réglage de la vitesse de transmission du port associé (dans notre cas COM6). Réglé de manière générale à 9600, je l’ai accéléré à 38400!

Il est également important de ne pas oublier de renseigner ce paramètre dans le code Arduino et Python!

 

 

 

 

 

 

 

Code Python utilisé dans le projet:



 

J’ai mis des commentaires un peu partout dans le code pour ne pas s’y perdre et comprendre l’application générale du programme. Sachez qu’une fois les données du port série récupérées, il est possible de créer plus ou moins n’importe quelle interface graphique à l’aide de code trouvable sur internet. Dans notre cas, il s’agit du diagramme de Kiviat.

 

 

Démonstration du fonctionnement du programme:

 

Lorsque nous lançons le logiciel Spyder, celui-ci affichera dans la console la chose suivante:

 

Nous pouvons ainsi lancer l’exécution de fichier depuis le bandeau général du logiciel (voir icône au centre du cercle rouge)

 

Il faudra ensuite renseigner les bons paramètres:

  • « start » : lance le processus d’acquisition
  • le nombre d’image crée avant la temporisation
  • L’intervalle de temps en secondes entre 2 acquisitions

Remarque:

La saisie des données (nombre d’acquisition et intervalle de temps) est limité à une valeur de 255. Cette valeur limite est du au fait qu’elle est est envoyé sous forme de caractère. Lors de son envoi sur le port série, elle est encodé sous forme de table Ascii qui contient 255 valeurs.

 

 

Après avoir renseigné les paramètres nécessaire, le programme en Python va générer un graphique correspondant aux différentes valeurs des photodiodes relevées.

Nous affichons le numéro de l’image (ici 0 puis 1 puis 24)pour connaitre l’avancée de l’acquisition ainsi que les valeurs mesurées par les photodiodes.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Lorsque le bon nombre d’acquisition est atteint, la temporisation dure le nombre de seconde indiqués (ici 10s) puis recommence à effectuer les acquisitions et ainsi de suite.

 

 

Pour arrêter la console, il suffit d’appuyer sur le bouton suivant:

 

 

Une fois la console arrêté, il faut redémarrer le noyau puis relancer l’exécution du fichier.

 

Si nous ne redémarrons pas le noyau un message d’erreur viendra. Il indiquera un problème au niveau du port série.

En effet, le fait d’interrompre la console, le port série reste en quelque sorte ouvert et ne se referme pas. Cependant il est difficile de le refermer efficacement puisque la seule solution serait d’écrire quelque chose de bien définit dans la console qui exécuterait ensuite une instruction fermant le port série; seulement le défilement des images générés rend impossible la saisie (où alors uniquement lorsque la pause entre 2 acquisitions se réalise). J’ai alors opté pour l’interruption et le redémarrage du noyau. Cette solution ne prend pas beaucoup plus de temps, et n’ayant pas de contrainte défini dans le cahier des charges, cette méthode peut-être validé!

 

Une image en extension png  identique à celle présente dans la console est aussi crée dans le dossier ou se trouve le fichier Python et ceux à chaque acquisition. Cependant, seul la dernière image (celle avant la temporisation) n’est vraiment accessible puisque les autres, dès que crées, sont aussitôt écrasés par celle d’une nouvelle acquisition.

 


 

5. Serveur MQTT

L’Intérêt de créer un serveur MQTT était de pouvoir bénéficier d’une interface à distance qui aurai permis de lancer les acquisitions à distance et récupérer les valeurs sans devoir être connecté a un PC. Pour cela Gaetan a créé un serveur local sur son PC via le broker Mosquitto. Nous avons réussi à obtenir des résultats en interconnectant deux PC avec un câble ethernet: nous avons réussi à nous connecter à un topic et pu lire et publier sur celui-ci via l’interface de commande Windows.

Voici l’initialisation du serveur sur le premier PC

 

 

On peut ensuite publier sur un topic de test via un second PC pour vérifier que le serveur fonctionne

 

 

Un souscripteur au topic va pouvoir lire le message envoyé depuis le second PC

Il faut maintenant pouvoir connecté notre Arduino à ce serveur MQTT.

Pour cela on va utiliser un shield ethernet pour le connecté sur le même réseau local que le serveur.

On doit alors ajouté les bibliothèque Arduino liés au protocole MQTT pour la communication entre l’Arduino et le serveur ainsi qu’une bibliothèque ethernet pour interagir avec le shield.

Ci dessous le code permettant à l’Arduino de se connecter au serveur MQTT et souscrire à un topic :

Nous avons malheureusement été contraint d’abodonner le serveur MQTT à cause d’un manque de matériel, nous n’avions qu’un shield ethernet pour l’Arduino alors que nous avions besoin d’un shield Wi-Fi ( rupture de stock depuis plusieurs mois ) qui nous aurai permis de nous connecter à distance au réseau local. Dans un souci de respect des délais Gaetan a décidé de travailler sur le support.

 


6. Support

Dans un premier temps nous avons créé la partie principale du support qui va maintenir le laser et diriger le faisceau vers le bas. Il est constitué d’un tube ainsi que d’un capuchon réalisé à la découpe laser.

 

 

 

 

 

 

 

 

 

On a ensuite constitué une plateforme pour positionner l’Arduino, le tout est surélevé à l’aide de baguette en bois pour que le tissu placer en dessous puisse réfléchir la lumière du laser sur l’anneau de photodiode.

On place alors une « jupe » sur la structure afin d’isoler l’anneau de photodiode de toute lumière exterieur qui risque de perturber les résultats.

L’ensemble de la structure à été réalisé à la découpe laser.

Le support est léger donc facilement déplaçable au dessus d’un tissu cependant il est très fragile.

 


7. Avancé du projet

Le schéma électrique ainsi que son montage fonctionne correctement.

La partie concernant la programmation Arduino & Python à été entièrement réalisé.

Le circuit imprimé ne fonctionnant pas, j’ai décidé de prendre l’initiative d’assembler moi-même les composants sur une plaquette que j’ai découpé moi même. Bien que cette solution ne soit pas très soigné, cette solution permet ainsi l’acquisition des données et de « sauver » le rendu final du projet.

L’idée du serveur MQTT a été abandonné.

Le circuit imprimé à été réalisé mais ne fonctionne pas.

 

8. Conclusion

 

La partie concernant la programmation Arduino & Python à été entièrement réalisé et son principe fonctionne correctement. Cependant, il peut encore être perfectible en simplifiant peut-être encore les codes et améliorant encore certaines choses (ex:vérifier les saisies rentrées par les utilisateurs, simplifier l’arrêt et le redémarrage des acquisitions)

Le circuit imprimé ne fonctionnant pas, j’ai décidé de prendre l’initiative d’assembler moi-même les composants sur une plaquette que j’ai découpé moi même. Bien que cette solution ne soit pas très soigné, cette solution permet ainsi l’acquisition des données. J’ai pu approfondir mes connaissances en language c++ et découvrir le langage python.

Devant réaliser des tâches qui ne me concernait pas à l’origine, j’aurai pu perfectionner les codes que j’ai écris avec ce temps de perdu.

Grace à ce projet nous avons pu apprendre à utiliser de nouveaux logiciels,  de nouveaux langages de programmation, nous avons pu rencontrer de nouveaux matériaux (photodiodes).  Mais il faut avant tout savoir faire preuve d’esprit critique  savoir ce qui a fonctionné c’est bien, savoir ce qui n’a pas marché et pourquoi c’est mieux.

 

Nous avons accumulé beaucoup de retard ce qui nous a fait perdre toute notre marge d’erreur, nous avons accumulé du retard pour différentes raisons,  certains membres du groupe ont manqué d’organisation durant la durée du projet et ainsi empêché la finalisation du projet, il y a aussi eu un manque de communication dans l’équipe.

Il faut donc garder à l’esprit les erreurs que l’on a commises lors de ce projet afin de ne plus les reproduire dans le futur .

 


9. Remerciement

Nous souhaitons tous les 3 remercier les professeurs pour les aides, les explications et les conseils qu’ils nous ont fournis. Nous souhaitons également Christophe De Sabbata pour sa patience et son aide.


Banc d’acquisition pour un système de vision

BANC DE VISION


Contrôle visuel de pièces

 

Notre Groupe :

FREUDENREICH Theo – BENSCH Dylan – MEYER Virgile


Un contrôle métrologique n’est pas toujours nécessaire afin de vérifier qu’une pièce soit conforme. Il est également possible de réaliser un contrôle visuel, à l’aide d’une caméra industrielle permettant de faire des prises de vue rapides, qui seront traitées par un logiciel. Notre projet s’inscrit dans le contrôle de pièces brutes de fonderie, un tel contrôle visuel est donc suffisant.

Nous réaliserons le banc sur lequel sera fixé une caméra. Ce banc devra pouvoir tourner autour de la pièce en question pour prendre différents angles de vue et contrôler la pièce.


Sommaire :

  1. Cahier des charges
  2. Solution retenue
  3. Conception
  4. Réalisation et montage du banc
  5. Motorisation de l’arc

1.Cahier des charges

Expression du besoin:

Le Banc de vision est destiné à un industriel. Il permet de prendre différentes prises de vues d’une pièce, sans intervention humaine,  à l’aide d’une caméra.

 

 

 

 

 

 

 

 

Diagramme des intéracteurs : 

 

Cahier des charges : 

Il présente succinctement les différents critères à respecter lors de la fabrication du banc :

2.Solution retenue : 

 

  • La caméra est fixée sur le chariot, qui permet son déplacement sur l’arc
  • L’arc, relié à un axe et un moteur pas à pas, va permettre de tourner autour de la pièce
  • La bille sous l’arc permet de diminuer la charge appliquée sur l’axe
  • Le bâti réalisé en profilés Bosch, permet de supporter l’ensemble.

 

 

 

 

 

 

 

3.Conception

Vue d’ensemble:

Plans Axe:

Plan Arc:

 

Plan chariot:

Vue éclatée du chariot :

Plan :

4.Réalisation et montage du banc

A l’exception des éléments standards liés aux profilés Bosch (équerres, cubes de liaison) et la poulie fixée sur l’axe, nous avons réalisés les pièces à l’atelier du département GMP.

Usinage de l’axe: pièce la plus complexe car elle comprend des rainures et perçages difficilement réalisable avec des moyens dit conventionnels. Nous avons donc réalisé cette pièce sur le tour 6 axes DMG Alpha 500. Pour cela nous avons tout d’abord utilisé le logiciel de FAO Esprit.

 

C’était une partie extrêmement enrichissante dans notre projet, nous avons exploré les nombreuses possibilités qu’offre le logiciel Esprit et les machines d’usinage 6 axe. En effet nous avons utilisés la broche de reprise mais aussi des outils tournants radiaux et axiaux et toutes les procédures que cela implique.

Découpage des plaques et de l’arc: De nombreux composants de notre projet, sont issus de découpe dans des plaques d’aluminium, ces pièces ont étés découpées par jet d’eau. cette opération à été réalisée par M. Senn, car pour des raisons de sécurité la découpe jet d’eau n’est pas accessible en ce moment.

Montage : Montage de la transmission entre le moteur et l’axe :

Montage du chariot sur l’arc : Le taraudage M10 n’a pas pu être réaliser, une vis et un écrou maintiennent l’ensemble :

L’assemblage finale sur le bâti : Seul le taraudage afin de pouvoir assembler la bille de maintient en bas de l’arc n’a pas été réalisé, la bille n’est donc pas en place, il en résulte une flexion importante du bâti, ainsi qu’un effort important au niveau de l’axe que rend la rotation difficile.

5.Motorisation de l’arc

 

L’arc est motorisé à l’aide d’un moteur pas à pas. Il nous permet de ne faire qu’un certain angle avec l’arc, lorsque l’ordre en est donné.

Le moteur doit être relié à une carte de puissance, qui permet de l’alimenter, la arduino ne pouvant pas le faire elle même.

Nous avons décidé de diviser le tour par 45° afin d’offrir 8 points de vue différents.

Calcul du nombre pas nécessaires:

Le moteur pas à pas réalise 200 pas par tour. Soit 1.8° par pas. Comme l’on réalise une prise de vue tous les 45°, il faut faire 25 pas.

Le rapport de réduction entre les deux roues étant de 11/72, il faut donner une consigne de 25/0.1528=163.6 pas.

Le logiciel arduino contient une bibliothèque « Stepper » qui permet de contrôler directement les moteurs pas à pas, voici le programme réalisé :

  • Pour que le moteur tourne il faut que le bouton soit à 0L. En effet, le contact est tout le temps fermé, sauf lors de l’appuie sur le bouton où il va s’ouvrir.

Schéma du câblage :

6.Conclusion

Même si nous ne sommes pas arrivé au terme de notre Projet, celui-ci nous a permis de mettre en pratique un grand nombre des compétences et savoirs étudiés en DUT GMP. Ceci au travers de phases de conception, recherche de solution, de fournisseur et de réalisation. Nous avons utilisé une grande gamme d’outils technologiques, logiciels comme matériels.


Supervision d’un panneau solaire

Les élèves ayant réalisé le projet :

  • Léo GOUZOUAZI étudiant GEII
  • Nikola ILIC étudiant GEII

Sommaire

  1. Présentation du Projet
  2. Analyse fonctionnelle
  3. Matériel
  4. Réalisation
  5. Avancée du projet
  6. Conclusion

Introduction

Le but du projet « Supervision d’un panneau solaire » est d’exercer un contrôle ou une vérification sur l’activité du panneau solaire situé au sein de l’IUT de Mulhouse, et ces informations seront stockées dans un tableur. Tout cela est rendu possible à l’aide de capteurs de courant, d’humidité, de température, de lumière, d’une Arduino Yun et de différents calculs réalisés à l’aide des valeurs renvoyées par les capteurs.

Ces valeurs étant constamment en évolution et n’étant pas fournises par le constructeur, nous proposons ainsi aux personnes voulant les exploiter une façon de s’en servir pour leurs études personnelles, les données étant récupérables tout les soirs.


Analyse fonctionnelle

Cahier des Charges Fonctionnelles (CdCF) :

Exercer un contrôle de l’activité du panneau solaire situé à l’IUT de Mulhouse pour laisser libre service de ces informations à Mme.Ihssane Chtouki et à ses recherches :

  • Pouvoir récupérer, stocker et utiliser les donnés relatives au panneau solaire à distance.
  • Renvoyer toutes les valeurs des capteurs toutes les minutes entre 6h du matin et 22h.
  • Possibilité de mettre le système de mesure à l’extérieur.
  • Toutes les valeurs doivent être récupérées sous forme de tableau.

La réalisation complète du projet serra réalisée par les étudiants du département Génie Électrique et Informatique Industrielle.

 

Expression du besoin (bête à corne) :


Matériel

Description du matériel :

-La carte :

  • Une carte Arduino Yun :

 

La carte Arduino Yun est une carte Arduino à laquelle a été rajouté un processeur qui fonctionne sous Linux Linino, cette carte possède une connectivité Ethernet, WiFi, une mémoire RAM ainsi qu’une mémoire flash (dont une partie est occupée par la distribution Linux) et un lecteur de carte micro-SD. Pour notre projet nous avons choisi cette carte afin de pouvoir exploiter sa fonctionnalité Ethernet et mirco-SD.

-Les Capteurs :

  • Un capteur de température et d’humidité : Le DHT 22

Le DHT 22 est un capteur de température et d’humidité très précis, il peut mesurer une humidité qui varie entre 0 et 100% avec une précision de ± 2% et pour ce qui est des mesures de température, elle peuvent aller de -40 a +80°C  avec une précision de ± 0.5°C. Cette précision explique pourquoi nous avons fait le choix de ce capteur.

  • Un capteur de luminosité : Le TSL2591

Le TSL2591 est un capteur de luminosité il permet de mesurer une intensité lumineuse qui varie de 188 µLux à 88000 Lux. Cette information nous est nécessaire car grâce elle nous pouvons déterminer la production du panneau solaire en W/m².

Il faut également savoir que ce capteur est un capteur fonctionnant sous I²C. Le bus I²C permet de faire communiquer entre eux des composants électroniques grâce à trois fils : un signal de données (SDA), un signal d’horloge (SCL), et un signal de référence électrique (masse). Cette particularité nous obligera donc a utilisé les Pins 2 et 3 de l’arduino (la 2 pour le SDA et la 3 pour le SCL).

Pour tout savoir sur le protocole I2C nous vous invitons à vous rendre sur ce site.

  • Capteur de courant linéaire à effet hall : Le MR003-006.2

Ce capteur à effet hall nous permet de mesurer un courant de ±5A

Mais qu’est-ce que l’effet hall? Tout courant électrique traversant un champ magnétique continu B subit une force électromagnétique dont le sens est donné par la règle des trois doigts (force Laplace). Les trajectoires des charges du courant électriques sont donc déviées en présence de B. Il apparaît donc une d.d.p. (différence de potentiel) sur deux bornes du capteur, dite Tension de Hall. Pour savoir exactement comment fonctionne notre capteur nous vous invitons à consulter sa Datasheet ici.

 


Réalisation

Synoptique

 

Configuration de l’Arduino Yun et de la carte SD

La carte Arduino Yun peut être utiliser comme serveur, pour cela il suffit de créer un répertoire « /arduino/www/ » sur le carte SD, tout les fichier présent dans le répertoire « www » serons accessible en tapant l’adresse « http://10.92.11.25/sd/ » (adresse IP de notre carte) dans n’importe quel navigateur web. Pour cela nous avons créer les dossier directement sur la carte SD avec un ordinateur.

 

Code

Le Code complet est disponible en cliquant ici.

Configuration du TSL2591 : void configureSensor(void)

Le TSL2591 est paramétrable en fonction des conditions d’utilisation. Cette configuration ce fait au début dans une fonction appeler configureSensor(). Le capteur étant à l’extérieur, il est soumis au rayon du soleil et donc à une lumière assez forte, nous l’avons donc configurer pour qu’il ne soit pas trop sensible.

 Initialisation : void setup()

Dans le setup nous allons démarré la liaison entre les deux processeurs grâce à la fonction Bridge.begin(). La fonction FileSystem.begin() nous permet de communiquer avec Linino. La fonction dht.begin() permet de communiquer avec le capteur DHT22.

 

Récupération de la date et l’heure : String getTimeStamp() et String getDateStamp()

Les deux fonctions fonctionne exactement de la même façon, elle vont tout simplement récupérer l’heure et la date du système d’exploitation Linino.

Ecriture dans un fichier .csv : void loop()

Les données des capteurs doivent être écrit dans un fichier csv. Ce format permet de structurer du texte dans un tableau. Le principe est simple chaque ligne du texte correspond à une ligne dans le tableau. Pour créer des colonnes, il suffit de séparer le texte par un un point virgule. Ce Format est compatible avec Microsoft Excel.

Exemple :

 

Dans notre cas nous voulons un tableau par jour, et connaitre le température, l’humidité et l’irradiance toute les minutes entre 6h et 22h.

Dans un premier temps nous allons récupérer l’heure grâce à la fonction getTimeStamp(). Quand il est 6h nous allons créer le fichier grâce à la fonction FileSystem.open(). Nous devons indiquer le chemin ou le fichier doit être créer. Nous avons décidés d’utiliser la date comme nom du fichier mais nous devons modifier les slashs par des underscores. Nous récupérons la date grace à la fonction String getDateStamp() qui nous renvois une chaîne de caractères, pour faire modifier les slashs par des underscores nous devons concaténer la chaîne de caractères dans un tableau grâce à la fonction DateStr.toCharArray(). La structure de la fonction FileSystem.open() est FileSystem.open(const char*, int), donc nous devons concaténer CheminConst dans un tableau. Puisque le fichier n’existe pas encore, la fonction va le créer.

Dans un second temps nous allons écrire les mesures des capteurs dans le fichier toute les minutes jusqu’à 22h. Pour cela nous allons utiliser une boucle while et un compteur. Dans cette boucle nous récupérons les données des capteurs dans des variables indépendante. Pour acquérir les valeurs des capteurs nous utilisons les fonctions disponible dans la librairie proposé par le fabriquant. Puis nous créer une seule chaîne de caractères dataString.


Avancée du projet

Lors de nos première séances projet, nous avions un projet totalement différent, nous avions pour objectif de mettre en place un pilotage à distance du chauffage des salles du bâtiment A. Pour ce faire nous voulions nous baser sur les emplois du temps disponibles sur le site de l’UHA dans la rubrique salles GEII et ainsi optimiser l’utilisation du chauffage en fonction de l’utilisation des salles. Or après avoir réalisé une étude approfondie des besoins et avoir étudié plus en détails la façon dont sont codés les emplois du temps, nous avons appris que ce projet ne serrait pas réalisable car le système de chauffage de l’IUT était centralisé. Nous voila arrivé à la fin de la 3ème séance. Il nous faut donc un nouveau projet. Après concertation avec M.Steger nous avons pu dès lors trouver notre nouveau projet : Supervision d’un panneau solaire.

Dès ce moment nous avons été orientés vers l’idée de la création d’un serveur MQTT sa réalisation nous a demandé un grand nombre d’heures qui n’ont au final aboutie à rien car nous avons abandonné la réalisation de ce serveur lui préférant une page internet.

Ayant déjà la carte Arduino Yun nous avons pu réaliser nos codes pour les capteurs choisis, par chance, l’IUT disposait déjà d’un capteur DHT11 utilisant les mêmes bibliothèques que le DHT22 nous avons donc pu tester ce premier code. Après commande et réception des différents capteurs tout c’est très vite enchainé, les codes ayant été écrits en amont ont pu directement être testés avec succès.

A cette date la partie codage est finie, le seul aspect non abordé du projet est la possibilité de positionner le système de mesure à l’extérieur.


Conclusion

Nous avons pu, lors de ce projet nous servir des connaissances acquises lors de nos études, et les mettre à profit dans un but précis. Nous avons également pu découvrir ce qu’est la gestion d’un projet, faire le choix des éléments les plus adaptés, communiquer et travailler en équipe dans un but précis, faire face à des difficultés mais également gérer les délais. Nous avons pris du retard dans notre projet pour différentes raisons, tel que le délais de la réception des capteurs (que nous avons pu en partie contourner en écrivant les codes sans pouvoir les tester) mais également lors de la tentative de création d’un serveur MQTT qui au final n’a pas été créé ou bien lorsque nous avons passé 3 séances à travailler sur un projet non réalisable. Ces erreurs sont donc à garder en mémoire et à ne plus reproduire dans nos projets futurs.


Remerciements

Nous tenons à remercier M. De Sabbata pour sa patience, son aide et ses conseils pour les soudures qui ont du être réalisées sur les différents capteurs ainsi que pour le prêt d’une carte Arduino Yun sans laquelle ce projet n’aurait pas pu se réaliser.


Course en cours

Projet « Course en Cours » :

 


L’équipe ayant réalisée le projet :

Antoine KIENTZ (GMP)

Théo RIGHINI (GMP)

Nicolas LE FOLL (GEII)

Titouan RIVIERE (GEII)

 

 



Sommaire

I. Introduction

           II. Analyse fonctionnelle

           III. Voiture de Course

         IV. Projet d’innovation

        V. Avancé du projet 

 

 


 Introduction : 

Notre projet se déroule dans le cadre de « Course en Cours », c’est un concours durant lequel plusieurs équipes composées de 4 à 6 étudiants doivent durant une année scolaire, développer une voiture de course miniature, mais également créer un stand, développer un projet d’innovation et préparer une soutenance.

Course en Cours est un dispositif pédagogique original, centré sur les Sciences et la Technologie. Lors de ce concours, les participants montent leur écurie en utilisant les connaissances théoriques obtenues lors des enseignements dispensés dans leurs formations.

Nous avons donc à notre disposition tous les moyens de production et de fabrication du département GMP de l’IUT  de Mulhouse, ainsi qu’un accès à l’IUT Lab et à aux installations du département SGM.

La première étape était d’organiser l’équipe suivant le règlement du concours. Il a fallu définir différent poste :

  • Chef d’équipe : Nicolas LE FOLL
  • Ingénieur conception : Antoine KIENTZ
  • Ingénieurs fabrication : Antoine KIENTZ, Théo RIGHINI
  • Responsables essais : Titouan RIVIERE, Nicolas LEFOLL
  • Responsable style/design : Nicolas LE FOLL, Antoine KIENTZ
  • Responsable communication/sponsoring : Titouan RIVIERE, Théo RIGHINI

La première partie de ce projet concerne la création d’une voiture de course miniature (châssis, coque, train avant, etc…). Le moteur de la voiture est fourni par l’organisation du concours.

Les épreuves auxquelles nous allons participer sont les suivantes :

  • Course de vitesse
  • Arrêt au stand
  • Temps de réaction
  • Développement sur Catia (logiciel de CAO)

La première partie, réalisée par les élèves de GMP, concerne la création d’une voiture (châssis, train avant, roues, coque) en deux exemplaires, le moteur et la transmission étant fournie par l’organisation. Cette partie permettra à l’équipe de participer aux différentes courses. Antoine, élève en GMP, sera le membre de l’équipe qui participera à l’épreuve de CAO sur Catia.

Cette première partie sera réalisée par les élèves de GMP Antoine KIENTZ et Théo RIGHINI.

La seconde partie est un projet d’innovation qui s’inscrit directement dans le sujet du concours, il s’agit ici de développer/créer une application de « l’intelligence numérique » sous la forme d’un objet programmé répondant à la problématique de course en cours mettant en œuvre des capteurs , actionneurs et un traitement algorithmique de l’information.

Cette seconde partie quand à elle, est réalisée par Titouan RIVIERE et Nicolas LE FOLL, élèves de GEII.

 


 Voiture de Course :

  1. Conception du véhicule

La phase de conception a été la partie la plus longue à réaliser. En effet, celle-ci nous a demandée beaucoup de temps de réflexion, et de mises en communs des idées, avant d’arriver à des solutions idéales et réalisables.

Nous nous sommes donc réunis devant un tableau, et avons exposés diverses solutions qui nous semblants intéressantes. Ensuite, nous avons évalués les points forts et les points faibles de chaque solution, pour décider de la plus idéale.

  1. Phase de fabrication et de montage

La phase de fabrication a été séparée en plusieurs parties.

Le châssis

Le châssis a été produit à l’aide d’une imprimante 3D, avec une matière appelée PLA. Cette imprimante est une SIGMAX BCN3D, disposant d’un plateau format A3. Elle est équipée d’un système de double extrusion indépendante, permettant des impressions simultanées, en mode miroir (symétrie) ou duplication.

Au fil du temps, notre solution a souvent évoluée du fait de nouvelles contraintes inattendues ou simplement afin de simplifier l’ensemble. Nous sommes passés par trois principaux designs de châssis, dont deux qui ont été réalisés.

Voici les trois versions par lesquelles nous sommes passés :

Châssis V1 :

Cette version n’a pas abouti, elle était restée au stade de concept. Nous l’avons conçue selon nos premières idées. La forme globale du châssis n’a pas été beaucoup modifiée.

Nous avions imaginé des rebords chanfreinés afin d’y caler la carrosserie, cependant cela n’était pas concluant. Nous n’avions pas encore imaginé la fixation de la carrosserie, du moteur et de la batterie, ainsi que tout l’ensemble train avant.

Châssis V2 :

 

Sur cette deuxième version, nous étions premièrement partis sur la mise en place de trois plots de maintien et mise en position de la carrosserie (deux latéraux, un à l’avant) :

 

Nous avons finalement opté pour une méthode plus simple qui sera expliqué lors de la présentation du châssis V3.

Les points de fixation de ce châssis sont les suivants :

 

Pour la batterie, la solution retenue  est une bande de fixation dite « scratch » qui entoure la batterie, étant donné que le bloc moteur/batterie, la châssis et la coque doivent être démontable en moins de deux minutes (imposé par l’organisation). La bande permet un maintien réglable et  un démontage rapide. Nous avons donc créé une encoche dans le châssis afin de permettre le passage du scratch.

 

 

Pour le moteur, nous avons mis en place deux bossages percés épousant la forme prévue à cet effet déjà présente sur le bloc moteur. Lors du montage, nous utiliserons un système de fixation vis/rondelle/écrou.

 

Châssis V3 : 

Pour cette troisième et dernière version du châssis, nous avons apporté plusieurs modifications majeures.

Premièrement, nous avons ajouté une deuxième encoche pour la fixation de la batterie (logement du scratch) afin d’assurer un maintien en position optimal. Nous avons également agrandi les encoches car l’imprimante 3D plaçait un matériau de  support dans ceux-ci,  qui était difficile à enlever en post-impression, ce qui a résulté d’une détérioration du logement.

Nous avons mis en place une rainure dans le « mur » qui guide la batterie, directement en sortie du moteur. Cette modification a été réalisé car le câble qui relie la batterie au moteur est plus court que sur les mesures réalisé sur les plans CATIA fournis par l’organisation. Par conséquent, il est impossible de passer  le câble sous la batterie. Nous l’avons donc passé par le côté. De plus, nous avons placé un arrêt au bout de la batterie afin de l’arrêter en translation en direction du train avant.

 

 

Au niveau des points de fixation de la coque, nous avons réalisé quatre trous répartis de manière égale sur le châssis, dans lesquels nous allons implanter quatre tiges métalliques de hauteur supérieure à la coque. Une fois la coque posée sur le châssis, nous placerons une goupille pour pouvoir arrêter la coque en translation et l’empêcher de se déloger.

Il a également fallu prévoir le passage de fil guide de la piste Course en Cours sur tout le long du véhicule. Nous avons donc créé un morceau rapporté que nous plaçons dans un logement sous le châssis.

 

Dernièrement, nous avons déduit que le train avant devait être réglable. Étant donné que la voiture n’est pas dirigeable, nous ne pouvons pas nous permettre d’avoir un défaut de trajectoire. Il faut qu’elle ait un mouvement rectiligne uniforme. C’est pourquoi nous avons inclus deux trous oblong au niveau du train avant afin d’assurer la fixation de l’ensemble fusée (guidage de l’axe) ainsi que son réglage.

 

Voici un comparatif en photos du châssis V2 et V3 :

 

Vidéo de l’impression du châssis :

 

La fusée

La fusée est le nom donné à l’ensemble fixé sur le châssis ayant pour fonction principale de guider l’axe avant en rotation.

Nous avons opté pour une réalisation en usinage conventionnel d’un ensemble composé de deux pièces. Nous avons choisis de réaliser ces pièces en usinage dans un brut d’aluminium car ces pièces devraient disposer d’alésages (H7) pour accueillir des bagues en bronze, afin de réaliser un guidage parfait de l’axe. Ces pièces apportent également de la rigidité au véhicule.

Axe avant :

L’axe du train avant a été usiné à l’aide d’un petit tour conventionnel. Cette étape a été minutieuse car il fallait par moment charioter l’axe sur 30mm en réalisant un diamètre 3mm. La tige était donc fortement soumise à la flexion. Il a fallu être précis lors des phases d’usinages et faire attention à l’usure des plaquettes carbures car l’outil chauffait beaucoup.

 

L’axe est une pièce de révolution disposant de trois diamètres différents :

  • Diamètre 6mm : c’est le diamètre non fonctionnel de l’axe, il est présent au centre de la fusée et n’est soumis à aucune contrainte particulière.
  • Diamètre 4mm : c’est le diamètre qui est monté glissant dans les bagues en bronze H7, la rotation optimale repose sur ce diamètre. Afin d’éviter quelconque frottement entre la roue et la fusée, ce diamètre dépasse d’1mm de la fusée et fait donc office de butée pour la roue.
  • Diamètre 3mm : c’est le diamètre aux extrémités de l’axe, il est fileté en M3x35 (mise en place d’un écrou au bout) et c’est lui qui accueille les roues.

Les roues :

Les roues ont été réalisées en impression 3D. Elles sont composée d’une ou plusieurs jantes (cela dépend du train avant ou arrière) et d’une bande roulante (polyuréthane) faisait office de pneumatique.

 

La jante arrière est décomposée en deux parties. La première partie qui contient le trou diamètre 3mm de passage de l’axe, et la deuxième partie contenant un carré de 4.5×4.5mm, carré présent sur l’axe moteur et ayant pour but d’entraîner les roues arrières.

Ces deux parties s’emboîtent l’une dans l’autre et englobe la bande roulante. La bande roulante est adaptée à cette jante et réalisée spécialement selon ses dimensions.

 

Les roues avant fonctionnent sur un principe similaire. Elles sont composées d’une jante disposant d’un trou diamètre 3mm de passage de l’axe, et d’une bande roulante également réalisée sur mesures.

 

La coque :

Nous voulions cette coque avec une allure aérodynamique, style supercar futuriste. L’esquisse a été pensée comme le reste du véhicule, chacun a donné son avis et cela a abouti à des croquis.

Une fois l’alllure principale du véhicule trouvée, nous avons réalisé sa conception sur CatiaV5. Nous nous sommes alors tournés vers le département SGM afin de leur demander des conseils sur les techniques de thermo-moulage.

Sur les conseils de Mr. ANTHOINE, nous avons dépouillé (5°) la coque pour faciliter le démoulage et l’avons rayonné (5mm) pour éviter les problèmes liés aux angles vifs lors du démoulage. Le plateau de leur machine de thermo-moulage n’étant pas assez grand, nous avons donc recours à l’aide du Lycée Théodore DECK de Guebwiller qui ont une machine capable de réaliser des pièces de telles dimensions (300×120).

 

 

La fabrication sera réalisée soit en ABS (épaisseur 1,5mm, plus simple à peindre mais moins résistant) soit en PVC (épaisseur 1mm, transparent donc plus compliqué à peindre, plus résistant aux chocs).

La matrice de moulage a été imprimée en deux parties, puis collée pour le moulage.

Aujourd’hui, il reste à mouler la coque au lycée Théodore DECK, et réaliser les quatre barres de fixations de la coque sur le châssis en tournage.

Conclusion :

Grâce à ce projet, nous avons pu suivre un projet entier, de sa conception à sa fabrication. Nous avons pu appliquer les compétences acquises lors des deux années de DUT, en conception mécanique mais également lors des cours de CAO.

Nous avons pu développer nos qualités de travail en groupe mais également nos capacités de réflexions. Les problèmes rencontrés ont été des challenges que nous avons pu relever en appliquant encore une fois les connaissances du DUT GMP.

Pour finir, nous avons pu utiliser les connaissances d’usinages acquises lors de la première année.

 

 


 Projet d’innovation :

 

La seconde partie de ce projet comme définit dans l’introduction, s’inscrit directement dans l’objectif du concours. Nous avons donc choisi de « créer » une voiture dite connectée, ce qui veut dire que l’on doit pouvoir accéder à un certain nombre de capteurs et pouvoir agir sur les effecteurs présent dans la voiture.

Analyse fonctionnelle

Cahier des charges fonctionnel :

Intégrer un système composé de capteurs et d’effecteurs dans une voiture télécommandée et envoyer ces informations en temps réel via une IHM  :

  • le système doit comporter des capteurs comme de température, humidité, accéléromètre et doit être assez petit pour rentrer dans une voiture télécommander.
  • Échange des informations en temps réel.
  • Avoir une IHM pour pouvoir visualiser ces données et agir sur les effecteurs.

 

Bête à corne :

 


Réalisation Matériel:

Dans un premier temps, nous avons choisi un Arduino Yun, qui est composé d’un microcontrôleur car il permet d’un part une intégration facile dans la voiture et de gérer un certain nombre de capteurs et d’effecteur, et d’un autre part de gérer en parallèle grâce un processeur spécifique une page web.

 

Architecture Arduino Yun.

En effet, le Yun possède deux processeurs différents et donc deux environnements permettant de gérer dans une première partie l’acquisition des données en langage C (environnement Arduino) qui par le bridge sera envoyé au noyau Linux, pour exécuter des protocoles HTTP et d’interagir avec notre IHM web.

 

 

 

Les capteurs choisis sont les suivants :

  • Double capteur de température

Le premier capteur est installé à l’extérieur de la voiture dans le but de connaitre la température ambiante. Le deuxième, collé au moteur à courant continu, indiquera la température de ce dernier afin que nous puissions agir dessus.

 

 

 

 

 

  • Capteur de luminosité

 

Situé sous le toit de la voiture, le capteur servira à capter la luminosité ambiante et agira sur les phares.

 

 

  • Capteur de chocs

 

Collé au niveau du capot, le tilt sensor envoie une impulsion en cas de chocs (utilisable pour un arrêter le moteur par exemple).

  • Accéléromètre

 

 

Les actionneurs :

Leds : Rajout de leds au niveau des phares.

Les leds peuvent-être dirigées de différentes façon : soit par une requête directement envoyée de la page web par un utilisateur, soit si la luminosité tombe à moins de 40 lux

Ventilateur : Comme les leds, s’actionne à l’aide d’une requête ou si la température du moteur dépasse les 60 degrés Celcius.

 

Voici les codes en C commentés :

 

 

 


Supervision :

 

Pour la réalisation de la supervision, nous avons dû créer une IHM permettant de visualiser toutes les données acquises ainsi que d’envoyer des « ordres » à l’Arduino. Pour réaliser cette IHM nous avons choisi d’utiliser le format web, rendu possible grâce à l’Arduino Yun, et donc nous avons écrit cette IHM en Hyper Text Markup Language (HTML) qui est un langage de balisage conçu pour représenter les pages web, uniquement structurel.

Cette IHM web est constitué de deux parties :

  • La première page est l’acquisition des capteurs :

 

 

  • La deuxième page permet d’agir directement sur les effecteurs via des boutons.

Après création de cette page web, il nous faut maintenant pouvoir dialoguer avec l’Arduino.

C’est donc pour cela que l’on a utilisé le Javascript, qui est un langage de programmation de script orienté objet qui permet de rendre les pages web dynamique autrement dit interactive avec l’utilisateur.

 

 

Hors ce langage ne s’exécute seulement que sur le client et ne permet donc aucun échange avec le serveur. C’est donc pour cela que l’on a utilisé le protocole Hypertext Transfer (HTTP) et plus précisément le XMLHttpRequest qui est un objet du navigateur accessible en Javascript permettant d’obtenir des données du serveur au format XML, JSON, ou HTML.

 

C’est donc grâce à ce protocole que l’on à créée une fonction type qui permet de recevoir non seulement des données mais aussi envoyer des « ordres » à l’Arduino qui seront ensuite traités pour gérer les effecteurs comme expliqué dans la première partie.

 

 

Dans la page « capteurs », les requêtes vont se lancer automatiquement toutes les secondes sans actions préalable de l’utilisateur.

 

 

Puis la page « effecteurs », elles seront lancées par l’utilisateur directement via l’appui de boutons.

 

 

 


Conclusion :

Malgré quelques problèmes rencontrés, on à réussis à remplir nos objectifs. En effet, le calibrage des capteurs n’à pas été facile, de même pour mettre en fonctionnement l’Arduino à cause de la configuration de base.

Maintenant après avoir terminé ce projet il y plusieurs d’amélioration possible :

  • Agir directement sur le moteur avec le capteur de choc.
  • Gérer les phases d’accélération grâce au capteur d’accélération.
  • Avoir la vitesse en temps réel.

 

 

 


Documents Annexes :

 

Code en C Arduino :

code HTML/CSS et JS :

ProjetCourseEnCour

 

 

 

 

 

 

 

….