Robot déformable

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 effectué des tests sur des moteurs (autres moteurs que ceux du robot). 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 floats, ou des chars. Lors de l’envoi, nous avons rencontré quelques problèmes liés à ces types. En effet, si nous envoyons des float et des int, alors la partie décimale du float était ajouté à 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. Hors 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êche pour le moment de tester les modifications apportées à notre programme.

Semaine 5

• Lundi 23/02 :

Nous sommes toujours dans la même situation que Jeudi 19/02, mais nous essayons 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. Malgré tout, 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.

• Jedui 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 lectures, qui le perturbent. 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