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

• Jeudi 29/01 : Mise en place du cahier des charges de notre projet.

Semaine 2

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

• Mercredi 04/02 : Implémentation du code en C++ permettant la lecture sur la liaison série en utilisant la bibliothèque 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.

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

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 = 987 ; // 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 :