Maquette pour la mesure de variation de température

Projet d’étude et réalisation GEII 1ère année

Maquette capteur de température

Sommaire

I – Présentation du projet

1 – Membres de l’équipe

2 – Objectif de la maquette

3 – Maquette déjà existante

II – Analyse fonctionnelle

1 – Bête à cornes

2 – Mindmap

3 – Diagramme de GANTT prévisionnel/effectif

III – Réalisation

1 – Choix des composants

2 – Circuit imprimé pont de Wheatstone

3 – Circuits imprimés de l’alimentation

4 – Affichage / Gestion des relais

5 – Boîtiers et câblages

IV – Conclusion

1 – Difficultés rencontrées

2 – Bilan du projet

3 – Remerciements

 

I – Présentation du projet

1 – Membres de l’équipe

L’équipe est composée de trois élèves de première année de DUT Génie Electrique et Informatique Industrielle de l’IUT de Mulhouse : GUITARD Sophie, GER Mickaël et SZAND Michaël.

2 – Objectif de la maquette

Initialement, la maquette est utilisée dans le cadre d’un TP d’électrotechnique de première année. Le but de ce TP est de relever une température variable entre 20 et 60°C sur différents capteurs de température afin de les comparer.

   

3 – Maquette précédente

Les professeurs de l’université souhaitent réaliser une nouvelle maquette afin d’améliorer le système de refroidissement (celui-ci ayant été réalisé jusqu’ici par un ventilateur USB), d’obtenir des soudure plus solides sur le circuit imprimé du pont de Wheatstone et de réorganiser celle-ci afin qu’elle soit plus compréhensible pour les élèves.

II – Analyse fonctionnelle

1 – Bête à cornes

2 – Mindmap

3 – Diagramme de GANTT

          Prévisionnel                                                                          Effectif

En pratique, le déroulement de notre projet a été quelque peu modifié. Certaines tâches on été réalisées plus rapidement que prévu (comme par exemple la programmation de l’Arduino) tandis que d’autres on été un peu plus longues.

III – Réalisation

1 – Choix des composants

Afin de concevoir notre nouvelle maquette nous avons dû procéder à un choix de composants.

  • Arduino UNO : microcontrôleur utilisé dans notre projet pour la gestion des relais, des boutons et de l’affichage de la température.
  • Ecran LCD : afficheur à cristaux liquide pour la température.
  • Résistances variables : celle ci vont permettre d’avoir une valeur de résistance réglé a la perfection contrairement a des résistances constante
  • Résistance chauffante : permettant d’augmenter la température du montage.
  • Module Peltier : permet de diminuer la température du montage.
  • Relais : alternant mode chauffe/refroidissement à l’aide des boutons poussoirs.

Le budget consommé de notre projet est donc de 106€, notre budget alloué étant de 200€.

2 – Circuit imprimé du pont de Wheatstone

Un pont de Wheatstone est un montage électrique permettant de mesurer une résistance électrique inconnue par équilibrage de deux branches d’un circuit en pont. Nous l’utilisons dans notre montage afin de déterminer la résistance de la CTN, variante en fonction de la température. Afin de réaliser le circuit imprimé, nous avons utilisé le logiciel de conception Kicad.

       

Ce circuit imprimé comprend donc 3 parties distinctes :

  • le pont de Wheatstone;
  • la linéarisation de la résistance RP;
  • la linéarisation du capteur AD.

3 – Circuit imprimé de l’alimentation

Afin d’alimenter l’ensemble de notre montage, nous avons réalisé des circuits imprimés supplémentaires contenant de simples borniers.

4 – Affichage / Gestion des relais

L’affichage de la température donnée par le capteur AD592 se fait sur un écran LCD par l’intermédiaire d’un Arduino. Deux boutons sous l’écran nous servent à passer du mode chauffe au mode refroidissement par l’intermédiaire de relais dirigé par l’Arduino. De plus, la maquette est programmée pour passer du mode chauffe au mode refroidissement dès que sa température excède  60°C et inversement lorsque celle-ci est inférieure à 20°C.

   

      

5 – Boîtiers et câblages

Deux boîtiers distincts on été réalisés pour la maquette. L’un pour accueillir le circuit imprimé du pont de Wheatstone, de dimension 72,9 mm x 115,7 mm x 60 mm contenant 10 borniers permettant à l’élève d’y brancher la résistance RP, le capteur CTN, le capteur AD et deux sorties V+, V- pour mesurer la résistance résultante du montage de Wheatstone ainsi que l’alimentation VCC et la masse . Le deuxième boîtier permet quant à lui d’accueillir les capteurs de températures, la résistance chauffante, le module Peltier, un ventilateur ainsi que les deux alimentations 5V et 12V.

IV – Conclusion

1 – Difficultés rencontrées

Aucune difficulté majeure n’a été rencontrée, mis à part le délais de livraison de certains composants ayant légèrement retardé notre projet et un problème de transfert de température entre le support et la résistance chauffante entraînant des pertes de chaleurs très élevées.

2 – Bilan du projet

Ce projet nous à permis de mettre en pratique les compétences qui nous on été enseignées durant l’année, de respecter minutieusement un cahier des charges, ainsi que de s’organiser dans le temps et de travailler en équipe.

3 – Remerciements

Nous tenons à remercier Mr COLICCHIO et Mr STRAFELLA pour leur aide tout au long du projet.

Nous voulions également remercier Mr DE SABBATA pour nous avoir guidé pour la conception des boîtiers à l’IUTLab, Mr XU pour avoir répondu à toutes nos questions ainsi que Mr WIRA pour nous avoir fourni l’écran d’affichage LCD.

Nous remercions enfin Mr ROTH pour nous avoir porté conseil lors des soutenances au fil des semaines.


Centrale d’autoconsommation solaire

Projet GEII 2ème année

Centrale d’autoconsommation solaire

 

 

Sommaire:

  1. Présentation de l’équipe

  2. Principe de l’autoconsommation

  3. Présentation du Projet

  4. Cahier des charges

  5. Etude du projet

  6. Réalisation du projet

  7. Bilan du projet

  8. Conclusion

  9. Remerciements

  10. Sources

1. Présentation de l’équipe

Nous sommes un groupe d’élèves en 2ème année de Dut GEII, Maillot Thibaut, Raedersdorf Adrien et Schaeffer Victor

2. Principe de l’autoconsommation

L’autoconsommation se définit par le fait de consommer l’énergie produite soit même à l’aide d’énergies renouvelables, mais c’est plus souvent l’énergie solaire qui utilisée par les particuliers produisant leur propre énergie par volonté de préserver la planète, faire des économies ou être indépendant énergétiquement. On associe l’autoconsommation à l’autoproduction qui est le fait de produire sa propre énergie.

En France 77% de l’énergie produite est issue du nucléaire et seul 1,6% de l’énergie produite est de l’énergie  solaire. Ce chiffre varie d’ailleur en fonctions de plusieurs conditions comme la météo, ou l’heure de la journée.

Quand on parle d’autoconsommation énergétique on parle généralement d’énergie photovoltaïque car c’est la plus simple à utiliser pour un particulier, il existe également l’autoconsommation éolienne mais elle est plus compliquée à mettre en place de par la réglementation et d’autre part l’incertitude de production d’une éolienne.

La France avait un retard par rapport à ses voisins l’Allemagne et l’Italie et qui favorisent déjà l’autoconsommation solaire avec des primes à la conversion et des possibilités de revente d’électricité aux producteurs. La France commence seulement à investir dans ce secteur, en légifèrent avec l’union européenne pour augmenter sa part de production en énergie renouvelable.

Depuis la loi du 24 juillet 2017 la vente de courant entre fournisseur et particuliers est légiférée, les particuliers peuvent vendre du courant à leur fournisseur électrique en réinjectant du courant dans le réseau et les auto-consommateurs sont exonérés de la taxe départementale de consommation finale d’électricité et de la CSPE.

En France en  2016  environ 40% des demandes de raccordement étaient pour l’autoconsommation solaire en  2017 il y a eu 19 000 installations photovoltaïques, dont 7 000 pour l’autoconsommation. Et le nombre d’installations solaire en autoconsommation ne cesse d’augmenter depuis 2017.

C’est dans ce contexte, que notre projet ce déroule, en effet en tant qu’étudiant en GEII nous devons nous tenir à la page, ce projet est donc dans l’ère du temps.

 

3. Cahier des charges

diagramme bête à cornes

Préambule

Le projet consiste à réaliser une centrale d’autoconsommation solaire.

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 est une initiative de l’enseignant tutorant, au vu de l’augmentation de systèmes autoconsommation en France, réaliser et étudier une centrale autoconsommation est un projet qui s’inscrit dans l’esprit d’une filière technologique.

Objectifs

Nous devons dimensionner et réaliser un système MPPT transportable à partir d’un panneau photovoltaïque mobile. Ce système doit être autonome, et pourra alimenter divers appareils de faible puissance.

Description de l’environnement logiciel

  • Arduino
  • KiCad
  • Victron connect
  • Coreldraw

Description de l’environnement matériel

  • Dispositifs électroniques.
  • Matériel d’ER de l‘IUT.
  • Outillage de l’IUT lab.

Contraintes techniques:

  • La limite de puissance de notre onduleur est de 300W
  • La sécurité du système, il ne faut pas déconnecter la batterie quand le panneau délivre du courant au risque d’abîmer nos composants, il faut prévoir de l’aération pour que la batterie ne chauffe pas trop.
  • Eviter La décharge complète de la batterie car celà réduit sa durée de vie.

 

4. Etude du projet

Schéma de principe

  • Le panneau photovoltaïque fournit du courant continu au régulateur MPPT
    1. Par traitement algorithmique la MPPT utilise le courant du panneau pour gérer la charger la batterie, elle maintient également la charge de la batterie et gère la décharge à l’aide de ses algorithmes préprogrammés.
    2. La MPPT peut directement alimenter une charge continue avec le courant délivré par le panneau photovoltaïque.
    3. Le remote on/off câble sert à contrôler l’allumage l’onduleur par  la MPPT
  • La batterie délivre du courant continu à l’onduleur qui convertit ce courant continu en alternatif.
  • L’onduleur est relié à des prises terre  et permet d’alimenter des appareils en 230V/50Hz
  • A noter la présence d’un fusible de 4 A pour protéger la batterie.

Composants

Panneau photovoltaïque

Un panneau photovoltaïque est un dispositif d’énergie renouvelable, qui transforme l’énergie solaire en énergie électrique.

La lumière du soleil est composée de particules appelées photons qui en entrants en contact avec les cellules de silicium du panneau vont exciter celles-ci et provoquer un mouvement d’électrons entre les parties chargées négativement et positivement,  générant du courant .

Notre panneau est un A-50M  de la marque Atersa, fourni par l’enseignant qui n’est plus disponible sur la marché .

 

 

C’est un panneau photovoltaïque polycristallin, c’est à dire que ses cellules sont composées de plusieurs cristaux de silicium agencées pour former la cellule.

 

 

Caractéristiques:

En conditions de test standard (1 kW/m², 25±2°C AM 1,5)

Puissance (w) 50 ±8%
Ipc (A) 2,64
Upc (V) 18,95
Icc (A) 2,95
Pnom(W) 220W
Uoc (V) 22,46
Eff 13,94%

 

 

 

Régulateur de charge solaire  MPPT

Une MPPT est un dispositif électronique, qui par traitement algorithmique gère le niveau de décharge de la batterie et la puissance que fournit la panneau au système.

Il existe différents algorithmes mais le plus rependu et le plus simple est l’algorithme Perturb and Observe.

P&O (Perturb and Observe)

  1. On mesure P1 la puissance du panneau photovoltaïque pour une tension U1 donnée.
  2. L’algorithme impose une tension U2 = U1 + dU et mesure la puissance correspondante à U2
  3. Si P2>P1 l’algorithme impose U3=U2 + dU
  4. SI P2<P1 l’algorithme impose U3=U1- dU

 

Nous utilisons une MPPT  SmartSolar 75V/15A de la marque Victron

Caractéristiques:

U (V) 13,8 V
I (A) 14,4
Icharge (A) 15
Uemax (V) 75
Imax (A) 15

Autoconsommation de la MPPT  25mA

 

Onduleur

Un onduleur est un système d’électronique de puissance qui convertit un courant continu en courant alternatif, dans un système d’autoproduction on utilise des onduleurs hybrides.

 

Nous utilisons un convertisseur Phoenix 350/12  de la marque Victron

Caractéristiques:

Puissance (VA) 350
Puissance (W) 300/250
Umoy (V) 230 ± 3%
F (HZ) 50 ± 0.1%
Ue 12
Eff 89%

 

Batterie AGM « Absorbed Glass Mat »

Une batterie à accumulateurs abrégé batterie est un système pouvant « stocker » du courant par des réactions électrochimiques, une batterie AGM (absorbed glass mat) est un type de batterie destiné à l’autoconsommation solaire au même titre que les batteries GEL, elles sont adaptées aux petits systèmes d’autoconsommation car supportent mieux la décharge profonde,  se chargent rapidement, sont plus légères que des batteries GEL et sont résistantes aux changements de température.

 

Batterie 12 V 60 Ah AGM de la marque Victron

 

 

Dimensionnement des composants

On dimensionne nos composants à partir des caractéristiques du panneau :

Puissance maximale en Watt-crête (W) 50 ±8%
Ipc (A) 2,64
Upc (V) 18,95
Icc (A) 2,95
Uoc (V) 22,46
Eff 13,94%

 

1 l’intensité maximale du régulateur MPTT

Cette intensité doit être supérieure à l’intensité de court-circuit (Icc) de notre panneau, avec une marge de sécurité de ±10-20%

Dans notre cas le courant de court-circuit du panneau est Icc =2,95 A, la MPPT doit donc pouvoir accepter

2,95 ±20% soit 3,54 A.

2 choix du parc de batterie en fonction de la puissance du panneau

 

Puissance de l’installation photovoltaïque Tension de batterie recommandée
0 – 800 Wc 12V
800 – 1600 Wc 24V
1600 Wc  et + 48V

 

Dans notre cas le panneau fournit 50 Wc en condition optimales on choisit donc un parc de batterie 12V.

Une méthode plus simple est de dimensionner par rapport au nombre de cellules du panneau ex : 36 cellules 12V, 72 cellules 24V

Avec un régulateur MPPT Il faut que la tension du panneau en circuit ouvert soit supérieure à celle de la batterie dans notre cas Uoc = 22,46V > 12V donc on peut utiliser une batterie 12V.

3 Tension maximale MPPT

On doit déterminer la compatibilité de la MMPT avec la tension du panneau en circuit ouvert +20% marge de sécurité en fonction de la température, dans notre ca on a

20% de 22,46 soit 4,492

Uoc= 22,46 + 4,492=26,952 V, on arrondit à 27 V.

Grâce à ces calculs on peut déterminer que notre régulateur de charge solaire sera une MPPT 75V/15A, pour deux  raisons, la première c’est qu’on surdimensionne  la MPPT en courant (on prend 15A au lieu de 10A) au cas où on devrait  rajouter un panneau. La deuxième raison est qu’il n’existe pas de modèle de MPPT en dessous de 75V.

4 l’onduleur

Il faut que la somme des puissances (en Watt) de nos appareils branchés soit inférieure à la puissance délivrée par l’onduleur.

Notre onduleur 12/350 délivre entre 300 W maximum il faut donc que nos appareils branchés ne dépassent pas cette puissance, un gros pc fixe par exemple ne doit pas être alimenté à notre système

Choix des câbles :  

On débite moins de 16 ampères, on prend donc  des sections de 1,5mm².

5. Réalisation du projet

Fabrication du support

Nous étions au départ partit sur un modèle design basé sur Skavenji mais au vu du poids total de nos composants (environ 50kg), ils nous fallait se rabattre sur un support solide et simple.

Nous avons acheté une planche de bois de sapin résistant aux changements de température de la batterie et assez épaisse qui servirait de support de base pour notre montage. Nous avions pros la taille des composants pour définir la taille minimale de notre base sur laquelle est fixée la batterie et l’onduleur, donc les composants les plus lourds (30kg au total)  de la base en prévoyant de l’espace pour la batterie qui chauffe.

Nous avons également acheté des roues pour les fixer sur le support, en effet le poids ne permettant pas d transporter notre montage manuellement les roues permettent un transport plus facile de notre centrale.

Pour le reste de la boite nous avons utilisé des plaques de contreplaqué fournies par Mr. De Sabbta, que nous avons découpées au laser, à partir d’un schéma réalisé sur Coreldraw. Nous avons prévu des emplacement pour mettre 2 prises terres, un allume cigare et des connecteurs bananes 4mm femelles pour connecter notre panneau solaire au système.

 

 

 

 

 

Les plaques de contreplaqué sont tenues entre-elles et à la base  par des équerres vissées.

 

Nous avons utilisé Des vis pour l’onduleur et la MPPT qui elle est fixée sur une des plaques de contreplaqué à la vertical comme demandé dans le manuel d’utilisation du produit. La batterie ne dois pas être percée ou abîmée il  nous a fallu la caler avec des  plaquettes de bois clouées à la base.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notre onduleur ayant des sorties connecteurs IEC C/14 femelles, il nous faut câbler un adaptateur pour relier l’onduleur aux prises terre.

 

 

 

 

 

 

Commande par Arduino

 

 

Il était  l’origine prévu de réaliser un switch entre  la MPPT  l’onduleur et la batterie pour pouvoir tirer du panneau depuis l’onduleur

Nous avions donc pensé à une carte électronique à transistors NPN,  commandée en 5V par un Arduino UNO. Le but était de faire commuter la sortie de la MPPT directement sur l’onduleur si le panneau fournissait son maximum de puissance, que l’on aurait mesuré avec les capteurs de l’arduino.

 

 

Nous avons réalisé une plaquette test avec un programme de commutation de transistors fonctionnel. Nous avons également prévus les capteurs de courant connectés à l’arduino ainsi que la partie du programme qui s’occupe de traiter les informations des capteurs.

Nous avons ensuite conceptionné et fabriqué la carte de commande avec ses 4 transistors, mais nous nous sommes posé la question de la présence de la carte  pour commander le système.

Nous avons conclu qu’il valait mieux abandonner pour les raisons suivantes:

  • Notre système MPPT Victron est déjà complètement autonome,  ajouter un élément extérieur qui perturberait le comportement de notre système ne serait pas une bonne idée.
  • Il est déconseillé de débrancher la batterie pour une commutation sur onduleur car cela risque d »endommager le système ou au minimum le perturber.
  • Commander notre système pour le faire commuter au moments ou le panneau produit à son maximum aurait réduit l’efficacité de la charge de la batterie.
  • Le panneau est de faible puissance et l’onduleur reçoit 12V de tension nominale hors notre panneau fournit environ 18V il y adonc peu de chance que la commutation par transistors fonctionne.

7. Bilan du projet

Résultats

 

Au moment ou nous rendons ce rapport, la boite est opérationnelle et peut alimenter des appareils, il manque un adaptateur c/14 pour la prise terre restante et l’allume cigare n’est toujours pas connecté.

Il est inutile de faire de la réinjection sur le réseau avec un panneau de faible puissance comme le notre, cet aspect n’est donc pas étudié dans notre projet.

Suite à une concertation avec l’enseignant tutorant, nous avons décidé de changer notre MPPT pour un modèle avec Bluetooth intégré afin de pouvoir faire des mesures de consommation et de production de notre système avec l’application Victro Connect.

8. Conclusion

Le projet doit encore être perfectionné et nous pensons qu’il aurait été plus intéressant de réaliser la majorité du système nous mêmes, par exemple en créant intégralement un véritable régulateur MPPT à partir d’un Arduino ou d’un Raspberry Py. Cela aurait pu pousser l’aspect technique à un niveau supérieur. En plus de rendre possible la commutation directe sur onduleur possible, même si au vu de la faible puissance de notre système cela n’aurait pu ne pas fonctionner.

9. Remerciements

Nous souhaitons remercier notre enseignant tutorant Mr Ould Djafar Abdeslam pour son aide sur et ses indications sur la partie théorique ainsi que Mr De Sabbat qui nous a accueilli au sein de l’IUT lab et pour son aide sur la partie réalisation.

10. Sources

https://www.myshop-solaire.com/comment-choisir-son-regulateur–_r_80_a_454.html

http://www.repereelec.fr/cables-dom.htm

https://www.energiedouce.com/content/14-tout-savoir-sur-les-panneaux-solaires

https://www.rte-france.com/fr/eco2mix/eco2mix-mix-energetique

https://www.edfenr.com/autoconsommation/

https://www.legifrance.gouv.fr/eli/loi/2017/2/24/DEVR1623346L/jo/texte

 


Système de régulation de température pour ruche

Dans le cadre de l’unité d’enseignement Études et Réalisations nous avons été amenés à réaliser un projet en équipe :

Nous avons travaillé sur ce projet en une équipe de 4 personnes.

Ce projet a pris une forme semblable à un véritable contrat d’entreprise : notre professeur tuteur nous a fourni un cahier des charges et des contraintes auxquelles nous devions répondre au mieux, tout en respectant les délais et le budget imposés.

Notre projet a pour but de réaliser un système capable d’élever et de contrôler la température à l’intérieur d’une ruche, et ce, dans le but d’éliminer un parasite de l’abeille : le Varroa.Le Varroa ne supporte pas les températures supérieures à 40°C, nous donc élever notre température au-delà de ce seuil. Toutefois, les abeilles, elles, ne supportent pas les températures supérieures à 46°C.
Nous allons donc réguler notre température pour qu’elle ne dépasse pas ce seuil.

Notre projet devra obéir à une fonction primaire (en rouge) et à plusieurs fonctions contraintes (en bleu).

Notre projet prendra la forme d’un toit pour ruche, fonctionnant à l’aide d’un écran LCD pouvant être soit opaque, soit transparent, et, en combinant cet écran a un système de double-vitrage, nous parviendront à réguler la température à l’intérieur de la ruche.Ci-dessus, le schéma général de notre système, détaillant les divers composants de notre système ainsi que leur rôle et les liaisons les reliant.Ci-dessus est le schéma électrique des sondes de température Ci-dessus est le schéma électrique des sondes de température que nous allons utiliser.Nous avons réalisé une carte d’alimentation permettant de relier nos quatre sondes de températures à la carte Arduino. Ci-dessus sont les schémas électriques réalisés sur Kicad, ainsi que le schéma du circuit imprimé correspondant.Ci-dessus vous pouvez voir nos premières tentatives pour connecter nos sondes à la carte Arduino.
Ces modèles étant peu pratiques, peu fiables et peu esthétiques, nous avons choisi d’opter à la place pour une carte d’alimentation sur circuit imprimé de notre réalisation.Les diverses étapes nécessaires à la réalisation d’un circuit imprimé.Ci-dessus une photo de notre écran LCD sur laquelle sont annotés le plan de masse ainsi que la pin d’entrée du courant Vin. Nous avons relié ce plan de masse à la masse de notre carte Arduino, ainsi que l’entrée Vin à l’une des pins de sortie de notre carte Arduino.Pour transporter et garder nos composants électronique à l’abri des conditions climatiques, nous avons opté pour une boîte étanche réalisée à l’imprimante 3D.
Ci-dessus vous pouvez voir une visualisation 3D des deux pièces de notre boitier.Ci-dessus, vous pouvez voir une représentation schématique de notre programme.
Pour chaque temps de cycle, on va relever les températures de chaque sonde, et, si n’importe laquelle de ces sondes renvoie une température supérieure à 43°C, le système passe en mode Surchauffe.Ci-dessus vous pouvez voir une capture d’écran de la console de notre Raspberry Pi, servant d’interface utilisateur et permettant a l’apiculteur d’observer l’évolution de la température dans la ruche et de consulter un historique des températures. Ci-dessus vous pouvez voir notre emploi du temps pour les deux semaines durant lesquelles ont eu lieu notre projet.Après avoir rempli le cahier des charges de notre projet, nous nous sommes attelés a concevoir et réaliser une alimentation portable pour notre système.
Toutefois, nous ne sommes pas parvenus à finir cette alimentation portable.En conclusion, nous sommes plutôt satisfait du travail que nous avons fourni.
En effet, nous avons réussi à mener à bien notre projet, et ce, uniquement avec du matériel de récupération ou d’emprunt.
Nous avons réussi a remplir notre cahier des charges deux jours en avance de la fin du projet.
Et aussi nous avons su mettre à profit nos connaissances et su apprendre de nouvelles compétences pour mener a bien ce qui aura été pour nous un projet très formateur.

 


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.


NAO suit une ligne

Résumé

Ce projet a été mené à bien par Stephane CAMUSSO et .

Le but du projet est de réaliser un suivi de ligne via un robot NAO.

Pour réaliser ce projet nous avons utilisé les éléments suivants :

  • Un robot NAO
  • Le logiciel Choregraphe d’Aldebaran
  • Le langage de programmation python
  • Les librairies pour python pour le traitement d’image

 

Read More


Localisation des NAO

 

 logo-iut

Localisation des Nao

Abstract

Le projet de localisation des robots Nao a été réalisé par Mathieu GARDIN, apprenti en DUT Génie Electrique et Informatique Industrielle auprès de Endress-Hauser Flowtec AG.

Introduction

Les robots Nao sont une avancée innovante dans la robotique. Grâce à sa panoplie de capteurs et d’articulations mécaniques, il se rapproche des fonctionnalités de l’être humain. On y retrouve entre autre un moyen vocal de répondre à des injonctions, des capteurs pour pouvoir entendre la voix, une fonction « visuelle » pour observer son environnement à l’aide de caméras ainsi que des capteurs permettant aux Naos de marcher. La majorité des fonctionnalités du Nao le destinent à une interaction avec son environnement extérieur. Cependant, à l’heure actuelle, aucun système n’existe pour pouvoir créer une fonction de géo-localisation dans cet environnement. A travers cette présentation, nous allons chercher à développer cette fonctionnalité et ainsi élargir les possibilités du Nao.

Présentation du Sujet

Pouvoir localiser un Nao lors de ces déplacements dans une pièce, tels a été le projet qui nous a été confié par Mr CUDEL. L’intérêt de ce projet résidait de pouvoir localiser à l’aide d’une interface graphique doublé par un serveur de base de données. L’objectif est que le Robot Nao puisse écrire dans la base de donnée et que l’interface graphique située dans un navigateur internet puisse effectuer une demande auprès de la base de donnée et se mettre à jour automatiquement.

Pour la réalisation du projet, on utilisera un raspberry pi 2 model b qui hébergera la base de donnée et sera connecté à l’aide d’une clée 3G sur le routeur pour communiquer avec le robot Nao

Organisation du Projet

La réalisation de ce projet a suivis un ordre précis:

Phase de concept :

  • Évaluation de la problématique actuelle et des solutions à mettre en place
  • Réflexion sur les langages de programmation à utiliser
  • Découverte et Apprentissage de l’utilisation des outils numériques (Raspberry pi 2 model b)

Analyse des fonctionnalités:

  • Création d’une base de donnée
  • Création d’une interface graphique
  • Création d’un moyen de communication entre Raspberry et Nao
  • Mise à jour automatique de l’interface graphique
  • Intégration des données spatio-temporel du Robot

Création de la partie design :

  • Réalisation d’un plan de la pièce
  • Intégration des balises sur l’environnement graphique

Intégration des fonctionnalités :

  • Mise en place de la base de donnée
  • Intégration de l’interface graphique au navigateur Web
  • Utilisation de la communication entre Robot et Raspberry

Phase de test:

  • Test des fonctionnalités
  • Correction des erreurs

Cahier des Charges

Base de donnée
La question de la base de donnée a surtout été conditionné par un choix technologique. MySQL ou SQlite. Dans un premier temps, il était prévu de partir sur une base de donnée en MySQL mais après quelques recherches, il a été montré que l’utilisation de SQlite économiserait les ressources du Raspberry  logo-mysql-170x115Sqlite
 Interface / Gestion base de donnée
Pour pouvoir créer les bases de données et les organiser, le choix s’est porté sur l’interface Phpmyadmin. Un outil conçu en PHP permettant l’administration des bases de données. Travaillant sur un système Linux, il était plus facile d’utiliser cet outil que de passer par l’invite de commande.  logo-og
 Interface graphique
Pour la création du plan d’une salle de Tp, on a utilisé un logiciel d’architecture appelé Kozikaza, permettant de re-constituer la salle de travaux pratiques avec ces obstacles et ces dimensions  kozi-kaza-mmi-deco
 Langages de programmations

Concernant les langages de programmation, plusieurs solutions ont été proposés. On pouvait utiliser un langage python presque exclusivement ou se porter sur des langages de programmation de type Web => PHP, HTML, AJAX, et JAVASCRIPT.

L’objectif de ce projet étant de travailler sur une interface graphique Web, il a été décidé d’utiliser PHP, HTML, AJAX, et JAVASCRIPT

 shutterstock_184983572-1000x480

Communication

La communication entre le robot Nao et le Raspberry se fera à l’aide d’un protocole de type UDP. Le robot enverra sa position dans une chaîne de caractère qui sera ensuite traduit par une table de transcodage au niveau du raspberry

Développement

PHPmyadmin

L’utilisation de PHPmyadmin se fait en local sur le raspberry : 127.0.0.1

phpmyadmin

Sur les besoins de ce projet, il a été demandé 3 types de données:

  • La première se base sur quel robot Nao envoie les données
  • La deuxième concerne le jour et l’heure à laquelle les informations ont été envoyés
  • La troisième nous renseignera sur la position du robot, si il se trouve à la balise 1, 2, 3 ou 4. Ces « balises » seront placés à différents endroits dans la pièce

Dans notre cas, on pouvait créer les tables de données manuellement, une pour chaque information ou programmer en SQL la création automatique de ces tables (visible ci-dessous en rouge). Pour les besoins du test, il a été décidé de créer une auto-incrémentation des données comme détaillés dans le document ci-dessous en bleu.

— phpMyAdmin SQL Dump
— version 4.4.14
— http://www.phpmyadmin.net

— Client : 127.0.0.1
— Généré le : Ven 22 Avril 2016 à 08:51
— Version du serveur : 5.6.26
— Version de PHP : 5.5.28SET SQL_MODE = « NO_AUTO_VALUE_ON_ZERO »;
SET time_zone = « +00:00 »;
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;–
— Base de données : `projet`
—- ———————————————————-
— Structure de la table `event`
CREATE TABLE IF NOT EXISTS `event` (
`ID` int(11) NOT NULL,
`robot` int(11) NOT NULL,
`position` int(11) NOT NULL,
`date` datetime NOT NULL
) ENGINE=InnoDB AUTO_INCREMENT=82 DEFAULT CHARSET=latin1;–
— Index pour les tables exportées
—-
— Index pour la table `event`

ALTER TABLE `event`
ADD PRIMARY KEY (`ID`);–
AUTO_INCREMENT pour les tables exportées
—-
AUTO_INCREMENT pour la table `event`

ALTER TABLE `event`
MODIFY `ID` int(11) NOT NULL AUTO_INCREMENT,AUTO_INCREMENT=82;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;
  • La table Robot identifie quel Nao a envoyé l’information
  • La position correspond à quelle balise a été repéré le robot
  • La date elle nous indique donc la position temporelle du robot

 

Plan de la salle de travaux pratiques

Le design de l’interface graphique réalisé à l’aide du logiciel d’architecture prend en compte une partie du mobilier de la salle ainsi que ces dimensions.

plan

Dans le cadre du projet, il a été intégré de manière très simple 4 balises numérotés de 1 à 4 avec des couleurs différentes représentant les positions du robot Nao comme montré dans l’image ci-dessous :

WP_20160606_001

 Programmation PHP / HTML

La programmation de l’interface graphique et de sa communication avec le raspberry s’est effectué avec code en PHP. Le principe est d’initier la communication en lui donnant les « username » et « password » de PHPmyadmin pour aller lire ce qui est écrit dans la base de donnée

 

<?php
$servername = « localhost »;
$username = « root »;
$password = « dptgeii »;
$database = « projet »;

// Create connection
$mysqli = new mysqli($servername, $username, $password, $database);

// Check connection
if ($mysqli->connect_error) {
die(« Connection failed:  » . $mysqli->connect_error);
}
else{
//QUERY

 

Une fois que la connexion est effectué, on utilise un code en Jquery pour rentrer dans notre table « event ».

else{
//QUERY
if (isset($_POST[‘reset’])) {
$query = ‘TRUNCATE TABLE event’;
$mysqli->query($query);
}
$query = ‘SELECT * FROM event LIMIT 10’;//QUERY
$result = $mysqli->query($query);
$num = mysqli_num_rows($result);$array = array();
//TEST
if ($result->num_rows > 0) {
while($row = $result->fetch_assoc()) {
array_push($array, $row);
}
}
//print_r($array);
}

Le reste de la programmation s’effectue en HTML pour pouvoir donner « vie » à l’interface graphique et implémenter les données sur la plate-forme Web

planF

Perspectives / Difficultés rencontrées

Une des premières difficultés a été l’installation et la mise à jour des logiciels sur le raspberry. L’intégration de PHPmyAdmin et du langage SQL à l’aide de la console linux intégrée a montré des réticences et a entraîné une perte de temps importante. La communication UDP qui devait s’ajouter comme partie finale du projet n’a finalement pas pu être réalisée par un manque de temps et une adaptation du code difficile à mettre en œuvre à notre niveau.

Les perspectives si la communication UDP était correctement installée et que le traitement des informations en provenance du Robot Nao se réalisait sans conflit, permettrait une étude de la localisation du robot sur une plus grande échelle. On pourrait travailler sur le bâtiment B en entier et pas juste au niveau de la salle de travaux pratiques.

Par la suite, l’intérêt du projet deviendrait plus prononcé si le raspberry émettrait des ordres de déplacements aux robots Nao. La localisation avec les capteurs du robot permettrait de créer un système d’acquisition quand le Nao arrive à destination.

Enfin en dernier lieu, transformer cette plate-forme Web pour l’intégrer dans une application Android permettant une utilisation mobile du projet.

Bilan

Par ce projet, j’ai eu la plaisir de pouvoir travailler sur des langages de programmation qui m’était jusqu’à lors inconnu. J’ai pu acquérir des compétences de programmation en base de données (SQL), langages Web (Ajax, Jquery, HTML, PHP, Javascript et CSS). Ce défi de travailler dans d’autres langages de programmation était une source de difficultés en plus mais m’a permis de créer un défi personnel pour la réalisation de ce projet.

Il est vrai qu’à l’heure actuelle, la localisation du robot Nao s’arrête à une simulation avec la plate-forme Web et il est toujours décevant d’un point de vue personnel de ne pouvoir mener à 100% la réalisation d’un projet. Mais les bases ont été crées et fonctionnent sans erreur. Pouvoir améliorer ces bases et en faire la naissance de nouveaux projets pour de futurs réalisations justifie le besoin d’un tels projet et surtout son importance dans l’enseignement du GEII.

A ce titre,  je tiens à remercier Mr Cudel d’avoir autorisé la réalisation de ce projet même en étant seul dessus. Cela m’a permis de réaliser ce projet personnel de travailler avec des outils Web et pouvoir appréhender le croisement entre Robotique et environnement Web.


Suiveur Ligne / Gestion de Stock

Abstract

Ce projet a été réalisé par Alexandre COLICCHIO et Loïc MONJOUSTE, élèves en DUT GEII par apprentissage (resp. Electro Ohms et PSA Peugeot-Citroën).

Introduction

La chaîne de production miniature Festo étudiée en Travaux Pratiques (TP) d’automatisme et de supervision permet de différencier, à chaque étape, les « bonnes » pièces (qui correspondent au gabarit prévu) des « mauvaises ». Cependant, aucun système automatisé n’est prévu pour retirer les « mauvaises » pièces de la chaîne. C’est pourquoi, il est nécessaire de créer un tel système.

Présentation du Sujet

Alors qu’un bras robotisé (actuellement fictif et non étudié dans le projet) retire les pièces imparfaites de la station Festo du palpeur (cf. Fig.1) pour les poser dans un stock, un second robot (suiveur de ligne) aura pour tâche de récupérer, une à une, chaque pièce afin de les entreposer dans un nouveau stock en début de ligne. Un autre bras robotisé (non étudié) pourra récupérer la pièce et la réintroduire en début de chaîne sur la station de distribution (cf. Fig.2).

Palpeur
Fig.1 : Station de perçage

Distributeur
Fig.2 : Station de distribution

Cahier des Charges

Les fonctions du stock de pièces :

Gérer le stock : Image :
Cette carte ne gère que la partie liée au stock en milieu de chaîne. C’est elle qui fait le lien entre le détecteur de présence pièce et l’émetteur FM. Funduino Uno
Choix :
Arduino est une marque fiable pour les circuits électroniques programmables. Les produits proposés sont à des prix abordables pour de petits projets. De plus, les constructeurs revendiquent la liberté de droits de leurs produits. Il n’est donc pas difficile de trouver de l’aide pour la programmation. Pour cette fonction (gérer le stock), les besoins en nombre d’entrées et de sorties étant faible (1 entrée et 1 sortie numériques), le petit modèle (14 E/S numériques) est suffisant pour apporter la gestion nécessaire.
Détecter les pièces à déplacer : Image :
Le stock est équipé d’un capteur fin de course normalement ouvert afin de détecter la présence de pièce(s) en attente. Au moment où une pièce appuie sur le capteur, celui-ci se ferme et laisse alors passer la tension d’alimentation de cinq volts jusqu’à la carte de gestion du stock. Findecourse
Choix :
Les capteurs à fin de course sont les plus basiques capteurs de présence d’obstacle. Ainsi, les prix sont extrêmement faibles alors que leur fiabilité est prouvée. En outre, il est possible de choisir le mode de fonctionnement (Normalement Ouvert ou Normalement Fermé).
Communiquer avec le robot : Image :
Le stock en milieu de ligne possède une station FM (Modulation de Fréquence) émettrice. A partir de l’information de la fonction de détection de pièce à déplacer, le transmetteur envoie un signal binaire modulé en 2FSK (2 Frequencies Shift Keying) à la station FM réceptrice se trouvant sur le robot. Lorsque le robot reçoit un « 1 » logique, la carte de gestion du robot interprète cette information et débute le mouvement en direction du stock en milieu de ligne. Emetteur FM
Choix :
Le robot doit recevoir une information à propos de l’état du stock. La première solution serait de relier le robot au stock à l’aide d’un câble. Cependant, bien que ce soit le moyen le moins onéreux, la connexion filaire implique énormément d’encombrement pour le robot : enroulement, écrasement du câble, etc. Il faut donc trouver une technologie sans fil et à des prix convenables. La modulation de fréquence est un bon choix puisque la transmission est protégée du bruit environnant sur la faible distance à parcourir. Par ailleurs, le signal à transmettre étant numérique, les changements d’état peuvent être extrêmement rapide, ce que la modulation de fréquence peut gérer.

 

Les fonctions du robot :

Gérer les entrées et sorties du robot : Images :
C’est le cerveau du robot. En effet, la carte Arduino contient la gestion complète des actions que doit entreprendre le robot en fonction des différents paramètres qu’il reçoit grâce aux capteurs. L’avantage de Arduino est que le logiciel est Open Source et facile d’utilisation. Ainsi, des millions de personnes partagent leurs programmes et idées afin d’aider les utilisateurs à traiter des fonctions. De plus, la carte est adaptative à divers systèmes. Dans notre cas, l’alimentation et le contrôle des moteurs de roues se font à partir d’un module moteur connecté à la carte. Arduino MEGA 2560
Motor Shield
Choix :
De même que la carte de gestion de stock, la carte choisie est de marque Arduino. On lui ajoute un module moteur (Motor Shield) afin de pouvoir y connecter et gérer les moteurs. Cette fois-ci, nous disposons d’un plus large panel d’entrées et sorties puisqu’il y a plus de périphériques à contrôler.
Communiquer avec le stock : Image :
Le robot doit recevoir l’information en provenance du stock pour démarrer son cycle de fonctionnement. Il est alors nécessaire de se doter d’un récepteur FM. Recepteur FM
Choix :
Il est nécessaire de choisir un récepteur en FM configuré à la même fréquence que l’émetteur. Ensuite, selon le codage de l’information par le transmetteur, le récepteur doit pouvoir comprendre et décoder cette information.
Se déplacer : Images :
Un système à trois points de contact au sol a été choisi avec l’utilisation de deux roues motrices et d’une bille libre. Cette dernière permet au robot de rester en équilibre. Les rotations sont effectuées à l’aide des roues motrices : une roue est à l’arrêt pendant que la seconde continue son mouvement. Les roues sont entraînées par des moteurs asynchrones. Roues motrices
Bille
Choix :
Les moteurs ont été récupérés sur un ancien robot, ce qui rend parfait le côté financier du déplacement du robot. De plus, la puissance est correcte par rapport au poids du robot (non négligeable).
Détecter la ligne : Image :
Les deux phototransistors à l’avant du robot permettent de détecter la ligne noire que le robot doit suivre. Selon le contraste de la surface observée, les phototransistors envoient une information numérique à la carte de gestion. Phototransistor
Choix :
Différentes technologies permettent de détecter une ligne (capteur de couleur, capteur à ultrason, etc.). La ligne étant sombre et la surface autour claire, un capteur de contraste permet de différencier la ligne du sol à moindre prix. L’inconvénient est que le capteur est très sensible à la luminosité extérieure. Il faut donc isoler les capteurs de l’environnement parasite.
Détecter le stock : Image :
Le robot ne doit en aucun cas entrer en collision avec la structure du stock. C’est pourquoi, il est nécessaire de mesurer la distance séparant le robot du stock jusqu’à ce qu’il se trouve à la place prévue. Capteur ultrason
Choix :
Il existe plusieurs technologies pour mesurer des distances, mais son (émetteur à ultrasons) cône de détection est plus grand, ce qui est utile lorsque les capteurs ne sont pas directement en face de l’obstacle à mesurer. De plus, son prix est convenable et sa détection par rapport à une surface connue reste fiable selon l’inclinaison. Enfin, la distance maximale est d’environ 2,5 mètres. Cette distance est très largement suffisante puisqu’on ne travaille que sur 5 centimètres maximum.
Récupérer la pièce : Images :
Une pince placée à l’avant du robot permet de prendre la pièce et la garder entre ses deux « doigts » le temps du trajet jusqu’au stock en début de ligne. Un capteur de fin de course est présent au fond de la cavité de la pince afin de s’assurer de la présence de la pièce attrapée. Pince
Servomoteur
Choix :
La pince a été créée par impression 3D à partir d’un modèle sous SolidWorks. Son coût de fabrication est dérisoire et les modifications à y apporter peuvent être faites facilement. En outre, la résistance du matériau rigide reste suffisante pour maintenir une pièce. Le servomoteur est directement adapté à la commande par carte Arduino et fonctionne en pas à pas. Le degré de liberté est de 180°, ce qui est suffisant pour commander la pince à l’ouverture complète et à la fermeture.

Etude des fonctions

Détecter les pièces à déplacer :

Le stock est un tube vertical ouvert à sa base (cf. Fig. 3). Ainsi, les pièces déposées, par la force d’attraction gravitationnelle, se placent directement à la sortie du stock. Le capteur fin de course, déclenché par l’appui de la pièce, est placé à la sortie. Câblé en normalement fermé, le capteur n’envoie aucune tension tant qu’il n’est pas activé. A l’activation, le capteur est ouvert : la tension d’alimentation est directement reliée à l’entrée de la carte de gestion du stock à une résistance de tirage près (cf. Fig. 4).

schema stock
Fig.3 : Stock en milieu de chaîne

Cablage FdC
Fig. 4 : Schéma de câblage du Fin de Course

Communiquer avec le robot :

L’information de présence de pièce reçue, la carte de gestion ne retient que le front montant de ce signal pour mettre à jour le signal numérique de sortie. La carte de gestion du stock envoie la lettre « a » (16#97) au robot afin de palier à tout problème de perturbations parasites. Ainsi, le code hexadécimal de « a » aura moins de chance d’apparaître par du bruit qu’un simple état logique haut. Le transmetteur module en fréquence (434MHz) les états logiques. Ainsi, un état bas aura une fréquence de modulation f0 alors que l’état haut sera modulé à une fréquence f1 (cf. Fig.6). L’antenne a été dimensionnée de façon à ne pas avoir de retour d’onde qui pourrait dégrader l’émetteur. Le calcul de la longueur de l’antenne se porte sur un cas de moitié d’onde (cf. Fig.7).

Calcul f0 f1
Fig. 6 : Calcul des fréquences du signal modulé

Calcul antenne
Fig. 7 : Taille de l’antenne

Communiquer avec le stock :

A ce moment, le récepteur FM placé sur le robot reconnaît la fréquence d’émission de 434MHz et la décode. On mesure, sur la patte de sortie numérique, les états haut et bas qui ont été émis (cf. Fig.8). Nous apercevons, cependant un problème d’impulsions indésirables en début de réception (cf. Fig.9). Ce problème peut facilement se résoudre à l’aide d’un filtre analogique passe-bas composé d’une résistance et d’un condensateur (cf. Fig.10). Les signaux reçus pendant le fonctionnement réel du robot sont sur une grande période (environ 1 seconde), donc les hautes fréquences peuvent être atténuées sans porter atteinte aux fonctionnalités utilisées. On remarque qu’en moyenne, la période d’une impulsion intempestive est d’environ 12,5ms. On en déduit une fréquence de 80Hz. On peut alors trouver les valeurs de R et C afin de lisser ces impulsions (cf. Fig. 11).

TX RX oscillo
Fig. 8 : Signal émis et signal reçu

Probleme reception
Fig. 9 : Aperçu d’oscillations en début de réception
Filtre Passe-Bas
Fig.10 : Filtre passe-bas

Calcul RC
Fig.11 : Calcul des éléments du filtre

Se déplacer :

Les moteurs sont alimentés par une batterie externe de 15 volts et connectés sur le module moteur de la carte de gestion du robot. La carte envoie l’information aux moteurs du sens de rotation et de la vitesse souhaitée selon la situation du robot. En effet, la carte Arduino (via le Motor Shield) envoie une valeur analogique (PWM) qui gère l’intensité reçue par les moteurs.

Détecter la ligne :

Les capteurs de contraste sont composés d’une LED (lumière invisible à l’oeil nu) et d’un phototransistor. Selon la réflexion de la lumière provenant de leur LED, la valeur numérique en sortie des capteurs est plus ou moins élevée. Sur une surface claire, les phototransistors renvoient une valeur faible (entre 0 et 100) alors que la valeur augmente lorsque le contraste est plus sombre (aux alentours des 800). Connectés à la carte de gestion, le robot « sait » s’il tente de franchir la ligne ou s’il est sur la bonne voie. Les capteurs sont très proches de la surface à observer puisque leur portée est de 3mm. En outre, deux LEDs blanches ont été ajoutées (cf. Fig.12) afin d’éclairer la surface et réduire les erreurs de contraste dues à l’ombre provoquée par la faible distance des capteurs par rapport au sol. Le bâti du robot joue un grand rôle dans cette ombre puisque le but est d’isoler au maximum le système des capteurs de la lumière ambiante (cf. Fig.13).

Led Blanche
Fig.12 : Exemple de LED blanche

Systeme isole
Fig.13 : Isolation et éclairage interne

Détecter le stock :

Arrivé près du stock, le robot n’est pas forcément aligné pour récupérer la pièce selon la trajectoire qu’il a utilisé pour l’atteindre. Il faut donc mesurer la distance entre le robot et le stock en deux points (la gauche et la droite du bâti du robot). Plus les capteurs sont éloignés et plus précis sera le parallélisme entre le stock et le robot. Chacun de ces capteurs sont composés d’un émetteur et d’un récepteur. L’émetteur envoie une onde d’environ 40 kHz qui, réfléchie sur la surface à mesurer, est captée par le récepteur. Le temps du trajet de l’onde définit la distance (cf. Fig.14).

Calcul distance
Fig.14 : Calcul de distance

Récupérer la pièce :

Correctement aligné devant le stock, le robot attrape la pièce à l’aide de la pince. En effet, le servomoteur relié à l’un des doigts entraîne le second doigt à l’aide d’un engrenage situé à la base des doigts de la pince. Celle-ci est composée de caoutchouc sur les bords des doigts afin d’augmenter l’adhérence de la pince et ainsi maintenir la pièce en place. Ensuite, un capteur fin de course est également positionné sur le fond de la pince dans le but de connaître la présence de la pièce au sein de la pince.

Ce que le robot devrait faire

Initialement, les stocks en milieu et début de ligne sont vides. Le robot est installé sur sa position de départ (le stock de départ se trouvant sur sa droite), perpendiculairement à la ligne à suivre (cf. Fig.15). Au moment de la détection de la présence d’une pièce dans le stock en milieu de chaîne, le robot reçoit l’information et débute un déplacement en avant. Les capteurs de contraste passent alors sur la ligne noire (les deux à la fois, comme sur la Fig.16). Le robot entame alors une rotation sur la droite jusqu’à ce qu’un des capteurs ne détecte plus la ligne. C’est alors que la phase de suivi de ligne débute (cf. Fig.17).

Schema etape 1
Fig.15 : Position de départ

Schema etape 2
Fig.16 : Détection de la ligne

Schema etape 3
Fig.17 : Rotation

A chaque fois que le robot tente de franchir la ligne par inadvertance, il se repositionne correctement, de sorte qu’il se recentre sur la ligne (cf. Fig.18). Une bande noire, mise en perpendiculaire de la ligne à suivre est le signal d’approche du stock où sont entreposées les pièces à déplacer. En effet, le programme de suivi de ligne s’arrête une fois la bande détectée par les deux phototransistors à la fois. Le robot s’arrête dans sa position (cf. Fig.19).

Schema etape 4
Fig.18 : Suivi de ligne

Schema etape 5
Fig.19 : Détection de la bande

A l’aide de ses capteurs à ultrason, le robot mesure la distance qu’il a de chacun de ses côtés par rapport au stock. Si l’une des valeurs de distance est différente de l’autre, le robot pivote de sorte que les valeurs des deux capteurs s’égalisent (cf. Fig.22). Il entame ensuite un léger mouvement en avant jusqu’à atteindre une valeur nulle sur ses capteurs de distance. Pendant ce même temps, la pince s’ouvre à son maximum afin d’avoir la pièce entre ses doigts une fois arrivé contre le stock (cf. Fig.21). Lorsque le robot est contre le stock, la pièce est complètement à l’intérieur de la pince, le fin de course placé au fond de la pince est déclenché. Ainsi, le robot referme les doigts afin de maintenir la pièce (cf. Fig.22).

Schema etape 6
Fig.20 : Alignement

Schema etape 7
Fig.21 : Avance du robot et ouverture de la pince

Schema etape 8
Fig.22 : Fermeture de la pince

Il entame ensuite un déplacement arrière jusqu’à ce qu’il ne détecte plus la bande noire posée sur la ligne à suivre (cf. Fig.23). A ce stade, le robot entame une rotation sur 180 degrés afin de se repositionner sur la ligne a suivre et le programme de suivi de ligne débute (cf. Fig.26). Le robot répète les mêmes mouvements que précédemment, jusqu’à arriver au stock de dépose de la pièce (cf. Fig.25).

Schema etape 9
Fig.23 : Marche arrière

Schema etape 10
Fig.24 : Demi-tour

Schema etape 11
Fig.25 : Répétition des étapes précédentes

Arrivé, il ouvre la pince, la pièce tombe et atterrit directement dans un petit logement prévu à cet effet. Comme pour le stock précédent, le robot recule, ne détecte plus la bande noire et entame un demi-tour sur lui-même. C’est la fin du cycle pour le robot : il doit recevoir une nouvelle information de présence pièce avant de chercher la suivante (cf. Fig.26).

Schema etape 12
Fig.26 : Position d’attente finale

Ce que le robot fait réellement

En position de départ, le robot est en attente de l’information d’une présence pièce. On appuie alors sur le capteur fin de course pour envoyer la trame correspondante au robot. Ce dernier comprend l’information et s’avance jusqu’à la ligne. Il entame alors une rotation de 90 degrés vers la droite sur lui-même puis suit la ligne jusqu’à la bande noire devant le stock. Il est ensuite capable de faire marche arrière jusqu’à ne plus capter la bande et à faire un demi-tour pour se diriger vers le stock en début de chaîne. De même, une fois arrivé, il entame une marche arrière et un demi-tour, pour enfin s’arrêter et attendre une seconde information de présence pièce afin d’entamer un second cycle.

Conclusion

Bien que nous ne soyons pas arrivé au terme des objectifs fixés, nous en avons appris énormément aussi bien sur le plan organisationnel que sur le plan technique. En effet, le projet nous a apporté une grande expérience sur le métier de concepteur de nouveaux systèmes. Nous ne souhaitions pas simplement appliquer les diverses connaissances acquises pendant les deux années en GEII, mais en obtenir de nouvelles. Cet objectif est rempli puisque nous savons désormais programmer une carte Arduino et utiliser les capteurs mis en place. En effet, de nos erreurs nous avons su tirer les leçons dans le but de les comprendre et de ne plus les commettre.

Perspectives

Ce projet, une fois achevé, pourrait par la suite être dupliqué et utilisé sur les différentes stations Festo afin de rapporter les pièces en début de chaîne. Ainsi, la chaîne serait entièrement autonome et pourrait fonctionner sans arrêt (sauf en cas de défauts). Par ailleurs, le coût de production de ce système est dérisoire, ce qui le rend particulièrement abordable quelle que soit l’organisme souhaitant se le procurer.


Bras Robotisé Cartésien

Abstract :

Nous sommes deux étudiants en 2e année de DUT génie électrique et BrasBleuinformatique industrielle à Mulhouse, Alexis ROSENKRANZ et Anthony WELTER.  Au début de la deuxième année, nous avions à choisir un projet à réaliser durant celle-ci. Après quelque temps de réflexion, nous avons choisi de réaliser un bras robotisé, projet que notre professeur accepta.

L’idée de réaliser un bras robotisé est pour nous un rêve d’enfant qui se concrétise…

Robot_enfant

 

Présentation du Sujet :

Piloter directement les moteurs n’a pas été notre premier but dans ce projet. Nous avions surtout l’envie de pouvoir piloter ce bras robotisé à l’aide de coordonnées cartésiennes, c’est à dire selon des axes que l’on nommera X, Y et Z.

Des calculs seront donc nécessaires dans le programme afin d’affecter les angles des moteurs de chaque axe à leur position pour que l’outil du robot soit à la position demandée dans le repère cartésien.

Coord_Cart

Imaginez que l’on veuille tracer une ligne, il sera donc nécessaire de calculer une multitude de points très proches puis d’affecter les moteurs à l’angle calculé pour chacun des points.

Il faut donc bien comprendre que pour réaliser un mouvement linéaire avec un bras robotisé, tous les axes devront bouger en même temps.

 

 

Bras_rotation

Si on veut rajouter une pince au bout d’un bras robotisé 3 axes, la pince restera fixe et l’on ne pourra pas choisir l’angle qu’elle aura par rapport au sol. C’est pour ces raisons que nous avons décidé de rajouter deux autres axes. L’un, pour que la pince soit toujours perpendiculaire par rapport au sol quelque soit l’inclinaison du bras.  L’autre axe, pour que la pince puisse réaliser une rotation sur elle-même, c’est-à-dire pour qu’on puisse attraper un objet face à elle-même et à 90 degrés.

Maintenant vous comprenez pourquoi notre bras robotisé est composé de 5 axes alors que l’on précise que uniquement 4 axes sont réellement pilotables.

 

Problématique :

La problématique qui se pose est donc :

ComProblématiquement pouvoir gérer en données cartésiennes un bras robotisé 4 axes ?

 

Cahier des Charges :

– Réaliser un bras robotisé 5 axes dont 4 réellement pilotablesCahier des charges

– Celui-ci devra pouvoir être pilotable dans un repère cartésien avec des déplacements linéaires

– La partie commande sera réalisée sur une carte type Arduino

– Le robot devrait pouvoir évoluer dans une demie sphère de 300 mm de rayon et prendre en compte les zones interdites

– La précision au bout du bras devrait être au moins de 4 mm

– Les coordonnées de position du robot devront pouvoir être entrées à l’aide d’un clavier

– Le robot devrait également être pilotable à l’aide d’une télécommande comportant 2 joysticks selon deux modes : angulaire ou linéaire.

– La position réelle du robot ainsi que les coordonnées tapées au clavier seront affichées sur un écran LCD.

– Les déplacements devront se faire en suivant une courbe d’accélération et de décélération.

– Le robot devra pouvoir se déplacer avec une charge d’au moins 200g dans sa pince.

– Le robot devrait comporter un bouton d’arrêt d’urgence de type coup de point.

 

Étude :

Nous avons commencé par vérifier si notre projet était réalisable à notre échelle. Pour ceci, nous devions réaliser plusieurs études notamment la manière à affecter la valeur à tous les angles en fonction des coordonnées cartésiennes. Nous avons principalement utilisé le théorème de Pythagore et le rapport entre le cosinus, les angles et l’hypotéCalculnuse afin de réaliser la conversion entre la position et les angles.

Exemple : pour calculer l’angle A (celui de la rotation de la tourelle), on utilise les coordonnées X et Y afin de calculer l’hypoténuse. Dans ce cas, l’hypoténuse correspond à la distance entre le bout de la pince et la base du robot. A partir de cet hypoténuse, on réalise le calcul suivant : cos-1 (X/hypoténuse). On obtient l’angle A.

C’est le même principe pour trouver les angles B (épaule du robot) et C (coude du robot). Il suffit de calculer la deuxième hypoténuse qui prend cette fois ci l’axe Z en compte.  Avec cette hypoténuse 2 et les valeurs XYZ on peut retrouver les angles B et C. À l’aide des angles B et C, on peut retrouver l’ angle D afin que la pince soit toujours perpendiculaire au sol. L’angle E est la rotation de la pince sur elle-même et est égal à l’angle A, afin que la pince soit toujours face à nous quelque soit la rotation bras.

 

Une fois que nous savions comment trouver chaque angle en fonction des coordonnées cartésiennes, il fallait que l’on choisisse correctement tous les matériaux et le matériel que nous allions utiliser afin de réaliser le bras.

Pour la partie commande, nous voulions utiliser un microcontrôleur de la marque Arduino pour plusieurs raisons. La première étant le budget. Un Arduino en moyenne coûte 30 €. De plus, il possède une puissance de calcul suffisante ainsi qu’un grand nombre d’entrées/sorties. Nous avons choisi l’Arduino mega car :

– Il possède 54 entrées-sortiesArduinomega

– 16 entrées analogiques

– Un processeur 8 bits

– Une fréquence d’horloge de 16 MHz

– Alimenter en 12 volts, elle génère un 5 V et un 3 volts à l’aide de son régulateur interne

DriverPour la partie puissance, nous avons choisi d’utiliser des drivers de moteur pas à pas. On envoie dans ces drivers un signal carré ainsi qu’une entrée booléenne pour le sens. C’est-à-dire qu’à chaque fois que l’on envoie un front montant sur l’entrée du driver, il réalise un pas sur le moteur pas à pas dans le sens choisi par l’entrée booléenne.

 

Pour la partie commande, nous avons choisi d’utiliser un clavier, une Claviermatrice 4×4 pour rentrer les valeurs cartésiennes et de petits joysticks afin de piloter manuellement les coordonnées cartésiennes.

 

 

LCD

Afin de visualiser les coordonnées, nous avons choisi d’utiliser un écran LCD à 2 x 16 caractères qui nous permet d’afficher les valeurs XYZ en temps réel ainsi que les valeurs tapées au clavier lorsqu’on l’utilise.

moteurpap

 

Pour les actionneurs, nous avons choisi d’utiliser des moteurs pas à pas réductés. Avec des moteurs pas à pas réductés, on peut gérer facilement la vitesse ainsi qu’une position. On connaît la valeur de l’angle d’un pas. Le réducteur est nécessaire afin d’avoir assez de couple pour faire bouger chaque axe du robot.  Nos moteurs ont un couple de 30 kg/cm c’est-à-dire qu’au bout de 40 cm le moteur peut soulever 750 g. L’idéal aurait été des servomoteurs avec retour de la position mais ceux-ci n’étaient malheureusement pas dans notre budget.

20160128_065512Possédant personnellement une imprimante 3D, on choisira d’imprimer la plus grande partie des pièces nécessaires.

 

 

 

 

 

Tout d’abord, l’ensemble du robot à été modélisé en 3D sur SolidWORKS afin de vérifier le design et le fait que rien n’entre en collision.

Plan_3D_BrastenduPlan_3D_Pince

Plan_TransparentG

 

 

 

Plan_3D_Bras

 

Les pièces à imprimer ont été converties en format STL depuis cette modalisation.

 

 

 

Pour les pièces que nous avons fait usiner, on a réalisé une mise en plan de ces pièces toujours sous SolidWORKS.

Plan_2D                                                                                        Plan_2D2

Schéma de câblage simplifié :

 

 Schema cablage robot

Réalisation :

Dans les premières heures que nous avons consacrées au projet, nous avons réalisé plusieurs parties de programme, notamment le programme appelé calcul afin de réaliser des tests qui nous ont permis de vérifier la faisabilité du projet. Il faut savoir que tout le projet se base sur la conversion entre les données cartésiennes qui sont en mm et les angles de chaque moteur qui sont en radian. Par conséquent, sans ce programme calcul le robot ne fonctionnerait pas.

Image2

Bien sûr, le programme calcul n’est pas le seul programme que l’on utilise pour le fonctionnement du robot. Nous avons par la suite programmé plusieurs autres parties que nous avons bien sûr testé, comme le programme rampe qui permet quand nous sommes en mode clavier d’accélérer progressivement la vitesse du robot sur la moitié de la distance à parcourir et de le décélérer sur la deuxième moitié. Cela permet au bras d’atteindre une vitesse maximale lorsqu’il réalise de grandes distances et de rester à une vitesse faible pour des courtes distances. Nous avons continué à créer et tester des bouts de programmes notamment pour décoder la matrice 4 x 4 qui nous sert de clavier, ainsi que le programme clavier en lui-même avec un protocole : Ecrire la coordonnée puis ensuite appuyer sur moins. Exemple pour avoir la coordonnées – 200 il faut taper 2 puis 0 plus 0 puis – et valider. Et beaucoup d’autres programmes dans ce type.

Nous avons passé beaucoup d’heures à réfléchir pour les mouvements du robot ainsi que les programmes afin de trouver toutes les erreurs potentielles avant qu’elles se produisent. Une fois tous les programmes écrits, nous avons assemblé dans un programme principal le Main.

 

Pour la mécanique, nous avons réalisé tous les plans de chaque pièce sur Solidworks : chaque pièce à été réfléchi pour :

– Limiter les efforts2016-06-11 17.28.01

– L’ergonomie du bras

– La précision pour qu’elles correspondent aux angles calculés

 

On peut voir ici l’axe creux permettant le passage des fils :

 

2016-06-11 17.27.47Notre imprimante est une petite imprimante d’entrée de gamme, gérée par un Arduino. Elle fonctionne à l’aide de moteurs pas à pas et courroies. Elle procède un volume d’impression de 200*200*200 ce qui fait que certaines grandes pièces ont du être imprimées en deux fois.

 

Il faut compter une vingtaine d’heures pour imprimer un bras comme celui-ci.20160521_00352520160521_003501

 

 

 

Au fur et à mesure des tests avec un moteur puis deux, puis un moteur avec un bout de bras puis avec un switch de fin de course, le câblage devenait compliqué. Nous avons donc décidé de tout décâbler et de faire un câblage définitif sur une planche pour que ça soit clair et qu’il n’y ait pas de faux contact. L’idéal aurait ici été de réaliser un circuit imprimé supportant les drivers, et comprenant des résistances de tirages afin de limiter les problèmes des parasites.

20160612_15332020160612_163705

2016-06-11 17.31.18

Lors de la réalisation et des tests, nous avons rencontré plusieurs
problèmes notamment les moteurs pas à pas non reductés qui servent à l’angle D et E chauffaient beaucoup. Par conséquent, on ne pouvait pas les englober dans une pièce plastique. Ces moteurs sont donc fixés sur une plaque en aluminium.

 

Vu que nous utilisons des moteurs pas à pas réductés, l’angle qui correspond à un pas est très faible. Par conséquent, il faut faire beaucoup de pas pour réaliser un angle en sortie de réducteur. Le problème étant que même en envoyant une impulsion à chaque tour de cycle avec l’Arduino mega, nous ne pouvions pas utiliser les moteurs à leurs vitesses maximum. Nous avons donc décidé de changer d’Arduino et de prendre un due. C’est un Arduino qui remplit les mêmes caractéristiques que le Mega c’est-à-dire 54 entrées-sorties, mais il fonctionne en 3,3 volts au lieu des 5 volts du méga. Il possède un processeur 32 bits au lieu des 8 bits. C’est à dire qu’il va falloir beaucoup moins de temps  pour réaliser des calculs. Et enfin il est cadencé à 84 MHz au lieu des 16 MHZ du mega. Quelques temps après, nous nous sommes rendus compte que c’était la bibliothèque gérant l’écran LCD qui ralentissait beaucoup le programme. Nous avons donc limité l’affichage sur l’écran tous les 100 tours de cycles. Aujourd’hui avec l’Arduino due, on est capable d’aller plus vite que la vitesse des moteurs.

Les drivers pas à pas eux aussi chauffent beaucoup, ils délivrent le courant nécessaire au moteur seulement quand ils sont froids : par conséquent, on a installé un ventilateur pour faire circuler l’air. Une fois la maquette réalisée, le programme installé dans l’Arduino, on a pu réaliser des tests concrets avec un programme fini :  nous nous sommes rendus compte que les moteurs pas à pas saccadaient un peu, par conséquent nous avons passé les drivers en commande demi pas et le bras robotisé se comporte mieux depuis.

2016-06-11 17.40.12Par la suite, nous avons géré les temporisations et les vitesses afin d’avoir des mouvements fluides avec différentes positions au moteur pour un certains nombres de points. Nous avons aussi constaté des parasites au niveau de la télécommande constitué du joystick, c’est-à-dire que de temps en temps le robot se déplace légèrement, alors que nous n’avons pas touché au joystick. On pourrait régler la sensibilité des joysticks, mais dans ce cas on aurait plus la possibilité de le déplacer lentement quand on déplace à peine le joystick.

2016-06-11 17.42.00

 

 

L’utilisation des moteurs pas à pas nous oblige à utiliser des fins de courses sur tous les axes afin de fixer l’angle à une certaine valeurs lors de la mise sous tension du robot. Par exemple, à la mise sous tension de l’Arduino, on ne sait pas dans quelle position se trouve le moteur pas à pas. On lancera donc une séquence de calibration lors de la mise sous tension.

 

 

Nous avons rempli le cahier des charges. Nous pouvons déplacer un bras robotisé avec trois possibilités :

 

– A l’aide du clavier, on peut rentrer les valeurs XYZ et même la valeur de l’angle E, 2016-06-11 17.31.33si on veut que la pince se retrouve perpendiculaire à nous. Une fois que l’on appuie sur valider, le robot se dirige vers ces valeurs en ligne droite avec rampe d’accélération et de décélération.

Vidéo Mode cartésien clavier :

 

 

– À l’aide de la télécommande, chaque joystick est composé de deux axes, c’est-à-dire que l’on peut avec un joystick augmenter ou diminuer X et idem pour Y. Avec l’autre joystick, on fait de même avec les paramètres Z et E. Plus on incline le joystick, plus la valeur s’incrémente ou se décrémente rapidement, c’est-à-dire le bras ira plus vite. Si l’on incrémente seulement X, le bras réalisera une ligne droite sur X, sans changer la valeur Y et Z.

Vidéo Mode cartésien Télécommande :

 

 

– Avec la même télécommande, on peut en basculant un switch sur le premier joystick gérer l’angle à la rotation de la tourelle ainsi que l’angle B. Et avec l’autre joystick, on gère l’angle C ainsi que l’angle E. C’est comme sur le mode cartésien, plus on incline le joystick plus la décrémentation ou l’incrémentation sera rapide.

Vidéo Mode angulaire :

Si l’on demande au bras d’aller à une coordonnée impossible pour lui, il affichera erreur sur l’écran et ne bougera pas. Exemple, si on lui demande un Z négatif donc sous le sol, il n’essayera pas d’y aller.

Vidéo Erreur :

Afin de connaître la position du bras et donc la position de chaque angle après la mise sous tension, on réalise une séquence de calibration. À la mise sous tension de l’Arduino, le premier programme que l’on réalise est la calibration. Il demande à tous les moteurs de tourner dans le même sens jusqu’au fin de course. A partir de là, il s’arrête et dans les valeurs du programme, on affecte la position actuelle du robot. De là, on connaît la position du bras. Ensuite le programme calibration se termine sur l’envoi du bras robotisé sur une position « home ».

Vidéo Calibration :

L’outil de notre robot est une pince.

Vidéo montrant le fonctionnement de la pince :

Gestion de Projet

Image3

Nous avons pris du retard sur la partie mécanique du robot, et nous avons perdu du temps à régler des problèmes de parasite sur le signal envoyé aux drivers pas à pas mais malgré cela le projet a été fini dans les temps.

 

Perspectives

14473-4001971Le bras robotisé est composé de 4 axes complètement automatisés et nous lui avons rajouté un cinquième axe qui correspond à la rotation du poignet sur un bras humain. Nous utilisons uniquement cet axe afin que la pince soit toujours perpendiculaire au sol. Nous pouvons l’utiliser pour donner un angle à la pince par rapport au sol mais dans ce cas-là, les calculs des angles deviendraient beaucoup plus lourds à réaliser car cela voudrait dire qu’il y aurait plusieurs possibilités d’angles pour la même position. C’est pour cette raison que nous gardons la pince perpendiculaire au sol. Il y a donc une évolution à ce niveau-là pour rendre le robot en 5 axes. Il suffirait de réaliser les calculs nécessaires. Dans cette optique, nous pourrions même le rendre mobile sur 6 axes afin de donner à l’outil une position mais également un angle dans l’espace.

 

Aujourd’hui le bras robotisé est pilotable de deux façons. activar-wifi-telefono-celular-ventjas-desventajasL’une avec le clavier en rentrant des coordonnées cartésiennes sur X,Y et Z et l’autre, avec la télécommande constituée de deux joysticks pour faire varier directement les coordonnées X,Y et Z. Il y aurait une évolution au niveau de la manière de piloter le robot car on pourrait très bien imaginer pouvoir le piloter à l’aide d’une interface web ou d’autres moyens de communication sans fil.

 

Bilan

Bilan

 

– Réaliser un bras robotisé 5 axes dont 4 réellement pilotables

canstock15025439 Le robot comporte ses 5 axes dont 4 pilotables

– Celui-ci devra pouvoir être pilotable dans un repère cartésien avec des déplacements linéaires

canstock15025439

– La partie commande sera réalisée sur une carte type Arduino

canstock15025439

– Le robot devrait pouvoir évoluer dans une demi sphère de 300 mm de rayon et prendre en compte les zones interdites

canstock15025439Le robot peut se déplacer dans une zone de 400mm autour de sa base et prend en compte les zones interdites

– La précision au bout du bras devrait être au moins de 4 mm

Afficher l'image d'origine Le jeu dans les réducteurs des moteurs pas à pas ne nous permet pas d’atteindre cette précision quelque soit la position du robot dans l’espace.

– Les coordonnées de positions du robot devraient être entrées à l’aide d’un clavier

canstock15025439

– Le robot devrait également être pilotable à l’aide d’une télécommande comportant 2 joysticks selon deux modes : angulaire ou linéaire.

canstock15025439

– La position réelle du robot ainsi que les coordonnées tapées au clavier seront affichées sur un écran LCD.

canstock15025439

– Les déplacements devront se faire en suivant une rampe d’accélération et de décélération.

canstock15025439

– Le robot devrait pouvoir se déplacer avec une charge de 200g max dans sa pince.

canstock15025439Le robot peut soulever environ 500g

– Le robot devrait comporter un bouton d’arrêt d’urgence de type coup de point.

canstock15025439

 

Conclusion

20160612_163604Voilà un petit extrait de notre projet, qui vous montre notre implication. On pourrait l’expliquer pendant des heures mais ce n’était pas le but, par conséquence on s’est contenté de vous expliquer les parties les plus intéressantes.

Le projet a été très intéressant, il nous a permis d’acquérir et de mettre en pratique beaucoup de connaissances. Aujourd’hui nous pouvons être fiers de notre réalisation car le bras robotisé fonctionne correctement. Il a été un projet complexe qui a demandé beaucoup d’heures de travail.

 


Memory

Jeu

Le projet Jeu Memory a pour but de créer un jeu de carte Memory sur ordinateur, qui devra être codé en language C grâce à l’outil Codeblocks , ainsi que l’utilisation de la bibliothèque graphique SDL2. 

Sans titre - 25

Read More


Vélo Magnétique

 

logo-iut

GEII

 

Projet: Vélo magnétique

Véloseul

BOULBAIR Badr 

PIVERT Anthony

 

Sommaire:



Présentation du projet

Tous les étudiants du GEII, en première année sont confronté à un challenge au cours de leurs deuxième semestre. Ils sont tenus de choisir un projet parmi quatorze sujets présentés, dans notre cas il s’agit du Vélo magnétique. Nous devons réaliser ce projet dans le cadre du module « Études & Réalisations », dont la notation comprend plusieurs facteurs, bien entendu la réalisation du projet, mais également la communication au sein du groupe, l’implication des différents membres, et la conduite du projet.

Les Intervenants du Projet Vélo Magnétique est Anthony PIVERT et Badr BOULBAIR.

Tout le monde (ou presque) aime faire du vélo, cela permet de s’entretenir, se déplacer écologiquement, ou tout simplement de se divertir au cours d’une balade. Dans tous les cas nous fournissons un effort physique, et donc de l’énergie.  Mais il est difficile de quantifier, et même de pouvoir réutiliser cette énergie avec un vélo ordinaire.  C’est pourquoi nous avons fait un vélo capable de vous montrer l’énergie que vous produisez en temps réel, et même d’utiliser cette énergie afin de : Charger son smartphone/allumer DES lampes/ et même utiliser des objets tel qu’une perceuse. Dans la seconde partie du projet nous avons fait en sorte que plus la personne qui pédale essayera d’aller vite plus la contrainte au niveau du pédalier sera grande (principe du vélo elliptique), par le principe du frein magnétique, tout en gardant un vélo utilisable par un large intervalle de personnes.



Cahier des charges

mindmap

 

 A) Diagramme Bête à corne:

La bête à cornes est un outil de représentation de questions fondamentales. (A qui rend il service, sur quoi agit-il, dans quel but)

  B) Diagramme Pieuvre

Le diagramme pieuvre regroupe les fonctions principales ainsi que les principales contraintes du projet. Dans notre cas nous avons un diagramme qui peux être divisé en deux parties.

Diagramme globale:

 

DIAGRAMME2.0

FP1 Générer de l’énergie électrique en fonction de l’énergie mécanique produite
FP2 Contrainte de pédalage du au frein magnétique
FC1 Le budget de ce projet est de 200€
FC2 Doit se fondre dans le décor
FC3 Utilisation de matériaux approprié
FC4 Garantir la sécurité de l’utilisateur
FC5 Accessible par un large publique

 

Read More


Onduleur

IUTGEII

 

 

 

 

Projet Maquette Énergie :

Onduleur

hjaja

 

GEII 1A 2015-2016 MULHOUSE

 


Sommaire :


Read More


Système Embarqué Mont Blanc

RESUME 

     Ce projet a pour objectif la conception et la fabrication d’un module autonome ayant la capacité de prendre certaines mesures physiques .(température, pression, humidité et position GPS). Ce système devra stocker ces données pour les transférer par la suite à un ordinateur.

Il sera utilisé dans de condition extrêmes puisque son but sera d’être utilisé lors d’une ascension du Mont Blanc.

Read More


NAO show lumineux



Résumé

 L’objectif du projet est de faire danser dans la salle B19 un robot NAO via le logiciel chorégraphe 2.1.3 et d’utiliser un serveur DMX afin que Nao donne les ordres aux projecteurs en synchronisation avec la musique selectionnée au préalable.

projetnao

Read More


ROBOTS AQUATIQUES


Sommaire

 

Introduction

Présentation du sujet

Cahier des Charges

Budget détaillé

Développement

Gestion de projet

Manuel Technique

Bilan

Bibliographie

Remerciements

 


Introduction

 

Etudiants de première année en département GEII à l’I.U.T de Mulhouse, nous avons eu la chance de pouvoir choisir entre différents sujets de projets proposés par les enseignants. Une fois les groupes réalisés, nous pouvions commencer à travailler sur un projet avec une grande liberté tout en aillant accès à l’aide des enseignants si besoin. Pendant 4 semaines, le but était à la fois de gérer la conduite du projet, l’étude et la réalisation de celui-ci.

⇑Sommaire

 


Présentation du Sujet

 

Nous avons lancé le projet par une visite à l’école Freinet de Mulhouse. L’objectif était de faire découvrir aux enfants la robotique. Les enfants étaient prévenus de notre visite et avaient pour mission de nous dessiner le robot de leur rêve sur le thème de notre projet : « Robot Aquatique ». Nous sommes donc venus récupérer les dessins afin de nous donner une idée des robots que nous allions devoir réaliser.

Ce que nous avons retenu :

  • Faire un robot « observateur » capable de se déplacer de façon autonome et de filmer les environs.
  • Faire 2 robots « combattants » capables de tirer de l’eau l’un sur l’autre et créer un jeu autour de cela. Ces robots sont quant à eux commandés par des manettes, afin de laisser les enfants jouer avec.

Nous avons aussi pu leur faire construire des robots Lego, ainsi que leur montrer ce qu’était dans les grandes lignes la programmation sur ordinateur.

⇑Sommaire

 


Cahier des Charges

 

Cadre du projet :

 

Contexte :

  • Collaboration avec les enfants de l’école Freinet afin de construire des robots qui répondent dans la mesure du possible aux attentes des élèves.
  • Des recherches ont été effectuées pour le choix des composants et sur la manière de construire les robots. Des tests de flottabilités ont également été effectués sur la coque confectionnée par les membres du groupe.

Acteurs :

  • Les enfants dans la recherche d’idées
  • Notre groupe de projet, soit : SEDIRI Aladin, FOUCAULT Antoine, LAVALLEE Arthur, DEVERCHIN Arnaud, DECKER-WURTZ Alexis, BERTRAND Christopher et GAECHTER Hugo dans les changements à apporter aux idées pour les rendre réalisables et les réaliser
  • Mr HUEBER et CHOISY en tant que profs référents

Besoins :

  • Connaissances techniques à acquérir dans la construction physique et la programmation des robots
  • Construire des robots fonctionnels tout en répondant aux attentes des enfants
  • Respecter les contraintes de sécurité, et celles imposées de coûts et de délais

But :

  • Ce projet à pour but de promouvoir le département GEII aux journées portes ouvertes, ainsi que de sensibiliser les enfants de l’école à la robotique. Il est important de montré que la robotique est une discipline qui nous intéresse et nous intrigue, c’est pourquoi ce projet est très apprécié car il nous permet de mettre en pratique tout ce qu’on connait de ce domaine, d’apprendre de nouvelles choses, tout en renvoyant pour le GEII l’image d’être un département qui innove dans ses méthodes d’apprentissage.
⇑Sommaire

Contraintes :

 

Budget :

200e imposés, extensible si besoin en appelant l’aide d’autres groupes qui n’ont pas besoin de tout utiliser

Délais :

  • Première date butoir à la JPO (1 robot fonctionnel en partie au moins nécessaire)
  • Date à laquelle les enfants viennent, où tous les robots doivent être fonctionnels, testés et approuvés (date en attente)
  • Date de fin de projet à laquelle tout doit être fini et présentable (26 Juin)

Sécurité :

Celle des robots et des enfants, s’assurer de l’étanchéité des robots et empêcher des fuites de courant dans l’eau.

Les normes officielles de sécurité des enfants sont à la charge de l’école.

Aucune norme officielle ne nous concernent dans la construction de nos robots, on ne trouve que des normes concernant des robots industriels ce qui n’est pas notre cas.

Taille du groupe :

Nous sommes 7 à travailler ensembles sur le même projet, ce qui exige une organisation et répartition des tâches irréprochables pour ne pas rendre certains travaux infructueux. On se sert donc de Google Drive pour avoir un tableau des tâches que chacun doit faire et pour quand. Chacun peut écrire sur ce fichier pour rendre compte de l’avancement de ses travaux et ainsi éviter des mésententes au sein du groupe.

⇑Sommaire

Objectifs du projet :

 

Faire découvrir aux enfants les possibilités mais aussi les limites de la robotique, tout en rendant le projet fun à découvrir à travers le contrôle des robots et d’un jeu.

⇑Sommaire

Ressources matérielles :

 

  • Coque (Polyester)
  • Hélices
  • Gouvernail
  • Moteurs
  • Cartes Arduino + Manette ou smartphone (Interface H/M)
  • Piscine

 

Ressources Humaines :

 

  • Membres de notre groupe
  • Les enfants (clients)
  • Profs référents (Mr HUEBER et CHOISY)
  • Autres groupes de projet pour bénéficier d’extensions de budget
⇑Sommaire

Graphiques :

  • Bête à cornes :

Bete a corne

⇑Sommaire
  • Pieuvres :

Générale :

Pieuvre GénéraleTableau Pieuvre générale

⇑Sommaire

Robot observateur :

Robot observateur Pieuvre

Tableau Pieuvre Robot obs

⇑Sommaire

Robots combattants :

Pieuvre robots combattants

Tableau pieuvre combattants

⇑Sommaire

GANTT :

Prévisionnel :

GANTT Prévisionnel

⇑Sommaire

Réel :

GANTT Réel

⇑Sommaire

 


Budget détaillé

 

Tableau budget

Liens :
1
2
3
4
5
6
7
8
9
10
11 et 13

Budget alloué : 200 €

Dépenses : 261,49 €

 

⇑Sommaire

 


Développement

 

Alimentation

 

Nous avons 2 moteurs sur le robot observateur :

  • Un pour avancer/reculer (Moteur courant continu) et le second pour tourner (Servomoteur)

Et 3 moteurs sur les robots combattants :

  • Un pour avancer/reculer (Moteur courant continu) et le second pour tourner (Servomoteur) et la pompe

 

Le problème rencontré dans les 2 cas était qu’une seule batterie ne suffisait pas, car lorsqu’on fait tourner tout les moteurs d’un bateau, la chute de tension provoquée était trop importante et faisait planter l’arduino.

 

Notre solution a été de mettre 2 batteries sur les bateaux :

  • Une de 9V pour alimenter l’arduino, arduino qui servira ensuite à alimenter le servomoteur
  • Une de 12V pour les autres moteurs (MCC pour l’observateur, MCC et pompe pour les combattants)

 

Alimentation

 

⇑Sommaire

Manette

 

Nous voulions au départ récupérer une manette déjà existante, type voiture commandée, afin de récupérer le récepteur, le mettre sur notre bateau plutôt que sur la voiture et réutiliser ainsi un fonctionnement déjà créer et simplement l’adapter à notre besoin.

Seulement, les manettes récupérées ne marchaient pas bien, beaucoup de composants étaient manquants, nous avons rencontré énormément de problème en voulant opter pour cette solution et ils auraient étés trop longs à résoudre. De plus, nous n’aurions en rien créer la communication, et le but de ce projet n’est pas de récupérer mais de créer.

 

Finalement, nous avons donc rajouter un shield USB sur l’arduino et un donggle bluetooth associé à une manette de PS3, ce qui nous a fait programmer : Programmation Commande Bateau

⇑Sommaire

Donggle

 

Nous pensions avoir un problème puisque le donggle bluetooth utilisé ne fonctionnait pas, mais c’était finalement simplement un composant dessoudé, nous l’avons donc simplement ressoudé.

 

⇑Sommaire

Servomoteur

 

Nous voulions récupérer pour les 3 bateaux 3x les mêmes servomoteurs récupérables à l’I.U.T, mais pour les robots combattants nous avons rencontré un problème de conflit avec la manette. En effet, soit le programme du servomoteur prenait de le dessus et fonctionnait à l’instar de celui de la manette, soit l’inverse, le programme de la manette fonctionne mais pas celui du servomoteur.

On a finalement du en prendre 2 nouveaux pour les robots combattants afin de régler ce problème.

 

Cela a entraîné un nouveau problème : Comment programmer ces nouveaux servomoteurs, et où trouver les drivers, étant donné qu’ils ne sont pas faits pour être programmés via arduino.

(Rappel : Programmation Commande Bateau)

 

⇑Sommaire

Pompes

 

Nous avons d’abord créer une pompe avec un petit moteur et des tubes, mais cela ne fonctionnait pas à 100% car nous avions un problème d’amorçage/réamorçage, nous étions obligés d’aspirer l’air bloqué dans la pompe afin de la lancer, et si l’angle de tir devenait trop important le même problème arrivait. Il était donc inenvisageable d’interrompre systématiquement le fonctionnement des robots.

Notre solution fut d’acheter de nouvelles pompes. En ce qui concerne le programme pour l’activer, nous avons trouvé un schéma électrique pour gérer un moteur à courant continu avec une pin de l’arduino

Cela comprenait une diode anti retour, 2 résistances et un transistor npn.

MCC schéma

Ça ne fonctionnait pas.

On a donc essayé de rajouter un transistor npn supplémentaire qui piloterait le précédent, mais ça ne résolvait pas le problème.

La solution fut finalement de remplacer le 1er transistor npn par un relais 12V qui est lui-même piloté par un transistor npn.

schéma pompes

 

⇑Sommaire

Caméra

 

Nous avions au départ un problème de batterie qui nous a même fait envisager d’enlever la caméra : en effet, la caméra s’éteignait au bout de quelques petites minutes. Finalement, nous avons changé de caméra et nous la rechargeons grâce à une batterie nomade en cas de besoin.

Nous avions aussi rencontré un autre problème qui empêchait cette nouvelle caméra de fonctionner, problème résolu par une mise à jour du firmware.

 

⇑Sommaire

 


Gestion de projet

 

Etant donné notre effectif ( 7 personnes ) nous nous devions d’être rigoureux dans la gestion et l’administration des tâches. Nous avons pour cela créer un dossier Google Drive partagé entre nous, sur lequel nous nous sommes organiser pour être sur que tout le monde avance ensemble sur le projet, éviter que trop ou trop peu de personnes travaillent sur la même chose, et garder le fil quant à la direction que nous voulions donner au projet.

⇑Sommaire

 


Manuel Technique

 

Pour reprendre notre projet, il faudra se référer au tableau budget afin d’identifier tout ce qui se trouve sur le bateau, et continuer de programmer différentes fonctions sur l’arduino en démarrant grâce à ce tutoriel qui explique les bases.

Ne pas oublier de bien regarder les caractéristiques des batteries pour savoir comment les rechargées.

Les robots étant faits pour des enfants, leur utilisation est très facile. Pour les robots combattants, il suffit de le brancher comme ceci la batterie et le moteur sur l’arduino :

Branchement moteur batterie sur arduino

Puis de contrôler les bateaux à l’aide des manettes.

Le robot observateur est autonome, il suffit donc de le poser dans l’eau et de lancer le moteur à l’aide du branchement vu précédemment.

⇑Sommaire

 


Bilan

 

Ces 4 semaines de projet nous ont appris à étudier pour directement mettre en application les notions vues, ce qui permet de mieux les acquérir et de pouvoir associé la théorie à la pratique.

Dans notre groupe de 7, nous avons aussi beaucoup travaillé afin de bien se répartir les tâches, de bien avancer ensemble et de profiter de notre effectif pour aller plus vite et plus loin dans le projet, pour éviter que cela se transforme en handicap et nous ralentisse.

Nous nous devions aussi d’aboutir à des résultats puisque nous nous sommes engagés auprès des enfants à leur fournir des robots qui fonctionnent et avec lesquels ils pourraient jouer, nous ne pouvions donc pas les décevoir.

Dans l’ensemble, nous avons rencontrés un bon nombre de problèmes de réalisations, étant donné que nous avions beaucoup de directions dans lesquelles nous pouvions aller, nous avons pris beaucoup de temps afin de bien définir le chemin que nous donnerions au projet, et nous avons rencontré plusieurs problèmes en chemin, essentiellement techniques dans la réalisation des robots et aussi dans la programmation. Cependant nous avons toujours trouvé des solutions à nos problèmes, et nous pourrions donc conclure en disant que notre plus gros problème fut de respecter les délais.

Ce projet nous a à tous beaucoup apporté, nous avons découvert tout ce qu’implique un projet lorsqu’on le mène de A à Z et on a pu se rendre compte de l’importance de la conduite de projet afin de ne pas perdre le fil malgré tout les imprévus qui peuvent intervenir.

⇑Sommaire

 


Bibliographie

 

Voici les liens des sites qui nous ont aider à réaliser notre projet :

Tutoriel Arduino UNO

Moteur CC via Arduino

RS composants pour les datasheets

Driver moteur Arduino

Schéma électrique pour pompes

Programmation Commande Bateau

 

Voir tableau du budget pour les adresses du matériel acheté.

⇑Sommaire

 


Remerciements

 

Nous tenons à remercier nos enseignants tuteurs Mr HUEBER et Mr CHOISY de nous avoir accompagnés et conseillés durant ce projet.

Nous adressons également un grand remerciement à Mr DE SABBATA qui nous a largement aidés pour la réalisation du projet.

⇑Sommaire

 


Maquette Domotique

  • Introduction

Dans le cadre de notre formation de première année de DUT GEII (Génie Electrique et Informatique Industrielle),  le module Etudes et Réalisation (Projets) doit être réalisé. Nous avons eu la possibilité de choisir le projet qui nous intéressait le plus. Pendant 4 semaines, de mars à avril, l’emploi du temps a été grandement consacré à cela. Nous étions encadrés par des professeurs qui étaient à notre disposition et qui nous ont notés sur nos recherches et notre avancement.

Image1

 

  • Présentation du sujet

La Maquette Domotique est un ancien projet inachevé commencé il y a 2 ans, nous l’avons repris pour le continuer et le finaliser. Nous avons donc dû résoudre les problèmes rencontrés par nos prédécesseurs.

Par le biais de notre Maquette Domotique, nous devons sensibiliser les personnes sur les « énergies de demain » en simulant une maison totalement autonome énergiquement grâce aux énergies renouvelables.

Nous disposons des énergies suivantes:

-Éolien : Utilisation d’une éolienne domestique.

-Solaire : Installation de panneaux photovoltaïques ainsi que thermiques.

-Hydraulique : Cours d’eau présent afin d’alimenter une turbine hydraulique.

-Biomasse : Combustion des bio-déchets.

-Bois : Combustion de bois dans un foyer bois.

Sur la maquette, l’éolienne et la turbine hydraulique fonctionnent grâce à des moteurs.

Répartition des systèmes de production des énergies renouvelables

 

Nous devons rendre notre maquette à la fois démonstrative et ludique afin de plaire au public.

 

  • Gestion de Projet

Nous sommes suivis par un professeur, dans la matière « Conduite de projet », qui nous apprend à travailler sur des projets en général. Nous avons ainsi à faire les démarches, les explications et les présentations du projet.

Nous avons appris à planifier nos semaines pour y associer les tâches à effectuer chaque jour et ainsi éviter le plus possible les écarts.

Pour cela nous sommes un groupe de 4 étudiants :

-Maillard Guillaume : Chef de projet

-Muller Quentin

-Perreaut Romain

-Sutter Valentin

 

  • Cahier des Charges

 

Schéma « Bête à corne » :

Sans 1titre

Schéma « Pieuvre » : Fonction du projet

Sans titre

Fonction Principale : Rendre notre Maquette attractive afin de sensibiliser le public sur l’utilisation des énergies renouvelables.

Fonctions Contraintes : Nous devons prendre en compte les contraintes pour faire de notre maquette un projet rentable, intéressant et pédagogique.

Read More


Challenge Robotique National

Robot Mobile

IUT de MulhouseGEII Mulhouselogo-uha

GEII 1A 2015-2016 MULHOUSE

Projet Robot Mobile

mulhouse_rotashneck

 

 



Membres du groupe:

 

  • BRULANT Antoine
  • DIAKHATE Matar
  • JUNCK Kevin
  • MARIAN JUDE Antony
  • SCHNELL Vincent
  • WAGNER Mickael

 

 

Présentation du sujet:

 

Dans le cadre du DUT Génie Électrique et Informatique Industrielle (G.E.I.I.) nous sommes amenés à réaliser un projet au courant du 2ème semestre. Cette année nous pouvions choisir entre 14 sujets différents. Nous avons choisis ce projet car nous nous sentons tous les 6 attirés par la robotique.

Notre projet est donc le suivant:

Nous devons concevoir et construire un robot qui  devra être indépendant, on peut donc dire qu’il sera plus ou moins doté d’une intelligence artificielle.

Le principe est simple, notre robot sera placé dans un coin du playground (dans ce cadre il s’agit d’une plate-forme utilisée pour tester un robot) de 8×8 mètres sur lequel seront placés des obstacles. Le but de la manœuvre étant que le robot atteigne le coin opposé du playground le plus rapidement possible et qu’une fois arrivé, il crève un ballon gonflable accroché sur son toit. Pour ce faire nous avons le droit d’utiliser tous les capteurs possibles et nous avons aussi le droit de placer jusqu’à 3 balises autours du ring pour pouvoir guider notre robot vers l’arrivée. Cependant un châssis nous est imposé.

 

Playground


 

 

Cahier des charges :

 

Bête à corne :

 

bete a corne

Diagramme Pieuvre :

 

Pieuvre_Projet

 

 

 

Pour résumer le diagramme pieuvre ci-dessus:

  • Le robot doit avant tout être capable de traiter les informations acquises à travers les capteurs et de se déplacer en fonction de celles-ci pour accéder à l’arrivée.

Cependant pour respecter les contraintes qui nous sont imposées le robot devra :

  • Traiter des informations grâce à un microcontrôleur (PIC 18F4520)
  • Être équipé de capteurs pour pouvoir détecter des obstacles
  • Être guidé par des balises
  • Remplir les conditions d’admission au concours robotique de Cachan
  • Être réalisable avec un budget de 200
  • Être terminé avant la présentation finale qui aura lieu fin Juin
  • Alimenté à partir d’une batterie 12V placée sur le robot
  • Posséder des moteurs et une interface de puissance pour pouvoir se déplacer

 

 


 

Gestion du projet:

Nous avons très rapidement compris qu’on pouvait découper notre projet en 3 parties afin de réaliser un robot conforme au normes imposées.

Ces 3 parties sont les suivantes:

  1. La motorisation du robot
  2. Détection d’obstacles
  3. Le guidage sur le playground

Nous sommes un groupe de 6 personnes,donc nous avons décider de nous diviser en 3 sous-groupes de 2 personnes afin de traiter toutes les parties simultanément.

1. Motorisation

 

Photo

Ainsi pour ce qui est de la partie motorisation du robot, Vincent et Matar ont utilisé des ponts en H dans le but de contrôler le sens de rotation du moteur ainsi que des sorties PWM (Pulse in With Modulation) afin de pouvoir gérer la vitesse de rotation des moteurs à l’aide d’une tension continue.

Pont en H

Test de la Motorisation

 

2. Détection

Pendant ce temps, Antony et Antoine se sont concentrés sur la détection des obstacles. Ils ont fini par conclure que l’outil le plus adapté pour repérer des obstacles est le capteur à ultrasons. Ainsi,il nous suffira d’envoyer des ondes dans la direction vers laquelle se déplace notre robot et de mesurer le temps que prendra l’onde pour revenir.Cela permettra de savoir à quelle distance se trouve l’obstacle et ainsi nous pourrons éviter tout obstacle qui se dressera devant notre robot.

capteur ultrason

Vidéo du fonctionnement de la partie Motorisation et Détection

 

3. Guidage

Mickaël et moi,nous avons travaillé sur cette 3ème partie. Après avoir évaluer toutes les solutions qui s’offraient à nous, nous avons conclu qu’utiliser une balise infra-rouge reste la meilleure option possible compte tenu de notre budget et de la durée du projet. Nous avons donc repris la balise qui a été fabriquée par le groupe de projet de l’année dernière et nous avons reprogrammé le microcontrôleur PIC18F4520 qui sera d’ailleur notre plate-forme de programmation tout au long du projet.

Bilan:

Actuellement,les 3 parties qui sont essentielles à la réalisation de notre robot sont terminées. Dans chacune des parties nous avons opté pour les méthodes les plus répandues pour la simple et bonne raison que ce sont les plus sûrs et les plus précises.

Pour ce qui est de la motorisation,nous  choisissons d’utiliser deux moteurs (un pour chaque roue) alimentés en PWM à l’aide d’un pont en H ainsi nous pouvons contrôler la vitesse et le sens de rotation.

Pour la détection d’obstacle,les émetteurs et récepteurs ultrasons ont été simple à contrôler et leurs précisions sont largement suffisantes pour subvenir à nos besoins ce qui justifie notre choix.

Pour le guidage,nous avons fait le choix d’utiliser des balises infrarouges car c’était la meilleure solution dans notre cas,compte tenu du fait que les autres solutions n’étaient pas réalisables avec notre budget ou étaient trop difficiles a mettre en œuvre.

 

Actuellement nous avons chacun fini nos parties mais nous n’avons pas encore pu mettre en commun pour créer un prototype. Cependant nous allons attaquer cette dernière phase du projet dans les jours à venir pour pouvoir finir notre projet dans les délais.

 

 

Conclusion:

Ce projet nous a aidé a mieux appréhender le travaille en équipe et nous a permis d’appliquer tous les cours théoriques que nous avons eu depuis le début de l’année.

Cependant nous nous sommes tous rendu compte que mener à termes un projet n’est pas toujours aussi facile que l’on le pensais. Nous avons dû faire beaucoup de recherches sur différents sujets pour pouvoir réaliser chacun nos parties. La partie programmation a été l’une des difficultés majeurs dans ce projet car nous n’avions jamais programmé un PIC auparavant.

Nous avons tous réalisé que lorsque nous rencontrons des problèmes,il est préférable de travailler tous ensemble pour résoudre le problème en vitesse et sans ambiguïté.

Au final nous sommes tous d’accord sur le fait que cette expérience est des plus enrichissantes car nous rencontrons de nombreux problèmes que nous serions souvent incapable de résoudre seuls, mais nous apprenons à les surmonter ensemble en équipe, ce qui nous permet de repousser nos limites et d’accélérer notre productivité


 

 

Portes_ouvertes_2016

 


Table traçante XY

Logo_IUT_Mulhouse                                              GEII

                                    capture_06232016_154752

Introduction

Etudiants de GEII première année, nous sommes arrivées a une période de l’année( mois de mars) que le département au projet d’étude et de réalisation de 1 ére année. C’est dans ce cadre là que plusieurs sujet de projets nous sont proposé. Libre aux étudiants de choisir sur quel projet ils vont se consacrer sur une période de 70 heures reparti en 4 semaines.

Dans notre cas, il s’agit du projet de la table traçante  XY.
prj 077

 

Read More


NAO sur Robotino

 

NAO se déplace

 

939397_10207861829137193_139388995_o

 

Résumé

 

Le département GEII de l’IUT de Mulhouse dispose de 4 robots humanoïdes NAO programmables qui sont capables de se déplacer en parfaite autonomie . Néanmoins, leur vitesse de marche reste très limitée. C’est pourquoi, il serait intéressant de pouvoir les asseoir sur un robot beaucoup plus mobile, un RoboTino, lui aussi à la disposition du département au nombre de 2. L’idée est donc de les rendre capables de réceptionner des informations transmises par le NAO afin de pouvoir amener celui-ci à bon port.

Une fois cette tâche établie, la finalité du projet serait de permettre au NAO d’accueillir et de guider des visiteurs au sein du bâtiment B grâce notamment au système de reconnaissance vocale du NAO et de ses différents capteurs.

Introduction

 

NAO est un robot humanoïde développé par Aldebaran Robotics, une start-up française basée à Paris, c’est un robot équipé de 14 à 25 degrés de liberté (=articulations) suivant les différents modèles proposés par la firme, ceux de l’IUT étant des modèles en ayant 25. Ce robot embarque un noyau linux (baptisé naoqi) ainsi que tout un panel de capteurs dont 4 capteurs ultrasons sur son torse pour l’évaluation des distances, 8 capteurs de pression, 2 caméras et 2 bumpers à ses pieds afin de détecter d’éventuels obstacles. Le tout pour un poids total de 4.8 kg et une hauteur de 58 cm. Il est surtout utilisé en laboratoire ou dans le domaine de l’enseignement comme c’est ici le cas.

En ce qui concerne son robot mobile, il s’agit d’un RoboTino développé par la firme Festo établie en Allemagne à Esslingen. C’est un robot programmable par PC, bardé de capteurs et capable de se déplacer en parfaite autonomie. Grâce à ses 3 moteurs et à ses roues suédoises, RoboTino peut se déplacer dans toutes les directions ainsi que tourner sur lui-même.

Il s’agit donc de notre projet du second semestre durant lequel nous avons travailler à faire communiquer les deux robots et rendre le tout fonctionnel.

Présentation du Sujet

 

Au cours de notre DUT GEII, nous sommes amenés lors du second semestre de notre première année à travailler sur un projet de notre choix parmi une dizaine de projets qui nous ont été proposés. Une fois le second semestre terminée, l’évaluation s’effectuera au cours d’une soutenance finale que nous avons eu le temps de préparer durant nos cours de conduite projet avec Monsieur ROTH. L’évaluation portera aussi sur notre esprit d’équipe, notre implication et le sérieux dont nous avons fait preuve au cours de toute la durée de notre projet.

Cahier des Charges

 

Préambule :

  • La société française Aldebaran Robotics, propose un robot humanoïde NAO autonome et programmable notamment destiné à des activités pédagogiques.
  • En 2008, la société lance une version academics de son robot afin de permettre son utilisation dans des laboratoires et dans des établissements d’enseignement tels que des universités
  • Le département GEII de l’IUT de Mulhouse possède ainsi 4 robots NAO au jour d’aujourd’hui.

Présentation :

  • Ils sont capables de recevoir et de guider des visiteurs potentiels à un endroit donné.
  • Les robots NAO sont donc des appareils capables de se déplacer de façon autonome au sein de leur environnement, mais leur vitesse de déplacement reste très limitée, restreignant ainsi grandement leur capacité d’accueil de visiteurs.
  • Le département GEII de l’IUT ayant aussi à sa disposition un robot mobile RoboTino capable de se déplacer en recevant des instructions au sein d’un réseau wifi, NAO doit pouvoir s’atteler à celui-ci et lui transmettre les bonnes informations pour arriver à destination.

Critères généraux :

  • L’assise de NAO sur le RoboTino doit être suffisamment stable pour assurer sa protection.
  • Mettre au point un dialogue commun entre les deux robots.
  • Une signalétique préalablement établie doit être mise en place au sein du bâtiment afin que NAO puisse s’orienter et donc transmettre les bonnes informations au robot mobile.

Critères de fonctionnement :

  • L’ensemble doit pouvoir se déplacer dans toutes les directions.
  • L’ensemble doit être capable de détecter et d’éviter un obstacle potentiel, que ce soit un objet ou une personne.
  • L’ensemble doit arriver à destination.

Critères techniques :

  • Prise en main du logiciel choregraphe et du langage python (NAO).
  • Prise en main du logiciel RoboTino view (Robot mobile).
  • Communication wifi entre les deux robots ou via des Entrées sorties + choix du routeur du robotino ou d’un routeur indépendant.
  • Utilisation de données UDP.

Bête à cornes:

 

Capture

Pieuvre:

 

Capture

Diagramme de Gantt

 

Capture

 

Développement

 

Nous pouvons distinguer plusieurs grandes étapes clés de notre projet, à savoir: (par ordre chronologique)

 

1°)La mise au point et la réalisation de l’assise:

Après avoir pensé à de multiples systèmes d’assise du NAO sur le Robotino, nous nous sommes décidé pour un système de « chaise » tout simplement, nos autres idées étant beaucoup plus complexes à réaliser et pas forcément plus efficaces. Parmi celles-ci, nous avons pensé à un socle surmonté d’une longue tige où fixer NAO debout dessus (solution pas vraiment stable), un système d’assise mais sans dossier avec un système de renne où NAO pourrait s’accrocher (plus ludique mais très instable elle aussi) ou encore un système d’escalier permettant à NAO de grimper de lui-même sur le robot mobile (solution difficile à mettre en oeuvre, risquée et sûrement très instable une fois de plus donc très vite abandonnée).

La solution de la chaise nous semblait donc être le meilleur choix.

 

12295005_10207861828897187_1779894414_o12422356_10207861828657181_397824911_o

 

2°)La prise en main des logiciels et du langage python:

Une fois la partie mécanique du projet résolue, nous avons commencé à nous initier à la programmation des deux robots puisque ce fût du matériel et un environnement de travail totalement nouveau pour nous. Nous nous sommes par la suite aussi intéressés aux bases du langages python nécessaire à la programmation de la mise en réseau des deux robots.

L’ensemble de cette période d’initiation a été opérée grâce notamment aux documents constructeurs et des divers tutos mis à notre disposition par nos professeurs tuteurs.

3°)Echanges de données UDP

Après avoir passer les quelques premières séances à nous approprier le projet et ses différents facteurs, nous avons pû commencer à nous attaquer au coeur même du sujet: la communication entre les deux robots.

Nous avons été aiguillé vers une utilisation de données UDP pour ce faire puisqu’il s’agit d’un des principaux protocoles de télé-communication au même titre que les données TCP, l’avantage des données UDP étant leur plus grande simplicité puisqu’elle n’implique pas de  » handshaking », cette simplicité qui à le défaut de ne pas garantir la bonne livraison du message envoyé.

C’est ici qu’intervient le langage python puisqu’il nous a permis de programmer un bloc vierge sur Choregraphe à l’origine de la communication entre les deux robots. En effet, ce bloc permet l’envoi de trames UDP du NAO à un serveur localisé sur le pc où le logiciel du robotino est lancé qui, lui, transmet ces trames au robotino afin de lui ordonner tel ou tel déplacement.

Pour être plus précis, nous avons récupérés grâce à un logiciel tiers (spyder) les codes générés par le robotino lors de chacun de ses déplacement (1 déplacement=1 code spécifique), nous avons ensuite fais correspondre chacun de ces codes à une instruction reconnue par le NAO (tout d’abord de type numérique puis de type vocal et enfin grâce au système de Nao Mark) à l’intérieur de ce bloc vierge sur l’interface Choregraphe propre au NAO.

 

Copie de nao mark code

 

 

 

Une fois cette étape établie, le reste de la programmation en python dans ce bloc permet l’envoi de ces codes sur un serveur que nous avons préalablement lancé et configuré sur RobotinoView.

 

tino1 - Copie

 

4°)Programmation de chacun des robots

Une fois la communication entre les deux robots établie, nous avons pu finaliser la programmation que nous avions esquissés de chacun de nos 2 robots puisqu’ils étaient jusqu’alors sommairement programmés afin de répondre à des ordres simples.

 

Notre programme RobotinoView:

 

Copie de tino1

 

Notre programme Choregraphe:

 

photo nao commande

 

Gestion de Projet

 

Notre chef de projet est Louis Spiesser et pour ce qui est  de la répartition des tâches, nous avons décidé de scinder l’équipe en deux:

  • Louis et Loïc ont été chargés de travailler sur NAO et son logiciel Choregraphe.
  • Luigi et Jean-Michel ont quant à eux été chargés de travailler sur le Robotino et son logiciel RobotinoView.

 

Ressources et bilan financier

 

Pour ce qui est des ressources utilisées, nous n’avons certes pas eu la nécessité de dépenser les 200 € mis à notre disposition mais nous avons cependant eu accès du matériel très couteux. En effet, nous avions à notre disposition 4 robots NAO valant 5000 € pièce ainsi qu’à deux robotino valant 8000 euros pièce sans compter la matière première et l’outillage fournis par l’IUT et nécessaire à la fabrication de notre assise.

 

Perspectives

 

Suite aux problèmes de portée wifi que nous avons rencontrés au cours de notre projet, nous avons été contraints de modifier la finalité de notre projet: A savoir, effectuer un itinéraire donné au sein de la salle B19, alors que notre perspective première était de pouvoir permettre à notre NAO de se déplacer au sein du bâtiment B voire même accueillir et présenter le bâtiment à des visiteurs potentiels.

Conclusion

 

Dans l’ensemble, notre projet s’est plus ou moins bien déroulé. En effet, nous avons eu pas mal de problèmes notamment au niveau du wifi comme expliqué précédemment mais aussi à d’autres niveau, principalement en ce qui concerne les Robotino puisque nous avons eu des problèmes de fusibles, de batterie et de clé wifi. Malgré cela, nous avons fini dans les temps tout en ayant progressé en programmation (Python) ou en réseau.

Au delà de cet approfondissement de nos connaissances en programmation et de notre initiation au réseau, ce projet nous a permis de développer un esprit d’équipe sur le long terme et d’effectuer un travail en autonomie sur une longue période.

En conclusion, malgré des hauts et des bas, ce fût un projet extrêmement intéressant malgré sa difficulté certaine et nous en tirons néanmoins un très bon souvenir.

 

Merci de nous avoir lu.

 

 

12499024_10207862073903312_1089619124_o

Jean-Michel, Loïc, Louis et Luigi