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

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

                   // 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

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

Semaine 4

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

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

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