Robot déformable : Différence entre versions

Version actuelle datée du 15 juin 2015 à 19:24

Cahier des charges

Présentation générale du projet

Contexte

Dans le cadre des recherches de l'équipe DEFROST (DEFormable RObots Simulation Team) basée à l'INRIA Lille é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?

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?

Objectif du projet

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.

Description du projet

Au cours du projet, nous traiterons 3 différentes parties :

Le robot déformable

• La partie simulation, récupération des données du logiciel

• La partie gestion du port série

• La partie gestion de l'Arduino

Vous trouverez ci-dessous les différents détails et objectifs concernant ces parties :

Partie simulation

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.

Partie interface port série

Dans cette partie les objectifs à atteindre seront les suivants :

• Gérer les vitesses d'envoi des différentes informations

• Adapter les types de données en faisant les calculs de conversion si nécessaire

• Gérer la communication (les périodes d’échantillonnage)

• Permettre l'échange de données dans les deux sens

Partie Arduino

La partie Arduino devra permettre d'obtenir :

• Des informations sur le nombre d'actionneurs

• Des informations sur le type de ces actionneurs :

- Servos moteurs
- Actionneurs pneumatiques
- Actionneurs hydrauliques
- SMART Servos (c'est à dire des Servos permettant le contrôle de position, de vitesse et de couple)

• Des informations sur le type de données envisagées

• Des FeedBacks des différents actionneurs, et de capteurs potentiels

Ainsi ce projet consiste à :

• Comprendre l’actuelle configuration du robot

• Créer une interface de contrôle en C pour
  • Calibrer les actionneurs
  • Transmettre les informations de forces/positions

But : Faciliter son utilisation

Choix techniques : matériel et logiciel

Logiciel :

• Logiciel open source SOFA [fourni au 28/1/2015 par l'INRIA]

Matériel :

• Robot déformable en silicone [fourni au 28/1/2015 par l'INRIA]
• Un Arduino [fourni au 28/1/2015 par l'INRIA]
• Informations sur les différents actionneurs

Etapes du projet

Voici le planning prévisionnel et l'avancement réel de notre projet sous forme d'un diagramme de Gantt :

Avancement du Projet

Semaine 1

• Lundi 26/01 :

Nous avons commencé par des recherches sur les travaux de l'INRIA concernant le robot déformable.

Projet de l'inria sur les robots déformables

Control of Elastic Soft Robots based on Real-Time Finite Element Method.Christian Duriez

• 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 é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 :

 struct servom{
 Servo servo;
              };
 servom servomo[nbMotors-1]; 

Ainsi, nous avons pu créer rapidement notre tableau de servos moteurs.

• Jeudi 29/01 :

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.

Nous avons également mis en place du cahier des charges de notre projet.

Semaine 2

• Lundi 02/02 :

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 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() ».

• Mercredi 04/02 :

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.

• Jeudi 05/02 :

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 :

  struct timeval timeout;
  timeout.tv_sec = 1.999;
  timeout.tv_usec = 0;
  vrpn_read_available_characters(portNumber,buffer,bytes,&timeout);

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.

Semaine 3

• Lundi 09/02 :

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.

                   // Actionneurs type servos moteurs
                   float diametre_SM = 35.01 ; // en mm
                   float angle_min_SM = 15 ; // en deg
                   float angle_max_SM = 165 ; // en deg

• Mercredi 11/02 :

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.

• Jeudi 12/02 :

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.

Semaine 4

• Lundi 16/02 :

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 projet IMA5, qui utilisait cette fois-ci des actionneurs pneumatiques.

• Mercredi 18/02 :

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. Nous nous situons dans la phase tests et re-vérification du CdCF selon le diagramme en V ci-dessous :

• Jeudi 19/02 :

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.

Semaine 5

• Lundi 23/02 :

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.

• Mercredi 25/02 :

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.

• Jeudi 26/02:

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.

Objectifs pour les séances prochaines :

• Tests des différents programmes
• Réimplantation du code avec le logiciel SOFA

Semaine 6

• Lundi 11/03 :

Depuis le début du projet, nous avons utilisé la vitesse de transmission maximale pour un arduino mega qui est de 115200 baud. Afin de résoudre nos problèmes, nous avons pensé à changer cette vitesse. En faisant quelques tests avec d'autres valeurs, nous sommes rendues compte que notre code marchait bien avec une vitesse de 9600 baud. Nous avons donc réglé cette vitesse sur le logiciel SOFA (scènes SOFA) , afin que celui-ci soit adapté aux codes.

• Mercredi 13/03 :

Nous avons commencé par installer le logiciel SOFA via ce lien logiciel SOFA et nous avons commencé à modifier le programme du plug-in SoftRobot.

Semaine 7

• Lundi 16/03

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.

• Mercredi 18/03

Pour compiler le programme, il fallait que tous les tableaux présents dans la première fonction "init" puissent être utilisés dans la deuxième. Pour cela nous devions créer une "Data" SOFA. Nous avons rencontré de nombreux problèmes (notamment dus aux fonctions de SOFA et leur utilisation dont les exemples sont rares).

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 :

Par exemple, dans la première fonction, on déclare un "write accessor" qui permet de faire le lien avec la DATA sofa préalablement déclarée, puis un "read accessor"

 sofa::Data<vector<float> > infosServosm // déclaration de la data SOFA dans le .h

 using sofa::helper::WriteAccessor; // déclaration pour pouvoir accéder aux  fonctions de type "Accessor"
 using sofa::helper::ReadAccessor;

 WriteAccessor<Data<vector<float> > > infosservosm= infosServosm; // déclaration dans la première fonction
 infosservosm.resize(50); // Permet de choisir la taille, ici 50

 ReadAccessor<Data<vector<float> > > infosservosm = infosServosm; 
 // déclaration dans la deuxième fonction pour accéder aux données, à savoir que la variable "infosservosm" crée s'utilise comme un tableau classique en C.

• Jeudi 19/03

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. Il ne nous restait plus qu'a réimplanter le code dans le projet SOFA.

Semaine 8

• Lundi 23/03

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.

• Mercredi 25/03

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à.

• Jeudi 26/03

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é.

Semaine 9

• Lundi 30/03

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 "en dur", 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.

Missions pour les semaines à venir :

- Objectif pour la fin de semaine : les parties Arduino et liaison série sont liées et fonctionnent.
- Objectif pour la semaine prochaine : les tests ont été effectués sur les robots et l'actionneur hydraulique à été ajouté.
- Objectif pour la semaine 11 : Mise en place des feedBacks des actionneurs du robot.

• Mercredi 01/04

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.

• Jeudi 02/04

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. Nous avons également voulu tester le code de la liaison série sur SOFA. Nous avons alors ouvert la "scène" 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).

Semaine 10

• Lundi 06/04

Ce lundi était férié.

• Mercredi 08/04

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.

• Jeudi 09/04

Même en ayant réalisé la mise à jour du pluging et donc en arrivant enfin à obtenir la bonne scène, le logiciel affichait tout de même un warning qui nous indiquait que la liaison entre la scène et Sofa n'était pas faite. Nous avons essayé de compiler notre programme mais nous n'arrivions pas à obtenir les bons résultats.

Semaine 11

• Lundi 13/04

Nous nous sommes rendues compte que le problème venait de la scène Sofa puisque la simulation n'envoyait que des 0. Afin de résoudre le problème, nous avons demandé à nos encadrants de nous aider. La scène SOFA a donc été corrigée. Ainsi, nous n'avions plus de warnings qui nous empêchaient de faire le lien avec notre code et le projet pouvait reprendre.

• Mardi 14/04

Après avoir effectué des tests sur sur l'arduino et sur la liaison série, nous avons commencé par définir les adresses des différentes broches du robot déformable avec les servomoteurs. Ensuite, nous avons transvasé notre code arduino sur la carte arduino Uno du robot. Les premiers tests sur le robot n'étaient pas très concluants.

• Mercredi 15/04

Nous nous sommes vite rendues compte qu'il y avait un problème de dépassement de mémoire. En effet, nous avions effectué 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 nous stockions 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 "vrai" robot déformable avec les servomoteurs.

• Jeudi 16/04

Nous avons eu l'intervention de l'industriel Valeo toute la matinée.

Semaine 12

• Lundi 20/04

Nous avons réglé quelques problèmes de 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 "vrai" robot pneumatique grâce à notre code.

==> Le code marche donc pour un robot pneumatique mais également pour un robot avec des actionneurs de types servos moteurs.

• Mercredi 22/04

Cette journée a été dédiée à la réalisation de la vidéo de notre projet. Elle a été réalisée par notre tuteur de projet, au sein de l'INRIA.

Bilan du projet

Bien que ce projet ne soit pas totalement finalisé (en effet il manque les Feedsbacks des actionneurs), il fonctionne néanmoins pour 2 types de robots :

- Les robots avec des actionneurs de type pneumatiques
- Les robots avec des actionneurs de type Servo moteurs.

Ce projet a été très enrichissant tant au niveau personnel que professionnel, car nous avons pu découvrir le fonctionnement d'un laboratoire de recherche et travailler en équipe.

A l'avenir, il serait intéressant d'améliorer le code produit, afin d'y implémenter tous types d'actionneurs et les Feedbacks manquant.

Fichiers Rendus

Média:Rapport_final_tiraby_elbez.pdf

Média:codes.zip