Course en Cours Carrosserie

Sommaire

  1. Présentation du projet
  2. Cahier des charges
  3. Conception
  4. Coût financier
  5. Usinage
  6. Conclusion

I/ Présentation du projet :

Course en cours est une compétition annuelle dont le but est d’imaginer, concevoir, construire et faire courir un véhicule doté, d’une motorisation électrique. Il n’y a pas de direction car la voiture ne devra rouler qu’en ligne droite. Différentes épreuves seront proposées tels qu’une course de rapidité sur 15 mètres, le temps de réaction (déclencher le départ du véhicule le plus rapidement possible), ainsi qu’une épreuve d’arrêt au stand

Dans le cadre de notre projet différentes tâches sont demandées. La collaboration entre 2 étudiants GEII ET 6 étudiants GMP sera nécessaire afin de mener à bien le projet.

Le travail des étudiants GMP et GEII est répartie en 4 groupes :

-Conception et réalisation des roues (2étudiants GMP)

-Conception et réalisation du châssis (2étudiants GMP)

-Conception et réalisation de la carrosserie (2étudiants GMP)

-Connectique et liaisons des systèmes électronique du moteur (2étudiants GEII)

Notre partie consiste en la réalisation de la carrosserie, pour cela nous devons respecter un cahier des charges imposé par le règlement de course en cours

Dans ce projet nous allons tout d’abord étudier le sujet avec l’analyse du cahier des charges, puis concevoir notre coque à l’aide du logiciel inventor et enfin fabriquer notre carrosserie en utilisant le procédé de stratoconception et thermoformage ainsi que du prototypage rapide pour réaliser l’aileron

II/ Cahier des charges
1)Diagramme des prestations

2)Diagramme des interacteurs

3)Tableau de caractérisation

Description fonctionnelle : Diagramme FAST

Le diagramme FAST (Function Analysis System Technic) indique comment une fonction de service est réalisée à l’aide de fonctions techniques. Il met en évidence une hiérarchie entre les fonctions techniques.

III) Conception

Choix de l’échelle du modelé

Création des plans nécessaire à la conception

Modélisation de l’aileron en 4 pièces

IV) Coût financier

Pour la partie carrosserie les coûts seront assez faibles, ils correspondent uniquement à l’achat des matières premières comme les plaques de medium pour stratoconception ainsi qu’à la plaque de pvc pour thermoformage, et de la visserie.

Ce qui fait un total de 44,4 euros TTC

V) Usinage

Usinage du moule en stratoconception

La stratoconception est un procédé de prototypage rapide qui consiste à décomposer la pièce en un ensemble de couches élémentaires appelées strates de les usiner et ensuite les assembler afin d’obtenir la pièce entière.

Sur les photos ci contres vous pouvez voir notre modèle CAO que nous avons découpé en 10 couches de 9 mm. Que nous avons ensuite usiné puis assemblé en les collant   

Prototypage rapide de l’aileron

Prototypage rapide des logos

Assemblage coque et aileron

  1. En raison de la situation actuelle nous n’avons pas réussis à thermoformer notre coque qui aurait par la suie dû être peinte et assemblé à l’aide de 4 goupilles sur le châssis de la voiture.

Ce projet nous a tout de même permis de travailler en équipe tout en collaborant avec les autres groupes du projet course en cours afin que tout le monde puisse respecter son cahier des charges. Grace à ce projet nous avons également découvert la démarche à effectuer en passant du cahier des charges, le choix de solutions technique, la conception ainsi que la fabrication pour pouvoir mener un projet à bien.


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


Trackeur GPS pour la cartographie de locaux

Tuteurs: Stéphane BAZEILLE et Nicolas VERRIER

Groupe: Yassine AMIAR et Farès KHALFALLAH

Sommaire :

I) Présentation générale du projet

  • Contexte et principe
  • Liste de matériel et logiciel utilisé
  • Diagramme de bête à cornes
  • Diagramme pieuvre

II) Gestion et réalisation du projet

  • Exploitation et activation des capteurs
    • GPS
    • Caméra
    • Centrale inertielle
  • Programmation
    • Coordonnées GPS
    • Photos
    • Interface
  • Finalisation
  • Difficultés rencontrées

III) Conclusion

  • Remerciements

I) Présentation générale du projet

  • Contexte et principe

Le projet trackeur GPS pour la cartographie de locaux a pour objectifs grâce à un dispositif créées par nos soins d’enregistrer le parcours fait lors de déplacement, dans notre cas nous avons parcouru l’enceinte de l’IUT. Suite à cela les informations du parcours sont enregistré et retranscrites sur un site internet ainsi que sur un fichier dans la mémoire de la Raspberry PI. Pour mettre à bien ce projet nous sommes compose d’un binôme.

Le principe est de retracer le trajet parcouru par l’utilisateur. Pour ce faire, il faut tout d’abord commencer par étudier les comportements des différents capteurs ( GPS, Centrale Inertielle, Caméra), puis de la carte Raspberry PI. Une fois ces tâches achevées, il faut programmer chaque capteur dans un programme différent afin d’arriver à ses fins sans risques de perdre toute la progression sur une petite erreur. Pour finir, il faut créer une interface afin de pouvoir lancer l’application et visualiser quelques données.

  • Liste de matériel et logiciel utilisé:
    • Raspberry PI
    • Batterie externe
    • Caméra
    • Boîtier
    • Ecran
    • Langage Python
    • GPS
  • Diagramme bête à cornes
  • Diagramme pieuvre

A partir du diagramme pieuvre on réalise le tableau des fonctions pieuvre le tout en détaillant chaque fonction principale dite FP dans notre cas seulement FP1 mais également les fonctions contraintes dite FC qui vont de FC1 à FC7 dans notre cas.

II) Gestion et réalisation du projet

  • Exploitation et activation des capteurs
    • GPS

Pour commencer, nous avons tout d’abord pris connaissance du module GPS dont nous disposions.

Après avoir pris connaissance du GPS, il a fallu le configurer sur la Raspberry PI afin de pouvoir récupérer les coordonnées sur la carte.

Pour cela, il a tout d’abord fallu installer le module GPSD grâce à cette ligne de commande:

sudo apt-get install gpsd gpsd-clients python-gps

Puis désactiver le gps:

sudo systemctl stop gpsd.socket

sudo systemctl disable gpsd.socket

Ensuite le réactiver :

sudo systemctl enable gpsd.socket

sudo systemctl start gpsd.socket

Finalement, nous avons pu visualiser les données obtenues grâce au GPS:

gpsmon

Voici ce que nous obtenons:

Nous remarquons que grâce au GPS, nous obtenons la date, l’heure ainsi que les coordonnées longitude, latitude et l’altitude. Nous verrons plus tard comment exploiter ces données pour notre projet.

  • Exploitation et activation des capteurs
    • Caméra

Pour régler la caméra, il faut tout d’abord l’autoriser à communiquer avec la Raspberry Pi en la paramétrant en rentrant la commande:

sudo raspi-config

Puis ensuite paramétrer ainsi:

Une fois ceci fait, nous pouvons brancher la PiCaméra à la Raspberry PI puis redémarrer le système.

Nous verrons plus tard en détail le programme qui permet de photographier avec la PiCaméra.

  • Exploitation et activation des capteurs
    • Centrale inertielle

Afin de nous repérer et pouvoir guider l’utilisateur à l’intérieur d’un bâtiment de l’IUT, nous avons pensé à utiliser une centrale inertielle qui calculerait la trajectoire lorsque l’on perd le signal GPS car il est impossible d’obtenir un signal GPS au sein d’un bâtiment avec un tel module GPS.

Nous avons tout d’abord essayé d’étudier la précision du capteur. Pour ce faire, nous avons placé le capteur sur un banc afin de pouvoir effectuer des trajectoires droites dans une seule direction verticale et horizontale (x ou y). Nous avons donc branché le capteur aux bonnes entrées de la Raspberry PI grâce à des câbles puis créer un petit programme afin de relever les données obtenues avec ce capteur.

Suite à un changement de groupe et donc une baisse d’effectif dans le groupe de ce projet, nous avons été contraints d’abandonner cette partie du projet…

  • Programmation
    • Coordonnées GPS

Dans cette partie, nous verrons les différents programmes utilisés pour ce projet. Commençons par le GPS.

Pour le GPS, nous devions tout d’abord récupérer les données captées par le GPS (Longitude, Latitude) grâce à ce programme trouvé sur internet que nous avons adapté à nos beoins:

port = '/dev/ttyAMA0'  #Sélection du port du GPS
gpsd = gps(mode=WATCH_ENABLE|WATCH_NEWSTYLE)

list_lat = []    #création de listes pour stocker les coordonnées
list_lon = []
x = []           #Coordonnées X
y = []           #Coordonnées Y
D = []           #Distance parcourue

i=1

try:
    while True:
        report = gpsd.next() #
        if report['class'] == 'TPV':
            lat = getattr(report, 'lat', 0.0)  #Récup latitude
            lon = getattr(report, 'lon', 0.0)  #Récup longitude
            Temps = getattr(report, 'time','') #Récup temps

Cependant, les coordonnées récupérées de cette manière sont des coordonnées brutes avec lesquelles nous ne pouvons pas nous repérer et tracer le trajet effectué. Pour remédier à cela, nous devons convertir les coordonnées GPS en coordonnées cartésiennes:

calc_lat = (6371*cos(float(lat))*cos(float(lon))) #conversion latitude
calc_lon = (6371*cos(float(lat))*sin(float(lon))) #conversion longitude
list_lat.append(calc_lat) #stock les données converties dans les listes
list_lon.append(calc_lon) 
#Conversion des données converties en points cartésiens X et Y 
x1 = float(list_lat[0]-list_lat[i-1])
y1 = float(list_lon[0]-list_lon[i-1])
x.append(x1)
y.append(y1)
#Calcul de la distance parcourue grâce à un calcul de distance entre deux vecteurs qui calcule la distance entre le point actuel et le point précédent puis qui s'additionne au fil du temps.
calc_dist = sqrt((x[i-1])**2+(y[i-1])**2)
D.append(calc_dist)

Ensuite, nous affichons les valeurs que nous avons calculé:

print "Coordonnees x : ",x[i-1]
print "Coordonnees y : ",y[i-1]
print "Distance parcourue : ",D[0]+D[i-1]," m"

i=i+1  #Incrémentation pour mesure d'un nouveau point de position

Pour avoir le tracé du parcours effectué, nous devons tracer un « graphique » des points x et y et l’afficher ensuite:

plt.plot(x,y)  #Traçage d'un point en fonction de x et y
time.sleep(1)  #Attente d'une seconde pour recommencer la boucle
os.system("clear")  #Actualisation de la fenêtre d'affichage

Nous affichons simplement le tracé final une fois que nous fermons l’application:

plt.show()     #Affichage du tracé

Grâce à ce programme simple, nous pouvons déjà obtenir un tracé du parcours effectué, avec en temps réel la distance parcourue et la position cartésienne x et y. Cependant, les coordonnées obtenues contenaient beaucoup de chiffres après la virgule, pour y remédier nous avons fait ainsi:

xi=str(x[i-1])
yi=str(y[i-1])
di=str(D[0]+D[i-1])
#Ensuite nous affichons seulement les 6 premiers caractères de ces données:
print "...",xi[0:5]
print "...",yi[0:5]
print "...",di[0:5]
  • Programmation
    • Photos

Pour la prise de photos lors du trajet, nous avons fait un programme simple de prise de photos. Ceci est un programme pour prendre 5 photos à une intervalle de 30 secondes entre chaque photos. Il faut ensuite l’adapter à nos besoins, c’est-à-dire, prendre des photos du début du trajet jusqu’à la fin.

from picamer import PiCamera #Importation des librairies nécessaires
from time import sleep

camera = Picamera() #Choix de la caméra

camera.resolution = (1024,768) #Choix de la résolution de la caméra
camera.rotation = 180  #Rotation de la caméra à 180° selon sa position car elle est placée à l'envers

i=0
while i<5:
      #Choix de la direction des photos
    chaine1=('/home/pi/Desktop/Photos_projet/image%d.jpeg')%i
      #Prévisualisation de la photo
    camera.start_preview(fullscreen = False, window = (50,50,640,480))
    sleep(1.5) #Attente de 1,5 seconde pour la visualisation
    camera.capture(chaine1) #Prise de la photo
    camera.stop_preview() #Arret de la visualisation
    print ('photo numero ', i+1, 'prise')
    i=i+1      #Incrémentation du numéro de la photo
    sleep(30)  #Attente de 30s pour la prochaine photos

Une fois ce programme adapté à nos besoins, nous l’ajoutons au programme principal. Pour notre cas, il fallait le rajouter au programme principal, nous avons donc choisi cette solution:

j=0
#Effectuer cette tâche uniquement lorsque i est un multiple de 30 (soit toutes les 30 secondes)
if i%30==0 :  
    chaine1=('/home/pi/Desktop/Photos_projet/image%d.jpeg')%i
    camera.capture(chaine1)
    j = j+1 #Comptage du nombre de photos prises
  • Programmation
    • Interface

Pour une question d’esthétique, nous créons une interface afin de visualiser le tout sur une seule fenêtre. Nous utilisons ici la librairie Tkinter fin de la créer. Voici le programme crée pour l’interface:

from Tkinter import*

fenetre = Tk()
fenetre.title('Trackeur GPS')  #Titre de la fenêtre d'interface

 #Création du label fenetre qui contiendra les objets (frame) 
champ_label = label(fenetre)  
cadre = Frame(fenetre, width=300, height=150, borderwidth=1)
cadre.pack(fill=BOTH)

 #Création du premier 'frame' qui contiendra du texte
pos_x = Frame(fenetre, width=20, height=50, borderwidth=1)
ligne_texte = Label(pos_x, text=("position x = "+str(x[i-1])),width=30
ligne texte.pack(side="left")
pos_x.pack(fill=BOTH)

 #Création du deuxième 'frame' qui contiendra du texte 
pos_y = Frame(fenetre, width=20, height=50, borderwidth=1)
ligne_texte2=Label(pos_y, text=("Position y = "+str(y[i-1])), width=30)
ligne_texte2.pack(side="left")
pos_y.pack(fill=BOTH)

 #Création du troisième 'frame' qui contiendra du texte 
dist = Frame(fenetre, width=20, height=50, borderwidth=1)
ligne_texte3=Label(dist, text=("Distance parcourue = "+str(D[0]+D[i-1])+" m"), width=30)
ligne_texte3.pack(side="left")
dist.pack(fill=BOTH)

#Création du quatrième 'frame' qui contiendra le nombre de photos prises depuis le début du trajet
nb_ph = Frame(fenetre, width=20, height=50, borderwidth=1)
ligne_texte4=Label(dist, text=("Photos prises : "+str(j)), width=30)
ligne_texte4.pack(side="left")
dist.pack(fill=BOTH)

 #Création d'un bouton 'Quitter'
Bouton_Quitter = Button(cadre, fg="red", text = "quitter", command = fenetre.destroy
Bouton_Quitter.pack(side="right")

champ_label.pack()

fenetre.update() #Actualisation de la fenêtre

Une fois tous ces programmes achevés, nous les mettons ensemble sur un seul programme afin d’avoir la totalité de l’application sur un seul programme, ce qui nous permettra de lancer un trajet et de l’arrêter lorsqu’on le souhaite.

  • Finalisation

Le système terminé, il ne fonctionne malheureusement pas comme on le souhaiterait. En effet, l’interface ne fonctionne pas comme prévu car lorsque les positions se mettent à jour, l’interface précédente reste présente et les nouvelles s’accumulent en dessous de celle-ci.

De plus, le module GPS que nous utilisons n’est pas très stable au vu de sa position dans le boîtier car il est « enfermé » ce qui crée des perturbations et donc fausse les données du tracking.

  • Difficultés rencontrées

Nous avons rencontré plusieurs difficultés au cours de ce projet. Premièrement, nous ne connaissions rien à propos de la Raspberry PI, ce fut pour nous une très bonne découverte.

De plus, le changement de groupe nous a contraint à devoir abandonner une partie du projet. Cela nous a aussi quelque peu ralenti.

Le module GPS met beaucoup de temps pour capter des satellites lors de la mise en tension. Ceci est encore plus ralenti lorsque le ciel est couvert.

III) Conclusion

Pour conclure, malgré que le projet ne soit pas fonctionnel à 100% et ne fonctionne pas comme nous le voudrions, nous avons beaucoup avancé et il nous a vraiment plu car il était très agréable à réaliser et il nous a permis de développer des compétences en programmation ainsi que de découvrir ce qu’est le Raspberry PI et toutes ces fonctionnalités. Il nous a aussi permis d’effectuer un agréable travail d’équipe, ce qui est très intéressant.

  • Remerciements

Nous tenons à remercier tout d’abord M.VERRIER Nicolas et M.BAZEILLE Stéphane non seulement pour nous avoir aidé mais également guidé tout au long du projet. Nous tenons à remercier également M.DE SABBATA qui nous a laissé accès à l’IUT LAB sans modération.


Système de vidéosurveillance autonome


  • Présentation du projet
  • Présentation des composants
  • Etude du projet
  • Présentation de l’aspect technique
  • Réalisation du projet
  • Conclusion
  • Remerciements

Présentation du projet

Le projet consiste à mettre en place un système de vidéosurveillance à l’extérieur qui sera autonome. Il faudra placer le système dans un endroit propice au soleil car celui ci sera alimenté grâce à l’énergie solaire. Ce système sera munit d’un boitier comportant le système ainsi que de la caméra et d’un petit panneau solaire. Pour ce projet, nous utiliserons un Raspberry Pi 3, un Witty Pi 2, une caméra, un panneau solaire, des capteurs et un ordinateur portable pour la partie de programmation.

Nous avons donc dans un premier temps, il fallait faire l’étude du sujet en réalisant plusieurs diagrammes, ensuite nous avons pu commencer la programmation en même temps que la création du boitier. Pour la suite, il a fallu se concentrer sur la détection de mouvement. Pour finir, nous avons réalisé une étude énergétique du projet, par rapport à la batterie.


Présentation des composants

En ce qui concerne les composants utilisés : nous utiliserons un Raspberry Pi 3, un Witty Pi 2, une caméra, un panneau solaire, des capteurs et un ordinateur portable pour la partie programmation.


Etude du projet

Au cours de cette étape du projet il était important de savoir sur quoi nous allions travailler, pour cela nous avons réaliser un certains nombre de diagrammes :

Une fois que les différentes tâches ont été déterminé nous nous sommes scindés en 2 groupes pour avancer en parallèle :


Présentation de l’aspect technique

Dans un premier temps nous nous sommes concentré sur l’aspect programmation du Raspberry Pi, notamment en élaborant un programme de redémarrage automatique du Raspberry Pi a l’aide du module Witty Pi, de cette façon nous pouvons contrôler la fréquence des prises de vue. Ensuite nous avons étudier le stockage nécessaire et le poids des photos pour optimiser le stockage des photos, un programme peut être activer pour supprimer les anciennes photos automatiquement (il est possible de stocker 1500 photos en Full HD). Nous avons ajouter les programme crée au démarrage du Raspberry Pi ce qui nous permet de rendre le système entièrement autonome d’un point de vue prise de photo.

Par la suite nous avons ajouté un système de détection de mouvement, ce système est pleinement fonctionnelle mais nécessite cependant une alimentation constante en énergie et cela sort de la quantité d’énergie dont nous disposons avec notre batterie actuelle (2000 mAh). Le flux vidéo peut aussi être accessible via internet si il y a une nécessité de contrôler la zone a distance.

Dans un deuxième temps nous avons étudier la partie énergétique du projet, notamment la consommation du Raspberry Pi et le rendement du panneau solaire. Avec une partie de 2000 mAh tel que la notre nous obtenons une autonomie théorique de 48 minutes, a cela nous devons ajouter l’usure de la batterie, nous avons donc du optimiser la consommation d’énergie pour que le système puisse être autonome le plus longtemps possible notamment la nuit ou en cas d’ensoleillement faible. A propos du temps de charge de la batterie, nous avons calculé un temps de charge de 4 H (Capacité batterie  / Puissance du chargeur = 2000/500 = 4 heures de charge)

Pour finir nous avons réalisé un boitier pour le Rasberry et le matériels électroniques ( batterie … ) afin d’avoir un support et une protection pour cette partie. Ensuite nous avons fixé le panneau solaire puis nous avons ajouté une barre réglable afin de choisir l’angle qui permettra au panneau de recevoir le meilleur rendement énergétique et d’alimenter au mieux la Raspberry.


Réalisation du projet

Au cours de la réalisation le groupe a été scindé en deux, une partie sur la programmation du Raspberry Pi et une autre sur la réalisation du boitier.

Dans la partie programmation nous avons utilisé le langage Python ainsi que l’environnement de travail Thonny Python 3. Les scripts était ensuite exécuter au démarrage avec le fichier rc.local.

En parallèle, le groupe occupé à la création du boitier a utilisé le logiciel CorelDRAW pour la réalisation de celui-ci, puis nous avons utilisé la découpeuse laser pour la créer.

Une fois le boitier réalisé, nous nous sommes attelé à la création d’un support pour le panneau solaire. Celui ci se devait d’être adaptable notamment en ayant pour contrainte la possibilité de changer l’inclinaison du panneau. Pour se faire nous avons opter pour un support en bois en deux parties, une partie sur le panneau solaire et une autre sur le sol, le tour relié par une charnière et avec la présence d’une crémaillère sur la partie basse du support. Ainsi l’angle du panneau peut être changer a tout moment.


Conclusion

Pour conclure, nous avons rencontré quelques problèmes notamment avec la batterie qui ne chargeait plus. Lorsque l’on voulait la charger cela prenait également beaucoup de temps donc nous ne pouvions que réaliser les essais lorsque la Raspberry était alimentée par l’ordinateur.

Nous avons un code python servant à commander la caméra, la prise de photo et ses différents paramètres comme la résolution et la luminosité. Ainsi que pour l’enregistrement de l’image à un endroit spécifique du raspberry, et un autre pour la gestion des photos en effaçant les plus anciennes, de cette façon nous pouvons garder un nombre défini de photos.

Ensuite, nous avons ajouté ces deux fichiers pythons au lancement grâce au fichier rc.local. Ce fichier permet d’exécuter les deux programmes au lancement du raspberry et en arrière-plan, et cela en moins de 30 secondes.

Nous avons géré la fréquence des prises grâce au module Witty Pi2. Grâce à ce module nous pouvons définir quand le raspberry s’allume ou s’éteint et ainsi gérer l’énergie.

Malgré quelques soucis, le but du projet a été atteint et le système fonctionne très bien. Dès que quelqu’un passait devant le capteur, le système prenait une photo. Pour la fiabilité du projet, nous conseillons de choisir une batterie avec une meilleure capacité et un plus grand panneau solaire pour la recharger.

Au final, nous avons un programme autonome et fonctionnel de prise de photos en milieu extérieur ou intérieur avec gestion de stockage d’énergie.


Remerciements

Nous souhaitons remercier nos professeurs :
– M. Verrier Nicolas
– M. Bazeille Stephane

Ainsi que les personnes suivantes pour leur aides :
– M. De Sabatta Christophe

Nous les remercions pour leurs aides et leurs conseils dans ce projet.


Trieuse/compteuse de monnaie

Sommaire 

  • Présentation du projet 
  • Présentation du matériel utilisé 
  • Étude du projet 
  • Déroulement du projet 
  • Résultats 
  • Conclusion 
  • Remerciements 

Présentation du projet 

Notre groupe est constitué de 3 étudiants de deuxième année : 

  • CLERBOUT Romain 
  • DUDENHOEFFER Maxime 
  • ZIMMERMANN Benjamin 

Dans le cadre du cours d’Études et Réalisations de deuxième année du DUT Génie Électrique et Informatique Industrielle, nous avons dû réaliser un projet. 

Le but de notre projet est de créer une machine qui trie et compte les pièces. Il faut également ajouter un afficheur à cette machine afin d’avoir le total des pièces. 

Dans ce projet nous avons dû travailler sur la partie structure et sur la partie programmation. 

Présentation du matériel utilisé 

Pour crée la structure il nous a fallu une imprimante 3D, une découpeuse laser et du plastique. 

Petite Machine De Découpe Laser Pour Acrylique/plastique/papier ...

Pour la partie programmation, il nous a fallu un Arduino, un écran LCD et un capteur de poids. 

Capteur de poids TEM01052B

Étude du projet 

L’attribut alt de cette image est vide, son nom de fichier est image-9.png.
L’attribut alt de cette image est vide, son nom de fichier est image-7.png.
 

 

Pour mener à bien la réalisation de notre projet nous avons séparé le travail en 2 parties : la partie informatique et la structure. 

Romain s’est occupé de la programmation pendant que Benjamin et Maxime se sont occupés de la structure. 

Avant de commencer le projet nous avons dû faire une analyse du capteur de poids ainsi que des pièces. Nous avons dû mesurer et peser chaque pièce afin de faciliter le triage. Par exemple, la pièce de 2 euros est la plus grande et la plus lourde, elle a 25,75 mm de diamètre et 8,5 g. Nous avons relevé ces deux caractéristiques pour chaque pièce. Le capteur a une plage de mesure qui va de 0 à 780 g.  Il a une précision de 4 mg, en effet, le capteur de poids fonctionne grâce à une résistance interne qui varie selon la courbure du matériau qui l’entoure. On récupère alors, en sortie,une tension qui nous permet, après une simple règle de trois, de connaître le poids en grammes de la pesée. On utilise aussi une carte qui permet de faire la liaison entre l’arduino et le module de pesée, celle-ci est utile pour amplifier le signal de sortie du capteur. On utilise d’ailleurs dans le programme, non pas une valeur de poids de la pièce en gramme mais une unité arbitraire. 

Voici l’analyse des pièces que nous avons réalisé : 

La pièce de 2 euros a un diamètre de 25.75 mm et un poids de 8.5g(1850ua). 

La pièce de 1 euro a un diamètre de 23.25 mm et un poids de 7.5g(1615ua). 

La pièce de 50 centimes a un diamètre de 24.25 mm et un poids de 7.80g(1650ua). 

La pièce de 20 centimes a un diamètre de 22.25 mm et un poids de 5.74g(1245ua). 

La pièce de 10 centimes a un diamètre de 19.75 mm et un poids de 4.10g(880ua). 

La pièce de 5 centimes a un diamètre de 21.25 mm et un poids de 3.92g(850ua). 

La pièce de 2 centimes a un diamètre de 18.75 mm et un poids de 3.06g(652ua). 

La pièce de 1 centimes a un diamètre de 16.25 mm et un poids de 2.30g(505ua). 

Ensuite il a fallu choisir comment programmer le comptage des pièces. Nous avons commencé sur une Raspberry pi mais au final nous sommes passé sur Arduino car c’était plus pratique entre autres parce que que celui-ci possède des entrées analogiques et le système d’exploitation de la raspberry pi n’était pas utilisé. 

Déroulement du projet 

Dans un premier temps, nous avons dû réfléchir à une solution pour trier les pièces. Nous avons opté pour une rampe fait à la découpe laser avec des trous à l’intérieur en fonction de la taille de chaque pièces, l’idée était d’incliner cette plaquette pour que les pièces roulent dessus et tombent dans le trou correspondant. Il fallait faire attention car les pièces de 50 cents et de 5 cents étaient plus grandes que les pièces de 1 euro et de 10 cent. Par la suite nous avons créé des tuyaux en dessous de chaque trou pour que la pièce se glissent dedans. 

Ensuite, il a fallu trouver une solution pour peser les pièces précédemment triées. Après avoir essayé de les peser séparément nous avons décidé de les peser toutes ensemble sur un banc de pesage. Celui-ci était équipé du capteur de poids.  

Pour finir, nous avons pu améliorer notre structure qui fonctionnait déjà pour qu’elle soit plus simple d’utilisation. En effet, nous avons rajouté une pièce, faite avec l’imprimante 3D à l’entrée de la rampe de tri pour guider les pièces plus facilement. Nous avons également ajouté des tiroirs à la sortie des tuyaux pour pouvoir récupérer les pièces une fois pesées. 

Pour le déroulement du côté de la programmation, qui a été fait en parallèle de la structure, nous avons fait un programme qui se divise en 2 parties. Une partie gère la pesée, on pèse tout le banc de pesé, on ajoute la pièce et on fait une soustraction de la nouvelle pesée moins l’ancienne, ce qui nous donne le poids de la pièce qui vient de tomber et nous permet de déterminer le type de celle-ci. La deuxième partie gère l’affichage. On affiche soit la cagnotte qui est l’affichage de base, soit le nombre de pièce par type. Cet affichage est géré par un bouton pendant qu’un autre bouton permet la remise à zéro de la cagnotte. 

Après avoir fini la structure et la programmation nous avons fini par améliorer notre projet. Nous avons ajouté une boîte pour ranger l’arduino et poser les deux boutons. Nous avons également re-designer notre projet pour en améliorer l’esthétique. 

Résultats 

La structure marche très bien, on met les pièces sur le trieur elles roulent puis tombent dans différents tuyaux selon leur taille. Ensuite, elle tombe dans des tiroirs posés sur le banc de pesage. Quand on a fini de compter les pièces, on peut retirer les tiroirs et récupérer les pièces. 

Nous avons réussi à afficher sur un écran LCD deux modes. 

Sur le premier mode, on peut voir un jackpot qui s’incrémente à chaque pièce qui arrive sur le banc de pesage. 

Sur le second mode, on peut voir un tableau avec les différentes pièces qui vont de 1 centime à 2 euros et à côté on voit le nombre de pièces posés sur le banc de pesage. 

Conclusion 

Nous avons réussi à terminer le projet dans les temps. 

Le projet étant centré plus sur la partie conception de l’objet et mise en place de nos idées grâce aux outils qui étaient à notre disposition, il nous a permis de développer nos compétences en programmation, mais également en conception 3D avec Tinkecad et en utilisation de programme de dessins vectoriels (CorelDraw) dont nous nous sommes aidés pour la découpe laser. Il a également permis de travailler en équipe, ce qui est la partie la plus intéressante du projet car nous mettons nos connaissances et nos idées en commun pour arriver à nos fins. 

Remerciements 

Finalement, nous tenons à remercier nos professeurs, M.Bazeille et M.Verrier pour leur aide et leurs conseils mais aussi M.de Sabbata qui nous a laissé accès à l’IUT Lab et à ses machines. 


Machine à café connectée

Sommaire

Introduction

Membres du projet et répartition des tâches

Problématiques

Gestion du projet

  1. Bête à cornes
  2. Mindmap
  3. Diagramme de GANTT
  4. Budget initial
  5. Liste des achats

Réalisation du projet

  1. La cafetière à filtre programmable
  2. Composants
    1. Raspberry PI
    2. Capteur de vibration
    3. Photorésistance
    4. Optocoupleur
    5. Ecran LCD tactile
  3. Implantation des capteurs
    1. Capteur de vibration et photorésistance
    2. Optocoupleur
  4. Codage
  5. Support

Bilan

Perspectives d’évolution

Remerciements

Introduction 

Dans le cadre des projets d’étude et réalisation du DUT Génie Electrique et Informatique Industrielle de Mulhouse, nous avions un volume de 96h pour réaliser le projet suivant : équiper une cafetière de capteurs pour monitorer son utilisation. Ce projet a duré pendant les quatre cinquièmes du volume horaire total, arrêté brutalement pour cause de COVID-19, c’est-à-dire d’octobre à mars.

Notre équipe s’est formée autour de ce projet par souci d’affinités et de préférences. Ce projet fut encadré par deux professeurs : M. Bazeille et M. Verrier. En dehors de nos heures de travail nous avons développé le projet en complément dans l’IUT LAB pour nous tenir à jour dans le diagramme prévisionnel. 

Membres du projet et répartition des tâches 

Les 4 membres de ce projet.

Anthony Tort Mathieu Rey Victor Seiler Thibaut Cauvez

Une fois les compétences de chacun découvertes, nous nous sommes réparti les tâches de telle sorte:

Présentation du projet

Le projet qui nous a été attribué est celui de la machine à café connectée. Ce projet consiste à apporter des modifications à une cafetière basique (Cosylife CL-PRG27) en y ajoutant des capteurs pour monitorer son utilisation. 

Les différents buts de ce projet sont :

  • La prise en main d’une raspberry pi
  • L’implantation de capteurs
  • La récolte d’informations à l’aide de ces capteurs
  • La réalisation de statistiques à partir de ces informations
  • L’enregistrement des données sur un site internet

Problématiques 

  1. Quels capteurs seront présents et comment les intégrer à notre cafetière ?
  2. Comment adapter notre système dans un environnement humide et chaud ?
  3. Comment utiliser des informations déjà présentes sur les capteurs de la cafetière ?
  4. Comment traiter et croiser ces informations de manière à avoir le plus de données utiles ?

Gestion du projet

1) Bête à cornes

Afin de ne pas s’égarer sur le sujet, nous avons mis en place une bête à cornes:

2) Mindmap

Ce diagramme a pour objectif de guider les avancées du projet.

3) Diagramme de GANTT

Les diagrammes de GANTT nous permet de comparer la durée d’avancement du projet prévisionnelle et réelle.

4) Budget initial 

Notre budget de départ était de 50 euros avec l’emprunt de la raspberry pi et de son écran tactile. Ce budget étant modulable il pouvait augmenter en cas d’achat de fournitures nécessaires au développement du projet qui dépasserait le plafond initial.

5) Liste des achats 

Article(s)Prix unitaire (TTC)QuantitéTotal (TTC)
Cafetière filtre programmable COSYLIFE CL-PRG2719.81 €119.81€
Capteur de vibrations ST0405.60€15.60€
Capteur De Lumière Photosensible3.97€13.97€
Optocoupleur Traversant (RS : 395-6344)0.238€102.38€
Prix Final(TTC) 31.76€

Les prix des résistances, des câbles  et de la carte électronique pour l’optocoupleur ne sont pas pris en compte car sont insignifiants ou récupérés sur d’anciens systèmes.

Réalisation du projet

1) La cafetière à filtre programmable

Ce projet consiste à agir sur la cafetière programmable de la marque Cosylife, il s’agit d’une cafetière basique avec un système d’horloge programmable pour l’allumer et l’éteindre de manière automatique à l’horaire que l’on souhaite.

MarqueCOSYLIFE
Type cafetièreCafetière programmable
ColorisNoir et inox
Puissance (W)900 W
ProgrammableOui
Capacité du réservoir (L)1,5 L
IsothermeNon
Nombre de tasses max15 tasses
Maintien au chaudOui
Porte filtreAmovible et lavable
Niveau d’eau visibleOui
Système anti-gouttesNon
Type de verseuseVerseuse Thermo-résistante
Veille automatiqueOui
Descriptif complémentaireverre plus résistant aux chocs thermiques
Informations complémentairesDécouvrir notre Marque et nos Produits Cosylife
Dimensions produitH 34,5 cm x L 19,9 cm x P 26,5 cm
Poids net1,55 kg
Poids brut2,4 kg
Code article960086

2) Composants

2.1) Raspberry pi

La raspberry pi est un nano-ordinateur nous permettant de faire le lien avec nos capteurs. En effet, les informations sont directement envoyées sur celle-ci afin d’être traitées et utilisées. Elles sont ensuite envoyées sur un écran LCD afin de les afficher.

Fiche technique:

ProcesseurARM v8, Quad-core 1.2 GHz, Broadcom2837 64bit CPU
Mémoire1 GB
Connectique4 x USB 2.0, 1 x CSI, 1 x micro SD, 1 x GPIO, Sortie vidéo et stéréo, 1x DSI
CommunicationBCM43143 Wifi WLAN, Bluetooth BLE
AlimentationMicro USB, jusqu’à 2,5A

2.2) Capteur de vibrations

Le capteur de vibrations permet de détecter l’utilisation de la machine à café. La cafetière tremblant un peu lorsqu’elle fait couler le café, son but ici est de capter ce tremblement. Un potentiomètre nous permet de calibrer le seuil de détection du capteur, ce dernier pouvant être utilisé avec une entrée analogique ou numérique.

Fiche technique:

Alimentation3 à 5 VCC
Sorties4 Sorties: VCC, GND, D0,A0
Dimensions42 x 17 x 9 mm

2.3) Photorésistance

La photorésistance est disposée contre le pichet de la cafetière, nous informant si le réservoir de café est présent ou non. Cette information nous permet de savoir si un café est servi et de savoir combien de fois le réservoir a été retiré.

Fiche technique:

Alimentation3,3 à 5 VCC
Sorties4 Sorties: VCC, GND, D0,A0
Dimensions3,2 x 1,4 cm

2.4) Optocoupleur

Nous utilisons des optocoupleurs afin de récupérer une information là où circule du courant. Ces optocoupleurs sont reliés directement à la cafetière afin de connaître si elle est branchée à un réseau électrique et aussi pour savoir si le bouton ON est activé.

Fiche technique:

Type de montageTraversant
Type de sortieTransistor
Tension directe maximum1,4 V
Nombre de broches4
Type de boîtierDIP
Temps de croissance5µs
Courant d’entrée maximum50 mA
Tension d’isolement5 kVrms
Taux de transfert de courant maximum260%
Rapport de transfert de courant minimum60%
Temps de chute4µs

2.5) Ecran LCD tactile

L’utilisation d’un écran LCD tactile nous permet de faire l’affichage de toute les informations récoltées grâce au capteur. L’utilisation d’un écran LCD tactile permet de faciliter l’utilisation de la cafetière car utiliser un écran d’ordinateur serait beaucoup moins ergonomique.

Fiche technique:

VersionLCD
Couleur16-bit
Affichageab 7.0 Zoll
Résolution physique800 x 400 Pixel
Diagonale17.78 cm
ModèleRaspberry Pi
ParticularitéTouch kapazitiv

3) Implantation des capteurs

3.1) Capteur de vibrations et photorésistance

Capteur de vibrations 

Pour intégrer le capteur de vibrations à notre cafetière, nous avons eu comme idée de le placer contre celle-ci. L’objectif a été de détecter les vibrations lorsque l’eau, présente dans le réservoir s’écoule dans le filtre. Cela nous a permis de savoir quand la cafetière passe du mode chauffage et remplissage au chauffage de la cafetière seul, et ainsi de connaître la consommation exacte en énergie car la cafetière consomme plus quand elle chauffe et écoule de l’eau. Nous savions aussi que lorsque l’eau s’écoule à un temps T (le débit d’écoulement étant constamment le même) il déverse un certain volume d’eau correspondant à un nombre de tasses à café moyen. Cela nous permis de connaître le volume de ces cafés servis. 

Photorésistance 

La photorésistance placée contre la verseuse en verre nous permet de détecter un changement d’état correspondant à la prise en main de cette même verseuse. Cela permet de savoir que quelqu’un est en train de se servir un café, et ainsi de connaître le nombre moyen de cafés servis à chaque utilisation.

Le branchement des ces deux capteurs, chacun composés de quatre broches, fut assez simple à réaliser :

  • VCC = alimentation du capteur (5V)
  • GND = masse du capteur
  • D0 = information de sortie logique du capteur 
  • A0 = information de sortie analogique du capteur

Nous avions uniquement utilisé la sortie D0 des deux capteurs de manière à détecter les changements d’état pour détecter les cas cités précédemment.  

3.2) Optocoupleur

 

L’optocoupleur est un composant électronique capable de transmettre un signal d’un circuit électrique à un autre, sans qu’il y ait de contact galvanique entre eux.

Dans le cas présent, il permet de récupérer des informations dans la cafetière elle-même et de l’envoyer dans la raspberry tout en séparant les deux circuits car la carte électronique d’où nous tirons les signaux est alimentée en 5V continu mais en 230V  alternatif ce qui est à la fois dangereux pour la raspberry et pour l’homme. Les signaux électriques que nous avons récupérés de la cafetière étant l’alimentation globale de la cafetière pour savoir si elle est branchée à une source de courant et l’appui sur le bouton de mise en marche de la cafetière pour savoir si elle est en veille ou en train de chauffer et faire du café. Nous avons donc deux circuits de l’optocoupleur, séparés mais branchés de la même façon c’est pour cela que l’image décrivant le branchement de l’optocoupleur ci-dessous correspond aux deux circuits de l’optocoupleur. 

Le branchement d’un optocoupleur consiste à récupérer le signal sur la pin 1 sortant par la pin 2  et d’alimenter la pin 3, s’il y a présence de signaux entre la pin 1 et 2 le transistor serra passant et et laissera passer le courant de la pin 4 à 3 pour ainsi récupérer un signal ou non sur la pin 3. En sortie de pin 3 nous avons intégré une diode au pont diviseur de tension pour savoir visuellement si le l’optocoupleur est passant ou bloquant.

Afin d’intégrer l’optocoupleur nous sommes passés par une phase test sur une breadboard puis nous avons dû créer la plaque électronique:

Néanmoins, afin de passer à l’étape de la création, des mesures de protection sont nécessaires à cause du contact avec des produits dangereux. Il faut donc se munir:                                                                                                                                         

De gants en latex

D’une blouse de travail

De lunette de protection

Après la création de la carte virtuellement, l’étape suivante consiste à créer la carte électronique qui est réalisée en plusieurs étapes:

  1. Imprimer, découper et passer aux rayons UV

Après avoir imprimé le schéma des pistes KiCad sur une feuille de calque, il faut découper la plaque qui va accueillir la piste avec les dimensions nécessaires. Ensuite, il faut placer la plaque découpée sur la feuille de calque dans les rayons UV afin de créer une réaction chimique sur la résine présente sur la plaque n’étant pas protégée par les pistes de la feuille de calque.

  1. Passage au révélateur et nettoyeur

La plaque passant dans le révélateur va afficher les pistes qui n’étaient pas exposées aux rayons UV. Elle va ensuite passer dans une nettoyeuse au perchlorure afin d’enlever les résidus de résine pour ainsi afficher les pistes cuivrées. La plaque sera encore passée aux UV afin d’enlever toute trace de résine.

  1. Étamage

La plaque va être ensuite plongée dans de l’étain chimique à froid pour y déposer une couche d’étain sur le cuivre afin de le protéger de l’oxydation.

  1. Perçage des pistes

Perçage des pistes avec différentes tailles de foret suivant les différentes pattes des composants. Le trou ne doit être ni trop petit ni trop grand.

Nous avons ensuite intégré l’optocoupleur en utilisant le logiciel kicad puis en réalisant toute les étapes de la création d’une plaque pour enfin l’intégrer dans un boite créé à la découpeuse laser pour nous permettre de le mettre en place et de manipuler le système en toute sécurité.

Voici une vidéo montrant les phases de test de l’optocoupleur ou l’on peut distinguer un changement d’état de l’information récupérée prouvant que le système fonctionne

Une fois tous les capteurs mis en place voici une image montrant comment ils sont disposés dans la boîte (ce n’est pas la disposition finale)

4) Codage 

La partie la plus importante de ce projet consiste à faire le codage de la raspberry pi. En effet il faut tout d’abord faire l’acquisition des différentes informations prises par les capteurs, il faut ensuite traiter ces informations et les croiser afin d’en tirer des statistiques et des informations sur l’état de la machine à café. Enfin il faut afficher ces informations sur un écran LCD. 

En raison de l’épidémie de Covid-19 nous n’avons pas de capture d’écran de notre code.

Tout d’abord nous utilisons nos capteurs en numérique, dans le but de savoir si la machine tremble ou non et si le pichet est présent ou non. Nous n’avons pas besoin de savoir la quantité de lumière et de vibrations, c’est pourquoi notre code fait de la détection de changement d’état.
Nous croisons nos données des différents capteurs afin de connaître l’état de la cafetière comme indiqué sur le schéma ci-dessous:

L’utilisation de la librairie “time” nous permet de savoir la date et l’heure réelle. Nous l’utilisons aussi pour compter la durée d’allumage de la cafetière et pour savoir depuis combien de temps la cafetière est branchée au réseau électrique. Ces valeurs multipliées aux valeurs mesurées de consommation dans ses différents états nous permet de connaître sa consommation en temps réel.

A l’aide d’un appareil permettant de mesurer les Watts par seconde, nous avons fait des tests et des courbes afin d’évaluer la consommation de la machine à café:

La programmation d’un compteur à chaque fois que quelqu’un retire le pichet nous permet de connaître le nombre de cafés servis et de créer des petites alertes (par exemple « changez filtre ») à partir d’un certain seuil dépassé.

On affiche puis on retire très rapidement notre code afin de faire le rafraîchissement des valeurs.

Voici une représentation de ce qu’affiche  l’écran après le lancement de notre programme:

5) Support

Afin de protéger les composants, nous avons dû créer un support. Pour cela, nous avons d’abord imaginé un boîtier qui suit la forme de la cafetière. Ainsi commence la modélisation de la cafetière.

Nous avons pris les mesures de la cafetière et modulé celle-ci. Par souci de moyens, nous avons décidé de changer notre fusil d’épaule et utiliser la découpeuse laser. Nous avons du refaire des plans et penser aux orifices afin de faire passer les fils et les composants et de placer l’écran de la raspberry PI sans que celui-ci ne tombe. Ci-dessous, les plans de la boîte.

Les parties noires signifient l’enlèvement de matière.

Ensuite, nous avons dû choisir la couleur de notre boîtier. Étant donné que nous avons besoin de mettre la photorésistance dans la pénombre, nous avons opté pour un noir uni sans transparence.  

Voici la face avant vue de l’intérieur de la boîte :

Pour fixer l’écran nous avons utilisé un ruban adhésif d’électricien.

Ci-dessous une image de la construction du boîtier:

Nous n’avons guerre pu finir sa construction car il nous faut encore ajuster différents capteurs. 

Bilan

Pour conclure sur notre projet, nous n’avons pas atteint tous nos objectifs principaux. En effet, il reste encore à finir l’intégration du support dans la cafetière puis régler la sensibilité des capteurs en situation réelle et enfin créer et récupérer les informations déjà acquises sur un site web. Malgré cela, la cafetière a reçu beaucoup d’améliorations depuis son état initial.  Nous avons découvert que le fait de modifier un système déjà fini en y ajoutant des améliorations est très intéressant. Nous avons réussi à tenir la plupart de nos prévisions malgré un certain retard pour cause de mauvais branchement de capteur, de programme, support ou encore dû au contexte actuel. Tout en avançant dans le projet nous avons continué à penser à de nouvelles améliorations car le projet nous a beaucoup plu et nous a permis d’apprendre et développer des connaissances portant sur notre formation GEII.

Perspectives d’évolution

Notre projet n’a pas atteint son maximum:

  • Nous pourrions piloter la cafetière à distance en enlevant la carte électronique qui pilote la cafetière et en intégrant un système de transistor piloté par la raspberry pi, elle-même pouvant être pilotée par une interface web
  • Intégrer un capteur de vibration adapté au système serait un grand avancement pour l’acquisition de nouvelles données et la précision de valeurs mesurées actuelles telles que la consommation électrique et le volume de café créé sur un temps donné.
  • La prise en compte de la consommation électrique de la raspberry pi  est intéressante car, à présent intégré au système, il fait partie de la cafetière.
  • Fixer un objectif de consommation de la cafetière sur l’interface pourrait sensibiliser ses utilisateurs et faire des économies d’énergie de manière à pouvoir exploiter ce projet dans un but d’économiser l’énergie.
  • L’ajout de nouveaux capteurs permettrait de créer plus d’informations, par exemple un capteur de niveau d’eau pourrait informer la quantité de cafés servis.
  • Une autre idée serait d’ajouter une information lorsque le pichet est retiré de la cafetière.

En utilisant un autre type de cafetière, nous pourrions pallier au problème de vibrations.

 Remerciements

Nous tenons à remercier l’IUT de Mulhouse ainsi que l’IUT LAB pour le budget et l’apport de matériels.

Également un grand merci à nos professeurs encadrants M. Bazeille et M. Verrier.