https://wiki-ima.plil.fr/mediawiki//api.php?action=feedcontributions&feedformat=atom&user=Gelbez 2026-04-25T03:04:13Z Contributions de l’utilisateur MediaWiki 1.29.2 https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=20384 2015-04-20T15:37:47Z

<p>Gelbez : /* Semaine 12 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> === Semaine 7 ===<br /> <br /> * '''Lundi 16/03'''<br /> Le but de la séance était de compiler la partie de code réimplantée dans le programme global du projet SOFA. Nous avons rencontré un problème lors de l'installation de SOFA, en effet une mauvaise version d'un programme nous empêchait de faire le lien avec la bibliothèque VRPN.<br /> <br /> * '''Mercredi 18/03'''<br /> Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction &quot;init&quot; puissent être utilisés dans la deuxième. Pour cela nous devions créer une &quot;Data&quot; SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares). <br /> <br /> Heureusement, grâce à l'aide de notre tuteur, qui connait parfaitement le fonctionnement de SOFA, nous avons pu y arriver en créant des accès en lecture et en écriture de la façon suivante : <br /> <br /> Par exemple, dans la première fonction, on déclare un &quot;write accessor&quot; qui permet de faire le lien avec la DATA sofa préalablement déclarée, puis un &quot;read accessor&quot; <br /> <br /> <br /> sofa::Data&lt;vector&lt;float&gt; &gt; infosServosm // déclaration de la data SOFA dans le .h<br /> <br /> using sofa::helper::WriteAccessor; // déclaration pour pouvoir accéder aux fonctions de type &quot;Accessor&quot;<br /> using sofa::helper::ReadAccessor;<br /> <br /> WriteAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm= infosServosm; // déclaration dans la première fonction<br /> infosservosm.resize(50); // Permet de choisir la taille, ici 50<br /> <br /> ReadAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm = infosServosm; <br /> // déclaration dans la deuxième fonction pour accéder aux données, à savoir que la variable &quot;infosservosm&quot; crée s'utilise comme un tableau classique en C.<br /> <br /> <br /> * '''Jeudi 19/03''' <br /> Le problème du transfert de tableaux étant résolu, nous avons pu tester le programme que nous avions écrit quelques semaines auparavant. Pour cela, nous avons d'abord commencer par l'extraire de SOFA pour éviter la compilation trop longue de tout le projet. Après des tests comparatifs entre le nouveau et l'ancien programme, il s'est avéré que celui-ci fonctionnait parfaitement.<br /> Il ne nous restait plus qu'a réimplanter le code dans le projet SOFA.<br /> <br /> === Semaine 8 ===<br /> <br /> * ''' Lundi 23/03 ''' <br /> <br /> Pour tester le programme réimplanté dans SOFA, nous avons du recompiler le projet afin d'ajouter des plugings ce qui s'est avéré assez long. A la fin de la séance, nous avons pu commencer les tests et nous avons remarqué quelques bugs dans le code. <br /> <br /> * ''' Mercredi 25/03 '''<br /> <br /> Durant cette séance, nous avons pu résoudre certains problème du code du port série, mais il restait malgré tout non fonctionnel à cause d'une série d'instructions ne réalisant pas l'effet désiré. Nos encadrant étant absent, nous devions patienter jusqu’à jeudi afin d'obtenir les informations nécessaires. Pendant ce temps, nous avons pu commencer les tests sur le code Arduino que nous avions codé il y a quelques semaines déjà.<br /> <br /> * '''Jeudi 26/03 '''<br /> Nous avons résolu le problème concernant le code du port série, grâce aux indications de notre encadrant. Cette partie du code semble opérationnelle pour les servos moteurs. Il nous reste a effectuer les tests concernant les actionneurs pneumatiques. Nous avons ensuite continué les tests du code Arduino. Il semble opérationnel pour les servos moteurs. Le début des tests sur les actionneurs pneumatique a également été débuté.<br /> <br /> <br /> <br /> === Semaine 9 === <br /> <br /> * '''Lundi 30/03''' <br /> <br /> Nous avons terminé les tests concernant la partie Arduino. Le code fonctionne avec un robot n'ayant que des servos moteurs, un robot n'ayant que des pneumatiques ou les 2. Malgré tout, ces tests ont été effectués &quot;en dur&quot;, c'est à dire que cette partie n'est pas encore liée à la partie liaison série (il peut donc encore y avoir des problèmes de disponibilité ou de lecture au niveau du port série). Nous attendons que les tests concernant la liaison série soient concluants pour les 3 configurations d'actionneurs possibles avant de commencer les tests finaux. La toute dernière partie consistera à tester ces codes sur les robots disponibles à l'INRIA. Il nous faudra également ajouter les actionneurs hydrauliques si tout fonctionne, même si les tests ne pourront jamais être effectués car le laboratoire ne dispose pas d'un tel robot pour le moment. <br /> <br /> '''Missions pour les semaines à venir : '''<br /> <br /> - Objectif pour la fin de semaine : les parties Arduino et liaison série sont liées et fonctionnent.<br /> - Objectif pour la semaine prochaine : les tests ont été effectués sur les robots et l'actionneur hydraulique à été ajouté.<br /> - Objectif pour la semaine 11 : Mise en place des feedBacks des actionneurs du robot.<br /> <br /> * ''' Mercredi 01/04 '''<br /> Durant cette séance, nous avons effectué les tests pour les trois configurations possibles d'actionneurs dans la liaison série. Nous avons trouvé quelques bugs dans le code, mais nous sommes arrivée à les résoudre facilement. Il ne restait plus qu'a comparer le code des pneumatiques avec notre code généralisé sur l'interface SOFA. Nous avons également fait des tests sur l'arduino afin de résoudre à l'avance les différents problèmes de lecture pour que la liaison entre les deux codes se passe bien.<br /> <br /> * ''' Jeudi 02/04 '''<br /> Nous avons continué les tests sur l'Arduino, qui pour le moment s'avèrent concluant. Nous espérons qu'il en sera de même pour la liaison des deux codes.<br /> Nous avons également voulu tester le code de la liaison série sur SOFA. Nous avons alors ouvert la &quot;scène&quot; sofa contenant le robot pneumatique. Mais à cause d'une mise à jour, cette scène était inutilisable. Nous devions donc attendre que SOFA se mette à jour entièrement afin de tester (ce qui a pris plus ou moins 1h de mise à jour).<br /> <br /> ===Semaine 10===<br /> <br /> * ''' Lundi 06/04 '''<br /> Ce lundi était férié.<br /> <br /> * ''' Mercredi 08/04 ''' <br /> La mise à jour de SOFA devait s'accompagner de la mise à jour du pluging contenant la scène en question. Cette mise à jour est également assez longue.<br /> <br /> * ''' Jeudi 09/04 ''' <br /> Même en ayant réaliser la mise à jour du pluging et donc en arrivant enfin à obtenir la bonne scène, on avait quand même un warning qui nous indiquait que la liaison entre la scène et Sofa n'était pas faite. Nous avons quand même essayé de compiler notre programme mais nous n'arrivions pas à obtenir les bons résultats.<br /> <br /> ===Semaine 11===<br /> <br /> * ''' Lundi 13/04 '''<br /> Nous nous sommes rendues compte que le problème venait de la scène Sofa puisqu'on ne recevait que des 0. Et donc nous avons demandé à nos encadrants de nous aider. Ils ont donc réussi à corriger la scène Sofa du robot pneumatique qui contenait des bugs et ces derniers nous empêchaient de faire le lien avec notre code.<br /> <br /> * ''' Mardi 14/04 '''<br /> Après avoir effectué des tests sur sur l'arduino et sur la liaison série, nous avons commencé par définir les bonnes adresses des différentes broches du robot déformable avec les servomoteurs et de le régler à la bonne vitesse de transmission. Ensuite, nous avons transvaser notre code arduino sur la carte arduino Uno du robot. Les premiers tests sur le robot n'étaient pas très concluants.<br /> <br /> * ''' Mercredi 15/04 ''' <br /> <br /> On s'est en fait vite rendues compte qu'il y avait un problème de dépassement de mémoire. En effet, on avait fait tous nos tests avec une carte arduino Atmega 2560 mais le robot était équipé d'une carte arduino Uno dont l'espace mémoire était plus restreint. Afin de résoudre ce problème, nous avons diminué la taille des tableaux dans lesquels on stockait les différents types d'actionneurs de 50 à 10. Ayant régler ce problème, nous avons réussi à la fin de la séance à commander correctement le &quot;vrai&quot; robot déformable avec les servomoteurs.<br /> <br /> * ''' Jeudi 16/04 ''' <br /> Nous avons eu l'intervention de l'industriel valeo toute la matinée.<br /> <br /> ===Semaine 12===<br /> <br /> * ''' Lundi 20/04 '''<br /> Nous avons réglé quelques problèmes de conditions de transmission sur l'arduino pour les actionneurs pneumatiques et nous avons rentré les adresses des différentes broches. Nous avons ensuite vérifié notre code de la liaison série avant de tester sur le robot pneumatique. Enfin, nous avons réussi à commander le &quot;vrai&quot; robot pneumatique grâce à notre code.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=20383 2015-04-20T15:36:05Z

<p>Gelbez : /* Semaine 10 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> === Semaine 7 ===<br /> <br /> * '''Lundi 16/03'''<br /> Le but de la séance était de compiler la partie de code réimplantée dans le programme global du projet SOFA. Nous avons rencontré un problème lors de l'installation de SOFA, en effet une mauvaise version d'un programme nous empêchait de faire le lien avec la bibliothèque VRPN.<br /> <br /> * '''Mercredi 18/03'''<br /> Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction &quot;init&quot; puissent être utilisés dans la deuxième. Pour cela nous devions créer une &quot;Data&quot; SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares). <br /> <br /> Heureusement, grâce à l'aide de notre tuteur, qui connait parfaitement le fonctionnement de SOFA, nous avons pu y arriver en créant des accès en lecture et en écriture de la façon suivante : <br /> <br /> Par exemple, dans la première fonction, on déclare un &quot;write accessor&quot; qui permet de faire le lien avec la DATA sofa préalablement déclarée, puis un &quot;read accessor&quot; <br /> <br /> <br /> sofa::Data&lt;vector&lt;float&gt; &gt; infosServosm // déclaration de la data SOFA dans le .h<br /> <br /> using sofa::helper::WriteAccessor; // déclaration pour pouvoir accéder aux fonctions de type &quot;Accessor&quot;<br /> using sofa::helper::ReadAccessor;<br /> <br /> WriteAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm= infosServosm; // déclaration dans la première fonction<br /> infosservosm.resize(50); // Permet de choisir la taille, ici 50<br /> <br /> ReadAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm = infosServosm; <br /> // déclaration dans la deuxième fonction pour accéder aux données, à savoir que la variable &quot;infosservosm&quot; crée s'utilise comme un tableau classique en C.<br /> <br /> <br /> * '''Jeudi 19/03''' <br /> Le problème du transfert de tableaux étant résolu, nous avons pu tester le programme que nous avions écrit quelques semaines auparavant. Pour cela, nous avons d'abord commencer par l'extraire de SOFA pour éviter la compilation trop longue de tout le projet. Après des tests comparatifs entre le nouveau et l'ancien programme, il s'est avéré que celui-ci fonctionnait parfaitement.<br /> Il ne nous restait plus qu'a réimplanter le code dans le projet SOFA.<br /> <br /> === Semaine 8 ===<br /> <br /> * ''' Lundi 23/03 ''' <br /> <br /> Pour tester le programme réimplanté dans SOFA, nous avons du recompiler le projet afin d'ajouter des plugings ce qui s'est avéré assez long. A la fin de la séance, nous avons pu commencer les tests et nous avons remarqué quelques bugs dans le code. <br /> <br /> * ''' Mercredi 25/03 '''<br /> <br /> Durant cette séance, nous avons pu résoudre certains problème du code du port série, mais il restait malgré tout non fonctionnel à cause d'une série d'instructions ne réalisant pas l'effet désiré. Nos encadrant étant absent, nous devions patienter jusqu’à jeudi afin d'obtenir les informations nécessaires. Pendant ce temps, nous avons pu commencer les tests sur le code Arduino que nous avions codé il y a quelques semaines déjà.<br /> <br /> * '''Jeudi 26/03 '''<br /> Nous avons résolu le problème concernant le code du port série, grâce aux indications de notre encadrant. Cette partie du code semble opérationnelle pour les servos moteurs. Il nous reste a effectuer les tests concernant les actionneurs pneumatiques. Nous avons ensuite continué les tests du code Arduino. Il semble opérationnel pour les servos moteurs. Le début des tests sur les actionneurs pneumatique a également été débuté.<br /> <br /> <br /> <br /> === Semaine 9 === <br /> <br /> * '''Lundi 30/03''' <br /> <br /> Nous avons terminé les tests concernant la partie Arduino. Le code fonctionne avec un robot n'ayant que des servos moteurs, un robot n'ayant que des pneumatiques ou les 2. Malgré tout, ces tests ont été effectués &quot;en dur&quot;, c'est à dire que cette partie n'est pas encore liée à la partie liaison série (il peut donc encore y avoir des problèmes de disponibilité ou de lecture au niveau du port série). Nous attendons que les tests concernant la liaison série soient concluants pour les 3 configurations d'actionneurs possibles avant de commencer les tests finaux. La toute dernière partie consistera à tester ces codes sur les robots disponibles à l'INRIA. Il nous faudra également ajouter les actionneurs hydrauliques si tout fonctionne, même si les tests ne pourront jamais être effectués car le laboratoire ne dispose pas d'un tel robot pour le moment. <br /> <br /> '''Missions pour les semaines à venir : '''<br /> <br /> - Objectif pour la fin de semaine : les parties Arduino et liaison série sont liées et fonctionnent.<br /> - Objectif pour la semaine prochaine : les tests ont été effectués sur les robots et l'actionneur hydraulique à été ajouté.<br /> - Objectif pour la semaine 11 : Mise en place des feedBacks des actionneurs du robot.<br /> <br /> * ''' Mercredi 01/04 '''<br /> Durant cette séance, nous avons effectué les tests pour les trois configurations possibles d'actionneurs dans la liaison série. Nous avons trouvé quelques bugs dans le code, mais nous sommes arrivée à les résoudre facilement. Il ne restait plus qu'a comparer le code des pneumatiques avec notre code généralisé sur l'interface SOFA. Nous avons également fait des tests sur l'arduino afin de résoudre à l'avance les différents problèmes de lecture pour que la liaison entre les deux codes se passe bien.<br /> <br /> * ''' Jeudi 02/04 '''<br /> Nous avons continué les tests sur l'Arduino, qui pour le moment s'avèrent concluant. Nous espérons qu'il en sera de même pour la liaison des deux codes.<br /> Nous avons également voulu tester le code de la liaison série sur SOFA. Nous avons alors ouvert la &quot;scène&quot; sofa contenant le robot pneumatique. Mais à cause d'une mise à jour, cette scène était inutilisable. Nous devions donc attendre que SOFA se mette à jour entièrement afin de tester (ce qui a pris plus ou moins 1h de mise à jour).<br /> <br /> ===Semaine 10===<br /> <br /> * ''' Lundi 06/04 '''<br /> Ce lundi était férié.<br /> <br /> * ''' Mercredi 08/04 ''' <br /> La mise à jour de SOFA devait s'accompagner de la mise à jour du pluging contenant la scène en question. Cette mise à jour est également assez longue.<br /> <br /> * ''' Jeudi 09/04 ''' <br /> Même en ayant réaliser la mise à jour du pluging et donc en arrivant enfin à obtenir la bonne scène, on avait quand même un warning qui nous indiquait que la liaison entre la scène et Sofa n'était pas faite. Nous avons quand même essayé de compiler notre programme mais nous n'arrivions pas à obtenir les bons résultats.<br /> <br /> ===Semaine 11===<br /> <br /> * ''' Lundi 13/04 '''<br /> Nous nous sommes rendues compte que le problème venait de la scène Sofa puisqu'on ne recevait que des 0. Et donc nous avons demandé à nos encadrants de nous aider. Ils ont donc réussi à corriger la scène Sofa du robot pneumatique qui contenait des bugs et ces derniers nous empêchaient de faire le lien avec notre code.<br /> <br /> * ''' Mardi 14/04 '''<br /> Après avoir effectué des tests sur sur l'arduino et sur la liaison série, nous avons commencé par définir les bonnes adresses des différentes broches du robot déformable avec les servomoteurs et de le régler à la bonne vitesse de transmission. Ensuite, nous avons transvaser notre code arduino sur la carte arduino Uno du robot. Les premiers tests sur le robot n'étaient pas très concluants.<br /> <br /> * ''' Mercredi 15/04 ''' <br /> <br /> On s'est en fait vite rendues compte qu'il y avait un problème de dépassement de mémoire. En effet, on avait fait tous nos tests avec une carte arduino Atmega 2560 mais le robot était équipé d'une carte arduino Uno dont l'espace mémoire était plus restreint. Afin de résoudre ce problème, nous avons diminué la taille des tableaux dans lesquels on stockait les différents types d'actionneurs de 50 à 10. Ayant régler ce problème, nous avons réussi à la fin de la séance à commander correctement le &quot;vrai&quot; robot déformable avec les servomoteurs.<br /> <br /> * ''' Jeudi 16/04 ''' <br /> Nous avons eu l'intervention de l'industriel valeo toute la matinée.<br /> <br /> ===Semaine 12===<br /> <br /> * ''' Lundi 20/04 '''<br /> Nous avons réglé quelques problèmes de conditions de transmission sur l'arduino pour les actionneurs pneumatiques et nous avons rentré les adresses des différentes broches. Nous avons ensuite vérifier notre code de la liaison série avant de tester sur le robot pneumatique. Enfin,<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=20382 2015-04-20T15:14:33Z

<p>Gelbez : /* Semaine 12 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> === Semaine 7 ===<br /> <br /> * '''Lundi 16/03'''<br /> Le but de la séance était de compiler la partie de code réimplantée dans le programme global du projet SOFA. Nous avons rencontré un problème lors de l'installation de SOFA, en effet une mauvaise version d'un programme nous empêchait de faire le lien avec la bibliothèque VRPN.<br /> <br /> * '''Mercredi 18/03'''<br /> Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction &quot;init&quot; puissent être utilisés dans la deuxième. Pour cela nous devions créer une &quot;Data&quot; SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares). <br /> <br /> Heureusement, grâce à l'aide de notre tuteur, qui connait parfaitement le fonctionnement de SOFA, nous avons pu y arriver en créant des accès en lecture et en écriture de la façon suivante : <br /> <br /> Par exemple, dans la première fonction, on déclare un &quot;write accessor&quot; qui permet de faire le lien avec la DATA sofa préalablement déclarée, puis un &quot;read accessor&quot; <br /> <br /> <br /> sofa::Data&lt;vector&lt;float&gt; &gt; infosServosm // déclaration de la data SOFA dans le .h<br /> <br /> using sofa::helper::WriteAccessor; // déclaration pour pouvoir accéder aux fonctions de type &quot;Accessor&quot;<br /> using sofa::helper::ReadAccessor;<br /> <br /> WriteAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm= infosServosm; // déclaration dans la première fonction<br /> infosservosm.resize(50); // Permet de choisir la taille, ici 50<br /> <br /> ReadAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm = infosServosm; <br /> // déclaration dans la deuxième fonction pour accéder aux données, à savoir que la variable &quot;infosservosm&quot; crée s'utilise comme un tableau classique en C.<br /> <br /> <br /> * '''Jeudi 19/03''' <br /> Le problème du transfert de tableaux étant résolu, nous avons pu tester le programme que nous avions écrit quelques semaines auparavant. Pour cela, nous avons d'abord commencer par l'extraire de SOFA pour éviter la compilation trop longue de tout le projet. Après des tests comparatifs entre le nouveau et l'ancien programme, il s'est avéré que celui-ci fonctionnait parfaitement.<br /> Il ne nous restait plus qu'a réimplanter le code dans le projet SOFA.<br /> <br /> === Semaine 8 ===<br /> <br /> * ''' Lundi 23/03 ''' <br /> <br /> Pour tester le programme réimplanté dans SOFA, nous avons du recompiler le projet afin d'ajouter des plugings ce qui s'est avéré assez long. A la fin de la séance, nous avons pu commencer les tests et nous avons remarqué quelques bugs dans le code. <br /> <br /> * ''' Mercredi 25/03 '''<br /> <br /> Durant cette séance, nous avons pu résoudre certains problème du code du port série, mais il restait malgré tout non fonctionnel à cause d'une série d'instructions ne réalisant pas l'effet désiré. Nos encadrant étant absent, nous devions patienter jusqu’à jeudi afin d'obtenir les informations nécessaires. Pendant ce temps, nous avons pu commencer les tests sur le code Arduino que nous avions codé il y a quelques semaines déjà.<br /> <br /> * '''Jeudi 26/03 '''<br /> Nous avons résolu le problème concernant le code du port série, grâce aux indications de notre encadrant. Cette partie du code semble opérationnelle pour les servos moteurs. Il nous reste a effectuer les tests concernant les actionneurs pneumatiques. Nous avons ensuite continué les tests du code Arduino. Il semble opérationnel pour les servos moteurs. Le début des tests sur les actionneurs pneumatique a également été débuté.<br /> <br /> <br /> <br /> === Semaine 9 === <br /> <br /> * '''Lundi 30/03''' <br /> <br /> Nous avons terminé les tests concernant la partie Arduino. Le code fonctionne avec un robot n'ayant que des servos moteurs, un robot n'ayant que des pneumatiques ou les 2. Malgré tout, ces tests ont été effectués &quot;en dur&quot;, c'est à dire que cette partie n'est pas encore liée à la partie liaison série (il peut donc encore y avoir des problèmes de disponibilité ou de lecture au niveau du port série). Nous attendons que les tests concernant la liaison série soient concluants pour les 3 configurations d'actionneurs possibles avant de commencer les tests finaux. La toute dernière partie consistera à tester ces codes sur les robots disponibles à l'INRIA. Il nous faudra également ajouter les actionneurs hydrauliques si tout fonctionne, même si les tests ne pourront jamais être effectués car le laboratoire ne dispose pas d'un tel robot pour le moment. <br /> <br /> '''Missions pour les semaines à venir : '''<br /> <br /> - Objectif pour la fin de semaine : les parties Arduino et liaison série sont liées et fonctionnent.<br /> - Objectif pour la semaine prochaine : les tests ont été effectués sur les robots et l'actionneur hydraulique à été ajouté.<br /> - Objectif pour la semaine 11 : Mise en place des feedBacks des actionneurs du robot.<br /> <br /> * ''' Mercredi 01/04 '''<br /> Durant cette séance, nous avons effectué les tests pour les trois configurations possibles d'actionneurs dans la liaison série. Nous avons trouvé quelques bugs dans le code, mais nous sommes arrivée à les résoudre facilement. Il ne restait plus qu'a comparer le code des pneumatiques avec notre code généralisé sur l'interface SOFA. Nous avons également fait des tests sur l'arduino afin de résoudre à l'avance les différents problèmes de lecture pour que la liaison entre les deux codes se passe bien.<br /> <br /> * ''' Jeudi 02/04 '''<br /> Nous avons continué les tests sur l'Arduino, qui pour le moment s'avèrent concluant. Nous espérons qu'il en sera de même pour la liaison des deux codes.<br /> Nous avons également voulu tester le code de la liaison série sur SOFA. Nous avons alors ouvert la &quot;scène&quot; sofa contenant le robot pneumatique. Mais à cause d'une mise à jour, cette scène était inutilisable. Nous devions donc attendre que SOFA se mette à jour entièrement afin de tester (ce qui a pris plus ou moins 1h de mise à jour).<br /> <br /> ===Semaine 10===<br /> <br /> * ''' Lundi 06/04 '''<br /> Ce lundi était férié.<br /> <br /> * ''' Mercredi 08/04 ''' <br /> La mise à jour de SOFA devait s'accompagner de la mise à jour du pluging contenant la scène en question. Cette mise à jour est également assez longue.<br /> <br /> * ''' Jeudi 09/04 ''' <br /> Même en ayant réaliser la mise à jour du pluging et donc en arrivant enfin à obtenir la bonne scène, on avait quand même un warning qui nous indiquait que la liaison entre la scène et Sofa n'était pas faite. Nous avons quand même essayer de compiler notre programme mais nous n'arrivions pas à obtenir les bons résultats.<br /> <br /> ===Semaine 11===<br /> <br /> * ''' Lundi 13/04 '''<br /> Nous nous sommes rendues compte que le problème venait de la scène Sofa puisqu'on ne recevait que des 0. Et donc nous avons demandé à nos encadrants de nous aider. Ils ont donc réussi à corriger la scène Sofa du robot pneumatique qui contenait des bugs et ces derniers nous empêchaient de faire le lien avec notre code.<br /> <br /> * ''' Mardi 14/04 '''<br /> Après avoir effectué des tests sur sur l'arduino et sur la liaison série, nous avons commencé par définir les bonnes adresses des différentes broches du robot déformable avec les servomoteurs et de le régler à la bonne vitesse de transmission. Ensuite, nous avons transvaser notre code arduino sur la carte arduino Uno du robot. Les premiers tests sur le robot n'étaient pas très concluants.<br /> <br /> * ''' Mercredi 15/04 ''' <br /> <br /> On s'est en fait vite rendues compte qu'il y avait un problème de dépassement de mémoire. En effet, on avait fait tous nos tests avec une carte arduino Atmega 2560 mais le robot était équipé d'une carte arduino Uno dont l'espace mémoire était plus restreint. Afin de résoudre ce problème, nous avons diminué la taille des tableaux dans lesquels on stockait les différents types d'actionneurs de 50 à 10. Ayant régler ce problème, nous avons réussi à la fin de la séance à commander correctement le &quot;vrai&quot; robot déformable avec les servomoteurs.<br /> <br /> * ''' Jeudi 16/04 ''' <br /> Nous avons eu l'intervention de l'industriel valeo toute la matinée.<br /> <br /> ===Semaine 12===<br /> <br /> * ''' Lundi 20/04 '''<br /> Nous avons réglé quelques problèmes de conditions de transmission sur l'arduino pour les actionneurs pneumatiques et nous avons rentré les adresses des différentes broches. Nous avons ensuite vérifier notre code de la liaison série avant de tester sur le robot pneumatique. Enfin,<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=20381 2015-04-20T15:01:41Z

<p>Gelbez : /* Semaine 11 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> === Semaine 7 ===<br /> <br /> * '''Lundi 16/03'''<br /> Le but de la séance était de compiler la partie de code réimplantée dans le programme global du projet SOFA. Nous avons rencontré un problème lors de l'installation de SOFA, en effet une mauvaise version d'un programme nous empêchait de faire le lien avec la bibliothèque VRPN.<br /> <br /> * '''Mercredi 18/03'''<br /> Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction &quot;init&quot; puissent être utilisés dans la deuxième. Pour cela nous devions créer une &quot;Data&quot; SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares). <br /> <br /> Heureusement, grâce à l'aide de notre tuteur, qui connait parfaitement le fonctionnement de SOFA, nous avons pu y arriver en créant des accès en lecture et en écriture de la façon suivante : <br /> <br /> Par exemple, dans la première fonction, on déclare un &quot;write accessor&quot; qui permet de faire le lien avec la DATA sofa préalablement déclarée, puis un &quot;read accessor&quot; <br /> <br /> <br /> sofa::Data&lt;vector&lt;float&gt; &gt; infosServosm // déclaration de la data SOFA dans le .h<br /> <br /> using sofa::helper::WriteAccessor; // déclaration pour pouvoir accéder aux fonctions de type &quot;Accessor&quot;<br /> using sofa::helper::ReadAccessor;<br /> <br /> WriteAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm= infosServosm; // déclaration dans la première fonction<br /> infosservosm.resize(50); // Permet de choisir la taille, ici 50<br /> <br /> ReadAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm = infosServosm; <br /> // déclaration dans la deuxième fonction pour accéder aux données, à savoir que la variable &quot;infosservosm&quot; crée s'utilise comme un tableau classique en C.<br /> <br /> <br /> * '''Jeudi 19/03''' <br /> Le problème du transfert de tableaux étant résolu, nous avons pu tester le programme que nous avions écrit quelques semaines auparavant. Pour cela, nous avons d'abord commencer par l'extraire de SOFA pour éviter la compilation trop longue de tout le projet. Après des tests comparatifs entre le nouveau et l'ancien programme, il s'est avéré que celui-ci fonctionnait parfaitement.<br /> Il ne nous restait plus qu'a réimplanter le code dans le projet SOFA.<br /> <br /> === Semaine 8 ===<br /> <br /> * ''' Lundi 23/03 ''' <br /> <br /> Pour tester le programme réimplanté dans SOFA, nous avons du recompiler le projet afin d'ajouter des plugings ce qui s'est avéré assez long. A la fin de la séance, nous avons pu commencer les tests et nous avons remarqué quelques bugs dans le code. <br /> <br /> * ''' Mercredi 25/03 '''<br /> <br /> Durant cette séance, nous avons pu résoudre certains problème du code du port série, mais il restait malgré tout non fonctionnel à cause d'une série d'instructions ne réalisant pas l'effet désiré. Nos encadrant étant absent, nous devions patienter jusqu’à jeudi afin d'obtenir les informations nécessaires. Pendant ce temps, nous avons pu commencer les tests sur le code Arduino que nous avions codé il y a quelques semaines déjà.<br /> <br /> * '''Jeudi 26/03 '''<br /> Nous avons résolu le problème concernant le code du port série, grâce aux indications de notre encadrant. Cette partie du code semble opérationnelle pour les servos moteurs. Il nous reste a effectuer les tests concernant les actionneurs pneumatiques. Nous avons ensuite continué les tests du code Arduino. Il semble opérationnel pour les servos moteurs. Le début des tests sur les actionneurs pneumatique a également été débuté.<br /> <br /> <br /> <br /> === Semaine 9 === <br /> <br /> * '''Lundi 30/03''' <br /> <br /> Nous avons terminé les tests concernant la partie Arduino. Le code fonctionne avec un robot n'ayant que des servos moteurs, un robot n'ayant que des pneumatiques ou les 2. Malgré tout, ces tests ont été effectués &quot;en dur&quot;, c'est à dire que cette partie n'est pas encore liée à la partie liaison série (il peut donc encore y avoir des problèmes de disponibilité ou de lecture au niveau du port série). Nous attendons que les tests concernant la liaison série soient concluants pour les 3 configurations d'actionneurs possibles avant de commencer les tests finaux. La toute dernière partie consistera à tester ces codes sur les robots disponibles à l'INRIA. Il nous faudra également ajouter les actionneurs hydrauliques si tout fonctionne, même si les tests ne pourront jamais être effectués car le laboratoire ne dispose pas d'un tel robot pour le moment. <br /> <br /> '''Missions pour les semaines à venir : '''<br /> <br /> - Objectif pour la fin de semaine : les parties Arduino et liaison série sont liées et fonctionnent.<br /> - Objectif pour la semaine prochaine : les tests ont été effectués sur les robots et l'actionneur hydraulique à été ajouté.<br /> - Objectif pour la semaine 11 : Mise en place des feedBacks des actionneurs du robot.<br /> <br /> * ''' Mercredi 01/04 '''<br /> Durant cette séance, nous avons effectué les tests pour les trois configurations possibles d'actionneurs dans la liaison série. Nous avons trouvé quelques bugs dans le code, mais nous sommes arrivée à les résoudre facilement. Il ne restait plus qu'a comparer le code des pneumatiques avec notre code généralisé sur l'interface SOFA. Nous avons également fait des tests sur l'arduino afin de résoudre à l'avance les différents problèmes de lecture pour que la liaison entre les deux codes se passe bien.<br /> <br /> * ''' Jeudi 02/04 '''<br /> Nous avons continué les tests sur l'Arduino, qui pour le moment s'avèrent concluant. Nous espérons qu'il en sera de même pour la liaison des deux codes.<br /> Nous avons également voulu tester le code de la liaison série sur SOFA. Nous avons alors ouvert la &quot;scène&quot; sofa contenant le robot pneumatique. Mais à cause d'une mise à jour, cette scène était inutilisable. Nous devions donc attendre que SOFA se mette à jour entièrement afin de tester (ce qui a pris plus ou moins 1h de mise à jour).<br /> <br /> ===Semaine 10===<br /> <br /> * ''' Lundi 06/04 '''<br /> Ce lundi était férié.<br /> <br /> * ''' Mercredi 08/04 ''' <br /> La mise à jour de SOFA devait s'accompagner de la mise à jour du pluging contenant la scène en question. Cette mise à jour est également assez longue.<br /> <br /> * ''' Jeudi 09/04 ''' <br /> Même en ayant réaliser la mise à jour du pluging et donc en arrivant enfin à obtenir la bonne scène, on avait quand même un warning qui nous indiquait que la liaison entre la scène et Sofa n'était pas faite. Nous avons quand même essayer de compiler notre programme mais nous n'arrivions pas à obtenir les bons résultats.<br /> <br /> ===Semaine 11===<br /> <br /> * ''' Lundi 13/04 '''<br /> Nous nous sommes rendues compte que le problème venait de la scène Sofa puisqu'on ne recevait que des 0. Et donc nous avons demandé à nos encadrants de nous aider. Ils ont donc réussi à corriger la scène Sofa du robot pneumatique qui contenait des bugs et ces derniers nous empêchaient de faire le lien avec notre code.<br /> <br /> * ''' Mardi 14/04 '''<br /> Après avoir effectué des tests sur sur l'arduino et sur la liaison série, nous avons commencé par définir les bonnes adresses des différentes broches du robot déformable avec les servomoteurs et de le régler à la bonne vitesse de transmission. Ensuite, nous avons transvaser notre code arduino sur la carte arduino Uno du robot. Les premiers tests sur le robot n'étaient pas très concluants.<br /> <br /> * ''' Mercredi 15/04 ''' <br /> <br /> On s'est en fait vite rendues compte qu'il y avait un problème de dépassement de mémoire. En effet, on avait fait tous nos tests avec une carte arduino Atmega 2560 mais le robot était équipé d'une carte arduino Uno dont l'espace mémoire était plus restreint. Afin de résoudre ce problème, nous avons diminué la taille des tableaux dans lesquels on stockait les différents types d'actionneurs de 50 à 10. Ayant régler ce problème, nous avons réussi à la fin de la séance à commander correctement le &quot;vrai&quot; robot déformable avec les servomoteurs.<br /> <br /> * ''' Jeudi 16/04 ''' <br /> Nous avons eu l'intervention de l'industriel valeo toute la matinée.<br /> <br /> ===Semaine 12===<br /> <br /> * ''' Lundi 20/04 '''<br /> Nous avons réglé quelques problèmes de conditions de transmission sur l'arduino pour les actionneurs pneumatiques et nous avons rentré les adresses des différentes broches. Nous avons ensuite vérifier notre code de la liaison série avant de tester sur le robot pneumatique.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=20380 2015-04-20T14:12:51Z

<p>Gelbez : /* Semaine 11 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> === Semaine 7 ===<br /> <br /> * '''Lundi 16/03'''<br /> Le but de la séance était de compiler la partie de code réimplantée dans le programme global du projet SOFA. Nous avons rencontré un problème lors de l'installation de SOFA, en effet une mauvaise version d'un programme nous empêchait de faire le lien avec la bibliothèque VRPN.<br /> <br /> * '''Mercredi 18/03'''<br /> Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction &quot;init&quot; puissent être utilisés dans la deuxième. Pour cela nous devions créer une &quot;Data&quot; SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares). <br /> <br /> Heureusement, grâce à l'aide de notre tuteur, qui connait parfaitement le fonctionnement de SOFA, nous avons pu y arriver en créant des accès en lecture et en écriture de la façon suivante : <br /> <br /> Par exemple, dans la première fonction, on déclare un &quot;write accessor&quot; qui permet de faire le lien avec la DATA sofa préalablement déclarée, puis un &quot;read accessor&quot; <br /> <br /> <br /> sofa::Data&lt;vector&lt;float&gt; &gt; infosServosm // déclaration de la data SOFA dans le .h<br /> <br /> using sofa::helper::WriteAccessor; // déclaration pour pouvoir accéder aux fonctions de type &quot;Accessor&quot;<br /> using sofa::helper::ReadAccessor;<br /> <br /> WriteAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm= infosServosm; // déclaration dans la première fonction<br /> infosservosm.resize(50); // Permet de choisir la taille, ici 50<br /> <br /> ReadAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm = infosServosm; <br /> // déclaration dans la deuxième fonction pour accéder aux données, à savoir que la variable &quot;infosservosm&quot; crée s'utilise comme un tableau classique en C.<br /> <br /> <br /> * '''Jeudi 19/03''' <br /> Le problème du transfert de tableaux étant résolu, nous avons pu tester le programme que nous avions écrit quelques semaines auparavant. Pour cela, nous avons d'abord commencer par l'extraire de SOFA pour éviter la compilation trop longue de tout le projet. Après des tests comparatifs entre le nouveau et l'ancien programme, il s'est avéré que celui-ci fonctionnait parfaitement.<br /> Il ne nous restait plus qu'a réimplanter le code dans le projet SOFA.<br /> <br /> === Semaine 8 ===<br /> <br /> * ''' Lundi 23/03 ''' <br /> <br /> Pour tester le programme réimplanté dans SOFA, nous avons du recompiler le projet afin d'ajouter des plugings ce qui s'est avéré assez long. A la fin de la séance, nous avons pu commencer les tests et nous avons remarqué quelques bugs dans le code. <br /> <br /> * ''' Mercredi 25/03 '''<br /> <br /> Durant cette séance, nous avons pu résoudre certains problème du code du port série, mais il restait malgré tout non fonctionnel à cause d'une série d'instructions ne réalisant pas l'effet désiré. Nos encadrant étant absent, nous devions patienter jusqu’à jeudi afin d'obtenir les informations nécessaires. Pendant ce temps, nous avons pu commencer les tests sur le code Arduino que nous avions codé il y a quelques semaines déjà.<br /> <br /> * '''Jeudi 26/03 '''<br /> Nous avons résolu le problème concernant le code du port série, grâce aux indications de notre encadrant. Cette partie du code semble opérationnelle pour les servos moteurs. Il nous reste a effectuer les tests concernant les actionneurs pneumatiques. Nous avons ensuite continué les tests du code Arduino. Il semble opérationnel pour les servos moteurs. Le début des tests sur les actionneurs pneumatique a également été débuté.<br /> <br /> <br /> <br /> === Semaine 9 === <br /> <br /> * '''Lundi 30/03''' <br /> <br /> Nous avons terminé les tests concernant la partie Arduino. Le code fonctionne avec un robot n'ayant que des servos moteurs, un robot n'ayant que des pneumatiques ou les 2. Malgré tout, ces tests ont été effectués &quot;en dur&quot;, c'est à dire que cette partie n'est pas encore liée à la partie liaison série (il peut donc encore y avoir des problèmes de disponibilité ou de lecture au niveau du port série). Nous attendons que les tests concernant la liaison série soient concluants pour les 3 configurations d'actionneurs possibles avant de commencer les tests finaux. La toute dernière partie consistera à tester ces codes sur les robots disponibles à l'INRIA. Il nous faudra également ajouter les actionneurs hydrauliques si tout fonctionne, même si les tests ne pourront jamais être effectués car le laboratoire ne dispose pas d'un tel robot pour le moment. <br /> <br /> '''Missions pour les semaines à venir : '''<br /> <br /> - Objectif pour la fin de semaine : les parties Arduino et liaison série sont liées et fonctionnent.<br /> - Objectif pour la semaine prochaine : les tests ont été effectués sur les robots et l'actionneur hydraulique à été ajouté.<br /> - Objectif pour la semaine 11 : Mise en place des feedBacks des actionneurs du robot.<br /> <br /> * ''' Mercredi 01/04 '''<br /> Durant cette séance, nous avons effectué les tests pour les trois configurations possibles d'actionneurs dans la liaison série. Nous avons trouvé quelques bugs dans le code, mais nous sommes arrivée à les résoudre facilement. Il ne restait plus qu'a comparer le code des pneumatiques avec notre code généralisé sur l'interface SOFA. Nous avons également fait des tests sur l'arduino afin de résoudre à l'avance les différents problèmes de lecture pour que la liaison entre les deux codes se passe bien.<br /> <br /> * ''' Jeudi 02/04 '''<br /> Nous avons continué les tests sur l'Arduino, qui pour le moment s'avèrent concluant. Nous espérons qu'il en sera de même pour la liaison des deux codes.<br /> Nous avons également voulu tester le code de la liaison série sur SOFA. Nous avons alors ouvert la &quot;scène&quot; sofa contenant le robot pneumatique. Mais à cause d'une mise à jour, cette scène était inutilisable. Nous devions donc attendre que SOFA se mette à jour entièrement afin de tester (ce qui a pris plus ou moins 1h de mise à jour).<br /> <br /> ===Semaine 10===<br /> <br /> * ''' Lundi 06/04 '''<br /> Ce lundi était férié.<br /> <br /> * ''' Mercredi 08/04 ''' <br /> La mise à jour de SOFA devait s'accompagner de la mise à jour du pluging contenant la scène en question. Cette mise à jour est également assez longue.<br /> <br /> * ''' Jeudi 09/04 ''' <br /> Même en ayant réaliser la mise à jour du pluging et donc en arrivant enfin à obtenir la bonne scène, on avait quand même un warning qui nous indiquait que la liaison entre la scène et Sofa n'était pas faite. Nous avons quand même essayer de compiler notre programme mais nous n'arrivions pas à obtenir les bons résultats.<br /> <br /> ===Semaine 11===<br /> <br /> * ''' Lundi 13/04 '''<br /> Nous nous sommes rendues compte que le problème venait de la scène Sofa puisqu'on ne recevait que des 0. Et donc nous avons demandé à nos encadrants de nous aider. Ils ont donc réussi à corriger la scène Sofa du robot pneumatique qui contenait des bugs et ces derniers nous empêchaient de faire le lien avec notre code.<br /> <br /> * ''' Mardi 14/04 '''<br /> Après avoir effectué des tests sur sur l'arduino et sur la liaison série, nous avons commencé par définir les bonnes adresses des différentes broches du robot déformable avec les servomoteurs et de le régler à la bonne vitesse de transmission. Ensuite, nous avons transvaser notre code arduino sur la carte arduino Uno du robot. Les premiers tests sur le robot n'étaient pas très concluants.<br /> <br /> * ''' Mercredi 15/04 ''' <br /> <br /> On s'est en fait vite rendues compte qu'il y avait un problème de dépassement de mémoire. En effet, on avait fait tous nos tests avec une carte arduino Atmega 2560 mais le robot était équipé d'une carte arduino Uno dont l'espace mémoire était plus restreint. Afin de résoudre ce problème, nous avons diminué la taille des tableaux dans lesquels on stockait les différents types d'actionneurs de 50 à 10. Ayant régler ce problème, nous avons réussi à la fin de la séance à commander correctement le robot déformable avec les servomoteurs.<br /> <br /> * ''' Jeudi 16/04 ''' <br /> Nous avons eu l'intervention de l'industriel valeo toute la matinée.<br /> <br /> ===Semaine 12===<br /> <br /> * ''' Lundi 20/04 '''<br /> Nous avons réglé quelques problèmes de conditions de transmission sur l'arduino pour les actionneurs pneumatiques et nous avons rentré les adresses des différentes broches. Nous avons ensuite vérifier notre code de la liaison série avant de tester sur le robot pneumatique.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=20356 2015-04-20T13:17:46Z

<p>Gelbez : /* Semaine 11 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> === Semaine 7 ===<br /> <br /> * '''Lundi 16/03'''<br /> Le but de la séance était de compiler la partie de code réimplantée dans le programme global du projet SOFA. Nous avons rencontré un problème lors de l'installation de SOFA, en effet une mauvaise version d'un programme nous empêchait de faire le lien avec la bibliothèque VRPN.<br /> <br /> * '''Mercredi 18/03'''<br /> Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction &quot;init&quot; puissent être utilisés dans la deuxième. Pour cela nous devions créer une &quot;Data&quot; SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares). <br /> <br /> Heureusement, grâce à l'aide de notre tuteur, qui connait parfaitement le fonctionnement de SOFA, nous avons pu y arriver en créant des accès en lecture et en écriture de la façon suivante : <br /> <br /> Par exemple, dans la première fonction, on déclare un &quot;write accessor&quot; qui permet de faire le lien avec la DATA sofa préalablement déclarée, puis un &quot;read accessor&quot; <br /> <br /> <br /> sofa::Data&lt;vector&lt;float&gt; &gt; infosServosm // déclaration de la data SOFA dans le .h<br /> <br /> using sofa::helper::WriteAccessor; // déclaration pour pouvoir accéder aux fonctions de type &quot;Accessor&quot;<br /> using sofa::helper::ReadAccessor;<br /> <br /> WriteAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm= infosServosm; // déclaration dans la première fonction<br /> infosservosm.resize(50); // Permet de choisir la taille, ici 50<br /> <br /> ReadAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm = infosServosm; <br /> // déclaration dans la deuxième fonction pour accéder aux données, à savoir que la variable &quot;infosservosm&quot; crée s'utilise comme un tableau classique en C.<br /> <br /> <br /> * '''Jeudi 19/03''' <br /> Le problème du transfert de tableaux étant résolu, nous avons pu tester le programme que nous avions écrit quelques semaines auparavant. Pour cela, nous avons d'abord commencer par l'extraire de SOFA pour éviter la compilation trop longue de tout le projet. Après des tests comparatifs entre le nouveau et l'ancien programme, il s'est avéré que celui-ci fonctionnait parfaitement.<br /> Il ne nous restait plus qu'a réimplanter le code dans le projet SOFA.<br /> <br /> === Semaine 8 ===<br /> <br /> * ''' Lundi 23/03 ''' <br /> <br /> Pour tester le programme réimplanté dans SOFA, nous avons du recompiler le projet afin d'ajouter des plugings ce qui s'est avéré assez long. A la fin de la séance, nous avons pu commencer les tests et nous avons remarqué quelques bugs dans le code. <br /> <br /> * ''' Mercredi 25/03 '''<br /> <br /> Durant cette séance, nous avons pu résoudre certains problème du code du port série, mais il restait malgré tout non fonctionnel à cause d'une série d'instructions ne réalisant pas l'effet désiré. Nos encadrant étant absent, nous devions patienter jusqu’à jeudi afin d'obtenir les informations nécessaires. Pendant ce temps, nous avons pu commencer les tests sur le code Arduino que nous avions codé il y a quelques semaines déjà.<br /> <br /> * '''Jeudi 26/03 '''<br /> Nous avons résolu le problème concernant le code du port série, grâce aux indications de notre encadrant. Cette partie du code semble opérationnelle pour les servos moteurs. Il nous reste a effectuer les tests concernant les actionneurs pneumatiques. Nous avons ensuite continué les tests du code Arduino. Il semble opérationnel pour les servos moteurs. Le début des tests sur les actionneurs pneumatique a également été débuté.<br /> <br /> <br /> <br /> === Semaine 9 === <br /> <br /> * '''Lundi 30/03''' <br /> <br /> Nous avons terminé les tests concernant la partie Arduino. Le code fonctionne avec un robot n'ayant que des servos moteurs, un robot n'ayant que des pneumatiques ou les 2. Malgré tout, ces tests ont été effectués &quot;en dur&quot;, c'est à dire que cette partie n'est pas encore liée à la partie liaison série (il peut donc encore y avoir des problèmes de disponibilité ou de lecture au niveau du port série). Nous attendons que les tests concernant la liaison série soient concluants pour les 3 configurations d'actionneurs possibles avant de commencer les tests finaux. La toute dernière partie consistera à tester ces codes sur les robots disponibles à l'INRIA. Il nous faudra également ajouter les actionneurs hydrauliques si tout fonctionne, même si les tests ne pourront jamais être effectués car le laboratoire ne dispose pas d'un tel robot pour le moment. <br /> <br /> '''Missions pour les semaines à venir : '''<br /> <br /> - Objectif pour la fin de semaine : les parties Arduino et liaison série sont liées et fonctionnent.<br /> - Objectif pour la semaine prochaine : les tests ont été effectués sur les robots et l'actionneur hydraulique à été ajouté.<br /> - Objectif pour la semaine 11 : Mise en place des feedBacks des actionneurs du robot.<br /> <br /> * ''' Mercredi 01/04 '''<br /> Durant cette séance, nous avons effectué les tests pour les trois configurations possibles d'actionneurs dans la liaison série. Nous avons trouvé quelques bugs dans le code, mais nous sommes arrivée à les résoudre facilement. Il ne restait plus qu'a comparer le code des pneumatiques avec notre code généralisé sur l'interface SOFA. Nous avons également fait des tests sur l'arduino afin de résoudre à l'avance les différents problèmes de lecture pour que la liaison entre les deux codes se passe bien.<br /> <br /> * ''' Jeudi 02/04 '''<br /> Nous avons continué les tests sur l'Arduino, qui pour le moment s'avèrent concluant. Nous espérons qu'il en sera de même pour la liaison des deux codes.<br /> Nous avons également voulu tester le code de la liaison série sur SOFA. Nous avons alors ouvert la &quot;scène&quot; sofa contenant le robot pneumatique. Mais à cause d'une mise à jour, cette scène était inutilisable. Nous devions donc attendre que SOFA se mette à jour entièrement afin de tester (ce qui a pris plus ou moins 1h de mise à jour).<br /> <br /> ===Semaine 10===<br /> <br /> * ''' Lundi 06/04 '''<br /> Ce lundi était férié.<br /> <br /> * ''' Mercredi 08/04 ''' <br /> La mise à jour de SOFA devait s'accompagner de la mise à jour du pluging contenant la scène en question. Cette mise à jour est également assez longue.<br /> <br /> * ''' Jeudi 09/04 ''' <br /> Même en ayant réaliser la mise à jour du pluging et donc en arrivant enfin à obtenir la bonne scène, on avait quand même un warning qui nous indiquait que la liaison entre la scène et Sofa n'était pas faite. Nous avons quand même essayer de compiler notre programme mais nous n'arrivions pas à obtenir les bons résultats.<br /> <br /> ===Semaine 11===<br /> <br /> * ''' Lundi 13/04 '''<br /> Nous nous sommes rendues compte que le problème venait de la scène Sofa puisqu'on ne recevait que des 0. Et donc nous avons demandé à nos encadrants de nous aider. Ils ont donc réussi à corriger la scène Sofa du robot pneumatique qui contenait des bugs et ces derniers nous empêchaient de faire le lien avec notre code.<br /> <br /> * ''' Mardi 14/04 '''<br /> Après avoir effectué des tests sur sur l'arduino et sur la liaison série, nous avons commencé par définir les bonnes adresses des différentes broches du robot déformable avec les servomoteurs et de le régler à la bonne vitesse de transmission. Ensuite, nous avons transvaser notre code arduino sur la carte arduino Uno du robot. Les premiers tests sur le robot n'étaient pas très concluants.<br /> <br /> * ''' Mercredi 15/04 ''' <br /> <br /> On s'est en fait vite rendues compte qu'il y avait un problème de dépassement de mémoire. En effet, on avait fait tous nos tests avec une carte arduino Atmega 2560 mais le robot était équipé d'une carte arduino Uno dont l'espace mémoire était plus restreint. Afin de résoudre ce problème, nous avons diminué la taille des tableaux dans lesquels on stockait les différents types d'actionneurs de 50 à 10. Ayant régler ce problème, nous avons réussi à la fin de la séance à commander correctement le robot déformable avec les servomoteurs.<br /> <br /> * ''' Jeudi 16/04 ''' <br /> Nous avons eu l'intervention de l'industriel valeo toute la matinée.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=20355 2015-04-20T13:17:24Z

<p>Gelbez : /* Semaine 10 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> === Semaine 7 ===<br /> <br /> * '''Lundi 16/03'''<br /> Le but de la séance était de compiler la partie de code réimplantée dans le programme global du projet SOFA. Nous avons rencontré un problème lors de l'installation de SOFA, en effet une mauvaise version d'un programme nous empêchait de faire le lien avec la bibliothèque VRPN.<br /> <br /> * '''Mercredi 18/03'''<br /> Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction &quot;init&quot; puissent être utilisés dans la deuxième. Pour cela nous devions créer une &quot;Data&quot; SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares). <br /> <br /> Heureusement, grâce à l'aide de notre tuteur, qui connait parfaitement le fonctionnement de SOFA, nous avons pu y arriver en créant des accès en lecture et en écriture de la façon suivante : <br /> <br /> Par exemple, dans la première fonction, on déclare un &quot;write accessor&quot; qui permet de faire le lien avec la DATA sofa préalablement déclarée, puis un &quot;read accessor&quot; <br /> <br /> <br /> sofa::Data&lt;vector&lt;float&gt; &gt; infosServosm // déclaration de la data SOFA dans le .h<br /> <br /> using sofa::helper::WriteAccessor; // déclaration pour pouvoir accéder aux fonctions de type &quot;Accessor&quot;<br /> using sofa::helper::ReadAccessor;<br /> <br /> WriteAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm= infosServosm; // déclaration dans la première fonction<br /> infosservosm.resize(50); // Permet de choisir la taille, ici 50<br /> <br /> ReadAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm = infosServosm; <br /> // déclaration dans la deuxième fonction pour accéder aux données, à savoir que la variable &quot;infosservosm&quot; crée s'utilise comme un tableau classique en C.<br /> <br /> <br /> * '''Jeudi 19/03''' <br /> Le problème du transfert de tableaux étant résolu, nous avons pu tester le programme que nous avions écrit quelques semaines auparavant. Pour cela, nous avons d'abord commencer par l'extraire de SOFA pour éviter la compilation trop longue de tout le projet. Après des tests comparatifs entre le nouveau et l'ancien programme, il s'est avéré que celui-ci fonctionnait parfaitement.<br /> Il ne nous restait plus qu'a réimplanter le code dans le projet SOFA.<br /> <br /> === Semaine 8 ===<br /> <br /> * ''' Lundi 23/03 ''' <br /> <br /> Pour tester le programme réimplanté dans SOFA, nous avons du recompiler le projet afin d'ajouter des plugings ce qui s'est avéré assez long. A la fin de la séance, nous avons pu commencer les tests et nous avons remarqué quelques bugs dans le code. <br /> <br /> * ''' Mercredi 25/03 '''<br /> <br /> Durant cette séance, nous avons pu résoudre certains problème du code du port série, mais il restait malgré tout non fonctionnel à cause d'une série d'instructions ne réalisant pas l'effet désiré. Nos encadrant étant absent, nous devions patienter jusqu’à jeudi afin d'obtenir les informations nécessaires. Pendant ce temps, nous avons pu commencer les tests sur le code Arduino que nous avions codé il y a quelques semaines déjà.<br /> <br /> * '''Jeudi 26/03 '''<br /> Nous avons résolu le problème concernant le code du port série, grâce aux indications de notre encadrant. Cette partie du code semble opérationnelle pour les servos moteurs. Il nous reste a effectuer les tests concernant les actionneurs pneumatiques. Nous avons ensuite continué les tests du code Arduino. Il semble opérationnel pour les servos moteurs. Le début des tests sur les actionneurs pneumatique a également été débuté.<br /> <br /> <br /> <br /> === Semaine 9 === <br /> <br /> * '''Lundi 30/03''' <br /> <br /> Nous avons terminé les tests concernant la partie Arduino. Le code fonctionne avec un robot n'ayant que des servos moteurs, un robot n'ayant que des pneumatiques ou les 2. Malgré tout, ces tests ont été effectués &quot;en dur&quot;, c'est à dire que cette partie n'est pas encore liée à la partie liaison série (il peut donc encore y avoir des problèmes de disponibilité ou de lecture au niveau du port série). Nous attendons que les tests concernant la liaison série soient concluants pour les 3 configurations d'actionneurs possibles avant de commencer les tests finaux. La toute dernière partie consistera à tester ces codes sur les robots disponibles à l'INRIA. Il nous faudra également ajouter les actionneurs hydrauliques si tout fonctionne, même si les tests ne pourront jamais être effectués car le laboratoire ne dispose pas d'un tel robot pour le moment. <br /> <br /> '''Missions pour les semaines à venir : '''<br /> <br /> - Objectif pour la fin de semaine : les parties Arduino et liaison série sont liées et fonctionnent.<br /> - Objectif pour la semaine prochaine : les tests ont été effectués sur les robots et l'actionneur hydraulique à été ajouté.<br /> - Objectif pour la semaine 11 : Mise en place des feedBacks des actionneurs du robot.<br /> <br /> * ''' Mercredi 01/04 '''<br /> Durant cette séance, nous avons effectué les tests pour les trois configurations possibles d'actionneurs dans la liaison série. Nous avons trouvé quelques bugs dans le code, mais nous sommes arrivée à les résoudre facilement. Il ne restait plus qu'a comparer le code des pneumatiques avec notre code généralisé sur l'interface SOFA. Nous avons également fait des tests sur l'arduino afin de résoudre à l'avance les différents problèmes de lecture pour que la liaison entre les deux codes se passe bien.<br /> <br /> * ''' Jeudi 02/04 '''<br /> Nous avons continué les tests sur l'Arduino, qui pour le moment s'avèrent concluant. Nous espérons qu'il en sera de même pour la liaison des deux codes.<br /> Nous avons également voulu tester le code de la liaison série sur SOFA. Nous avons alors ouvert la &quot;scène&quot; sofa contenant le robot pneumatique. Mais à cause d'une mise à jour, cette scène était inutilisable. Nous devions donc attendre que SOFA se mette à jour entièrement afin de tester (ce qui a pris plus ou moins 1h de mise à jour).<br /> <br /> ===Semaine 10===<br /> <br /> * ''' Lundi 06/04 '''<br /> Ce lundi était férié.<br /> <br /> * ''' Mercredi 08/04 ''' <br /> La mise à jour de SOFA devait s'accompagner de la mise à jour du pluging contenant la scène en question. Cette mise à jour est également assez longue.<br /> <br /> * ''' Jeudi 09/04 ''' <br /> Même en ayant réaliser la mise à jour du pluging et donc en arrivant enfin à obtenir la bonne scène, on avait quand même un warning qui nous indiquait que la liaison entre la scène et Sofa n'était pas faite. Nous avons quand même essayer de compiler notre programme mais nous n'arrivions pas à obtenir les bons résultats.<br /> <br /> ===Semaine 11===<br /> <br /> * ''' Lundi 13/04 '''<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=20339 2015-04-20T12:28:27Z

<p>Gelbez : /* Semaine 9 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> === Semaine 7 ===<br /> <br /> * '''Lundi 16/03'''<br /> Le but de la séance était de compiler la partie de code réimplantée dans le programme global du projet SOFA. Nous avons rencontré un problème lors de l'installation de SOFA, en effet une mauvaise version d'un programme nous empêchait de faire le lien avec la bibliothèque VRPN.<br /> <br /> * '''Mercredi 18/03'''<br /> Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction &quot;init&quot; puissent être utilisés dans la deuxième. Pour cela nous devions créer une &quot;Data&quot; SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares). <br /> <br /> Heureusement, grâce à l'aide de notre tuteur, qui connait parfaitement le fonctionnement de SOFA, nous avons pu y arriver en créant des accès en lecture et en écriture de la façon suivante : <br /> <br /> Par exemple, dans la première fonction, on déclare un &quot;write accessor&quot; qui permet de faire le lien avec la DATA sofa préalablement déclarée, puis un &quot;read accessor&quot; <br /> <br /> <br /> sofa::Data&lt;vector&lt;float&gt; &gt; infosServosm // déclaration de la data SOFA dans le .h<br /> <br /> using sofa::helper::WriteAccessor; // déclaration pour pouvoir accéder aux fonctions de type &quot;Accessor&quot;<br /> using sofa::helper::ReadAccessor;<br /> <br /> WriteAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm= infosServosm; // déclaration dans la première fonction<br /> infosservosm.resize(50); // Permet de choisir la taille, ici 50<br /> <br /> ReadAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm = infosServosm; <br /> // déclaration dans la deuxième fonction pour accéder aux données, à savoir que la variable &quot;infosservosm&quot; crée s'utilise comme un tableau classique en C.<br /> <br /> <br /> * '''Jeudi 19/03''' <br /> Le problème du transfert de tableaux étant résolu, nous avons pu tester le programme que nous avions écrit quelques semaines auparavant. Pour cela, nous avons d'abord commencer par l'extraire de SOFA pour éviter la compilation trop longue de tout le projet. Après des tests comparatifs entre le nouveau et l'ancien programme, il s'est avéré que celui-ci fonctionnait parfaitement.<br /> Il ne nous restait plus qu'a réimplanter le code dans le projet SOFA.<br /> <br /> === Semaine 8 ===<br /> <br /> * ''' Lundi 23/03 ''' <br /> <br /> Pour tester le programme réimplanté dans SOFA, nous avons du recompiler le projet afin d'ajouter des plugings ce qui s'est avéré assez long. A la fin de la séance, nous avons pu commencer les tests et nous avons remarqué quelques bugs dans le code. <br /> <br /> * ''' Mercredi 25/03 '''<br /> <br /> Durant cette séance, nous avons pu résoudre certains problème du code du port série, mais il restait malgré tout non fonctionnel à cause d'une série d'instructions ne réalisant pas l'effet désiré. Nos encadrant étant absent, nous devions patienter jusqu’à jeudi afin d'obtenir les informations nécessaires. Pendant ce temps, nous avons pu commencer les tests sur le code Arduino que nous avions codé il y a quelques semaines déjà.<br /> <br /> * '''Jeudi 26/03 '''<br /> Nous avons résolu le problème concernant le code du port série, grâce aux indications de notre encadrant. Cette partie du code semble opérationnelle pour les servos moteurs. Il nous reste a effectuer les tests concernant les actionneurs pneumatiques. Nous avons ensuite continué les tests du code Arduino. Il semble opérationnel pour les servos moteurs. Le début des tests sur les actionneurs pneumatique a également été débuté.<br /> <br /> <br /> <br /> === Semaine 9 === <br /> <br /> * '''Lundi 30/03''' <br /> <br /> Nous avons terminé les tests concernant la partie Arduino. Le code fonctionne avec un robot n'ayant que des servos moteurs, un robot n'ayant que des pneumatiques ou les 2. Malgré tout, ces tests ont été effectués &quot;en dur&quot;, c'est à dire que cette partie n'est pas encore liée à la partie liaison série (il peut donc encore y avoir des problèmes de disponibilité ou de lecture au niveau du port série). Nous attendons que les tests concernant la liaison série soient concluants pour les 3 configurations d'actionneurs possibles avant de commencer les tests finaux. La toute dernière partie consistera à tester ces codes sur les robots disponibles à l'INRIA. Il nous faudra également ajouter les actionneurs hydrauliques si tout fonctionne, même si les tests ne pourront jamais être effectués car le laboratoire ne dispose pas d'un tel robot pour le moment. <br /> <br /> '''Missions pour les semaines à venir : '''<br /> <br /> - Objectif pour la fin de semaine : les parties Arduino et liaison série sont liées et fonctionnent.<br /> - Objectif pour la semaine prochaine : les tests ont été effectués sur les robots et l'actionneur hydraulique à été ajouté.<br /> - Objectif pour la semaine 11 : Mise en place des feedBacks des actionneurs du robot.<br /> <br /> * ''' Mercredi 01/04 '''<br /> Durant cette séance, nous avons effectué les tests pour les trois configurations possibles d'actionneurs dans la liaison série. Nous avons trouvé quelques bugs dans le code, mais nous sommes arrivée à les résoudre facilement. Il ne restait plus qu'a comparer le code des pneumatiques avec notre code généralisé sur l'interface SOFA. Nous avons également fait des tests sur l'arduino afin de résoudre à l'avance les différents problèmes de lecture pour que la liaison entre les deux codes se passe bien.<br /> <br /> * ''' Jeudi 02/04 '''<br /> Nous avons continué les tests sur l'Arduino, qui pour le moment s'avèrent concluant. Nous espérons qu'il en sera de même pour la liaison des deux codes.<br /> Nous avons également voulu tester le code de la liaison série sur SOFA. Nous avons alors ouvert la &quot;scène&quot; sofa contenant le robot pneumatique. Mais à cause d'une mise à jour, cette scène était inutilisable. Nous devions donc attendre que SOFA se mette à jour entièrement afin de tester (ce qui a pris plus ou moins 1h de mise à jour).<br /> <br /> ===Semaine 10===<br /> <br /> * ''' Lundi 06/04 '''<br /> Ce lundi était férié.<br /> <br /> * ''' Mercredi 08/04 ''' <br /> La mise à jour de SOFA devait s'accompagnée de la mise à jour du pluging contenant la scène en question. Cette mise à jour est également assez longue.<br /> <br /> * ''' Jeudi 09/04 ''' <br /> Nous avons fait quelques modifications sur le code de la liaison série <br /> <br /> ===Semaine 11===<br /> <br /> * ''' Lundi 13/04 '''<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=20338 2015-04-20T12:27:11Z

<p>Gelbez : /* Semaine 10 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> === Semaine 7 ===<br /> <br /> * '''Lundi 16/03'''<br /> Le but de la séance était de compiler la partie de code réimplantée dans le programme global du projet SOFA. Nous avons rencontré un problème lors de l'installation de SOFA, en effet une mauvaise version d'un programme nous empêchait de faire le lien avec la bibliothèque VRPN.<br /> <br /> * '''Mercredi 18/03'''<br /> Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction &quot;init&quot; puissent être utilisés dans la deuxième. Pour cela nous devions créer une &quot;Data&quot; SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares). <br /> <br /> Heureusement, grâce à l'aide de notre tuteur, qui connait parfaitement le fonctionnement de SOFA, nous avons pu y arriver en créant des accès en lecture et en écriture de la façon suivante : <br /> <br /> Par exemple, dans la première fonction, on déclare un &quot;write accessor&quot; qui permet de faire le lien avec la DATA sofa préalablement déclarée, puis un &quot;read accessor&quot; <br /> <br /> <br /> sofa::Data&lt;vector&lt;float&gt; &gt; infosServosm // déclaration de la data SOFA dans le .h<br /> <br /> using sofa::helper::WriteAccessor; // déclaration pour pouvoir accéder aux fonctions de type &quot;Accessor&quot;<br /> using sofa::helper::ReadAccessor;<br /> <br /> WriteAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm= infosServosm; // déclaration dans la première fonction<br /> infosservosm.resize(50); // Permet de choisir la taille, ici 50<br /> <br /> ReadAccessor&lt;Data&lt;vector&lt;float&gt; &gt; &gt; infosservosm = infosServosm; <br /> // déclaration dans la deuxième fonction pour accéder aux données, à savoir que la variable &quot;infosservosm&quot; crée s'utilise comme un tableau classique en C.<br /> <br /> <br /> * '''Jeudi 19/03''' <br /> Le problème du transfert de tableaux étant résolu, nous avons pu tester le programme que nous avions écrit quelques semaines auparavant. Pour cela, nous avons d'abord commencer par l'extraire de SOFA pour éviter la compilation trop longue de tout le projet. Après des tests comparatifs entre le nouveau et l'ancien programme, il s'est avéré que celui-ci fonctionnait parfaitement.<br /> Il ne nous restait plus qu'a réimplanter le code dans le projet SOFA.<br /> <br /> === Semaine 8 ===<br /> <br /> * ''' Lundi 23/03 ''' <br /> <br /> Pour tester le programme réimplanté dans SOFA, nous avons du recompiler le projet afin d'ajouter des plugings ce qui s'est avéré assez long. A la fin de la séance, nous avons pu commencer les tests et nous avons remarqué quelques bugs dans le code. <br /> <br /> * ''' Mercredi 25/03 '''<br /> <br /> Durant cette séance, nous avons pu résoudre certains problème du code du port série, mais il restait malgré tout non fonctionnel à cause d'une série d'instructions ne réalisant pas l'effet désiré. Nos encadrant étant absent, nous devions patienter jusqu’à jeudi afin d'obtenir les informations nécessaires. Pendant ce temps, nous avons pu commencer les tests sur le code Arduino que nous avions codé il y a quelques semaines déjà.<br /> <br /> * '''Jeudi 26/03 '''<br /> Nous avons résolu le problème concernant le code du port série, grâce aux indications de notre encadrant. Cette partie du code semble opérationnelle pour les servos moteurs. Il nous reste a effectuer les tests concernant les actionneurs pneumatiques. Nous avons ensuite continué les tests du code Arduino. Il semble opérationnel pour les servos moteurs. Le début des tests sur les actionneurs pneumatique a également été débuté.<br /> <br /> <br /> <br /> === Semaine 9 === <br /> <br /> * '''Lundi 30/03''' <br /> <br /> Nous avons terminé les tests concernant la partie Arduino. Le code fonctionne avec un robot n'ayant que des servos moteurs, un robot n'ayant que des pneumatiques ou les 2. Malgré tout, ces tests ont été effectués &quot;en dur&quot;, c'est à dire que cette partie n'est pas encore liée à la partie liaison série (il peut donc encore y avoir des problèmes de disponibilité ou de lecture au niveau du port série). Nous attendons que les tests concernant la liaison série soient concluants pour les 3 configurations d'actionneurs possibles avant de commencer les tests finaux. La toute dernière partie consistera à tester ces codes sur les robots disponibles à l'INRIA. Il nous faudra également ajouter les actionneurs hydrauliques si tout fonctionne, même si les tests ne pourront jamais être effectués car le laboratoire ne dispose pas d'un tel robot pour le moment. <br /> <br /> '''Missions pour les semaines à venir : '''<br /> <br /> - Objectif pour la fin de semaine : les parties Arduino et liaison série sont liées et fonctionnent.<br /> - Objectif pour la semaine prochaine : les tests ont été effectués sur les robots et l'actionneur hydraulique à été ajouté.<br /> - Objectif pour la semaine 11 : Mise en place des feedBacks des actionneurs du robot.<br /> <br /> * ''' Mercredi 01/04 '''<br /> Durant cette séance, nous avons effectué les tests pour les trois configurations possibles d'actionneurs dans la liaison série. Nous avons trouvé quelques bugs dans le code, mais nous sommes arrivée à les résoudre facilement. Il ne restait plus qu'a comparer le code des pneumatiques avec notre code généralisé sur l'interface SOFA. Nous avons également fait des tests sur l'arduino afin de résoudre à l'avance les différents problèmes de lecture pour que la liaison entre les deux codes se passe bien.<br /> <br /> * ''' Jeudi 02/04 '''<br /> Nous avons continué les tests sur l'Arduino, qui pour le moment s'avèrent concluant. Nous espérons qu'il en sera de même pour la liaison des deux codes.<br /> Nous avons également voulu tester le code de la liaison série sur SOFA. Nous avons alors ouvert la &quot;scène&quot; sofa contenant le robot pneumatique. Mais à cause d'une mise à jour, cette scène était inutilisable. Nous devions donc attendre que SOFA se mette à jour entièrement afin de tester (il a plus ou moins 1h de mise à jour).<br /> <br /> <br /> ===Semaine 10===<br /> <br /> * ''' Lundi 06/04 '''<br /> Ce lundi était férié.<br /> <br /> * ''' Mercredi 08/04 ''' <br /> La mise à jour de SOFA devait s'accompagnée de la mise à jour du pluging contenant la scène en question. Cette mise à jour est également assez longue.<br /> <br /> * ''' Jeudi 09/04 ''' <br /> Nous avons fait quelques modifications sur le code de la liaison série <br /> <br /> ===Semaine 11===<br /> <br /> * ''' Lundi 13/04 '''<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=18911 2015-03-18T14:42:52Z

<p>Gelbez : v</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> === Semaine 7 ===<br /> <br /> * '''Lundi 16/03'''<br /> Le but de la séance était de compiler la partie de code réimplanté dans le programme global du projet SOFA. Nous avons rencontré un problème lors de l'installation de SOFA, en effet une mauvaise version d'un programme nous empêchait de faire le lien avec la bibliothèque VRPN.<br /> <br /> * '''Jeudi 18/03'''<br /> Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction puisse être utilisés dans la deuxième. Pour cela nous devions créer une &quot;Data&quot; SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares)<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=18545 2015-03-11T16:27:47Z

<p>Gelbez : /* Semaine 6 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons commencé à modifier le programme du plug-in SoftRobot.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=18500 2015-03-11T14:34:30Z

<p>Gelbez : /* Semaine 6 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA] et nous avons regardé le programme du plug-in SoftRobot.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=18494 2015-03-11T14:29:27Z

<p>Gelbez : /* Semaine 5 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :'''<br /> Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :'''<br /> Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons également généralisé ce programme Arduino (permettant le contrôle des différents moteurs après réception des données envoyées par la liaison série). Le programme avait été réalisé pour le robot déformable et donc uniquement pour ses quatre moteurs (nord, sud, est, ouest). Le but était donc de pouvoir l’utiliser pour un nombre de moteurs indéfini, placé par la suite en paramètre. Nous n’avons pas rencontré de difficultés particulières, car il s’agissait généralement de remplacer les variables par des tableaux. Malgré tout, il était impossible de créer directement un tableau de servos moteur avec la bibliothèque « servo.h ». Nous avons donc dû créer une structure, contenant une variable de type servo, afin de pouvoir achever ce programme : <br /> <br /> <br /> struct servom{<br /> Servo servo;<br /> };<br /> servom servomo[nbMotors-1]; <br /> <br /> <br /> Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.<br /> <br /> <br /> * '''Jeudi 29/01''' :<br /> Lors de cette séance, nous avons testé notre programme Arduino. Malheureusement, de nombreux dysfonctionnements du matériel (et notamment de l’Arduino et de sa plaque de connexion) nous ont ralenti. En effet, les problèmes de connexion à l’Arduino et les mauvais contacts entre le support et les moteurs ne nous permettaient pas de savoir si les mauvais résultats des essais étaient dus au matériel ou au programme. <br /> <br /> Nous avons également mis en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' <br /> Après un changement d’Arduino et de support, nous avons finalement réussi à tester notre programme Arduino. Nous avons donc pu commencer à étudier le code de la liaison série, déjà réalisé par les membres de l’équipe Defrost, mais qui n’était adapté qu’aux 4 servos moteurs du robot déformable. Ce code C++ était conçu uniquement pour envoyer les données provenant de SOFA vers l’arduino. Nous avons donc cherché une fonction dans la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] nous permettant de lire des données. Bien qu’il n’y ait que peu d’information sur cette bibliothèque sur internet, nous avons tout de même réussi à trouver la fonction ''« vrpn_read_available_characters() »''. <br /> <br /> <br /> * '''Mercredi 04/02 :''' <br /> Après avoir trouvé la fonction qui convenait pour notre projet, nous avons tenté de trouver la façon dont celle-ci pouvait fonctionner. Malheureusement, avant d’effectuer les premiers tests, nous nous sommes rendu compte qu’il était nécessaire d’extraire cette partie du code du projet SOFA, afin de ne pas devoir lancer le logiciel à chaque compilation. Après avoir remplacé les variables qui provenaient du logiciel et réinstallé la bibliothèque, nous avons pu tester notre fonction. Nous avons commencé par des envois simples, qui se limitaient à un chiffre ou une lettre. Malheureusement la fonction ne recevait pas la donnée envoyée. Il s’est avéré que nous ne lisions tout simplement pas au bon moment.Donc, grâce à une simple boucle while, nous avons pu régler ce problème.<br /> <br /> <br /> * '''Jeudi 05/02 :''' <br /> Durant cette séance, nous nous sommes rendues compte qu’une autre version de la fonction ''« vrpn_read_available_characters() »'' existait avec une option « timeout ». Cette option permet de lire le port série durant la durée souhaitée. Cela permettait donc de simplifier le code et de ne plus utiliser de boucle while. Malgré tout, nous avons eu des difficultés à trouver un exemple d’utilisation de cette fonction. Mais nous y sommes finalement parvenues :<br /> <br /> struct timeval timeout;<br /> timeout.tv_sec = 1.999;<br /> timeout.tv_usec = 0;<br /> vrpn_read_available_characters(portNumber,buffer,bytes,&amp;timeout);<br /> <br /> <br /> Nous avons choisi un temps de 1,999 secondes après avoir effectué différents tests. A la fin de la journée, nous sommes donc arrivées à envoyer une série d’informations de l’arduino vers l’ordinateur.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' <br /> Le but de cette séance était de différencier les informations relatives aux différents actionneurs lors de leur réception sur le port série. Pour cela, nous avons choisi un moyen simple : mettre en place des délimiteurs dans le code Arduino. Afin de correctement classer les différentes informations dans ce code, nous avons d’abord pensé à élaborer des structures pour chaque actionneur. Malheureusement, cela s’est avéré difficile notamment à cause d’un problème de librairie au niveau de l’Arduino. Nous avons donc préféré l’utilisation de simples variables.<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> * '''Mercredi 11/02 : <br /> Les informations transmises par l’Arduino pouvaient très bien être des entiers, des float, ou des char. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyions des float et des int, alors la partie décimale du float était ajoutée à l’int (surement dû au fait que le buffer n’était pas reinitialisé). Nous avons donc décidé de n’envoyer que des float, ce qui ne changeait pas notre programme dans le fond. Une fois la transmission réussie, nous avons ajouté les délimiteurs : un pour chaque fin de type, et un pour la fin de la transmission. <br /> <br /> * '''Jeudi 12/02 :''' <br /> Maintenant que nous arrivions à recevoir les informations classées en provenance de l’Arduino, nous avons réalisé le code permettant de les récupérer au niveau de la liaison série.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' <br /> La première partie du code de la liaison série étant terminée, nous nous sommes ensuite concentrées sur la retransmission vers l’Arduino après récupération des données de SOFA et traitement par méthodes mathématiques. Comme le programme devait traiter 4 types d’actionneurs différents, nous avons étudié le code actuel (réalisé pour les servos moteurs) mais aussi le code d’un robot d’un [http://projets-imasc.plil.net/mediawiki/index.php?title=P28_Mod%C3%A9lisation_d%27un_robot_chirurgical_d%C3%A9formable_pour_la_simulation_et_le_contr%C3%B4le projet IMA5], qui utilisait cette fois-ci des actionneurs pneumatiques.<br /> <br /> * '''Mercredi 18/02 :''' <br /> A cause d’un problème d’incompréhension avec notre tuteur, nous avons dû réadapter une partie de notre code déjà existant. En effet, nous pensions que pour chaque type d’actionneur, les données envoyées étaient les mêmes. Or il s’est avéré que cela n’était pas le cas, et que chaque donnée envoyée pouvait varier d’un actionneur à un autre, même si ces derniers étaient du même type. Ainsi, nous avons modifié le code de l’Arduino et utilisé des tableaux pour chaque paramètre lié à un type, avec un maximum de 50 valeurs différentes pour chacun d’entre eux. Des délimiteurs de fin de tableaux ont également été ajoutés. Nous avons également complété le code de la liaison série, en reclassant les tableaux des différents types en sous tableaux de différents paramètres.<br /> Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' <br /> Un problème lié à des conflits entre le port série de l’Arduino et celui de l’ordinateur nous empêchait de tester les modifications apportées à notre programme.<br /> <br /> ===Semaine 5===<br /> <br /> * '''Lundi 23/02 :'''<br /> Nous étions toujours dans la même situation que Jeudi 19/02, mais nous avons essayé activement de résoudre le problème. Pendant cette séance, nous avons tout de même amélioré le code Arduino réalisé lors de la toute première séance, afin qu’il puisse traiter tout type d’actionneur.<br /> <br /> * '''Mercredi 25/02 :'''<br /> Après un changement d’unité centrale, nous avons réussi à tester notre programme. Malheureusement, le code qui fonctionnait lors des séances précédentes (à savoir la récupération des données et leur classement), ne fonctionne plus et nous avons cherché à résoudre le problème. <br /> <br /> * '''Jeudi 26/02: '''<br /> Nous avons réussi à debugger la première partie du code, en ajoutant des Serial.flush() à notre code Arduino. Malheureusement, même si en général le code fonctionne parfaitement, il reste parfois des bugs, des erreurs de lecture, qui le perturbe. Nous cherchons donc un moyen de résoudre le problème.<br /> <br /> <br /> <br /> '''Objectifs pour les séances prochaines :''' <br /> * Tests des différents programmes<br /> * Réimplantation du code avec le logiciel SOFA<br /> <br /> <br /> ===Semaine 6===<br /> <br /> * '''Lundi 11/03 :'''<br /> Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est 115200 baud mais nous avons pensé à changer cette vitesse et en faisant quelques tests avec d'autres valeurs nous sommes rendues compte que notre marchait bien avec une vitesse de 9600 baud. Et comme sur le logiciel SOFA nous pouvons réglé la vitesse de transmission, nous avons décidé de garder celle-ci même si pour le moment nous ne savons pas exactement pourquoi l'arduino n'envoie pas des données à certaines vitesses.<br /> <br /> * '''Mercredi 13/03 :'''<br /> Nous avons commencé par installer le logiciel SOFA via ce lien [http://http://www.sofa-framework.org/wordpress/?page_id=166 logiciel SOFA]<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17229 2015-02-19T14:22:44Z

<p>Gelbez : /* Semaine 4 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> <br /> <br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' Nous avons commencé par regarder le programme qui permet la commande du robot pneumatique afin de vérifier que notre code est assez généralisé pour qu'on puisse commander ce genre de robot également. N'ayant pas de connaissances pré-acquises en c++, nous nous sommes rendues compte qu'il était plus pratique d'utiliser des vecteurs en C++ plutôt que des tableaux donc nous les avons changé.<br /> <br /> <br /> * '''Mercredi 18/02 :''' A cause d'un problème d'incompréhension, nous sommes rendues compte que toutes les caractéristiques des actionneurs peuvent changer et donc même si nous n'avons que 4 types d'actionneurs il fallait prévoir de la place mémoire pour stocker les différentes caractéristiques relative à un même types d'actionneur. Par exemple pour les servomoteurs, suivant les applications, nous ne pouvant pas sauvegarder sur l'arduino l'angle max comme étant un réel mais plutôt comme un tableau avec différentes valeurs potentielles des angles max. Nous allons donc changer notre code en fonction de ces nouvelles spécifications du cahier des charges. Et donc là nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' Nous avons eu de gros problèmes liés au matériel puisqu'on n'arrivait même plus à recevoir correctement les données de l'arduino via la liaison série.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17228 2015-02-19T14:14:57Z

<p>Gelbez : /* Semaine 4 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> <br /> <br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 165 ; // en deg<br /> <br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' Nous avons commencé par regarder le programme qui permet la commande du robot pneumatique afin de vérifier que notre code est assez généralisé pour qu'on puisse commander ce genre de robot également. N'ayant pas de connaissances pré-acquises en c++, nous nous sommes rendues compte qu'il était plus pratique d'utiliser des vecteurs en C++ plutôt que des tableaux donc nous les avons changé.<br /> <br /> <br /> * '''Mercredi 18/02 :''' A cause d'un problème d'incompréhension, nous sommes rendues compte que toutes les caractéristiques des actionneurs peuvent changer et donc même si nous n'avons que 4 types d'actionneurs il fallait prévoir de la place mémoire pour stocker les différentes caractéristiques relative à un même types d'actionneur. Par exemple pour les servomoteurs, suivant les applications, nous ne pouvant pas sauvegarder sur l'arduino l'angle max comme étant un réel mais plutôt comme un tableau avec différentes valeurs potentielles des angles max. Nous allons donc changer notre code en fonction de ces nouvelles spécifications du cahier des charges. Et donc là nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> <br /> * '''Jeudi 19/02 :''' Nous avons eu de gros problèmes par rapport au matériel puisqu'on n'arrivait même plus à recevoir correctement les données de l'arduino via la liaison série.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17166 2015-02-18T15:30:01Z

<p>Gelbez : /* Semaine 4 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> <br /> <br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' Nous avons commencé par regarder le programme qui permet la commande du robot pneumatique afin de vérifier que notre code est assez généralisé pour qu'on puisse commander ce genre de robot également. N'ayant pas de connaissances pré-acquises en c++, nous nous sommes rendues compte qu'il était plus pratique d'utiliser des vecteurs en C++ plutôt que des tableaux donc nous les avons changé.<br /> <br /> <br /> * '''Mercredi 18/02 :''' A cause d'un problème d'incompréhension, nous sommes rendues compte que toutes les caractéristiques des actionneurs peuvent changer et donc même si nous n'avons que 4 types d'actionneurs il fallait prévoir de la place mémoire pour stocker les différentes caractéristiques relative à un même types d'actionneur. Par exemple pour les servomoteurs, suivant les applications, nous ne pouvant pas sauvegarder sur l'arduino l'angle max comme étant un réel mais plutôt comme un tableau avec différentes valeurs potentielles des angles max. Nous allons donc changer notre code en fonction de ces nouvelles spécifications du cahier des charges. Et donc là nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg|center]]<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Fichier:Photov.jpg&diff=17164 2015-02-18T15:28:57Z

<p>Gelbez : </p> <hr /> <div></div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17163 2015-02-18T15:28:25Z

<p>Gelbez : /* Semaine 4 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> <br /> <br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' Nous avons commencé par regarder le programme qui permet la commande du robot pneumatique afin de vérifier que notre code est assez généralisé pour qu'on puisse commander ce genre de robot également. N'ayant pas de connaissances pré-acquises en c++, nous nous sommes rendues compte qu'il était plus pratique d'utiliser des vecteurs en C++ plutôt que des tableaux donc nous les avons changé.<br /> <br /> <br /> * '''Mercredi 18/02 :''' A cause d'un problème d'incompréhension, nous sommes rendues compte que toutes les caractéristiques des actionneurs peuvent changer et donc même si nous n'avons que 4 types d'actionneurs il fallait prévoir de la place mémoire pour stocker les différentes caractéristiques relative à un même types d'actionneur. Par exemple pour les servomoteurs, suivant les applications, nous ne pouvant pas sauvegarder sur l'arduino l'angle max comme étant un réel mais plutôt comme un tableau avec différentes valeurs potentielles des angles max. Nous allons donc changer notre code en fonction de ces nouvelles spécifications du cahier des charges. Et donc là nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : <br /> <br /> [[Fichier:photov.jpg]]<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17162 2015-02-18T15:27:07Z

<p>Gelbez : /* Semaine 4 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> <br /> <br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' Nous avons commencé par regarder le programme qui permet la commande du robot pneumatique afin de vérifier que notre code est assez généralisé pour qu'on puisse commander ce genre de robot également. N'ayant pas de connaissances pré-acquises en c++, nous nous sommes rendues compte qu'il était plus pratique d'utiliser des vecteurs en C++ plutôt que des tableaux donc nous les avons changé.<br /> <br /> <br /> * '''Mercredi 18/02 :''' A cause d'un problème d'incompréhension, nous sommes rendues compte que toutes les caractéristiques des actionneurs peuvent changer et donc même si nous n'avons que 4 types d'actionneurs il fallait prévoir de la place mémoire pour stocker les différentes caractéristiques relative à un même types d'actionneur. Par exemple pour les servomoteurs, suivant les applications, nous ne pouvant pas sauvegarder sur l'arduino l'angle max comme étant un réel mais plutôt comme un tableau avec différentes valeurs potentielles des angles max. Nous allons donc changer notre code en fonction de ces nouvelles spécifications du cahier des charges. Et donc là nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : [[Fichier:[[photo_v.jpg]]]]<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Fichier:Photo_v.jpg&diff=17161 2015-02-18T15:26:17Z

<p>Gelbez : </p> <hr /> <div></div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17160 2015-02-18T15:24:23Z

<p>Gelbez : /* Semaine 4 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> <br /> <br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' Nous avons commencé par regarder le programme qui permet la commande du robot pneumatique afin de vérifier que notre code est assez généralisé pour qu'on puisse commander ce genre de robot également. N'ayant pas de connaissances pré-acquises en c++, nous nous sommes rendues compte qu'il était plus pratique d'utiliser des vecteurs en C++ plutôt que des tableaux donc nous les avons changé.<br /> <br /> <br /> * '''Mercredi 18/02 :''' A cause d'un problème d'incompréhension, nous sommes rendues compte que toutes les caractéristiques des actionneurs peuvent changer et donc même si nous n'avons que 4 types d'actionneurs il fallait prévoir de la place mémoire pour stocker les différentes caractéristiques relative à un même types d'actionneur. Par exemple pour les servomoteurs, suivant les applications, nous ne pouvant pas sauvegarder sur l'arduino l'angle max comme étant un réel mais plutôt comme un tableau avec différentes valeurs potentielles des angles max. Nous allons donc changer notre code en fonction de ces nouvelles spécifications du cahier des charges. Et donc là nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : [[Fichier:[[diagramme.jpg]]]]<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17159 2015-02-18T15:23:57Z

<p>Gelbez : /* Semaine 4 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> <br /> <br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' Nous avons commencé par regarder le programme qui permet la commande du robot pneumatique afin de vérifier que notre code est assez généralisé pour qu'on puisse commander ce genre de robot également. N'ayant pas de connaissances pré-acquises en c++, nous nous sommes rendues compte qu'il était plus pratique d'utiliser des vecteurs en C++ plutôt que des tableaux donc nous les avons changé.<br /> <br /> <br /> * '''Mercredi 18/02 :''' A cause d'un problème d'incompréhension, nous sommes rendues compte que toutes les caractéristiques des actionneurs peuvent changer et donc même si nous n'avons que 4 types d'actionneurs il fallait prévoir de la place mémoire pour stocker les différentes caractéristiques relative à un même types d'actionneur. Par exemple pour les servomoteurs, suivant les applications, nous ne pouvant pas sauvegarder sur l'arduino l'angle max comme étant un réel mais plutôt comme un tableau avec différentes valeurs potentielles des angles max. Nous allons donc changer notre code en fonction de ces nouvelles spécifications du cahier des charges. Et donc là nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : [[Fichier:[[diagramme_V.jpg]]]]<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17158 2015-02-18T15:23:29Z

<p>Gelbez : /* Semaine 4 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> <br /> <br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' Nous avons commencé par regarder le programme qui permet la commande du robot pneumatique afin de vérifier que notre code est assez généralisé pour qu'on puisse commander ce genre de robot également. N'ayant pas de connaissances pré-acquises en c++, nous nous sommes rendues compte qu'il était plus pratique d'utiliser des vecteurs en C++ plutôt que des tableaux donc nous les avons changé.<br /> <br /> <br /> * '''Mercredi 18/02 :''' A cause d'un problème d'incompréhension, nous sommes rendues compte que toutes les caractéristiques des actionneurs peuvent changer et donc même si nous n'avons que 4 types d'actionneurs il fallait prévoir de la place mémoire pour stocker les différentes caractéristiques relative à un même types d'actionneur. Par exemple pour les servomoteurs, suivant les applications, nous ne pouvant pas sauvegarder sur l'arduino l'angle max comme étant un réel mais plutôt comme un tableau avec différentes valeurs potentielles des angles max. Nous allons donc changer notre code en fonction de ces nouvelles spécifications du cahier des charges. Et donc là nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : [[Fichier:[[diagramme_v.jpg]]]]<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17157 2015-02-18T15:21:06Z

<p>Gelbez : /* Semaine 3 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> <br /> <br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> <br /> ===Semaine 4===<br /> <br /> <br /> * '''Lundi 16/02 :''' Nous avons commencé par regarder le programme qui permet la commande du robot pneumatique afin de vérifier que notre code est assez généralisé pour qu'on puisse commander ce genre de robot également. N'ayant pas de connaissances pré-acquises en c++, nous nous sommes rendues compte qu'il était plus pratique d'utiliser des vecteurs en C++ plutôt que des tableaux donc nous les avons changé.<br /> <br /> <br /> * '''Mercredi 18/02 :''' A cause d'un problème d'incompréhension, nous sommes rendues compte que toutes les caractéristiques des actionneurs peuvent changer et donc même si nous n'avons que 4 types d'actionneurs il fallait prévoir de la place mémoire pour stocker les différentes caractéristiques relative à un même types d'actionneur. Par exemple pour les servomoteurs, suivant les applications, nous ne pouvant pas sauvegarder sur l'arduino l'angle max comme étant un réel mais plutôt comme un tableau avec différentes valeurs potentielles des angles max. Nous allons donc changer notre code en fonction de ces nouvelles spécifications du cahier des charges. Et donc là nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous : [[Fichier:[[interventions_ice_tech.jpg]]]]<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Fichier:Diagramme.jpeg&diff=17156 2015-02-18T15:19:08Z

<p>Gelbez : </p> <hr /> <div></div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17147 2015-02-18T14:28:01Z

<p>Gelbez : /* Semaine 3 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> <br /> <br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17146 2015-02-18T14:26:30Z

<p>Gelbez : /* Semaine 3 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> '''<br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01 ; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17145 2015-02-18T14:26:01Z

<p>Gelbez : /* Semaine 3 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> '''<br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> * '''Jeudi 12/02 :''' Nous avons réussi à faire la transmission et nous avons fini la première partie qui consiste à stocker les caractéristiques sur l’arduino et récupérer les différentes informations via la liaison série pour générer les commandes du robot.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17142 2015-02-18T14:18:39Z

<p>Gelbez : /* Semaine 3 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> '''<br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> // Actionneurs type servos moteurs<br /> float diametre_SM = 35.01; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=17141 2015-02-18T14:18:17Z

<p>Gelbez : /* Semaine 3 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> '''<br /> * '''Mercredi 11/02 : '''Ayant récupéré les différentes caractéristiques de chaque actionneur, nous avons pensé dans un premier temps à utiliser une structure par actionneur afin de sauvegarder ces caractéristiques sur l’arduino. Mais nous avons constaté par la suite que c’était inutile d'utiliser des librairies supplémentaires et que le programme restait assez clair et lisible même en utilisant de simples variables et donc nous avons adopté cette solution . Et voici un exemple illustrant les servo-moteurs:<br /> <br /> -// Actionneurs type servos moteurs<br /> float diametre_SM = 35.01; // en mm<br /> float angle_min_SM = 15 ; // en deg<br /> float angle_max_SM = 987 ; // en deg<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16900 2015-02-14T11:17:49Z

<p>Gelbez : /* Semaine 2 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> '''<br /> * '''Mercredi 11/02 : '''<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16812 2015-02-11T21:54:20Z

<p>Gelbez : /* Semaine 3 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> ===Semaine 3===<br /> <br /> * '''Lundi 09/02 :''' Après un bref meeting sur les différentes caractéristiques des actionneurs que nous devons prendre en compte, nous avons essayé de récupérer les données reçues par l'arduino et les stocker afin de pouvoir faire les différentes opérations dessus avant de les retransmettre.<br /> <br /> '''<br /> * '''Mercredi 11/02 : '''<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16582 2015-02-07T11:55:37Z

<p>Gelbez : /* Semaine 2 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16581 2015-02-07T11:55:10Z

<p>Gelbez : /* Semaine 1 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16580 2015-02-07T11:54:46Z

<p>Gelbez : /* Semaine 1 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet.<br /> <br /> ===Semaine 2===<br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16579 2015-02-07T11:54:02Z

<p>Gelbez : /* Semaine 2 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet<br /> <br /> ===Semaine 2===<br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> * '''Mercredi 04/02 :''' Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN] mais en omettant que les données que les données que nous devons envoyer sont récupérer via la simulation SOFA et en les remplaçant par des données codées en dur dans le programme. <br /> <br /> * '''Jeudi 05/02 :''' Déboggage du programme en C++ suite à des problèmes liés aux modules devant être installés pour l'utilisation des fonctions de la bibliothèque [http://www.cs.unc.edu/Research/vrpn/vrpn_standard_stuff.html VRPN]. Nous avons donc réussi à la fin de la journée à envoyer et recevoir des données de l'arduino au pc via la liaison série.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16372 2015-02-03T15:50:53Z

<p>Gelbez : /* Semaine 1 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet<br /> <br /> ===Semaine 2===<br /> <br /> * '''Lundi 02/02 :''' Nous avons récupéré le code de la liaison série déjà utilisé et nous avons commencé à réfléchir à un code nous permettant de lire sur la liaison série.<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16282 2015-01-30T20:21:15Z

<p>Gelbez : /* Semaine 1 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Projet de l'inria sur les robots déformables]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16281 2015-01-30T20:19:42Z

<p>Gelbez : /* Semaine 1 */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> [https://team.inria.fr/shacra/christian-duriez-research/ Contrôle des robots déformable par la méthode FEM]<br /> <br /> [https://hal.inria.fr/hal-00823766/document Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez]<br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16280 2015-01-30T20:01:47Z

<p>Gelbez : /* Description du projet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération des données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations ,concernant les différentes forces et pressions appliquées, du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivants : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnage)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - Actionneurs pneumatiques<br /> - Actionneurs hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16279 2015-01-30T19:58:23Z

<p>Gelbez : /* Contexte */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille [http://http://www.inria.fr/equipes/defrost équipe Defrost] sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique de notre projet serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs seraient variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération de données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations de forces mais aussi de pressions du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivant : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnages)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - De type pneumatiques<br /> - De type hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16278 2015-01-30T19:53:31Z

<p>Gelbez : /* Etapes du projet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe Defrost basée à l'INRIA sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs sont variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération de données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations de forces mais aussi de pressions du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivant : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnages)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - De type pneumatiques<br /> - De type hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt : <br /> [[Fichier:gantt.png]]<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Fichier:Gantt.png&diff=16277 2015-01-30T19:49:21Z

<p>Gelbez : a téléversé une nouvelle version de « Fichier:Gantt.png »</p> <hr /> <div></div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=16276 2015-01-30T19:34:07Z

<p>Gelbez : /* Objectif du projet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> <br /> ====Contexte====<br /> [[Fichier:logoinria.jpg|center]]<br /> Dans le cadre des recherches de l'équipe Defrost basée à l'INRIA sur les robots déformables, il nous a été demandé de réaliser l'interface entre le robot siliconé contrôlé par un Arduino et un logiciel de simulation. L'équipe de recherche a réalisé une interface qui ne s'applique qu'à ce robot en particulier, celui-ci possédant pour le moment un nombre précis d'actionneurs dont les caractéristiques sont connues. Mais est-il possible d’augmenter ce nombre et de diversifier les actionneurs en conservant un code simple et clair?<br /> <br /> <br /> Ainsi, la problématique serait la suivante : comment transmettre les données de la simulation à un robot dont le nombre et le type d'actionneurs sont variables?<br /> <br /> ====Objectif du projet====<br /> <br /> L'objectif est donc de créer une console de configuration / contrôle entre une plate-forme de simulation interactive et un robot en silicone piloté par un Arduino. La difficulté est d'adapter ces informations au type et au nombre d'actionneurs dont peut être composé le robot. Le but est également de produire des codes polyvalents, adaptables à toute configuration. Enfin, il est important de pouvoir avoir accès aux différentes valeurs des actionneurs.<br /> <br /> ====Description du projet====<br /> Au cours du projet, nous traiterons 3 différentes parties : <br /> <br /> [[Fichier:robot.png|thumb|right|Le robot déformable]]<br /> <br /> * La partie simulation, récupération de données du logiciel<br /> <br /> * La partie gestion du port série<br /> <br /> * La partie gestion de l'Arduino<br /> <br /> Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties : <br /> <br /> '''Partie simulation'''<br /> <br /> Le but est de récupérer les informations de forces mais aussi de pressions du logiciel de simulation, afin de pouvoir les transmettre par la suite. <br /> <br /> '''Partie interface port série''' <br /> <br /> Dans cette partie les objectifs à atteindre seront les suivant : <br /> <br /> * Gérer les vitesses d'envoi des différentes informations<br /> <br /> * Adapter les types de données en faisant les calculs de conversion si nécessaire<br /> <br /> * Gérer la communication (les périodes d’échantillonnages)<br /> <br /> * Permettre l'échange de données dans les deux sens<br /> <br /> '''Partie Arduino''' <br /> <br /> La partie Arduino devra permettre d'obtenir : <br /> <br /> * Des informations sur le nombre d'actionneurs<br /> <br /> * Des informations sur le type de ces actionneurs : <br /> - Servos moteurs<br /> - De type pneumatiques<br /> - De type hydrauliques<br /> - SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)<br /> <br /> * Des informations sur le type de données envisagées<br /> <br /> * Des FeedBacks des différents actionneurs, et de capteurs potentiels<br /> <br /> <br /> Ainsi ce projet consiste à : <br /> <br /> * Comprendre l’actuelle configuration du robot<br /> <br /> * Créer une interface de contrôle en C pour<br /> ** Calibrer les actionneurs<br /> **Transmettre les informations de forces/positions<br /> <br /> But : Faciliter son utilisation<br /> <br /> ====Choix techniques : matériel et logiciel====<br /> <br /> '''Logiciel :''' <br /> * Logiciel open source SOFA [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> <br /> '''Matériel :''' <br /> * Robot déformable en silicone [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Un Arduino [&lt;span style=&quot;color: green;&quot;&gt;fourni au 28/1/2015 par l'INRIA&lt;/span&gt;]<br /> * Informations sur les différents actionneurs<br /> <br /> ===Etapes du projet===<br /> <br /> Voici le planning prévisionnel concernant notre projet : <br /> <br /> * '''Semaines 1-2 :''' Prise en main hardware (plaque et moteur)<br /> - Contrôle d'un Arduino standard et compréhension des codes du robot déformable<br /> -''' 9 février''' : réunion sur l'avancement du projet<br /> <br /> * '''Semaines 3-4 :''' Formalisation/standardisation du/des protocole(s)<br /> <br /> * '''Semaines 5-6-7 :''' Implémentation et interface port série<br /> <br /> * '''Semaines 8-9 :''' Interfaçage avec la simulation<br /> <br /> * '''Semaine 10 :''' Tests sur le vrai robot<br /> <br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> <br /> * '''Lundi 26/01 :''' Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.<br /> <br /> * '''Mercredi 28/01 :''' Nous avons pris rendez-vous avec notre tuteur, à l'INRIA, afin de voir le robot et de détailler le cahier des charges. Après la présentation et une réunion afin de définir concrètement le projet, nous avons pu commencer à travailler, en prenant d'abord en main l'Arduino. Ainsi, nous avons essayé de comprendre le code du robot actuel, et nous avons effectué des tests sur des moteurs (autres moteurs que ceux du robot).<br /> <br /> * '''Jeudi 29/01''' : Mise en place du cahier des charges de notre projet<br /> <br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=15234 2014-12-17T19:26:55Z

<p>Gelbez : </p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> ==Cahier des charges==<br /> ===Présentation générale du projet=== <br /> ====Contexte====<br /> ====Objectif du projet====<br /> ====Description du projet====<br /> ====Choix techniques : matériel et logiciel====<br /> ===Etapes du projet===<br /> ==Avancement du Projet==<br /> ===Semaine 1===<br /> ...<br /> == Fichiers Rendus ==</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Robot_d%C3%A9formable&diff=15232 2014-12-17T19:25:57Z

<p>Gelbez : Page créée avec « 1 Cahier des charges 1.1 Présentation générale du projet 1.1.1 Contexte 1.1.2 Objectif du projet 1.1.3 Description du projet 1.1.4 Choix techniques : matériel et logiciel... »</p> <hr /> <div>1 Cahier des charges<br /> 1.1 Présentation générale du projet<br /> 1.1.1 Contexte<br /> 1.1.2 Objectif du projet<br /> 1.1.3 Description du projet<br /> 1.1.4 Choix techniques : matériel et logiciel<br /> 1.2 Etapes du projet<br /> 2 Avancement du Projet<br /> 2.1 Semaine 1<br /> 3 Fichiers Rendus</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Communication_s%C3%A9rie,_2013/2014,_TD1&diff=13558 2014-06-12T18:26:37Z

<p>Gelbez : /* Transmission */</p> <hr /> <div>= Introduction =<br /> ----<br /> <br /> <br /> <br /> L'objectif de ce projet est de réaliser un circuit électronique qui avait pour mission de gérer le port série présent sur la carte FPGA de la NanoBoard (dans les deux sens c'est à dire émission et réception) ainsi que de réaliser une interface de gestion du port série présent sur la Foxboard.<br /> <br /> '''Gestion du port série de la Nanoboard'''<br /> <br /> Le module RS232 se décompose en deux sous-modules, à savoir une partie émission et une partie réception.<br /> * un bit start <br /> * 8 bits de données<br /> * un bit stop <br /> * Pas de bit de parité<br /> <br /> [[Fichier:Serial-trame.png‎|center]]<br /> <br /> <br /> Matériel utilisé :<br /> <br /> * le port série du PC <br /> <br /> * le logiciel hyperterminal de windows pour transmettre et recevoir les données<br /> <br /> <br /> '''Gestion de la Foxboard'''<br /> <br /> Il s'agit de réaliser une interface Web qui va permettre :<br /> <br /> 1- d'envoyer une chaine de caractères au port série de la FoxBoard <br /> <br /> 2- d'afficher les caractères reçus sur ce même port série.<br /> <br /> = Organisation du projet =<br /> <br /> ----<br /> <br /> <br /> <br /> == Répartition des taches ==<br /> <br /> Nous nous sommes partagés le travail en 2 parties :<br /> <br /> 1- Partie informatique réalisée par Sandra Hage Chehade et Ghada El Bez<br /> <br /> 2- Partie électronique réalisée par Romain Imbert et Louis Chauchard<br /> <br /> == Progression projet ==<br /> <br /> Nous avons consacré la première séance à la compréhension du sujet et à la prise en main des différents outils de travail(La librairie Jquery permettant les requettes Ajax, le logiciel Altium …).<br /> <br /> Ensuite, nous avons essayé de chercher des solutions adéquates pour la transmission et pour la réception que ce soit pour la partie informatique mais également pour la partie électronique.<br /> <br /> Enfin, nous avons pu effectuer différents tests afin de vérifier le bon fonctionnement de notre liaison série.<br /> <br /> = Partie Informatique =<br /> <br /> ----<br /> <br /> == Mise en situation ==<br /> <br /> La partie informatique consiste à réaliser une interface Web qui permet de communiquer avec le port série du serveur. <br /> Notre site doit être composé d'une seule page HTML qui contient :<br /> * Une zone de texte pour l'émission.<br /> * Une zone de texte pour la réception.<br /> * Un bouton qui permet de commencer.<br /> Les langages utilisés pour notre interface sont : HTML, JavaScript, PHP. Nous avons aussi utiliser des requêtes Ajax pour combiner tous ces langages. Pour cela, nous avons installé la librairie jQuery.<br /> Nous avons réalisé d'abord nos test en utilisant un serveur local. Nous avons ensuite copier nos fichiers sur la Foxboard, afin de rendre celle-ci comme un serveur.<br /> <br /> ''' Séance 1 (07/05/2014) '''<br /> <br /> Cette séance était consacrée à la compréhension du sujet et à la découverte des différents langages qu'on allait utiliser. Nous avons aussi commencé à faire la page HTML ainsi que quelques fonctions en javascript.<br /> <br /> ''' Séance 2 (14/05/2014) '''<br /> <br /> Pendant cette séance nous avons réalisé les deux fichiers PHP d'émission et de réception. Par contre, en testant en utilisant l'Arduino, on recevait bien des informations mais l'émission des données ne fonctionnait pas.<br /> <br /> ''' Séance 3 (21/05/2014) '''<br /> <br /> Nous avons corrigé nos erreurs qui se trouvaient dans notre code. Et nous avons configuré notre Foxboard avec le réseau polytech.<br /> <br /> ''' Séances supplémentaires '''<br /> <br /> Nous avons copié nos fichiers sur la Foxboard. Et nous avons rédigé le wiki.<br /> == Transmission ==<br /> Nous avons décidé de commencer par cette partie car elle était plus simple que la partie réception.<br /> En effet, il suffit d'ouvrir le port série et d'écrire la chaîne de caractères tapée par l'utilisateur dans le port série. Nos avons donc utilisé le language PHP pour réaliser cette mission. &lt;br/&gt;<br /> Voici notre code correspondant :<br /> <br /> <br /> &lt;font size='3' color='red'&gt;&lt;?php&lt;/font&gt; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Récupération des données de l'url*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; $entree=$_REQUEST['id']; &lt;/font&gt;&lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Ouverture du port série*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; define('SERIAL_DEVICE','/dev/ttyACM0');<br /> $f=fopen(SERIAL_DEVICE,'w'); &lt;br/&gt;&lt;/font&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Ecrire la chaine 'entree' dans le port série */ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; if($f==FALSE) die('fopen\n');<br /> if(fwrite($f,&quot;$entree\n&quot;)&lt;=0) die(&quot;fwrite \n&quot;);&lt;br/&gt;<br /> fclose($f);<br /> &lt;/font&gt;<br /> &lt;font size='3' color='red'&gt;?&gt;&lt;/font&gt;<br /> <br /> <br /> Cette fonction sera appelée quand l'utilisateur clique sur le bouton 'valider'. En effet, l'appui sur le bouton permet d'appeler une fonction javascript qui, grâce à des requêtes Ajax, va pouvoir enregistrer des données dans l'url. Ainsi, la fonction PHP pourra avoir les données nécessaires. &lt;br/&gt;<br /> Voici le code correspondant à la fonction javascript envoyer() :<br /> <br /> &lt;font size='3'&gt;function envoyer(){&lt;/font&gt; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Récupération de la chaîne de caractères entrée par l'utilisatuer*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; var chaine = $('#entree').val(); <br /> var parameters={id: chaine}; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt;/*Requête Ajax*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt;$.ajax({url: 'envoyer.php', type: 'post', data: parameters});&lt;br/&gt;<br /> }&lt;/font&gt; &lt;/font&gt;<br /> <br /> Nous avons pu tester en premier temps la transmission grâce à une carte Arduino qui allume une led pour dire que la carte a bien reçu une information.<br /> <br /> == Réception ==<br /> <br /> == Implémentation sur la Foxboard ==<br /> <br /> = Partie Électronique =<br /> ----<br /> Comme on a pu le voir précédemment,la valeur par défaut est à l'état haut. L'envoi du bit de start est représenté par le passage de l'état haut à l'état bas. Ensuite les 8 bits de données sont envoyés à chaque front d'horloge et le dernier (10ème bit) correspond au bit de stop qui permet la remise à la valeur par défaut.<br /> De plus, le bit de poids faible est transmis en tête.<br /> <br /> == Émission ==<br /> <br /> (Séance 1 et Séance 2)<br /> <br /> Pour la toute première séance, suite au choix définitif du sujet et de sa compréhension, nous avons effectué plusieurs recherches sur le fonctionnement de la liaison série. <br /> <br /> Avant de commencer directement sur le projet, nous avons réalisé le tutoriel d'Altium Designer proposé. Ce qui nous a permis de nous familiariser avec l'utilisation de ce logiciel. <br /> En effet, cela nous a permis de comprendre le fonctionnement de la Nanoboard avec les composants des différentes librairies &quot;FPGA&quot;.<br /> <br /> Ensuite, nous avons commencé réellement le projet, en nous intéressant dans un premier temps à la partie émission, qui nous semblait plus facile. <br /> Nous avons rapidement choisi d'utiliser un registre à décalage étant donné que l'on avait eu, au premier semestre, un TP de logique qui permettait de charger des données en parallèle et qui les transmettait ensuite en série.<br /> <br /> Nous avons donc débuté avec un montage simple qui comporte les éléments suivants:<br /> <br /> * Un registre à décalage SR16CLES pour convertir Parallèle/Série<br /> <br /> * Un Configurable Digital IO qui permet de générer les 8 bits de données, reliés au niveau des 8 premières broches du registre à décalage. Les autres sont reliées au VCC. Seule la broche D8 est reliée au GND (masse) pour représenter le bit de start qui est un passage de 1 à 0.<br /> <br /> * Des LEDs pour visualiser la bonne conversion parallèle/série <br /> <br /> <br /> Suite à ce test, on a pu constater que le registre à décalage fonctionne.<br /> <br /> Pour la seconde séance, nous avions prévu de continuer et de terminer la partie émission et si possible de commencer la partie réception.<br /> <br /> Nous avons gardé le schéma de la première séance, mais nous avons ajouté en plus la possibilité de sélectionner parmi deux vitesses différentes d'émission (sous conseil de nos professeurs). L'utilisation d'un multiplexeur nous a permis de faire cette sélection.<br /> <br /> Il suffit de relier deux générateurs de fréquence sur les deux entrées du multiplexeur. L'appui sur un bouton de type switch, qui doit être complémenté, sélectionne l'une des deux entrées à générer. <br /> <br /> On utilise une bascule D afin de mémoriser le premier appui puis lors du deuxième appui, la valeur mémorisée est complémentée. Ce qui permet d'alterner entre les deux vitesses de transmission possibles, à chaque appui du bouton.<br /> <br /> De plus,un second bouton switch est utilisé pour le chargement des données parallèles.<br /> <br /> [[Fichier:Emission_avec_test.png|thumb|800px|center|Émission]]<br /> <br /> <br /> <br /> Une fois le schéma réalisé, nous avons effectué des tests en envoyant des trames avec le DIO ainsi que les générateurs d'horloge.<br /> Un générateur d'horloge était configuré pour réaliser une vitesse de transmission de 9600 bauds et un autre générateur d'horloge était configuré pour réaliser une vitesse de 4800 bauds.<br /> <br /> Puis nous avons visualisé avec l'analyseur logique ce que nous obtenions sur une broche du port A de la nanoboard.<br /> On remarque bien le bit de start, représenté par le passage de l'état haut à l'état bas.<br /> ::::::::[[Fichier:Alternance01010.png|thumb|400px|left|Trame de 8 bits alternés 0101 0101]][[Fichier:Trame_0101_0101.png|thumb|350px|center|visualisation à l'analyseur logique]]<br /> On remarque que l'on reçoit bien les bits alternés à l'envers, ce qui s'explique par le fait que le bit de poids faible est en-tête. L'émission de bits de données fonctionne donc parfaitement.<br /> &lt;br /&gt;&lt;br /&gt;<br /> Nous avons de plus, visualisé les fréquences des trames reçues afin de vérifier si nous obtenions bien les deux vitesses de transmissions désirées.<br /> On constate que la structure fonctionne bien.<br /> En effet, dès l'appui du bouton, on passe d'une vitesse de transmission de 9600 bauds (9.6 KHz) à une vitesse de transmission de 4800 bauds (4.8 KHZ).<br /> <br /> <br /> ::::::::[[Fichier:Fréquence_9600Bds.png|thumb|400px|left|visualisation de la vitesse de transmission de 9600 bauds]][[Fichier:Fréquence_4800Bds.png|thumb|400px|center|visualisation de la vitesse de transmission de 4800 bauds]]<br /> <br /> == Réception ==<br /> (Séance 2 et Séance 3)<br /> <br /> La partie émission fonctionnant, nous nous sommes penchés sur la partie Réception du système qui est apparue bien plus complexe.<br /> <br /> Suite à l'explication de Monsieur Boé, nous avons compris que pour cette partie, il était nécessaire d'utiliser deux générateurs d'horloge de fréquence différente. En effet, si l'on souhaite détecter correctement un bit, il faut se positionner en plein milieu du bit et non pas au niveau d'un front (montant ou descendant) afin d'être sûr de détecter un bit et non une perturbation quelconque. Pour se faire, il faut utiliser une deuxième horloge de fréquence deux fois plus rapide pour pouvoir être au milieu du bit.<br /> <br /> On reçoit la trame de 10 bits en série à partir de la broche RS RX. Puis le premier front descendant (correspondant au bit de start) doit être détecté pour démarrer le compteur.<br /> <br /> La porte AND donnera un 1 logique lorsque ce front sera détecté et que la valeur du compteur sera inférieure ou égale à 1.<br /> Ceci va provoquer un front montant au niveau de l’horloge de la bascule D ce qui va permettre le chargement de la valeur de D en sortie (Q).<br /> <br /> Cette sortie va donc permettre la mise en route du compteur (broche CE). Ce compteur est donc comparé à la valeur 10 qui valide l’entrée CE du registre U10 pour permettre le décalage.<br /> <br /> Si le compteur est strictement supérieur à 10, l’entrée CE du registre U10 (série vers parallèle) devient donc bloquée et ceci va entraîner le blocage du décalage. <br /> Au même moment, on remet le compteur à 0 en envoyant un 1 sur son entrée CLR et la sortie Q de la bascule repasse donc à 0 ce qui bloque le compteur U12.<br /> Si le compteur est supérieur ou égal à 1, l’entrée de sélection du multiplexeur est égale à 1 ce qui va donc changer la fréquence du compteur.<br /> <br /> <br /> [[Fichier:Schéma final.png|thumb|600px|center|Schéma complet de la partie Émission et Réception]]<br /> <br /> Malheureusement, cette seconde partie n'a pas donné de résultats concluants, nous n'avons donc pas pu valider son bon fonctionnement.<br /> <br /> = Assemblage =<br /> <br /> = Conclusion =<br /> <br /> En conclusion, la partie informatique fonctionne et la partie électronique seule la partie émission fonctionne convenablement, la partie réception ne donne pas de résultats concluants. Ce qui malheureusement, bloque la possibilité de relier les deux parties du projet...</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Communication_s%C3%A9rie,_2013/2014,_TD1&diff=13557 2014-06-12T18:24:32Z

<p>Gelbez : /* Progression projet */</p> <hr /> <div>= Introduction =<br /> ----<br /> <br /> <br /> <br /> L'objectif de ce projet est de réaliser un circuit électronique qui avait pour mission de gérer le port série présent sur la carte FPGA de la NanoBoard (dans les deux sens c'est à dire émission et réception) ainsi que de réaliser une interface de gestion du port série présent sur la Foxboard.<br /> <br /> '''Gestion du port série de la Nanoboard'''<br /> <br /> Le module RS232 se décompose en deux sous-modules, à savoir une partie émission et une partie réception.<br /> * un bit start <br /> * 8 bits de données<br /> * un bit stop <br /> * Pas de bit de parité<br /> <br /> [[Fichier:Serial-trame.png‎|center]]<br /> <br /> <br /> Matériel utilisé :<br /> <br /> * le port série du PC <br /> <br /> * le logiciel hyperterminal de windows pour transmettre et recevoir les données<br /> <br /> <br /> '''Gestion de la Foxboard'''<br /> <br /> Il s'agit de réaliser une interface Web qui va permettre :<br /> <br /> 1- d'envoyer une chaine de caractères au port série de la FoxBoard <br /> <br /> 2- d'afficher les caractères reçus sur ce même port série.<br /> <br /> = Organisation du projet =<br /> <br /> ----<br /> <br /> <br /> <br /> == Répartition des taches ==<br /> <br /> Nous nous sommes partagés le travail en 2 parties :<br /> <br /> 1- Partie informatique réalisée par Sandra Hage Chehade et Ghada El Bez<br /> <br /> 2- Partie électronique réalisée par Romain Imbert et Louis Chauchard<br /> <br /> == Progression projet ==<br /> <br /> Nous avons consacré la première séance à la compréhension du sujet et à la prise en main des différents outils de travail(La librairie Jquery permettant les requettes Ajax, le logiciel Altium …).<br /> <br /> Ensuite, nous avons essayé de chercher des solutions adéquates pour la transmission et pour la réception que ce soit pour la partie informatique mais également pour la partie électronique.<br /> <br /> Enfin, nous avons pu effectuer différents tests afin de vérifier le bon fonctionnement de notre liaison série.<br /> <br /> = Partie Informatique =<br /> <br /> ----<br /> <br /> == Mise en situation ==<br /> <br /> La partie informatique consiste à réaliser une interface Web qui permet de communiquer avec le port série du serveur. <br /> Notre site doit être composé d'une seule page HTML qui contient :<br /> * Une zone de texte pour l'émission.<br /> * Une zone de texte pour la réception.<br /> * Un bouton qui permet de commencer.<br /> Les langages utilisés pour notre interface sont : HTML, JavaScript, PHP. Nous avons aussi utiliser des requêtes Ajax pour combiner tous ces langages. Pour cela, nous avons installé la librairie jQuery.<br /> Nous avons réalisé d'abord nos test en utilisant un serveur local. Nous avons ensuite copier nos fichiers sur la Foxboard, afin de rendre celle-ci comme un serveur.<br /> <br /> ''' Séance 1 (07/05/2014) '''<br /> <br /> Cette séance était consacrée à la compréhension du sujet et à la découverte des différents langages qu'on allait utiliser. Nous avons aussi commencé à faire la page HTML ainsi que quelques fonctions en javascript.<br /> <br /> ''' Séance 2 (14/05/2014) '''<br /> <br /> Pendant cette séance nous avons réalisé les deux fichiers PHP d'émission et de réception. Par contre, en testant en utilisant l'Arduino, on recevait bien des informations mais l'émission des données ne fonctionnait pas.<br /> <br /> ''' Séance 3 (21/05/2014) '''<br /> <br /> Nous avons corrigé nos erreurs qui se trouvaient dans notre code. Et nous avons configuré notre Foxboard avec le réseau polytech.<br /> <br /> ''' Séances supplémentaires '''<br /> <br /> Nous avons copié nos fichiers sur la Foxboard. Et nous avons rédigé le wiki.<br /> == Transmission ==<br /> Nous avons décidé de commencer par cette partie car elle était plus simple que la partie réception.<br /> En effet, il suffit d'ouvrir le port série et d'écrire la chaîne de caractères tapée par l'utilisateur dans le port série. Nos avons donc utilisé le language PHP pour réaliser cette mission. &lt;br/&gt;<br /> Voici notre code correspondant :<br /> <br /> <br /> &lt;font size='3' color='red'&gt;&lt;?php&lt;/font&gt; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Récupération des données de l'url*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; $entree=$_REQUEST['id']; &lt;/font&gt;&lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Ouverture du port série*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; define('SERIAL_DEVICE','/dev/ttyACM0');<br /> $f=fopen(SERIAL_DEVICE,'w'); &lt;br/&gt;&lt;/font&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Ecrire la chaine 'entree' dans le port série */ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; if($f==FALSE) die('fopen\n');<br /> if(fwrite($f,&quot;$entree\n&quot;)&lt;=0) die(&quot;fwrite \n&quot;);&lt;br/&gt;<br /> fclose($f);<br /> &lt;/font&gt;<br /> &lt;font size='3' color='red'&gt;?&gt;&lt;/font&gt;<br /> <br /> <br /> Cette fonction sera appelée quand l'utilisateur clique sur le bouton 'valider'. En effet, l'appuie sur le bouton permet d'appeler une fonction javascript qui, grâce à des requêtes Ajax, va pouvoir enregistrer des données dans l'url. Ainsi, la fonction PHP pourra avoir les données nécessaire. &lt;br/&gt;<br /> Voici le code correspondant à la fonction javascrip envoyer() :<br /> <br /> &lt;font size='3'&gt;function envoyer(){&lt;/font&gt; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Récupération de la chaîne de caractères entrée par l'utilisatuer*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; var chaine = $('#entree').val(); <br /> var parameters={id: chaine}; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt;/*Requête Ajax*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt;$.ajax({url: 'envoyer.php', type: 'post', data: parameters});&lt;br/&gt;<br /> }&lt;/font&gt; &lt;/font&gt;<br /> <br /> Nous avons pu tester en premier temps la transmission grâce à une carte Arduino qui allume une led pour dire que la carte a bien reçu une information.<br /> <br /> == Réception ==<br /> <br /> == Implémentation sur la Foxboard ==<br /> <br /> = Partie Électronique =<br /> ----<br /> Comme on a pu le voir précédemment,la valeur par défaut est à l'état haut. L'envoi du bit de start est représenté par le passage de l'état haut à l'état bas. Ensuite les 8 bits de données sont envoyés à chaque front d'horloge et le dernier (10ème bit) correspond au bit de stop qui permet la remise à la valeur par défaut.<br /> De plus, le bit de poids faible est transmis en tête.<br /> <br /> == Émission ==<br /> <br /> (Séance 1 et Séance 2)<br /> <br /> Pour la toute première séance, suite au choix définitif du sujet et de sa compréhension, nous avons effectué plusieurs recherches sur le fonctionnement de la liaison série. <br /> <br /> Avant de commencer directement sur le projet, nous avons réalisé le tutoriel d'Altium Designer proposé. Ce qui nous a permis de nous familiariser avec l'utilisation de ce logiciel. <br /> En effet, cela nous a permis de comprendre le fonctionnement de la Nanoboard avec les composants des différentes librairies &quot;FPGA&quot;.<br /> <br /> Ensuite, nous avons commencé réellement le projet, en nous intéressant dans un premier temps à la partie émission, qui nous semblait plus facile. <br /> Nous avons rapidement choisi d'utiliser un registre à décalage étant donné que l'on avait eu, au premier semestre, un TP de logique qui permettait de charger des données en parallèle et qui les transmettait ensuite en série.<br /> <br /> Nous avons donc débuté avec un montage simple qui comporte les éléments suivants:<br /> <br /> * Un registre à décalage SR16CLES pour convertir Parallèle/Série<br /> <br /> * Un Configurable Digital IO qui permet de générer les 8 bits de données, reliés au niveau des 8 premières broches du registre à décalage. Les autres sont reliées au VCC. Seule la broche D8 est reliée au GND (masse) pour représenter le bit de start qui est un passage de 1 à 0.<br /> <br /> * Des LEDs pour visualiser la bonne conversion parallèle/série <br /> <br /> <br /> Suite à ce test, on a pu constater que le registre à décalage fonctionne.<br /> <br /> Pour la seconde séance, nous avions prévu de continuer et de terminer la partie émission et si possible de commencer la partie réception.<br /> <br /> Nous avons gardé le schéma de la première séance, mais nous avons ajouté en plus la possibilité de sélectionner parmi deux vitesses différentes d'émission (sous conseil de nos professeurs). L'utilisation d'un multiplexeur nous a permis de faire cette sélection.<br /> <br /> Il suffit de relier deux générateurs de fréquence sur les deux entrées du multiplexeur. L'appui sur un bouton de type switch, qui doit être complémenté, sélectionne l'une des deux entrées à générer. <br /> <br /> On utilise une bascule D afin de mémoriser le premier appui puis lors du deuxième appui, la valeur mémorisée est complémentée. Ce qui permet d'alterner entre les deux vitesses de transmission possibles, à chaque appui du bouton.<br /> <br /> De plus,un second bouton switch est utilisé pour le chargement des données parallèles.<br /> <br /> [[Fichier:Emission_avec_test.png|thumb|800px|center|Émission]]<br /> <br /> <br /> <br /> Une fois le schéma réalisé, nous avons effectué des tests en envoyant des trames avec le DIO ainsi que les générateurs d'horloge.<br /> Un générateur d'horloge était configuré pour réaliser une vitesse de transmission de 9600 bauds et un autre générateur d'horloge était configuré pour réaliser une vitesse de 4800 bauds.<br /> <br /> Puis nous avons visualisé avec l'analyseur logique ce que nous obtenions sur une broche du port A de la nanoboard.<br /> On remarque bien le bit de start, représenté par le passage de l'état haut à l'état bas.<br /> ::::::::[[Fichier:Alternance01010.png|thumb|400px|left|Trame de 8 bits alternés 0101 0101]][[Fichier:Trame_0101_0101.png|thumb|350px|center|visualisation à l'analyseur logique]]<br /> On remarque que l'on reçoit bien les bits alternés à l'envers, ce qui s'explique par le fait que le bit de poids faible est en-tête. L'émission de bits de données fonctionne donc parfaitement.<br /> &lt;br /&gt;&lt;br /&gt;<br /> Nous avons de plus, visualisé les fréquences des trames reçues afin de vérifier si nous obtenions bien les deux vitesses de transmissions désirées.<br /> On constate que la structure fonctionne bien.<br /> En effet, dès l'appui du bouton, on passe d'une vitesse de transmission de 9600 bauds (9.6 KHz) à une vitesse de transmission de 4800 bauds (4.8 KHZ).<br /> <br /> <br /> ::::::::[[Fichier:Fréquence_9600Bds.png|thumb|400px|left|visualisation de la vitesse de transmission de 9600 bauds]][[Fichier:Fréquence_4800Bds.png|thumb|400px|center|visualisation de la vitesse de transmission de 4800 bauds]]<br /> <br /> == Réception ==<br /> (Séance 2 et Séance 3)<br /> <br /> La partie émission fonctionnant, nous nous sommes penchés sur la partie Réception du système qui est apparue bien plus complexe.<br /> <br /> Suite à l'explication de Monsieur Boé, nous avons compris que pour cette partie, il était nécessaire d'utiliser deux générateurs d'horloge de fréquence différente. En effet, si l'on souhaite détecter correctement un bit, il faut se positionner en plein milieu du bit et non pas au niveau d'un front (montant ou descendant) afin d'être sûr de détecter un bit et non une perturbation quelconque. Pour se faire, il faut utiliser une deuxième horloge de fréquence deux fois plus rapide pour pouvoir être au milieu du bit.<br /> <br /> On reçoit la trame de 10 bits en série à partir de la broche RS RX. Puis le premier front descendant (correspondant au bit de start) doit être détecté pour démarrer le compteur.<br /> <br /> La porte AND donnera un 1 logique lorsque ce front sera détecté et que la valeur du compteur sera inférieure ou égale à 1.<br /> Ceci va provoquer un front montant au niveau de l’horloge de la bascule D ce qui va permettre le chargement de la valeur de D en sortie (Q).<br /> <br /> Cette sortie va donc permettre la mise en route du compteur (broche CE). Ce compteur est donc comparé à la valeur 10 qui valide l’entrée CE du registre U10 pour permettre le décalage.<br /> <br /> Si le compteur est strictement supérieur à 10, l’entrée CE du registre U10 (série vers parallèle) devient donc bloquée et ceci va entraîner le blocage du décalage. <br /> Au même moment, on remet le compteur à 0 en envoyant un 1 sur son entrée CLR et la sortie Q de la bascule repasse donc à 0 ce qui bloque le compteur U12.<br /> Si le compteur est supérieur ou égal à 1, l’entrée de sélection du multiplexeur est égale à 1 ce qui va donc changer la fréquence du compteur.<br /> <br /> <br /> [[Fichier:Schéma final.png|thumb|600px|center|Schéma complet de la partie Émission et Réception]]<br /> <br /> Malheureusement, cette seconde partie n'a pas donné de résultats concluants, nous n'avons donc pas pu valider son bon fonctionnement.<br /> <br /> = Assemblage =<br /> <br /> = Conclusion =<br /> <br /> En conclusion, la partie informatique fonctionne et la partie électronique seule la partie émission fonctionne convenablement, la partie réception ne donne pas de résultats concluants. Ce qui malheureusement, bloque la possibilité de relier les deux parties du projet...</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Communication_s%C3%A9rie,_2013/2014,_TD1&diff=13556 2014-06-12T18:20:51Z

<p>Gelbez : /* Émission */</p> <hr /> <div>= Introduction =<br /> ----<br /> <br /> <br /> <br /> L'objectif de ce projet est de réaliser un circuit électronique qui avait pour mission de gérer le port série présent sur la carte FPGA de la NanoBoard (dans les deux sens c'est à dire émission et réception) ainsi que de réaliser une interface de gestion du port série présent sur la Foxboard.<br /> <br /> '''Gestion du port série de la Nanoboard'''<br /> <br /> Le module RS232 se décompose en deux sous-modules, à savoir une partie émission et une partie réception.<br /> * un bit start <br /> * 8 bits de données<br /> * un bit stop <br /> * Pas de bit de parité<br /> <br /> [[Fichier:Serial-trame.png‎|center]]<br /> <br /> <br /> Matériel utilisé :<br /> <br /> * le port série du PC <br /> <br /> * le logiciel hyperterminal de windows pour transmettre et recevoir les données<br /> <br /> <br /> '''Gestion de la Foxboard'''<br /> <br /> Il s'agit de réaliser une interface Web qui va permettre :<br /> <br /> 1- d'envoyer une chaine de caractères au port série de la FoxBoard <br /> <br /> 2- d'afficher les caractères reçus sur ce même port série.<br /> <br /> = Organisation du projet =<br /> <br /> ----<br /> <br /> <br /> <br /> == Répartition des taches ==<br /> <br /> Nous nous sommes partagés le travail en 2 parties :<br /> <br /> 1- Partie informatique réalisée par Sandra Hage Chehade et Ghada El Bez<br /> <br /> 2- Partie électronique réalisée par Romain Imbert et Louis Chauchard<br /> <br /> == Progression projet ==<br /> <br /> Nous avons consacré la première séance à la compréhension du sujet et à la prise en main des différents outils de travail(La librairie Jquery permettant les requettes Ajax, le logiciel Altium …).<br /> <br /> Ensuite, nous avons essayé de chercher des solutions adéquates pour la transmission et pour la réception que ce soit pour la partie informatique mais également pour la partie électronique.<br /> <br /> Enfin, nous avons pu effectuer différents tests afin de vérifier le bon fonctionnement d'une notre liaison série.<br /> <br /> = Partie Informatique =<br /> <br /> ----<br /> <br /> == Mise en situation ==<br /> <br /> La partie informatique consiste à réaliser une interface Web qui permet de communiquer avec le port série du serveur. <br /> Notre site doit être composé d'une seule page HTML qui contient :<br /> * Une zone de texte pour l'émission.<br /> * Une zone de texte pour la réception.<br /> * Un bouton qui permet de commencer.<br /> Les langages utilisés pour notre interface sont : HTML, JavaScript, PHP. Nous avons aussi utiliser des requêtes Ajax pour combiner tous ces langages. Pour cela, nous avons installé la librairie jQuery.<br /> Nous avons réalisé d'abord nos test en utilisant un serveur local. Nous avons ensuite copier nos fichiers sur la Foxboard, afin de rendre celle-ci comme un serveur.<br /> <br /> ''' Séance 1 (07/05/2014) '''<br /> <br /> Cette séance était consacrée à la compréhension du sujet et à la découverte des différents langages qu'on allait utiliser. Nous avons aussi commencé à faire la page HTML ainsi que quelques fonctions en javascript.<br /> <br /> ''' Séance 2 (14/05/2014) '''<br /> <br /> Pendant cette séance nous avons réalisé les deux fichiers PHP d'émission et de réception. Par contre, en testant en utilisant l'Arduino, on recevait bien des informations mais l'émission des données ne fonctionnait pas.<br /> <br /> ''' Séance 3 (21/05/2014) '''<br /> <br /> Nous avons corrigé nos erreurs qui se trouvaient dans notre code. Et nous avons configuré notre Foxboard avec le réseau polytech.<br /> <br /> ''' Séances supplémentaires '''<br /> <br /> Nous avons copié nos fichiers sur la Foxboard. Et nous avons rédigé le wiki.<br /> == Transmission ==<br /> Nous avons décidé de commencer par cette partie car elle était plus simple que la partie réception.<br /> En effet, il suffit d'ouvrir le port série et d'écrire la chaîne de caractères tapée par l'utilisateur dans le port série. Nos avons donc utilisé le language PHP pour réaliser cette mission. &lt;br/&gt;<br /> Voici notre code correspondant :<br /> <br /> <br /> &lt;font size='3' color='red'&gt;&lt;?php&lt;/font&gt; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Récupération des données de l'url*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; $entree=$_REQUEST['id']; &lt;/font&gt;&lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Ouverture du port série*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; define('SERIAL_DEVICE','/dev/ttyACM0');<br /> $f=fopen(SERIAL_DEVICE,'w'); &lt;br/&gt;&lt;/font&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Ecrire la chaine 'entree' dans le port série */ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; if($f==FALSE) die('fopen\n');<br /> if(fwrite($f,&quot;$entree\n&quot;)&lt;=0) die(&quot;fwrite \n&quot;);&lt;br/&gt;<br /> fclose($f);<br /> &lt;/font&gt;<br /> &lt;font size='3' color='red'&gt;?&gt;&lt;/font&gt;<br /> <br /> <br /> Cette fonction sera appelée quand l'utilisateur clique sur le bouton 'valider'. En effet, l'appuie sur le bouton permet d'appeler une fonction javascript qui, grâce à des requêtes Ajax, va pouvoir enregistrer des données dans l'url. Ainsi, la fonction PHP pourra avoir les données nécessaire. &lt;br/&gt;<br /> Voici le code correspondant à la fonction javascrip envoyer() :<br /> <br /> &lt;font size='3'&gt;function envoyer(){&lt;/font&gt; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Récupération de la chaîne de caractères entrée par l'utilisatuer*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; var chaine = $('#entree').val(); <br /> var parameters={id: chaine}; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt;/*Requête Ajax*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt;$.ajax({url: 'envoyer.php', type: 'post', data: parameters});&lt;br/&gt;<br /> }&lt;/font&gt; &lt;/font&gt;<br /> <br /> Nous avons pu tester en premier temps la transmission grâce à une carte Arduino qui allume une led pour dire que la carte a bien reçu une information.<br /> <br /> == Réception ==<br /> <br /> == Implémentation sur la Foxboard ==<br /> <br /> = Partie Électronique =<br /> ----<br /> Comme on a pu le voir précédemment,la valeur par défaut est à l'état haut. L'envoi du bit de start est représenté par le passage de l'état haut à l'état bas. Ensuite les 8 bits de données sont envoyés à chaque front d'horloge et le dernier (10ème bit) correspond au bit de stop qui permet la remise à la valeur par défaut.<br /> De plus, le bit de poids faible est transmis en tête.<br /> <br /> == Émission ==<br /> <br /> (Séance 1 et Séance 2)<br /> <br /> Pour la toute première séance, suite au choix définitif du sujet et de sa compréhension, nous avons effectué plusieurs recherches sur le fonctionnement de la liaison série. <br /> <br /> Avant de commencer directement sur le projet, nous avons réalisé le tutoriel d'Altium Designer proposé. Ce qui nous a permis de nous familiariser avec l'utilisation de ce logiciel. <br /> En effet, cela nous a permis de comprendre le fonctionnement de la Nanoboard avec les composants des différentes librairies &quot;FPGA&quot;.<br /> <br /> Ensuite, nous avons commencé réellement le projet, en nous intéressant dans un premier temps à la partie émission, qui nous semblait plus facile. <br /> Nous avons rapidement choisi d'utiliser un registre à décalage étant donné que l'on avait eu, au premier semestre, un TP de logique qui permettait de charger des données en parallèle et qui les transmettait ensuite en série.<br /> <br /> Nous avons donc débuté avec un montage simple qui comporte les éléments suivants:<br /> <br /> * Un registre à décalage SR16CLES pour convertir Parallèle/Série<br /> <br /> * Un Configurable Digital IO qui permet de générer les 8 bits de données, reliés au niveau des 8 premières broches du registre à décalage. Les autres sont reliées au VCC. Seule la broche D8 est reliée au GND (masse) pour représenter le bit de start qui est un passage de 1 à 0.<br /> <br /> * Des LEDs pour visualiser la bonne conversion parallèle/série <br /> <br /> <br /> Suite à ce test, on a pu constater que le registre à décalage fonctionne.<br /> <br /> Pour la seconde séance, nous avions prévu de continuer et de terminer la partie émission et si possible de commencer la partie réception.<br /> <br /> Nous avons gardé le schéma de la première séance, mais nous avons ajouté en plus la possibilité de sélectionner parmi deux vitesses différentes d'émission (sous conseil de nos professeurs). L'utilisation d'un multiplexeur nous a permis de faire cette sélection.<br /> <br /> Il suffit de relier deux générateurs de fréquence sur les deux entrées du multiplexeur. L'appui sur un bouton de type switch, qui doit être complémenté, sélectionne l'une des deux entrées à générer. <br /> <br /> On utilise une bascule D afin de mémoriser le premier appui puis lors du deuxième appui, la valeur mémorisée est complémentée. Ce qui permet d'alterner entre les deux vitesses de transmission possibles, à chaque appui du bouton.<br /> <br /> De plus,un second bouton switch est utilisé pour le chargement des données parallèles.<br /> <br /> [[Fichier:Emission_avec_test.png|thumb|800px|center|Émission]]<br /> <br /> <br /> <br /> Une fois le schéma réalisé, nous avons effectué des tests en envoyant des trames avec le DIO ainsi que les générateurs d'horloge.<br /> Un générateur d'horloge était configuré pour réaliser une vitesse de transmission de 9600 bauds et un autre générateur d'horloge était configuré pour réaliser une vitesse de 4800 bauds.<br /> <br /> Puis nous avons visualisé avec l'analyseur logique ce que nous obtenions sur une broche du port A de la nanoboard.<br /> On remarque bien le bit de start, représenté par le passage de l'état haut à l'état bas.<br /> ::::::::[[Fichier:Alternance01010.png|thumb|400px|left|Trame de 8 bits alternés 0101 0101]][[Fichier:Trame_0101_0101.png|thumb|350px|center|visualisation à l'analyseur logique]]<br /> On remarque que l'on reçoit bien les bits alternés à l'envers, ce qui s'explique par le fait que le bit de poids faible est en-tête. L'émission de bits de données fonctionne donc parfaitement.<br /> &lt;br /&gt;&lt;br /&gt;<br /> Nous avons de plus, visualisé les fréquences des trames reçues afin de vérifier si nous obtenions bien les deux vitesses de transmissions désirées.<br /> On constate que la structure fonctionne bien.<br /> En effet, dès l'appui du bouton, on passe d'une vitesse de transmission de 9600 bauds (9.6 KHz) à une vitesse de transmission de 4800 bauds (4.8 KHZ).<br /> <br /> <br /> ::::::::[[Fichier:Fréquence_9600Bds.png|thumb|400px|left|visualisation de la vitesse de transmission de 9600 bauds]][[Fichier:Fréquence_4800Bds.png|thumb|400px|center|visualisation de la vitesse de transmission de 4800 bauds]]<br /> <br /> == Réception ==<br /> (Séance 2 et Séance 3)<br /> <br /> La partie émission fonctionnant, nous nous sommes penchés sur la partie Réception du système qui est apparue bien plus complexe.<br /> <br /> Suite à l'explication de Monsieur Boé, nous avons compris que pour cette partie, il était nécessaire d'utiliser deux générateurs d'horloge de fréquence différente. En effet, si l'on souhaite détecter correctement un bit, il faut se positionner en plein milieu du bit et non pas au niveau d'un front (montant ou descendant) afin d'être sûr de détecter un bit et non une perturbation quelconque. Pour se faire, il faut utiliser une deuxième horloge de fréquence deux fois plus rapide pour pouvoir être au milieu du bit.<br /> <br /> On reçoit la trame de 10 bits en série à partir de la broche RS RX. Puis le premier front descendant (correspondant au bit de start) doit être détecté pour démarrer le compteur.<br /> <br /> La porte AND donnera un 1 logique lorsque ce front sera détecté et que la valeur du compteur sera inférieure ou égale à 1.<br /> Ceci va provoquer un front montant au niveau de l’horloge de la bascule D ce qui va permettre le chargement de la valeur de D en sortie (Q).<br /> <br /> Cette sortie va donc permettre la mise en route du compteur (broche CE). Ce compteur est donc comparé à la valeur 10 qui valide l’entrée CE du registre U10 pour permettre le décalage.<br /> <br /> Si le compteur est strictement supérieur à 10, l’entrée CE du registre U10 (série vers parallèle) devient donc bloquée et ceci va entraîner le blocage du décalage. <br /> Au même moment, on remet le compteur à 0 en envoyant un 1 sur son entrée CLR et la sortie Q de la bascule repasse donc à 0 ce qui bloque le compteur U12.<br /> Si le compteur est supérieur ou égal à 1, l’entrée de sélection du multiplexeur est égale à 1 ce qui va donc changer la fréquence du compteur.<br /> <br /> <br /> [[Fichier:Schéma final.png|thumb|600px|center|Schéma complet de la partie Émission et Réception]]<br /> <br /> Malheureusement, cette seconde partie n'a pas donné de résultats concluants, nous n'avons donc pas pu valider son bon fonctionnement.<br /> <br /> = Assemblage =<br /> <br /> = Conclusion =<br /> <br /> En conclusion, la partie informatique fonctionne et la partie électronique seule la partie émission fonctionne convenablement, la partie réception ne donne pas de résultats concluants. Ce qui malheureusement, bloque la possibilité de relier les deux parties du projet...</div>

Gelbez https://wiki-ima.plil.fr/mediawiki//index.php?title=Communication_s%C3%A9rie,_2013/2014,_TD1&diff=13555 2014-06-12T18:16:15Z

<p>Gelbez : /* Organisation du projet */</p> <hr /> <div>= Introduction =<br /> ----<br /> <br /> <br /> <br /> L'objectif de ce projet est de réaliser un circuit électronique qui avait pour mission de gérer le port série présent sur la carte FPGA de la NanoBoard (dans les deux sens c'est à dire émission et réception) ainsi que de réaliser une interface de gestion du port série présent sur la Foxboard.<br /> <br /> '''Gestion du port série de la Nanoboard'''<br /> <br /> Le module RS232 se décompose en deux sous-modules, à savoir une partie émission et une partie réception.<br /> * un bit start <br /> * 8 bits de données<br /> * un bit stop <br /> * Pas de bit de parité<br /> <br /> [[Fichier:Serial-trame.png‎|center]]<br /> <br /> <br /> Matériel utilisé :<br /> <br /> * le port série du PC <br /> <br /> * le logiciel hyperterminal de windows pour transmettre et recevoir les données<br /> <br /> <br /> '''Gestion de la Foxboard'''<br /> <br /> Il s'agit de réaliser une interface Web qui va permettre :<br /> <br /> 1- d'envoyer une chaine de caractères au port série de la FoxBoard <br /> <br /> 2- d'afficher les caractères reçus sur ce même port série.<br /> <br /> = Organisation du projet =<br /> <br /> ----<br /> <br /> <br /> <br /> == Répartition des taches ==<br /> <br /> Nous nous sommes partagés le travail en 2 parties :<br /> <br /> 1- Partie informatique réalisée par Sandra Hage Chehade et Ghada El Bez<br /> <br /> 2- Partie électronique réalisée par Romain Imbert et Louis Chauchard<br /> <br /> == Progression projet ==<br /> <br /> Nous avons consacré la première séance à la compréhension du sujet et à la prise en main des différents outils de travail(La librairie Jquery permettant les requettes Ajax, le logiciel Altium …).<br /> <br /> Ensuite, nous avons essayé de chercher des solutions adéquates pour la transmission et pour la réception que ce soit pour la partie informatique mais également pour la partie électronique.<br /> <br /> Enfin, nous avons pu effectuer différents tests afin de vérifier le bon fonctionnement d'une notre liaison série.<br /> <br /> = Partie Informatique =<br /> <br /> ----<br /> <br /> == Mise en situation ==<br /> <br /> La partie informatique consiste à réaliser une interface Web qui permet de communiquer avec le port série du serveur. <br /> Notre site doit être composé d'une seule page HTML qui contient :<br /> * Une zone de texte pour l'émission.<br /> * Une zone de texte pour la réception.<br /> * Un bouton qui permet de commencer.<br /> Les langages utilisés pour notre interface sont : HTML, JavaScript, PHP. Nous avons aussi utiliser des requêtes Ajax pour combiner tous ces langages. Pour cela, nous avons installé la librairie jQuery.<br /> Nous avons réalisé d'abord nos test en utilisant un serveur local. Nous avons ensuite copier nos fichiers sur la Foxboard, afin de rendre celle-ci comme un serveur.<br /> <br /> ''' Séance 1 (07/05/2014) '''<br /> <br /> Cette séance était consacrée à la compréhension du sujet et à la découverte des différents langages qu'on allait utiliser. Nous avons aussi commencé à faire la page HTML ainsi que quelques fonctions en javascript.<br /> <br /> ''' Séance 2 (14/05/2014) '''<br /> <br /> Pendant cette séance nous avons réalisé les deux fichiers PHP d'émission et de réception. Par contre, en testant en utilisant l'Arduino, on recevait bien des informations mais l'émission des données ne fonctionnait pas.<br /> <br /> ''' Séance 3 (21/05/2014) '''<br /> <br /> Nous avons corrigé nos erreurs qui se trouvaient dans notre code. Et nous avons configuré notre Foxboard avec le réseau polytech.<br /> <br /> ''' Séances supplémentaires '''<br /> <br /> Nous avons copié nos fichiers sur la Foxboard. Et nous avons rédigé le wiki.<br /> == Transmission ==<br /> Nous avons décidé de commencer par cette partie car elle était plus simple que la partie réception.<br /> En effet, il suffit d'ouvrir le port série et d'écrire la chaîne de caractères tapée par l'utilisateur dans le port série. Nos avons donc utilisé le language PHP pour réaliser cette mission. &lt;br/&gt;<br /> Voici notre code correspondant :<br /> <br /> <br /> &lt;font size='3' color='red'&gt;&lt;?php&lt;/font&gt; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Récupération des données de l'url*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; $entree=$_REQUEST['id']; &lt;/font&gt;&lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Ouverture du port série*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; define('SERIAL_DEVICE','/dev/ttyACM0');<br /> $f=fopen(SERIAL_DEVICE,'w'); &lt;br/&gt;&lt;/font&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Ecrire la chaine 'entree' dans le port série */ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; if($f==FALSE) die('fopen\n');<br /> if(fwrite($f,&quot;$entree\n&quot;)&lt;=0) die(&quot;fwrite \n&quot;);&lt;br/&gt;<br /> fclose($f);<br /> &lt;/font&gt;<br /> &lt;font size='3' color='red'&gt;?&gt;&lt;/font&gt;<br /> <br /> <br /> Cette fonction sera appelée quand l'utilisateur clique sur le bouton 'valider'. En effet, l'appuie sur le bouton permet d'appeler une fonction javascript qui, grâce à des requêtes Ajax, va pouvoir enregistrer des données dans l'url. Ainsi, la fonction PHP pourra avoir les données nécessaire. &lt;br/&gt;<br /> Voici le code correspondant à la fonction javascrip envoyer() :<br /> <br /> &lt;font size='3'&gt;function envoyer(){&lt;/font&gt; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt; /*Récupération de la chaîne de caractères entrée par l'utilisatuer*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt; var chaine = $('#entree').val(); <br /> var parameters={id: chaine}; &lt;br/&gt;<br /> &lt;font size='2' color='green'&gt;&lt;i&gt;/*Requête Ajax*/ &lt;/i&gt;&lt;/font&gt; <br /> &lt;font size='3'&gt;$.ajax({url: 'envoyer.php', type: 'post', data: parameters});&lt;br/&gt;<br /> }&lt;/font&gt; &lt;/font&gt;<br /> <br /> Nous avons pu tester en premier temps la transmission grâce à une carte Arduino qui allume une led pour dire que la carte a bien reçu une information.<br /> <br /> == Réception ==<br /> <br /> == Implémentation sur la Foxboard ==<br /> <br /> = Partie Électronique =<br /> ----<br /> Comme on a pu le voir précédemment,la valeur par défaut est à l'état haut. L'envoi du bit de start est représenté par le passage de l'état haut à l'état bas. Ensuite les 8 bits de données sont envoyés à chaque front d'horloge et le dernier (10ème bit) correspond au bit de stop qui permet la remise à la valeur par défaut.<br /> De plus, le bit de poids faible est transmis en tête.<br /> <br /> == Émission ==<br /> <br /> (Séance 1 et Séance 2)<br /> <br /> Pour la toute première séance, suite au choix définitif du sujet et de sa compréhension, nous avons effectué plusieurs recherches sur le fonctionnement de la liaison série. <br /> <br /> Avant de commencer directement sur le projet, nous avons réalisé le tutoriel d'Altium Designer proposé. Ce qui nous a permis de nous familiariser avec l'utilisation de ce logiciel. <br /> En effet, cela nous a permis de comprendre le fonctionnement de la Nanoboard avec les composants des différentes librairies &quot;FPGA&quot;.<br /> <br /> Ensuite, nous avons commencé réellement le projet, en nous intéressant dans un premier temps à la partie émission, qui nous semblait plus facile. <br /> Nous avons rapidement choisi d'utiliser un registre à décalage étant donné que l'on avait eu, au premier semestre, un TP de logique qui permettait de charger des données en parallèle et qui les transmettait ensuite en série.<br /> <br /> Nous avons donc débuté avec un montage simple qui comporte les éléments suivants:<br /> <br /> Un registre à décalage SR16CLES pour convertir Parallèle/Série<br /> <br /> Un Configurable Digital IO qui permet de générer les 8 bits de données, reliés au niveau des 8 premières broches du registre à décalage. Les autres sont reliées au VCC. Seule la broche D8 est reliée au GND (masse) pour représenter le bit de start qui est un passage de 1 à 0.<br /> <br /> Des LEDs pour visualiser la bonne conversion parallèle/série <br /> <br /> <br /> Suite à ce test, on a pu constater que le registre à décalage fonctionne.<br /> <br /> Pour la seconde séance, nous avions prévu de continuer et de terminer la partie émission et si possible de commencer la partie réception.<br /> <br /> Nous avons gardé le schéma de la première séance, mais nous avons ajouté en plus la possibilité de sélectionner parmi deux vitesses différentes d'émission (sous conseil de nos professeurs). L'utilisation d'un multiplexeur nous a permis de faire cette sélection.<br /> <br /> Il suffit de relier deux générateurs de fréquence sur les deux entrées du multiplexeur. L'appui sur un bouton de type switch, qui doit être complémenté, sélectionne l'une des deux entrées à générer. <br /> <br /> On utilise une bascule D afin de mémoriser le premier appui puis lors du deuxième appui, la valeur mémorisée est complémentée. Ce qui permet d'alterner entre les deux vitesses de transmission possibles, à chaque appui du bouton.<br /> <br /> De plus,un second bouton switch est utilisé pour le chargement des données parallèles.<br /> <br /> [[Fichier:Emission_avec_test.png|thumb|800px|center|Émission]]<br /> <br /> <br /> <br /> Une fois le schéma réalisé, nous avons effectué des tests en envoyant des trames avec le DIO ainsi que les générateurs d'horloge.<br /> Un générateur d'horloge était configuré pour réaliser une vitesse de transmission de 9600 bauds et un autre générateur d'horloge était configuré pour réaliser une vitesse de 4800 bauds.<br /> <br /> Puis nous avons visualisé avec l'analyseur logique ce que nous obtenions sur une broche du port A de la nanoboard.<br /> On remarque bien le bit de start, représenté par le passage de l'état haut à l'état bas.<br /> ::::::::[[Fichier:Alternance01010.png|thumb|400px|left|Trame de 8 bits alternés 0101 0101]][[Fichier:Trame_0101_0101.png|thumb|350px|center|visualisation à l'analyseur logique]]<br /> On remarque que l'on reçoit bien les bits alternés à l'envers, ce qui s'explique par le fait que le bit de poids faible est en-tête. L'émission de bits de données fonctionne donc parfaitement.<br /> &lt;br /&gt;&lt;br /&gt;<br /> Nous avons de plus, visualisé les fréquences des trames reçues afin de vérifier si nous obtenions bien les deux vitesses de transmissions désirées.<br /> On constate que la structure fonctionne bien.<br /> En effet, dès l'appui du bouton, on passe d'une vitesse de transmission de 9600 bauds (9.6 KHz) à une vitesse de transmission de 4800 bauds (4.8 KHZ).<br /> <br /> <br /> ::::::::[[Fichier:Fréquence_9600Bds.png|thumb|400px|left|visualisation de la vitesse de transmission de 9600 bauds]][[Fichier:Fréquence_4800Bds.png|thumb|400px|center|visualisation de la vitesse de transmission de 4800 bauds]]<br /> <br /> <br /> == Réception ==<br /> (Séance 2 et Séance 3)<br /> <br /> La partie émission fonctionnant, nous nous sommes penchés sur la partie Réception du système qui est apparue bien plus complexe.<br /> <br /> Suite à l'explication de Monsieur Boé, nous avons compris que pour cette partie, il était nécessaire d'utiliser deux générateurs d'horloge de fréquence différente. En effet, si l'on souhaite détecter correctement un bit, il faut se positionner en plein milieu du bit et non pas au niveau d'un front (montant ou descendant) afin d'être sûr de détecter un bit et non une perturbation quelconque. Pour se faire, il faut utiliser une deuxième horloge de fréquence deux fois plus rapide pour pouvoir être au milieu du bit.<br /> <br /> On reçoit la trame de 10 bits en série à partir de la broche RS RX. Puis le premier front descendant (correspondant au bit de start) doit être détecté pour démarrer le compteur.<br /> <br /> La porte AND donnera un 1 logique lorsque ce front sera détecté et que la valeur du compteur sera inférieure ou égale à 1.<br /> Ceci va provoquer un front montant au niveau de l’horloge de la bascule D ce qui va permettre le chargement de la valeur de D en sortie (Q).<br /> <br /> Cette sortie va donc permettre la mise en route du compteur (broche CE). Ce compteur est donc comparé à la valeur 10 qui valide l’entrée CE du registre U10 pour permettre le décalage.<br /> <br /> Si le compteur est strictement supérieur à 10, l’entrée CE du registre U10 (série vers parallèle) devient donc bloquée et ceci va entraîner le blocage du décalage. <br /> Au même moment, on remet le compteur à 0 en envoyant un 1 sur son entrée CLR et la sortie Q de la bascule repasse donc à 0 ce qui bloque le compteur U12.<br /> Si le compteur est supérieur ou égal à 1, l’entrée de sélection du multiplexeur est égale à 1 ce qui va donc changer la fréquence du compteur.<br /> <br /> <br /> [[Fichier:Schéma final.png|thumb|600px|center|Schéma complet de la partie Émission et Réception]]<br /> <br /> Malheureusement, cette seconde partie n'a pas donné de résultats concluants, nous n'avons donc pas pu valider son bon fonctionnement.<br /> <br /> = Assemblage =<br /> <br /> = Conclusion =<br /> <br /> En conclusion, la partie informatique fonctionne et la partie électronique seule la partie émission fonctionne convenablement, la partie réception ne donne pas de résultats concluants. Ce qui malheureusement, bloque la possibilité de relier les deux parties du projet...</div>

Gelbez