Asservissement d’un panneau solaire

Sommaire

  1. IntroductionComposition et rôles de l’équipe
  2. Définition du besoin Outils d’analyse fonctionnelle et définition du système
  3. Analyse solaire Étude de la trajectoire du soleil et ensoleillement
  4. Analyse mécaniqueConception et dimensionnement d’un support
  5. Analyse électrique Asservissement du système et normes électriques
  6. Solution finale Présentation de la solution retenue
  7. Conclusion

1. Introduction

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

Notre groupe est ainsi composé de 4 étudiants. Les rôles, définis en début de projet, sont les suivants :

  • DI MAURO Bastien – Définition du besoin et conception sous CREO
  • HIRTH Matthieu – Analyse électrique et asservissement du système
  • MANSUY Guillaume – Analyse mécanique et conception sous CREO
  • SITTERLE Hugo – Analyse mécanique et choix de la motorisation

L’analyse de la trajectoire du soleil ou encore de la position du support dans l’IUT ont été étudiée par l’ensemble des membres de l’équipe.

2. Définition du besoin :

La première étape du projet est la définition du besoin. L’objectif est de définir les éléments à traiter, ainsi que les problématiques et les contraintes du projet.

Le diagramme des prestations nous permet de définir la fonction principale du système Tracker.

Le système Tracker permet à l’utilisateur de programmer la structure dans le but de suivre la trajectoire du soleil, et ainsi de maximiser le rendement de la production.

Le diagramme des interacteurs permet de mettre en évidence les fonctions principales et les fonctions contraintes.

  • FP1 : Orienter le panneau solaire en fonction de la trajectoire du soleil
  • FC1 : Résister au poids des panneaux
  • FC 2 : Positionner le système sur un espace exposé au soleil
  • FC 3 : Alimenter le système
  • FC 4 : Résister aux conditions extérieures (Usure, rouille, vent)
  • FC 5 : Faciliter la maintenance du matériel électrique présent sur le système

Nous avons également réalisé un diagramme FAST. Ce dernier nous permet de définir les solutions constructives choisies pour répondre aux problématiques.

Pour terminer, en reprenant les termes du diagramme des interacteurs, nous avons établi le tableau de caractérisation des fonctions :

Fonctions de services Critères Niveau d’exigences Flexibilité
 FP 1 Orienter le système Rotation des panneaux Vérin électrique et paliers F1
Autonomie Aucune intervention de l’utilisateur F0
Pilotage Arduino F1
FC 1 Résister au poids Structure métallique Aucunes déformations F0
FC 2 Positionner le système Exposition au soleil Terrain F1
FC 3 Alimenter le système Alimentation du vérin Prise secteur F0
FC 4 Résister aux conditions extérieures Structure métallique Aucunes traces de rouille, d’usure F0
FC 5 Faciliter la maintenance Structure et matériel électrique Accessibilité F0

 

Légende :

  • FP: Fonction Principale
  • FC: Fonction Contrainte
  • Flexibilité F0: Flexibilité nulle – Niveau impératif
  • Flexibilité F1: Flexibilité faible – Niveau peu négociable
  • Flexibilité F2: Flexibilité bonne – Niveau négociable
  • Flexibilité F3: Flexibilité forte – Niveau très négociable

 

3. Analyse solaire

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

  • L’azimut,
  • La hauteur,

L’azimut représente la position du soleil  selon les quatre points cardinaux et la hauteur représente l’inclinaison du soleil par rapport à l’origine d’un plan horizontal. L’asservissement se fait grâce à ces deux paramètres. Les panneaux solaires doivent se situer perpendiculairement aux rayons du soleil pour une production optimale.

A travers cette analyse nous allons décider de l’orientation à donner au système afin de garantir un rendement maximal. La localisation géographique du système nous est imposée et se situe entre le bâtiment GEII et GMP.

Dans un premier temps nous avons identifié la trajectoire du soleil sur l’emplacement choisit à l’aide du site SunEarthTools.

A partir de cette trajectoire nous avons pu en déduire l’heure à laquelle l’ensoleillement est maximal, soit environ 11h30 en été.

Le système sera donc orienté en direction du Sud, où le soleil est à son zénith.

Les rayons du soleil étant les plus importants entre environ 9h et 15h, cela nous donne une amplitude d’environ 100° en azimut à prévoir entre le début et la fin de journée. Cependant à cause du relief, des bâtiments et des arbres présents sur les lieux une amplitude de rotation inférieure serait suffisante.

La hauteur du soleil varie entre 20° et 65° environ au fil des saisons lorsque les panneaux produiront le maximum.

A l’aide d’un second site (http://re.jrc.ec.europa.eu/pvgis/apps4/pvest.php?lang=lang=fr&map=europe), nous avons estimé la production potentielle d’un tel système. Nous avons pu réaliser un comparatif entre un système fixe, un système asservi sur 1 axe de rotation (l’azimut) et un système asservi sur 2 axes de rotation (hauteur et azimut).

Nous nous sommes alors rendu compte qu’un système à deux axes de rotation n’était pas d’une grande valeur ajoutée par rapport à un système à un axe de rotation. De plus, la conception d’un système deux axes serait plus complexe et plus coûteuse.

Nous avons donc décidé de réaliser un système de Tracker solaire asservi sur un seul axe, l’azimut. Le système serait alors incliné de manière fixe par rapport à la hauteur moyenne du soleil, soit environ 40°.

Mois Ed Em
Janvier 0.27 8.33
Février 0.46 12.9
Mars 0.73 22.8
Avril 0.92 27.7
Mai 0.95 29.4
Juin 1.03 30.9
Juillet 1.04 32.1
Août 0.97 30.1
Septembre 0.80 24.0
Octobre 0.54 16.7
Novembre 0.32 9.60
Décembre 0.24 7.46
Moyenne à l’année 0.690 21.0
Total à l’année 252

Ed: Production moyenne par jour du système (kWh)

Em: Production moyenne par mois du système (kWh)

 

4. Analyse mécanique

1. Choix de la motorisation

Après avoir déterminé l’inclinaison maximale nécessaire, il a fallu faire un choix sur le type de motorisation qui équipera le système. Pour cela, une étude de différentes solutions a été réalisé afin d’en choisir une qui correspondra au mieux à l’exigence principale du cahier des charges, faire pivoter le panneau avec un angle de 40°.

Cependant il a fallu respecter d’autres contraintes :

  • La motorisation doit être facilement programmable avec les cartes Arduino
  • La motorisation doit prendre le minimum de place
  • La motorisation doit être étanche

Le tableau de comparaison ci-dessous nous permettra de comprendre le choix final de notre motorisation.

Solutions proposées Crémaillère et pignon Vérin électrique Moteur « simple » Moteur « pas à pas »
Avantage(s) Système simple Précis selon la course du vérin Système simple Bonne précision
Système peu encombrant
Inconvénient(s) Système encombrant Choisir un vérin avec une course suffisante Difficultés de réglage Programmation difficile
Difficile à mettre en place Transmission du couple
Coût estimé De 20 à 70€ De 80 à 120€ De 20 à 70€ De 20 à 70€
Fonctionnement du système Pignon en sortie du moteur s’engrainant dans une crémaillère Vérin lié aux panneaux entraînant la rotation Sortie du moteur lié à la traverse Sortie du moteur lié à la traverse

Après étude, notre choix s’oriente sur le vérin de parabole. Il répond parfaitement à nos différentes contraintes et peut être mise en place rapidement sans gros travaux sur la structure. La mise en place du vérin sur la structure nécessite cependant la conception d’une pièce spécifique permettant l’assemblage de ce dernier avec la structure.

Grâce à la modélisation sur le logiciel CREO3 nous savons exactement la position du vérin sur le cadre ainsi que sur les panneaux solaires.

Nous avons trouvé un vérin sur le site de « Transplanet », cependant après commande de celui-ci, le vérin n’est malheureusement jamais arrivé.

2. Structure

L’objectif de ce projet étant de rendre mobile 4 panneaux solaires, il s’agit de développer une structure mécanique supportant la charge des panneaux et comprenant des liaisons mécaniques permettant de satisfaire les paramètres abordés dans l’analyse de l’ensoleillement.

Après avoir étudié la possibilité d’intégrer deux axes de rotation pouvant supporter les panneaux solaires, il s’est avéré que la structure serait trop complexe et importante à réaliser.

De ce fait nous avons décidé d’asservir les panneaux sur 1 axe de rotation permettant un suivi du soleil durant la journée (l’azimut). Les panneaux seraient alors inclinés de manière fixe selon la hauteur moyenne du soleil (environ 40°).

Cependant avec une telle inclinaison un système supportant 4 panneaux atteindrait des dimensions trop importantes (hauteur de la structure supérieure à 4 m, résistance des matériaux).

Le système a donc été divisé en deux. Ce dernier devra supporter 2 panneaux et sera dupliqué pour les 2 autres restants.

En respectant les paramètres d’inclinaison est en laissant une marge de départ d’environ 1 m par rapport au sol afin d’éviter les collisions entre les panneaux et le sol, la hauteur et la longueur du système seraient d’environ 2 m. Nous avons décidé de solidariser les panneaux solaires selon leurs largeur afin réduire au maximum la taille du système. La largeur d’un panneau étant de 998 cm, l’axe supportant le poids des panneaux et permettant leurs rotation devra être supérieur à 2 m. Ce dernier doit être assez résistant pour :

  • Ne pas fléchir sous le poids des panneaux (18 kg par panneau donc 36 kg pour deux),
  • Assurer une durée de vie importante à la structure (ne pas rouiller),
  • Limiter la masse de la structure mobile afin de réduire les efforts appliqués sur la structure fixe.

 

En premier nous sommes partie sur une structure composée :

–  D’une structure mobile comportant :

  • Un tube servant d’axe de rotation,
  • D’un cadre en profilé « U » solidarisant les deux panneaux,
  • Deux traverses permettant la fixation des panneaux,
  • Deux colliers filetés permettant le serrage des panneaux sur le tube support.

–  D’une structure fixe, supportant la structure mobile, comportant :

  • Deux supports « triangles »,
  • Deux paliers permettant la rotation de la structure mobile,
  • Deux supports pour paliers permettant de donner l’inclinaison souhaitée aux paliers,
  • Des rails de fixation permettant l’ancrage des « triangles » dans les fondations.

Les deux supports « triangles » sont de tailles différentes afin de donner l’inclinaison fixe aux panneaux. Une structure en forme de triangle a été choisie afin de mieux répartir les efforts et d’augmenter l’amplitude de rotation des panneaux. Un troisième « pieds » a été conçu pour le petit « triangle » afin de compenser le glissement des panneaux : la structure étant inclinée, les efforts se retrouvent concentrés sur le petit support. De plus, l’empattement important des triangles permet une meilleure stabilité du système face au vent ou à la neige. La fixation au sol de l’ensemble étant réalisé à l’aide de rails de fixation, la structure serait facilement démontable si besoin.

Cependant la structure devant être assemblée par soudage, avec la complexité des angles, il s’est avéré que la structure serait trop complexe à réaliser. De plus la structure fixe n’était pas assez rigide, les deux supports « triangles » devaient être solidaire.

Nous avons donc repensé la conception des supports de manière plus simple et sommes partis sur une base rectangulaire.

Deux rectangles en profilé carré reprenant les hauteurs des deux triangles seraient alors solidarisés par deux renforts horizontaux situés au sol et un renfort incliné se situant en dessous de l’axe de rotation des panneaux.

Des calculs de dimensionnement ont été réalisés sur la barre support des panneaux solaires. Cette étude a été réalisée sur une barre acier et aluminium ronde et creuse dont le diamètre extérieur est de 40 ou 50 mm avec une épaisseur variable, allant de 1 à 3 mm. Nous avons choisi une barre de diamètre 40 mm et d’épaisseur 2 mm en acier : celle-ci présente une flèche raisonnable de 19 mm en sachant que la force de 1000 N (en réalité la charge supportée par la barre est de l’ordre de 400 N) est appliquée en un point, au milieu de la barre.

3. Choix des paliers

Les panneaux solaires sont entrainés en rotation par un vérin électrique. Le vérin, fixé sur la structure métallique (Grand support), va entraîner le cadre d’assemblage des panneaux. Le débattement des panneaux dépendra de la course maximale du vérin.

La rotation de la traverse s’effectue par le biais de roulements à billes. Afin de bloquer la traverse en translation, nous avons choisis des paliers comportant des manchons. Les caractéristiques des paliers sont les suivantes :

  • Palier à semelle en deux parties – Référence SNG 509
  • Diamètre : 40 mm
  • Entraxe des perçages de fixation : 170 mm
  • Matière du palier : Fonte
  • Roulement à billes – Référence SKF 1209K
  • Manchon de serrage – Référence H209
  • Bagues – Référence SR85X5,5
  • Kit joints fourni – Référence TSNU509

Lien vers le revendeur : https://www.lebonroulement.com/tous-les-paliers-fonte/180149-palier-fonte-en-deux-parties-sng5091209k.html

Comme indiqué ci-dessus, les paliers vont permettre la rotation de la traverse supportant les panneaux, mais va également permettre l’arrêt axial de la traverse grâce au manchon.

Le montage de la traverse dans les paliers s’effectue de la manière suivante :

  • Montage des paliers sur la structure métallique
  • Montage de la traverse dans les paliers
  • Serrage du manchon présent dans le palier inférieur une fois la traverse positionnée

 

4. Structure fixe

Le nombre de panneaux solaires étant passé à 5, nous avons changer la conception du support devant être fixe afin qu’il supporte 3 panneaux. L’inclinaison donnée au support fixe est la même que celle du support mobile, soit 33°. Cela permettra aux étudiants de réaliser un comparatif de la production solaire d’un système fixe et d’un système mobile.

 

 

5. Analyse électrique

Normes

Avant de commencer les analyses sur les panneaux, nous avons dû nous renseigner sur les normes existantes concernant l’installation de panneaux photovoltaïques raccordés au réseau telles que :

  • Protection contre les chocs électriques
  • Protection contre les surintensités
  • Protection contre la foudre
  • Signalisation
  • Emplacement du coffret de mise en sécurité pompiers

Après avoir pris connaissance des normes liées aux panneaux, une nouvelle question s’est posée : faut-il brancher les panneaux en série ou en parallèle (ou les deux) ?

Lorsque les panneaux sont en série, les tensions s’additionnent. Lorsqu’ils sont en parallèle c’est les courants qui s’additionnent.

5 Panneaux Tension (V) Courant (A)
Série 150 8
Parallèle 30 40

L’onduleur disponible exige une tension minimum de 140V. Concernant ses limites maximales, on atteint 400V et 10 A.

Le seul circuit possible est avec tous les panneaux en série.

 

Schéma électrique

Les panneaux en série sont reliés tout d’abord au coffret de securisé pompiers. On arrive ensuite dans la partie continue du boîtier de sécurité avant de passer par l’onduleur. Ce dernier va faire passer la tension en alternatif qui va repasser par le boîtier de sécurité mais dans la partie alternative. Enfin le courant arrive dans le réseau de l’IUT et alimente ce qui en a besoin.

L’ensemble est relié à la terre pour la protection parafoudre.

 

Montage

Pour rendre les panneaux mobiles et pour les faire suivre le soleil, il faut un système de tracker. Ce système est composé d’une carte Arduino Uno, d’un Motor Shield, d’une breadboard, de 2 photorésistances, de 2 résistances et d’un moteur.

Montage – Réalisé à l’aide du logiciel Fritzing

Le Motor Shield est directement empilé sur la carte Arduino et permet de piloter plusieurs moteurs jusqu’à 48V. Il pilotera le moteur permettant la rotation des panneaux.

Dual DC Motor Shield

lien : semageek

 

Les photorésistances sont reliées aux ports analogiques A2 et A3 de la carte. La sensibilité d’une photorésistance peut être changée en fonction de la valeur de la résistance reliée au Gnd. Plus la résistance est élevée, plus la sensibilité de la lumière sera forte et adaptée aux faibles intensités lumineuses. Au contraire, une résistance plus faible comme 100 Ω est plus adaptée en milieu ensoleillé.

Les deux photorésistances seront séparées par une pièce qui fait de l’ombre à l’une des deux quand les rayons du Soleil ne leur sont pas perpendiculaires.

 

Programmation

Lorsqu’il fait jour, le programme teste continuellement la valeur des photorésistances. Quand une différence de valeurs entre les 2 photorésistances est trop importante, une prise de valeurs est lancée pour réaliser une moyenne sur chaque photorésistance. Si l’écart entre les moyennes est supérieur à une valeur donnée, une tension s’applique aux bornes du moteur jusqu’à que la photorésistance la moins éclairée dépasse la valeur de l’autre. Le signe de la tension dépend de la photorésistance la plus éclairée.

Lorsqu’il fait nuit, la valeur de chaque photorésistance atteint 0. Les panneaux se placent alors en direction du levé du Soleil et s’arrêtent.

Programme

 

6. Solution finale

 

7. Conclusion

L’étude du projet a été réalisée cependant nous n’avons pas réussi à mettre en œuvre la solution conçu. Notre commande tardive de matériel ne nous permet malheureusement pas de réaliser la structure. Différents devis auprès de différents fournisseurs ont été réalisé, mais pour la plupart nous sommes toujours en attente de réponses.

Tous les plans des éléments présentés dans cet article ainsi que la liste des éléments à commander avec le nom des fournisseurs sont à disposition pour un éventuel prochain groupe d’étudiants souhaitant terminer le travail commencé.

Les documents sont disponibles en annexe ci-dessous (plans, devis et matériel nécessaire,etc.).

 

Annexes :

Mise en plan – Support fixe

Mise en Plan – Support mobile

Commande du matériel

Support Mobile

Support Fixe


Babyfoot connecté


Equipe de projet 

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

LE CONCEPT : PRÉSENTATION GÉNÉRALE

 

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


Qu’est-ce que le baby foot ?

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


Présentation du projet

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


Cahier des charges 

Diagramme bête à cornes

Diagramme Pieuvre

 

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

Diagramme bloc

 

Diagramme d’exigence

 

Budget

Partie Capteurs

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

Montage électrique :

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

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

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

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

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

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

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

Programmation :

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

 

 

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

 

Présentation de Node Red : 


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

 

 

 

 

 

 

Démarrer Node-Red

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

Partie Interface Graphique Node Red

Nous avons tout d’abord commencé par installer le nœud dashboard. Celui ci nous a permit de gérer l’interface graphique à l’aide de différentes commandes. Chacune d’elle est spécifique, vous trouvez le contenu un peu plus bas.

 

 

 

 

 

 

 

 

 

 

 

 

 

1) Conception de la page d’accueil :

  

La page d’accueil est constitué de deux blocs. Le premier bloc « logo » et le second « Réalisation ». Ce sont tous les deux des « templates », c’est à dire que nous allons pouvoir insérer des images, écrire, décider de l’alignement du texte… grâce à la programmation en html.

2) Menu Règles :

On affiche la page des règles avec un scroll :

3) Menu de match : Score 

  • Nœud But Equipe Rouge => Affiche le texte sur l’interface graphique
  • Nœud Score =>  Récupère la valeur du compteur
  • Nœud Compte Equipe Bleu => Permet de disposer la valeur du compteur au centre
  • Nœud Remise à zéro => Lors d’un appui, il envoie l’info au RAZ et ainsi le RAZ injecte 0 dans le nœud de comptage

Avec le bouton de remise à zéro :

Partie Leds 

 

Les leds dans le projet baby-foot connecté auront comme but de clignoter de la couleur respective à celle de l’équipe afin d’avertir l’utilisateur de la présence d’un nouveau but.

 

Pour répondre à ce besoin nous nous sommes tourné vers l’utilisation d’un ruban de led pour la gestion de la taille des zones à éclairer sur le baby-foot.

Les résistances auront pour but de résister au passage du courant dans les transistors.

 

Le fonctionnement d’un transitor :

 

Le transistor dispose de 3 bornes, le collecteur, l’émetteur et la base. Le collecteur et l’émetteur sont techniquement symétriques. Dans notre cas le collecteur sera la couleur du ruban de leds et l’émetteur le 0V, car nous souhaitons émettre aux leds le 0V afin de les faire briller. La base, notre signal de sortie du Raspberry permet de laisser passer ou non la conductivité du collecteur vers l’émetteur en laissant passer les électrons se trouvant dans le transistor grâce à l’envoie d’une faible tension, ici 3,3V.

 

Schéma d’un Transistor NPN avec 0V à la base

Schéma d’un Transistor NPN avec 3,3V à la base

 

Montage électrique :

 

Mesure courant des leds :

  • Bleu : 0.7A
  • Rouge : 0.8A
  • Vert : 0.7A

 

Matériels utilisés :

  • 1 Ruban de leds BRG de 12V
  • 1 Alimentation 12V/2A
  • 3 Transistors 2N4922 NPN 2A
  • 3 Résistances 270 Ohms

 

Pour s’assurer du bon fonctionnement du montage nous avons simuler le signal délivré par le Raspberry à l’aide d’un générateur de tension réglé sur une tension de 3,3V.

 

 

Nous avons élaboré un boitier comprenant le montage précédent.

Voici des photos du résultat final de la boite.

 

Le programme :

 

Voici une vue d’ensemble du programme sur Node-Red permettant le clignotement des leds.

Le programme est composé d’une succession de 4 temporisations de type trigger lancées lors du passage à 1 du capteur détectant un but. Ces temporisations sont reliées aux sorties des leds de la couleur  du but qui fera ainsi clignoter les leds.

 

Le fonctionnement des différentes temporisations en série nous permet de créer différentes impulsions chacune de la valeur de la plus petite temporisation crée. Ce qui entraîne un clignotement des leds pendant une durée de 1s toutes les 125ms dans notre cas.

 

Trigger :

Module de sortie :

 

 

 

Schéma Electrique du Baby-Foot Connecté :

Schéma électrique Baby-Foot Connecté

 

Câblage du Baby-Foot : 

 

Finalisation de la partie Génie Electrique et Informatique Industrielle en vidéo : 

 

Partie GMP

Dans un premier temps, nous avons procédé au démontage et à la rénovation du baby-foot. L’état initial de la structure était exécrable (trous, visseries abimés, bois enfoncé, saletés…) Cette remise en état fut chronophage et couteuse en matériaux (colles, mastic, pâte à réparer, visseries neuves) et en nouveaux outils (forets, mèche à bois). En disposant uniquement d’une soixantaine d’heures de projets, la partie purement mécanique et industrielle du projet fut un réel contre la montre. Malheureusement, malgré de nombreuse heure supplémentaire, le projet n’a pas pu totalement aboutir, notamment à cause de nombreux problèmes au cours du démontage et de la rénovation, bien que les opérations d’usinage et de conception ce sont quant à elles généralement bien déroulés.

Nous allons maintenant vous présenter notre cahier des charges mis en place début décembre, avec les fonctions mises en place et les tâches restants à effectuer :

Cahier des charges (GMP)

FONCTIONS

CRITÈRES

NIVEAUX

FP1 : Assurer une bonne jouabilité du babyfoot

 

Guidage barres de jeu et confort

 

 

Système de palier lisse

Arrêt axial des barres

 

FC1 : Stabiliser le babyfoot

 

Stabiliser

Renforcer les pieds Double pied
Lier les pieds Tige filetée + écrous

 

FC2 : Assurer l’acheminement des balles vers les capteurs

 

Acheminer

 

 

Guider la balle

 

Lattes + tube PVC

 

FC3 : Loger les composants électroniques

 

Logement

Écran Boitier en bois
Capteurs Sur tube PVC

 

FC4 : Doit être esthétique

 

Esthétisme
Design, formes Formes discrètes
Couleurs Toutes

 

FP1 : Assurer une bonne jouabilité du babyfoot

 

Réalisation de paliers lisses afin d’assurer le bon guidage des barres. Après concertation avec les professeurs, l’idée retenue était de réaliser les paliers lisse en laiton pour éviter le contact entre acier et aluminium (peu favorable au glissement). Après consultation avec l’atelier, le délai d’approvisionnement du tube de laiton correspondant à notre besoin était trop important. C’est pourquoi nous avons décidé de réaliser les paliers en aluminium avec bague plastique et utiliser des barres en acier.

 

Présentation du système :

 

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1527&part=4

 

 

 

Modélisation des pièces sous Creo

 

 

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=3https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=2

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1527&part=3

 

 

 

Réalisation de la FAO (Fabrication assistée par ordinateur)

 

 

 

 

Usinage de la pièce avec une commande numérique

 

 

Résultat obtenu :

 

Préparation du flan pour accueillir les 2 pièces

 

 

Perçage de 3 trous diamètre 3.2 pour faire passer les vis d’assemblage M3 du système de guidage.

 

 

Assemble du système de guidage

 

 

Renouvellement des barres : Démontage des barres actuelles, débitage de ronds d’acier Ø15, perçage et mise en place des nouveaux bonhommes. Montage des anneaux de serrage pour bloquer la barre axialement en translation.

 

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1528&part=2

 

 

Nouvelles surfaces de jeux : nouveau tapis et plinthes en bois. Prise de côtes, mise en plan papier puis transmission à GRAUER Construction, spécialiste dans la création de maisons à ossature bois.

Restructuration du fonds de but : « Gamelles » intempestives dus à la forme peu ingénieuse du fond de but : découpe d’une plaque PVC vissées avec un coussinet sur la paroi pour créer un effet d’amortissement.

Rehausse du plateau de jeu : Pour assurer un meilleur confort de jeu avec les nouveaux joueurs plus petits que les anciens modèles, nous avons rehausser le plateau de jeu à l’aide de calles plastiques normalisées fournies par GRAUER Construction.

 

A faire :

  • Découpe & pose du tapis de jeux
  • Ajout de palier cylindrique plastique (type IGUS) pour minimiser le frottement acier-aluminium des barres avec le palier : Bien que la translation des barres dans les paliers soit optimale avec un système correctement lubrifié, cette solution améliorerait d’avantage le confort de jeu.
  • Opération de percage-alesage et montage serré des paliers cylindriques sur 16 pièces déjà réalisées

 

FC1 : Stabiliser le babyfoot

Stabilisation : Ajout de 4 pieds supplémentaires, conception CAO, mise en plan DXF et sous-traité par HUSSON International (Les pièces en bois trop massive ne pouvant pas être usinées à l’atelier)

Nouveau système de solidarisation du bâti : Fixation des pieds deux à deux via une tige filetée. Le maintien de la distance entre les deux mêmes pieds est assuré par une entretoise. L’écart entre les pieds droits et les pieds gauches sont maintenus grâce à un système de contre-écrou.

A faire :

  • Nous avons pu observer une nette amélioration de la stabilité, mais un phénomène de bascule reste présent et problématique pour le confort de jeu et l’endommagement prématuré des composants. Une recherche d’une nouvelle solution ou amélioration du concept est envisageable.

 

FC2 : Acheminer la balle vers les capteurs

 

Goulotte d’alimentation : Assemblage d’une structure bois/PVC permettant de guider la balle de la sortie de but à l’accès de repêche.

 

A faire :

Perfectionnement de la structure, dans de rares positions la balle reste coincée.

FC3 : Logements des composants électroniques

Création d’un logement d’écran : Réalisation d’un logement d’écran en bois permettant le passage des câbles jusqu’au Raspberry

 

Logement des capteurs dans la goulotte PVC : Réalisation d’une rainure dans la goulotte permettant l’insertion des capteurs en position verticale pour une détection de la balle vers le bas.

 

 

FC4 : Doit être esthétique

Visserie non apparente : Réalisation de cache écrou en impression 3D pour cacher la visserie apparente.

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=5

https://e-partage.uha.fr/service/home/~/?auth=co&loc=fr&id=1526&part=4

Habillage : découpe de profil aluminium pour réaliser le haut de but

Ponçage : peinture à réaliser

 

Conclusion : Ce projet fut motivant de par notre intérêt pour le baby-foot mais également dans l’application de nos compétences de génie mécanique. Cependant, il fut trop ambitieux de prévoir la remise à neuf intégrale du baby-foot en 60 heures. Il y aurait Intérêt de reconduire le projet l’année prochaine pour les futurs étudiants de deuxième année : une base fonctionnelle est en place, mais il reste beaucoup de piste d’améliorations pour obtenir un produit optimal. De plus, lors de la création de chaque pièce, par soucis de ne pas abîmer la structure existante et de pouvoir modifier en cas d’échec, chaque pièce a été conçu de manière à pouvoir être démontées facilement, ce qui facilitera la prise en main par d’autres étudiants.

 

État actuel :

 

 


Tir automatisé avec catapulte

Participant

  • KERNACKER Thomas(GMP)
  • ASTRIC François-David (GMP)
  • KUPFER Paulin (GEII)

Le Lanceur (GMP)

Le projet du lanceur consiste à lancer une balle de squash de 24g dans une cible (panier) à une distance de 10m.

La contrainte que nous possédions était de faire tenir notre système complet dans un cube de 25 cm³.

 

Définition du besoin

Le diagramme « Bête à corne » nous permet de définir la fonction principale du lanceur.

 

Le diagramme « Pieuvre » permet de définir les fonctions principales et les fonctions contraintes de notre système.

 

 

Schéma Cinématique

La Conception

Au niveau de la conception du lanceur, nous avons décidés de nous rapprocher de l’idée du canon.

Le corps principale du lanceur est un fût où l’on vient placer les divers éléments du système d’armement et de propulsion.

Lanceur 3D

Au départ, nous avions envisagés trois solutions différentes pour armer notre lanceur.

La solution de gauche consiste à compresser un ressort de compression pour propulser la balle. L’inconvénient de cette solution est qu’elle n’est pas très modulable car l’on ne peut placer qu’un seul ressort.

La solution du centre consiste à tendre des élastiques pour envoyer la balle. Cette solution est pratique car l’on peut ajouter ou retirer facilement les couches d’élastiques pour régler la puissance de tir.

La dernière solution consiste à tendre des ressorts de tractions. Nous avons choisis cette solution car elle est assez modulable, on peut placer jusqu’à 4 ressorts sur le système, mais aussi pour le fait de travailler avec de « vrais » composants mécaniques.

Le lancé

Tout d’abord il nous a fallu déterminer les conditions avec lesquelles nous enverrons notre balle de squash à 10m. Nous supposons au départ plusieurs variables :

  • Durée de vol de la balle de squash = 0.5s pour un tir très rapide
  • Angle de tir = 15° pour un tir tendu

Grâce aux équations du mouvement, nous trouvons une vitesse de balle égale à 14m/s.

Pour évaluer l’énergie nécessaire au tir d’une balle de squash de 24g, nous avons alors réalisé un tableau Excel, nous donnant une énergie d’environ 2.3 Joule.

 

Cette valeur est très satisfaisante car situé après la chute de la courbe de l’énergie.

 

Dimensionnement

Avec la vitesse de 14m/s, nous déterminons ensuite les ressorts et moteurs nécessaires à la charge du tir.

Nous trouvons alors une raideur de ressort d’environ 4N/mm. Selon notre conception, celle-ci sera acquise grâce à 4 ressorts d’1N/mm chacun ou 8 ressorts de 0.5N/mm.

De même, nous déterminons un couple de sortie nécessaire à l’armement de 0.81N.m.

Nos recherches sur différents moteurs déjà disponible au sein de l’IUT nous ont permis de récupérer un petit moteur avec un couple de 3kg.cm, ce qui équivaut à 0.29N.m.

Son couple n’étant pas suffisant, il nécessitera l’accompagnement d’un système de réduction.

Par la suite nous avons déterminés le nombre de dents des deux roues dentées afin d’obtenir un couple de 0.28N.m.

Pour le système de réduction; on considérera un rendement hypothétique de 0.85.

Le système d’armement

Afin d’armer notre lanceur, nous avons conçus un système d’armement reprenant le principe d’un treuil.

Système d’armement 3D

Pour ce faire, on entraîne un axe avec un moteur accompagné d’un système de réduction. Cet axe va enrouler un câble en acier qui va ensuite tendre notre système de propulsion.

Nous avons dimensionnés nos engrenages de tel sorte à pouvoir récupérer un moteur fourni par l’IUT, ce qui nous évite des frais supplémentaires pour notre projet.

La pièce la plus complexe de système est l’axe car il doit avoir une tolérance géométrique élevé sur toute sa longueur (∅4 g6) pour permettre un ajustement juste glissant dans le cylindre tendeur.

Plan axe 2D

Cylindre tendeur 3D

L’axe est situé en dessous de la section droite du tube car il faut permettre au câble en acier de s’enrouler autour du cylindre tendeur de façon à garder le système de propulsion coaxial avec le fût.

L’arrêt axial de l’axe s’effectue par deux anneaux élastiques car il ne subit pas d’effort axial particulier. Il est guidé par deux coussinets en bronze afin de minimiser les frottements et d’avoir un rendement le plus élevé possible.

Coussinet en bronze

L’ensemble des pièces sont en aluminium dû à la légèreté de cette matière sauf l’axe qui est quant à lui en acier, afin de ne pas se faire cisailler par le câble en acier.

 

Le système de propulsion

Afin de propulser la balle de squash, nous avons conçu un tige guidée en translation à travers le fût du lanceur par une douille en plastique Igus.

Nous avons choisis cette douille en plastique car sa technologie lui permet d’avoir un coefficient de frottement très faible, qui se rapproche de la qualité d’une cage à bille, à moindre coût.

Système d’armement 3D

Douille plastique Igus 3D

L’ensemble de la tige est composé de 4 pièces afin de pouvoir la monter dans notre système de propulsion.

Ces quatre pièces sont mises en positions par guidages cylindriques et sont ensuite vissées sur l’axe de la tige.

Vue éclatée de la tige 3D

Le système de propulsion comportera donc 2 paires de ressorts différents suite à la rupture de stock de nos fournisseurs.

Ces ressorts sont fixés sur le disque et la tige afin de propulser l’ensemble de la tige, guidée par la douille en plastique.

Le disque est fixé dans le fût par deux vis M4 et est ensuite goupiller pour lui permettre de bien rester fixe suite aux efforts qu’il va subir.

La pièce tenant la câble en acier a été conçu afin de permettre au câble de bien rester dans le plan de la section droite du fût.

Pièce porte-câble 3D

L’ensemble des pièce sont en aluminium pour minimiser le poids du système.

 

Fixation au bâti

L’ensemble du fût est tenu par une pièce intermédiaire permettant de la tenir est de régler son angle de tir. Malheureusement, faute de temps, nous n’avons pas pu réaliser ce système.

Fixation tube 3D

Le Système de Visée (GEII)

Le système de visée sera par reconnaissance visuel d’une couleur autour de la cible . Il fonctionnera sur le principe d’un tracking de couleur rouge et d’une gestion de 2 servos-moteur.

Le Matériel

  • 2 Servo-moteur. J’ai utilisé des moteur 50 Hz, la Fréquence est importante à connaitre car il faut la renseigner dans certains programmes, en effet un servo moteur fonctionne avec pour consigne une impulsion de 1 à 2 ms sur sa fréquence de fonctionnement. Pour la bibliothèque servo.h la fréquence est calculée toute seul.
  • Un Raspberry pi au minimum 2 (je n’ai pas testé sur une version antérieur).Il est nécessaire d’avoir une certaine puissance de calcul pour faire du traitement d’image.
  • Une camera Pi module V1 suffi car à 10 metre une cible de 1m mesure 11 pixel de rayon soit une tache de 380 pixel. Le calcul vaut : rayon=2549*1/tan(26.75) *10 . L’aire = rayon * rayon * pi.

Le système

Il n’est pas très compliqué. La Caméra pi a son emplacement dans la carte. Les servo-moteurs peuvent avoir leur alimentation extérieur mais on peut aussi les câbler sur le 5 V de la Raspberry. Il faut aussi réunir toutes les masses. Les codes couleurs des câbles des servo moteur sont precis: brun = la terre, rouge = le +, jaune = la consigne.

Le Programme

Le programme est donc un tracking du rouge(h = 20, s = 240, v = 200) on aurait aussi pu le faire avec d’autre couleur mais il faut en avoir une qui ne soit pas confondable avec l’élément du décor.Le programme complet sera en fin de ce paragraphe, il incluras tout les outils facilitant le paramétrages du système.

Le programme consiste en trois parti:

  1. Le traitement de l’image
  2. Positionnement des coordonné
  3. Mise en mouvement des moteurs

 

Le traitement de l’image est une binarisation des pixels rouges en blanc. Pour cela il faut d’abord passer l’image de BGR (bleu, vert, rouge) en HSV (teinte, saturation, brillance). Ensuite le programme crée un masque de recherche qui passe sur chaque pixel pour le comparé.

En second, le programme va récupérer les coordonnés de la plus grande tache, cette tache sera notre cible, il faudra parfois ajuster les valeur de s et h en fonction du décor car la luminosité peut faire varier ces valeurs. Cette partie calcul le centre de gravité de la tache et il déplace petit à petit les anciennes coordonnées. Lorsque ceci est fait, il dessine le cercle nous permettant de voir quelle tache il a désigné comme étant la plus grosse de notre image.

Enfin on va calculer l’angle à ajouter au lanceur pour qu’il puisse se replacer en face de la cible. Pour ce calcul il faut ajouter à l’ancien angle, le nouvelle angle qui vaut le rapport difference de pixel par rapport au centre sur les pixel max fois l’angle.

Avec la bibliothèque Servo on a seulement besoin de renseigner l’angle. Certain comme GPIO sur Raspberry demande des calculs supplémentaires dépendant de vos moteur mais ce sera toujours sur la base de a+(angle/180)*b.

Voici le programme:

#include « opencv/highgui.h »

#include « opencv/cv.h »

 

#include <iostream>

#include <stdlib.h>

#include <stdio.h>

#include <servo.h>

 

//methode mathematique

#define max(a, b) ((a) > (b) ? (a) : (b))

#define min(a, b) ((a) < (b) ? (a) : (b))

#define abs(x) ((x) > 0 ? (x) : -(x))

#define sign(x) ((x) > 0 ? 1 : -1)

 

// pas de l’object

#define STEP_MIN 5

#define STEP_MAX 100

 

IplImage *image;

 

// position de reference

CvPoint objectPos = cvPoint(-1, -1);

// parametre de couleur

int h = 20, s = 240, v = 200, tolerance = 15;

 

/*

* binarisation de l’image

*/

CvPoint binarisation(IplImage* image, int *nbPixels) {

 

int x, y;

CvScalar pixel;

IplImage *hsv, *mask;

IplConvKernel *kernel;

int sommeX = 0, sommeY = 0;

*nbPixels = 0;

Pif paf pouf

 

// creation du masque de binarisation

mask = cvCreateImage(cvGetSize(image), image->depth, 1);

 

// recreer l’image en couleur HSV

hsv = cvCloneImage(image);

cvCvtColor(image, hsv, CV_BGR2HSV);

 

// creation du masque de recherché de couleur

cvInRangeS(hsv, cvScalar(h – tolerance -1, s – tolerance, 0), cvScalar(h + tolerance -1, s + tolerance, 255), mask);

 

// definition de l’outil de reconnaissance

kernel = cvCreateStructuringElementEx(5, 5, 2, 2, CV_SHAPE_ELLIPSE);

 

// filtrage des parasite

cvDilate(mask, mask, kernel, 1);

cvErode(mask, mask, kernel, 1);

 

// On cherche le centre de l’objet

for(x = 0; x < mask->width; x++) {

for(y = 0; y < mask->height; y++) {

 

// Si le pixel est un de ceux tracké le prendre en compte pour le centre de gravité.

if(((uchar *)(mask->imageData + y*mask->widthStep))[x] == 255) {

sommeX += x;

sommeY += y;

(*nbPixels)++;

}

}

}

 

// affichage sur écran pour les tests

cvShowImage(« GeckoGeek Mask », mask);

 

 

cvReleaseStructuringElement(&kernel);

 

cvReleaseImage(&mask);

 

cvReleaseImage(&hsv);

 

// Si l’on a rien on considère l’objet au centre

if(*nbPixels > 0)

return cvPoint((int)(sommeX / (*nbPixels)), (int)(sommeY / (*nbPixels)));

else

return cvPoint(-1, -1);

}

 

/*

* ajout d’un cercle indicatif renseignant la position de l’objet

*/

Point addObjectToVideo(IplImage* image, CvPoint objectNextPos, int nbPixels) {

 

int objectNextStepX, objectNextStepY;

 

// Calcul de la position du cercle

if (nbPixels > 10) {

 

// Si aucune position trouvé

if (objectPos.x == -1 || objectPos.y == -1) {

objectPos.x = objectNextPos.x;

objectPos.y = objectNextPos.y;

}

 

// Deplacement du cercle vers l’object

if (abs(objectPos.x – objectNextPos.x) > STEP_MIN) {

objectNextStepX = max(STEP_MIN, min(STEP_MAX, abs(objectPos.x – objectNextPos.x) / 2));

objectPos.x += (-1) * sign(objectPos.x – objectNextPos.x) * objectNextStepX;

}

if (abs(objectPos.y – objectNextPos.y) > STEP_MIN) {

objectNextStepY = max(STEP_MIN, min(STEP_MAX, abs(objectPos.y – objectNextPos.y) / 2));

objectPos.y += (-1) * sign(objectPos.y – objectNextPos.y) * objectNextStepY;

}

 

 

} else {

 

objectPos.x = -1;

objectPos.y = -1;

 

}

 

// On dessine le cercle

if (nbPixels > 10)

cvDrawCircle(image, objectPos, 15, CV_RGB(255, 0, 0), -1);

 

cvShowImage(« GeckoGeek Color Tracking », image);

//retour des coordonee du point

Return objectPos;

}

 

 

int main() {

Servo moty;

Servo motX;

Point viseur;

Float x;

Float y;

 

Moty.attach(8);

Moty.attach(7);

while(1)

// Image & hsvImage

IplImage *hsv;

// Video Capture

CvCapture *capture;

 

int nbPixels;

 

CvPoint objectNextPos;

 

// initialization de la capture video

capture = cvCreateCameraCapture(200);

 

 

if (!capture) {

printf(« Video non prise.\n »);

return -1;

}

 

// creation de la fenetre

cvNamedWindow(« test « , CV_WINDOW_AUTOSIZE);

cvNamedWindow(« test Mask », CV_WINDOW_AUTOSIZE);

cvMoveWindow(« test Color Tracking », 0, 100);

cvMoveWindow(« test Mask », 650, 100);

 

// On prend l’image courrante

image = cvQueryFrame(capture);

 

 

objectNextPos = binarisation(image, &nbPixels);

viseur = addObjectToVideo(image, objectNextPos, nbPixels);

 

//mise en mouvement des moteurs

 

x=viseur.x/2549*26.75+x; //angle que l’on veut rajouter(2549 la resolution/26.75 l’angle de vue)

y=viseur.y/1944*20.7+y;

moty.write(y) ;

motx.write(x) ;

delay(15) ;

 

// Destruction de la fenetre

cvDestroyWindow(« test Color Tracking »);

cvDestroyWindow(« test Mask »);

cvReleaseCapture(&capture);

 

return 0;

 

}

Avancement

Le projet n’a pu être fini fautes de temps, ma principal difficulté ne fut pas dans le programme car chaque partie était assez simple mais dans l’installation de l’opencv sur Raspberry. Je n’ai jamais réussi à l’installer puis l’utiliser sur 2 raspberry différent. J’ai aussi pris du retard car après une mauvaise manipulation j’ai grillé une Raspberry du au nombreux changement durant mes test des moteurs en Arduino


Anneaux de photodiodes

Anneau photodiodes

 

LITZLER Cédric

ZUGMEYER Adrien

BARETTI Gaetan

 


Sommaire

 

1. Présentation du projet

2. Attributions des rôles

3. Câblage électrique & Réalisation du circuit imprimé

4. Programmation Arduino

5.Programmation Python(Spyder)

6. Serveur MQTT

7.Avancé du projet

8. Conclusion

9.Remerciements

 


1. Présentation du projet

Dans le cadre de notre projet de 2ème année en « Etudes et Réalisations », nous avons mes 2 camarades ainsi que moi-même été amenés à travailler ensemble sur le projet d’un anneau de photodiodes.

Le but de ce projet est de créer un système de mesure qui sera utilisé pour visualiser la direction de l’étirement d’un textile soumis à un test.

Le système sera composé d’une carte Arduino, d’un laser, d’un circuit électrique de forme circulaire, d’une alimentation et de photodiodes. Ce système sera placé au dessus du textile et protégé de la lumière par un tube ou une jupe. Le laser et les photodiodes pointeront en direction du textile et la lumière du laser sera plus ou moins réfléchie par le tissu vers les photodiodes placées sous la forme d’un cercle afin de connaitre l’intensité de l’étirement et la direction des fibres du textile. Ces mesures seront lues via un PC sous forme de tension .

Ci-dessous, voici un premier schéma montrant un peu à quoi va ressembler le résultat final de notre projet ainsi que 2 images de notre maquette actuelle. A cela, il faut encore y rajouter un manche ou un support permettant de fixer le matériel tel que la carte Arduino, les connexions des différents câbles électriques, la pile etc…

 


2. Attributions des rôles

 

LITZLER Cédric:

  • Programmation de la carte Arduino
  • Programmation Python
  • Câblage & conception du schéma électrique
  • Réalisation du câblage électrique de la plaquette finale
  • Rédaction du dossier texte

 

ZUGMEYER Adrien:

  • Etude de la partie électrique: Réalisation du Circuit-Imprimé & Conception du schéma électrique
  • Rédaction du dossier texte
  • Travail sur le support

 

BARETTI Gaetan:

  • Conception du Schéma électrique, Planification & création du serveur MQTT (abandoné)
  • Rédaction du dossier texte
  • Travail sur le support

 

 


3. Câblage électrique

Le projet prévoyait initialement 36 photodiodes mais après une étude plus détaillée de tous le système, nous somme passé à 8 photodiodes pour un soucis de complexité. La difficulté principale réside dans la présence du grand nombre de fils au final. Après s’être documenté sur internet et sur divers sites, j’ai pu dresser le schéma électrique qui permet la liaison des photodiodes avec la carte Arduino. Ce câblage comporte 8 résistances de 1MΩ, la carte Arduino MEGA, 8 photodiodes et beaucoup de fils électriques.

La masse est relié entre la résistance et la photodiode. La photodiode elle, est relié à l’autre entrée de la résistance et relie les entrées analogiques de A0 à A7.

Ci-dessous, le schéma électrique réalisé sur le logiciel kicad:

 

 

 

Réalisation du circuit imprimé:

A l’aide du schéma électrique réalisé sur le logiciel Kicad, nous avons pu nous en servir pour créer le circuit imprimé.

Adrien a donc dû se familiariser avec l’environnement de travail de Kicad ce qui n’a pas été chose aisée car c’est un logiciel qui n’est pas très intuitif. Kicad permet, à partir d’un schéma électrique, de créer un Circuit imprimé en associant les empreintes des composants avec leur noms. Voici le résultat obtenu après plusieurs heures de travail sur le logiciel de création:

 

 

 

 

 

 

 

                                                                                                    Voici a quoi ressemblera le circuit imprimé lorsqu’il sera fini

 

Suite à cela nous avons pu utiliser le laboratoire de Circuit imprimé pour découper le disque puis le percer pour accueillir les pattes des composants électronique, nous avons enfin, pu souder les composants à la carte.

 



4. Codage Arduino

Le codage de la carte Arduino est une étape très importante dans le projet afin de recevoir les valeurs des photodiodes. Après avoir réalisé de nombreuse recherches sur internet sur la façon de construire ce code, j’ai travaillé en plusieurs étapes.

Dans un premier temps j’ai commencé par essayer de piloter 1 seule photodiode puis 4, puis d’ajouter un bouton pour contrôler les acquisitions uniquement lors de son appui dessus. Finalement, j’ai pu supprimer ce bouton n’ayant plus de réel utilité puisque toutes les acquisitions se font maintenant via le logiciel Spyder.

A présent, le programme comporte les 8 photodiodes et fonctionne efficacement.

Le programme utilise la liaison série à 38400 bits/seconde.

 

Le principe général est le suivant:

Les photodiodes relèvent une valeur correspondant à une tension en fonction de la luminosité qu’elles perçoivent. Le programme doit pouvoir lire les valeurs du nombre d’acquisition et de la durée entre 2 acquisitions sur le port série. Ces valeurs saisies par l’utilisateur seront stockés dans des variables dans la mémoire ROM (voir explication de l’utilisation de la mémoire ROM en-dessous du code)

De plus, il doit également pouvoir envoyer les valeurs des photodiodes via le port série de façon à être récupérée grâce à une instruction bien précise sur le logiciel Spyder.

 

 

Le code arduino final:

 




 

Quelques explications importantes:

 

-On commence par déclarer les bibliothèques utilisées.

-On déclare dans un integer constant nommé numReading  la taille du tableau (Ici 6).         Objectif –> Lisser légèrement les valeurs en utilisant les 6 dernières valeurs présentes dans le tableau afin de ne pas avoir a traiter des signaux « parasites ».

-Utilisation de « EEPROM.read(0) » et « EEPROM.read(1) » dans le programme arduino car les variables sont généralement stockés dans un buffer et que les paramètres du nombre d’acquisition et du délai entre 2 acquisitions ne sont transmises qu’une seul fois par le port série. Ecrire ce résultat dans la ROM de la carte Arduino permet donc de préserver cette valeur.

-Ne pas oublier dans la fonction setup l’initiailisation de la communication serie à 38400 et l’initialisation du tableau.

-ReadIndex nous servira à évoluer de 0 à 6 pour lire chaque valeur du tableau.

-Total contient la somme de toutes les valeurs du tableau.

-Average sera la valeur moyenne du tableau (total / numReading).

 

Fonction principale loop():

-On retire de total la valeur actuellement indexée du tableau (afin de faire de la place pour la nouvelle).

-On vient stocker la valeur du potentiomètre dans l’index en cours du tableau.

-On ajoute la valeur au total.

-On augmente l’index de 1 afin de passage à la « case suivante » du tableau.

-Si l’index dépassee 6, alors on le remet à 0. Le tableau évolue de reading[0] à reading[6].

-On calcul la valeur moyenne du tableau reading[].

-On envoit la moyenne au moniteur série.

 

 

 


 

5. Programmation Python (Spyder)

 

Spyder est un environnement de développement pour Python qui intègre de nombreuses bibliothèques à usage scientifique tel que « Matpolib » que nous importons afin de pouvoir tracer notre graphique en forme de polygone.

 

Préparation:

Si le module du port série n’est pas installé, vous obtiendrez ce message d’erreur: “No module named serial”. Cela est dû au fait que le port série n’est pas directement inclut avec python

Pour ce faire il a fallu l’installer  à l’aide de la ligne de commande « pip install pyserial » dans Anaconda Prompt*:

 

*J’ai installé Anaconda Navigator qui regroupe en quelque sorte tous les fichier dont a besoin Spyder pour fonctionner

 

Afin d’accélérer la vitesse de transmission du port série, il a fallu modifier le réglage de la vitesse de transmission du port associé (dans notre cas COM6). Réglé de manière générale à 9600, je l’ai accéléré à 38400!

Il est également important de ne pas oublier de renseigner ce paramètre dans le code Arduino et Python!

 

 

 

 

 

 

 

Code Python utilisé dans le projet:



 

J’ai mis des commentaires un peu partout dans le code pour ne pas s’y perdre et comprendre l’application générale du programme. Sachez qu’une fois les données du port série récupérées, il est possible de créer plus ou moins n’importe quelle interface graphique à l’aide de code trouvable sur internet. Dans notre cas, il s’agit du diagramme de Kiviat.

 

 

Démonstration du fonctionnement du programme:

 

Lorsque nous lançons le logiciel Spyder, celui-ci affichera dans la console la chose suivante:

 

Nous pouvons ainsi lancer l’exécution de fichier depuis le bandeau général du logiciel (voir icône au centre du cercle rouge)

 

Il faudra ensuite renseigner les bons paramètres:

  • « start » : lance le processus d’acquisition
  • le nombre d’image crée avant la temporisation
  • L’intervalle de temps en secondes entre 2 acquisitions

Remarque:

La saisie des données (nombre d’acquisition et intervalle de temps) est limité à une valeur de 255. Cette valeur limite est du au fait qu’elle est est envoyé sous forme de caractère. Lors de son envoi sur le port série, elle est encodé sous forme de table Ascii qui contient 255 valeurs.

 

 

Après avoir renseigné les paramètres nécessaire, le programme en Python va générer un graphique correspondant aux différentes valeurs des photodiodes relevées.

Nous affichons le numéro de l’image (ici 0 puis 1 puis 24)pour connaitre l’avancée de l’acquisition ainsi que les valeurs mesurées par les photodiodes.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Lorsque le bon nombre d’acquisition est atteint, la temporisation dure le nombre de seconde indiqués (ici 10s) puis recommence à effectuer les acquisitions et ainsi de suite.

 

 

Pour arrêter la console, il suffit d’appuyer sur le bouton suivant:

 

 

Une fois la console arrêté, il faut redémarrer le noyau puis relancer l’exécution du fichier.

 

Si nous ne redémarrons pas le noyau un message d’erreur viendra. Il indiquera un problème au niveau du port série.

En effet, le fait d’interrompre la console, le port série reste en quelque sorte ouvert et ne se referme pas. Cependant il est difficile de le refermer efficacement puisque la seule solution serait d’écrire quelque chose de bien définit dans la console qui exécuterait ensuite une instruction fermant le port série; seulement le défilement des images générés rend impossible la saisie (où alors uniquement lorsque la pause entre 2 acquisitions se réalise). J’ai alors opté pour l’interruption et le redémarrage du noyau. Cette solution ne prend pas beaucoup plus de temps, et n’ayant pas de contrainte défini dans le cahier des charges, cette méthode peut-être validé!

 

Une image en extension png  identique à celle présente dans la console est aussi crée dans le dossier ou se trouve le fichier Python et ceux à chaque acquisition. Cependant, seul la dernière image (celle avant la temporisation) n’est vraiment accessible puisque les autres, dès que crées, sont aussitôt écrasés par celle d’une nouvelle acquisition.

 


 

5. Serveur MQTT

L’Intérêt de créer un serveur MQTT était de pouvoir bénéficier d’une interface à distance qui aurai permis de lancer les acquisitions à distance et récupérer les valeurs sans devoir être connecté a un PC. Pour cela Gaetan a créé un serveur local sur son PC via le broker Mosquitto. Nous avons réussi à obtenir des résultats en interconnectant deux PC avec un câble ethernet: nous avons réussi à nous connecter à un topic et pu lire et publier sur celui-ci via l’interface de commande Windows.

Voici l’initialisation du serveur sur le premier PC

 

 

On peut ensuite publier sur un topic de test via un second PC pour vérifier que le serveur fonctionne

 

 

Un souscripteur au topic va pouvoir lire le message envoyé depuis le second PC

Il faut maintenant pouvoir connecté notre Arduino à ce serveur MQTT.

Pour cela on va utiliser un shield ethernet pour le connecté sur le même réseau local que le serveur.

On doit alors ajouté les bibliothèque Arduino liés au protocole MQTT pour la communication entre l’Arduino et le serveur ainsi qu’une bibliothèque ethernet pour interagir avec le shield.

Ci dessous le code permettant à l’Arduino de se connecter au serveur MQTT et souscrire à un topic :

Nous avons malheureusement été contraint d’abodonner le serveur MQTT à cause d’un manque de matériel, nous n’avions qu’un shield ethernet pour l’Arduino alors que nous avions besoin d’un shield Wi-Fi ( rupture de stock depuis plusieurs mois ) qui nous aurai permis de nous connecter à distance au réseau local. Dans un souci de respect des délais Gaetan a décidé de travailler sur le support.

 


6. Support

Dans un premier temps nous avons créé la partie principale du support qui va maintenir le laser et diriger le faisceau vers le bas. Il est constitué d’un tube ainsi que d’un capuchon réalisé à la découpe laser.

 

 

 

 

 

 

 

 

 

On a ensuite constitué une plateforme pour positionner l’Arduino, le tout est surélevé à l’aide de baguette en bois pour que le tissu placer en dessous puisse réfléchir la lumière du laser sur l’anneau de photodiode.

On place alors une « jupe » sur la structure afin d’isoler l’anneau de photodiode de toute lumière exterieur qui risque de perturber les résultats.

L’ensemble de la structure à été réalisé à la découpe laser.

Le support est léger donc facilement déplaçable au dessus d’un tissu cependant il est très fragile.

 


7. Avancé du projet

Le schéma électrique ainsi que son montage fonctionne correctement.

La partie concernant la programmation Arduino & Python à été entièrement réalisé.

Le circuit imprimé ne fonctionnant pas, j’ai décidé de prendre l’initiative d’assembler moi-même les composants sur une plaquette que j’ai découpé moi même. Bien que cette solution ne soit pas très soigné, cette solution permet ainsi l’acquisition des données et de « sauver » le rendu final du projet.

L’idée du serveur MQTT a été abandonné.

Le circuit imprimé à été réalisé mais ne fonctionne pas.

 

8. Conclusion

 

La partie concernant la programmation Arduino & Python à été entièrement réalisé et son principe fonctionne correctement. Cependant, il peut encore être perfectible en simplifiant peut-être encore les codes et améliorant encore certaines choses (ex:vérifier les saisies rentrées par les utilisateurs, simplifier l’arrêt et le redémarrage des acquisitions)

Le circuit imprimé ne fonctionnant pas, j’ai décidé de prendre l’initiative d’assembler moi-même les composants sur une plaquette que j’ai découpé moi même. Bien que cette solution ne soit pas très soigné, cette solution permet ainsi l’acquisition des données. J’ai pu approfondir mes connaissances en language c++ et découvrir le langage python.

Devant réaliser des tâches qui ne me concernait pas à l’origine, j’aurai pu perfectionner les codes que j’ai écris avec ce temps de perdu.

Grace à ce projet nous avons pu apprendre à utiliser de nouveaux logiciels,  de nouveaux langages de programmation, nous avons pu rencontrer de nouveaux matériaux (photodiodes).  Mais il faut avant tout savoir faire preuve d’esprit critique  savoir ce qui a fonctionné c’est bien, savoir ce qui n’a pas marché et pourquoi c’est mieux.

 

Nous avons accumulé beaucoup de retard ce qui nous a fait perdre toute notre marge d’erreur, nous avons accumulé du retard pour différentes raisons,  certains membres du groupe ont manqué d’organisation durant la durée du projet et ainsi empêché la finalisation du projet, il y a aussi eu un manque de communication dans l’équipe.

Il faut donc garder à l’esprit les erreurs que l’on a commises lors de ce projet afin de ne plus les reproduire dans le futur .

 


9. Remerciement

Nous souhaitons tous les 3 remercier les professeurs pour les aides, les explications et les conseils qu’ils nous ont fournis. Nous souhaitons également Christophe De Sabbata pour sa patience et son aide.


Surveillance d’une imprimante 3D et re-bobinage de bobines de matière

 

L’équipe ayant réalisée le projet :

Johann GRINAN (GEII)

Jérôme WILLIG (GEII)

Hugo MACCAGLIA (GMP)

Jonathan MEISTER (GMP)

Noémie HARDY (GMP)

 


Sommaire

                                         1. Introduction

2. Analyse fonctionnelle

3. Réalisation côté GEII

4. Réalisation côté GMP

                                         5. Conclusion

                                         6. Documents annexes

 

 


Introduction

 

 

L’impression 3D est l’appellation « grand public » des procédés de fabrication de pièces en volume par ajout ou agglomération de matière. L’impression 3D permet de réaliser un objet réel : un concepteur dessine l’objet 3D grâce à un outil de conception assistée par ordinateur (CAO). Le fichier 3D obtenu est traité par un logiciel spécifique qui organise le découpage en tranches des différentes couches nécessaires à la réalisation de la pièce. Le découpage est envoyé à l’imprimante qui dépose ou solidifie la matière couche par couche jusqu’à obtenir la pièce finale. Le principe reste proche de celui d’une imprimante 2D classique à cette grande différence près : c’est l’empilement des couches qui crée le volume.

De ce fait, cet outil est indispensable pour les étudiants du département Génie Mécanique et Productique (GMP) afin de réaliser tous types de pièces, et donc l’IUT en possède quelques unes. Cependant, les professeurs de ce département nous ont rapporté un problème à l’utilisation de leurs imprimantes : Les temps d’impression étant long (peuvent durer des jours), aucun moyen de supervision n’est mis en place pour contrôler cette machine, notamment pendant les weekend. De plus, il arrive que parfois, la matière ne s’empile pas comme on le souhaiterait et donc non seulement la pièce à imprimer n’est pas aboutie, mais en plus, de la matière est consommée « pour rien », entraînant des coûts supplémentaires.  Vous trouverez donc, ci-dessous, comment nous avons procéder pour la réalisation d’un tel projet.

 


 

Analyse fonctionnelle

 

 

Cahier des charges (CdCF) :

Intégrer un système de commande à distance (supervision) pour une des imprimante 3D du département GMP comprenant :

  • La possibilité de voir en temps réel (+ ou – 5 min) l’état de l’impression en cours, et pour y arriver, devoir d’abord allumer la lumière en actionnant un bras mécanique qui ira appuyer sur le bouton concerné de la machine
  • Pouvoir arrêter le système en cas de mauvaise impression pour limiter les dégâts

La partie mécanique (support de la caméra + bras mécanique) sera réalisée par les étudiants du département GMP

La partie électrique (supervision, câblages, intégration de l’informatique embarquée) sera réalisée par les étudiants du département GEII

Expression du besoin :

 

Diagramme des interactions :

Diagramme FAST :

 

Estimation coût projet :

 

L’IutLab (Le FabLab de l’Iut) nous a fourni tout le matériel.

 


 

Réalisation côté GEII

 

 

I.  Initialisation du Raspberry Pi

Nous avons reçu un Raspberry Pi 3 sans système d’exploitation, il a donc fallu formater une carte microSD et en télécharger un dessus. Nous avons fait le choix de prendre Raspbian, mais il en existe une variété comme Ubuntu, Fedora, etc.

Voici à quoi ressemble l’environnement de travail :

 

Il faut brancher un clavier, une souris, un écran sur le Raspberry, il est donc plus pratique pour nous de travailler depuis l’ordinateur, ce qui nécessite la prise à distance de celui-ci.

Pour avoir accès à l’invite de commande du Raspberry depuis l’ordinateur, nous avons utilisé le logiciel Putty basé sur du SSH qui sécurise la connexion à distance.

Il suffit de rentrer l’adresse IP du Raspberry dans le champ « Host Name ». Celle-ci peut être connue via la commande « ifconfig » sur le Raspberry ou « ipconfig/all » sur l’ordinateur.

Il faut ensuite rentrer des identifiants paramétrables depuis le Raspberry. De base, id : pi et pwd : raspberry

 

Cette technique permet uniquement d’avoir accès à l’invite de commande depuis l’ordinateur. Pour avoir son interface graphique, nous avons utilisé le logiciel « VNC Viewer ».

 

Il serait aussi avantageux de pouvoir envoyer des fichiers depuis l’ordinateur vers le Raspberry sans passer à chaque fois par la carte microSD. L’utilisation du logiciel « Filezilla » utilisant le protocole SFTP nous a été d’une grande utilité.

Sur la partie gauche, vous trouvez les fichiers présents sur votre machine et à droite sur celle à qui vous voulez l’envoyer.  Comme toutes les connexions à distance réalisées ci-dessus, il vous faut l’adresse IP du Raspberry.

Comme nous allons réalisé notre programme en python, il faut installer l’IDE. La commande Linux permettant de faire cette action est « wget ». Il a fallu donc nous familiariser avec les commandes principales sur Linux.

Comme pour tout autre langage de programmation, l’installation de librairies est indispensable. Voici la liste des nos librairies :

  • « paho.mqtt.client » pour la communication en MQTT
  • « RPi.GPIO » pour piloter les GPIO (pin du Rpi) comme sur un Arduino par exemple
  • « time » pour les tempos

II.  Compréhension du python et du protocole MQTT 

 

Nous avons fait le choix de programmer en python sur le Raspberry. Ce langage de programmation nous offre des fonctionnalités comme :

  • créer des interfaces graphiques

  • faire circuler des informations au travers d’un réseau

  • dialoguer d’une façon avancée avec votre système d’exploitation

 

C’est grâce à lui que l’on va interpréter les messages reçus en MQTT. Mais au fait, qu’est ce que le MQTT ?

 

MQTT (MQ Telemetry Transport) est un protocole de messagerie publish-subscribe basé sur le protocole TCP/IP. Comme nous le voyons sur l’image, un capteur va, par exemple, envoyer ses données sur un topic spécifique via le broker MQTT et les appareils abonnés à ce topic pourront recevoir ces données.

Avantages : Ceci prend en compte une de nos principales contraintes : l’ouverture d’un port à l’UHA n’est pas autorisé pour des raisons de sécurité. Si nous faisons un serveur sur le Raspberry, nous pouvons que consulter la page depuis le réseau local, ce qui n’est pas pratique et ne répond pas au cahier des charges. Or, en passant par le broker : « test.mosquitto.org » les messagent transiteront par celui-ci ce qui résout le problème.

Voir doc. annexes pour le code en python stocké sur le Raspberry

 

III. Câblage électrique Raspberry

 

Schéma de câblage du servomoteur.

 

Le Raspberry ne fournissant pas assez de courant sur ses GPIO, il a fallu rajouter une alimentation externe à pile pour que le servomoteur reçoive assez de courant, sinon des vibrations peuvent apparaître. Attention à bien brancher la masse du Raspberry avec la borne négative des piles, et celle du servomoteur ensemble pour avoir le même référentiel.

Actuellement, nous branchons les différents composants électroniques via la « breadboard » afin d’effectuer les tests, et par la suite, les composants seront soudés les uns aux autres et placés dans une boîte isolée du milieu extérieur.

 

IV.  Mise en place de la supervision

 

Nous avons dû créer un serveur Node-Red sur IBM Cloud et un sur le Raspberry Pi pour éviter l’ouverture du port (1880) du Raspberry qui mettrait le réseau de l’IUT en danger, car même sécurisé, la présence de failles peut être rapidement décelée par autrui.

Comment cela fonctionne et communique ensemble :

Sur IBM Cloud (génération de requêtes + affichage résultat de celle-ci si besoin) : Mise en forme de l’interface graphique visible par l’utilisateur qui va générer des « requêtes ». Ces dernières seront envoyées par le protocole décrit plus haut (MQTT) via un Broker. Il suffit donc d’avoir Internet pour envoyer des données.

Sur Raspberry (commande associée à la requête) : Réception des « requêtes » effectuées sur l’interface qui génère une action sur le Raspberry (ex : prendre une photo, mettre une sortie à 1 ou 0, etc…). Si besoin, nous renvoyons le résultat (toujours par MQTT) sur le Cloud (ex : l’image prise par le Pi qui a été convertie en base64).

 

Node-Red permet de créer une interface graphique très facilement par l’intermédiaire de blocs appelés « node » mappés entre eux (voir ci-dessous). Il s’installe sur Raspberry mais comme nous ne voulons pas faire de serveur dessus il faut passer par un Cloud. Le seul que nous avons trouvé permettant une utilisation gratuite est IBM Bluemix.

 

Notre « Flow » tournant sur le Cloud (voir doc. annexes pour le programme) :

Notre « Flow » tournant sur le Raspberry (voir doc. annexes pour le programme) :

 

Si les Nodes MQTT restent à l’état « connecting », changez le broker utilisé. Vous pourrez trouver sur Internet une liste de broker en ligne, en voici une liste : 

  • iot.eclipse.org
  • broker.hivemq.com
  • test.mosquitto.org
  • test.mosca.io
  • broker.mqttdashboard.com

 

L’interface actuelle pour notre supervision :

Note : L’information de la température de la CPU peut paraître inutile mais grâce à elle, nous savons si Node-RED Cloud et Node-RED sur le Raspberry communiquent bien entre eux, ce qui permet de gagner du temps pendant la maintenance en cas de problème.

 

Boitier de protection réalisé à l’aide d’une imprimante 3D :

Afin de créer une boîte sur mesure qui assurera la protection de l’électronique intégrée, nous avons procédé par CAO et réalisé le boîtier grâce à une imprimante 3D:

 

 


 

Réalisation côté GMP

 

Conception des supports de fixation :

I. Support de caméra

Ci-dessous, l’ancienne puis la nouvelle conception du support

 

 

Dans l’ancienne solution, les 2 pattes venant se glisser derrière la vitre risquant d’être trop fragile, nous les avons donc remplacés pas une seule.

Nous avons décidé de réaliser le support de la caméra en impression 3D. En effet les contraintes sur ce support étant faibles, le PLA est suffisamment résistant pour supporter le poids de la caméra.

La caméra est fixée avec du scotch double face sur la paroi.


II. Réalisation du support amovible du doigt motorisé

 

 

 

 

 

 

 

 

 

 

 

 

 


Vue d’ensemble du système de fixation

 

Graphe des liaisons :

 

 

 

 

III. Réalisation des pièces à l’atelier :

  • Sur machine CN à découpe jet d’eau :

Support moteur                                                                                                                                               Support axe

La programmation de la machine jet d’eau se fait directement depuis le poste machine. Il faut transférer le fichier .dxf contenant le profil que devra suivre la buse de la machine pour le transformer ensuite en trajectoire.

  • Sur machine traditionnelle :

Débitage du brut pour l’axe                              Usinage en pince de l’axe                          Fraisage de la rainure de passage du moteur

 

 

Les trajectoire d’entrée de la découpe jet d’eau ont dû être ébavurés ainsi que toutes les arrêtes vives.

 Modification du cahier des charges :

Changement du cahier des charges durant le projet. Ce changement est de pouvoir appuyer sur les boutons de l’imprimante manuellement sans avoir à faire pivoter le bras pour accéder aux boutons.

De ce fait nous avons usiner deux boutons venant se fixer derrière les vis de pression permettant d’appuyer sur les commandes de l’imprimante par l’intermédiaire des vis de pression.

Nous avons usiné les boutons en laiton pour plus d’esthétique, avec un léger arrondi pour améliorer l’ergonomie.

Montage du système

 


Conclusion

 

Situation actuelle :

Supervision permettant de :

  • Piloter le système conçu par les GMP avec le servomoteur
  • Envoyer une image sur un mail à sélectionner
  • Envoyer une image sur l’interface directement
  • Suivre les actions effectuées grâce à un journal d’évènement

 

Nous avons également intégré une sécurité pour notre microcontrôleur :

  • Mise en marche d’un ventilateur si la température de la CPU dépasse 50°
  • Arrêt du Raspberry si la température de la CPU dépasse 80°

 

Connaissances générales acquises :

  • Gestion de projet : Savoir respecter un cahier des charges, dans les délais et coûts souhaités
  • Humain : Dialoguer avec un autre corps de métier et se mettre d’accord sur les façons de réaliser un système
  • Programmation : Capacité d’adaptation notamment en python qui est un langage de programmation très convoité en industrie
  • Technique : Capacité à surmonter et résoudre des problèmes techniques, pouvant retarder le projet, et donc être rapide et efficace dans la recherche d’information

 

Le fait d’avoir pu répondre au cahier des charges nous a permis de voir notre projet fini, ce qui est d’autant plus motivant pour nous :

 

 


Documents annexes

 

Vous pourrez trouver ci-dessous des procédures utiles concernant le projet (méthodes à appliquer, erreurs à éviter…) ainsi que nos programmes :

Procédures pour Node-RED :

 

Création compte IBM

Duplication de notre Flow

Redémarrer le serveur IBM (tous les 10 jours en version gratuite)

Sélection du TOPIC MQTT via menu déroulant

 

Programmes python et Node-RED :

 

Programme python pour le servomoteur

Flow sur le Cloud

Flow sur le Raspberry

Flow pour la sélection via menu déroulant

 


AUTOM A TISE – Bar à cocktails

Equipe ayant travaillé sur le projet :

 

  • Julien Gruaux – GMP
  • Axel Sitterle – GMP
  • Nathan Zindy – GMP
  • Margot Daval – GEII
  • Nathan Mourant – GEII

Sommaire

I/ Présentation du projet
II/ Analyse fonctionnelle
III/ Réalisation côté GMP
IV/ Réalisation côté GEII
V/ Conclusion


I/ Présentation du projet

 

Depuis plusieurs années, l’automatique devient de plus en plus banales, aussi bien dans le milieu industriel que dans le quotidien, à travers la domotique. En constatant ce fait et voulant en profiter, des étudiants de deuxième année de l’an dernier avait eu pour projet de réaliser un bar à cocktail automatisé.
En se basant sur ce projet, les départements GMP et GEII de l’IUT de Mulhouse nous ont demandé de créer une nouvelle machine à cocktail automatisée pour pouvoir la présenter en démonstration lors des journées portes ouvertes de l’IUT. Au cours de cet article, nous allons donc vous expliquer notre travail pour réaliser ce projet avec une équipe composée d’apprentis GMP et d’apprentis GEII.

 


II/ Analyse fonctionnelle

 

A- Diagramme des besoins et des interacteurs

Afin de pouvoir établir un cahier des charges répondant à tous les besoins de la machine, nous avons commencer par faire un diagramme des besoins ainsi qu’un diagramme des interacteurs.
Les besoins de notre projet étant les mêmes que pour celui de l’an dernier, nous avons repris celui du projet de l’an dernier :

Il en est de même pour le diagramme des interacteurs :

FP : Fonction Principale
FC: Fonction Contrainte

B- Cahier des charges

Grâce aux diagramme ci dessus et en discutant entre nous, nous avons alors pu établir le cahier des charges suivant :


Flexibilité :
F0 : Flexibilité nulle – niveau impératif
F1 : Flexibilité faible – niveau peu négociable
F2 : Flexibilité bonne – niveau négociable
F3 : Flexibilité forte – niveau très négociable

C- Diagramme FAST

A partir du cahier des charges que nous avons établi grâce aux deux diagrammes précédents et nos discussions, nous pouvons maintenant établir un diagramme FAST pour notre projet :

D- Répartition du travail

Partie génie mécanique :

  • Choix des solutions techniques pour répondre aux attentes : Axel, Nathan Z. et Julien
  • Modélisation sur Créo : Nathan Z.
  • Choix des matériaux de la structure : Axel et Julien
  • Conception et mise en plan des pièces à usiner : Axel, Nathan Z. et Julien
  • Usinage : Axel, Nathan Z. et Julien
  • Assemblage : Axel, Nathan Z. et Julien

 

Partie génie électrique :

Les deux apprentis GEII ayant chacun déjà eu des diplômes dans des domaines différents avant de reprendre leurs études en GEII, la répartition du travail entre eux s’est fait selon leurs parcours. En effet, nous avons cherché à tirer profits de cela pour identifier les points forts de chacun au moment de répartir le travail pour nous montrer plus efficace. Ainsi, Nathan M. ayant déjà des compétences dans le domaine mécanique, choisir les moteurs pour le projet ou s’occuper du calcul de dimensionnement électrique sont plus simples à faire pour lui. Sur le même principe, la programmation du Raspberry et de l’IHM sont plus simple pour Margot qui a déjà des compétences en programmation. On obtient alors la répartition du travail suivante :

  • Choix du moteur et des capteurs : Nathan M.
  • Dimensionnement électrique : Nathan M.
  • Installation électrique et câblage : Nathan M. et Margot
  • Programmation Raspberry : Margot
  • Réalisation et programmation IHM : Margot
  • Rédaction du dossier : Margot

Cependant, Nathan M. ayant démissionné de la formation en début du deuxième semestre après plusieurs semaines d’absence, la répartition du travail a été complètement bouleversée pour faire face au départ de Nathan M. et au retard dû à son absence.
Cependant, pour ne pas abandonner le projet ou le laisser inachevé, il a été convenu qu’un binôme de première année en GEII continuerait à travailler sur le sujet durant leur temps de projet.


III/ Réalisation côté GMP

Ce projet est issue de la récupération d’ancien objets inutilisés sauf pour les moteurs, les pompes péristaltiques et les doseurs-bouteilles. Les pièces spécifiques comme les pignons des moteurs ou encore le support pour le verre, on été dessinées et imprimées en 3D par nos soins.

A- Plateau mobile

1.) Le plateau et son moteur

Tout est partie de la récupération d’une imprimante ayant un plateau motorisé. Ce plateau guidé à l’aide de deux glissières est le parfait élément pour commencer notre projet de bar automatisé,
alias AUTOM-A-TISE.

Le but étant d’avoir un plateau où l’on puisse déposer le verre. Ce plateau va ensuite se translater pour positionner le verre en dessous des différentes stations, à savoir deux stations avec doseur-bouteille et une station avec l’arrivée de liquide venant des pompes péristaltiques.

 

Nous avons dessinée un schéma cinématique pour définir les différents liaisons à mettre en place pour l’installation des différents éléments.

Schéma cinématique :

Il a fallut placer le moteur sur le bâti avec un système de courroie et de tendeur pour transmettre la rotation du moteur au plateau.

Liaison du moteur au plateau (à l’aide de deux vis + une rondelle et équerre de fixation) :

 

Conception du pignon du moteur sur Creo :

2.) Le support pour le verre

Le support a d’abord été dessiné sur Creo, il est en trois pièces :

  • un socle central intégrant l’emplacement pour un capteur de présence verre.
  • deux pattes extérieurs qui vont venir appuyer le verre de part et d’autre pour le maintenir en position à l’aide de ressorts.

Il a été imprimé grâce à l’imprimante 3D puis les ressorts on été formé à la main.

Le support-verre durant sa conception :

Réalisation finale :

B- Le poussoir pour doseur-bouteille

Nous sommes partis d’une base trouvée dans le local des pièces usagées de l’IUT à côté de l’IUT LAB. C’est un rail, dont la position était probablement codée, avec un coulisseau qui possédait un système pneumatique.

Nous avons décidé de placer une crémaillère à l’intérieur de ce rail pour pouvoir utiliser le coulisseau comme poussoir. Le moteur sera fixé sur le rail fixe et la crémaillère sur le coulisseau qui sera mobile.

Nous avons d’abord conçu le pignon du moteur sur Creo, puis la crémaillère en récupérant l’empreinte du pignon. Nous avons envoyé ces pièces pour l’impression 3D, l’impression de la crémaillère s’est fait sur le flanc pour obtenir une fibre se dirigeant dans le sens des efforts des dents du pignon.

 

Assemblage final du système de crémaillère à l’intérieur d’un profilé aluminium :

 


IV/ Réalisation côté GEII

 

A- Choix des moteurs, capteurs et dimensionnement électrique

L’un des objectifs que nous nous étions fixé au moment du dimensionnement électrique était de limiter au maximum le nombre de prise nécessaire au fonctionnement du bar à cocktails automatisé par soucis de praticité. Le bloc secteur d’alimentation de la Raspberry Pi étant déjà fourni, nous avons alors penser à utiliser une multiprise classique à l’intérieur de la machine afin de pouvoir y brancher tous les différents éléments nécessaires tout en assurant la nécessité d’un seul branchement extérieur au bar à cocktails pour son fonctionnement.

Pour limiter les dépenses mais aussi le câblage et l’alimentation nécessaire, nous avons également opté pour des moteurs pas à pas. Comme nous utilisons une carte HAT Adafruit pour Rasberry Pi permettant de piloter des moteurs continus et pas à pas, nous avons rapidement décidé de prendre des moteurs de la même marque. Les moteurs devant être capable d’aller dans les deux sens, et la carte de pilotage pouvant être alimentée jusqu’à 12V, nous avons alors opté pour des moteurs pas à pas de 12V et de couple 20N*cm. Il compte 200 pas par révolution et chaque angle de pas est de 1,8 degré. La première bobine est reliée aux câbles rouge et jaune, et la seconde bobine aux câbles vert et gris.

On compte deux moteurs identiques, l’un qui permettra de faire avancer le plateau et le deuxième qui assurera la montée et la descente du mécanisme activant les doseurs des bouteilles. Ils seront tous les deux alimentés par la carte HAT, elle-même alimentée en 12V. Pour raccorder la carte HAT à celle de la Raspberry, il suffit de placer les connecteurs 2×20 femelles de la carte de pilotage des moteurs sur ceux 2×20 mâles de la carte Raspberry Pi, réalisant ainsi un nouvel étage. Nous vous proposons ci-dessous le schéma de câblage des moteurs et de l’alimentation sur la carte HAT de pilotage.

Attention cependant, la carte HAT prenant tous les connecteurs 2×20 de la carte Raspberry Pi, l’alimentation de l’écran de cette dernière doit également se faire via la carte HAT d’Adafruit une fois cette dernière connectée. L’écran étant alimenté en 5V, comme la Raspberry Pi, il faut alors utiliser un connecteur 5V et un autre GND disponibles sur la carte HAT.

Concernant les capteurs, l’utilisation de moteurs pas à pas nous permet de nous passer de capteurs de position. L’idée d’un capteur à contact, pour s’assurer de la présence d’un verre dans la machine, a fini par être abandonnée par manque de temps. Un emplacement pour un capteur à contact à pourtant été prévu dans la structure du socle pour le verre, ce qui permet un éventuel ajout par la suite.

Au niveau des alimentations nécessaires, il nous faut donc une alimentation de 5V pour la Raspberry Pi et son écran tactile, et une alimentation de 12V pour la carte HAT de pilotage des moteurs Adafruit, qui s’occupera d’alimenter les deux moteurs pas à pas. Le bloc secteur pour l’alimentation de la Raspberry Pi est déjà fournie, il ne nous reste donc plus qu’à utiliser un autre bloc secteur de 12V pour l’alimentation de la carte HAT.

B- Programmation de la Raspberry

Il a été choisi dès le début du projet de piloter le bar à cocktails automatisé grâce à une Raspberry Pi. C’est donc sur cette dernière que nous devions programmer. Bien que le Python reste son langage de développement « natif », il reste possible de développer un programme dans plusieurs autres langages. Cependant, avant de commencer le développement d’un programme ou même de choisir son langage de développement, nous avons d’abord travailler sur l’algorithme du programme afin de connaître les éventuelles contraintes ou libertés de choix possibles. Par exemple, les deux moteurs n’étant jamais actif en même temps, un système multitâches n’était pas obligatoire pour la programmation.

Une programmation du bar à cocktails grâce à l’outil Node Red a été envisagé durant un moment. En effet, l’utilisation de Node Red permettait de piloter les pins GPIO de la Raspberry Pi pour les moteurs, mais aussi de rendre le bar à cocktails connecté grâce à l’interface de Node Red. De plus, la gestion de l’IHM devenait bien plus simple à faire, se créant grâce au programme. Cependant, pour rendre le bar à cocktails connecté, une connexion internet était nécessaire, ce qui peut ne pas être forcément possible partout. De plus, la sauvegarde d’un projet nécessite un import puis un export de flux, ce qui ne permet pas de rendre le bar à cocktails prêt à l’utilisation sans la recréation d’un projet et l’export du programme développé. Pour finir, Node Red utilise exclusivement du langage javascript, langage avec lequel nous n’étions pas à l’aise. Et le manque de temps nous empêchait de faire une remise à niveau suffisante pour le développement du projet.

Le choix d’une carte HAT d’Adafruit, permettant le pilotage de moteurs pas à pas ou continus (jusqu’à deux moteurs pas à pas ou quatre moteurs continus), nous a permis d’opter pour une autre solution de développement. En effet, la carte HAT était livrée avec une librairie Python déjà existante permettant le pilotage des différents moteurs pouvant être connectés à la carte, ainsi que des petits programmes de tests de fonctionnement pour chaque type de moteurs. Le langage Python ressemblant énormément au langage C, vu durant la première année de GEII, son utilisation était alors beaucoup plus intuitive et aisée que celle du javascript. De plus, cela étant le langage « natif » de la Raspberry, nous étions sûr de ne pas avoir de problèmes d’interprétation du script. Malheureusement, l’utilisation d’un script en Python nous faisait renoncer au côté connecté du bar à cocktails et nous obligeait à trouver une autre solution pour l’IHM.
Pourtant, par manque de temps pour le développement du programme, le script en Python fut la solution retenue pour le projet. Son développement a donc être pu fait assez rapidement, bien qu’il manquait le nombre de pas nécessaire aux moteurs pour les déplacements demandés. Par manque de temps également, le pilotage de la pompe péristaltique n’a pas pu être fait et ajouté au programme.

Ainsi, voici la partie principale du programme développé pour le projet :

Comme on peut le voir sur la capture d’écran, le programme a été entièrement commenté afin de faciliter le travail d’autres personnes pouvant avoir à modifier le code si le projet est repris par la suite.

Malheureusement, suite à un problème technique avec les connecteurs 2×20 de la carte HAT, il nous a été impossible de réaliser les tests concernant le nombre de pas nécessaires aux moteurs pour les divers déplacements. Pour la même raison, et n’ayant pas toutes les données nécessaires, il n’a pas été possible de tester le programme du bar à cocktail dans son intégralité.

C- Ce qu’il reste à faire

Dû fait de la démission de Nathan M. du DUT GEII et du retard déjà accumulé avant son départ, le projet n’a pas pu être terminé du côté électrique malgré notre envie d’aller jusqu’au bout. Cependant, pour palier à ce problème, qui semblait déjà inévitable au moment de la démission de Nathan M., il a rapidement été convenu que le projet serait repris par un binôme de première année en DUT GEII pour faire en sorte de le finir.

La première mission qui était prévue de leur confier était le câblage des différents éléments de la machine. C’est d’ailleurs également pour cette raison que nous avons tenu a essayé de le limiter au maximum, afin de faire en sorte qu’ils perdent le moins de temps possible sur cette tâche.
En plus du câblage, et suite au problème technique survenu lors de la phase de test de la carte HAT Adafruit, ils devront également s’occuper de mettre en place la nouvelle carte de pilotage en place et tester le nombre de pas nécessaires aux moteurs pour les divers mouvements. Une fois cela fait, ils pourront alors rentrer les valeurs trouvées dans le programme déjà prêt pour le pilotage du bar à cocktails et tester ce dernier.
Pour finir, ils pourront également modifier ce programme afin d’y intégrer la gestion de la pompe péristaltique prévue dans la machine.

Enfin, concernant les améliorations possibles s’ils ont le temps ou si le projet est également repris alors leur travail, il peut être intéressant d’ajouter un capteur à contacts pour s’assurer de la présence d’un verre sur le socle, comme nous pensions le faire au départ.
Il peut également être possible d’adapter le code pour une utilisation de Node Red afin de pouvoir rendre le bar à cocktail connecté et avoir une IHM convenable. Le développement d’une IHM semble être aussi une bonne piste d’amélioration du projet actuel.


IV/ Conclusion

Malgré les différentes difficultés rencontrées, nous avons pu aboutir à une réalisation mécanique fonctionnelle et avancé au maximum la réalisation électrique et informatique. Cette dernière sera transmise à un binôme de première année de GEII afin de la finaliser. Pour leur permettre une plus grande facilité de câblage, nous avons donc choisi de ne pas figer les éléments électroniques du projet sur le système.

Le projet reste malgré tout améliorable, et des perspectives d’évolutions peuvent être envisagées. Il nous a permis de travailler en équipe tout en partageant nos idées et nos connaissances.

Notre projet s’inscrit dans une démarche économique, où la récupération de matériaux et autres éléments récupérés au stock des pièces usagés de l’IUT Lab a été essentielle. Les implantations des différents éléments sur le système de base (imprimante) a développé notre capacité d’adaptation.

 


Banc d’acquisition pour un système de vision

BANC DE VISION


Contrôle visuel de pièces

 

Notre Groupe :

FREUDENREICH Theo – BENSCH Dylan – MEYER Virgile


Un contrôle métrologique n’est pas toujours nécessaire afin de vérifier qu’une pièce soit conforme. Il est également possible de réaliser un contrôle visuel, à l’aide d’une caméra industrielle permettant de faire des prises de vue rapides, qui seront traitées par un logiciel. Notre projet s’inscrit dans le contrôle de pièces brutes de fonderie, un tel contrôle visuel est donc suffisant.

Nous réaliserons le banc sur lequel sera fixé une caméra. Ce banc devra pouvoir tourner autour de la pièce en question pour prendre différents angles de vue et contrôler la pièce.


Sommaire :

  1. Cahier des charges
  2. Solution retenue
  3. Conception
  4. Réalisation et montage du banc
  5. Motorisation de l’arc

1.Cahier des charges

Expression du besoin:

Le Banc de vision est destiné à un industriel. Il permet de prendre différentes prises de vues d’une pièce, sans intervention humaine,  à l’aide d’une caméra.

 

 

 

 

 

 

 

 

Diagramme des intéracteurs : 

 

Cahier des charges : 

Il présente succinctement les différents critères à respecter lors de la fabrication du banc :

2.Solution retenue : 

 

  • La caméra est fixée sur le chariot, qui permet son déplacement sur l’arc
  • L’arc, relié à un axe et un moteur pas à pas, va permettre de tourner autour de la pièce
  • La bille sous l’arc permet de diminuer la charge appliquée sur l’axe
  • Le bâti réalisé en profilés Bosch, permet de supporter l’ensemble.

 

 

 

 

 

 

 

3.Conception

Vue d’ensemble:

Plans Axe:

Plan Arc:

 

Plan chariot:

Vue éclatée du chariot :

Plan :

4.Réalisation et montage du banc

A l’exception des éléments standards liés aux profilés Bosch (équerres, cubes de liaison) et la poulie fixée sur l’axe, nous avons réalisés les pièces à l’atelier du département GMP.

Usinage de l’axe: pièce la plus complexe car elle comprend des rainures et perçages difficilement réalisable avec des moyens dit conventionnels. Nous avons donc réalisé cette pièce sur le tour 6 axes DMG Alpha 500. Pour cela nous avons tout d’abord utilisé le logiciel de FAO Esprit.

 

C’était une partie extrêmement enrichissante dans notre projet, nous avons exploré les nombreuses possibilités qu’offre le logiciel Esprit et les machines d’usinage 6 axe. En effet nous avons utilisés la broche de reprise mais aussi des outils tournants radiaux et axiaux et toutes les procédures que cela implique.

Découpage des plaques et de l’arc: De nombreux composants de notre projet, sont issus de découpe dans des plaques d’aluminium, ces pièces ont étés découpées par jet d’eau. cette opération à été réalisée par M. Senn, car pour des raisons de sécurité la découpe jet d’eau n’est pas accessible en ce moment.

Montage : Montage de la transmission entre le moteur et l’axe :

Montage du chariot sur l’arc : Le taraudage M10 n’a pas pu être réaliser, une vis et un écrou maintiennent l’ensemble :

L’assemblage finale sur le bâti : Seul le taraudage afin de pouvoir assembler la bille de maintient en bas de l’arc n’a pas été réalisé, la bille n’est donc pas en place, il en résulte une flexion importante du bâti, ainsi qu’un effort important au niveau de l’axe que rend la rotation difficile.

5.Motorisation de l’arc

 

L’arc est motorisé à l’aide d’un moteur pas à pas. Il nous permet de ne faire qu’un certain angle avec l’arc, lorsque l’ordre en est donné.

Le moteur doit être relié à une carte de puissance, qui permet de l’alimenter, la arduino ne pouvant pas le faire elle même.

Nous avons décidé de diviser le tour par 45° afin d’offrir 8 points de vue différents.

Calcul du nombre pas nécessaires:

Le moteur pas à pas réalise 200 pas par tour. Soit 1.8° par pas. Comme l’on réalise une prise de vue tous les 45°, il faut faire 25 pas.

Le rapport de réduction entre les deux roues étant de 11/72, il faut donner une consigne de 25/0.1528=163.6 pas.

Le logiciel arduino contient une bibliothèque « Stepper » qui permet de contrôler directement les moteurs pas à pas, voici le programme réalisé :

  • Pour que le moteur tourne il faut que le bouton soit à 0L. En effet, le contact est tout le temps fermé, sauf lors de l’appuie sur le bouton où il va s’ouvrir.

Schéma du câblage :

6.Conclusion

Même si nous ne sommes pas arrivé au terme de notre Projet, celui-ci nous a permis de mettre en pratique un grand nombre des compétences et savoirs étudiés en DUT GMP. Ceci au travers de phases de conception, recherche de solution, de fournisseur et de réalisation. Nous avons utilisé une grande gamme d’outils technologiques, logiciels comme matériels.


Lyre pilotée par un arduino avec le protocole ArtNet

L’équipe ayant participé au projet :

  • LITZLER Nathan(GEII)
  • HAEGELIN Francois (GEII)
  • BAUMANN Jeffrey (GMP)
  • SCHIEBER Louis (GMP)

Sommaire

  1.  Présentation du projet
  2.  Analyse fonctionnelle
  3.  Réalisation électrique
  4.  Réalisation mécanique
  5. Conclusion

1. Présentation du projet

Créée en 1986, la norme DMX est toujours d’actualité chez les professionnels de l’éclairage et de l’événementiel. La raison ? Elle est économe en câbles : un cordon XLR DMX peut gérer 512 canaux au total. Sachant qu’un projecteur moyen peut être piloté par 1 à 15 canaux environ, une seule ligne DMX permet de couvrir la plupart des besoins en éclairage.
De plus, le DMX est un langage standardisé, qui fonctionne avec n’importe quel matériel d’éclairage au sens large, quelle que soit la marque : projecteur PAR, blocs de leds, strombes, machines à effet, lyres, etc.…
A chaque canal est affectée une valeur allant de 0 à 255, permettant de contrôler chaque paramètre avec précision. Depuis le logiciel ou la console, vous pourrez programmer des animations, les sauvegarder, les rappeler, les modifier…

Ayant un membre du groupe travaillant dans le milieu de l’événementiel et s’intéressant aux nouvelles technologies scéniques nous avons eu la curiosité de décrypter le DMX et ses trames. C’est pour cette raison qu’ayant l’opportunité de réaliser un projet entre GMP (Génie mécanique et productique) et GEII (Génie électrique et informatique industrielle) nous avons décidé de nous lancer dans la conception d’une lyre DMX afin de d’allier nos spécialités. Cette lyre low cost est donc la reproduction d’une lyre commercialisée créée de toutes pièces par nos soins et à moindres coûts. Vous découvrirez donc, ci-dessous, les étapes ainsi que la répartition de notre projet.

 

2.Analyse fonctionnelle

Cahier des charges

Réalisation d’une lyre commandée par un arduino comprenant :

  • L’envoi de trames DMX via le logiciel node managment utility
  • L’acquisition de trames DMX via un réseau Ethernet grâce à un boitier ENTTEC
  • La commande de 2 moteurs pas à pas
  • La commande de leds de différentes couleurs

 

Bête à corne :

FAST :

Estimation coût du projet :

MATERIEL QUANTITE A COMMANDER PRIX
Arduino mega 1 35€
Moteur pas à pas 2 30€
Ensemble de leds 1 20€
Shield de puissance 1 10€
Shield DMX 1 10€
Materiels éléctroniques fils, résistance, MOSFET 10€
TOTAL 105€

Les prix d’une lyre DMX variant de 160€  à 1500€ nous n’avons finalement pas économisé énormément au vu des heures passées sur le projet.

Répartition des tâches :

 


RÉALISATION ELECTRIQUE

1. Prise en main du DMX

Afin de bien commencer le projet nous avons du comprendre de quelle manière les trames DMX sont envoyés et découpés afin de les réceptionner de la meilleure façon.

Le protocole DMX512 est donc un protocole qui permet de contrôler 512 canaux en affectant à chacun d’entre eux une valeur entre 0 et 255.

La transmission se fait de façon sérialisée, ainsi tous les appareils esclaves recevront les 512 valeurs en même temps. Dans notre cas nous avons uniquement la lyre qui reçoit les trames donc les problèmes des 32 appareils maximum sur une même ligne DMX ne nous dérange pas.

Le principe de fonctionnement est relativement complexe cependant nous pouvons en retenir que la transmission se fait par un cable d’une paire blindée raccordé à des connecteur XLR de type 5 broches (seuls les 3 premières sont utilisés). La trame est envoyé 44 fois par seconde soit une fréquence de rafraîchissement de 44Hz.

La commande du protocole DMX se fait généralement via un pupitre plus ou moins complexes selon la taille de la scène et son utilités.  Pour nos essais nous utiliserons le logiciel Node Management Utility, qui est plus facile à prendre en main, afin d’envoyer les différentes valeurs sur les différents canaux.

Pour finir nous avons appris qu’une norme permettait d’éviter le câblage fastidieux. La norme nommée Art-Net est donc celle que nous utiliserons tout au long de notre projet, elle intègre les trames DMX dans des paquets Ethernet et simplifie le câblage.

2. Choix du matériel électrique

Le choix du matériel fut la partie la plus longue du projet puisque nous surmontions les problèmes de matériel au fur et à mesure que nous les rencontrions. Nous avons donc commencer la programmation avec un arduino UNO avant de nous rendre compte que celui-ci ne fonctionnait pas du fait qu’il n’a qu’un seul port série. Nous avons donc, par la suite, du faire évoluer notre Arduino UNO en Arduino MEGA.

Le membre de notre groupe travaillant dans l’événementiel ayant un spot lumineux a sa disposition nous n’avons donc pas eu besoin de choisir les leds, nous les avons simplement récupérées.

3. Connexion à l’arduino

Nous avons ensuite dû nous connecter à l’arduino avec le DMX afin d’acquérir les trames. Nous passerons donc par un boitier ENTTEC permettant la traduction des trames ART-Net en DMX512.

Une fois la trame acquise nous avons du comprendre comment la traduire afin de faire fonctionner les moteurs et les leds grâce aux instructions envoyées.

Nous nous sommes rendu compte qu’il fallait rajouter un module pour recevoir les trames DMX sur l’arduino. Ce schéma utilise donc un module qui comporte un MAX485 qui permet l’adaptation entre la carte arduino (0V-5V) et le protocole RS485. Le module MAX485 peut fonctionner en émetteur et récepteur, ici nous ne l’utiliserons que en tant que récepteur.

Attribution des bornes

DI Driver INPUT DE Driver output Enable
RO Receive OUTPUT RE Receiver ouptput enable
Vcc Alimentation 5V GND Masse 0V
A Data + B Data –

 

Une fois les trames acquises grâce au module nous avons créer un programme comprenant une librairies DMXSerial.h permettant de traduire ces signaux en sortie PWM afin de piloter le moteur et les leds.

Signal de sortie PWM :

Ainsi en fonction de la valeur envoyé sur les différents canaux les équipements esclaves fonctionneront comme décrit dans l’image ci dessus (la valeur 255 = 100%).

3. Programmation

Pour commencer nous avons programmer les leds et le moteur séparément avant des les intégrer dans le même programme.

Choix et câblage des leds:

Nous avons démonté le spot lumineux existant afin d’en récupérer les leds et définir quels seraient ses besoins énergétiques.

Les leds sont des PAR6_RGB 3 en 1 (Bleu rouge et vert) consommant 1W.

Afin de contrôler les led (alimentés en 12V) avec l’Arduino , une solution est d’utiliser des transistors Mosfets avec une résistance d’un kilo ohm comme ci-dessous sans oublier de mettre toutes les masses communes.

Câblage des leds RGB

Breadboard      Câblage des leds RGB

 

Programmation leds:

 

Choix et câblage moteur

Afin de limiter l’alimentation nécessaire, nous avons choisis des moteurs pas à pas. Utilisant un arduino pour contrôler ce moteur nous nous sommes renseignés auprès de l’IUTLAB sur la disponibilité des moteurs pas à pas. Les moteurs devant aller dans les deux sens et ne pouvant dépasser une alimentation de 12v, nous avons choisis des moteurs pas à pas de 12V.

Afin de contrôler ces moteurs grâce à l’arduino nous avons du rajouter un shield de puissance.

Enable : Allume la led du pin 13 de l’arduino pour signifier que la carte de puissance est en route

Step : Gère les pas du moteur

Direction : Gère le sens de rotation du moteur

VMOteur : Alimentation moteur

GND/Masse : Connexion à la masse

2B, 2A, 1A, 1B : Sorties du moteur

VDD : Alimentation 12v

 

 

Câblage finale avant intégration dans boitier

 

Programmation finale (moteur + leds):

Problèmes rencontrés:

  • Réception de la trame DMX et traduction du signal contrôler le moteur et allumer les leds

    >  Librairie DMXSerial pour acquérir les trames DMX et librairie STEPPER pour controler le moteur pas à pas

  • Faire tourner deux fonctions en simultanées sur l’arduino

     > Suppression de la fonction DMXSerial.dataUpdated()/DMXSerial.resetUpdated() qui permet l’attendre d’une mise à jour d’une trame

     > Utilisation de la fonction micros()

Améliorations possible:

  • Intégration d’un embout XLR mâle femelle pour améliorer l’esthétique de la connexion entre le shield DMX et le boitier Art-Net.
  • Création d’un programme gérant une interface DMX afin d’obtenir un show automatisé.
  • Mise en place d’un deuxième moteur avec son shield de puissance pour gérer la rotation horizontale des leds.
  • Intégration d’un circuit imprimé

 


RÉALISATION MECANIQUE

1. Choix de la motorisation et des transmissions

Après avoir défini le cahier des charges, nous avons retenu la solution des moteurs pas-à-pas. Ceux-ci ont la spécificité de pouvoir s’arrêter précisément. Cela nous permet donc de bien gérer la course de la lyre.

Notre lyre est composée de deux moteurs. L’un pouvant faire tourner le plateau sur l’axe verticale et l’autre, placé sur la plateau qui eut faire tourner le spot sur un axe horizontal. Ils sont fixé à l’aide de brides.

La conception de notre lyre c’est faites en deux parties. Nous avons tout d’abord commencé par concevoir le boitier principal. Il accueille tous les composants électroniques ainsi le premier moteur qui fait tourner le plateau selon l’axe vertical.

Notre première idée était une boite thermo pliée de 5 faces avec en plus un couvercle. Mais nous n’avons pas retenu cette solution pour des raisons d’étanchéité. Il aurait aussi été compliqué de fixer les composants sur le fond dû à une épaisseur de paroi trop faible. Nous aurions aussi rencontré des difficultés de montage dû au manque de modularité du boitier.

Notre deuxième solution était donc de faire chaque face indépendante l’une de l’autre. Cela nous a permis d’avoir un fond plus épais que les parois. De ce fait, nous avons opté pour une épaisseur de 10mm ce qui permet donc de percer et tarauder le fond pour pouvoir y fixer des composants. Réalisé par impression 3D, le fond du boitier a une forme carrée de 200 par 200mm comprenant différentes extrusions. Une première série d’extrusions sur les côtés qui permettent la mise en position des parois lors de l’assemblage. Puis 8 pattes de fixations intégrants des écrous montés serrés dans des logements hexagonales prévus à cet effet. Les parois latérales sont donc maintenues en position par des ensembles vis-écrous.

Dans l’hypothèse d’une production en série cette pièce aurait été réalisée en moulage par injection de matière plastique type ABS.

Pour les parois latérales nous avons décidé de faire les 4 parois identiques en épaisseur 3mm en PMMA. Elles sont munies de 4 trous de passage de vis destinés à leur maintien en position comme évoqué précédemment. Le fait de faire 4 parois identiques permet de ne pas chercher quelle paroi doit être montée à quel endroit. Un ordre de montage de ces parois n’est donc pas nécessaire. Chaque paroi a en revanche un sens de montage car elles ne sont pas symétriques, en effet pour obtenir une bonne finition au niveau des angles nous les avons fait se chevaucher successivement l’une sur l’autre.

Le couvercle quant à lui est muni d’une « corniche »  ce qui permet sa mise en position plus facilement. Il sera maintenu en position avec les parois de la même manière que le fond grâce à des pattes de fixation avec écrous intégrés. Cette partie du boitier aura également été effectué par impression 3D.

Sur ce couvercle est fixé un palier lisse réalisé en aluminium à l’aide d’un tour à commandes numériques. Celui-ci a pour but d’assurer la liaison pivot entre le plateau et le haut du boitier. Nous avons opté pour une liaison pivot par palier lisse car la liaison pivot devait également assurer le passage de câble du boitier vers le spot et le second moteur.

Donc c’est cet assemblage qui constitue cette première partie de la lyre.

Vient ensuite la partie du haut, le plateau tournant. Il a été réalisé en plusieurs parties. La partie principale en PMMA est thermo pliée en forme de U. C’est sur cette pièce que l’on viendra fixer les autres composants permettant la rotation du spot selon l’axe horizontal.

Pour guider le plateau en rotation avec le boitier, nous avons conçu seconde une pièce que l’on viendra fixer sur la partie principale du plateau. Cette pièce est un second palier lisse, cette fois-ci réalisé en impression 3D. Nous avons opté pour cette réalisation car nous y avons directement intégré une roue dentée sur le bas qui sera entraînée par le moteur dans le boitier. C’est donc plus exactement à travers cette pièce que passeront les câbles qui vont du boitier jusqu’au spot et au moteur.

Sur cette pièce en U viendra aussi se visser une bride sur laquelle sera fixée le moteur qui permettra de faire tourner le spot suivant l’axe horizontal.

Pour le guidage du spot, nous avons conçu deux différents systèmes de chaque côté du spot. D’un côté nous avons fait une pièce qui sera vissée sur la pièce principale du plateau. Le spot sera libre en rotation autour de cette pièce. Celle-ci est  creuse suivant son axe mais il y a aussi un trou sur le côté ce qui permet un passage des câbles qui sortent du second palier lisse évoqué plus haut jusque dans le spot.

De l’autre côté nous avons une pièce semblable à la précédente mais avec un tube plus petit qui viendra accueillir un axe monté serrer à l’aide d’une vis de pression.

Cet axe permettra de guider une roue dentée qui sera fixée sur le spot, ce qui permet la mise en rotation du spot sur l’autre côté

Le spot tournera donc autour de l’axe diamètre 5mm d’un côté et autour de la pièce de passage de câble qui est diamètre 16mm.

 

Améliorations possibles :

  • Rigidifier la pièce principale du plateau
  • Réduction des vibrations faites par le moteur


SHOW FINAL


CONCLUSION

Tout au long de ce projet nous avons pu mettre a rude épreuve les compétences acquises en cours. Nous avons également pu décrypter le DMX et ses mystères afin d’en comprendre les trames et  protocoles. Le travail d’équipe avec un autre corps de métier nous a appris que la communication au sein d’un groupe est primordial au bon déroulement d’un projet. N’ayant pas eu toutes les informations en notre possession dès le début du projet nous avons eu du mal à nous mettre en route ainsi qu’à départager les taches que chacun devait effectuer. De plus n’ayant eu les cours de gestion de projet qu’une fois le délai du projet entamé de moitié ce fut compliquer de respecter les délais.

Cependant la mise en pratique des connaissances scolaires fut intéressante et la finalité du projet fonctionnant à 80% est relativement satisfaisante.


Supervision d’un panneau solaire

Les élèves ayant réalisé le projet :

  • Léo GOUZOUAZI étudiant GEII
  • Nikola ILIC étudiant GEII

Sommaire

  1. Présentation du Projet
  2. Analyse fonctionnelle
  3. Matériel
  4. Réalisation
  5. Avancée du projet
  6. Conclusion

Introduction

Le but du projet « Supervision d’un panneau solaire » est d’exercer un contrôle ou une vérification sur l’activité du panneau solaire situé au sein de l’IUT de Mulhouse, et ces informations seront stockées dans un tableur. Tout cela est rendu possible à l’aide de capteurs de courant, d’humidité, de température, de lumière, d’une Arduino Yun et de différents calculs réalisés à l’aide des valeurs renvoyées par les capteurs.

Ces valeurs étant constamment en évolution et n’étant pas fournises par le constructeur, nous proposons ainsi aux personnes voulant les exploiter une façon de s’en servir pour leurs études personnelles, les données étant récupérables tout les soirs.


Analyse fonctionnelle

Cahier des Charges Fonctionnelles (CdCF) :

Exercer un contrôle de l’activité du panneau solaire situé à l’IUT de Mulhouse pour laisser libre service de ces informations à Mme.Ihssane Chtouki et à ses recherches :

  • Pouvoir récupérer, stocker et utiliser les donnés relatives au panneau solaire à distance.
  • Renvoyer toutes les valeurs des capteurs toutes les minutes entre 6h du matin et 22h.
  • Possibilité de mettre le système de mesure à l’extérieur.
  • Toutes les valeurs doivent être récupérées sous forme de tableau.

La réalisation complète du projet serra réalisée par les étudiants du département Génie Électrique et Informatique Industrielle.

 

Expression du besoin (bête à corne) :


Matériel

Description du matériel :

-La carte :

  • Une carte Arduino Yun :

 

La carte Arduino Yun est une carte Arduino à laquelle a été rajouté un processeur qui fonctionne sous Linux Linino, cette carte possède une connectivité Ethernet, WiFi, une mémoire RAM ainsi qu’une mémoire flash (dont une partie est occupée par la distribution Linux) et un lecteur de carte micro-SD. Pour notre projet nous avons choisi cette carte afin de pouvoir exploiter sa fonctionnalité Ethernet et mirco-SD.

-Les Capteurs :

  • Un capteur de température et d’humidité : Le DHT 22

Le DHT 22 est un capteur de température et d’humidité très précis, il peut mesurer une humidité qui varie entre 0 et 100% avec une précision de ± 2% et pour ce qui est des mesures de température, elle peuvent aller de -40 a +80°C  avec une précision de ± 0.5°C. Cette précision explique pourquoi nous avons fait le choix de ce capteur.

  • Un capteur de luminosité : Le TSL2591

Le TSL2591 est un capteur de luminosité il permet de mesurer une intensité lumineuse qui varie de 188 µLux à 88000 Lux. Cette information nous est nécessaire car grâce elle nous pouvons déterminer la production du panneau solaire en W/m².

Il faut également savoir que ce capteur est un capteur fonctionnant sous I²C. Le bus I²C permet de faire communiquer entre eux des composants électroniques grâce à trois fils : un signal de données (SDA), un signal d’horloge (SCL), et un signal de référence électrique (masse). Cette particularité nous obligera donc a utilisé les Pins 2 et 3 de l’arduino (la 2 pour le SDA et la 3 pour le SCL).

Pour tout savoir sur le protocole I2C nous vous invitons à vous rendre sur ce site.

  • Capteur de courant linéaire à effet hall : Le MR003-006.2

Ce capteur à effet hall nous permet de mesurer un courant de ±5A

Mais qu’est-ce que l’effet hall? Tout courant électrique traversant un champ magnétique continu B subit une force électromagnétique dont le sens est donné par la règle des trois doigts (force Laplace). Les trajectoires des charges du courant électriques sont donc déviées en présence de B. Il apparaît donc une d.d.p. (différence de potentiel) sur deux bornes du capteur, dite Tension de Hall. Pour savoir exactement comment fonctionne notre capteur nous vous invitons à consulter sa Datasheet ici.

 


Réalisation

Synoptique

 

Configuration de l’Arduino Yun et de la carte SD

La carte Arduino Yun peut être utiliser comme serveur, pour cela il suffit de créer un répertoire « /arduino/www/ » sur le carte SD, tout les fichier présent dans le répertoire « www » serons accessible en tapant l’adresse « http://10.92.11.25/sd/ » (adresse IP de notre carte) dans n’importe quel navigateur web. Pour cela nous avons créer les dossier directement sur la carte SD avec un ordinateur.

 

Code

Le Code complet est disponible en cliquant ici.

Configuration du TSL2591 : void configureSensor(void)

Le TSL2591 est paramétrable en fonction des conditions d’utilisation. Cette configuration ce fait au début dans une fonction appeler configureSensor(). Le capteur étant à l’extérieur, il est soumis au rayon du soleil et donc à une lumière assez forte, nous l’avons donc configurer pour qu’il ne soit pas trop sensible.

 Initialisation : void setup()

Dans le setup nous allons démarré la liaison entre les deux processeurs grâce à la fonction Bridge.begin(). La fonction FileSystem.begin() nous permet de communiquer avec Linino. La fonction dht.begin() permet de communiquer avec le capteur DHT22.

 

Récupération de la date et l’heure : String getTimeStamp() et String getDateStamp()

Les deux fonctions fonctionne exactement de la même façon, elle vont tout simplement récupérer l’heure et la date du système d’exploitation Linino.

Ecriture dans un fichier .csv : void loop()

Les données des capteurs doivent être écrit dans un fichier csv. Ce format permet de structurer du texte dans un tableau. Le principe est simple chaque ligne du texte correspond à une ligne dans le tableau. Pour créer des colonnes, il suffit de séparer le texte par un un point virgule. Ce Format est compatible avec Microsoft Excel.

Exemple :

 

Dans notre cas nous voulons un tableau par jour, et connaitre le température, l’humidité et l’irradiance toute les minutes entre 6h et 22h.

Dans un premier temps nous allons récupérer l’heure grâce à la fonction getTimeStamp(). Quand il est 6h nous allons créer le fichier grâce à la fonction FileSystem.open(). Nous devons indiquer le chemin ou le fichier doit être créer. Nous avons décidés d’utiliser la date comme nom du fichier mais nous devons modifier les slashs par des underscores. Nous récupérons la date grace à la fonction String getDateStamp() qui nous renvois une chaîne de caractères, pour faire modifier les slashs par des underscores nous devons concaténer la chaîne de caractères dans un tableau grâce à la fonction DateStr.toCharArray(). La structure de la fonction FileSystem.open() est FileSystem.open(const char*, int), donc nous devons concaténer CheminConst dans un tableau. Puisque le fichier n’existe pas encore, la fonction va le créer.

Dans un second temps nous allons écrire les mesures des capteurs dans le fichier toute les minutes jusqu’à 22h. Pour cela nous allons utiliser une boucle while et un compteur. Dans cette boucle nous récupérons les données des capteurs dans des variables indépendante. Pour acquérir les valeurs des capteurs nous utilisons les fonctions disponible dans la librairie proposé par le fabriquant. Puis nous créer une seule chaîne de caractères dataString.


Avancée du projet

Lors de nos première séances projet, nous avions un projet totalement différent, nous avions pour objectif de mettre en place un pilotage à distance du chauffage des salles du bâtiment A. Pour ce faire nous voulions nous baser sur les emplois du temps disponibles sur le site de l’UHA dans la rubrique salles GEII et ainsi optimiser l’utilisation du chauffage en fonction de l’utilisation des salles. Or après avoir réalisé une étude approfondie des besoins et avoir étudié plus en détails la façon dont sont codés les emplois du temps, nous avons appris que ce projet ne serrait pas réalisable car le système de chauffage de l’IUT était centralisé. Nous voila arrivé à la fin de la 3ème séance. Il nous faut donc un nouveau projet. Après concertation avec M.Steger nous avons pu dès lors trouver notre nouveau projet : Supervision d’un panneau solaire.

Dès ce moment nous avons été orientés vers l’idée de la création d’un serveur MQTT sa réalisation nous a demandé un grand nombre d’heures qui n’ont au final aboutie à rien car nous avons abandonné la réalisation de ce serveur lui préférant une page internet.

Ayant déjà la carte Arduino Yun nous avons pu réaliser nos codes pour les capteurs choisis, par chance, l’IUT disposait déjà d’un capteur DHT11 utilisant les mêmes bibliothèques que le DHT22 nous avons donc pu tester ce premier code. Après commande et réception des différents capteurs tout c’est très vite enchainé, les codes ayant été écrits en amont ont pu directement être testés avec succès.

A cette date la partie codage est finie, le seul aspect non abordé du projet est la possibilité de positionner le système de mesure à l’extérieur.


Conclusion

Nous avons pu, lors de ce projet nous servir des connaissances acquises lors de nos études, et les mettre à profit dans un but précis. Nous avons également pu découvrir ce qu’est la gestion d’un projet, faire le choix des éléments les plus adaptés, communiquer et travailler en équipe dans un but précis, faire face à des difficultés mais également gérer les délais. Nous avons pris du retard dans notre projet pour différentes raisons, tel que le délais de la réception des capteurs (que nous avons pu en partie contourner en écrivant les codes sans pouvoir les tester) mais également lors de la tentative de création d’un serveur MQTT qui au final n’a pas été créé ou bien lorsque nous avons passé 3 séances à travailler sur un projet non réalisable. Ces erreurs sont donc à garder en mémoire et à ne plus reproduire dans nos projets futurs.


Remerciements

Nous tenons à remercier M. De Sabbata pour sa patience, son aide et ses conseils pour les soudures qui ont du être réalisées sur les différents capteurs ainsi que pour le prêt d’une carte Arduino Yun sans laquelle ce projet n’aurait pas pu se réaliser.


Course en cours

Projet « Course en Cours » :

 


L’équipe ayant réalisée le projet :

Antoine KIENTZ (GMP)

Théo RIGHINI (GMP)

Nicolas LE FOLL (GEII)

Titouan RIVIERE (GEII)

 

 



Sommaire

I. Introduction

           II. Analyse fonctionnelle

           III. Voiture de Course

         IV. Projet d’innovation

        V. Avancé du projet 

 

 


 Introduction : 

Notre projet se déroule dans le cadre de « Course en Cours », c’est un concours durant lequel plusieurs équipes composées de 4 à 6 étudiants doivent durant une année scolaire, développer une voiture de course miniature, mais également créer un stand, développer un projet d’innovation et préparer une soutenance.

Course en Cours est un dispositif pédagogique original, centré sur les Sciences et la Technologie. Lors de ce concours, les participants montent leur écurie en utilisant les connaissances théoriques obtenues lors des enseignements dispensés dans leurs formations.

Nous avons donc à notre disposition tous les moyens de production et de fabrication du département GMP de l’IUT  de Mulhouse, ainsi qu’un accès à l’IUT Lab et à aux installations du département SGM.

La première étape était d’organiser l’équipe suivant le règlement du concours. Il a fallu définir différent poste :

  • Chef d’équipe : Nicolas LE FOLL
  • Ingénieur conception : Antoine KIENTZ
  • Ingénieurs fabrication : Antoine KIENTZ, Théo RIGHINI
  • Responsables essais : Titouan RIVIERE, Nicolas LEFOLL
  • Responsable style/design : Nicolas LE FOLL, Antoine KIENTZ
  • Responsable communication/sponsoring : Titouan RIVIERE, Théo RIGHINI

La première partie de ce projet concerne la création d’une voiture de course miniature (châssis, coque, train avant, etc…). Le moteur de la voiture est fourni par l’organisation du concours.

Les épreuves auxquelles nous allons participer sont les suivantes :

  • Course de vitesse
  • Arrêt au stand
  • Temps de réaction
  • Développement sur Catia (logiciel de CAO)

La première partie, réalisée par les élèves de GMP, concerne la création d’une voiture (châssis, train avant, roues, coque) en deux exemplaires, le moteur et la transmission étant fournie par l’organisation. Cette partie permettra à l’équipe de participer aux différentes courses. Antoine, élève en GMP, sera le membre de l’équipe qui participera à l’épreuve de CAO sur Catia.

Cette première partie sera réalisée par les élèves de GMP Antoine KIENTZ et Théo RIGHINI.

La seconde partie est un projet d’innovation qui s’inscrit directement dans le sujet du concours, il s’agit ici de développer/créer une application de « l’intelligence numérique » sous la forme d’un objet programmé répondant à la problématique de course en cours mettant en œuvre des capteurs , actionneurs et un traitement algorithmique de l’information.

Cette seconde partie quand à elle, est réalisée par Titouan RIVIERE et Nicolas LE FOLL, élèves de GEII.

 


 Voiture de Course :

  1. Conception du véhicule

La phase de conception a été la partie la plus longue à réaliser. En effet, celle-ci nous a demandée beaucoup de temps de réflexion, et de mises en communs des idées, avant d’arriver à des solutions idéales et réalisables.

Nous nous sommes donc réunis devant un tableau, et avons exposés diverses solutions qui nous semblants intéressantes. Ensuite, nous avons évalués les points forts et les points faibles de chaque solution, pour décider de la plus idéale.

  1. Phase de fabrication et de montage

La phase de fabrication a été séparée en plusieurs parties.

Le châssis

Le châssis a été produit à l’aide d’une imprimante 3D, avec une matière appelée PLA. Cette imprimante est une SIGMAX BCN3D, disposant d’un plateau format A3. Elle est équipée d’un système de double extrusion indépendante, permettant des impressions simultanées, en mode miroir (symétrie) ou duplication.

Au fil du temps, notre solution a souvent évoluée du fait de nouvelles contraintes inattendues ou simplement afin de simplifier l’ensemble. Nous sommes passés par trois principaux designs de châssis, dont deux qui ont été réalisés.

Voici les trois versions par lesquelles nous sommes passés :

Châssis V1 :

Cette version n’a pas abouti, elle était restée au stade de concept. Nous l’avons conçue selon nos premières idées. La forme globale du châssis n’a pas été beaucoup modifiée.

Nous avions imaginé des rebords chanfreinés afin d’y caler la carrosserie, cependant cela n’était pas concluant. Nous n’avions pas encore imaginé la fixation de la carrosserie, du moteur et de la batterie, ainsi que tout l’ensemble train avant.

Châssis V2 :

 

Sur cette deuxième version, nous étions premièrement partis sur la mise en place de trois plots de maintien et mise en position de la carrosserie (deux latéraux, un à l’avant) :

 

Nous avons finalement opté pour une méthode plus simple qui sera expliqué lors de la présentation du châssis V3.

Les points de fixation de ce châssis sont les suivants :

 

Pour la batterie, la solution retenue  est une bande de fixation dite « scratch » qui entoure la batterie, étant donné que le bloc moteur/batterie, la châssis et la coque doivent être démontable en moins de deux minutes (imposé par l’organisation). La bande permet un maintien réglable et  un démontage rapide. Nous avons donc créé une encoche dans le châssis afin de permettre le passage du scratch.

 

 

Pour le moteur, nous avons mis en place deux bossages percés épousant la forme prévue à cet effet déjà présente sur le bloc moteur. Lors du montage, nous utiliserons un système de fixation vis/rondelle/écrou.

 

Châssis V3 : 

Pour cette troisième et dernière version du châssis, nous avons apporté plusieurs modifications majeures.

Premièrement, nous avons ajouté une deuxième encoche pour la fixation de la batterie (logement du scratch) afin d’assurer un maintien en position optimal. Nous avons également agrandi les encoches car l’imprimante 3D plaçait un matériau de  support dans ceux-ci,  qui était difficile à enlever en post-impression, ce qui a résulté d’une détérioration du logement.

Nous avons mis en place une rainure dans le « mur » qui guide la batterie, directement en sortie du moteur. Cette modification a été réalisé car le câble qui relie la batterie au moteur est plus court que sur les mesures réalisé sur les plans CATIA fournis par l’organisation. Par conséquent, il est impossible de passer  le câble sous la batterie. Nous l’avons donc passé par le côté. De plus, nous avons placé un arrêt au bout de la batterie afin de l’arrêter en translation en direction du train avant.

 

 

Au niveau des points de fixation de la coque, nous avons réalisé quatre trous répartis de manière égale sur le châssis, dans lesquels nous allons implanter quatre tiges métalliques de hauteur supérieure à la coque. Une fois la coque posée sur le châssis, nous placerons une goupille pour pouvoir arrêter la coque en translation et l’empêcher de se déloger.

Il a également fallu prévoir le passage de fil guide de la piste Course en Cours sur tout le long du véhicule. Nous avons donc créé un morceau rapporté que nous plaçons dans un logement sous le châssis.

 

Dernièrement, nous avons déduit que le train avant devait être réglable. Étant donné que la voiture n’est pas dirigeable, nous ne pouvons pas nous permettre d’avoir un défaut de trajectoire. Il faut qu’elle ait un mouvement rectiligne uniforme. C’est pourquoi nous avons inclus deux trous oblong au niveau du train avant afin d’assurer la fixation de l’ensemble fusée (guidage de l’axe) ainsi que son réglage.

 

Voici un comparatif en photos du châssis V2 et V3 :

 

Vidéo de l’impression du châssis :

 

La fusée

La fusée est le nom donné à l’ensemble fixé sur le châssis ayant pour fonction principale de guider l’axe avant en rotation.

Nous avons opté pour une réalisation en usinage conventionnel d’un ensemble composé de deux pièces. Nous avons choisis de réaliser ces pièces en usinage dans un brut d’aluminium car ces pièces devraient disposer d’alésages (H7) pour accueillir des bagues en bronze, afin de réaliser un guidage parfait de l’axe. Ces pièces apportent également de la rigidité au véhicule.

Axe avant :

L’axe du train avant a été usiné à l’aide d’un petit tour conventionnel. Cette étape a été minutieuse car il fallait par moment charioter l’axe sur 30mm en réalisant un diamètre 3mm. La tige était donc fortement soumise à la flexion. Il a fallu être précis lors des phases d’usinages et faire attention à l’usure des plaquettes carbures car l’outil chauffait beaucoup.

 

L’axe est une pièce de révolution disposant de trois diamètres différents :

  • Diamètre 6mm : c’est le diamètre non fonctionnel de l’axe, il est présent au centre de la fusée et n’est soumis à aucune contrainte particulière.
  • Diamètre 4mm : c’est le diamètre qui est monté glissant dans les bagues en bronze H7, la rotation optimale repose sur ce diamètre. Afin d’éviter quelconque frottement entre la roue et la fusée, ce diamètre dépasse d’1mm de la fusée et fait donc office de butée pour la roue.
  • Diamètre 3mm : c’est le diamètre aux extrémités de l’axe, il est fileté en M3x35 (mise en place d’un écrou au bout) et c’est lui qui accueille les roues.

Les roues :

Les roues ont été réalisées en impression 3D. Elles sont composée d’une ou plusieurs jantes (cela dépend du train avant ou arrière) et d’une bande roulante (polyuréthane) faisait office de pneumatique.

 

La jante arrière est décomposée en deux parties. La première partie qui contient le trou diamètre 3mm de passage de l’axe, et la deuxième partie contenant un carré de 4.5×4.5mm, carré présent sur l’axe moteur et ayant pour but d’entraîner les roues arrières.

Ces deux parties s’emboîtent l’une dans l’autre et englobe la bande roulante. La bande roulante est adaptée à cette jante et réalisée spécialement selon ses dimensions.

 

Les roues avant fonctionnent sur un principe similaire. Elles sont composées d’une jante disposant d’un trou diamètre 3mm de passage de l’axe, et d’une bande roulante également réalisée sur mesures.

 

La coque :

Nous voulions cette coque avec une allure aérodynamique, style supercar futuriste. L’esquisse a été pensée comme le reste du véhicule, chacun a donné son avis et cela a abouti à des croquis.

Une fois l’alllure principale du véhicule trouvée, nous avons réalisé sa conception sur CatiaV5. Nous nous sommes alors tournés vers le département SGM afin de leur demander des conseils sur les techniques de thermo-moulage.

Sur les conseils de Mr. ANTHOINE, nous avons dépouillé (5°) la coque pour faciliter le démoulage et l’avons rayonné (5mm) pour éviter les problèmes liés aux angles vifs lors du démoulage. Le plateau de leur machine de thermo-moulage n’étant pas assez grand, nous avons donc recours à l’aide du Lycée Théodore DECK de Guebwiller qui ont une machine capable de réaliser des pièces de telles dimensions (300×120).

 

 

La fabrication sera réalisée soit en ABS (épaisseur 1,5mm, plus simple à peindre mais moins résistant) soit en PVC (épaisseur 1mm, transparent donc plus compliqué à peindre, plus résistant aux chocs).

La matrice de moulage a été imprimée en deux parties, puis collée pour le moulage.

Aujourd’hui, il reste à mouler la coque au lycée Théodore DECK, et réaliser les quatre barres de fixations de la coque sur le châssis en tournage.

Conclusion :

Grâce à ce projet, nous avons pu suivre un projet entier, de sa conception à sa fabrication. Nous avons pu appliquer les compétences acquises lors des deux années de DUT, en conception mécanique mais également lors des cours de CAO.

Nous avons pu développer nos qualités de travail en groupe mais également nos capacités de réflexions. Les problèmes rencontrés ont été des challenges que nous avons pu relever en appliquant encore une fois les connaissances du DUT GMP.

Pour finir, nous avons pu utiliser les connaissances d’usinages acquises lors de la première année.

 

 


 Projet d’innovation :

 

La seconde partie de ce projet comme définit dans l’introduction, s’inscrit directement dans l’objectif du concours. Nous avons donc choisi de « créer » une voiture dite connectée, ce qui veut dire que l’on doit pouvoir accéder à un certain nombre de capteurs et pouvoir agir sur les effecteurs présent dans la voiture.

Analyse fonctionnelle

Cahier des charges fonctionnel :

Intégrer un système composé de capteurs et d’effecteurs dans une voiture télécommandée et envoyer ces informations en temps réel via une IHM  :

  • le système doit comporter des capteurs comme de température, humidité, accéléromètre et doit être assez petit pour rentrer dans une voiture télécommander.
  • Échange des informations en temps réel.
  • Avoir une IHM pour pouvoir visualiser ces données et agir sur les effecteurs.

 

Bête à corne :

 


Réalisation Matériel:

Dans un premier temps, nous avons choisi un Arduino Yun, qui est composé d’un microcontrôleur car il permet d’un part une intégration facile dans la voiture et de gérer un certain nombre de capteurs et d’effecteur, et d’un autre part de gérer en parallèle grâce un processeur spécifique une page web.

 

Architecture Arduino Yun.

En effet, le Yun possède deux processeurs différents et donc deux environnements permettant de gérer dans une première partie l’acquisition des données en langage C (environnement Arduino) qui par le bridge sera envoyé au noyau Linux, pour exécuter des protocoles HTTP et d’interagir avec notre IHM web.

 

 

 

Les capteurs choisis sont les suivants :

  • Double capteur de température

Le premier capteur est installé à l’extérieur de la voiture dans le but de connaitre la température ambiante. Le deuxième, collé au moteur à courant continu, indiquera la température de ce dernier afin que nous puissions agir dessus.

 

 

 

 

 

  • Capteur de luminosité

 

Situé sous le toit de la voiture, le capteur servira à capter la luminosité ambiante et agira sur les phares.

 

 

  • Capteur de chocs

 

Collé au niveau du capot, le tilt sensor envoie une impulsion en cas de chocs (utilisable pour un arrêter le moteur par exemple).

  • Accéléromètre

 

 

Les actionneurs :

Leds : Rajout de leds au niveau des phares.

Les leds peuvent-être dirigées de différentes façon : soit par une requête directement envoyée de la page web par un utilisateur, soit si la luminosité tombe à moins de 40 lux

Ventilateur : Comme les leds, s’actionne à l’aide d’une requête ou si la température du moteur dépasse les 60 degrés Celcius.

 

Voici les codes en C commentés :

 

 

 


Supervision :

 

Pour la réalisation de la supervision, nous avons dû créer une IHM permettant de visualiser toutes les données acquises ainsi que d’envoyer des « ordres » à l’Arduino. Pour réaliser cette IHM nous avons choisi d’utiliser le format web, rendu possible grâce à l’Arduino Yun, et donc nous avons écrit cette IHM en Hyper Text Markup Language (HTML) qui est un langage de balisage conçu pour représenter les pages web, uniquement structurel.

Cette IHM web est constitué de deux parties :

  • La première page est l’acquisition des capteurs :

 

 

  • La deuxième page permet d’agir directement sur les effecteurs via des boutons.

Après création de cette page web, il nous faut maintenant pouvoir dialoguer avec l’Arduino.

C’est donc pour cela que l’on a utilisé le Javascript, qui est un langage de programmation de script orienté objet qui permet de rendre les pages web dynamique autrement dit interactive avec l’utilisateur.

 

 

Hors ce langage ne s’exécute seulement que sur le client et ne permet donc aucun échange avec le serveur. C’est donc pour cela que l’on a utilisé le protocole Hypertext Transfer (HTTP) et plus précisément le XMLHttpRequest qui est un objet du navigateur accessible en Javascript permettant d’obtenir des données du serveur au format XML, JSON, ou HTML.

 

C’est donc grâce à ce protocole que l’on à créée une fonction type qui permet de recevoir non seulement des données mais aussi envoyer des « ordres » à l’Arduino qui seront ensuite traités pour gérer les effecteurs comme expliqué dans la première partie.

 

 

Dans la page « capteurs », les requêtes vont se lancer automatiquement toutes les secondes sans actions préalable de l’utilisateur.

 

 

Puis la page « effecteurs », elles seront lancées par l’utilisateur directement via l’appui de boutons.

 

 

 


Conclusion :

Malgré quelques problèmes rencontrés, on à réussis à remplir nos objectifs. En effet, le calibrage des capteurs n’à pas été facile, de même pour mettre en fonctionnement l’Arduino à cause de la configuration de base.

Maintenant après avoir terminé ce projet il y plusieurs d’amélioration possible :

  • Agir directement sur le moteur avec le capteur de choc.
  • Gérer les phases d’accélération grâce au capteur d’accélération.
  • Avoir la vitesse en temps réel.

 

 

 


Documents Annexes :

 

Code en C Arduino :

code HTML/CSS et JS :

ProjetCourseEnCour

 

 

 

 

 

 

 

….