Polytech Projets Ge

p>. !https://forge.clermont-universite.fr/attachments/download/16022/lirmm_20160115130052_20160115130106.png! !https://forge.clermont-universite.fr/attachments/download/16023/polytech_logo_20160115125734_20160115125749.png!

p<. Projet GE4a-GE5a :

*Entreprise / Client* :

*Auteurs* : Jessy Louis - Priscille Ndombi - Joris Payen

*Responsable Projet* : Mr Sébastien Lengagne

*Tuteur industriel* : Mme Isabelle Goi 

    [[1. Résumé]] 

    [[2. Abstract]] 

    [[3. Introduction]] 

    [[4. Présentation du Sujet]] 

    [[5. Cahier des Charges]] 

        [[1. Spécifications du cahier des charges]] 

    [[6. Développement]] 

        [[1. Partie analogique]] 

       [[2. Communications microcontrôleur]] 

        [[3. Serveur Web - Raspberry - Arduino]] 

    [[7. Gestion de Projet]] 

        [[1. W.B.S.]] 

        [[2. Gantt]] 

    [[8. Bilan]] 

        [[1. Etat d'avancement]] 

        [[2. Analyse Critique]] 

        [[3. Perspectives]]

    [[9. Bibliographie]] 

    [[10. Documents]] 

    [[11. Notes d'application]] 

        [[1. Implantation du protocole CanOpen sur Arduino]] 

        [[2. Structure d'un programme de transfert USB <-> SPI]] 

        [[3. Chaine de conversion analogique numérique d'instrumentation]]

---

p=. %{color:red}Résumé%  

Dans le cadre de notre projet de fin d’étude en école d’ingénieur, nous avons eu à réaliser un projet proposé par le Département Génie Civil et par le laboratoire LIRMM (Laboratoire d’Informatique, de Robotique et de Microélectronique de Montpellier). Il s’agit de récupérer d’une part la valeur d’une déformation pour les travaux pratiques du département Génie Civil, et d’autre part récupérer la déformation d’une patte du robot hexapode RHEX pour le laboratoire LIRMM.

Mots clés :

Déformation

Acquisition de données

Liaison série

Serveur Web

Page Web 

---

p=. %{color:red}Abstract% 

As part of our project of end of study in engineering school, we had to implement a project proposed by the Department of Civil Engineering and the LIRMM laboratory (Laboratory of Informatics and Microelectronics of Montpellier). This is to recover the one hand the value of a strain for the Civil Engineering Department of the practical work, and also recover the deformation of a hexapod robot leg of RHEX LIRMM laboratory (Laboratory of Informatics and Microelectronics of Montpellier).

Key Words :

Deformation

Data acquisition

Serial link

Web server

Web page

---

p=. %{color:red}Introduction%

Pour le cas du laboratoire LIRMM, il s’agit d’un robot RHEX (Robot Hexapode) qui a six pattes en mouvement. L’année dernière un groupe de deux étudiants a réalisé un projet sur ce robot pour récupérer l’image de l’effort sur le robot et également traiter l’information de la déformation et de la stocker. C’est dans cette optique que nous avons continué ce projet en réutilisant les jauges de contraintes réalisées pour récupérer les données de déformations des pattes mais aussi de récupérer les angles de déplacements de la patte en mouvement à l'aide d'un encodeur.

Le département Génie Civil utilise un dispositif assez cher pour des plateformes de bancs d’essai de travaux pratiques. Le besoin s’est donc présenté dans le sens où il fallait réaliser un autre dispositif moins onéreux pour essentiellement récupérer les données de leurs capteurs de déformation. En d’autres termes, les étudiants effectuent des travaux pratiques sur des systèmes en acier, ils mesurent les déformations suivant l’effort exercé sur ces systèmes. Nous intervenons donc sur ses systèmes pour récupérer ces informations et les rendre disponible sur une page Web.

Dans les deux cas il nous faut réaliser un système d’acquisition des différentes déformations à partir des capteurs de déformations implantés sur les dispositifs (bancs d’essai et pattes du robot RHEX). 

---

p=. %{color:red}Présentation du Sujet%

Dans le cadre de la formation d’ingénieur Polytech CLERMONT-FERRAND, les élèves sont amenés à réaliser des projets industriels. Ces projets permettant de mettre en place nos connaissances techniques et d’acquérir les méthodes de la gestion de projet et de la communication en milieu professionnel. Ils nous permettent tout simplement de nous préparer au monde du travail.

Le projet proposé à notre équipe est de réaliser la mesure de déformation d’un système de test du département Génie Civil et également de réaliser un dispositif de mesure de déformations des pattes du robot RHEX, dispositif ayant quelques similarités avec la demande du département Génie Civil pour le laboratoire LIRMM.

p=. !https://forge.clermont-universite.fr/attachments/download/16024/robot_hexapode_20160115125921_20160115125941.png!

Afin de réaliser ce projet, nous avons eu besoin des connaissances du Génie Electrique mais aussi d’acquérir de nouvelles connaissances par exemple pour la création du serveur Web, la page Web etc.

Vous trouverez à travers ce dossier la description du besoin des deux clients, les solutions techniques utilisées. Vous pourrez également retrouver un recueil de résultats obtenus. 

---

p=. %{color:red}Cahier des Charges%

p(((. - Cahier des charges commun

Le cahier des charges commun imposé par les clients est de réaliser une carte électronique permettant d’acquérir, de numériser et de stocker les données de quatre capteurs dans le but de mesurer des déformations.

Traitement des données analogiques

Dans cette fonction, la problématique principale est de faire communiquer le convertisseur et le microcontrôleur. Il faudra donc paramétrer les différents registres et récupérer les données du convertisseur.

- Cahier des charges du Robot RHEX

La partie du laboratoire LIRMM est de récupérer les données de plusieurs jauges de déformation situées sur les six pattes du robot RHEX. Ces données doivent être synchronisées avec la position de la patte sur laquelle se trouvent les différentes jauges à l’aide d’un encodeur. Un Arduino a été imposé pour stocker les données ainsi que pour communiquer avec l’encodeur.

p(((. - Mesurer 4 déformations de 4 jauges de contrainte

p(((. - Envoi des données converties et aussi de l'angle des pattes (ce dernier est récupéré par un encodeur connecté à un Arduino)

p(((. - Budget

-Cahier des charges Construction

La partie du département Génie Civil est de récupérer les données d’un capteur à un instant mais la carte doit être générique, elle doit être capable de prendre en entrée quatre capteurs de nature différentes. Les différentes cartes doivent être synchronisées entre elles pour pouvoir faire le lien entre les différents capteurs. Une Raspberry Pi a été imposé par le client pour stocker les données et les rendre accessibles sur un serveur. Une page web sera réalisée dans le but de récupérer ces données mais également pour paramétrer et étalonner la carte.

p(((. - Mesurer 4 types de capteurs différents

p(((. - Envoi des données au Raspberry Pi

p(((. - Création du serveur

p(((. - Création de la page web

p(((. - Budget

p=. %{color:red}Spécifications du cahier des charges%  

Ces différentes spécifications constituent celles de la partie Construction du projet

p(((.  - Acquisition d'un canal par carte, type d'entrée à choisir par connectique / cavaliers / configurations ( données disponibles sur une même carte, mais pas en même temps). 

p(((. - 4 types de capteurs qui sont : signal tension +/-10V , ponts de jauges (ponts 350ohms, sensibilité nominale 2mV/V) , jauges de déformation (jauges 350 ohms) , signal courant 0-20mA. 

p(((.  - Résolution > 16bits effectifs dans toutes les conditions.

p(((. - Fréquence d'acquisition de 0 à 100Hz.

p(((. - Communication avec maitre (Raspberry PI ou un PC) pour la récupération des données.

p(((. - Lecture/écriture des registres du convertisseur pour la configuration de celui-ci.

p(((. - Lecture d'une valeur convertie sur demande.

p(((.  - Une entrée logique pour la synchro / déclenchement mesures.

p(((.  - Bloc mémoire (lecture/écriture par USB) >=128 octets (programmation référence de la carte, adresse de la carte, etc.) 

---

p=. %{color:red}Developpement%

Au début du projet, nous avons été confrontés à plusieurs problèmes dont :

p(((. - Etudes sur les types de capteurs que nous allions utiliser

p(((. - La manière dont nous allions récupérer les données du convertisseur.

p(((. - L’accessibilité aux données converties sur un serveur Web

Nous avons posé ces différentes problématiques car ce sont ces dernières qui nous permettront de répondre au cahier des charges qui nous a été présenté.

C'est pour cela que nous avons réparti la résolution de nos problèmes en trois parties principales qui vont se compéter pour nous permettre de résoudre tout nos problèmes. 

---

p=. %{color:red}Partie analogique%

p((((. %{color:red}a. Problématique:%

Dans cette partie, la partie analogique va être présentée, c'est-à-dire des capteurs jusqu'au convertisseur. Différents types de capteurs sont à prendre en compte, un pont de jauges de contraintes complet (+/-5mV), une jauge de contrainte (350Ω), +/- 10V et 0…20mA. Ces 4 capteurs sont utilisés pour le projet Construction tandis que pour le projet RHEX, seul la jauge de déformation sera utilisée. Tous ces signaux sont adaptés en une même tension pour ensuite pouvoir la traiter. Il reste ensuite à choisir les composants et les tester pour vérifier leur bon comportement. Un multiplexeur est placé juste après l’adaptation des capteurs pour effectuer le choix de ces derniers. L’ADC choisi est un AD7176-2 car une résolution supérieure à 16 bits est demandée.

p((((. %{color:red}b. Etude d'une solution théorique:% 

p((((. - Adaptation des différents capteurs

Nous avons fait le choix d’adapter les différents signaux des capteurs en une tension de +/- 10V car cela simplifie l’adaptation pour l’ADC et nous avons également un capteur qui nous délivre directement cette tension. Cela nous évite d’ajouter des composants et réduit donc le coût de la carte.

Pour le premier capteur +/- 10V, nous n’avons pas besoin d’adapter le signal comme expliqué ci-dessus. Un amplificateur suiveur est placé juste après le multiplexeur et joue le rôle d’adaptateur d’impédance quel que soit le capteur choisi.

Pour le pont de jauges, une amplification à 2 étages est effectuée pour limiter le bruit car le gain final est de 2000. Le premier étage est un amplificateur différentiel car le signal mesuré est une tension non référencée par rapport à la masse. Cet amplificateur différentiel a également un gain de 20. De ce fait, il reste à réaliser une amplification avec un gain de 100, qui est réalisée par un amplificateur non-inverseur. Un potentiomètre est mis en place dans le but de compenser les offset des deux AOP.

En ce qui concerne la jauge de contrainte, il faut créer le reste du pont sur la carte électronique. Ceci est effectué avec trois résistances de précision de la même valeur que la jauge, c’est-à-dire 350Ω à +/- 0,1%. Une fois le pont crée, une tension de mesure de +/- 1,25mV peut être récupérée car c’est un quart de pont et non un pont complet. Ensuite l’adaptation s’effectue de la manière que pour le pont complet à la petite différence que l’amplificateur différentiel a un gain de 80 cette fois-ci.

Le dernier capteur nous délivre un courant qui varie de 0 à 20mA. L’image de ce signal est obtenue grâce à la loi d’Ohm. Le courant circulera dans une résistance de 500Ω, cette valeur à était choisie car cela permet d’avoir une plage de tension de 0 à 10V.

Ces quatre signaux sont chacun connectés à une entrée du multiplexeur.

p((((. - Adaptation des signaux pour l’ADC

Comme dit ci-dessus, le début de cette partie commence à la sortie du MUX. Pour ne pas avoir de problèmes avec les différentes impédances, un amplificateur suiveur est placé à la sortie du multiplexeur. Pour rappel, le signal à la sortie de ce composant est une tension +/- 10V.

Une fois la qualité du signal assurée, la partie adaptation peut commencer. Etant donné que l’ADC prend en entrée une tension de 0 à 5V, il faut donc diminuer la tension de sortie ainsi qu’ajouter un offset. Un driver de l’ADC est proposé dans sa datasheet qui correspond parfaitement à la demande.

p((((. - Création des cartes

Une première carte de Debug a été réalisée premièrement dans le but de tester le bon fonctionnement des différents composants. Cette carte n’avait aucune contrainte de taille, le seul souhait était qu’elle soit fonctionnelle.

Les deux autres cartes avaient certains points communs à la base mais le projet avançant, plusieurs différences sont apparues pour diverses raisons. La première étant la contrainte de place car le reste du pont qui est créé sur la carte doit être au plus près de cette dernière. La raison est que la déformation est mesurée grâce à une différence de résistance, et si la longueur des connecteurs est trop importante, la mesure sera faussée. Donc la carte doit être placée à l’intérieur de la patte du robot pour créer une cage de Faraday et avoir moins de soucis de CEM (compatibilité électromagnétique). L’isolation galvanique prévue à donc était supprimée, la communication avec l’ADC qui devait être gérée par un PIC, va être gérée par un arduino (uniquement pour le projet RHEX). Les alimentations sont également différentes, pour le projet Construction seul l’USB gère l’alimentation et les différentes tensions sont réalisées à l’aide de convertisseurs. Pour le projet RHEX, l’alimentation est faite par des alimentations extérieures toujours dans un souci de place.

Le développement CAO des cartes a été effectué sur Proteus. Tous les schémas électriques ainsi que les cartes se trouvent dans la documentation technique. 

---

p=. %{color:red}Communications microcontrôleur%

p((((. %{color:red}a. Problématique:% 

Pour permettre les conversions par notre ADC, nous devons lui demander de réaliser ces opérations. En d'autres termes nous devons commander le fonctionnement de l'ADC. C'est pour cela que nous avons choisi d'utiliser un microcontrôleur. Celui que nous avons choisi est celui que nous utilisons en cours d'informatique le PIC18F550. Ce dernier a pourtant un convertisseur intégré mais nous ne pouvons pas l'utiliser car la résolution qu'on nous demande est supérieure à 16 bits et le convertisseur intégré ne peut pas réaliser cette contrainte.

p((((. %{color:red}b.  Etude d'une solution théorique:%

p(((((. Fonctionnement du PIC18F4550 :

Les microcontrôleurs PIC sont relativement peu coûteux et faciles à trouver, il y a aussi d'autres microcontrôleurs comme « Arduino » qui conviendront parfaitement. Mais le PIC18F est facilement disponible et très puissant comme microcontrôleur, il est permet d'ajouter facilement un peu de logique et d’intelligence pour les projets.

C'est une unité de traitement et d’exécution de l'information à laquelle on a ajouté des périphériques internes permettant de réaliser des montages sans nécessiter l’ajout de composants annexes. Un microcontrôleur PIC peut donc fonctionner de façon autonome après programmation.

Pour la programmation de ce dernier nous allons coder en C sur le logiciel MPLABX qui est un simulateur fourni par Microchip pour en effet visualiser le résultat de notre code. La programmation de ce PIC se fera in-situ car nous allons connecter notre PIC à un Pickit3? pour effectuer ce debuggage et charger le programme dans le microcontrôleur. 

p(((((. Liaison SPI : (liaison entre le convertisseur et le PIC18F4550)

Ce protocole de communication a été défini dans notre cahier de charge par rapport au convertisseur. Le port synchrone SPI (Serial Peripheral Interface) est un port série synchrone. Il permet de communiquer sur 3 fils avec un certain nombre de périphériques. La synchronisation est assurée par le processeur. C'est donc avec le codage de ce protocole que la liaison entre

Les caractéristiques essentielles sont:

• rapidité.

• robustesse ( peu sensible aux interférences).

• peu de fils ou de traces à router.

Le mode de fonctionnement SPI que nous avons utilisé est le suivant :

• Master mode: Le microcontrôleur contrôle l'horloge

Les broches du microcontrôleur utilisées sont:

• Serial Data Out: SDO/RC5

• Serial Data In: SDI/RC4

• Serial Clock: SCK/RC3

• Une 4ème broche peut être utilisée comme Chip Select en mode Slave:

Slave select \SS/RA5.

p(((((. - Etude des registres du convertisseur permettant d'accéder aux données converties

Le convertisseur qui va nous transférer les données est le AD7176 , il respecte le cahier des charges car notre résolution est de 16bits.  

p=. !https://forge.clermont-universite.fr/attachments/download/16025/AD7176_20160115122803_20160115122828.jpg!

Nous avons donc dû étudier les registres de cet ADC qu'il fallait initialiser pour permettre une communication avec le microcontrôleur.

Ces registres sont les suivants :

Registre de communication : COMMS. Il est en écriture et doit être initialisé à chaque communication.

Le bit WEN barre doit être mis à l’état bas pour commencer toute forme de communication. Le bit R/W (0 : en mode écriture, 1 : en mode lecture). La séquence RA détermine quel registre sur lequel on communique avec.

Status register : registre en mode lecture, il permet de connaître l’état du convertisseur.

RDY : bit qui va déterminer s’il y’a une nouvelle donnée disponible et s’il est en attente d’une donnée.

CHANNEL : permet de lire sur quelle chaîne de conversion on est exactement.

ADC MODE REGISTER (ADC MODE) Registre qui contrôle le mode dans lequel on travaille. Il est en mode écriture et lecture. ¨Pour notre convertisseur on est en mode Single Conversion Mode. Le delay est à 0. Le bit SING_CYC doit est mis à 1 parce qu’on utilise qu’une seule chaîne de conversion.

Serial Interface Register : Il permet de configurer les différentes options d’interface.

Data Register : Le registre de donnée contient le résultat de la conversion de l’ADC. 24 bits de données. La lecture du registre de donnée apporte le bit RDY, et la broche à l’état haut si elle était à l’état bas. L’ADC ne pourra pas lire une autre donnée si le registre de donnée est en pleine lecture.

GPIO Configuration : Ce registre contrôle l'usage général broches Entrée / Sortie de l'ADC.

p(((. - Communication USB :

Lorsque les données sont récupérées il faut les envoyer au serveur et pour cela nous avons choisi d’utiliser un mini PC appelé Rasberry Pi qui va contrôler le PIC en tant que maître de ce dernier. Il va lui envoyer des demandes de récupération des données converties.

Pour communiquer entre la Raspberry Pi et la carte microcontrôleur qui aura reçu les données converties, nous avons choisi d'utiliser le protocole USB (Universal Serial Bus). Microchip fournit déjà un code de base permettant d'utiliser le protocole USB sur certain microcontrôleur et on a pu trouver celui de notre microcontrôleur : PIC18F4550.

Ce protocole permet de faire communiquer deux composants à travers 4 fils : VCC, VDD, D+ et D-. Les données transitent en passant par les broches D+ et D-. 

---

p=. %{color:red}Serveur Web - Raspberry PI - Arduino%

---

p=. %{color:red}Gestion de Projet%

---

p=. %{color:red}W.B.S%

p=. !https://forge.clermont-universite.fr/attachments/download/16026/WBS_20160114201926_20160114201955.png!

p=. %{color:red}Gantt%

La présentation du GANTT est séparée en trois partie comme les trois parties du sommaire car il n'était pas lisible autrement.

En couleurs se trouve le Gantt prévisionnel et en blanc rayé le Gantt réel.

Pour la partie analogique, le retard a été pris au niveau de la sous-traitance car le cahier des charges avait mal était conçu à la base. Ce n'est pas évident de constituer un cahier des charges comme le client le pense, et surtout de la faire comprendre à son sous-traitant.

p=. !https://forge.clermont-universite.fr/attachments/download/16027/GanttAnalogique_20160114203252_20160114204357.png!

Pour la programmation microcontrôleur il y'a eu beaucoup de retard sur la validation du fonctionnement du programme concernant la partie SPI, en effet il y'a eu un gros problème dès le début pour la gestion du temps. Cela nous fait comprendre réellement que suivre les jalons qu'on se fixe n'est pas évident à respecter mais pour cela il faut prendre rapidement des initiatives pour trouver des solutions qui permettrait de ne pas se retrouver à la fin du projet sans un résultat conséquent.

p=. !https://forge.clermont-universite.fr/attachments/download/16028/GanttCommunication_20160114203252_20160114203428.png!

p=. !https://forge.clermont-universite.fr/attachments/download/16029/GanttArduino_20160114203252_20160114203441.png!

---

p=. %{color:red}Bilan%

---

p=. %{color:red}Etat d'avancement%

---

p=. %{color:red}Analyse Critique% 

---

p=. %{color:red}Perspectives% 

---

p=. %{color:red}Bibliographie%

---

p=. %{color:red}Documents% 

Première présentation ge4a : P1.pdf?

Revue d'appel d'offre ge4a : RAO.pdf?

Rapport fin ge4a : RapportGe4a.pdf?

Revue de lancement ge5a : P3.pdf?

Revue d'avancement ge5a : P4.pdf?

Revue de Projet ge5a : RP.pdf?

Soutenance de Projet ge5a : S.pdf?

Poster Ge5a? : Poster.pdf?

Archives contenant les codes sources des programmes : code.zip?

Archives contenant la C.A.O. : cao.zip?

---

 *Notes d'application*

Le nom du fichier doit contenir votre nom.

 Implantation du protocole CanOpen? sur Arduino

note_application_LOUIS.pdf?

 Structure d'un programme de transfert USB <-> SPI

Note d'application de Mme NDOMBI

 Chaine de conversion analogique numérique d'instrumentation

Note d'application de M. PAYEN