PROJET GEII

HACHEUR ONDULEUR AVEC CIRCUIT DE COMMANDE

 

Sommaire:

1. Présentation de l’équipe

2. Présentation du Projet

3. Cahier des charges

4. Gestion de Projet

5. Etude du projet

   1. Etude du circuit de commande

      1. Montage Trigger de Schmitt
      2. Montage Integrateur
      3. Trigger de Schmitt en série avec Intégrateur (Générateur triangulaire)
      4. Montage pour modulation à largeur d’impulsion (MLI)
      5. Montage pour la MLI complémentaire

   2. Etude du circuit de puissance

      1. Pont en H
      2. Choix des transistors
      3. Choix des diodes de roue libre
      4. Choix des résistances de limitation de courant
      5. Thermique et choix des radiateurs

6. Réalisation du projet

   1. Boitier

   2. Carte de puissance

   3. Carte de commande

   4. Réalisation des cartes

7. Bilan du projet

   1. Résultats

8. Conclusion

9. Remerciements

1. Présentation de l’équipe

 

 

L’équipe est constituée de 6 personnes : Simon HEGE, Willy PERRIN, Victor SCHAEFFER, Loïc MINERY, Thibaut MAILLOT et Adrien RAEDERSTORFF.

2. Présentation du Projet

Nous avons dû réaliser une maquette pédagogique de hacheur onduleur avec circuit de commande que nous utiliserons en  2eme année de DUT Geii.

Un hacheur onduleur est un circuit permettant de faire varier la vitesse de moteurs à courants continus ou alternatifs

3. Cahier des charges

diagramme bête à cornes

 

diagramme pieuvre (fonctions)

Etude du cahier des charges

C’est la première étape, elle définit les impératifs du projet  et ses limites, le cahier des charges doit être approuvé par tous les acteurs du projet, c’est un contrat.

 

 

Préambule

Le projet consiste à réaliser une maquette pédagogique (circuit) de type hacheur-onduleur (conversion
continu-continu et continu-alternatif) avec un circuit de commande.

Contexte

Nous devons réaliser un projet en groupe tutoré par un enseignant, dans la filière DUT GEII de l’IUT de
Mulhouse.
Ce projet est organisé en parallèle des cours et s’inscrit dans la continuité des projets réalisés par les
autres élèves l’année précédente.

Objectifs

Réaliser une maquette de type hacheur-onduleur (conversion continu-continu et continu-alternatif)
avec circuit de commande fonctionnelle et sécurisée avec composants amovibles si possible.

Description de l’environnement logiciel

● Logiciel Kicad pour réaliser les plans de la maquette
● LTspice pour la simulation du circuit de puissance

Description de l’environnement matériel

● Composants électroniques / plaques
● Appareils de mesures de l’IUT pour effectuer des test
● Machines d’ER de l‘IUT pour réaliser la maquette

 

 

 

Contraintes

Contraintes techniques:

la maquette fourni 75 à 100 W et +/- 15V composants amovibles et utilisables
en sécurité

Délais:

Nous disposons d’une durée totale de 2 semaines du 16 avril au 29 avril pour réaliser le projet, ce
qui comprend:
● les calculs
● le choix des composants
● la réalisation d’un plan de maquette
● la réalisation de la maquette.
● Les tests

Autres contraintes:

Les composants doivent être obligatoirement commandés sur le site Radiospares.
Nous disposons d’un budget maximum de 200 euros que l’enseignant tuteur devra approuver.

 

 

 

 

4. Gestion de projet

 

Gantt prévisionnel

 

 

 

 

 

 

 

 

Gantt final

Mindview final

 

 

 

 

 

 

 

 

5. Etude du projet

Etude du circuit de commande

Montage Trigger de Schmitt

Ce montage consiste en une résistance en série avec un amplificateur opérationnel et une autre résistance en parallèle à l’amplificateur.

On applique le théorème de superposition au trigger pour trouver Ve.

 

 

Il commute avec une tension d’entrée sinusoïdale en entrée, en sortie on obtient un signal carré:

Montage Intégrateur

Ce montage consiste en une résistance en série avec un amplificateur, ainsi qu’un condensateur en parallèle à l’amplificateur.

En sortie on obtient l’intégrale du signal d’entrée.

Montage Trigger de Schmitt Intégrateur

On met les deux montages précédents en série et on boucle car le montage commute tout seul ( pas besoin de tension d’entrée), en sortie on obtient un signal triangulaire (intégrale du signal carré délivré par le trigger).

Signal de sortie

 

Ce montage est le cœur du circuit de commande, c’est lui qui fait varier la fréquence du signal.

f étant  la fréquence d’oscillation, on remplacer R3 par une résistance de 2200 ohms en série avec un potentiomètre de 10k ohms.

On calcule la fréquence maximum avec R3=2200 ohms

On calcule maintenant la fréquence minimum avec R3=12200 ohms

 

 

Montage pour modulation à largeur d’impulsion (MLI)

On utilise un comparateur simple en série avec la montage précédent, on envoie un signal avec un GBF qu’on compare avec le signal triangulaire.

Si c’est un signal sinusoïdal: on obtient une modulation à largeur d’impulsion, on approche une sinusoïde en découpant le signal continu.

 

Montage pour la MLI complémentaire (comparateur et comparateur inverseur)

On utilise un montage de type comparateur à fenêtre ci dessous, de D1 sort une tension positive ou nulle (effet de la diode), de D2 sort le signal complémentaire, effet du comparateur inverseur.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nous avons modifié le montage de base suite à la demande des professeurs, qui ont décidé de travailler avec des signaux positifs et négatifs,

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Réalisation d’une plaquette de test pour la commande

Nous avons réalisé une maquette test du circuit de commande pour tester si notre solution fonctionnait.

   Pour celà nous l’avons branchée à un oscilloscope pour visualiser  la MLI.

 

Ci dessous le signal observé avec la plaquette test.

 

 

 

Nous visualisons bien la MLI en bleu, le signal triangulaire ainsi que la sinusoidale en violet.

 

Étude du circuit de puissance

Comme nous voulons pouvoir faire varier la vitesse de moteurs continus et alternatifs, il faut un montage qui rempli les deux critères, le hacheur 4 quadrants pour le  continu et l’onduleur monophasé pour l’alternatif sont en réalité le  même montage appelé pont en H.

Ce montage consiste en 4 composants (Q1,2,3,4) qui agissent comme des interrupteurs et laissent passer le courant venant du potentiel Vcc jusqu’à  la masse. Les diodes en parallèles sont des diodes de roues libres elles permettent d’assurer la transition lorsque que l’on change de sens, en effet les 4 interrupteurs ne sont jamais tous fermés en général ce sont Q3 et Q2 fermés (moteur tourne à droite ou Q4 et Q1 fermés (moteur tourne à gauche).

 

notre pont en H est composé de:

 

2 transistors NPN

2 transistors PNP

4 diodes

Le tout alimenté par une tension Vcc= +15V

Le circuit de puissance correspond à un pont en H avec 2 transistors NPN et 2 transistors PNP de l’autre. Chaque transistor aura une diode  en parallèle, ce sont des diodes de roue libre, elles permettent d’évité une surtension en cas d’arrêt brutal de la tension d’alimentation.

Transistor NPN et PNP:

Les transistors NPN et PNP sont utilisés comme des interrupteurs commandés, ils sont composés d’une base, d’un émetteur et d’un collecteur. Pour les NPN le courant entre dans le collecteur et sort de l’émetteur alors que pour les PNP le courant entre dans l’émetteur et sort du collecteur.

Les transistors possèdent deux états un état bloqué et un état saturé.

Le transistor est bloqué quand Ib=0

Le transistor est passant quand Ib>Ic/HFE

Montage en Darlington:

Dans notre cas le courant de sortie de la partie commande est trop petit par rapport au courant qui doit passer dans les transistors du pont en H. Nous avons donc pris 2 autres transistors NPN et PNP qui prenaient des courants plus petit, et réalisé un montage en Darlington pour avoir un gain en courant pour les transistors du pont en H.

Calcul des résistances du darlington

Afin de limiter le courant de base du transistor pour ne pas casser le transistor on met une résistance à la base

Pour les résistances de tirage avec une loi des maille on a

UR est la tension aux bornes de la résistance de tirage, quand le transistor n’est pas passant le courant de qui traverse la résistance est I, on a:.

On a donc :

On prendra une résistance de 10k ohms

Calcul résistance de base de PNP1:

Calcul résistance de base de NPN2

Calcul de la résistance du radiateur

Les transistors délivrent de la chaleur qu’il faut  limiter à l’aide de radiateur

Pj=VCE x Ic=1.2×3=3.6W

Pj(pertes joules)

Vce(tension collecteur-émetteur)

Ic(courant du collecteur)

 

 

Rthja=(θJ-θa)/Pj=3.6W

Rthja(résistance jonction-air)

θJ(température la jonction)

θa(température de l’air)

 

 

Rthra=Rthja-Rthjb-Rthbr=34 °C/W

Rthra(résistance radiateur-air)

Rthjb(résistance jonction-boîtier)

Rthbr(résistance boîtier-radiateur)

 

Fonctionnement

Le pont en H comprend 4 transistors (2 NPN et 2PNP) on alimente le pont en H avec la MLI sur 2 transistor d’un côté et avec son complément sur les 2 autres transistors, car les 2 transistors NPN doivent commuter en même temps quand l’un est passant l’autre est bloquant. De même pour les PNP.

6. Réalisation

Boitier

 

 

Nous avions 2 choix pour la boite; fabriquer un boitier ou en utiliser un déjà en stock. Nous avons opté pour la deuxième option car la configuration de ce type de boite est optimale. En effet, le boitier est isolé électriquement et peut facilement contenir les deux cartes de commande et puissance, il répond donc aux contraintes de sécurité.

Dans un premier temps nous avons  pris les mesures du couvercle et fait une esquisse du schéma pédagogique à graver sur le couvercle, nous avons utilisé le logiciel CorelDraw pour réaliser le schéma.

Nous avons par la suite réalisé un prototype sur un plastique de test. Le rendu final étant satisfaisant, nous avons donc décidé de passer à la gravure sur boitier.

Malheureusement, suite à une erreur sur la composition du matériau de la boite, la gravure ne s’est pas effectuée correctement. Nous avons donc dû percer nous-même les trous et nettoyer le couvercle car de l’acide s’était formé.

Le résultat final restant tout de même acceptable, nous avons décidé de le garder en l’état.

Nous avons apr la suite mis en place les borniers et soudé les cables

 

Carte de puissance 

Nous avons utilisé le logiciel Kicad pour la réalisation du schéma et la modélisation de la carte avec les composants et les jonctions en tailles réelles.

E-schéma

 

Pcb-new

 

Liste de matériel

Composant Valeurs Référence Nombre Diode 3A / 1000 V 1N5408 4 Transistor NPN Ic=3 A Ib=150 mA Hfe=25 BC639 2 Transistor NPN Ic=150 mA Ib=1.5 mA (3mA max) Hfe=100 TIP31 2 Transistor PNP Ic=150 mA Ib=1.5 mA (3mA max) Hfe=100 TIP32 2 Transistor PNP Ic=3 A Ib=150 mA Hfe=25 BC640 2 Bornier 2 7 Bornier 3 1

Carte de commande

E-schéma

Pcb-new

Liste de matériel

Composant Valeurs Référence Nombre AOP TL081 1 AOP TL084 1 Diode 100 mA / 100 V 1N4148 4 Condensateur 100nF 1 Potentiomètre 10k 1 Résistance 1k 1 Résistance 2.2k 1 Résistance 10k 5 Résistance 8.2k 2 Résistance 18k 2 Bornier 2 bornes 3 Bornier 3 bornes 2 Bornier 4 bornes 1

 

 

 

Impression des cartes

Nous avons imprimé les calque des Pcb pour les utiliser plus tard dans le processus de fabrication des cartes.

 

 

 

Dans un premier temps, nous avons dû prendre les dimensions de nos cartes afin de les découper correctement à l’aide de la cisaille.

Voici nos cartes après la découpe selon les bonnes dimensions.

Ensuite, nous avons placé notre carte avec le calque superposé dans l’insoleuse à UV pendant 2 minutes.

 

Pour la partie révélation, nous avons utilisé un sachet de la préparation révélatrice dilué dans un litre d’eau. On doit ensuite agiter doucement le bac pour que le liquide submerge la carte, et faire ressortir le circuit imprimé.

 

 

 

 

 

 

 

 

 

 

 

 

La machine à perchlorure de fer nous a permis d’effectuer la suite du tirage du circuit.

 

La machine à étamage étant hors service, nous avons utilisé de l’étain liquide qui est une technique tout aussi efficace. La manipulation est la même que pour le bac de révélation.

 

Une fois l’étain incrusté sur nos cartes, nous avons percé les trous pour les pattes des composants. La taille de chaque perçage était prédéfinie pour pouvoir faire rentrer les pattes de tous nos composants.

 

Voila le résultat de la carte de notre partie commande, une carte avec deux couches. Pour connecter les couches nous avons dû réaliser des vias, c’est à dire connecter les deux couches avec de la soudure. Pour la carte de puissance ces étapes sont les mêmes.

 

 

L’étape suivante est de souder les composants sur les cartes, une étape difficile car elle demande d’être extrêmement minutieux. Il ne faut pas que deux potentiels soient connectés par de la soudure, les Vias doivent êtres bien réalisés sinon les deux couches ne sont pas en contact.

 

Voici le résultat final pour la partie puissance:

Le résultat final pour la partie commande:

 

 

7. Bilan du projet

Résultats

A la fin des deux semaines de projet, notre carte de commande ne fonctionnait pas. Nous avons donc pris sur notre temps libre afin de  régler le problème. Grâce à l’aide de M. Colicchio, nous avons trouvé la cause du problème. Il se trouve qu’ un via était mal soudé. Nous avons donc fait le nécessaire afin que la carte fonctionne correctement.

Au moment ou nous rendons ce rapport, notre maquette pédagogique fonctionne. En effet, nous parvenons à faire varier la vitesse d’un moteur. Néanmoins au vu des courbes obtenues sur l’oscilloscope (oscillations parasites), la maquette présente des défauts qui sont très probablement dû à des soudures mal réalisées ou des câbles mal connectés. Nous travaillerons encore sur les cartes après le rendu du rapport afin qu’elle soit parfaitement opérationnelle pour l’année prochaine.

 

8. Conclusion :

Ces deux semaines de projet nous ont permis d’acquérir une première expérience du travail en groupe. En effet, il s’agit d’un aperçu de ce qu’est le monde professionnel et le travail en équipe.

Nous avons dû prendre des initiatives pour pouvoir respecter les délais prévisionnels que nous nous sommes nous-même fixés dans notre diagramme GANTT prévisionnel. La répartition des tâches entre les différents membres du groupe, partie commande et partie puissance, nous a permis d’avancer plus rapidement. Nous nous sommes souvent réunis afin d’analyser l’avancement des parties de chaque membres du groupe.

Nous avons dû utiliser les connaissances apprises en cours lors du semestre 1 et du semestre 2. Les notions qui nous ont été nécessaire étaient principalement celles d’électrotechnique et d’électricité.

La plaquette de test sur laquelle nous avons installé les composants nous a permis de tester la partie commande. Cette opération nous a aidés à trouver et résoudre les problèmes rencontrés, sans passer par la partie réalisation de la carte. Cette technique nous a ainsi apporté un gain de temps non négligeable.

Malgré quelques erreurs et soudures mal effectuées, nous avons persistés et réussis à rendre notre projet, opérationnel et respectant le cahier des charges, dans les temps.

Ce boitier hacheur-onduleur va nous servir, ainsi qu’à tous les étudiants du département GEII, lors des TP du semestre 3.

 

9. Remerciements:

Nous souhaitons remercier les enseignants Mr COLICCHIO et Mr STRAFELLA qui ont été nos tuteurs sur ce projet. Ils nous ont permis de mieux comprendre le sujet, et ont toujours été présent pour répondre à nos questions et nous apporter leur expérience.

Nous remercions également Mr DE SABBATA qui nous a accueillis au sein de l’IUT LAB et nous a conseillé pour la conception de la boite.

Nous remercions enfin Mr ROTH pour nous avoir aidé et conseillé lors des soutenances intermédiaires afin d’améliorer la qualité de notre présentation et de notre prestation pour la soutenance finale.

Projet mesure de la qualité de l’eau

Sommaire

 

1) Contexte et définition du projet

a) Contexte

b) Objectif du projet

c) Description de l’équipe

d) Périmètre

e)Description de l’existant

 

2)Besoin du projet

3)Contraintes

a) Coûts

b) Délais

c) Autres

 

4) Déroulement du projet

a) Planification

 

 

 

1) Contexte et définition du projet

 

a) Contexte

Le projet rentre dans le cadre du projet tutoré du 2ème semestre. C’est un système composé d’un ensemble de capteurs et sondes.

 

b) Objectif du projet

 

Pour ce projet, nous avions plusieurs objectifs :

 

-Avoir finit notre projet pour la date du 26 avril au plus tôt.

-Tester la qualité.

-Utiliser l’ensemble de sondes et de capteurs.

-Faire fonctionner une carte Arduino et Raspberry pi.

 

c)Description de l’équipe

 

-Hosatte Clément : Chef de projet

-Kieffer Maxime : Programmeur

-Nestelhut Alexandre : Concepteur

 

d)Périmètre

 

La caractéristique spéciale était l’horaire des salles et les heures prévues pour le projet.

 

e)Description de l’existant

Nous avions à notre disposition, une sonde de température, une sonde de Ph, et une sonde de conductivité électrique, ainsi qu’une carte Arduino et Raspberry pi.

 

 

 

2)Besoin du projet

 

 

 

3)Contraintes

a) Coût

Nous n’avions pas un budget à proprement parler, M. Xu s’est occupé de commander les pièces dont nous avions besoin pour ce projet. Nous avons donc un coût de : 232,46 euros.

b)Délais

Le temps prévu pour ce projet était de 2 semaines, plus un mois supplémentaire si nous n’avions pas fini ou qu’il nous restait quelques modifications à faire.

c)Autres

Nos autres contraintes étaient la disponibilité de l’équipement ainsi que la celle des personnes qui nous accompagnait pendant toute la durée du projet, c’est-à-dire, notre professeur référent s’il y avait la moindre modifications à faire.

4)Déroulement du projet

a)Planification

Phase de recherche :

Nous avons tout d’abord commencé des recherches préliminaires afin de savoir si nous aurions besoin de composants supplémentaires pour le câblage de nos différentes sondes. Nous en avons aussi profité pour étudier les langages de programmation.

 

 

Phase de programmation :

La phase de programmation est la phase où nous avons passé le plus de temps, mais qui est aussi la plus importante. Nous avons donc fait un premier programme sur Arduino afin de récupérer les valeurs mesurées par les sondes.

 

 

Ensuite nous avons fait un programme sur le Raspberry pi pour afficher les valeurs récupérées par les sondes pendant un certain temps et les enregistrer dans un fichier texte.

 

 

Phase de conception

La phase de conception est celle qui nous a permis de tester nos sondes afin d’avoir des valeurs cohérentes, mais aussi de préparer le boîtier isoler à l’eau et à l’humidité afin de protéger les différentes cartes électroniques.

 

 

Phase d’assemblage

Pendant cette phase, qui a été la dernière, nous avons assemblé le module portable qui permet de transporter le système et de le protéger comme l’eau et l’humidité.

Nous avons procédé en plusieurs étapes :

 

-Tout d’abord nous avons conçus le boitier sur site web prévu à cet effet

 

– Nous avons ensuite fixées les plaques ensemble avec de la colle, sauf celle du haut, afin de pouvoir accéder à l’intérieur du module.

 

-Nous avons ensuite créer des encoches afin de faire passer les différents câbles

 

-Pour finir, nous avons limés la plaque du haute afin de mettre l’écran au même niveau que la plaque

 

Remerciements

 

Nous tenons à remercier M.Xu pour ce projet qui a été fort intéressant et qui nous a permis d’appliquer ce que l’on nous a enseigné en cours.  Nous remercions aussi M.DeSabatta pour son aide lors de la conception du boîtier, M.Schubnel, ingénieur du département SGM qui nous a procuré les solutions d’étalonnage du Ph et M.Roth qui nous as donné de nombreux conseils concernant la préparation de notre présentation.

PROJET GEII

Relevé de consommation d’eau par vision

Sommaire:

 

1. Présentation de l’équipe

2. Cahier des charges

3. Gestion de Projet

4. Réalisation du projet

• Programmation

• Boitier

5. Résultats

6. Conclusion

7. Remerciements

 

 

1.Présentation de l’équipe

 

Etudiants de GEII, notre groupe doit en l’espace de 2 semaines réaliser un relevé de consommation d’eau par vision.

Notre groupe est composé de Emre TEKIN, Typhaine ZOUACHE, Alper UCAR et Ludovic ROCHEMONT.

Pour réaliser le projet, nous nous sommes fractionner. Emre et Ludovic sur la partie programmation et Typhaine et Alper sur la conception de la boîte.

 

2.Cahier des charges

 

 

• Objectif :

Réalisation d’un système de relevé de consommation d’eau par vision.

 

• Présentation du projet :

Il s’agit de réaliser un système d’acquisition d’images, capable de capturer des images de relevé de consommation d’eau. Les images seront capturées à la demande, ou suivant un fréquence déterminée. Elles seront ensuite à la fois stockées et transmises via un protocole réseau vers un unité de traitement, capable de lire les valeurs indiquées par le compteur.

 

• Contraintes techniques :

-Acquisition d’image périodique + par requête par PC

-Acquisition d’images + envoi de l’image

-Gestion de l’illumination (LED + système de filtres anti-reflets)

-Intégration du système pour qu’il soit facile à installer (boîtier, câblage…)

 

• Bête à corne :

• Diagramme pieuvre :

• Analyse fonctionnel :

 

3.Gestion de projet

• Programme du projet :

 

• Detail des semaines :

 

4.Réalisation du projet

• 1.Programmation

Avant de réaliser un programme il nous fallu se familiariser avec le logiciel Python. Pour cela, nous avons reçu un petit cours de programmation en python et aussi quelque commande pratique à utiliser sur le Raspberry PI par M.BAZEILLE.

• • Commande pratique :

• cd <nom ou chemin du répertoire> : permet de changer de répertoire courant (cd = change directory). Cette commande permet de réaliser les mêmes actions que lorsque vous vous baladez avec votre souris dans l’arborescence de votre système.
• mkdir <nom du répertoire> : permet de créer un nouveau répertoire dans le répertoire courant (mkdir = make directory). Pour supprimer un répertoire, il suffit d’utiliser la commande rmdir <nom du répertoire>.
• ls : permet de lister les fichiers et répertoires contenus dans le répertoire courant.
• cp <fichier source> <répertoire de destination> : permet de copier le fichier source et de le coller dans le répertoire de destination (cp = copy). Il est également possible de réaliser un « couper/coller » à l’aide de la commande mv <fichier source> <répertoire de destination> (mv = move).
• Programme Python du projet :

Dans cette Partie du programme, nous trouvons les différentes bibliothèques utilisées ainsi que les fonctions de connexion (on_connect) de publication (on_publish) et de souscription (on _subscribe).

MQTT (MQ Telemetry Transport) est un protocole de messagerie léger qui facilite la transmission des données de télémétrie pour les clients réseau dont les ressources sont limitées. Ce protocole, qui suit un modèle de communication de type publication/abonnement via un broker de messages, est utilisé pour les échanges machine-à-machine (M2M). Il joue un rôle important dans l’Internet des objets.

Notre client MQTT est le Broker hivemq, initialement nous avions mosquitto mais du à des discordance nous avons choisi celui-ci. Nous avons aussi la connexion au serveur FTP de l’IUT.

 

Dans le cadre rouge, nous nous inscrivons sur les Topics créer au préalable « Projiut/Images/Eau » topic de teste « Eau/Image » Topic où les images par fréquence sont envoyé et « Eau/image/demande » Topic qui reçoit les images à la demande de l’utilisateur.

Dans le cadre vert, nous avons la partie qui gère les leds à allumer et la prise d’image par la PiCamera. La partie haute initialise les ports de sortie du Pi relié aux leds avec allumage ensuite on prend une photo puis on éteint les leds.

Cette partie du programme permet la prise et l’envoie de la photo par demande, c’est pour cela quel se trouve dans une fonction on_demande.

Sur la partie envoie, nous avons le même procédé que sur envoie par fréquence.

Dans le cadre jaune qui suit, les lignes de code permettent d’ouvrir le fichier contenant l’image, de la transformer en bits et de l’envoyer par FTP mais aussi par MQTT.

Le serveur FTP étant basé sur le site de l’IUT pour un usage autre que dans l’IUT il faudrait enlever les lignes permettant de se connecter au serveur ainsi que le transcode et l’envoie.

Pour la récupération des images nous avons un autre code mais cette fois si sur un pc :

Le programme ressemble au précédant sauf que celui reçoit les images depuis le serveur MQTT avec la mise en place du temps suivi de _demande si l’image a été reçu sur le topic Eau/Image.

 

• 2.Boitier

Avant toute chose il nous a fallu étudier l’aspect de la boîte ainsi que l’environnement dans lequel il serait installer.

Les compteurs d’eau étant le plus souvent dans des endroits sombres et humide. Nous avons décidé de faire une boite imperméable renferment le Raspberry Pi pour ne pas endommager les composants . Le problème suivants était la manière dont nous allions poser cette boîte sur le compteur pour prendre des photos correcte. Pour régler ce problème, nous avons pris une tête de canalisation d’eau de la taille du diamètre du compteur pour le placer au-dessus dans n’importe quel position.

Le compteur étant plonger dans le noir, nous avons disposer de leds de par et d’autre le PiCamera. Cependant, nous observions un reflet sur la vitre du compteur. Pour y remédier, nous avons conçu un dôme artificiel pour diffuser la lumière sans pour autant avoir un reflet.

La boîte ne comporte qu’une seul entrer celle de l’alimentation secteur, puisque le programme d’envoie de l’image peut être lancer par un poste différent connecter sur le même réseau FTP.

 

 

 

 

 

 

 

 

 

 

 

 

5.Résultats

Le projet est aboutie et fonctionnel présenter dans cette vidéo :

 

 

6.Conclusion

Ces deux semaines de projet nous ont permis d’acquérir une première expérience riche du monde du travail. En effet, il s’agit l’un des aspect les plus importants que l’on peut rencontrer dans le monde professionnel

Nous avons dû prendre des initiatives pour pouvoir respecter les délais prévisionnels que nous nous sommes nous-même fixés dans notre diagramme GANTT prévisionnel. La répartition des tâches entre les différents membres du groupe, partie programmation et partie mécanique, nous a permis d’avancer plus rapidement avec des réunions quotidienne pour parler de nos avancement.

 

7.Remerciement

Nous souhaitons remercier les enseignants Mr CUDEL, Mr WIRA et Mr BAZEILLE qui ont été nos tuteurs et d’une grande aide sur ce projet. Ils nous ont permis de mieux comprendre le sujet, et ont toujours été présent pour répondre à nos questions et nous apporter leur expérience.

Nous remercions également Mr DE SABBATA qui nous a accueillis au sein de l’IUT LAB et nous a conseillé pour la conception de la boîte.

Nous remercions enfin Mr ROTH pour nous avoir aidé et conseillé lors des soutenances d’exercice afin d’améliorer la qualité de notre présentation et de notre prestation pour la soutenance finale.

fichier zip contenant code:

relever de consommation d’eau par vision

Tuteur : Stéphane Bazeille

Groupe : Braun Florian, Eckler Louis, Hebinger Pierre, Tissot Hugo, Zaid El Khil Damien, Benjamin Zimmermann, Jérémy Binder

 

Sommaire

 

Cahier des charges

1. Présentation générale du problème

        1.1. Projet

        1.2. Contexte

        1.3. Énoncé du besoin

        1.4. Environnement du produit

2. Expression fonctionnelle du besoin

3. Cadre de réponse pour chaque fonction

 

 

Gestion et réalisation du projet

1. Tester et communiquer avec tous les capteurs   

A) Caméra

              a) Configuration

              b) Branchement

              c) Code

B) Centrale inertielle

              a) Configuration

              b) Branchement

              c) Code

C) GPS

              a) Configuration

              b) Branchement

              c) Code

2. Enregistrer les données et photos   

A) Enregistrer les données textes

            a) Installation nécessaires

            b) Code

B) Enregistrer les photos

3) Envoyer les données et photos sur les serveurs  

A) Envoi des données textes au serveur MQTT

B) Envoi de photos au serveur FTP

4) Réceptions des données et photos ( client à serveur) 

A) Serveur FTP

B) Serveur Node.js / Mysql

            a) Mise en place de l’infrastructure web

            b) Installation des extension node.js

            c) Code de réception node.js

5) Interface utilisateur  

A) Interface utilisateur Raspberry PI

B) Interface utilisateur côté serveur

            a) code

6) Finalisation du programme principale  

7) Création du boîtier

 

Vidéo de présentation

 

 

 

 

Cahier des charges

1. Présentation générale du produit

 

    1.1. Projet

Le projet Tracker GPS consiste à créer un dispositif portable, permettant d’enregistrer un parcours lors d’une randonnée. Les données sont, par la suite, retranscrites sur un carte gérée sur un site internet.

   1.2. Contexte

Afin de porter à bien le projet, nous sommes constitués d’un groupe de 7 personnes.

Dans un premier temps il faudra étudier le fonctionnement de chaque module (GPS, IMU, Caméra), ainsi que celui de la Raspberry, cela est primordial pour la compréhension et la réalisation.  Après avoir connecté puis communiqué avec les capteurs, il sera nécessaire de les programmer un à un pour au final créer un seul et unique programme. En parallèle, il faudra créer une interface (site internet), sur lequel on serait capable d’afficher le trajet, et une autre interface (écran du Raspberry), pour pouvoir lancer le programme et visualiser les différentes informations.

 

   1.3. Enoncé du besoin

1.4 Environnement du produit

Le dispositif final doit être facilement transportable et doit répondre à un minimum de contraintes environnementales:

• résister à l’humidité
• s’adapter aux différentes météo

La liste de matériel nécessaire :

• Batterie
• Raspberry PI
• GPS, IMU (centrale inertielle)
• Caméra
• Écran d’interaction
• Boîtier
• Serveur MQTT
• Serveur FTP
• Site Internet

Pour tout ces composants, le coût à l’achat représente 202 €, un coût qui ne nous est pas soumis car tout le matériel a été fourni par l’IUT.

2. Expression fonctionnelle du besoin

 

Fonction	Désignation	Critères d’appréciations	Niveau	Flexibilité	Observations
FP1	Permettre à l’utilisateur de consulter les informations sur son parcours	– visualiser sur un écran – carte avec un tracé visible du trajet	/	/	/
FC1	Récolter les données du Raspberry PI	– envoyer les différentes coordonnées GPS – envoyer les images prises avec le Raspberry PI	photos toutes les 30s / données toutes les 2 secondes	±10 s pour les photos / ± 2 s pour les données	quelques secondes de retard possibles pour l’envoi des données lors de l’envoi d’une photo
FC2	Transporter le tracker GPS	– boîtier contenant le Raspberry pi – un boitier léger	/	poids agréable à transporter. taille: peu encombrant	capteur gps plus efficace quand à l’extérieur du boîtier
FC3	Communiquer avec le Raspberry PI	-communiquer à l’aide de serveur MQTT et FTP	sans fil	/	/
FC4	Être alimenté en énergie	-batterie	1h	minimum 30 minutes	2h
FC5	Être ergonomique	-Forme : des poignées (pour faciliter le transport) -Couleur : transparent (pour avoir un regard sur les composants)	une bonne prise en main	/	/
FC6	Environnement	– dispositif résistant à l’humidité et non influencé par la pression atmosphérique	résister à une météo pluvieuse	résister à une légère pluie	mettre le capteur GPS dans le boitier pour plus d’étanchéité, mais une perte d’efficacité du capteur
FC7	Coût	– coût final  accessible	250€	+ ou –           50€	202€ sans le support

3. Cadre de réponse par fonction

FP1
Le tracker pourra afficher les données récoltées sur un écran Raspberry, puis il pourra également consulter son trajet tracé sur une carte sur un site internet.

FC1
Les données pourront être récoltés toutes les 2 secondes. Les photos seront quant à elle récoltées toutes les 10 secondes. Un retard de quelques secondes pourra se faire remarquer lors de l’envoi d’une photo.

FC2
Le tracker GPS sera transporté dans un boîtier contenant tous les composants. Le boîtier sera en plastique et donc léger. Cependant pour avoir une meilleure efficacité du GPS il est possible de fixer le module GPS à l’extérieur, si le besoin s’en fait ressentir.

FC3
Le raspberry Pi pourra envoyer les données récoltées grâce à un serveur MQTT (pour les données) et grâce à un serveur FTP (pour les photos).

FC4
Le tracker GPS sera alimenté grâce à une batterie externe, pour une autonomie de 2h de trajet avant rechargement.

FC5
Le tracker GPS sera ergonomique grâce au boîtier qui possédera des poignées. Il serait également possible de fixer une sangle sur le boitier pour pouvoir le porter autour du cou. Le boîtier sera transparent afin de pouvoir visualiser les composants.

FC6
Le dispositif sera protégé par le boîtier et sera donc résistant à l’humidité. Le tracker pourra résister à une légère pluie. Cependant l’écran étant positionné sur le dessus, il ne pourra pas résister à une forte pluie.

FC7                                                                                                                                                                                                                                                      Le dispositif  doit avoir un coût finale proche de 250€, en prenant en compte le Raspberry PI, le module GPS, la centrale inertielle, la caméra, l’écran tactile Raspberry PI, la batterie et le support du dispositif.

 

 

 

 

Gestion et réalisation du projet

 

1. Tester et communiquer avec tous les capteurs   

A) Caméra

(Braun/Eckler)

              a) Configuration

Avant de brancher la PiCamera sur votre Raspberry Pi, il faut autoriser la caméra à interagir avec la carte, pour cela il faut exécuter:

sudo raspi-config

 

              b) Branchement

Vous pouvez ensuite brancher la PiCamera à l’endroit indiqué:

              c) Code

Le code ci-dessous permet de prendre une photo et de la sauvegarder dans un fichier sur la Raspberry Pi:

from picamera import PiCamera from time import sleep camera = PiCamera () titre = 4                                           // si on veut que la photo se nomme “image4”. Cette ligne sera par la suite remplacé pour pouvoir sauvegarder les photos à la suite avec un numéro différent def cameraInitialisation () : camera.rotation = 180 camera.hflip = True def cameraCapture (titre) : camera.start_preview () sleep (2) camera.capture (‘/home/pi/Desktop/Images/image%s.jpg’ % titre) // Mettre entre les parenthèses le fichier où vous voulez sauvegarder les photos camera.stop_preview () cameraInitialisation () cameraCapture (titre)

documentation sur la PiCamera:

https://www.raspberrypi.org/documentation/hardware/camera/

 

 

B) Centrale inertielle

(Zaid El Khil / Tissot / Hebinger)

              a) Configuration

Avant de commencer quelconque branchement, il faut configurer votre Raspberry PI pour pouvoir lire les données de la centrale inertielle.

Nous allons utiliser le support I2C de la Raspberry PI:

sudo apt-get install -y python-smbus sudo apt-get install -y i2c-tools sudo apt-get install i2c-tools libi2c-dev

puis exécuter:

sudo raspi-config

pour accéder au panneau de configuration et suivre les instructions suivantes:

 

• aller sur “Interfacing Option”

• ensuite I2C

• Activer

• puis reboot

 

• ensuite il faut commenter dans la “Blacklist de l’I2C”

sudo nano /etc/modprobe.d/raspi-blacklist.conf

et placer un “ # ” devant blacklist i2c-bcm2708

 

• il faut éditer le module conf file

sudo nano /etc/modules

et y ajouter deux lignes:    i2c-dev

i2c-bcm2708

• puis reboot le système une nouvelle fois.

 

              b) Branchement

Pour le branchement de la centrale inertielle, il faut donc relier l’IMU au Raspberry PI en  réalisant le montage suivant:

ensuite la commande:

sudo i2cdetect -y 1 ou sudo i2cdetect -y 0

selon votre Raspberry PI

Un tableau comme ci-dessous devrait apparaître, si ces valeurs sont visibles, alors la configuration et le branchement ont été correctement effectué.

 

              c) Code

Afin de pouvoir lire correctement les données du magnétomètre, de l’accéléromètre et du gyroscope disponible avec la centrale inertielle, le code ,disponible sur le lien ci-dessous, sera nécessaire.

https://drive.google.com/open?id=1-dwNxMipXEEbJau5epRVy8zdp7lH6LXU

 

Avec ce code nous allons commencer par initialiser et paramétrer les sorties pour ensuite les lire comme souhaité.

Les données affichées à l’écran correspondent aux valeurs des axes X, Y et Z du magnétomètre, de l’accéléromètre et du gyroscope.

Pour plus de détails sur les paramètres, les datasheets sont disponibles sur les liens ci-dessous.

datasheet de l’accéléromètre et du gyroscope https://www.pololu.com/file/0J1087/LSM6DS33.pdf

datasheet du magnétomètre             https://www.pololu.com/file/0J1089/LIS3MDL.pdf

 

C) GPS

(Zimmermann/Binder)

              a) Configuration

Pour configurer le module GPS nous avons dû désactiver l’interface série du raspberry en allant dans : Menu>Préférences>Raspberry Pi Configuration. Puis « Serial » sur « Disable ».

Nous avons ensuite modifié dans un terminal le “sudo nano /boot/cmdline.txt” en y retirant : console=ttyAMA0,115200.

              b) Branchement

Pour brancher le module GPS sur le raspberry nous avons simplement utilisé un câble USB vers micro-USB ce qui nous a permis d’avoir un branchement plus propre et plus soigné plutôt que de brancher le module directement avec les broches.

              c) Code

Pour pouvoir utiliser correctement le module GPS et récupérer les données qu’il nous fournit nous avions besoin tout d’abord d’installer le module :

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

 

Grâce à ça nous pouvions par la suite récupérer les données du GPS grâce à la commande “gpsd”.

Ensuite, afin de récupérer les données qui nous intéressaient nous avons utilisé le code suivant qui nous a permis d’avoir la longitude, l’altitude, la vitesse de déplacement…

from gps import * import os def mon_cgps(): session = gps(mode=WATCH_ENABLE) try:  while True:   donnees = session.next()   if donnees[‘class’] == « TPV »:    os.system(‘clear’)    print    print ‘ Information GPS’    print ‘—————————————-‘    print ‘latitude      ‘ , session.fix.latitude    print ‘longitude     ‘ , session.fix.longitude    print ‘temps utc     ‘ , session.utc    print ‘altitude (m)  ‘ , session.fix.altitude    print ‘vitesse (m/s) ‘ , session.fix.speed    print    print ‘satellites    ‘ , session.satellites except KeyError:  pass except KeyboardInterrupt:  print  print « Ferme par l’utilisateur » except StopIteration:  print  print « GPSD s’est arrete » finally:  session = None

 

 

 

2. Enregistrer les données et photos   

A) Enregistrer les données textes

(Hebinger)

Pour enregistrer les données des différents capteurs directement sur la RaspBerry nous avons choisi la sauvegarde sous forme de tableau.

            a) Installation nécessaires

Avant de pouvoir utiliser le script de sauvegarde il faut tout d’abord installer les librairies d’écritures xL à l’aide de la commande suivante

sudo apt-get install python-xlwt

Toute la documentation nécessaire à la compréhension de cette dernière est disponible ici : https://pypi.org/project/xlwt/

 

            b) Code

Tout le script nécessaire se trouve en suivant ce lien : https://drive.google.com/open?id=1d6-4YDzDVPpVTdZg8sJKrt0wrI_OgpVD

Après initialisation du code à l’aide de la commande:

enregistrementExcelInitialiser(trajet_id)

il suffit de faire appel à la commande suivante:

enregistrementExcelValeures(…)

celle-ci ajoutera une ligne au tableau contenant toutes les valeurs spécifiées.

 

 

B) Enregistrer les photos

(Eckler/Hebinger)

Le code permettant de sauvegarder les photos est directement contenu dans le code permettant de la prendre, il suffit de changer ce dernier pour modifier l’emplacement de cette dernière:

camera.capture (‘/home/pi/Desktop/Images/image%s.jpg’ % titre)

 

 

3) Envoyer les données et photos sur les serveurs  

A) Envoi des données textes au serveur MQTT

(Eckler/Tissot/Hebinger)

Avant de pouvoir envoyer quelques chose il nous faut un serveur. Nous avons utilisé le serveur “broker.hivemq.com” ,qui est gratuit, sur le topic “iutmulhouse”, pour pouvoir envoyer nos données textes.

Avant de coder il faut paramétrer la Raspberry PI:

sudo pip install paho-mqtt

 

Il faut ensuite écrire un script en python pour envoyer les données sur le serveur.

Le code est assez simpliste:

import paho.mqtt.publish as publish import time import random def envoiDonnee(n, host): print(« sending…. ») publish.single(« iutmulhouse », »%s » %n, hostname=host)  »’ //exemple de données à envoyer while True: n = « ‘trajet-2′,0515,45458,677,456,78954,236,7891,1587,6814,-987,-785,1548998,5489,4899,0.5,0.748,8,’toto' » envoiDonnee(n, » ») time.sleep(3)  »’

 

 

 

Les données que nous envoyons correspondent à:

• id du trajet
• temps
• les 3 valeurs indiquées par le magnétomètre
• les 3 valeurs indiquées par le accéléromètre
• les 3 valeurs indiquées par le gyroscope
• les 4 valeurs indiquées par le GPS
• les 3 valeurs indiquées par le magnétomètre en Gauss
• titre photo

Enfin, pour pouvoir vérifier et visualiser ces données sur le serveur nous avons utilisé l’application “MQTT Snooper”.

 

*Message Queuing Telemetry Transport

 

 

B) Envoi de photos au serveur FTP

(Tissot)

Pour l’envoi des photos nous avons choisi d’utiliser un serveur FTP. Pour se faire, nous avons tout d’abord crée un emplacement dédié au projet sur le serveur « /geotracker.cf/htdocs/trajets/ ».

Ensuite nous avons initialisé la Raspberry PI avec la commande suivante:

sudo apt-get install vsftpd

 

Puis, nous avons écrit un script en python en 2 étapes:

• Créer un dossier avec l’id du trajet sur le serveur FTP (utiliser lors d’un nouveau trajet)

import ftplib import time def creerDossier(dossier): server = ‘185.27.134.11’ username = ‘b7_21363641’ password = ‘mdp’ ftp_connection = ftplib.FTP(server, username, password) remote_path = « /geotracker.cf/htdocs/trajets/ » ftp_connection.cwd(remote_path) ftp_connection.mkd(dossier) //”dossier” correspond à l’id du trajet

 

• Envoyer la photo sur le serveur dans le dossier que nous venons de créer

def envoiPhoto(local, photo, dossier): server = ‘185.27.134.11’ username = ‘b7_21363641’ password = ‘mdp’ ftp_connection = ftplib.FTP(server, username, password) remote_path = « /geotracker.cf/htdocs/trajets/ » ftp_connection.cwd(remote_path + dossier) fichier = open(local + photo, ‘rb’) ftp_connection.storbinary(‘STOR ‘+photo, fichier) fichier.close() //”local” correspond à l’endroit ou la photo à été enregistré après avoir été prise //”photo” correspond au nom de la photo donné lors de son enregistrement

Il ne reste plus qu’à aller voir sur le serveur si les commandes ont bien été effectué.

*File Transfer Protocol

 

 

4) Réceptions des données et photos ( client à serveur) 

A) Serveur FTP

(Hebinger)

Pour serveur FTP nous avons utilisé celui fourni directement par notre hébergeur web que nous utiliserons plus tard pour le site ( cela permet aussi de faciliter l’accès à ces photos à partir du site ).

Ce serveur nous permet donc de stocker toutes les photos.

La seule chose qu’il faut faire pour préparer le serveur à recevoir les données est de créer un dossier “trajets” dans le dossier web du serveur, ici “htdocs”. Ce dossier permettra de contenir les photos des différents trajets.

exemple:

geotracker.cf/htdocs/trajets/trajet-1/image-0.jpg

 

B) Serveur Node.js / Mysql

(Hebinger)

Les données texte sont sauvées à l’aide d’un serveur node.js et d’une base de données MySQL.

MySQL est un protocole permettant la sauvegarde de données sous forme de table tel un tableur excel. node.js est un protocole serveur permettant l’exécution indépendante de code javascript.

Le serveur node va pouvoir se connecter au serveur de communication MQTT afin de récupérer les infos envoyées par le Raspberry-Pi et va ensuite directement les inscrire dans la base de données MySQL.

            a) Mise en place de l’infrastructure web

Pour notre infrastructure web nous avons fait le choix de nous servir uniquement de services gratuit afin de ne pas être limité par le temps.

Pour cela Heroku à été notre premier choix afin d’héberger le serveur node.js car fiable jusqu’ici : https://www.heroku.com/

Puis nous avons pris un hebergeur MySQL, pour cela nous nous sommes tournés vers db4free : https://www.db4free.net

 

Côté installation pour le MySQL c’est très simple il suffit de se connecter au serveur avec les informations fournies lors de l’inscription. Pour nous cela s’est fait à travers PhpMyAdmin.

Puis il faut créer une nouvelle table de données afin de stocker les informations.

 

Pour le serveur node.js, Heroku procure une installation à travers dropbox suite à l’inscription.

interface sur le site de Heroku suite à l’envoi des données

 

            b) Installation des extension node.js

Pour le serveur node.js nous nous sommes servis de plusieurs “packages” permettants de faciliter la création d’applications et de supprimer les répétitions inutiles et sources d’erreurs.

• express
• mqtt
• mysql
• web-mqtt-client

 

cela peut se faire à travers la console node.js et des commandes suivantes :

 

npm install MySQL npm install mqtt

 

            c) Code de réception node.js

Le code de réception sous node.js permet de se connecter au serveur de communication MQTT, il va attendre un évènement “on message” afin de lire le message envoyé par la Raspberry-Pi et en envoyer les informations à la base MySQL à travers la commande “sendDataToMysql”

code complet commenté disponible ici : https://drive.google.com/open?id=1y4qjYR4vDO6iCB4ZVGP_rQUBJmR7wtqb

 

5) Interface utilisateur  

A) Interface utilisateur Raspberry PI

(Zaid El Khil / Tissot)

Afin de pouvoir contrôler et lire directement le programme et d’assurer son bon fonctionnement, la création d’une interface utilisateur est nécessaire.

Pour cela, nous avons écrit un script en python en plusieurs étapes:

• Créer les dimensions de l’interface, mettre en place un bouton “Nouveau Trajet” et un bouton “Fin de trajet”, ainsi qu’une scrutation en continu de ces boutons lors du lancement du programme.

 

# -*- coding: utf-8 -*- from tkinter import * import time main = Tk() loop=False def scanning (): if loop: print (‘scanning…’) main.after(1000,scanning) main.geometry(« 1280×720 ») main.title(‘interface traquer’) app = Frame (main) Depart = Button(main,text= »Nouveau trajet »,command= NouveauDepart, bg=’#06D806′, width=15, height=2).place(x=’50’,y=’40’) Arrive = Button(main,text= »Fin », command= Fin, bg=’#E31E00′, width=15, height=2).place(x=250,y=40) main.after(1000,scanning) main.mainloop()

• création d’une Scrollbar et d’une zone d’affichage de texte afin de visionner en temps réel les données récupérées et envoyées.

scrollbar = Scrollbar(main) scrollbar.pack(ipadx=50, side = RIGHT, fill= Y) mylist= Listbox(main, yscrollcommand= scrollbar.set ) def afficher(t): for line in range(1): mylist.insert(END,t) mylist.pack(pady=100, expand=50, side = LEFT ,fill = BOTH) scrollbar.config(command = mylist.yview)

 

• Attribuer une fonction à chaque bouton.

def NouveauDepart(): global loop loop= True print (‘Nouveau départ’) t = « Nouveau départ » afficher(t) def Fin(): global loop loop=False print(« Fin de trajet ») t = « Fin de trajet » afficher(t)

(La création d’un nouveau trajet et le lancement des prises de données lors de l’appui sur le bouton “Nouveau départ” sera défini sur le programme final, et de même pour l’arrêt de prise de données lors de l’appui sur le bouton “Fin de trajet”.)

← Visuel de l’interface

 

 

 

B) Interface utilisateur côté serveur

(Hebinger)

L’interface utilisateur serveur permet à l’utilisateur du traqueur GPS de consulter ses différents trajets sur une carte. Il pourra consulter les différentes photos prises et voir un tracé de son parcours, le tout sur une carte ou il pourra choisir entre une vue type “carte” et “satellite”.

Un menu déroulant permet de choisir le trajet voulu et un bouton permet d’actualiser le tracé en temps réel.

Les photos sont accessibles à travers un clic sur les pointeurs le long du trajet.

Le Site est accessible à cette adresse : http://geotracker.cf et est hébergé par https://byet.host/

 

Il a été créé à l’aide de différents langages de programmation tels que le javascript, le php, et le HTML/CSS.

L’accès au service de carte nécessite un code d’API google disponible gratuitement à travers leur plateforme : https://developers.google.com/maps/

 

              a) code

L’interface se sert de HTML et de CSS pour le visuel. L’interactivité est gérée par du javascript et l’accès à la base de données se fait à travers du javascript et du php.

Le code complet, commenté, du site est disponible en suivant ce lien : https://drive.google.com/open?id=1ww60wHfPfqo16twtB_ymCQpQmDPzUTUy

 

 

6) Finalisation du programme principale  

(Hebinger/Tissot)

Pour le programme final nous avons donc rassemblé les différents codes en utilisant la fonction “import”.

Le programme final peut se découper en plusieurs phases:

• L’initialisation du code pour l’interface Raspberry PI
• L’initialisation des différents capteurs en appelant les fonctions “central.initialise()” et
  “camera.cameraInitialisation ()”
• Attribuer aux boutons “nouveau départ” et “fin de trajet” leurs fonctions respectives
• La boucle principale qui envoie et enregistre les données toutes les 2 secondes et les photos toutes les 30 secondes

 

Pour plus de détails le programme est disponible sur le lien suivant:

https://drive.google.com/open?id=1ojvLKpooMv4-dqw6wrcToLJsb8RanAMJ

 

 

 

7) Création du boîtier

(Zaid El Khil / Braun /Eckler)

• Pour la création du boîtier nous avons opté pour un support cubique pouvant permettre le transport de tous les capteurs, batterie, écran et câble. Nous l’avons réalisé à l’aide d’une découpe laser.

• Nous lui avons ajouté des encoches suffisamment grandes pour pouvoir travailler un minimum sur les câbles en cas de petits problèmes (pour les plus gros problèmes qui nécessitent plus d’espace d’intervention nous avons permis l’ouverture du support au niveau de l’écran).

 

• De plus pour le bon fonctionnement des capteurs, la position dans le support est primordiale, leur position n’est donc pas mis au hasard, notamment pour la centrale inertielle et le capteur GPS qui selon leur orientation offriront des valeurs plus ou moins faussées.  La caméra aura une encoche pour lui permettre de prendre des photos.

• Pour plus d’étanchéité nous avons collé les parties basses du boîtier avec une colle industrielle (bien que nous ne pouvons pas assurer une étanchéité maximum en vu des moyens que nous avons).

 

 

Vidéo de présentation

 

 

Nao aide à la rééducation des personnes âgées

 

Sommaire:

 

Membres de l’équipe

Présentation

Introduction

Matériel à disposition

Le robot Nao

Le cahier des charges

Diagramme de la bête à cornes

Diagramme pieuvre

Gestion de projet

Développement du projet

Approfondissements techniques

Problèmes rencontrés

Conclusion

 

Membres de L’équipe :

 

Toussaint Raphaëlle et Dusausay Laura en première années de DUT GEII de Mulhouse sont fières de vous présenter leur projet de second semestre.

Présentation :

 

Au début du second semestre de la première année, tous les élèves exerçants cette poursuite d’études sont amenés à réaliser un projet qui leur est imposé. Les heures de travail sont comprises dans l’emploi du temps et comptent à peu près une soixantaine d’heures.  Cela nous permet d’acquérir de nombreuses compétences et de nous perfectionner dans plusieurs domaines tels que la programmation et la connectivité, mais aussi d’apprendre le langage python ainsi que le logiciel Chorégraphe pour piloter NAO.

Introduction :

 

Cette année L’EHPAD souhaiterai investir dans un robot Nao. Le but de celui-ci serait de venir en aide à l’ergothérapeute en faisant les mouvements demandés.

Ainsi nous rentrons en jeu ! Notre rôle est de programmer un robot NAO afin de faire une représentation lors d’une séance avec l’ergothérapeute. Ce qui permettra à l’EHPAD d’investir ou non dans un robot.

Matériel à disposition :

 

Pour ce projet  nous avons à notre service 4 robots Nao, le logiciel choregraphe, une imprimante laser et une en couleur. Ayant déjà tout le matériel nécessaire pour réaliser ce projet nous n’avons aucun budget supplémentaire à notre disposition.

Le robot Nao :

 

Ce robot est un robot humanoïde créé par l’entreprise familiale française Aldebaran Robotics. Il contient une multitude de capteurs qui lui permettent au mieux de recréer les mouvements humains et qui lui permettent d’être très autonome. Il peut par exemple reconnaître qu’il est couché sur le sol et peut ainsi se relever sans difficultés. Il est ainsi doté de 4 capteurs à ultrasons sur le torse, deux caméras Haute Définition, 8 capteurs de pression, des bumpers sur les pieds ainsi que d’un accéléromètre et d’un gyromètre. Il a un poids total de 4,8 kg. Il a un “cerveau”  qui est programmable à l’aide du logiciel “Choregraphe”.Celui-ci a une interface simplifiée faite de boîtes pré-programmés. Ainsi ce logiciel est facile à prendre en mains au départ. Évidemment dès que l’on veut personnaliser les boîtes, approfondir le programme, il faut commencer à coder.

 

Cahier des charges:

 

Nous devons, pour ce projet, respecter un cahier des charges défini par l’ergothérapeute lors d’une réunion qui se déroulait une semaine avant le démarrage des deux semaines de projet. Dans ce cahier des charges nous retrouvons:

 

• La liste des mouvements à reproduire
• Les mouvements ne doivent pas être trop rapide
• Le robot doit expliquer le mouvement à faire et doit compter le nombre de répétitions d’une voix lente et forte
• Le robot doit être facile d’utilisation et doit pouvoir se commander oralement ainsi que visuellement à l’aide de pancartes.
• Le robot doit pouvoir répéter les mouvements 10 fois
• Le robot doit avoir une autonomie suffisante pour tenir 1h sans recharge
• La séance doit pouvoir être personnalisable en choisissant les mouvements voulu et pas avoir toujours la même série d’exercices
• Le programme doit être finalisé avant le 18 juin, date de la soutenance finale

Diagramme de la bête à cornes:

 

Diagramme pieuvre:

Gestion de projet:

 

Afin de mener à bien ce projet, il a fallu s’organiser intelligemment. Nous nous sommes tout d’abord distribuée les différents mouvements à créer, puis DUSAUSAY Laura s’est occupée de l’interaction visuelle avec le robot à l’aide de pancartes, TOUSSAINT Raphaëlle s’est occupée de l’interaction vocale avec le robot. Ces deux semaines étaient vraiment très remplies puisque nous travaillions sur ce projet tous les jours de 8h30 jusqu’à 17h45.

Développement du projet:

 

Il a tout d’abord fallu nous familiariser avec le logiciel “Choregraphe” qui est un logiciel plutôt simple d’utilisation. Grâce à un document fourni par notre professeur, nous avons pu nous entraîner à programmer différents mouvements de la tête, des bras, des poignets et des doigts. Avec ce logiciel nous avons aussi dû programmer en Python, par chance nous connaissions déjà un peu ce langage de programmation.

Nous avons donc commencé ces deux semaines de projet par une journée de programmation des différents mouvements ainsi que le fait de pouvoir enchaîner un même mouvement 10 fois. Nous avons ensuite dû penser à la façon de programmer NAO pour qu’il comprenne ce qu’on lui dit, qu’il nous réponde puis qu’il fasse l’action demandée. En parallèle, nous avons dû réfléchir à la façon dont le NAO pourrait reconnaître un mouvement visuellement. Nous sommes donc parties sur l’idée de pancartes que le NAO devra reconnaître. Une fois la pancarte reconnue, il devra expliquer le mouvement voulu et le faire 10 fois.

Une semaine plus tard, l’ergothérapeute est revenue nous voir pour constater l’avancée de notre projet et nous donner les points à améliorer. Suite à cette réunion nous avons conclu que le robot parlait trop vite et que ses mouvements étaient trop rapide, elle nous a aussi demandé que le NAO puisse compter le nombre de fois qu’il a fait le mouvement, qu’il puisse se lever en début de séance afin de se présenter et qu’il se mette assis après avoir remercié les personnes de l’avoir écouté.

Choses promises, choses dues, elle revient nous voir le dernier jour de projet pour voir l’aboutissement de notre travail qu’elle a trouvé très satisfaisant. Nous avons ainsi convenu un rendez-vous à l’EHPAD afin de faire une présentation à plusieurs résidents.

Ce moment tant attendu est enfin arrivé, le stress était palpable, les résidents allaient-ils aimer l’idée d’un robot qui les aide dans la rééducation? La séance se déroule avec malheureusement quelques petits problèmes techniques. Le personnel de l’EHPAD était épanoui et heureusement pour nous les résidents l’étaient aussi!!! Ils avaient juste une crainte, celle que le robot remplace définitivement l’ergothérapeute, mais le directeur leur a expliqué qu’il ne sera qu’une aide et ne remplacera jamais aucun employé de l’EHPAD, alors les résidents étaient ravis.

 

Approfondissements techniques:

 

Nous allons vous expliquer plus en détail comment nous avons réalisé les mouvements, l’interface audio ainsi que visuelle.

1.Mouvements:

 

Nous avons réalisé nous même les mouvements que nous avons besoin pour ce projet. Pour ce fait nous avons utilisé la fonction “ timelines” . Celle-ci donne sur un Nao virtuel que nous pouvons positionner comme on le souhaite, et enregistrer sa position.

           

 

Chaque séquence de 1 mouvement fut enregistré dans un dossier séparé, eux même inclus dans un dossier contenant une boucle (10 répétitions des mouvements), une fonction “say” (pour que le Nao explique le mouvement).

2.Interface audio:

 

L’interface audio est réalisée à partir d’un “Qichat” codé en python. Qichat permet d’avoir une interaction vocale avec le robot. Pour ce fait nous avons enregistré les différentes phrases types que Nao reconnaît comme un déclencheur d’exercices ou de réponses.

3.Interface visuelle:

 

Le Nao possède une vision HD mais celui-ci ne sait pas lire. Il se contente de reconnaître les formes et les couleurs qu’il voit. Ainsi nous avons fabriqué des tablettes pour chaque exercice. Ces tablettes de format A5 contiennent un nuage de mot représentant une forme avec des couleurs différentes.

Avec la fonction “vision recognize” nous avons enregistré chaque image/tablette dans la banque de données du Nao. Ensuite avec un “switch cases” nous avons associé les images à une série d’exercices eux même enregistrés dans sa base de données.

 

Problèmes rencontrés:

 

Dans ce projet le problème majeur fut dans le codage du Qichat. En effet celui-ci ne reconnaissait pas le compteur et ils nous était impossible de régler la voix. De plus la reconnaissance vocale du Nao étant très faible il nous était difficile d’avoir un résultat fiable, c’est pourquoi nous avons opté pour une solution alternative: la reconnaissance visuelle.

Mais nous avons eu quelques problèmes également pour la reconnaissance visuelle. En effet lors de la réalisation nous avons toujours eu les mêmes contraintes environnementale (forte luminosité, salle calme…) Ainsi lorsque nous avons présenté notre projet à l’EHPAD, la luminosité de la salle étant plus faible la reconnaissance des tablettes/images fut laborieuse.

Conclusion:

 

Malgré les difficultés rencontrées nous avons réussi à terminer notre projet et même aller au delà en faisant une démonstration à l’EHPAD.

Nous sommes ravies d’avoir pu travailler avec des professionnels. Cela fut très enrichissant et concret. Nous avons pu lier la programmation, l’interaction Homme/machine ainsi que la demande de l’employeur.  Nous remercions donc l’EHPAD de l’arc à Mulhouse de nous avoir fait confiance, l’ergothérapeute qui nous a suivis durant ce projet pour adapter au mieux l’interaction avec le Nao. Nous tenons également à remercier notre tuteur de projet M.Cudel.

 

 

 

Projet Robot de combat MakerFight

 

 

Sommaire

 

 

I) Contexte et définition du projet

1) Contexte (p3)

2) Objectifs de notre groupe (p3)

3) Périmètre du projet (p4)

4) Critères d’acceptabilité (p4)

 

II) Besoins du robot (p5)

III) Contraintes

1)Coûts (p6)

2) Délais (p6)

3) Autres (p6)

 

IV) Déroulement du projet

1) Planification (p7)

 

V) Journée MakerFight et préparation

 

 

 

I)Contexte et définition de projet

 

1. Contexte

 

Le MakerFight est un événement créé il y a 3 ans permettant de réunir des intéressés de la robotique, de la mécanique et de l’électronique afin de faire concourir des robots de combat en les faisant s’affronter dans une arène.

La première édition du MakerFight était privée mais cette année, celle-ci est ouverte a tous ceux qui veulent y présenter un robot de combat. Cet événement se déroulera cette année le Samedi 21 avril.

 

2) Objectifs de notre groupe

Pour cet événement, notre groupe se fixe plusieurs objectifs :

 

• Avoir à la date du 21 avril, un robot permettant de concourir.
• Contrôler le robot à distance
• Faire fonctionner tous les moteurs
• Remporter des matchs

 

3)Périmètre du projet :

 

Pour le bon fonctionnement de notre projet, notre groupe de quatre membres (TOUSSAINT Raphaëlle,KIEFFER Maxime, HUSSER Valentin et JUND Bastien) avons dû nous fixer des limites pour notre projet :

 

• Le règlement du MakerFight (Masse, types d’armes)
• Notre budget de 200€
• Le temps imparti pour notre projet
• La faisabilité technique

 

 

4)Critères à respecter :

 

Pour valider notre robot, et ainsi lui permettre de concourir, nous avons dû soumettre notre robot a plusieurs règles :

 

Les armes interdites :

-Explosifs

-Liquide

-Êtres vivants

-Projectiles

-Décharges électrique

Autres contraintes :

-Masse : 20 kg maximum avec une marge de 100 grammes

-Contrôle du robot à distance (sans fil)

-Nécessite un dispositif de sécurité en dehors de l’arène

 

II)Besoins du robot

 

N°	Fonction	Critères	Priorité	Flexibilité
FP1	Doit se déplacer sans problèmes dans l’arène	-roues -taille	Haute	Temps de réaction variable
FP2	Doit respecter les contraintes imposées	-Poids -Armes -Budget	Haute	Poids : +100g
FP3	Doit utiliser les armes à disposition	-scie -bèche	Haute	/
FC1	Fournir une documentation	Site des projets	Moyenne	Date remise doc
FC2	Etre transporter en sécurité	Protection plastique	Haute	/
FC3	Préparation évènement MakerFight	Entrainement contrôles	Faible	/

 

III)Contraintes

 

1)Coûts

 

Le budget accordé à notre projet est de 5O € par personne, soit un total de 200 €. Un peu moins de la moitié de notre budget a été dépensé pour acheter des batteries et environ 50€ ont été dépensé pour des cartes électroniques.

Pour réaliser notre projet, nous avons pu bénéficier de l’aide de Mr.DeSabbata , ainsi qu’un accès à l’IUT Lab , ou nous avons pu utiliser les logiciels tel que CorelDraw ou différentes machines, ce qui nous as permit d’économiser de l’argent et du temps.

 

2)Délais

 

Le délai final pour notre robot est la date du MakerFight, c’est-à-dire le 21 avril 2018. Depuis le début de notre projet, nous avons assister à plusieurs réunions (en Novembre et en Février), permettant de mettre au point l’avancement de notre robot.

 

3)Autres

 

En termes de contraintes, nous avons dû nous renseigner sur les différentes règles du MakerFight, ainsi que sur les mesures de sécurité à prendre concernant la protection des armes en dehors de l’arène, afin d’éviter tout risques.

Nous avons aussi dû prendre en compte le délai imposé par l’IUT pour l’achat de nos différents composants, pour la gestion de notre budget. Le fait de travailler sur le robot uniquement en dehors des heures de cours est aussi une contrainte en plus.

 

 

 

IV)Déroulement du projet

 

Depuis le début de notre projet, nous sommes passés par plusieurs phases :

-Phase de recherches : formes du robot, type d’armes, idées …

Durant cette premiere phase, nous avons tout d’abord fait quelques réunions afin de décider de la taille et de la forme finale du robot. Nous avons aussi commencé a imaginé

les différentes armes de notre robot ainsi que son moyen de déplacement.  Nous en somme arrivés a la conclusion que notre robot sera rectangulaire et possédera comme armes :

-une scie

-une bêche coupée en deux

-Deux bras a l’avant

-Phase de conception : 

Lors de cette deuxième phase , nous avons commencé a faire des tests pour réaliser une maquette de notre robot, ainsi que ses plans . Pour cela  nous avons utilisé différents  logiciels tels que CorelDraw et Solidworks. Cette phase s’est étendue jusqu’au dernier jour car il comporte aussi la partie programmation sous Arduino qui fut un véritable casse-tête

 

 

 

-Phase de récupération : matériaux, moteurs, recherche partenariat

Cette phase ci fut l’une des plus longues car nous devions recherché tous les matériaux nécessaire a la fabrication de notre robot. Pendant plusieurs mois, nous avons recherché des moteurs de perceuses pour faire fonctionner les roues , un moteur de ventilateur de moteur de voiture pour notre scie , des moteurs de lève-vitre pour les bras du robot ainsi qu’un moteur d’essuie glace pour notre bêche. Nous avons réussis a en trouver une grosse partie en demandant à des casses automobiles et les moteurs de perceuse en demandant dans notre entourage. Pour le châssis , nous avons obtenus un partenariat avec un métallurgiste du nom de John Steel qui nous a gracieusement offerts les plaques pour notre châssis en échange d’un peu de visibilité.

-Phase d’assemblage  : fixation et modification moteurs

Durant cette phase , nous avons du modifier certains moteurs pour les adapter a notre robots :

 

-moteurs des roues :

Nous avons modifié le moteur de tel sorte qu’il soit plus résistant et moins limité dans ses capacités ; nous avons remplacé l’étage de pignons en plastique qui entraîne le moteur par des pignons en métal et nous avons enlevé le limiteur de couple pour éviter que les roues soient limitées en vitesse , donc en maniabilité.

 

-moteur de bêche

 

Pour celui-ci , nous n’avons pas eu besoin de modifier la moteur .En revanche , nous avons du fixer un bras à la bêche et percer un trou de la bonne taille dans ce meme bras afin de l’emboiter dans l’axe du moteur

 

-moteur de scie

 

Encore une fois , nous n’avons pas eu besoin de modifier le moteur mais nous avons du récupérer l’axe d’un moteur de meuleuse. Nous avons usiné la pièce et permis ainsi d’entraîner notre scie sans que cette dernière puisse sortir de son axe.

 

V) Journée Makerfight et préparation

Malgré que la nuit fût courte, nous étions remonté à bloc (malgré le stress) pour cette journée, lors de notre arrivée, il nous restait un certains nombre de test à faire:

-Vérifier que les roues fonctionnait correctement, la bêche ainsi que la scie.
-Prendre en main la maniabilité du robot

 

Arriva le moment temps redouté par tous les robots de la pesé ainsi que des tirages aux sorts pour les groupes:

Tout se déroulait correctement jusqu’à notre premier combat aux alentours de 10h45, nous affrontions le redoutable Sweetie Bot, la première manche fût remporté par lui, lors de celle-ci notre scie, monté à l’envers se dévissa et nous ne pouvions donc utiliser que la bèche, malgré celà nous remportons la deuxième manche avant de nous incliner sur la troisième manche.

Après le combat, ce fût une véritable course:
-Remonter la scie à l’endroit.
-Le pont en H de la bèche était HS.

Pas de répis, il fallait tout réparer avant le deuxième combat face à Schbunk, un adversaire redoutable.

Arrive donc le moment fatidique : Le combat contre Schbunk.

La première manche fût totalement en son sens.
La deuxième manche, nous arrivons à accrocher cette manche avant une troisième qui promettait d’être très mouvementé.
Mais, lors de la deuxième manche, une de nos roues avaient cessé de fonctionner, la dernière manche promettait d’être compliqué, mais, malgré ça, le robot s’est bien défendu !

Il avait maintenant, quelques blessures de « guerres », et avait survécu.
Comme le combat précédent, il était de notre devoir de le remettre sur roues pour qu’il puisse continuer à concourir.

La suite des matchs, se fût malheureusement sur deux roues (fautes aux pont en H).
Malgré ça, le robot s’est bien défendu et cette journée fût affolante et excitante à vivre!

Une expérience à refaire!