Wiki d'activités IMA - Contributions de l’utilisateur [fr]

Projets IMA5 2014/2015

2015-03-03T23:15:33Z

Vvergez : Ajout lien via fichier wiki

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

== Répartition des binômes ==

<table border="1">
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<tr>
<td>[[P1 Modélisation et commande de l'auto-ignition d'un moteur HCCI]]</td>
<td>Moulé Alexandre / Taché Clément </td>
<td> Anne-Lise Gehin / Jean-Yves Dieulot </td>
<td>[[Fichier:Rapport decembre moule tache.pdf]] </td>
<td>[[Fichier: RapportFinPFE.pdf]]</td>
</tr>
<tr><td>[[P5 Filtrage des indicateurs numériques de diagnostic]]</td>
<td> ZIOU Ismaïl / HAMZAOUI Oussama </td>
<td> Belkacem Ould Bouamama </td>
<td>[[Fichier:rapport_Z.pdf]]</td>
<td>[[Fichier:Rapport PFE ZIOU HAMZAOUI.pdf]]</td>
</tr>
<tr>
<td>[[P6 Gestion des flux thermiques du bâtiment Polytech]]</td>
<td>Florian Royer / Zohour Assaieb </td>
<td> Belkacem Ould Bouamama </td>
<td> [[Fichier:Rapport_Intermédiaire_Royer_Assaieb.pdf]] </td>
<td> [[Fichier:Rapport_Final_PFE_ProjetP6.pdf]] </td>
</tr>
<tr><td>[[P7 Utilisation d'un Robot Nao pour les enfants autistes]]</td>
<td> Rodriguez Loïc/Ismaïl Tahry</td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Projetpfenaomi.pdf]]</td>
<td>[[Fichier:Rapport PFE RodriguezTahry.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P8 Pilulier]]</td>
<td> Alexandre Mercier / Emile Pinet</td>
<td> Thomas VANTROYS / Alexandre BOE </td>
<td>[[Fichier:Rapport decembre PFE pilulier mercier pinet.pdf]]</td>
<td>[[Fichier:Rapport PFE Pinet Mercier.pdf]]</td>
</tr>
<tr><td>[[P9 Agenda pour personnes non lectrices]]</td>
<td> Cédric DESPREZ & Soufiane HADDAOUI </td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Rapport_MiSoutenance_DESPREZ_HADDAOUI.pdf]]</td>
<td>[[Fichier:RapportFinal_Desprez-Haddaoui.pdf‎]]</td>
</tr>
<tr><td>[[P11 Détecteur d'obstacles pour fauteuils électriques]]</td>
<td> Geoffrey ROSE / Marjorie TIXIER </td>
<td> GAPAS / Blaise Conrard </td>
<td> [[Fichier:Rapport_Intermédiaire_PFE_GAPAS_Rose_Tixier.pdf]]</td>
<td> [[Fichier: Rapport_PFE_Rose_Tixier.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P12 Automatiser à l'aide d'une interface LabView la procédure de mesure de conductivité électrique d'un alternateur à griffes]]</td>
<td> Hugo FONDU </td>
<td> Abdelkader Benabou </td>
<td>[[Fichier:rapport_presoutenance.pdf]]</td>
<td>[[Fichier:Rapport soutenance Fondu.pdf]]</td>
<td>[[Fichier:Video projet Fondu.avi]]</td>
<td></td>
</tr>
<tr><td>[[P13 Construction d'un support motorisé pour la réalisation des essais de décharges électrostatique]]</td>
<td> JEBBARI Zineb / BEKRAOUI Oumaima </td>
<td> Nathalie Rolland </td>
<td> [[Fichier:rapportJebbek.pdf]] </td>
<td> [[Fichier:rapport-final-jebbek.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P19 Contrôle et synchronisation d'instruments en microscopie]]</td>
<td> Simon Duthoit</td>
<td> Samuel Hym </td>
<td></td>
<td>[[Fichier:RapportPFESimonDuthoit.pdf]]</td>
</tr>
<tr><td>[[P21 Balise Bluetooth Low Energy]]</td>
<td> Kévin CHALONO / Armagan YAMNAZ</td>
<td> Thomas VANTROYS </td>
<td> [[ Fichier:ProjetBLE 1 pdf.pdf]]</td>
<td></td>
<td></td>
</tr>
<tr><td>[[P21 Bis Prototypage d'interactions localisées et contextualisées ]]</td>
<td> Olivier Tailliez</td>
<td> Thomas Vantroys / Yvan Peter </td>
<td></td>
<td>[[Fichier: PFE_Olivier_Tailliez.pdf‎]]</td>
</tr>
<tr><td>[[P22 Google Glass en logistique ]]</td>
<td> Jérémy Gondry / Vincent Meunier </td>
<td> Laurent Grisoni </td>
<td>[[Fichier:Rapport_intermediaire_Gondry_Meunier.pdf]]</td>
<td>[[Fichier:Rapport_final_PFE_Meunier_Gondry.pdf]]</td>
</tr>
<tr><td>[[P24 Robot de surveillance domestique]]</td>
<td> Sébastien DELTOMBE </td>
<td> Xavier Redon </td>
<td>[[Fichier:Rapport_PFE_P24_Deltombe.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P25 SmartMeter]]</td>
<td> Thomas Ederlé / Sylvain Fossaert</td>
<td> Guillaume Renault / Xavier Redon / Alexandre Boé </td>
<td> [[Fichier:RapportFossaertEderle.pdf]] </td>
<td> [[Fichier:RapportEderleFossaert.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P26 Vehicule Electrique ]]</td>
<td> Smain Labdouni / Adnane Jaoui </td>
<td> Arnaud Chielens / Philippe Delarue </td>
<td> [[Fichier:RAPPORT_VE_DEC.pdf]]</td>
<td> [[Fichier:Rapport_pfe_Jaoui_Labdouni_Fevrier.pdf]] </td>
</tr>
<tr><td>[[P27 Controle Direct de Puissance d'un Convertisseur Matriciel ]]</td>
<td> Quentin Pesqueux / Nicolas Alexandre </td>
<td> Philippe Delarue </td>
<td> [[Fichier:PFE_IMA5_MATRIX_CONVERTER_Alexandre_Pesqueux.pdf]]</td>
<td> [[Fichier:Rapport_PFE_Alexandre_Pesqueux.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle]]</td>
<td> Charlotte BRICOUT / Nathan MARTIN </td>
<td> Jérémie DEQUIDT</td>
<td> [[Fichier:-BRICOUT MARTIN--Rapport PFE.pdf]] </td>
<td> [[Fichier:Rapport PFE VF.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P33 Ligthing contactless / "wireless"]]</td>
<td> Benjamin Lafit </td>
<td> Alexandre Boé </td>
<td> [[Fichier:Rapport_Benjamin_Lafit.pdf]] </td>
<td> [[Fichier:Rapport_Final_Benjamin_Lafit.pdf‎]]</td>
<td></td>
</tr>
<tr><td>[[P35 Hack-a-Wii : Emulation de wiimote pour rendre la Wii accessibles aux personnes handicapées ]]</td>
<td> Fabien Violier </td>
<td> Laurent Grisoni </td>
<td> </td>
<td></td>
</tr>
<tr><td>[[P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA ]]</td>
<td> Jérôme Vaessen </td>
<td> Julien Cartigny / Pierrick Buret </td>
<td> [[Fichier:Rapport_VAESSEN_presoutenance.pdf‎]] </td>
<td> [[Fichier:Rapport_PFE_P37_VAESSEN_finale.pdf‎]] </td>
<td></td>
</tr>
<tr><td>[[P44 Création d'un systeme domotique sans fil ]]</td>
<td> Benoit MALIAR / Thomas MAURICE</td>
<td> Pierrick BURET / Thomas VANTROYS </td>
<td> [[Fichier:RapportMaliarMauriceDecembre.pdf]] </td>
<td> [[Fichier:Rapport_final_Maliar_Maurice.pdf]]</td>
</tr>
<tr><td>[[P45 Aide à la navigation d'un véhicule autonome]]</td>
<td> Pierre APPERCÉ</td>
<td> Rochdi MERZOUKI </td>
<td>[[Fichier:Rapport_Mi-PFE_Apperce_Pierre.pdf|alt=Rapport intermédiaire du PFE]]</td>
<td>[[Fichier:Rapport_PFE_Appercé_Pierre.pdf|alt=Rapport du PFE]]</td>
<td>[[Fichier:Video_PFE_wiki.avi‎|alt=Video de présentation de PFE]]</td>
</tr>
<tr><td>[[P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens]]</td>
<td> Valentin VERGEZ</td>
<td> Rochdi MERZOUKI </td>
<td>[https://drive.google.com/file/d/0BzEs72ClJBLRTVBfZ09RYmpWYnM/view?usp=sharing Rapport intermédiaire]</td>
<td>[https://drive.google.com/file/d/0BzEs72ClJBLRTHVwZ2RrQmdwNkU/view?usp=sharing Rapport final]</td>
<td>[[Fichier:VidPFE_ValentinVERGEZ_web.mp4]] OU [https://drive.google.com/file/d/0BzEs72ClJBLRWnNELVZ1MEtIRzQ/view?usp=sharing Video (via Google Drive)]</td>
</tr>
<tr><td>[[P57 CHRU Lille : Smart Picking]]</td>
<td> Mathieu Bossennec / Florian Caron</td>
<td> Gwénaëlle Maton / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Rapport-PFE-SmartPicking-Intermediaire.pdf‎]] </td>
<td> [[Fichier:Rapport-PFE-BOSSENNEC_CARON-SmartPicking.pdf‎]] </td>
</tr>
<tr>
<td>[[P58 Transformation des spectateurs d’un concert en afficheur géant interactif]]</td>
<td> Hautecoeur Mélanie </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td>[[Fichier : PFE_Rapport_Hautecoeur_Melanie.pdf‎]]</td>
</tr>
<tr><td>[[P59 Assistance globale pour aide au parking]]</td>
<td> Mathieu GERIER / Céline LY </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td>[[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf]]‎</td>
<td>[[Fichier:Rapport_projet_GERIER_LY.pdf]]</td>
</tr>
</table>

Fichier:VidPFE ValentinVERGEZ web.mp4

2015-03-03T23:10:49Z

Vvergez : Video de PFE IMA5 2015 - Valentin VERGEZ Simulateur Temps Réel d'un Environement de Robots Autonomes Logisticiens

Video de PFE IMA5 2015 - Valentin VERGEZ
Simulateur Temps Réel d'un Environement de Robots Autonomes Logisticiens

Projets IMA5 2014/2015

2015-03-03T23:06:24Z

Vvergez : Ajouts des liens de rapports et de vidéo

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

== Répartition des binômes ==

<table border="1">
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<tr>
<td>[[P1 Modélisation et commande de l'auto-ignition d'un moteur HCCI]]</td>
<td>Moulé Alexandre / Taché Clément </td>
<td> Anne-Lise Gehin / Jean-Yves Dieulot </td>
<td>[[Fichier:Rapport decembre moule tache.pdf]] </td>
<td>[[Fichier: RapportFinPFE.pdf]]</td>
</tr>
<tr><td>[[P5 Filtrage des indicateurs numériques de diagnostic]]</td>
<td> ZIOU Ismaïl / HAMZAOUI Oussama </td>
<td> Belkacem Ould Bouamama </td>
<td>[[Fichier:rapport_Z.pdf]]</td>
<td>[[Fichier:Rapport PFE ZIOU HAMZAOUI.pdf]]</td>
</tr>
<tr>
<td>[[P6 Gestion des flux thermiques du bâtiment Polytech]]</td>
<td>Florian Royer / Zohour Assaieb </td>
<td> Belkacem Ould Bouamama </td>
<td> [[Fichier:Rapport_Intermédiaire_Royer_Assaieb.pdf]] </td>
<td> [[Fichier:Rapport_Final_PFE_ProjetP6.pdf]] </td>
</tr>
<tr><td>[[P7 Utilisation d'un Robot Nao pour les enfants autistes]]</td>
<td> Rodriguez Loïc/Ismaïl Tahry</td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Projetpfenaomi.pdf]]</td>
<td>[[Fichier:Rapport PFE RodriguezTahry.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P8 Pilulier]]</td>
<td> Alexandre Mercier / Emile Pinet</td>
<td> Thomas VANTROYS / Alexandre BOE </td>
<td>[[Fichier:Rapport decembre PFE pilulier mercier pinet.pdf]]</td>
<td>[[Fichier:Rapport PFE Pinet Mercier.pdf]]</td>
</tr>
<tr><td>[[P9 Agenda pour personnes non lectrices]]</td>
<td> Cédric DESPREZ & Soufiane HADDAOUI </td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Rapport_MiSoutenance_DESPREZ_HADDAOUI.pdf]]</td>
<td>[[Fichier:RapportFinal_Desprez-Haddaoui.pdf‎]]</td>
</tr>
<tr><td>[[P11 Détecteur d'obstacles pour fauteuils électriques]]</td>
<td> Geoffrey ROSE / Marjorie TIXIER </td>
<td> GAPAS / Blaise Conrard </td>
<td> [[Fichier:Rapport_Intermédiaire_PFE_GAPAS_Rose_Tixier.pdf]]</td>
<td> [[Fichier: Rapport_PFE_Rose_Tixier.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P12 Automatiser à l'aide d'une interface LabView la procédure de mesure de conductivité électrique d'un alternateur à griffes]]</td>
<td> Hugo FONDU </td>
<td> Abdelkader Benabou </td>
<td>[[Fichier:rapport_presoutenance.pdf]]</td>
<td>[[Fichier:Rapport soutenance Fondu.pdf]]</td>
<td>[[Fichier:Video projet Fondu.avi]]</td>
<td></td>
</tr>
<tr><td>[[P13 Construction d'un support motorisé pour la réalisation des essais de décharges électrostatique]]</td>
<td> JEBBARI Zineb / BEKRAOUI Oumaima </td>
<td> Nathalie Rolland </td>
<td> [[Fichier:rapportJebbek.pdf]] </td>
<td> [[Fichier:rapport-final-jebbek.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P19 Contrôle et synchronisation d'instruments en microscopie]]</td>
<td> Simon Duthoit</td>
<td> Samuel Hym </td>
<td></td>
<td>[[Fichier:RapportPFESimonDuthoit.pdf]]</td>
</tr>
<tr><td>[[P21 Balise Bluetooth Low Energy]]</td>
<td> Kévin CHALONO / Armagan YAMNAZ</td>
<td> Thomas VANTROYS </td>
<td> [[ Fichier:ProjetBLE 1 pdf.pdf]]</td>
<td></td>
<td></td>
</tr>
<tr><td>[[P21 Bis Prototypage d'interactions localisées et contextualisées ]]</td>
<td> Olivier Tailliez</td>
<td> Thomas Vantroys / Yvan Peter </td>
<td></td>
<td>[[Fichier: PFE_Olivier_Tailliez.pdf‎]]</td>
</tr>
<tr><td>[[P22 Google Glass en logistique ]]</td>
<td> Jérémy Gondry / Vincent Meunier </td>
<td> Laurent Grisoni </td>
<td>[[Fichier:Rapport_intermediaire_Gondry_Meunier.pdf]]</td>
<td>[[Fichier:Rapport_final_PFE_Meunier_Gondry.pdf]]</td>
</tr>
<tr><td>[[P24 Robot de surveillance domestique]]</td>
<td> Sébastien DELTOMBE </td>
<td> Xavier Redon </td>
<td>[[Fichier:Rapport_PFE_P24_Deltombe.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P25 SmartMeter]]</td>
<td> Thomas Ederlé / Sylvain Fossaert</td>
<td> Guillaume Renault / Xavier Redon / Alexandre Boé </td>
<td> [[Fichier:RapportFossaertEderle.pdf]] </td>
<td> [[Fichier:RapportEderleFossaert.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P26 Vehicule Electrique ]]</td>
<td> Smain Labdouni / Adnane Jaoui </td>
<td> Arnaud Chielens / Philippe Delarue </td>
<td> [[Fichier:RAPPORT_VE_DEC.pdf]]</td>
<td> [[Fichier:Rapport_pfe_Jaoui_Labdouni_Fevrier.pdf]] </td>
</tr>
<tr><td>[[P27 Controle Direct de Puissance d'un Convertisseur Matriciel ]]</td>
<td> Quentin Pesqueux / Nicolas Alexandre </td>
<td> Philippe Delarue </td>
<td> [[Fichier:PFE_IMA5_MATRIX_CONVERTER_Alexandre_Pesqueux.pdf]]</td>
<td> [[Fichier:Rapport_PFE_Alexandre_Pesqueux.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle]]</td>
<td> Charlotte BRICOUT / Nathan MARTIN </td>
<td> Jérémie DEQUIDT</td>
<td> [[Fichier:-BRICOUT MARTIN--Rapport PFE.pdf]] </td>
<td> [[Fichier:Rapport PFE VF.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P33 Ligthing contactless / "wireless"]]</td>
<td> Benjamin Lafit </td>
<td> Alexandre Boé </td>
<td> [[Fichier:Rapport_Benjamin_Lafit.pdf]] </td>
<td> [[Fichier:Rapport_Final_Benjamin_Lafit.pdf‎]]</td>
<td></td>
</tr>
<tr><td>[[P35 Hack-a-Wii : Emulation de wiimote pour rendre la Wii accessibles aux personnes handicapées ]]</td>
<td> Fabien Violier </td>
<td> Laurent Grisoni </td>
<td> </td>
<td></td>
</tr>
<tr><td>[[P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA ]]</td>
<td> Jérôme Vaessen </td>
<td> Julien Cartigny / Pierrick Buret </td>
<td> [[Fichier:Rapport_VAESSEN_presoutenance.pdf‎]] </td>
<td> [[Fichier:Rapport_PFE_P37_VAESSEN_finale.pdf‎]] </td>
<td></td>
</tr>
<tr><td>[[P44 Création d'un systeme domotique sans fil ]]</td>
<td> Benoit MALIAR / Thomas MAURICE</td>
<td> Pierrick BURET / Thomas VANTROYS </td>
<td> [[Fichier:RapportMaliarMauriceDecembre.pdf]] </td>
<td> [[Fichier:Rapport_final_Maliar_Maurice.pdf]]</td>
</tr>
<tr><td>[[P45 Aide à la navigation d'un véhicule autonome]]</td>
<td> Pierre APPERCÉ</td>
<td> Rochdi MERZOUKI </td>
<td>[[Fichier:Rapport_Mi-PFE_Apperce_Pierre.pdf|alt=Rapport intermédiaire du PFE]]</td>
<td>[[Fichier:Rapport_PFE_Appercé_Pierre.pdf|alt=Rapport du PFE]]</td>
<td>[[Fichier:Video_PFE_wiki.avi‎|alt=Video de présentation de PFE]]</td>
</tr>
<tr><td>[[P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens]]</td>
<td> Valentin VERGEZ</td>
<td> Rochdi MERZOUKI </td>
<td>[https://drive.google.com/file/d/0BzEs72ClJBLRTVBfZ09RYmpWYnM/view?usp=sharing Rapport intermédiaire]</td>
<td>[https://drive.google.com/file/d/0BzEs72ClJBLRTHVwZ2RrQmdwNkU/view?usp=sharing Rapport final]</td>
<td>[https://drive.google.com/file/d/0BzEs72ClJBLRWnNELVZ1MEtIRzQ/view?usp=sharing Vidéo]</td>
</tr>
<tr><td>[[P57 CHRU Lille : Smart Picking]]</td>
<td> Mathieu Bossennec / Florian Caron</td>
<td> Gwénaëlle Maton / Alexandre Boé / Thomas Vantroys </td>
<td> [[Fichier:Rapport-PFE-SmartPicking-Intermediaire.pdf‎]] </td>
<td> [[Fichier:Rapport-PFE-BOSSENNEC_CARON-SmartPicking.pdf‎]] </td>
</tr>
<tr>
<td>[[P58 Transformation des spectateurs d’un concert en afficheur géant interactif]]</td>
<td> Hautecoeur Mélanie </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td>[[Fichier : PFE_Rapport_Hautecoeur_Melanie.pdf‎]]</td>
</tr>
<tr><td>[[P59 Assistance globale pour aide au parking]]</td>
<td> Mathieu GERIER / Céline LY </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td>[[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf]]‎</td>
<td>[[Fichier:Rapport_projet_GERIER_LY.pdf]]</td>
</tr>
</table>

P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens

2015-02-24T09:00:03Z

Vvergez : /* Downloads */

== Downloads ==
[https://drive.google.com/file/d/0BzEs72ClJBLRTVBfZ09RYmpWYnM/view?usp=sharing Rapport intermédiaire] 
[https://drive.google.com/open?id=0BzEs72ClJBLRTHVwZ2RrQmdwNkU&authuser=0 Rapport final]

== Présentation du projet ==
Pour bien comprendre l'objet de ce projet, il faut savoir où sont nés les besoins.
Depuis l'année scolaire 2013/2014, des membres de Polytech Lille ont entrepris de participer à la Logistic League de la Robocup. 
La Robocup est une compétition internationale de Robotique, ayant pour but d'encourager le développement des robots autonomes. Historiquement la Robocup présente des compétitions de robots footballeurs, l'objectif initial étant d'obtenir une équipe de robots capable de rivaliser avec une équipe humaine. 
Depuis sa création, la Robocup a pris beaucoup d'ampleur et héberge maintenant - en plus de ses différentes leagues de football - des leagues orientés autour du secours, de la maison ou encore de la logistique. 

C'est cette league logistique qui nous intéresse. Créée et supportée par l'entreprise Festo, elle vise à représenter un environnement logistique de plus en plus autonome. 

Le travail se concentre principalement sur les Robotinos de Festo, des robots mobiles holonomes. Ces robots doivent évoluer par équipes de trois, deux équipes adverses à la fois, sur un terrain représentant un environnement de production. 
Leur rôle est d'optimiser la production du site en gérant les différentes machines de fabrication de produits et en s'adaptant à leur environnement. 
L'utilisation des machines est très simplifié, la majeure partie du travail se concentre finalement autour de la compréhension de l'environnement et de la stratégie de production. 

Une grande partie de l'appréhension de l'environnement par les robots est faite par vision. La vision par ordinateur est une chose complexe, l'un des besoin est donc d'obtenir un traitement d'image efficace et robuste. 

La stratégie elle, nécessite un nombre important de tests. 
Il est très coûteux de reproduire l’environnement de compétition complet, il faut avoir l'espace nécessaire pour l'installer. Il faudrait aussi deux fois plus de robots pour représenter l'équipe adverse et le matériel s'userait rapidement à cause de l'utilisation intense. 
Il est assez évident qu'un outil de simulation, sans être absolument nécessaire, serait un grand avantage. 

== Présentation des outils ==
Pour répondre à ces besoins, plusieurs outils sont utilisés. Les trois principaux sont ROS, V-REP et OpenCV.
=== ROS (Robot Operating System) - Framework pour applications de robotique ===
ROS, est une collection d'outils permettant le développement efficace et surtout rapide d'application de robotique. 
Partant du constat que les applications de robotique sont souvent similaires et que l'on y retrouve les même besoins, Open Source Robotics Foundation a lancé ROS, un projet open source qui permettrait aux roboticiens de développer leur logiciels de robotique à partir d'une base solide et standard. 
Depuis l'idée de départ jusqu'à aujourd'hui, ROS a rencontré un franc succès au point d'être pour ainsi dire une référence dans le domaine. 

Son concept de base est très intéressant car il permet de concevoir son système logiciel sous forme de plusieurs petits nœuds "indépendants". Indépendants ne veux pas dire isolés, les nœuds peuvent communiquer entre eux par plusieurs moyens de communications très complets. Mais leur développement lui peut-être réalisé indépendamment du reste de l'application. 

C'est très satisfaisant d'un point de vue du travail collaboratif premièrement, mais aussi pour le diagnostique d'erreur. Un système découpé en sous-systèmes est bien plus facile à maintenir. 
Mais c'est surtout très intéressant pour la partie qui va suivre, la simulation. 

ROS est l'environnement utilisé pour tout l'applicatif embarqué sur les Robotinos de l'équipe de Polytech Lille. Il sera donc un outil incontournable pour ce projet. 

=== V-Rep - Simulateur de robotique temps réel ===
V-REP, le simulateur de Coppelia Robotics, se définit comme le couteau suisse de la simulation robotique. C'est un logiciel Open Source, gratuit pour une utilisation non commerciale et assez récent. 
Il est toutefois déjà très abouti et a comme grand intérêt d'être très facilement interconnectable avec d'autres applicatif et notamment avec ROS. 
Autre intérêt, V-REP propose un mode de fonctionnement en temps-réel. Cela signifie que la simulation est optimisée pour respecter des contraintes de temps-réel et permet d'avoir une simulation fidèle à la réalité, utilisable en combinaison avec un système réel. 

Comme dit précédemment, ROS fonctionne avec des nœuds indépendants. Dans le système commandant les Robotinos de l'équipe, un paquets de nœuds sont en charge de l'interfaçage entre le logiciel et le matériel. D'un point de vue des nœuds ROS, il importe peu de savoir quels nœuds fonctionnent, tant que nos messages d'informations sont reçus et que les informations nécessaires nous sont émises. 
Partant de ce principe, si c'est V-REP qui reçoit tout les ordres de mouvements et qui renvoi, à la place des nœuds habituels, les informations des capteurs, le flux caméra, etc, l'application fonctionnera sans problème. 
L'utilisation de la simulation sera alors totalement transparente, aucune modification de l'application ne sera nécessaire et c'est là toute la force de cette combinaison V-REP/ROS. 

=== OpenCV - Bibliothèque Open Source de vision par ordinateur ===
S'agissant d'un rapport intermédiaire, le travail effectué jusqu'ici n'utilise pas OpenCV. Il est toutefois intéressant d'en parler pour présenter le projet dans sa globalité. 
OpenCV est une bibliothèque, open-source elle aussi, de Computer Vision (vision par ordinateur, ou encore traitement d'images). Elle sera utilisée dans la seconde partie du projet qui consiste à fiabiliser le traitement d'images et le rendre plus efficace. 
La encore, cette bibliothèque est complètement intégrée à ROS, ce qui est bien-sûr un grand avantage. Elle permettra de traiter tant les flux vidéos réels que ceux en provenance de la simulation. 

Je précise ici, qu'à ce stade du projet, du code OpenCV est déjà fonctionnel sur un flux vidéo en provenance du robotino. C'est une source de problèmes en moins pour cette partie du projet, il ne reste plus qu'à s'occuper des algorithmes.

== Résultats ==

== Avancement du projet ==
=== Partie Simulateur ===
==== Semaine 01 | 22/09 - 28/09 ====
'''Objectif :''' ''Planification du projet'' 
Découverte du simulateur V-Rep via les tutoriels. 
Planification des premières semaines de projet, consacrées au simulateur. Les semaines suivants la soutenance de décembre seront elles consacrées au travail sur la reconnaissance vidéo. 
Rédaction de la base de la page Wiki.

==== Semaine 02 | 29/09 - 05/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 
Modélisation de la roue omnidirectionnelle. 

* Méthode 1 : Pure shape sphérique motorisé sur un axe et laissée libre sur un second axe. Pour garder l'axe libre à l'horizontale, même après rotation de la roue, un script viens replacer l'axe à chaque itération de la simulation. Cette méthode semble avoir des effets secondaires indésirables. Un couple apparaît sur l'axe "libre" de la roue, au point de pouvoir maintenir le robot à l'oblique. L'origine de ce couple n'est pas encore claire. 

* Méthode 2 : Modélisation complète de la roue omnidirectionnelle avec des galets ovoïdes "non pure". Cela complexifie la simulation qui semble avoir des ratés sur la résolution des contacts avec le sol et qui ralenti la simulation (la simulation ne respecte plus les contraintes temps réel).

* Méthode 3 (à tester) : Remplacer les galets par plusieurs "pure shape" sphériques.

* Méthode 4 (à tester) : Regarder du côté des textures avec aucune friction sur l'un des axes de l'objet.

==== Semaine 03 | 06/10 - 12/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

* Méthode 3 : Remplacer les galets par plusieurs "pure shape" sphériques. Il faut plusieurs sphères pure pour remplacer un seul galet (ovoïdes "non pure"). Le gain obtenu par simplification des éléments est perdu par la multiplication des éléments libres. Cela complexifie aussi la simulation qui semble avoir des ratés sur la résolution des contacts avec le sol et qui ralenti sévèrement la simulation (la simulation ne respecte plus les contraintes temps réel).

* Méthode 4 : Regarder du côté des textures avec aucune friction sur l'un des axes de l'objet. Ces textures fonctionnent avec le moteur physique Vortex. Il a pour inconvénient d'être payant et de ne proposer que 20 secondes de simulation dans sa version gratuite. Néanmoins, les résultats sont époustouflants et correspondent aux besoins (avec respect des contraintes temps réel dans la simulation). 

Ces quatre solutions sont toutes les solutions que j'ai trouvées à ce jour. Je pense garder celle du moteur physique Vortex pour des tests cours et tenter d'améliorer les résultats de la première méthode en m'attardant sur les manipulation scriptées pour éviter ou réduire les effets secondaires lors de simulations longues (plus de 20sec).

==== Semaine 04 | 13/10 - 19/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

==== Semaine 05 | 20/10 - 26/10 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 06 | 27/10 - 02/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 07 | 03/11 - 09/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 08 | 10/11 - 16/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 09 | 17/11 - 23/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 10 | 24/11 - 30/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 
Abandon définitif de la modélisation dynamique (modélisation des roues omnidirectionnelles). 
La modélisation sera uniquement cinématique.

==== Semaine 11 | 01/12 - 07/12 ====
'''Objectif :''' '' Définition des besoins pour la partie reconnaissance vidéo '' 

==== Semaine 12 | 08/12 - 14/12 ====
'''Objectif :''' '' Préparation de la soutenance '' 

==== Semaine 13 | 15/12 - 21/12 ====
'''Objectif :''' '' Soutenance de projet '' 

=== Partie Reconnaissance vidéo ===
==== Semaine 14 | 22/12 - 28/12 ====
'''Objectif :''' '' Planification de la partie reconnaissance vidéo '' 

== Médiagraphie ==
Site de Coppeliarobotics (simulateur V-Rep) 
[http://www.coppeliarobotics.com/ http://www.coppeliarobotics.com/]

Site et wiki de ROS (Robot Operating System) 
[http://www.ros.org/ http://www.ros.org/] 
[http://wiki.ros.org/ http://wiki.ros.org/]

P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens

2015-02-24T08:59:45Z

Vvergez : /* Downloads */

== Downloads ==
[https://drive.google.com/file/d/0BzEs72ClJBLRTVBfZ09RYmpWYnM/view?usp=sharing Rapport intermédiaire]
[https://drive.google.com/open?id=0BzEs72ClJBLRTHVwZ2RrQmdwNkU&authuser=0 Rapport final]

== Présentation du projet ==
Pour bien comprendre l'objet de ce projet, il faut savoir où sont nés les besoins.
Depuis l'année scolaire 2013/2014, des membres de Polytech Lille ont entrepris de participer à la Logistic League de la Robocup. 
La Robocup est une compétition internationale de Robotique, ayant pour but d'encourager le développement des robots autonomes. Historiquement la Robocup présente des compétitions de robots footballeurs, l'objectif initial étant d'obtenir une équipe de robots capable de rivaliser avec une équipe humaine. 
Depuis sa création, la Robocup a pris beaucoup d'ampleur et héberge maintenant - en plus de ses différentes leagues de football - des leagues orientés autour du secours, de la maison ou encore de la logistique. 

C'est cette league logistique qui nous intéresse. Créée et supportée par l'entreprise Festo, elle vise à représenter un environnement logistique de plus en plus autonome. 

Le travail se concentre principalement sur les Robotinos de Festo, des robots mobiles holonomes. Ces robots doivent évoluer par équipes de trois, deux équipes adverses à la fois, sur un terrain représentant un environnement de production. 
Leur rôle est d'optimiser la production du site en gérant les différentes machines de fabrication de produits et en s'adaptant à leur environnement. 
L'utilisation des machines est très simplifié, la majeure partie du travail se concentre finalement autour de la compréhension de l'environnement et de la stratégie de production. 

Une grande partie de l'appréhension de l'environnement par les robots est faite par vision. La vision par ordinateur est une chose complexe, l'un des besoin est donc d'obtenir un traitement d'image efficace et robuste. 

La stratégie elle, nécessite un nombre important de tests. 
Il est très coûteux de reproduire l’environnement de compétition complet, il faut avoir l'espace nécessaire pour l'installer. Il faudrait aussi deux fois plus de robots pour représenter l'équipe adverse et le matériel s'userait rapidement à cause de l'utilisation intense. 
Il est assez évident qu'un outil de simulation, sans être absolument nécessaire, serait un grand avantage. 

== Présentation des outils ==
Pour répondre à ces besoins, plusieurs outils sont utilisés. Les trois principaux sont ROS, V-REP et OpenCV.
=== ROS (Robot Operating System) - Framework pour applications de robotique ===
ROS, est une collection d'outils permettant le développement efficace et surtout rapide d'application de robotique. 
Partant du constat que les applications de robotique sont souvent similaires et que l'on y retrouve les même besoins, Open Source Robotics Foundation a lancé ROS, un projet open source qui permettrait aux roboticiens de développer leur logiciels de robotique à partir d'une base solide et standard. 
Depuis l'idée de départ jusqu'à aujourd'hui, ROS a rencontré un franc succès au point d'être pour ainsi dire une référence dans le domaine. 

Son concept de base est très intéressant car il permet de concevoir son système logiciel sous forme de plusieurs petits nœuds "indépendants". Indépendants ne veux pas dire isolés, les nœuds peuvent communiquer entre eux par plusieurs moyens de communications très complets. Mais leur développement lui peut-être réalisé indépendamment du reste de l'application. 

C'est très satisfaisant d'un point de vue du travail collaboratif premièrement, mais aussi pour le diagnostique d'erreur. Un système découpé en sous-systèmes est bien plus facile à maintenir. 
Mais c'est surtout très intéressant pour la partie qui va suivre, la simulation. 

ROS est l'environnement utilisé pour tout l'applicatif embarqué sur les Robotinos de l'équipe de Polytech Lille. Il sera donc un outil incontournable pour ce projet. 

=== V-Rep - Simulateur de robotique temps réel ===
V-REP, le simulateur de Coppelia Robotics, se définit comme le couteau suisse de la simulation robotique. C'est un logiciel Open Source, gratuit pour une utilisation non commerciale et assez récent. 
Il est toutefois déjà très abouti et a comme grand intérêt d'être très facilement interconnectable avec d'autres applicatif et notamment avec ROS. 
Autre intérêt, V-REP propose un mode de fonctionnement en temps-réel. Cela signifie que la simulation est optimisée pour respecter des contraintes de temps-réel et permet d'avoir une simulation fidèle à la réalité, utilisable en combinaison avec un système réel. 

Comme dit précédemment, ROS fonctionne avec des nœuds indépendants. Dans le système commandant les Robotinos de l'équipe, un paquets de nœuds sont en charge de l'interfaçage entre le logiciel et le matériel. D'un point de vue des nœuds ROS, il importe peu de savoir quels nœuds fonctionnent, tant que nos messages d'informations sont reçus et que les informations nécessaires nous sont émises. 
Partant de ce principe, si c'est V-REP qui reçoit tout les ordres de mouvements et qui renvoi, à la place des nœuds habituels, les informations des capteurs, le flux caméra, etc, l'application fonctionnera sans problème. 
L'utilisation de la simulation sera alors totalement transparente, aucune modification de l'application ne sera nécessaire et c'est là toute la force de cette combinaison V-REP/ROS. 

=== OpenCV - Bibliothèque Open Source de vision par ordinateur ===
S'agissant d'un rapport intermédiaire, le travail effectué jusqu'ici n'utilise pas OpenCV. Il est toutefois intéressant d'en parler pour présenter le projet dans sa globalité. 
OpenCV est une bibliothèque, open-source elle aussi, de Computer Vision (vision par ordinateur, ou encore traitement d'images). Elle sera utilisée dans la seconde partie du projet qui consiste à fiabiliser le traitement d'images et le rendre plus efficace. 
La encore, cette bibliothèque est complètement intégrée à ROS, ce qui est bien-sûr un grand avantage. Elle permettra de traiter tant les flux vidéos réels que ceux en provenance de la simulation. 

Je précise ici, qu'à ce stade du projet, du code OpenCV est déjà fonctionnel sur un flux vidéo en provenance du robotino. C'est une source de problèmes en moins pour cette partie du projet, il ne reste plus qu'à s'occuper des algorithmes.

== Résultats ==

== Avancement du projet ==
=== Partie Simulateur ===
==== Semaine 01 | 22/09 - 28/09 ====
'''Objectif :''' ''Planification du projet'' 
Découverte du simulateur V-Rep via les tutoriels. 
Planification des premières semaines de projet, consacrées au simulateur. Les semaines suivants la soutenance de décembre seront elles consacrées au travail sur la reconnaissance vidéo. 
Rédaction de la base de la page Wiki.

==== Semaine 02 | 29/09 - 05/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 
Modélisation de la roue omnidirectionnelle. 

* Méthode 1 : Pure shape sphérique motorisé sur un axe et laissée libre sur un second axe. Pour garder l'axe libre à l'horizontale, même après rotation de la roue, un script viens replacer l'axe à chaque itération de la simulation. Cette méthode semble avoir des effets secondaires indésirables. Un couple apparaît sur l'axe "libre" de la roue, au point de pouvoir maintenir le robot à l'oblique. L'origine de ce couple n'est pas encore claire. 

* Méthode 2 : Modélisation complète de la roue omnidirectionnelle avec des galets ovoïdes "non pure". Cela complexifie la simulation qui semble avoir des ratés sur la résolution des contacts avec le sol et qui ralenti la simulation (la simulation ne respecte plus les contraintes temps réel).

* Méthode 3 (à tester) : Remplacer les galets par plusieurs "pure shape" sphériques.

* Méthode 4 (à tester) : Regarder du côté des textures avec aucune friction sur l'un des axes de l'objet.

==== Semaine 03 | 06/10 - 12/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

* Méthode 3 : Remplacer les galets par plusieurs "pure shape" sphériques. Il faut plusieurs sphères pure pour remplacer un seul galet (ovoïdes "non pure"). Le gain obtenu par simplification des éléments est perdu par la multiplication des éléments libres. Cela complexifie aussi la simulation qui semble avoir des ratés sur la résolution des contacts avec le sol et qui ralenti sévèrement la simulation (la simulation ne respecte plus les contraintes temps réel).

* Méthode 4 : Regarder du côté des textures avec aucune friction sur l'un des axes de l'objet. Ces textures fonctionnent avec le moteur physique Vortex. Il a pour inconvénient d'être payant et de ne proposer que 20 secondes de simulation dans sa version gratuite. Néanmoins, les résultats sont époustouflants et correspondent aux besoins (avec respect des contraintes temps réel dans la simulation). 

Ces quatre solutions sont toutes les solutions que j'ai trouvées à ce jour. Je pense garder celle du moteur physique Vortex pour des tests cours et tenter d'améliorer les résultats de la première méthode en m'attardant sur les manipulation scriptées pour éviter ou réduire les effets secondaires lors de simulations longues (plus de 20sec).

==== Semaine 04 | 13/10 - 19/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

==== Semaine 05 | 20/10 - 26/10 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 06 | 27/10 - 02/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 07 | 03/11 - 09/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 08 | 10/11 - 16/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 09 | 17/11 - 23/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 10 | 24/11 - 30/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 
Abandon définitif de la modélisation dynamique (modélisation des roues omnidirectionnelles). 
La modélisation sera uniquement cinématique.

==== Semaine 11 | 01/12 - 07/12 ====
'''Objectif :''' '' Définition des besoins pour la partie reconnaissance vidéo '' 

==== Semaine 12 | 08/12 - 14/12 ====
'''Objectif :''' '' Préparation de la soutenance '' 

==== Semaine 13 | 15/12 - 21/12 ====
'''Objectif :''' '' Soutenance de projet '' 

=== Partie Reconnaissance vidéo ===
==== Semaine 14 | 22/12 - 28/12 ====
'''Objectif :''' '' Planification de la partie reconnaissance vidéo '' 

== Médiagraphie ==
Site de Coppeliarobotics (simulateur V-Rep) 
[http://www.coppeliarobotics.com/ http://www.coppeliarobotics.com/]

Site et wiki de ROS (Robot Operating System) 
[http://www.ros.org/ http://www.ros.org/] 
[http://wiki.ros.org/ http://wiki.ros.org/]

P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens

2014-12-17T09:14:54Z

Vvergez : Lien vers rapport

== Downloads ==
[https://drive.google.com/file/d/0BzEs72ClJBLRTVBfZ09RYmpWYnM/view?usp=sharing Rapport intermédiaire]

== Présentation du projet ==
Pour bien comprendre l'objet de ce projet, il faut savoir où sont nés les besoins.
Depuis l'année scolaire 2013/2014, des membres de Polytech Lille ont entrepris de participer à la Logistic League de la Robocup. 
La Robocup est une compétition internationale de Robotique, ayant pour but d'encourager le développement des robots autonomes. Historiquement la Robocup présente des compétitions de robots footballeurs, l'objectif initial étant d'obtenir une équipe de robots capable de rivaliser avec une équipe humaine. 
Depuis sa création, la Robocup a pris beaucoup d'ampleur et héberge maintenant - en plus de ses différentes leagues de football - des leagues orientés autour du secours, de la maison ou encore de la logistique. 

C'est cette league logistique qui nous intéresse. Créée et supportée par l'entreprise Festo, elle vise à représenter un environnement logistique de plus en plus autonome. 

Le travail se concentre principalement sur les Robotinos de Festo, des robots mobiles holonomes. Ces robots doivent évoluer par équipes de trois, deux équipes adverses à la fois, sur un terrain représentant un environnement de production. 
Leur rôle est d'optimiser la production du site en gérant les différentes machines de fabrication de produits et en s'adaptant à leur environnement. 
L'utilisation des machines est très simplifié, la majeure partie du travail se concentre finalement autour de la compréhension de l'environnement et de la stratégie de production. 

Une grande partie de l'appréhension de l'environnement par les robots est faite par vision. La vision par ordinateur est une chose complexe, l'un des besoin est donc d'obtenir un traitement d'image efficace et robuste. 

La stratégie elle, nécessite un nombre important de tests. 
Il est très coûteux de reproduire l’environnement de compétition complet, il faut avoir l'espace nécessaire pour l'installer. Il faudrait aussi deux fois plus de robots pour représenter l'équipe adverse et le matériel s'userait rapidement à cause de l'utilisation intense. 
Il est assez évident qu'un outil de simulation, sans être absolument nécessaire, serait un grand avantage. 

== Présentation des outils ==
Pour répondre à ces besoins, plusieurs outils sont utilisés. Les trois principaux sont ROS, V-REP et OpenCV.
=== ROS (Robot Operating System) - Framework pour applications de robotique ===
ROS, est une collection d'outils permettant le développement efficace et surtout rapide d'application de robotique. 
Partant du constat que les applications de robotique sont souvent similaires et que l'on y retrouve les même besoins, Open Source Robotics Foundation a lancé ROS, un projet open source qui permettrait aux roboticiens de développer leur logiciels de robotique à partir d'une base solide et standard. 
Depuis l'idée de départ jusqu'à aujourd'hui, ROS a rencontré un franc succès au point d'être pour ainsi dire une référence dans le domaine. 

Son concept de base est très intéressant car il permet de concevoir son système logiciel sous forme de plusieurs petits nœuds "indépendants". Indépendants ne veux pas dire isolés, les nœuds peuvent communiquer entre eux par plusieurs moyens de communications très complets. Mais leur développement lui peut-être réalisé indépendamment du reste de l'application. 

C'est très satisfaisant d'un point de vue du travail collaboratif premièrement, mais aussi pour le diagnostique d'erreur. Un système découpé en sous-systèmes est bien plus facile à maintenir. 
Mais c'est surtout très intéressant pour la partie qui va suivre, la simulation. 

ROS est l'environnement utilisé pour tout l'applicatif embarqué sur les Robotinos de l'équipe de Polytech Lille. Il sera donc un outil incontournable pour ce projet. 

=== V-Rep - Simulateur de robotique temps réel ===
V-REP, le simulateur de Coppelia Robotics, se définit comme le couteau suisse de la simulation robotique. C'est un logiciel Open Source, gratuit pour une utilisation non commerciale et assez récent. 
Il est toutefois déjà très abouti et a comme grand intérêt d'être très facilement interconnectable avec d'autres applicatif et notamment avec ROS. 
Autre intérêt, V-REP propose un mode de fonctionnement en temps-réel. Cela signifie que la simulation est optimisée pour respecter des contraintes de temps-réel et permet d'avoir une simulation fidèle à la réalité, utilisable en combinaison avec un système réel. 

Comme dit précédemment, ROS fonctionne avec des nœuds indépendants. Dans le système commandant les Robotinos de l'équipe, un paquets de nœuds sont en charge de l'interfaçage entre le logiciel et le matériel. D'un point de vue des nœuds ROS, il importe peu de savoir quels nœuds fonctionnent, tant que nos messages d'informations sont reçus et que les informations nécessaires nous sont émises. 
Partant de ce principe, si c'est V-REP qui reçoit tout les ordres de mouvements et qui renvoi, à la place des nœuds habituels, les informations des capteurs, le flux caméra, etc, l'application fonctionnera sans problème. 
L'utilisation de la simulation sera alors totalement transparente, aucune modification de l'application ne sera nécessaire et c'est là toute la force de cette combinaison V-REP/ROS. 

=== OpenCV - Bibliothèque Open Source de vision par ordinateur ===
S'agissant d'un rapport intermédiaire, le travail effectué jusqu'ici n'utilise pas OpenCV. Il est toutefois intéressant d'en parler pour présenter le projet dans sa globalité. 
OpenCV est une bibliothèque, open-source elle aussi, de Computer Vision (vision par ordinateur, ou encore traitement d'images). Elle sera utilisée dans la seconde partie du projet qui consiste à fiabiliser le traitement d'images et le rendre plus efficace. 
La encore, cette bibliothèque est complètement intégrée à ROS, ce qui est bien-sûr un grand avantage. Elle permettra de traiter tant les flux vidéos réels que ceux en provenance de la simulation. 

Je précise ici, qu'à ce stade du projet, du code OpenCV est déjà fonctionnel sur un flux vidéo en provenance du robotino. C'est une source de problèmes en moins pour cette partie du projet, il ne reste plus qu'à s'occuper des algorithmes.

== Résultats ==

== Avancement du projet ==
=== Partie Simulateur ===
==== Semaine 01 | 22/09 - 28/09 ====
'''Objectif :''' ''Planification du projet'' 
Découverte du simulateur V-Rep via les tutoriels. 
Planification des premières semaines de projet, consacrées au simulateur. Les semaines suivants la soutenance de décembre seront elles consacrées au travail sur la reconnaissance vidéo. 
Rédaction de la base de la page Wiki.

==== Semaine 02 | 29/09 - 05/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 
Modélisation de la roue omnidirectionnelle. 

* Méthode 1 : Pure shape sphérique motorisé sur un axe et laissée libre sur un second axe. Pour garder l'axe libre à l'horizontale, même après rotation de la roue, un script viens replacer l'axe à chaque itération de la simulation. Cette méthode semble avoir des effets secondaires indésirables. Un couple apparaît sur l'axe "libre" de la roue, au point de pouvoir maintenir le robot à l'oblique. L'origine de ce couple n'est pas encore claire. 

* Méthode 2 : Modélisation complète de la roue omnidirectionnelle avec des galets ovoïdes "non pure". Cela complexifie la simulation qui semble avoir des ratés sur la résolution des contacts avec le sol et qui ralenti la simulation (la simulation ne respecte plus les contraintes temps réel).

* Méthode 3 (à tester) : Remplacer les galets par plusieurs "pure shape" sphériques.

* Méthode 4 (à tester) : Regarder du côté des textures avec aucune friction sur l'un des axes de l'objet.

==== Semaine 03 | 06/10 - 12/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

* Méthode 3 : Remplacer les galets par plusieurs "pure shape" sphériques. Il faut plusieurs sphères pure pour remplacer un seul galet (ovoïdes "non pure"). Le gain obtenu par simplification des éléments est perdu par la multiplication des éléments libres. Cela complexifie aussi la simulation qui semble avoir des ratés sur la résolution des contacts avec le sol et qui ralenti sévèrement la simulation (la simulation ne respecte plus les contraintes temps réel).

* Méthode 4 : Regarder du côté des textures avec aucune friction sur l'un des axes de l'objet. Ces textures fonctionnent avec le moteur physique Vortex. Il a pour inconvénient d'être payant et de ne proposer que 20 secondes de simulation dans sa version gratuite. Néanmoins, les résultats sont époustouflants et correspondent aux besoins (avec respect des contraintes temps réel dans la simulation). 

Ces quatre solutions sont toutes les solutions que j'ai trouvées à ce jour. Je pense garder celle du moteur physique Vortex pour des tests cours et tenter d'améliorer les résultats de la première méthode en m'attardant sur les manipulation scriptées pour éviter ou réduire les effets secondaires lors de simulations longues (plus de 20sec).

==== Semaine 04 | 13/10 - 19/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

==== Semaine 05 | 20/10 - 26/10 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 06 | 27/10 - 02/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 07 | 03/11 - 09/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 08 | 10/11 - 16/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 09 | 17/11 - 23/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 10 | 24/11 - 30/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 
Abandon définitif de la modélisation dynamique (modélisation des roues omnidirectionnelles). 
La modélisation sera uniquement cinématique.

==== Semaine 11 | 01/12 - 07/12 ====
'''Objectif :''' '' Définition des besoins pour la partie reconnaissance vidéo '' 

==== Semaine 12 | 08/12 - 14/12 ====
'''Objectif :''' '' Préparation de la soutenance '' 

==== Semaine 13 | 15/12 - 21/12 ====
'''Objectif :''' '' Soutenance de projet '' 

=== Partie Reconnaissance vidéo ===
==== Semaine 14 | 22/12 - 28/12 ====
'''Objectif :''' '' Planification de la partie reconnaissance vidéo '' 

== Médiagraphie ==
Site de Coppeliarobotics (simulateur V-Rep) 
[http://www.coppeliarobotics.com/ http://www.coppeliarobotics.com/]

Site et wiki de ROS (Robot Operating System) 
[http://www.ros.org/ http://www.ros.org/] 
[http://wiki.ros.org/ http://wiki.ros.org/]

P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens

2014-11-26T15:55:34Z

Vvergez : /* Semaine 10 | 24/11 - 30/11 */

== Présentation du projet ==
=== Contexte ===

=== Cahier des charges ===

== Présentation des outils ==
=== ROS (Robot Operating System) - Framework pour applications de robotique ===
=== V-Rep - Simulateur de robotique temps réel ===
=== OpenCV - Bibliothèque Open Source de vision par ordinateur ===

== Résultats ==

== Avancement du projet ==
=== Partie Simulateur ===
==== Semaine 01 | 22/09 - 28/09 ====
'''Objectif :''' ''Planification du projet'' 
Découverte du simulateur V-Rep via les tutoriels. 
Planification des premières semaines de projet, consacrées au simulateur. Les semaines suivants la soutenance de décembre seront elles consacrées au travail sur la reconnaissance vidéo. 
Rédaction de la base de la page Wiki.

==== Semaine 02 | 29/09 - 05/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 
Modélisation de la roue omnidirectionnelle. 

* Méthode 1 : Pure shape sphérique motorisé sur un axe et laissée libre sur un second axe. Pour garder l'axe libre à l'horizontale, même après rotation de la roue, un script viens replacer l'axe à chaque itération de la simulation. Cette méthode semble avoir des effets secondaires indésirables. Un couple apparaît sur l'axe "libre" de la roue, au point de pouvoir maintenir le robot à l'oblique. L'origine de ce couple n'est pas encore claire. 

* Méthode 2 : Modélisation complète de la roue omnidirectionnelle avec des galets ovoïdes "non pure". Cela complexifie la simulation qui semble avoir des ratés sur la résolution des contacts avec le sol et qui ralenti la simulation (la simulation ne respecte plus les contraintes temps réel).

* Méthode 3 (à tester) : Remplacer les galets par plusieurs "pure shape" sphériques.

* Méthode 4 (à tester) : Regarder du côté des textures avec aucune friction sur l'un des axes de l'objet.

==== Semaine 03 | 06/10 - 12/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

* Méthode 3 : Remplacer les galets par plusieurs "pure shape" sphériques. Il faut plusieurs sphères pure pour remplacer un seul galet (ovoïdes "non pure"). Le gain obtenu par simplification des éléments est perdu par la multiplication des éléments libres. Cela complexifie aussi la simulation qui semble avoir des ratés sur la résolution des contacts avec le sol et qui ralenti sévèrement la simulation (la simulation ne respecte plus les contraintes temps réel).

* Méthode 4 : Regarder du côté des textures avec aucune friction sur l'un des axes de l'objet. Ces textures fonctionnent avec le moteur physique Vortex. Il a pour inconvénient d'être payant et de ne proposer que 20 secondes de simulation dans sa version gratuite. Néanmoins, les résultats sont époustouflants et correspondent aux besoins (avec respect des contraintes temps réel dans la simulation). 

Ces quatre solutions sont toutes les solutions que j'ai trouvées à ce jour. Je pense garder celle du moteur physique Vortex pour des tests cours et tenter d'améliorer les résultats de la première méthode en m'attardant sur les manipulation scriptées pour éviter ou réduire les effets secondaires lors de simulations longues (plus de 20sec).

==== Semaine 04 | 13/10 - 19/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

==== Semaine 05 | 20/10 - 26/10 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 06 | 27/10 - 02/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 07 | 03/11 - 09/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 08 | 10/11 - 16/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 09 | 17/11 - 23/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 10 | 24/11 - 30/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 
Abandon définitif de la modélisation dynamique (modélisation des roues omnidirectionnelles). 
La modélisation sera uniquement cinématique.

==== Semaine 11 | 01/12 - 07/12 ====
'''Objectif :''' '' Définition des besoins pour la partie reconnaissance vidéo '' 

==== Semaine 12 | 08/12 - 14/12 ====
'''Objectif :''' '' Préparation de la soutenance '' 

==== Semaine 13 | 15/12 - 21/12 ====
'''Objectif :''' '' Soutenance de projet '' 

=== Partie Reconnaissance vidéo ===
==== Semaine 14 | 22/12 - 28/12 ====
'''Objectif :''' '' Planification de la partie reconnaissance vidéo '' 

== Médiagraphie ==
Site de Coppeliarobotics (simulateur V-Rep) 
[http://www.coppeliarobotics.com/ http://www.coppeliarobotics.com/]

Site et wiki de ROS (Robot Operating System) 
[http://www.ros.org/ http://www.ros.org/] 
[http://wiki.ros.org/ http://wiki.ros.org/]

P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens

2014-10-12T17:54:55Z

Vvergez : Semaine 03

== Présentation du projet ==
=== Contexte ===

=== Cahier des charges ===

== Présentation des outils ==
=== ROS (Robot Operating System) - Framework pour applications de robotique ===
=== V-Rep - Simulateur de robotique temps réel ===
=== OpenCV - Bibliothèque Open Source de vision par ordinateur ===

== Résultats ==

== Avancement du projet ==
=== Partie Simulateur ===
==== Semaine 01 | 22/09 - 28/09 ====
'''Objectif :''' ''Planification du projet'' 
Découverte du simulateur V-Rep via les tutoriels. 
Planification des premières semaines de projet, consacrées au simulateur. Les semaines suivants la soutenance de décembre seront elles consacrées au travail sur la reconnaissance vidéo. 
Rédaction de la base de la page Wiki.

==== Semaine 02 | 29/09 - 05/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 
Modélisation de la roue omnidirectionnelle. 

* Méthode 1 : Pure shape sphérique motorisé sur un axe et laissée libre sur un second axe. Pour garder l'axe libre à l'horizontale, même après rotation de la roue, un script viens replacer l'axe à chaque itération de la simulation. Cette méthode semble avoir des effets secondaires indésirables. Un couple apparaît sur l'axe "libre" de la roue, au point de pouvoir maintenir le robot à l'oblique. L'origine de ce couple n'est pas encore claire. 

* Méthode 2 : Modélisation complète de la roue omnidirectionnelle avec des galets ovoïdes "non pure". Cela complexifie la simulation qui semble avoir des ratés sur la résolution des contacts avec le sol et qui ralenti la simulation (la simulation ne respecte plus les contraintes temps réel).

* Méthode 3 (à tester) : Remplacer les galets par plusieurs "pure shape" sphériques.

* Méthode 4 (à tester) : Regarder du côté des textures avec aucune friction sur l'un des axes de l'objet.

==== Semaine 03 | 06/10 - 12/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

* Méthode 3 : Remplacer les galets par plusieurs "pure shape" sphériques. Il faut plusieurs sphères pure pour remplacer un seul galet (ovoïdes "non pure"). Le gain obtenu par simplification des éléments est perdu par la multiplication des éléments libres. Cela complexifie aussi la simulation qui semble avoir des ratés sur la résolution des contacts avec le sol et qui ralenti sévèrement la simulation (la simulation ne respecte plus les contraintes temps réel).

* Méthode 4 : Regarder du côté des textures avec aucune friction sur l'un des axes de l'objet. Ces textures fonctionnent avec le moteur physique Vortex. Il a pour inconvénient d'être payant et de ne proposer que 20 secondes de simulation dans sa version gratuite. Néanmoins, les résultats sont époustouflants et correspondent aux besoins (avec respect des contraintes temps réel dans la simulation). 

Ces quatre solutions sont toutes les solutions que j'ai trouvées à ce jour. Je pense garder celle du moteur physique Vortex pour des tests cours et tenter d'améliorer les résultats de la première méthode en m'attardant sur les manipulation scriptées pour éviter ou réduire les effets secondaires lors de simulations longues (plus de 20sec).

==== Semaine 04 | 13/10 - 19/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

==== Semaine 05 | 20/10 - 26/10 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 06 | 27/10 - 02/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 07 | 03/11 - 09/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 08 | 10/11 - 16/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 09 | 17/11 - 23/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 10 | 24/11 - 30/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 11 | 01/12 - 07/12 ====
'''Objectif :''' '' Définition des besoins pour la partie reconnaissance vidéo '' 

==== Semaine 12 | 08/12 - 14/12 ====
'''Objectif :''' '' Préparation de la soutenance '' 

==== Semaine 13 | 15/12 - 21/12 ====
'''Objectif :''' '' Soutenance de projet '' 

=== Partie Reconnaissance vidéo ===
==== Semaine 14 | 22/12 - 28/12 ====
'''Objectif :''' '' Planification de la partie reconnaissance vidéo '' 

== Médiagraphie ==
Site de Coppeliarobotics (simulateur V-Rep) 
[http://www.coppeliarobotics.com/ http://www.coppeliarobotics.com/]

Site et wiki de ROS (Robot Operating System) 
[http://www.ros.org/ http://www.ros.org/] 
[http://wiki.ros.org/ http://wiki.ros.org/]

P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens

2014-10-01T19:38:59Z

Vvergez : /* Semaine 02 | 29/09 - 05/10 */

P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens

2014-09-28T16:41:37Z

Vvergez : Ajout du squelette de section "Présentation des outils"

P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens

2014-09-28T16:34:04Z

Vvergez : /* Médiagraphie */

== Présentation du projet ==
=== Contexte ===

=== Cahier des charges ===

== Résultats ==

== Avancement du projet ==
=== Partie Simulateur ===
==== Semaine 01 | 22/09 - 28/09 ====
'''Objectif :''' ''Planification du projet'' 
Découverte du simulateur V-Rep via les tutoriels. 
Planification des premières semaines de projet, consacrées au simulateur. Les semaines suivants la soutenance de décembre seront elles consacrées au travail sur la reconnaissance vidéo. 
Rédaction de la base de la page Wiki.

==== Semaine 02 | 29/09 - 05/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

==== Semaine 03 | 06/10 - 12/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

==== Semaine 04 | 13/10 - 19/10 ====
'''Objectif :''' '' Modélisation Robotino 3 '' 

==== Semaine 05 | 20/10 - 26/10 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 06 | 27/10 - 02/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 07 | 03/11 - 09/11 ====
'''Objectif :''' '' Interfaçage ROS et V-REP '' 

==== Semaine 08 | 10/11 - 16/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 09 | 17/11 - 23/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 10 | 24/11 - 30/11 ====
'''Objectif :''' '' Tests et correction de la modélisation '' 

==== Semaine 11 | 01/12 - 07/12 ====
'''Objectif :''' '' Définition des besoins pour la partie reconnaissance vidéo '' 

==== Semaine 12 | 08/12 - 14/12 ====
'''Objectif :''' '' Préparation de la soutenance '' 

==== Semaine 13 | 15/12 - 21/12 ====
'''Objectif :''' '' Soutenance de projet '' 

=== Partie Reconnaissance vidéo ===
==== Semaine 14 | 22/12 - 28/12 ====
'''Objectif :''' '' Planification de la partie reconnaissance vidéo '' 

== Médiagraphie ==
Site de Coppeliarobotics (simulateur V-Rep) 
[http://www.coppeliarobotics.com/ http://www.coppeliarobotics.com/]

Site et wiki de ROS (Robot Operating System) 
[http://www.ros.org/ http://www.ros.org/] 
[http://wiki.ros.org/ http://wiki.ros.org/]

P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens

2014-09-28T16:14:39Z

Vvergez : Squelette de la page (avec suivi du projet) - Objectifs jusqu'à décembre - Résumé semaine 01

Projets IMA5 2014/2015

2014-09-28T14:42:53Z

Vvergez : /* Répartition des binômes */

FPGA et roues codeuses

2014-04-16T02:29:32Z

Vvergez : Déplacement du lien vers le Rapport (trop peu visible et non conforme au placement choisi sur les autres Wiki) - Suppression du WIP

= Présentation =
== Aperçu ==
Le sujet propose de réaliser un système simple sur cible FPGA permettant de :
* Lire et décoder une ou plusieurs roues codeuses ;
* Asservir un ou plusieurs moteurs, soit pas-à-pas soir à courant continu.

La cible visée sera un FPGA de chez Xilinx (carte de développement). En parallèle, une carte d'interface de puissance sera réalisée (interface entre FPGA et moteurs).

== Cahier des charges étendu ==
=== Description ===
Ce projet s'inscrit dans le cadre de la réalisation d'un robot mobile autonome, capable de se déplacer avec précision grâce au retour de ses capteurs.
La propulsion du robot est effectuée par deux moteurs à courant-continu, chacun couplé à une roue motrice tandis que le retour sur le déplacement est lui obtenu par deux codeurs à quadratures de phases couplés à des roues de mesures.
Il est aussi possible de récupérer l'information de vitesse des moteurs grâce à des dynamos tachymétriques ou par le biais d'autres codeurs à quadratures de phases directement couplés au moteur.

Pour approcher ce fonctionnement, on travaillera initialement sur un seul codeur et un seul moteur. L'objectif est d'interpréter les signaux en quadratures de phases avec un FPGA et d'effectuer à partir de cette information un asservissement en vitesse du moteur.

Si ce fonctionnement de base est obtenu suffisamment tôt, des améliorations sont envisageables, comme par exemple :
* Commande et mesure pour plusieurs moteurs et codeurs ;
* Pilotage du FPGA par un protocole de communication (série, CAN, I2C, à déterminer …) ;
* Asservissement polaire (cas d'un déplacement de robot) ;
* Calcul d'odométrie.
La liste est non exhaustive.

=== Travail à réaliser ===
* '''FPGA :'''
** Récupération des signaux codeurs ;
** Interprétation des signaux et comptage ;
** Écriture de la mesure sur un bus ;
** Lecture de la consigne d'asservissement ;
** Asservissement et génération de la consigne moteur.

* '''Électronique de puissance : '''
** Carte de conversion consigne (signaux logiques) en commande (tension avec puissance) ;
** Éventuelle protection en tension et en courant de la carte.

=== Caractéristiques ===
Les moteurs utilisés peuvent être de deux types différents :
* ''Graupner Speed 720 BB Torque.''
Alimenté en '''0-12V''' avec des courants max de '''3A''' et des courants moyens de 750mA.
* ''Faulhaber 3557K024CS.''
Alimenté en '''0-24V''' avec des courants max de '''1,1A''' et des courants moyens de 65mA.

Ces deux types de moteurs représentent des cas très usités, il conviendra donc d'avoir une carte de puissance permettant d'assumer ces deux configurations.

= Suivi des séances =
== Semaine 1 (5/02) ==
Élaboration du cahier des charges étendu.
Réflexion sur les différentes étapes à réaliser pour arriver au bout du projet.



== Semaine 2 (12/02) ==
Nous commençons notre programmation sur le logiciel Altium afin d'utiliser le FPGA de la nanoboard.
Le premier module sera un module de génération de PWM (Pulse Width Modulation) afin de pouvoir contrôler les moteurs au travers de la carte de puissance. Ce module est paramétré par une valeur codée sur 1 octet (entre 0 et 255) qui permet de changer la valeur du rapport cyclique.
*Si on a '''0''', rapport cyclique = '''0%''' , sortie = '''0V''' (état bas)
*Si on a '''127''', rapport cyclique = '''50%''' , sortie = 50% état haut et 50% état bas
*Si on a '''255''', rapport cyclique = '''100%''', sortie = '''3V3''' (état haut)

Nous commençons aussi la réflexion sur les méthodes de décodage de signaux de quadratures de phases. Les résultats sont peu concluant, la solution trouvée test chaque configuration possible des signaux avant de traduire la configuration en un comptage ou un décomptage. La résolution est limité au nombre de pas par tours du codeur.

== Semaine 3 (19/02) ==
Fin du codage de la PWM. Ci dessous un image montrant une PWM de rapport cyclique 33% donc avec 0x3F en entrée.

[[Fichier:PWM_3F.png | 500px]]

Dans le cadre du projet et du développement du robot de la coupe de France 2014, nous avons besoin d'un module de communication série afin de pourvoir avoir un dialogue entre le FPGA et d'autres contrôleurs (Raspberry Pi, beagleBone...).

Dans un premier temps nous cherchons une IP(Intellectual Property) de communication serie RS232. Et nous testons les différents modules trouvés.

Afin de pouvoir se partager les codes sources et faire un travail collaboratif de manière efficace, nous avons mis en place un repository git sur GitHub. De cette manière tous nos codes seront versionnés et nous pourrons revenir à des versions précédente en cas de problème.

Après une importante tâche de documentation, il s'avère que les composants électroniques du commerces comptent chaque fronts des deux signaux en quadratures de phases, augmentant ainsi la résolution du comptage par 4 et facilitant apparemment le raisonnement.
En étudiant la situation sous forme logique (table de vérité, tableau de karnaugh), nous trouvons une solution à base de quelques ou exclusif.

[[Fichier:Github.jpg]]

== Semaine 4 (26/02) ==
Test de différents modules mais les résultats ne sont pas concluants. Les IP trouvées sont des très lourds et difficiles à mettre en place. Pour les besoins de notre projet nous avons voulons un programme assez simple qui fais juste une communication RS232 sans correction d'erreurs. C'est pourquoi nous décidons finalement de coder nous même le module.

La solution développée sur papier pour le décodage des signaux est mis en place sous Altium, on obtient un comptage/décomptage conforme, mais un tour ne correspond pas exactement à 1024 * 4 pas.

== Semaine 5 (05/03) ==
Afin de s'affranchir d'Altium et de la nanoboard nous décidons de passer sur le logiciel ISE de Xilink. Son avantage est que nous allons pouvoir passer sur une carte de développement différente (la starter board ) et nous pourrons aussi programmer avec la prochaine carte de développement (Spartan-6 LX9
MicroBoard) qui sera commandée prochainement.

Le passage sous Xilink implique la programmation d'un fichier de contraintes afin d'indiquer au logiciel où connecter physiquement nos entrées sorties déclarées dans le programme. Ce fichier sera le seul à changer si l'on veut changer de FPGA car un code VHDL est portable et ne dépends pas du FPGA.

Nous avons donc pris en main le nouveau logiciel et programmer notre premier fichier de contrainte afin de pouvoir essayer notre module de PWM sur la nouvelle carte.

Les problèmes de comptage de la semaine précédente sont identifiés, lors du temps de monté des signaux en quadratures, le FPGA interprète différents niveau de tensions (haut,bas) à cause d'un bruit présent sur le signal. C'est un phénomène similaires aux "rebonds" que l'on trouverait sur un bouton poussoir.
Une solution à base de lissage est essayée, ce n'est pas concluant.

== Semaine 6 (12/03) ==
Début du codage de la partie '''réception''' du module série. Celui-ci sera composé de trois fichiers :
*le fichier de réception série : '''serial_rx'''
*le fichier d'envoi série : '''serial_tx'''
*le fichier de gestion des deux autres fichiers : '''serial_module''', c'est le fichier principal du module, c'est dans celui-là que l'on va instancier dans deux composants serial_rx et serial_tx.

Réception d'une carte de développement FPGA (Spartan-6 LX9 MicroBoard), c'est celle là qui sera intégrée au robot. Programmation du fichier de contraintes et test de cette carte avec un programme simple (allumage d'une LED) afin de vérifier son fonctionnement.

Pour enfin résoudre le problème d'inexactitude du comptage, le problème des "rebonds", nous utilisons un module "debouncer", qui vérifie l’établissement du signal pendant plusieurs fronts d'horloge.
Ce module a été développé par Mickael Coronado, Ingénieur Electronique Analogique / Numérique (Spécialiste FPGA) et Dirigeant (entreprise Inodesign).

== Semaine 7 (19/03) ==
Après quelques difficultés de programmation dû à l'appréhension du VHDL, le module de réception série est fonctionnel. Lorsqu'on lui envoi une donnée grâce à minicom, il l'affiche le code ASCII sur des leds.

Sur l'image suivante, nous avons envoyé le caractère 'a' (code ASCII : 0x97) et l'on voit que l'affichage de 'a' sur les leds fonctionne correctement
[[Fichier:Reception_a.jpg | 500px]]

Début du code d'émission série.

Début du code et du raisonnement de l'asservissement d'un moteur. Assemblage des modules PWM, debouncer, décodeur à quadrature dans un module reprenant toute l'application.

== Semaine 8 (26/03) ==
Fin du code d'émission série, le FPGA est capable d'envoyer une donnée venant des switch de la carte(8 bits) et l'affichage se fait sur minicom.
Par exemple si on envoi 98 en hexadecimal (0110 0010), nous verrons 'b' s'afficher sur minicom car 0x98 correspond au code ASCII du caractère 'b'.

Début de la programmation du module général de la communication série.

Un pilotage d'un moteur à courant continu en vitesse est maintenant possible avec un codeur rotatif.

== Semaine 9 (2/04) ==
Le module de communication série est entièrement fonctionnel, il peut donc être intégré dans n'importe quelle programme VHDL, pour cela il faut le déclarer en tant que composant dans son programme et faire les map des ports nécessaires.

Ce module permet de gérer l'envoi et la réception facilement, au sein d'un programme.

Afin de faciliter l'accès aux différents paramètres d'asservissement et ainsi pouvoir les lires ou les changer, nous décidons de créer un module de mémoire. Celui-ci sera un registre de grande taille dans lequel le module d'asservissement mais aussi un ordinateur comme un Raspberry (par le biais de la communication série) pourra aller lire/écrire.

Valentin est partit pour la semaine complète à Magdebourg (Allemagne) pour une participation à l'Open German Robocup, une pré-coupe de la Robocup, compétition internationale de robotique.
Il y a donc eu une interruption logique de la progression sur son travail.

== Semaine 10 (9/04) ==
Début de la programmation du module prenant en charge le composant série et le registre avec le protocole série d'accès aux données.

Le module du registre est relativement simple à coder puisqu'il s'agit de déclarer un grand registre et d'y faire des alias afin d'avoir un accès simplifié.

Test de communication entre le port série et le registre. Pour cela on a créé un module instanciant les composants serial_module et register_module. Ce module va écouter le port série et si une donnée arrive et correspond à une valeur particulière, il écrira dans le registre la valeur en question. Puis, il ira chercher la valeur écrite dans le registre afin de la renvoyer et de vérifier que la donnée du registre correspond à la donnée envoyée.

Maintenant, nous voulons modifier ce module afin qu'il puisse aller écrire au bon endroit dans le registre. Nous allons donc créer un protocole d'envoi des données, de cette manière suivant l'adresse et la donnée reçue nous pourrons mettre à jour le registre mais aussi renvoyer une valeur du registre.

L'ordinateur connecté au FPGA pourra donc récupérer les valeurs des asservissement et de déplacement. Il pourra aussi modifier ces valeurs afin de donner des ordres au robot (exemple : avancer à une vitesse particulière).

Le protocole est le suivant :
*Premier octet, initialisation : 0x00
*Deuxième octet, ordre :
**0x01 : lecture
**0x02 : écriture
*Troisième octet, adresse : entre 0x00 et 0x17 (24 adresses possibles)
*Quatrième octet, données : entre 0x00 et 0xFF (en cas de lecture 0x55)
*Cinquième octet, fin : 0xFF

Le FPGA n'aura jamais à demander d'informations au Raspberry par conséquent, lorsqu'il y aura une demande de lecture, le FPGA renverra directement la valeur demandée sans utilisation de protocole particulier.

== Semaine 11 (16/04) ==
On a continué à programmer le protocole, des difficultés ont été rencontrées dans l'instanciation et le mappage des différentes entrées sorties afin d'utiliser correctement les modules à inclure (serial_module et register_module). Ces difficultés sont dues au faite que c'est la première fois où l'on fait un mappage complet prenant en compte deux composants annexes.
La programmation n'est aujourd'hui (15/04/2014) pas encore fini du à un retard dans les phases de tests, il sera prochainement finalisé en vue d'une implantation dans un module principal de gestion du déplacement du robot qui sera programmé dans le FPGA du robot.

== A venir ==
Création d'un programme C sur Raspberry afin de faire des échanges de données avec le FPGA et création de l'intelligence du robot.

= Descriptif technique =
== Carte de puissance ==
La carte de puissance permet de connecter 2 moteurs entre 12 et 55V consommant jusqu'à 3A grâce à deux ponts en H (LMD18200). Ces moteurs seront contrôlés par une modulation par largeur d'impulsion (PWM).

=== Schéma électrique ===
[[Fichier:Schema_carte_puissance.PNG | 500px]]

=== PCB ===
[[Fichier:CartePuissance_Moteurs.png | 500px]]

== Communication série ==
La communication fonctionne à une vitesse fixée dans le programme, par défaut à 9600 bauds. Elle est 8N1 c'est à dire 8 bits de données, pas de parité et 1 bit de stop.
Elle peut être implantée sur n'importe qu'elle FPGA car elle n'utilise aucune librairie propre à un constructeur.

== Registre mémoire ==
Le registre mémoire est un registre de grande taille sur lequel on va lire et écrire des données de différentes tailles.

== Asservissement ==
Il peut être intéressant de réaliser un asservissement polaire d'un robot (en angle et en distance) en utilisant deux moteurs de propulsions, de la mesure sur les moteurs pour une boucle d'asservissement de vitesse et une mesure sur deux roues libres qui suivent le déplacement.
C'est une réalisation plutôt compliquée, mais les briques principales sont déjà prêtes.

= Rapport =
Vous pouvez accéder au rapport du projet en suivant ce lien : [https://drive.google.com/file/d/0BzEs72ClJBLRckRIeEZIQURmRnM/edit?usp=sharing Rapport du projet]

FPGA et roues codeuses

2014-04-15T21:56:15Z

Vvergez :

Vous pouvez accéder au rapport du projet en suivant ce lien : [https://drive.google.com/file/d/0BzEs72ClJBLRckRIeEZIQURmRnM/edit?usp=sharing Rapport du projet]

= Work In Progress =
Cette page est en cours de rédaction et le restera tout le long du projet. Elle sera mise à jour régulièrement (lors des séances de travail). 
La version finale sera disponible le 16 avr. 2014.

= Présentation =
== Aperçu ==
Le sujet propose de réaliser un système simple sur cible FPGA permettant de :
* Lire et décoder une ou plusieurs roues codeuses ;
* Asservir un ou plusieurs moteurs, soit pas-à-pas soir à courant continu.

La cible visée sera un FPGA de chez Xilinx (carte de développement). En parallèle, une carte d'interface de puissance sera réalisée (interface entre FPGA et moteurs).

== Cahier des charges étendu ==
=== Description ===
Ce projet s'inscrit dans le cadre de la réalisation d'un robot mobile autonome, capable de se déplacer avec précision grâce au retour de ses capteurs.
La propulsion du robot est effectuée par deux moteurs à courant-continu, chacun couplé à une roue motrice tandis que le retour sur le déplacement est lui obtenu par deux codeurs à quadratures de phases couplés à des roues de mesures.
Il est aussi possible de récupérer l'information de vitesse des moteurs grâce à des dynamos tachymétriques ou par le biais d'autres codeurs à quadratures de phases directement couplés au moteur.

Pour approcher ce fonctionnement, on travaillera initialement sur un seul codeur et un seul moteur. L'objectif est d'interpréter les signaux en quadratures de phases avec un FPGA et d'effectuer à partir de cette information un asservissement en vitesse du moteur.

Si ce fonctionnement de base est obtenu suffisamment tôt, des améliorations sont envisageables, comme par exemple :
* Commande et mesure pour plusieurs moteurs et codeurs ;
* Pilotage du FPGA par un protocole de communication (série, CAN, I2C, à déterminer …) ;
* Asservissement polaire (cas d'un déplacement de robot) ;
* Calcul d'odométrie.
La liste est non exhaustive.

=== Travail à réaliser ===
* '''FPGA :'''
** Récupération des signaux codeurs ;
** Interprétation des signaux et comptage ;
** Écriture de la mesure sur un bus ;
** Lecture de la consigne d'asservissement ;
** Asservissement et génération de la consigne moteur.

* '''Électronique de puissance : '''
** Carte de conversion consigne (signaux logiques) en commande (tension avec puissance) ;
** Éventuelle protection en tension et en courant de la carte.

=== Caractéristiques ===
Les moteurs utilisés peuvent être de deux types différents :
* ''Graupner Speed 720 BB Torque.''
Alimenté en '''0-12V''' avec des courants max de '''3A''' et des courants moyens de 750mA.
* ''Faulhaber 3557K024CS.''
Alimenté en '''0-24V''' avec des courants max de '''1,1A''' et des courants moyens de 65mA.

Ces deux types de moteurs représentent des cas très usités, il conviendra donc d'avoir une carte de puissance permettant d'assumer ces deux configurations.

= Suivi des séances =
== Semaine 1 (5/02) ==
Élaboration du cahier des charges étendu.
Réflexion sur les différentes étapes à réaliser pour arriver au bout du projet.



== Semaine 2 (12/02) ==
Nous commençons notre programmation sur le logiciel Altium afin d'utiliser le FPGA de la nanoboard.
Le premier module sera un module de génération de PWM (Pulse Width Modulation) afin de pouvoir contrôler les moteurs au travers de la carte de puissance. Ce module est paramétré par une valeur codée sur 1 octet (entre 0 et 255) qui permet de changer la valeur du rapport cyclique.
*Si on a '''0''', rapport cyclique = '''0%''' , sortie = '''0V''' (état bas)
*Si on a '''127''', rapport cyclique = '''50%''' , sortie = 50% état haut et 50% état bas
*Si on a '''255''', rapport cyclique = '''100%''', sortie = '''3V3''' (état haut)

Nous commençons aussi la réflexion sur les méthodes de décodage de signaux de quadratures de phases. Les résultats sont peu concluant, la solution trouvée test chaque configuration possible des signaux avant de traduire la configuration en un comptage ou un décomptage. La résolution est limité au nombre de pas par tours du codeur.

== Semaine 3 (19/02) ==
Fin du codage de la PWM. Ci dessous un image montrant une PWM de rapport cyclique 33% donc avec 0x3F en entrée.

[[Fichier:PWM_3F.png | 500px]]

Dans le cadre du projet et du développement du robot de la coupe de France 2014, nous avons besoin d'un module de communication série afin de pourvoir avoir un dialogue entre le FPGA et d'autres contrôleurs (Raspberry Pi, beagleBone...).

Dans un premier temps nous cherchons une IP(Intellectual Property) de communication serie RS232. Et nous testons les différents modules trouvés.

Afin de pouvoir se partager les codes sources et faire un travail collaboratif de manière efficace, nous avons mis en place un repository git sur GitHub. De cette manière tous nos codes seront versionnés et nous pourrons revenir à des versions précédente en cas de problème.

Après une importante tâche de documentation, il s'avère que les composants électroniques du commerces comptent chaque fronts des deux signaux en quadratures de phases, augmentant ainsi la résolution du comptage par 4 et facilitant apparemment le raisonnement.
En étudiant la situation sous forme logique (table de vérité, tableau de karnaugh), nous trouvons une solution à base de quelques ou exclusif.

[[Fichier:Github.jpg]]

== Semaine 4 (26/02) ==
Test de différents modules mais les résultats ne sont pas concluants. Les IP trouvées sont des très lourds et difficiles à mettre en place. Pour les besoins de notre projet nous avons voulons un programme assez simple qui fais juste une communication RS232 sans correction d'erreurs. C'est pourquoi nous décidons finalement de coder nous même le module.

La solution développée sur papier pour le décodage des signaux est mis en place sous Altium, on obtient un comptage/décomptage conforme, mais un tour ne correspond pas exactement à 1024 * 4 pas.

== Semaine 5 (05/03) ==
Afin de s'affranchir d'Altium et de la nanoboard nous décidons de passer sur le logiciel ISE de Xilink. Son avantage est que nous allons pouvoir passer sur une carte de développement différente (la starter board ) et nous pourrons aussi programmer avec la prochaine carte de développement (Spartan-6 LX9
MicroBoard) qui sera commandée prochainement.

Le passage sous Xilink implique la programmation d'un fichier de contraintes afin d'indiquer au logiciel où connecter physiquement nos entrées sorties déclarées dans le programme. Ce fichier sera le seul à changer si l'on veut changer de FPGA car un code VHDL est portable et ne dépends pas du FPGA.

Nous avons donc pris en main le nouveau logiciel et programmer notre premier fichier de contrainte afin de pouvoir essayer notre module de PWM sur la nouvelle carte.

Les problèmes de comptage de la semaine précédente sont identifiés, lors du temps de monté des signaux en quadratures, le FPGA interprète différents niveau de tensions (haut,bas) à cause d'un bruit présent sur le signal. C'est un phénomène similaires aux "rebonds" que l'on trouverait sur un bouton poussoir.
Une solution à base de lissage est essayée, ce n'est pas concluant.

== Semaine 6 (12/03) ==
Début du codage de la partie '''réception''' du module série. Celui-ci sera composé de trois fichiers :
*le fichier de réception série : '''serial_rx'''
*le fichier d'envoi série : '''serial_tx'''
*le fichier de gestion des deux autres fichiers : '''serial_module''', c'est le fichier principal du module, c'est dans celui-là que l'on va instancier dans deux composants serial_rx et serial_tx.

Réception d'une carte de développement FPGA (Spartan-6 LX9 MicroBoard), c'est celle là qui sera intégrée au robot. Programmation du fichier de contraintes et test de cette carte avec un programme simple (allumage d'une LED) afin de vérifier son fonctionnement.

Pour enfin résoudre le problème d'inexactitude du comptage, le problème des "rebonds", nous utilisons un module "debouncer", qui vérifie l’établissement du signal pendant plusieurs fronts d'horloge.
Ce module a été développé par Mickael Coronado, Ingénieur Electronique Analogique / Numérique (Spécialiste FPGA) et Dirigeant (entreprise Inodesign).

== Semaine 7 (19/03) ==
Après quelques difficultés de programmation dû à l'appréhension du VHDL, le module de réception série est fonctionnel. Lorsqu'on lui envoi une donnée grâce à minicom, il l'affiche le code ASCII sur des leds.

Sur l'image suivante, nous avons envoyé le caractère 'a' (code ASCII : 0x97) et l'on voit que l'affichage de 'a' sur les leds fonctionne correctement
[[Fichier:Reception_a.jpg | 500px]]

Début du code d'émission série.

Début du code et du raisonnement de l'asservissement d'un moteur. Assemblage des modules PWM, debouncer, décodeur à quadrature dans un module reprenant toute l'application.

== Semaine 8 (26/03) ==
Fin du code d'émission série, le FPGA est capable d'envoyer une donnée venant des switch de la carte(8 bits) et l'affichage se fait sur minicom.
Par exemple si on envoi 98 en hexadecimal (0110 0010), nous verrons 'b' s'afficher sur minicom car 0x98 correspond au code ASCII du caractère 'b'.

Début de la programmation du module général de la communication série.

Un pilotage d'un moteur à courant continu en vitesse est maintenant possible avec un codeur rotatif.

== Semaine 9 (2/04) ==
Le module de communication série est entièrement fonctionnel, il peut donc être intégré dans n'importe quelle programme VHDL, pour cela il faut le déclarer en tant que composant dans son programme et faire les map des ports nécessaires.

Ce module permet de gérer l'envoi et la réception facilement, au sein d'un programme.

Afin de faciliter l'accès aux différents paramètres d'asservissement et ainsi pouvoir les lires ou les changer, nous décidons de créer un module de mémoire. Celui-ci sera un registre de grande taille dans lequel le module d'asservissement mais aussi un ordinateur comme un Raspberry (par le biais de la communication série) pourra aller lire/écrire.

Valentin est partit pour la semaine complète à Magdebourg (Allemagne) pour une participation à l'Open German Robocup, une pré-coupe de la Robocup, compétition internationale de robotique.
Il y a donc eu une interruption logique de la progression sur son travail.

== Semaine 10 (9/04) ==
Début de la programmation du module prenant en charge le composant série et le registre avec le protocole série d'accès aux données.

Le module du registre est relativement simple à coder puisqu'il s'agit de déclarer un grand registre et d'y faire des alias afin d'avoir un accès simplifié.

Test de communication entre le port série et le registre. Pour cela on a créé un module instanciant les composants serial_module et register_module. Ce module va écouter le port série et si une donnée arrive et correspond à une valeur particulière, il écrira dans le registre la valeur en question. Puis, il ira chercher la valeur écrite dans le registre afin de la renvoyer et de vérifier que la donnée du registre correspond à la donnée envoyée.

Maintenant, nous voulons modifier ce module afin qu'il puisse aller écrire au bon endroit dans le registre. Nous allons donc créer un protocole d'envoi des données, de cette manière suivant l'adresse et la donnée reçue nous pourrons mettre à jour le registre mais aussi renvoyer une valeur du registre.

L'ordinateur connecté au FPGA pourra donc récupérer les valeurs des asservissement et de déplacement. Il pourra aussi modifier ces valeurs afin de donner des ordres au robot (exemple : avancer à une vitesse particulière).

Le protocole est le suivant :
*Premier octet, initialisation : 0x00
*Deuxième octet, ordre :
**0x01 : lecture
**0x02 : écriture
*Troisième octet, adresse : entre 0x00 et 0x17 (24 adresses possibles)
*Quatrième octet, données : entre 0x00 et 0xFF
*Cinquième octet, fin : 0xFF

Le FPGA n'aura jamais à demander d'informations au Raspberry par conséquent, lorsqu'il y aura une demande de lecture, le FPGA renverra directement la valeur demandée sans utilisation de protocole particulier.

== Semaine 11 (16/04) ==
On a continué à programmer le protocole, des difficultés ont été rencontrées dans l'instanciation et le mappage des différentes entrées sorties afin d'utiliser correctement les modules à inclure (serial_module et register_module). Ces difficultés sont dues au faite que c'est la première fois où l'on fait un mappage complet prenant en compte deux composants annexes.
La programmation n'est aujourd'hui (15/04/2014) pas encore fini du à un retard dans les phases de tests, il sera prochainement finalisé en vue d'une implantation dans un module principal de gestion du déplacement du robot qui sera programmé dans le FPGA du robot.

== A venir ==
Création d'un programme C sur Raspberry afin de faire des échanges de données avec le FPGA et création de l'intelligence du robot.

= Descriptif technique =
== Carte de puissance ==
La carte de puissance permet de connecter 2 moteurs entre 12 et 55V consommant jusqu'à 3A grâce à deux ponts en H (LMD18200). Ces moteurs seront contrôlés par une modulation par largeur d'impulsion (PWM).

=== Schéma électrique ===
[[Fichier:Schema_carte_puissance.PNG | 500px]]

=== PCB ===
[[Fichier:CartePuissance_Moteurs.png | 500px]]

== Communication série ==
La communication fonctionne à une vitesse fixée dans le programme, par défaut à 9600 bauds. Elle est 8N1 c'est à dire 8 bits de données, pas de parité et 1 bit de stop.
Elle peut être implantée sur n'importe qu'elle FPGA car elle n'utilise aucune librairie propre à un constructeur.

== Registre mémoire ==
Le registre mémoire est un registre de grande taille sur lequel on va lire et écrire des données de différentes tailles.

== Asservissement ==
Il peut être intéressant de réaliser un asservissement polaire d'un robot (en angle et en distance) en utilisant deux moteurs de propulsions, de la mesure sur les moteurs pour une boucle d'asservissement de vitesse et une mesure sur deux roues libres qui suivent le déplacement.
C'est une réalisation plutôt compliquée, mais les briques principales sont déjà prêtes.

FPGA et roues codeuses

2014-02-05T13:58:04Z

Vvergez : /* Work In Progress */

= Work In Progress =
Cette page est en cours de rédaction et le restera tout le long du projet. Elle sera mise à jour régulièrement (lors des séances de travail). 
La version finale sera disponible le 16 avr. 2014.

= Présentation =
== Aperçu ==
Le sujet propose de réaliser un système simple sur cible FPGA permettant de :
* Lire et décoder une ou plusieurs roues codeuses ;
* Asservir un ou plusieurs moteurs, soit pas-à-pas soir à courant continu.

La cible visée sera un FPGA de chez Xilinx (carte de développement). En parallèle, une carte d'interface de puissance sera réalisée (interface entre FPGA et moteurs).

== Cahier des charges étendu ==
=== Description ===
Ce projet s'inscrit dans le cadre de la réalisation d'un robot mobile autonome, capable de se déplacer avec précision grâce au retour de ses capteurs.
La propulsion du robot est effectuée par deux moteurs à courant-continu, chacun couplé à une roue motrice tandis que le retour sur le déplacement est lui obtenu par deux codeurs à quadratures de phases couplés à des roues de mesures.
Il est aussi possible de récupérer l'information de vitesse des moteurs grâce à des dynamos tachymétriques ou par le biais d'autres codeurs à quadratures de phases directement couplés au moteur.

Pour approcher ce fonctionnement, on travaillera initialement sur un seul codeur et un seul moteur. L'objectif est d'interpréter les signaux en quadratures de phases avec un FPGA et d'effectuer à partir de cette information un asservissement en vitesse du moteur.

Si ce fonctionnement de base est obtenu suffisamment tôt, des améliorations sont envisageables, comme par exemple :
* Commande et mesure pour plusieurs moteurs et codeurs ;
* Pilotage du FPGA par un protocole de communication (série, CAN, I2C, à déterminer …) ;
* Asservissement polaire (cas d'un déplacement de robot) ;
* Calcul d'odométrie.
La liste est non exhaustive.

=== Travail à réaliser ===
* '''FPGA :'''
** Récupération des signaux codeurs ;
** Interprétation des signaux et comptage ;
** Écriture de la mesure sur un bus ;
** Lecture de la consigne d'asservissement ;
** Asservissement et génération de la consigne moteur.

* '''Électronique de puissance : '''
** Carte de conversion consigne (signaux logiques) en commande (tension avec puissance) ;
** Éventuelle protection en tension et en courant de la carte.

=== Caractéristiques ===
Les moteurs utilisés peuvent être de deux types différents :
* ''Graupner Speed 720 BB Torque.''
Alimenté en '''0-12V''' avec des courants max de '''3A''' et des courants moyens de 750mA.
* ''Faulhaber 3557K024CS.''
Alimenté en '''0-24V''' avec des courants max de '''1,1A''' et des courants moyens de 65mA.

Ces deux types de moteurs représentent des cas très usités, il conviendra donc d'avoir une carte de puissance permettant d'assumer ces deux configurations.

= Suivi des séances =

= Descriptif technique =

FPGA et roues codeuses

2014-02-05T13:57:36Z

Vvergez : /* Work In Progress */

= Work In Progress =
Cette page est en cours de rédaction et le restera tout le long du projet. Elle sera mise à jour régulièrement (lors des séances de travail).
La version finale sera disponible le 16 avr. 2014.

= Présentation =
== Aperçu ==
Le sujet propose de réaliser un système simple sur cible FPGA permettant de :
* Lire et décoder une ou plusieurs roues codeuses ;
* Asservir un ou plusieurs moteurs, soit pas-à-pas soir à courant continu.

La cible visée sera un FPGA de chez Xilinx (carte de développement). En parallèle, une carte d'interface de puissance sera réalisée (interface entre FPGA et moteurs).

== Cahier des charges étendu ==
=== Description ===
Ce projet s'inscrit dans le cadre de la réalisation d'un robot mobile autonome, capable de se déplacer avec précision grâce au retour de ses capteurs.
La propulsion du robot est effectuée par deux moteurs à courant-continu, chacun couplé à une roue motrice tandis que le retour sur le déplacement est lui obtenu par deux codeurs à quadratures de phases couplés à des roues de mesures.
Il est aussi possible de récupérer l'information de vitesse des moteurs grâce à des dynamos tachymétriques ou par le biais d'autres codeurs à quadratures de phases directement couplés au moteur.

Pour approcher ce fonctionnement, on travaillera initialement sur un seul codeur et un seul moteur. L'objectif est d'interpréter les signaux en quadratures de phases avec un FPGA et d'effectuer à partir de cette information un asservissement en vitesse du moteur.

Si ce fonctionnement de base est obtenu suffisamment tôt, des améliorations sont envisageables, comme par exemple :
* Commande et mesure pour plusieurs moteurs et codeurs ;
* Pilotage du FPGA par un protocole de communication (série, CAN, I2C, à déterminer …) ;
* Asservissement polaire (cas d'un déplacement de robot) ;
* Calcul d'odométrie.
La liste est non exhaustive.

=== Travail à réaliser ===
* '''FPGA :'''
** Récupération des signaux codeurs ;
** Interprétation des signaux et comptage ;
** Écriture de la mesure sur un bus ;
** Lecture de la consigne d'asservissement ;
** Asservissement et génération de la consigne moteur.

* '''Électronique de puissance : '''
** Carte de conversion consigne (signaux logiques) en commande (tension avec puissance) ;
** Éventuelle protection en tension et en courant de la carte.

=== Caractéristiques ===
Les moteurs utilisés peuvent être de deux types différents :
* ''Graupner Speed 720 BB Torque.''
Alimenté en '''0-12V''' avec des courants max de '''3A''' et des courants moyens de 750mA.
* ''Faulhaber 3557K024CS.''
Alimenté en '''0-24V''' avec des courants max de '''1,1A''' et des courants moyens de 65mA.

Ces deux types de moteurs représentent des cas très usités, il conviendra donc d'avoir une carte de puissance permettant d'assumer ces deux configurations.

= Suivi des séances =

= Descriptif technique =

FPGA et roues codeuses

2014-02-05T13:55:26Z

Vvergez : /* Work In Progress */

= Work In Progress =
----

= Présentation =
== Aperçu ==
Le sujet propose de réaliser un système simple sur cible FPGA permettant de :
* Lire et décoder une ou plusieurs roues codeuses ;
* Asservir un ou plusieurs moteurs, soit pas-à-pas soir à courant continu.

La cible visée sera un FPGA de chez Xilinx (carte de développement). En parallèle, une carte d'interface de puissance sera réalisée (interface entre FPGA et moteurs).

== Cahier des charges étendu ==
=== Description ===
Ce projet s'inscrit dans le cadre de la réalisation d'un robot mobile autonome, capable de se déplacer avec précision grâce au retour de ses capteurs.
La propulsion du robot est effectuée par deux moteurs à courant-continu, chacun couplé à une roue motrice tandis que le retour sur le déplacement est lui obtenu par deux codeurs à quadratures de phases couplés à des roues de mesures.
Il est aussi possible de récupérer l'information de vitesse des moteurs grâce à des dynamos tachymétriques ou par le biais d'autres codeurs à quadratures de phases directement couplés au moteur.

Pour approcher ce fonctionnement, on travaillera initialement sur un seul codeur et un seul moteur. L'objectif est d'interpréter les signaux en quadratures de phases avec un FPGA et d'effectuer à partir de cette information un asservissement en vitesse du moteur.

Si ce fonctionnement de base est obtenu suffisamment tôt, des améliorations sont envisageables, comme par exemple :
* Commande et mesure pour plusieurs moteurs et codeurs ;
* Pilotage du FPGA par un protocole de communication (série, CAN, I2C, à déterminer …) ;
* Asservissement polaire (cas d'un déplacement de robot) ;
* Calcul d'odométrie.
La liste est non exhaustive.

=== Travail à réaliser ===
* '''FPGA :'''
** Récupération des signaux codeurs ;
** Interprétation des signaux et comptage ;
** Écriture de la mesure sur un bus ;
** Lecture de la consigne d'asservissement ;
** Asservissement et génération de la consigne moteur.

* '''Électronique de puissance : '''
** Carte de conversion consigne (signaux logiques) en commande (tension avec puissance) ;
** Éventuelle protection en tension et en courant de la carte.

=== Caractéristiques ===
Les moteurs utilisés peuvent être de deux types différents :
* ''Graupner Speed 720 BB Torque.''
Alimenté en '''0-12V''' avec des courants max de '''3A''' et des courants moyens de 750mA.
* ''Faulhaber 3557K024CS.''
Alimenté en '''0-24V''' avec des courants max de '''1,1A''' et des courants moyens de 65mA.

Ces deux types de moteurs représentent des cas très usités, il conviendra donc d'avoir une carte de puissance permettant d'assumer ces deux configurations.

= Suivi des séances =

= Descriptif technique =

FPGA et roues codeuses

2014-02-05T13:46:18Z

Vvergez :

= Work In Progress =
----

== Cahier des charges étendu ==
=== Description ===
Ce projet s'inscrit dans le cadre de la réalisation d'un robot mobile autonome, capable de se déplacer avec précision grâce au retour de ses capteurs.
La propulsion du robot est effectuée par deux moteurs à courant-continu, chacun couplé à une roue motrice tandis que le retour sur le déplacement est lui obtenu par deux codeurs à quadratures de phases couplés à des roues de mesures.
Il est aussi possible de récupérer l'information de vitesse des moteurs grâce à des dynamos tachymétriques ou par le biais d'autres codeurs à quadratures de phases directement couplés au moteur.

Pour approcher ce fonctionnement, on travaillera initialement sur un seul codeur et un seul moteur. L'objectif est d'interpréter les signaux en quadratures de phases avec un FPGA et d'effectuer à partir de cette information un asservissement en vitesse du moteur.

Si ce fonctionnement de base est obtenu suffisamment tôt, des améliorations sont envisageables, comme par exemple :
* Commande et mesure pour plusieurs moteurs et codeurs ;
* Pilotage du FPGA par un protocole de communication (série, CAN, I2C, à déterminer …) ;
* Asservissement polaire (cas d'un déplacement de robot) ;
* Calcul d'odométrie.
La liste est non exhaustive.

=== Travail à réaliser ===
* '''FPGA :'''
** Récupération des signaux codeurs ;
** Interprétation des signaux et comptage ;
** Écriture de la mesure sur un bus ;
** Lecture de la consigne d'asservissement ;
** Asservissement et génération de la consigne moteur.

* '''Électronique de puissance : '''
** Carte de conversion consigne (signaux logiques) en commande (tension avec puissance) ;
** Éventuelle protection en tension et en courant de la carte.

=== Caractéristiques ===
Les moteurs utilisés peuvent être de deux types différents :
* ''Graupner Speed 720 BB Torque.''
Alimenté en '''0-12V''' avec des courants max de '''3A''' et des courants moyens de 750mA.
* ''Faulhaber 3557K024CS.''
Alimenté en '''0-24V''' avec des courants max de '''1,1A''' et des courants moyens de 65mA.

Ces deux types de moteurs représentent des cas très usités, il conviendra donc d'avoir une carte de puissance permettant d'assumer ces deux configurations.

FPGA et roues codeuses

2014-01-30T17:55:35Z

Vvergez : Page créée avec « = En Construction = ---- »

= En Construction =
----

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T16:37:02Z

Vvergez : /* Rapports des élèves */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

===='''Séance 1'''====

La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

===='''Séance 2'''====

Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

===='''Séance 3'''====

Cette séance aura été moins productive car on se trouve déjà en phase d'intégration électronique/informatique. 
La partie électronique n'étant pas encore totalement aboutie, la majeure partie de nos efforts a été consacrée à cette dernière.

La partie électronique a pour objectif de récupérer des informations de capteurs de pression pour ensuite les envoyer à la FoxBoard qui doit les traiter. 
Un simple cercle de couleur a été ajouté pour représenter la pression exercée sur le premier capteur. Si le capteur ne capte aucune pression, on reçoit la valeur 255 et le cercle est vert. En revanche plus la pression est forte plus la valeur tend vers 0 et alors le cercle vire au noir.

<center>[[Fichier:AccéléromètreVERT.png|400px|Capteur de pression relâché]][[Fichier:AccéléromètreNOIR.png|400px|Capteur de pression au maximum]]</center>

Initialement il était prévu de gérer la communication série avec la NanoBoard (partie électronique) par émission d'un octet puis réception de quatre octets avec les trois mesures des capteurs de pression. 
Seulement la communication série avec la NanoBoard nous a causé de nombreux soucis, nous n'arrivions pas à maîtriser les blocs fonctionnels que l'on nous a fourni. Nous avons donc changé de stratégie.
 

Les informations sont envoyées en continues et précédées par un 0 (le capteur de pression n'atteint jamais 0) pour pouvoir repérer à quels capteurs correspondent les valeurs. Nous nous servons en fait de la valeur 0 comme d'un marqueur de début d'information. 
Pour mettre en oeuvre ce filtrage des octets avant que la partie électronique ne soit finalisée, la solution adoptée a été de simuler le comportement de la NanoBoard. En effet avec un logiciel tel que [http://manpages.ubuntu.com/manpages/lucid/man1/socat.1.html socat], il est possible de rediriger logiciellement un port vers un autre. 
Partant de là il a été très simple d'envoyer sur un port une série de plusieurs octets aléatoires précédés d'un 0 et ceux répété à l'infini, avec la redirection il a alors été possible de recevoir ces octets comme s'ils provenaient de la FoxBoard. 
Cette technique de travail nous aura été très bénéfique puisqu'elle nous a permis de faire des tests sans avoir à attendre l'aboutissement de l'entité électronique.

Ce nouveau mode de fonctionnement, après quelques heures de travail supplémentaire, est totalement fonctionnel. Nous pouvons considérer notre application, à l'asservissement près, comme étant aboutie.

Vous pouvez accéder aux codes de l'application en suivant ce lien : 
[https://sourceforge.net/projects/scbrasrobotique/files/ Bras Robotique (Codes Source)]

=== '''PARTIE ELECTRONIQUE''' ===

===='''Séance 1'''====

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

<center>[[Fichier:Schéma_à_faire.png|1000px]]</center>

Le Convertisseur analogique numérique, à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

Schéma de déroulement :

<center>[[Fichier:Partienumetanal.png|1000px]]</center>

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Une fois le sujet appréhendé, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionne. Nous avons ensuite créé notre propre PWM dont voilà le schéma : 

<center>[[Fichier:Seance1.png]] </center>

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz. 

<center>[[Fichier:Fonctionnement PWM.png|900px|Exemple de MLI]] </center>

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

===='''Séance 2'''====

<center>[[Fichier:Basculepourmemorisation.png|450px]]</center>
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

<center>[[Fichier:Schéma électrique.png]]</center>

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

===='''Séance 3'''====

Voici les tests effectués lors de la troisième séance :

<center>[[Fichier:Scope_4.png|schema 1|600px]]</center>

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

<center>[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|500px]]</center>

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

<center>[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px]]</center>

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

===='''Séance 4 (Supplémentaire)'''====

Voici le schéma complet d'Altium :

<center>[[Fichier:Altium1.png|schéma complet|900px]]</center>

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc (constitué d'un multiplexeur et d'un compteur) pour simuler 4 capteurs :

<center>[[Fichier:Altium2.png|schéma complet|900px]]</center>

Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies (multiplexeur) où se situent les données à envoyer. La première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

Les tests à effectuer dans cette partie ont été les plus long. En effet il a fallu faire des tests complets afin d'être sur de ce qu'y été envoyé sur le port série. Nous avons tout d'abord utilisé un Arduino de manière à visualiser facilement les données envoyées et ainsi se passer de la partie informatique et s'assurer du bon fonctionnement de l'émission. Or, il s'est avéré que la configuration par défaut de la communication série de celui-ci n'était pas compatible avec notre système. Nous avons pu déceler les problèmes au moyen de l'analyseur logique, et avons décider ensuite de réaliser la communication avec la partie informatique.

Après s'être assuré du bon fonctionnement de l'envoi d'une donnée sur le port série, nous avons rajouter le bloc afin de simuler l'envoi de
4 données simultanées, ce qui pourrait correspondre à 4 capteurs de pression (ce nombre peut être facilement augmenté).

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T00:56:44Z

Vvergez : /* Séance 3 */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===
Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

==='''Séance 3'''===
Cette séance aura été moins productive car on se trouve déjà en phase d'intégration électronique/informatique. 
La partie électronique n'étant pas encore totalement aboutie, la majeure partie de nos efforts a été consacrée à cette dernière.

La partie électronique a pour objectif de récupérer des informations de capteurs de pression pour ensuite les envoyer à la FoxBoard qui doit les traiter. 
Un simple cercle de couleur a été ajouté pour représenter la pression exercée sur le premier capteur. Si le capteur ne capte aucune pression, on reçoit la valeur 255 et le cercle est vert. En revanche plus la pression est forte plus la valeur tend vers 0 et alors le cercle vire au noir.

<center>[[Fichier:AccéléromètreVERT.png|400px|Capteur de pression relâché]][[Fichier:AccéléromètreNOIR.png|400px|Capteur de pression au maximum]]</center>

Initialement il était prévu de gérer la communication série avec la NanoBoard (partie électronique) par émission d'un octet puis réception de quatre octets avec les trois mesures des capteurs de pression. 
Seulement la communication série avec la NanoBoard nous a causé de nombreux soucis, nous n'arrivions pas à maîtriser les blocs fonctionnels que l'on nous a fourni. Nous avons donc changé de stratégie.
 

Les informations sont envoyées en continues et précédées par un 0 (le capteur de pression n'atteint jamais 0) pour pouvoir repérer à quels capteurs correspondent les valeurs. Nous nous servons en fait de la valeur 0 comme d'un marqueur de début d'information. 
Pour mettre en oeuvre ce filtrage des octets avant que la partie électronique ne soit finalisée, la solution adoptée a été de simuler le comportement de la NanoBoard. En effet avec un logiciel tel que [http://manpages.ubuntu.com/manpages/lucid/man1/socat.1.html socat], il est possible de rediriger logiciellement un port vers un autre. 
Partant de là il a été très simple d'envoyer sur un port une série de plusieurs octets aléatoires précédés d'un 0 et ceux répété à l'infini, avec la redirection il a alors été possible de recevoir ces octets comme s'ils provenaient de la FoxBoard. 
Cette technique de travail nous aura été très bénéfique puisqu'elle nous a permis de faire des tests sans avoir à attendre l'aboutissement de l'entité électronique.

Ce nouveau mode de fonctionnement, après quelques heures de travail supplémentaire, est totalement fonctionnel. Nous pouvons considérer notre application, à l'asservissement près, comme étant aboutie.

Vous pouvez accéder aux codes de l'application en suivant ce lien : 
[https://sourceforge.net/projects/scbrasrobotique/files/ Bras Robotique (Codes Source)]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

<center>[[Fichier:Schéma_à_faire.png|1000px]]</center>

Le Convertisseur analogique numérique, à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

Schéma de déroulement :

<center>[[Fichier:Partienumetanal.png|1000px]]</center>

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Une fois le sujet appréhendé, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionne. Nous avons ensuite créé notre propre PWM dont voilà le schéma : 

<center>[[Fichier:Seance1.png]] </center>

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz. 

<center>[[Fichier:Fonctionnement PWM.png|900px|Exemple de MLI]] </center>

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

<center>[[Fichier:Basculepourmemorisation.png|450px]]</center>
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

<center>[[Fichier:Schéma électrique.png]]</center>

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===
Voici les tests effectués lors de la troisième séance :

<center>[[Fichier:Scope_4.png|schema 1|600px]]</center>

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

<center>[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|500px]]</center>

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

<center>[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px]]</center>

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

<center>[[Fichier:Altium1.png|schéma complet|900px]]</center>

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc (constitué d'un multiplexeur et d'un compteur) pour simuler 4 capteurs :

<center>[[Fichier:Altium2.png|schéma complet|900px]]</center>

Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies (multiplexeur) où se situent les données à envoyer. La première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

Les tests à effectuer dans cette partie ont été les plus long. En effet il a fallu faire des tests complets afin d'être sur de ce qu'y été envoyé sur le port série. Nous avons tout d'abord utilisé un Arduino de manière à visualiser facilement les données envoyées et ainsi se passer de la partie informatique et s'assurer du bon fonctionnement de l'émission. Or, il s'est avéré que la configuration par défaut de la communication série de celui-ci n'était pas compatible avec notre système. Nous avons pu déceler les problèmes au moyen de l'analyseur logique, et avons décider ensuite de réaliser la communication avec la partie informatique.

Après s'être assuré du bon fonctionnement de l'envoi d'une donnée sur le port série, nous avons rajouter le bloc afin de simuler l'envoi de
4 données simultanées, ce qui pourrait correspondre à 4 capteurs de pression (ce nombre peut être facilement augmenté).

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T00:49:29Z

Vvergez : /* Séance 2 : */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===
Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

==='''Séance 3'''===
Cette séance aura été moins productive car on se trouve déjà en phase d'intégration électronique/informatique. 
La partie électronique n'étant pas encore totalement aboutie, la majeure partie de nos efforts a été consacrée à cette dernière.

La partie électronique a pour objectif de récupérer des informations de capteurs de pression pour ensuite les envoyer à la FoxBoard qui doit les traiter. 
Un simple cercle de couleur a été ajouté pour représenter la pression exercée sur le premier capteur. Si le capteur ne capte aucune pression, on reçoit la valeur 255 et le cercle est vert. En revanche plus la pression est forte plus la valeur tend vers 0 et alors le cercle vire au noir.

<center>[[Fichier:AccéléromètreVERT.png|400px|Capteur de pression relâché]][[Fichier:AccéléromètreNOIR.png|400px|Capteur de pression au maximum]]</center>

Initialement il était prévu de gérer la communication série avec la NanoBoard (partie électronique) par émission d'un octet puis réception de quatre octets avec les trois mesures des capteurs de pression. 
Seulement la communication série avec la NanoBoard nous a causé de nombreux soucis, nous n'arrivions pas à maîtriser les blocs fonctionnels que l'on nous a fourni. Nous avons donc changé de stratégie.
 

Les informations sont envoyées en continues et précédées par un 0 (le capteur de pression n'atteint jamais 0) pour pouvoir repérer à quels capteurs correspondent les valeurs. Nous nous servons en fait de la valeur 0 comme d'un marqueur de début d'information. 
Ce nouveau mode de fonctionnement, après quelques heures de travail supplémentaire, est totalement fonctionnel. Nous pouvons considérer notre application, à l'asservissement près, comme étant aboutie.

Vous pouvez accéder aux codes de l'application en suivant ce lien : 
[https://sourceforge.net/projects/scbrasrobotique/files/ Bras Robotique (Codes Source)]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

<center>[[Fichier:Schéma_à_faire.png|1000px]]</center>

Le Convertisseur analogique numérique, à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

Schéma de déroulement :

<center>[[Fichier:Partienumetanal.png|1000px]]</center>

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Une fois le sujet appréhendé, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionne. Nous avons ensuite créé notre propre PWM dont voilà le schéma : 

<center>[[Fichier:Seance1.png]] </center>

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz. 

<center>[[Fichier:Fonctionnement PWM.png|900px|Exemple de MLI]] </center>

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

<center>[[Fichier:Basculepourmemorisation.png|450px]]</center>
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

<center>[[Fichier:Schéma électrique.png]]</center>

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===
Voici les tests effectués lors de la troisième séance :

<center>[[Fichier:Scope_4.png|schema 1|600px]]</center>

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

<center>[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|500px]]</center>

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

<center>[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px]]</center>

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

<center>[[Fichier:Altium1.png|schéma complet|900px]]</center>

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc (constitué d'un multiplexeur et d'un compteur) pour simuler 4 capteurs :

<center>[[Fichier:Altium2.png|schéma complet|900px]]</center>

Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies (multiplexeur) où se situent les données à envoyer. La première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

Les tests à effectuer dans cette partie ont été les plus long. En effet il a fallu faire des tests complets afin d'être sur de ce qu'y été envoyé sur le port série. Nous avons tout d'abord utilisé un Arduino de manière à visualiser facilement les données envoyées et ainsi se passer de la partie informatique et s'assurer du bon fonctionnement de l'émission. Or, il s'est avéré que la configuration par défaut de la communication série de celui-ci n'était pas compatible avec notre système. Nous avons pu déceler les problèmes au moyen de l'analyseur logique, et avons décider ensuite de réaliser la communication avec la partie informatique.

Après s'être assuré du bon fonctionnement de l'envoi d'une donnée sur le port série, nous avons rajouter le bloc afin de simuler l'envoi de
4 données simultanées, ce qui pourrait correspondre à 4 capteurs de pression (ce nombre peut être facilement augmenté).

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T00:47:42Z

Vvergez : /* Séance 3 : */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===
Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

==='''Séance 3'''===
Cette séance aura été moins productive car on se trouve déjà en phase d'intégration électronique/informatique. 
La partie électronique n'étant pas encore totalement aboutie, la majeure partie de nos efforts a été consacrée à cette dernière.

La partie électronique a pour objectif de récupérer des informations de capteurs de pression pour ensuite les envoyer à la FoxBoard qui doit les traiter. 
Un simple cercle de couleur a été ajouté pour représenter la pression exercée sur le premier capteur. Si le capteur ne capte aucune pression, on reçoit la valeur 255 et le cercle est vert. En revanche plus la pression est forte plus la valeur tend vers 0 et alors le cercle vire au noir.

<center>[[Fichier:AccéléromètreVERT.png|400px|Capteur de pression relâché]][[Fichier:AccéléromètreNOIR.png|400px|Capteur de pression au maximum]]</center>

Initialement il était prévu de gérer la communication série avec la NanoBoard (partie électronique) par émission d'un octet puis réception de quatre octets avec les trois mesures des capteurs de pression. 
Seulement la communication série avec la NanoBoard nous a causé de nombreux soucis, nous n'arrivions pas à maîtriser les blocs fonctionnels que l'on nous a fourni. Nous avons donc changé de stratégie.
 

Les informations sont envoyées en continues et précédées par un 0 (le capteur de pression n'atteint jamais 0) pour pouvoir repérer à quels capteurs correspondent les valeurs. Nous nous servons en fait de la valeur 0 comme d'un marqueur de début d'information. 
Ce nouveau mode de fonctionnement, après quelques heures de travail supplémentaire, est totalement fonctionnel. Nous pouvons considérer notre application, à l'asservissement près, comme étant aboutie.

Vous pouvez accéder aux codes de l'application en suivant ce lien : 
[https://sourceforge.net/projects/scbrasrobotique/files/ Bras Robotique (Codes Source)]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

<center>[[Fichier:Schéma_à_faire.png|1000px]]</center>

Le Convertisseur analogique numérique, à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

Schéma de déroulement :

<center>[[Fichier:Partienumetanal.png|1000px]]</center>

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Une fois le sujet appréhendé, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionne. Nous avons ensuite créé notre propre PWM dont voilà le schéma : 

<center>[[Fichier:Seance1.png]] </center>

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz. 

<center>[[Fichier:Fonctionnement PWM.png|900px|Exemple de MLI]] </center>

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===
Voici les tests effectués lors de la troisième séance :

<center>[[Fichier:Scope_4.png|schema 1|600px]]</center>

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

<center>[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|500px]]</center>

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

<center>[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px]]</center>

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

<center>[[Fichier:Altium1.png|schéma complet|900px]]</center>

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc (constitué d'un multiplexeur et d'un compteur) pour simuler 4 capteurs :

<center>[[Fichier:Altium2.png|schéma complet|900px]]</center>

Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies (multiplexeur) où se situent les données à envoyer. La première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

Les tests à effectuer dans cette partie ont été les plus long. En effet il a fallu faire des tests complets afin d'être sur de ce qu'y été envoyé sur le port série. Nous avons tout d'abord utilisé un Arduino de manière à visualiser facilement les données envoyées et ainsi se passer de la partie informatique et s'assurer du bon fonctionnement de l'émission. Or, il s'est avéré que la configuration par défaut de la communication série de celui-ci n'était pas compatible avec notre système. Nous avons pu déceler les problèmes au moyen de l'analyseur logique, et avons décider ensuite de réaliser la communication avec la partie informatique.

Après s'être assuré du bon fonctionnement de l'envoi d'une donnée sur le port série, nous avons rajouter le bloc afin de simuler l'envoi de
4 données simultanées, ce qui pourrait correspondre à 4 capteurs de pression (ce nombre peut être facilement augmenté).

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T00:46:46Z

Vvergez : /* Séance 3 : */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===
Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

==='''Séance 3'''===
Cette séance aura été moins productive car on se trouve déjà en phase d'intégration électronique/informatique. 
La partie électronique n'étant pas encore totalement aboutie, la majeure partie de nos efforts a été consacrée à cette dernière.

La partie électronique a pour objectif de récupérer des informations de capteurs de pression pour ensuite les envoyer à la FoxBoard qui doit les traiter. 
Un simple cercle de couleur a été ajouté pour représenter la pression exercée sur le premier capteur. Si le capteur ne capte aucune pression, on reçoit la valeur 255 et le cercle est vert. En revanche plus la pression est forte plus la valeur tend vers 0 et alors le cercle vire au noir.

<center>[[Fichier:AccéléromètreVERT.png|400px|Capteur de pression relâché]][[Fichier:AccéléromètreNOIR.png|400px|Capteur de pression au maximum]]</center>

Initialement il était prévu de gérer la communication série avec la NanoBoard (partie électronique) par émission d'un octet puis réception de quatre octets avec les trois mesures des capteurs de pression. 
Seulement la communication série avec la NanoBoard nous a causé de nombreux soucis, nous n'arrivions pas à maîtriser les blocs fonctionnels que l'on nous a fourni. Nous avons donc changé de stratégie.
 

Les informations sont envoyées en continues et précédées par un 0 (le capteur de pression n'atteint jamais 0) pour pouvoir repérer à quels capteurs correspondent les valeurs. Nous nous servons en fait de la valeur 0 comme d'un marqueur de début d'information. 
Ce nouveau mode de fonctionnement, après quelques heures de travail supplémentaire, est totalement fonctionnel. Nous pouvons considérer notre application, à l'asservissement près, comme étant aboutie.

Vous pouvez accéder aux codes de l'application en suivant ce lien : 
[https://sourceforge.net/projects/scbrasrobotique/files/ Bras Robotique (Codes Source)]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

<center>[[Fichier:Schéma_à_faire.png|1000px]]</center>

Le Convertisseur analogique numérique, à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

Schéma de déroulement :

<center>[[Fichier:Partienumetanal.png|1000px]]</center>

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Une fois le sujet appréhendé, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionne. Nous avons ensuite créé notre propre PWM dont voilà le schéma : 

<center>[[Fichier:Seance1.png]] </center>

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz. 

<center>[[Fichier:Fonctionnement PWM.png|900px|Exemple de MLI]] </center>

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===
Voici les tests effectués lors de la troisième séance :

<center>[[Fichier:Scope_4.png|schema 1|600px]]</center>

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

<center>[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|350px]]</center>

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

<center>[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px]]</center>

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

<center>[[Fichier:Altium1.png|schéma complet|900px]]</center>

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc (constitué d'un multiplexeur et d'un compteur) pour simuler 4 capteurs :

<center>[[Fichier:Altium2.png|schéma complet|900px]]</center>

Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies (multiplexeur) où se situent les données à envoyer. La première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

Les tests à effectuer dans cette partie ont été les plus long. En effet il a fallu faire des tests complets afin d'être sur de ce qu'y été envoyé sur le port série. Nous avons tout d'abord utilisé un Arduino de manière à visualiser facilement les données envoyées et ainsi se passer de la partie informatique et s'assurer du bon fonctionnement de l'émission. Or, il s'est avéré que la configuration par défaut de la communication série de celui-ci n'était pas compatible avec notre système. Nous avons pu déceler les problèmes au moyen de l'analyseur logique, et avons décider ensuite de réaliser la communication avec la partie informatique.

Après s'être assuré du bon fonctionnement de l'envoi d'une donnée sur le port série, nous avons rajouter le bloc afin de simuler l'envoi de
4 données simultanées, ce qui pourrait correspondre à 4 capteurs de pression (ce nombre peut être facilement augmenté).

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T00:44:31Z

Vvergez : /* Séance 3 : */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===
Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

==='''Séance 3'''===
Cette séance aura été moins productive car on se trouve déjà en phase d'intégration électronique/informatique. 
La partie électronique n'étant pas encore totalement aboutie, la majeure partie de nos efforts a été consacrée à cette dernière.

La partie électronique a pour objectif de récupérer des informations de capteurs de pression pour ensuite les envoyer à la FoxBoard qui doit les traiter. 
Un simple cercle de couleur a été ajouté pour représenter la pression exercée sur le premier capteur. Si le capteur ne capte aucune pression, on reçoit la valeur 255 et le cercle est vert. En revanche plus la pression est forte plus la valeur tend vers 0 et alors le cercle vire au noir.

<center>[[Fichier:AccéléromètreVERT.png|400px|Capteur de pression relâché]][[Fichier:AccéléromètreNOIR.png|400px|Capteur de pression au maximum]]</center>

Initialement il était prévu de gérer la communication série avec la NanoBoard (partie électronique) par émission d'un octet puis réception de quatre octets avec les trois mesures des capteurs de pression. 
Seulement la communication série avec la NanoBoard nous a causé de nombreux soucis, nous n'arrivions pas à maîtriser les blocs fonctionnels que l'on nous a fourni. Nous avons donc changé de stratégie.
 

Les informations sont envoyées en continues et précédées par un 0 (le capteur de pression n'atteint jamais 0) pour pouvoir repérer à quels capteurs correspondent les valeurs. Nous nous servons en fait de la valeur 0 comme d'un marqueur de début d'information. 
Ce nouveau mode de fonctionnement, après quelques heures de travail supplémentaire, est totalement fonctionnel. Nous pouvons considérer notre application, à l'asservissement près, comme étant aboutie.

Vous pouvez accéder aux codes de l'application en suivant ce lien : 
[https://sourceforge.net/projects/scbrasrobotique/files/ Bras Robotique (Codes Source)]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

<center>[[Fichier:Schéma_à_faire.png|1000px]]</center>

Le Convertisseur analogique numérique, à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

Schéma de déroulement :

<center>[[Fichier:Partienumetanal.png|1000px]]</center>

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Une fois le sujet appréhendé, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionne. Nous avons ensuite créé notre propre PWM dont voilà le schéma : 

<center>[[Fichier:Seance1.png]] </center>

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz. 

<center>[[Fichier:Fonctionnement PWM.png|900px|Exemple de MLI]] </center>

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===
Voici les tests effectués lors de la troisième séance :

<center>[[Fichier:Scope_4.png|schema 1|600px]]</center>

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

<center>[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|350px]]</center>

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

<center>[[Fichier:Altium1.png|schéma complet|900px]]</center>

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc (constitué d'un multiplexeur et d'un compteur) pour simuler 4 capteurs :

<center>[[Fichier:Altium2.png|schéma complet|900px]]</center>

Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies (multiplexeur) où se situent les données à envoyer. La première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T00:43:39Z

Vvergez : /* Séance 4 (Supplémentaire) : */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===
Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

==='''Séance 3'''===
Cette séance aura été moins productive car on se trouve déjà en phase d'intégration électronique/informatique. 
La partie électronique n'étant pas encore totalement aboutie, la majeure partie de nos efforts a été consacrée à cette dernière.

La partie électronique a pour objectif de récupérer des informations de capteurs de pression pour ensuite les envoyer à la FoxBoard qui doit les traiter. 
Un simple cercle de couleur a été ajouté pour représenter la pression exercée sur le premier capteur. Si le capteur ne capte aucune pression, on reçoit la valeur 255 et le cercle est vert. En revanche plus la pression est forte plus la valeur tend vers 0 et alors le cercle vire au noir.

<center>[[Fichier:AccéléromètreVERT.png|400px|Capteur de pression relâché]][[Fichier:AccéléromètreNOIR.png|400px|Capteur de pression au maximum]]</center>

Initialement il était prévu de gérer la communication série avec la NanoBoard (partie électronique) par émission d'un octet puis réception de quatre octets avec les trois mesures des capteurs de pression. 
Seulement la communication série avec la NanoBoard nous a causé de nombreux soucis, nous n'arrivions pas à maîtriser les blocs fonctionnels que l'on nous a fourni. Nous avons donc changé de stratégie.
 

Les informations sont envoyées en continues et précédées par un 0 (le capteur de pression n'atteint jamais 0) pour pouvoir repérer à quels capteurs correspondent les valeurs. Nous nous servons en fait de la valeur 0 comme d'un marqueur de début d'information. 
Ce nouveau mode de fonctionnement, après quelques heures de travail supplémentaire, est totalement fonctionnel. Nous pouvons considérer notre application, à l'asservissement près, comme étant aboutie.

Vous pouvez accéder aux codes de l'application en suivant ce lien : 
[https://sourceforge.net/projects/scbrasrobotique/files/ Bras Robotique (Codes Source)]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

<center>[[Fichier:Schéma_à_faire.png|1000px]]</center>

Le Convertisseur analogique numérique, à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

Schéma de déroulement :

<center>[[Fichier:Partienumetanal.png|1000px]]</center>

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Une fois le sujet appréhendé, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionne. Nous avons ensuite créé notre propre PWM dont voilà le schéma : 

<center>[[Fichier:Seance1.png]] </center>

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz. 

<center>[[Fichier:Fonctionnement PWM.png|900px|Exemple de MLI]] </center>

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

<center>[[Fichier:Altium1.png|schéma complet|900px]]</center>

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc (constitué d'un multiplexeur et d'un compteur) pour simuler 4 capteurs :

<center>[[Fichier:Altium2.png|schéma complet|900px]]</center>

Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies (multiplexeur) où se situent les données à envoyer. La première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T00:41:47Z

Vvergez : /* Séance 1 : */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===
Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

==='''Séance 3'''===
Cette séance aura été moins productive car on se trouve déjà en phase d'intégration électronique/informatique. 
La partie électronique n'étant pas encore totalement aboutie, la majeure partie de nos efforts a été consacrée à cette dernière.

La partie électronique a pour objectif de récupérer des informations de capteurs de pression pour ensuite les envoyer à la FoxBoard qui doit les traiter. 
Un simple cercle de couleur a été ajouté pour représenter la pression exercée sur le premier capteur. Si le capteur ne capte aucune pression, on reçoit la valeur 255 et le cercle est vert. En revanche plus la pression est forte plus la valeur tend vers 0 et alors le cercle vire au noir.

<center>[[Fichier:AccéléromètreVERT.png|400px|Capteur de pression relâché]][[Fichier:AccéléromètreNOIR.png|400px|Capteur de pression au maximum]]</center>

Initialement il était prévu de gérer la communication série avec la NanoBoard (partie électronique) par émission d'un octet puis réception de quatre octets avec les trois mesures des capteurs de pression. 
Seulement la communication série avec la NanoBoard nous a causé de nombreux soucis, nous n'arrivions pas à maîtriser les blocs fonctionnels que l'on nous a fourni. Nous avons donc changé de stratégie.
 

Les informations sont envoyées en continues et précédées par un 0 (le capteur de pression n'atteint jamais 0) pour pouvoir repérer à quels capteurs correspondent les valeurs. Nous nous servons en fait de la valeur 0 comme d'un marqueur de début d'information. 
Ce nouveau mode de fonctionnement, après quelques heures de travail supplémentaire, est totalement fonctionnel. Nous pouvons considérer notre application, à l'asservissement près, comme étant aboutie.

Vous pouvez accéder aux codes de l'application en suivant ce lien : 
[https://sourceforge.net/projects/scbrasrobotique/files/ Bras Robotique (Codes Source)]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

<center>[[Fichier:Schéma_à_faire.png|1000px]]</center>

Le Convertisseur analogique numérique, à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

Schéma de déroulement :

<center>[[Fichier:Partienumetanal.png|1000px]]</center>

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Une fois le sujet appréhendé, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionne. Nous avons ensuite créé notre propre PWM dont voilà le schéma : 

<center>[[Fichier:Seance1.png]] </center>

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz. 

<center>[[Fichier:Fonctionnement PWM.png|900px|Exemple de MLI]] </center>

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

[[Fichier:Altium1.png|schéma complet|1400px]]

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc (constitué d'un multiplexeur et d'un compteur) pour simuler 4 capteurs :

[[Fichier:Altium2.png|schéma complet|900px|droite]]
Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies (multiplexeur) où se situent les données à envoyer. La première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T00:40:22Z

Vvergez : /* Séance 1 : */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===
Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

==='''Séance 3'''===
Cette séance aura été moins productive car on se trouve déjà en phase d'intégration électronique/informatique. 
La partie électronique n'étant pas encore totalement aboutie, la majeure partie de nos efforts a été consacrée à cette dernière.

La partie électronique a pour objectif de récupérer des informations de capteurs de pression pour ensuite les envoyer à la FoxBoard qui doit les traiter. 
Un simple cercle de couleur a été ajouté pour représenter la pression exercée sur le premier capteur. Si le capteur ne capte aucune pression, on reçoit la valeur 255 et le cercle est vert. En revanche plus la pression est forte plus la valeur tend vers 0 et alors le cercle vire au noir.

<center>[[Fichier:AccéléromètreVERT.png|400px|Capteur de pression relâché]][[Fichier:AccéléromètreNOIR.png|400px|Capteur de pression au maximum]]</center>

Initialement il était prévu de gérer la communication série avec la NanoBoard (partie électronique) par émission d'un octet puis réception de quatre octets avec les trois mesures des capteurs de pression. 
Seulement la communication série avec la NanoBoard nous a causé de nombreux soucis, nous n'arrivions pas à maîtriser les blocs fonctionnels que l'on nous a fourni. Nous avons donc changé de stratégie.
 

Les informations sont envoyées en continues et précédées par un 0 (le capteur de pression n'atteint jamais 0) pour pouvoir repérer à quels capteurs correspondent les valeurs. Nous nous servons en fait de la valeur 0 comme d'un marqueur de début d'information. 
Ce nouveau mode de fonctionnement, après quelques heures de travail supplémentaire, est totalement fonctionnel. Nous pouvons considérer notre application, à l'asservissement près, comme étant aboutie.

Vous pouvez accéder aux codes de l'application en suivant ce lien : 
[https://sourceforge.net/projects/scbrasrobotique/files/ Bras Robotique (Codes Source)]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

<center>[[Fichier:Schéma_à_faire.png|1000px]]</center>

Le Convertisseur analogique numérique, à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

Schéma de déroulement :

<center>[[Fichier:Partienumetanal.png|1000px]]</center>

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Une fois le sujet appréhendé, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionne. Nous avons ensuite créé notre propre PWM dont voilà le schéma :

<center>[[Fichier:Seance1.png]] </center>

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz.

<center>[[Fichier:Fonctionnement PWM.png|vignette|900px|Exemple de MLI]] </center>

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

[[Fichier:Altium1.png|schéma complet|1400px]]

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc (constitué d'un multiplexeur et d'un compteur) pour simuler 4 capteurs :

[[Fichier:Altium2.png|schéma complet|900px|droite]]
Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies (multiplexeur) où se situent les données à envoyer. La première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T00:29:08Z

Vvergez : /* Séance 3 */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===
Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

==='''Séance 3'''===
Cette séance aura été moins productive car on se trouve déjà en phase d'intégration électronique/informatique. 
La partie électronique n'étant pas encore totalement aboutie, la majeure partie de nos efforts a été consacrée à cette dernière.

La partie électronique a pour objectif de récupérer des informations de capteurs de pression pour ensuite les envoyer à la FoxBoard qui doit les traiter. 
Un simple cercle de couleur a été ajouté pour représenter la pression exercée sur le premier capteur. Si le capteur ne capte aucune pression, on reçoit la valeur 255 et le cercle est vert. En revanche plus la pression est forte plus la valeur tend vers 0 et alors le cercle vire au noir.

<center>[[Fichier:AccéléromètreVERT.png|400px|Capteur de pression relâché]][[Fichier:AccéléromètreNOIR.png|400px|Capteur de pression au maximum]]</center>

Initialement il était prévu de gérer la communication série avec la NanoBoard (partie électronique) par émission d'un octet puis réception de quatre octets avec les trois mesures des capteurs de pression. 
Seulement la communication série avec la NanoBoard nous a causé de nombreux soucis, nous n'arrivions pas à maîtriser les blocs fonctionnels que l'on nous a fourni. Nous avons donc changé de stratégie.
 

Les informations sont envoyées en continues et précédées par un 0 (le capteur de pression n'atteint jamais 0) pour pouvoir repérer à quels capteurs correspondent les valeurs. Nous nous servons en fait de la valeur 0 comme d'un marqueur de début d'information. 
Ce nouveau mode de fonctionnement, après quelques heures de travail supplémentaire, est totalement fonctionnel. Nous pouvons considérer notre application, à l'asservissement près, comme étant aboutie.

Vous pouvez accéder aux codes de l'application en suivant ce lien : 
[https://sourceforge.net/projects/scbrasrobotique/files/ Bras Robotique (Codes Source)]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

[[Fichier:Schéma_à_faire.png|1000px]]

Le Convertisseur analogique numérique), à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

schéma de déroulement :

[[Fichier:Partienumetanal.png|1000px]]

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Lorsque le sujet était clair, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionner. Nous avons ensuite crée notre propre PWM et nous sommes arrivés à cela :

[[Fichier:Seance1.png]]

[[Fichier:Fonctionnement PWM.png|vignette|900px|Exemple de MLI]]

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz.

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

[[Fichier:Altium1.png|schéma complet|1400px]]

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc (constitué d'un multiplexeur et d'un compteur) pour simuler 4 capteurs :

[[Fichier:Altium2.png|schéma complet|900px|droite]]
Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies (multiplexeur) où se situent les données à envoyer. La première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-17T00:09:49Z

Vvergez : /* Séance 2 */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===
Cette séance a été consacré à la finition de l'interface WEB.

Javascript nous permet de répondre à certains événements, comme le clic de la souris par exemple. Nous pouvons aussi récupérer la position du curseur. 
Ainsi, en associant ces fonctionnalités à notre dessin JCanvas (dessin actualisé régulièrement), nous avons implémenté une fonctionnalité de contrôle du dessin, l'idée étant de pouvoir asservir le bras robotique à la position donnée sur le dessin.

On se retrouve alors avec pour le dessin de droite, la possibilité de mouvoir le dessin éléments par éléments :
<center>[[Fichier:SelectionFA.png|400px|Premier élément sélectionné]][[Fichier:SelectionSA.png|300px|Second élément sélectionné]]</center>

Malheureusement, par faute de temps l'asservissement n'a pas été réalisé. 
Il faut savoir que le bras est initialement un gadget piloté par une télécommande filaire. Ce gadget a été légèrement détourné de sa fonctionnalité première, mais le système de commande par petites impulsions a été gardé. Un tel système de commande ne permet pas d'implanter un simple système d'asservissement avec boucle de retour tel qu'on sait les faire en IMA3. L'asservissement aurait dû être aborder sous un œil totalement nouveau pour nous et nous avons donc préférer nous focaliser sur les fonctionnalités premières du système mais sans toutefois supprimer cette fonctionnalité qui pourra être reprise par qui le souhaitera.

==='''Séance 3'''===

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

[[Fichier:Schéma_à_faire.png|1000px]]

Le Convertisseur analogique numérique), à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

schéma de déroulement :

[[Fichier:Partienumetanal.png|1000px]]

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Lorsque le sujet était clair, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionner. Nous avons ensuite crée notre propre PWM et nous sommes arrivés à cela :

[[Fichier:Seance1.png]]

[[Fichier:Fonctionnement PWM.png|vignette|900px|Exemple de MLI]]

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz.

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

[[Fichier:Altium1.png|schéma complet|1400px]]

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc pour simuler 4 capteurs :

[[Fichier:Altium2.png|schéma complet|900px|droite]]
Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies où se situent les données à envoyer. la première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

[[peut-être à compléter]]

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T23:52:54Z

Vvergez : /* Séance 1 */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

<center>[[Fichier:Presentation.png|900px|Interface WEB complète]]</center>

==='''Séance 2'''===

==='''Séance 3'''===

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

[[Fichier:Schéma_à_faire.png|1000px]]

Le Convertisseur analogique numérique), à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

schéma de déroulement :

[[Fichier:Partienumetanal.png|1000px]]

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Lorsque le sujet était clair, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionner. Nous avons ensuite crée notre propre PWM et nous sommes arrivés à cela :

[[Fichier:Seance1.png]]

[[Fichier:Fonctionnement PWM.png|vignette|900px|Exemple de MLI]]

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz.

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

[[Fichier:Altium1.png|schéma complet|1400px]]

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc pour simuler 4 capteurs :

[[Fichier:Altium2.png|schéma complet|900px|droite]]
Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies où se situent les données à envoyer. la première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

[[peut-être à compléter]]

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T23:51:00Z

Vvergez : /* Séance 1 */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




===='''Objectifs du projet :'''====

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

'''Le projet se décompose en trois parties :'''

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression.
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

===='''Gestion de projet | Equipe :'''====
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===
Sur cette partie, nous avons à notre disposition un banc d'essai composé de plusieurs éléments :
* Une FoxBoard, faisant ici office de serveur WEB;
* Trois accéléromètres gérés par une platine Arduino MEGA;
* Un bras robotisé;
* Quatre capteurs de pressions (non gérés électroniquement).

Le bras robotisé peut-être connecté en USB à un ordinateur (et donc à la FoxBoard) où un démon pourra être utilisé pour le piloter. 
La platine Arduino elle, peut être relié à un ordinateur aussi mais communique via liaison série. A chaque fois qu'un octet sera reçu par l'Arduino, un paquet de quatre octets contenant les valeurs des accéléromètres est renvoyé.

==='''Séance 1'''===
La première séance a été pleine de découvertes. 
Pour réaliser notre interface WEB nous pouvions nous reposer sur quelques exemples d'utilisation de bibliothèques et langages de programmations déjà fournis. Cette séance a donc été en grande partie consacré à la découverte de ces possibilités.

Dans un premier temps il s'agissait donc de tester les exemples et de commencer à les adapter à notre application.

Les langages, librairies et fonctionnalités retenues auront été les suivants :
* Structure de la page principale en HTML;
* Communication série gérée en PHP;
* Contrôle du bras robotique via un [http://fr.wikipedia.org/wiki/Daemon_(informatique) démon] codé en langage C;
* Transmission des ordres au démon contrôlant le bras robotiques par émission de paquets UDP (émission gérée en PHP).
* Actualisation de la page principale grâce à Javascript et sa bibliothèque JQuery;
* Exécutions des scripts PHP et récupérations de données grâce à Ajax;
* Dessin pour affichage "intuitif" des retours d'informations en Javascript avec la bibliothèque JCanvas.

L'assimilation de ces nouvelles connaissances a donc pris la majeure partie de cette séance. 
Il restait toutefois à comprendre le principe de fonctionnement de la FoxBoard pour pouvoir y implanter toutes notre application par la suite. La FoxBoard est un ordinateur avec une distribution [http://fr.wikipedia.org/wiki/Debian Debian] et un serveur web [http://fr.wikipedia.org/wiki/Lighttpd Lighttpd]. 
Nous avons dû la configurer préalablement pour lui attribuer une adresse IP Locale Fixe : 172.26.79.13 pour pouvoir la joindre depuis un navigateur internet par exemple. Il a aussi été nécessaire d'installer certains paquets pour faire fonctionner notre application puis placer nos fichiers et compiler nos divers démons.

Ce n'est seulement qu'en fin de séance que le développement de notre application à proprement parler a réellement commencé. L'objectif était de pouvoir visualiser en temps réel les valeurs brutes des accéléromètres ainsi que des capteurs de pression, de pouvoir commander le bras avec des boutons et avoir une visualisation intuitive de ces informations.

Voici à quoi ressemble notre interface une fois finalisée :

[[Fichier:Presentation.png|Interface WEB complète]]

==='''Séance 2'''===

==='''Séance 3'''===

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

[[Fichier:Schéma_à_faire.png|1000px]]

Le Convertisseur analogique numérique), à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la tension PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://nb3000.altium.com/ Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

schéma de déroulement :

[[Fichier:Partienumetanal.png|1000px]]

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur du rapport cyclique de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Lorsque le sujet était clair, des tests sur Altium ont été effectués. Un bloc PWM était mis à notre disposition afin de voir comment cela fonctionner. Nous avons ensuite crée notre propre PWM et nous sommes arrivés à cela :

[[Fichier:Seance1.png]]

[[Fichier:Fonctionnement PWM.png|vignette|900px|Exemple de MLI]]

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz et ainsi avoir une fréquence de PWM de 1MHz/256=3,9KHz.

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur du rapport cyclique de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat à la pression que nous exercions sur le capteur.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V (en pratique il est légèrement supérieur à 0V), alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet de transformer le signal carré de rapport cyclique variable en une rampe de tension.. On obtient donc un signal en dent de scie correspondant à la variation de notre PWM. Ce signal sera ensuite facilement comparable avec l'image de la tension issue du capteur.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3.9KHz).

=> fc < fs (fréquence du système)

fc < 3.9KHz

Or on sait que : fc = 1/(2piRC)

=> C = 330nF R = 2K ohms

Nous avons utilisé un potentiomètre afin d'ajuster la valeur de la résistance et ainsi obtenir un signal en dent de scie le plus linéaire que possible (avec peu de variations entre deux variations de rapport cyclique) de manière à augmenter la précision du résultat.

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une variation de la tension image du capteur, entre 0V et 3V. Pour cela nous avons mis une résistance de 10k ohms en association avec le capteur de pression pour former un diviseur de tension. De cette façon nous récupérons une image en tension de la valeur du capteur de pression (proportionnelle à la pression exercée sur le capteur).

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande (environ 10 fois) que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et pour celle en entrée nous avons pris une valeur de 100 ohms afin d'abaisser la tension de 3.3V à 3V afin qu'elle soit légèrement en dessous de la valeur maximale de la tension de la PWM de sorte qu'elle puisse être comparée facilement.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

[[Fichier:Altium1.png|schéma complet|1400px]]

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc pour simuler 4 capteurs :

[[Fichier:Altium2.png|schéma complet|900px|droite]]
Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies où se situent les données à envoyer. la première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

[[peut-être à compléter]]

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T23:05:30Z

Vvergez : /* Séance 1 */

Fichier:AccéléromètreVERT.png

2013-06-16T22:46:11Z

Vvergez :

Fichier:SelectionSA.png

2013-06-16T22:45:42Z

Vvergez :

Fichier:Presentation.png

2013-06-16T22:45:20Z

Vvergez :

Fichier:AccéléromètreNOIR.png

2013-06-16T22:44:04Z

Vvergez :

Fichier:SelectionFA.png

2013-06-16T22:43:17Z

Vvergez :

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T21:52:12Z

Vvergez : /* Séance 1 : */

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T21:47:32Z

Vvergez : /* PARTIE INFORMATIQUE */

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T21:17:57Z

Vvergez : /* Rapports des élèves */

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T21:15:51Z

Vvergez : /* Gestion de projet / rédaction Wiki */

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T21:10:30Z

Vvergez : /* Rapports des élèves */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

'''Présentation'''

Dans notre projet, l' électronique a pour but de récupérer la valeur d'un capteur de pression. En effet celui-ci se comporte comme une résistance variable, la valeur que l'on récupérera sera donc une valeur analogique (tension). Nous aurons donc pour but de créer un convertisseur analogique vers numérique. De cette manière, la transmission pourra se faire via une communication série.

'''Partie numérique'''

'''Partie analogique'''

La partie analogique se compose d'un amplificateur opérationnelle monté en comparateur, de résistances, de capacité et d'un capteur de pression. L'AOp nous permet de comparer la tension issue du capteur avec la tension de la PWM filtrée. Lorsque la tension de la PWM est supérieur à la tension du capteur la sortie de l'AOp est à 1 logique (5V).
Afin de pouvoir comparer la tension de la PWM nous avons du la filtrer à l'aide d'un filtre passe-bas pour obtenir une rampe de tension (Rappel : le signal d'une PWM est un signal carré de rapport cyclique variable).

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




'''Objectifs du projet :'''

* Réaliser une interface Web pour le pilotage du bras robotique. Elle doit permettre de commander les différents actionneurs du bras (rotation de la base, mouvement du bras, ouverture/fermeture de la pince, allumage/extinction de la LED).

* Afficher toutes les informations retournées par le système, à savoir :
** Angles des membres du robot (grâce à des accéléromètres);
** Présence d'objets déposés devant le bras (capteurs de pression).

Le projet se décompose en trois parties :

* Partie Electronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de récupérer la pression exercée sur un capteur de pression. 
Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).
La gestion électronique des accéléromètres est déjà effectuée par le biais d'une platine Arduino, il ne nous appartient pas de la concevoir.

* Partie Informatique : Conception d'une interface WEB dynamique grâce à plusieurs langages de développement et leur librairies. Le tout est ensuite embarqué sur une FoxBoard, serveur directement relié au bras robotique et à un réseau TCP/IP. Ceci permet de commander le bras n’importe où tant qu'on est connecté à la FoxBoard via le réseau, et si ce réseau est internet alors le bras peut-être piloté depuis n'importe où dans le monde.

* Intégration : Partie clé, associant le travail des deux parties précédentes et finalisant le projet. L'informatique et l'électronique communiquerons par le biais d'une liaison série.

'''Gestion de projet | Equipe :'''
Pour ce projet nous étions une équipe de trois personnes, Benjamin LAFIT, Mathieu GERIER et Valentin VERGEZ. 
Dans la répartition des tâches nous avons choisi d'affecter un responsable sur chaque partie, Mathieu à l'électronique et Valentin à l'informatique. Benjamin était alors chargé de faire la liaison entre les deux, d'apporter son aide à chacun selon les besoins et s'assurer que les deux parties aboutiraient ensembles pour ensuite passer à l'intégration électronique/informatique.

Finalement, la partie électronique s'annonçant plus compliquée pour nous, Benjamin, en plus de son rôle d'intermédiaire, a surtout pris en charge la partie électronique analogique tandis que Mathieu se spécialisait sur l'aspect électronique numérique.

=== '''PARTIE INFORMATIQUE''' ===

[[Toute ta partie informatique, désolé si je n'ai rien écris mais je n'avais pas les données]]

==='''Séance 1'''===

==='''Séance 2'''===

==='''Séance 3'''===

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

[[Fichier:Schéma_à_faire.png|1000px]]

Le Convertisseur analogique numérique), à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://www.google.fr/imgres?um=1&client=firefox-a&sa=N&rls=org.mozilla:fr:official&hl=fr&biw=1600&bih=770&tbm=isch&tbnid=08I09Rs8TUawTM:&imgrefurl=http://fr.farnell.com/altium/12-400-nb2dsk01-db30/xilinx-spartan-3-nanoboard-nb2/dp/1714409&docid=AgDwTOE4fjRsQM&imgurl=http://fr.farnell.com/productimages/farnell/standard/1714407-40.jpg&w=316&h=200&ei=Ulq8UbvIGOOc0QWu64G4Cw&zoom=1&iact=rc&dur=405&page=1&tbnh=133&tbnw=209&start=0&ndsp=33&ved=1t:429,r:7,s:0,i:104&tx=104&ty=77 Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

schéma de déroulement :

[[Fichier:Partienumetanal.png|1000px]]

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Lorsque le sujet était clair, des tests sur Altium ont été effectués. Le bloc PWM était mis à notre disposition afin de voir comment cela fonctionner. Nous avons fait des tests et nous sommes arrivés à cela :

[[Fichier:Seance1.png]]

[[Fichier:Fonctionnement PWM.png|vignette|900px|Exemple de MLI]]

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz.

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat par rapport au vrai.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V, alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet d'obtenir la valeur analogique recherchée.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3KHz).

=> fn < fs (fréquence du système)

fn < 3KHz

Or on sait que : fn = 1/(2piRC)

=> C = 330nF R = 2K ohms

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une [[à compléter]]

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et celle en entrée, la valeur est de 100 ohms.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, c'est-à-dire de nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

[[Fichier:Altium1.png|schéma complet|1400px]]

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc pour simuler 4 capteurs :

[[Fichier:Altium2.png|schéma complet|900px|droite]]
Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies où se situent les données à envoyer. la première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

[[peut-être à compléter]]

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T20:19:59Z

Vvergez : /* PARTIE INFORMATIQUE */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

'''Présentation'''

Dans notre projet, l' électronique a pour but de récupérer la valeur d'un capteur de pression. En effet celui-ci se comporte comme une résistance variable, la valeur que l'on récupérera sera donc une valeur analogique (tension). Nous aurons donc pour but de créer un convertisseur analogique vers numérique. De cette manière, la transmission pourra se faire via une communication série.

'''Partie numérique'''

'''Partie analogique'''

La partie analogique se compose d'un amplificateur opérationnelle monté en comparateur, de résistances, de capacité et d'un capteur de pression. L'AOp nous permet de comparer la tension issue du capteur avec la tension de la PWM filtrée. Lorsque la tension de la PWM est supérieur à la tension du capteur la sortie de l'AOp est à 1 logique (5V).
Afin de pouvoir comparer la tension de la PWM nous avons du la filtrer à l'aide d'un filtre passe-bas pour obtenir une rampe de tension (Rappel : le signal d'une PWM est un signal carré de rapport cyclique variable).

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




'''Objectif du projet :'''

* Réaliser une interface Web de pilotage de bras robotique permettant de commander les différents moteurs du bras.

* Afficher la position du bras ainsi que des objets placés sur les capteurs de position.

Le projet se compose de trois parties :

* Partie électronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de connaître la valeur d’un capteur de pression. Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).

* Partie Informatique : Réalisation d’un fichier html comprenant du Javascript , du Php ainsi qu’un programme en langage C. Les programmes sont ensuite stockés sur une FoxBoard, serveur relié au bras robotique, ce qui permet de commander le bras n’importe où lorsqu’on est connecté à la FoxBoard.

* Partie permettant de rendre compatibles les systèmes informatiques et électroniques afin de pouvoir faire une bonne liaison série.

[[FAIRE UNE INTRODUCTION]]

=== '''PARTIE INFORMATIQUE''' ===

[[Toute ta partie informatique, désolé si je n'ai rien écris mais je n'avais pas les données]]

==='''Séance 1'''===

==='''Séance 2'''===

==='''Séance 3'''===

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

[[Fichier:Schéma_à_faire.png|1000px]]

Le Convertisseur analogique numérique), à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://www.google.fr/imgres?um=1&client=firefox-a&sa=N&rls=org.mozilla:fr:official&hl=fr&biw=1600&bih=770&tbm=isch&tbnid=08I09Rs8TUawTM:&imgrefurl=http://fr.farnell.com/altium/12-400-nb2dsk01-db30/xilinx-spartan-3-nanoboard-nb2/dp/1714409&docid=AgDwTOE4fjRsQM&imgurl=http://fr.farnell.com/productimages/farnell/standard/1714407-40.jpg&w=316&h=200&ei=Ulq8UbvIGOOc0QWu64G4Cw&zoom=1&iact=rc&dur=405&page=1&tbnh=133&tbnw=209&start=0&ndsp=33&ved=1t:429,r:7,s:0,i:104&tx=104&ty=77 Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

schéma de déroulement :

[[Fichier:Partienumetanal.png|1000px]]

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Lorsque le sujet était clair, des tests sur Altium ont été effectués. Le bloc PWM était mis à notre disposition afin de voir comment cela fonctionner. Nous avons fait des tests et nous sommes arrivés à cela :

[[Fichier:Seance1.png]]

[[Fichier:Fonctionnement PWM.png|vignette|900px|Exemple de MLI]]

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz.

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat par rapport au vrai.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V, alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet d'obtenir la valeur analogique recherchée.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3KHz).

=> fn < fs (fréquence du système)

fn < 3KHz

Or on sait que : fn = 1/(2piRC)

=> C = 330nF R = 2K ohms

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une [[à compléter]]

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et celle en entrée, la valeur est de 100 ohms.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, c'est-à-dire de nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

[[Fichier:Altium1.png|schéma complet|1400px]]

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc pour simuler 4 capteurs :

[[Fichier:Altium2.png|schéma complet|900px|droite]]
Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies où se situent les données à envoyer. la première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

[[peut-être à compléter]]

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T20:15:45Z

Vvergez : /* Séance 3 : */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

'''Présentation'''

Dans notre projet, l' électronique a pour but de récupérer la valeur d'un capteur de pression. En effet celui-ci se comporte comme une résistance variable, la valeur que l'on récupérera sera donc une valeur analogique (tension). Nous aurons donc pour but de créer un convertisseur analogique vers numérique. De cette manière, la transmission pourra se faire via une communication série.

'''Partie numérique'''

'''Partie analogique'''

La partie analogique se compose d'un amplificateur opérationnelle monté en comparateur, de résistances, de capacité et d'un capteur de pression. L'AOp nous permet de comparer la tension issue du capteur avec la tension de la PWM filtrée. Lorsque la tension de la PWM est supérieur à la tension du capteur la sortie de l'AOp est à 1 logique (5V).
Afin de pouvoir comparer la tension de la PWM nous avons du la filtrer à l'aide d'un filtre passe-bas pour obtenir une rampe de tension (Rappel : le signal d'une PWM est un signal carré de rapport cyclique variable).

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




'''Objectif du projet :'''

* Réaliser une interface Web de pilotage de bras robotique permettant de commander les différents moteurs du bras.

* Afficher la position du bras ainsi que des objets placés sur les capteurs de position.

Le projet se compose de trois parties :

* Partie électronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de connaître la valeur d’un capteur de pression. Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).

* Partie Informatique : Réalisation d’un fichier html comprenant du Javascript , du Php ainsi qu’un programme en langage C. Les programmes sont ensuite stockés sur une FoxBoard, serveur relié au bras robotique, ce qui permet de commander le bras n’importe où lorsqu’on est connecté à la FoxBoard.

* Partie permettant de rendre compatibles les systèmes informatiques et électroniques afin de pouvoir faire une bonne liaison série.

[[FAIRE UNE INTRODUCTION]]

=== '''PARTIE INFORMATIQUE''' ===

[[Toute ta partie informatique, désolé si je n'ai rien écris mais je n'avais pas les données]]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

[[Fichier:Schéma_à_faire.png|1000px]]

Le Convertisseur analogique numérique), à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://www.google.fr/imgres?um=1&client=firefox-a&sa=N&rls=org.mozilla:fr:official&hl=fr&biw=1600&bih=770&tbm=isch&tbnid=08I09Rs8TUawTM:&imgrefurl=http://fr.farnell.com/altium/12-400-nb2dsk01-db30/xilinx-spartan-3-nanoboard-nb2/dp/1714409&docid=AgDwTOE4fjRsQM&imgurl=http://fr.farnell.com/productimages/farnell/standard/1714407-40.jpg&w=316&h=200&ei=Ulq8UbvIGOOc0QWu64G4Cw&zoom=1&iact=rc&dur=405&page=1&tbnh=133&tbnw=209&start=0&ndsp=33&ved=1t:429,r:7,s:0,i:104&tx=104&ty=77 Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

schéma de déroulement :

[[Fichier:Partienumetanal.png|1000px]]

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Lorsque le sujet était clair, des tests sur Altium ont été effectués. Le bloc PWM était mis à notre disposition afin de voir comment cela fonctionner. Nous avons fait des tests et nous sommes arrivés à cela :

[[Fichier:Seance1.png]]

[[Fichier:Fonctionnement PWM.png|vignette|900px|Exemple de MLI]]

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz.

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat par rapport au vrai.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V, alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet d'obtenir la valeur analogique recherchée.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3KHz).

=> fn < fs (fréquence du système)

fn < 3KHz

Or on sait que : fn = 1/(2piRC)

=> C = 330nF R = 2K ohms

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une [[à compléter]]

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et celle en entrée, la valeur est de 100 ohms.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, c'est-à-dire de nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

==='''Séance 4 (Supplémentaire) :'''===

Voici le schéma complet d'Altium :

[[Fichier:Altium1.png|schéma complet|1400px]]

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc pour simuler 4 capteurs :

[[Fichier:Altium2.png|schéma complet|900px|droite]]
Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies où se situent les données à envoyer. la première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

[[peut-être à compléter]]

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Contrôle de bras robotique, 2012/2013, TD2

2013-06-16T20:11:15Z

Vvergez : /* PARTIE ELECTRONIQUE */

== Evaluation informatique et électronique ==



=== Gestion de projet / rédaction Wiki ===

* Informatique :

* Electronique :

'''Présentation'''

Dans notre projet, l' électronique a pour but de récupérer la valeur d'un capteur de pression. En effet celui-ci se comporte comme une résistance variable, la valeur que l'on récupérera sera donc une valeur analogique (tension). Nous aurons donc pour but de créer un convertisseur analogique vers numérique. De cette manière, la transmission pourra se faire via une communication série.

'''Partie numérique'''

'''Partie analogique'''

La partie analogique se compose d'un amplificateur opérationnelle monté en comparateur, de résistances, de capacité et d'un capteur de pression. L'AOp nous permet de comparer la tension issue du capteur avec la tension de la PWM filtrée. Lorsque la tension de la PWM est supérieur à la tension du capteur la sortie de l'AOp est à 1 logique (5V).
Afin de pouvoir comparer la tension de la PWM nous avons du la filtrer à l'aide d'un filtre passe-bas pour obtenir une rampe de tension (Rappel : le signal d'une PWM est un signal carré de rapport cyclique variable).

Note .

=== Test fonctionnels ===

* Sous-système.
** Sous-système informatique :
** Sous-système électronique :

=== Qualité de la réalisation ===

* Informatique : Note .
** procédure de test :
** pages HTML et Javascript :
** scripts PHP ou programmes C :
** installation sur FoxBoard :
* Electronique : Note .
** qualité de la réalisation :
** tests autonomes :

=== Bilan ===

Note finale :

== Rapports des élèves ==




'''Objectif du projet :'''

* Réaliser une interface Web de pilotage de bras robotique permettant de commander les différents moteurs du bras.

* Afficher la position du bras ainsi que des objets placés sur les capteurs de position.

Le projet se compose de trois parties :

* Partie électronique : Réalisation d’un convertisseur analogique numérique (CAN) permettant de connaître la valeur d’un capteur de pression. Pour la réalisation du CAN, nous avions besoin d’un mélange d’électronique numérique (NanoBoard) et d’électronique analogique (comparateurs, résistances…).

* Partie Informatique : Réalisation d’un fichier html comprenant du Javascript , du Php ainsi qu’un programme en langage C. Les programmes sont ensuite stockés sur une FoxBoard, serveur relié au bras robotique, ce qui permet de commander le bras n’importe où lorsqu’on est connecté à la FoxBoard.

* Partie permettant de rendre compatibles les systèmes informatiques et électroniques afin de pouvoir faire une bonne liaison série.

[[FAIRE UNE INTRODUCTION]]

=== '''PARTIE INFORMATIQUE''' ===

[[Toute ta partie informatique, désolé si je n'ai rien écris mais je n'avais pas les données]]

=== '''PARTIE ELECTRONIQUE''' ===

==='''Séance 1 :'''===

La première séance a servi à comprendre le lien entre le logiciel [http://www.elektronique.fr/logiciels/altium-designer.php Altium] et la NanoBoard. Sur Altium, des composants sont mis à disposition (bascules RS, D, des compteurs…). Le but est, à partir de ces composants, de les relier pour concevoir le système désiré (ici un CAN). Ensuite, le système ainsi réalisé est adapté pour fonctionner sur la NanoBoard.

Schéma de principe :

[[Fichier:Schéma_à_faire.png|1000px]]

Le Convertisseur analogique numérique), à partir d’une [http://fr.wikipedia.org/wiki/Modulation_de_largeur_d%27impulsion Modulation à Largeur d'Impulsions] (MLI) aussi appelée PWM , permet de comparer la valeur de la PWM avec la tension du capteur de pression afin de connaître la valeur de ce dernier. Pour cela, nous avons du adapter les tensions du capteur et de la PWM pour que les résultats puissent correspondre. C’est-à-dire que lorsque le capteur ne reçoit aucune pression, la valeur de la tension est par exemple de 3.3V alors la PWM doit être au maximum à 3.3V.

La PWM sera crée par la [http://www.google.fr/imgres?um=1&client=firefox-a&sa=N&rls=org.mozilla:fr:official&hl=fr&biw=1600&bih=770&tbm=isch&tbnid=08I09Rs8TUawTM:&imgrefurl=http://fr.farnell.com/altium/12-400-nb2dsk01-db30/xilinx-spartan-3-nanoboard-nb2/dp/1714409&docid=AgDwTOE4fjRsQM&imgurl=http://fr.farnell.com/productimages/farnell/standard/1714407-40.jpg&w=316&h=200&ei=Ulq8UbvIGOOc0QWu64G4Cw&zoom=1&iact=rc&dur=405&page=1&tbnh=133&tbnw=209&start=0&ndsp=33&ved=1t:429,r:7,s:0,i:104&tx=104&ty=77 Nanoboard]. Ce signal sera dans la partie analogique, filtré par un filtre passe-bas puis comparé avec un comparateur.

schéma de déroulement :

[[Fichier:Partienumetanal.png|1000px]]

La valeur du capteur de pression sera donnée par la PWM, lorsque la la tension de la PWM sera supérieure à la valeur du capteur, le comparateur enverra un 1 logique ou 5V (0 sinon) au fpga qui enregistrera la valeur de la PWM dans un registre 8 bits. Ce résultat sera alors envoyé périodiquement par liaison série à la FoxBoard.

Lorsque le sujet était clair, des tests sur Altium ont été effectués. Le bloc PWM était mis à notre disposition afin de voir comment cela fonctionner. Nous avons fait des tests et nous sommes arrivés à cela :

[[Fichier:Seance1.png]]

[[Fichier:Fonctionnement PWM.png|vignette|900px|Exemple de MLI]]

Dans ce schéma, il y a deux compteurs. Le premier, qui compte jusqu'à 256, représente la période de la PWM et le second quant à lui permet de faire varier la rapport cyclique. Plus le rapport cyclique du signal est grand, plus la valeur de la tension de la PWM sera grande.

Le deuxième compteur servant à générer le rapport cyclique doit varier à chaque nouveau comptage de la PWM. Par exemple, le compteur U5 est initialement à 0, le compteur U4 compte jusqu'à 256, puis retombe à 0. Lorsqu'il est égal à 0, il incrémente le compteur U5 grâce à la broche CEO et passe ainsi à 1, ainsi de suite jusqu'à son maximum qui est T, la période de la PWM.

La fréquence de l'horloge est celle de la Nanoboard 50MHz.
Cependant, nous avons eu recours à la CLKGEN afin de diminuer la fréquence à 1MHz.

Nous n'avons pas fini sur le fpga, il reste seulement la gestion de la mémorisation car on ne veut mémoriser la valeur de la PWM seulement quand nous avons la réelle valeur du capteur de pression.

==='''Séance 2 :'''===

[[Fichier:Basculepourmemorisation.png|vignette|450px]]
Nous avons rajouté un registre 8 bits afin de mémoriser la valeur du capteur de pression lorsque l'on obtient une valeur du capteur.

Pour les tests, nous avons mis en sortie un panneau de 8 leds ainsi qu'un afficheur digital afin de visualiser le résultat et de pouvoir comparer le résultat par rapport au vrai.

La partie analogique a été également faite:

[[Fichier:Schéma électrique.png]]

Pour le capteur de pression, nous avons ajouté des diviseurs de tension. Un pour réduire la tension d'entrée de 3.3V à 3V car le signal de la PWM va seulement jusqu'à 3V. Or, si le capteur présente une tension de 3.3V, nous ne pouvons trouver aucun résultat.
Ensuite, le deuxième sert à avoir un équivalent en tension de la pression exercé sur le capteur. Lorsque le capteur est mis fortement sous pression, l'équivalent en tension est de 0V, alors que lorsque le capteur n'est exercé à aucune pression, l'image en tension est de 3V.
Le comparateur a pour valeur de référence 0V et 5V afin de pouvoir communiquer correctement avec la Nanoboard qui peut recevoir 0V, ce qui correspond à un 0 logique et 5V, ce qui correspond à un 1 logique.

Le filtre passe bas appliqué sur la PWM permet d'obtenir la valeur analogique recherchée.

Définition des valeurs des composants:

* Composants du filtre passe bas :

la fréquence de résonance devait être inférieure à la fréquence du système (1Mhz/256 = 3KHz).

=> fn < fs (fréquence du système)

fn < 3KHz

Or on sait que : fn = 1/(2piRC)

=> C = 330nF R = 2K ohms

* Composants du diviseur de tension avec capteur de pression

Il suffisait seulement ici d'avoir une [[à compléter]]

* Composants du premier diviseur de tension

Il fallait respecter l'adaptation d'impédance. Il fallait donc avoir une impédance beaucoup plus grande en sortie du diviseur de tension.

Soit que la résistance en sortie du diviseur de tension soit beaucoup plus grande que l'impédance relié à la masse.

On a donc choisi une résistance de 1K ohms pour la résistance connectée à la masse et celle en entrée, la valeur est de 100 ohms.

==='''Séance 3 :'''===

Voici les tests effectués lors de la troisième séance :

[[Fichier:Scope_4.png|schema 1|vignette|600px|gauche]]

Dans ce schéma, nous pouvons voir en vert, l'image en tension du capteur de tension, en jaune, la valeur de la PWM filtrée. Ensuite, le signal en bleu est la sortie du comparateur. On peut voir sur ce signal que lorsque la valeur du capteur de pression est égale à la valeur de la PWM filtrée, la sortie du comparateur passe de 0 logique à 1 logique. Cependant, on peut voir lors du passage de 0 à 1, le signal change d'état beaucoup de fois.
Ce changement d'état est dû à cause de la PWM qui est en forme de dent de scie.

[[Fichier:Scope_2.png|schéma 2 : PWM filtrée|vignette|350px|droite]]

Comme, on peut le voir sur le schéma 2, le signal étant en dent de scie, on peut voir que le signal bleu correspondant à la valeur du capteur est égal plusieurs fois à la valeur de la PWM filtrée. Ceci explique donc pourquoi dans le schéma 1, le signal bleu change d'état plusieurs fois.

Pour corriger cette erreur, c'est-à-dire de nous avons créer un système qui permet, à partir de la première égalité entre la PWM filtrée et la valeur en tension du capteur de pression, d'avoir un 1 logique jusqu'à la fin de la période de PWM.

Voici le système de correction des changements d'états :

[[Fichier:Regalge_petitesd pertubes.png|Système de correction d'erreur|600px|vignette|gauche]]

Le système est constitué d'une bascule RS, qui permet lorsque pour la première fois la sortie du comparateur passe à 1, de mettre la sortie de la bascule à 1, ensuite quelque soit la valeur de la sortie du comparateur, le résultat de la bascule RS reste inchangé, puis lorsque l'on arrive en fin de la période de la PWM, la donnée de la bascule RS passe à 0.
Le signal corrigé est le signal rose du schéma 1.

remarque : le CAN donnera seulement une valeur approximative de la valeur du capteur de pression.

* '''Séance bonus :'''

Voici le schéma complet d'Altium :

[[Fichier:Altium1.png|schéma complet|1400px]]

Nous avons utilisé des blocs déjà utilisés pour la liaison série (émission et réception). Ils fonctionnent à la fréquence de la NanoBoard, c'est-à-dire 50MHz

De plus, nous avons crée un bloc pour simuler 4 capteurs :

[[Fichier:Altium2.png|schéma complet|900px|droite]]

Lorsque une donnée valide est reçu sur le bloc émission (déjà fourni sur Altium), le compteur U13 compte afin de choisir les voies où se situent les données à envoyer. la première donnée où la valeur est nulle sert d'indicateur afin d'envoyer correctement et dans l'ordre les données par liaison série. Le fait d'avoir ajouté un 0 en début permet que les informations reçues sur l'ordinateur ne soient pas décalées, soit faussées.

[[peut-être à compléter]]

=== '''PARTIE COMMUNICATION''' ===

Cette partie a été la plus dure, car il fallait connaître les attentes des parties informatiques et électroniques. Il a fallu corriger quelques détails afin que la communication par liaison série (RS232) se fasse correctement.

[[Ici il faudrait détailler un peu plus. J'ai parlé de la partie liaison série un peu sur partie électronique mais je ne savais pas quoi mettre d'autre ici]]

=== '''CONCLUSION''' ===

Ce projet nous a permis de découvrir le monde des systèmes communicants (SC) ainsi que de travailler sur deux domaines différents : l'électronique et l'informatique.
Nous avons pu collaborer ensembles. Les idées ont été discutées, argumentées et sélectionnées afin d'en garder les plus importantes.
La partie informatique nous a permis de nous familiariser avec les protocoles Web, de nouveaux langages ont été acquis durant ces séances comme le Php, Jquery, JavaScript...
Pour ce qui est partie Electronique, nous avons travaillé sur l'électronique numérique et l'électronique analogique et fait marcher ensemble ces deux systèmes pour ainsi créer un Convertisseur Analogique Numérique.
Le plus dur a été de faire la liaison entre la partie informatique et électronique. Cela nous a montré à quel point il était important de définir un cahier des charges précis car dans le cas contraire, les deux parties peuvent marcher mais ne sont pas compatibles.

Projets troisième année, 2012/2013, TD2

2013-05-16T06:37:29Z

Vvergez : /* Répartition des binômes */

== Répartition des binômes ==

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Contrôle de matrice leds, 2012/2013, TD2]] || Benoit Maliar,Thomas Maurice,Fabien Violier
|-
| [[Communication série, 2012/2013, TD2]] || Hugo Fondu, Kévin Chalono
|-
| [[Gestion afficheurs, 2012/2013, TD2]] || Mercier Alexandre , Sultana Quentin
|-
| [[Gestion de LED RVB, 2012/2013, TD2]] || Céline Ly, Pierre Appercé, Marjorie Tixier, Geoffrey Rose
|-
| [[Contrôle de sonar, 2012/2013, TD2]] || Nathan Martin, Charlotte Bricout, Soufiane Haddaoui, Sylvain Fossaert
|-
| [[Contrôle d'accéléromètre, 2012/2013, TD2]] ||
|-
| [[Contrôle de bras robotique, 2012/2013, TD2]] || Valentin Vergez, Mathieu Gerier, Benjamin Lafit
|}

Projets troisième année, 2012/2013, TD2

2013-05-16T06:36:33Z

Vvergez : /* Répartition des binômes */

== Répartition des binômes ==

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Contrôle de matrice leds, 2012/2013, TD2]] || Benoit Maliar,Thomas Maurice,Fabien Violier
|-
| [[Communication série, 2012/2013, TD2]] || Hugo Fondu, Kévin Chalono
|-
| [[Gestion afficheurs, 2012/2013, TD2]] ||
|-
| [[Gestion de LED RVB, 2012/2013, TD2]] || Céline Ly, Pierre Appercé, Marjorie Tixier, Geoffrey Rose
|-
| [[Contrôle de sonar, 2012/2013, TD2]] || Nathan Martin, Charlotte Bricout, Soufiane Haddaoui
|-
| [[Contrôle d'accéléromètre, 2012/2013, TD2]] ||
|-
| [[Contrôle de bras robotique, 2012/2013, TD2]] || Valentin Vergez, Mathieu Gerier, Benjamin Lafit
|}

Projets troisième année, 2012/2013, TD2

2013-05-16T06:35:53Z

Vvergez : /* Répartition des binômes */

== Répartition des binômes ==

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Contrôle de matrice leds, 2012/2013, TD2]] || Benoit Maliar,Thomas Maurice,Fabien Violier
|-
| [[Communication série, 2012/2013, TD2]] ||
|-
| [[Gestion afficheurs, 2012/2013, TD2]] ||
|-
| [[Gestion de LED RVB, 2012/2013, TD2]] || Céline Ly, Pierre Appercé, Marjorie Tixier, Geoffrey Rose
|-
| [[Contrôle de sonar, 2012/2013, TD2]] || Nathan Martin, Charlotte Bricout, Soufiane Haddaoui
|-
| [[Contrôle d'accéléromètre, 2012/2013, TD2]] ||
|-
| [[Contrôle de bras robotique, 2012/2013, TD2]] || Valentin Vergez, Mathieu Gerier, Benjamin Lafit
|}