Proj-2013-2014-BrasRobot-Handicap-2

Cahier des charges

SRS [1]

1. Introduction :

Le logiciel doit permettre au bras robotique de détecter la présence d'un marqueur posé sur un objet quelconque et de définir une trajectoire afin de l'attraper et de le ramener à l’utilisateur . Le but étant à long terme de ce projet est développer des logiciels de contrôle de bras manipulateur pour l'assistance de personnes handicapés.

2. Matériel :

Nous avons a notre disposition un bras robotique «  RB-Lyn-322 » qui dispose de 4 dégrées de libertés . Chacun contrôlé par un moteur . Ce robot est aussi équipé d'un carte SCC-32 permettant d'assurer communication entre le robot est le logiciel . Une webcam est disponible permettant la détection de l'objet ( Parti effectue par le groupe 2)

3.Besoins fonctionnels :

      -Le logiciel doit être capable de communiquer avec tous robots équipé d'une carte SSC-32 .  
      -Le logiciel aura avoir deux mode : Un mode manuel qui permettra à l’utilisateur de déplacer librement le bras . Un deuxième qui seras de un mode dit de détection qui recherchera l'objet dans                     l'environnement  
      -Le logiciel doit être capable de calculer une trajectoire correct afin d'attraper l'objet . 
      -Pour des soucis de précision, Un simulateur doit être implémenté permettant de représenter le bras robotique virtuellement  . 
      -La logiciel doit être capable d’échanger des informations avec le groupe s'occupant de la partie détection de marqueur

4.Besoins non fonctionnels :

 . 
 -Langage de programmation Python 
 -Environnement système Linux, distribution Ubuntu ou Debian
 -Gestion des source git
 -Vpython pour la simulation de robot.

Team

• Supervisor: Olivier Richard

• Adam Tiamiou, Radhoane Ben Younes

• Department : RICM 4, Polytech Grenoble

Steps

The projet was attributed on Monday 13th and started the following day.

Week 2 (January 13th - Janurary 19th) -

Week 3 (January 20th - Janurary 26th)

- Test du bras robotique avec le logiciel fourni

- Apprentissage du Python

- Compréhension du code de pyssc-32

Week 4 (January 27th - February 2nd)

- Compréhension du code de pyssc-32

- Test de communication avec la carte ssc-32 .

- Recherches associées

- Modélisation de l'interface de commande du robot pour l'integration du code pyssc-32 permettant la communication

- Partage des tâches : Un s'occupe de la partie communication avec le robot . L'autre de l'interface en python + algorithme de positionnement lors de la détéction d'un marqeur .

Week 5 (February 3th - February 9th)

Deux tâches faites en parallèles  :

- Modélisation de l'interface de commande du robot (suite)

- Communication avec la carte ssc-32 succesfull. Problème : les positions des Servos sont trés dur à décrire avec uniquement l'utulisation du manual . Creation de fonction et classe permettant de decrire les positions plus efficacement

Communication de ssc-32 vers machine pose problème : la carte ssc-32 doit renvoyé des données afin de savoir par exemple si le moteur x est arrivé à position (Ex : fonction Wait_for_Servos (ssc32)) mais ne renvoie rien -> recherche de solution.

-Description du robot en deux zones graphiques : une pour l'axe des Z, une autre pour les axes X et Y.

-Codage du déplacement de la pince du robot en coordonnées X et Y : Optimisation du choix des axes(angles) à modifier,méthode des cercles, le bras doit se déplacer sur la zone graphique de façon cohérente => Recherche de plusieurs équations mathématique pour comprendre le problème

Week 6 (February 10th - February 16th)

- Finalisation du codage de la communcication avec ssc-32 (voir git) , création d'un parseur permettant d'envoyer une suite de commande au robot à partir d'un fichier txt .

- Développement du simulateur et de l'algorithme de déplacement .

- Déscription UML des différentes classes utilisé.

-> Avec le deuxième groupe .Trouver un moyen éfficace de définir l'emplacement assez précise du tag pour pouvoir avoir une position la plus proche possible et ainsci pouvoir déplacé le robot en conséquence .

-Réalisation de l'algorithme permettant à la pince d'atteindre un point(atteignable) sur la zone XY

Week 7 (February 17th - February 23th)

- Modélisation des axes du robot en VPython

- Déplacement de la pince en coordonnée XY grâce à un Drag de la souris => Définition de la manière dont les axes (2 axes pour l'instant) bougent grâce à la méthode des cercles

- Modification de l'algorithme pour intégrer les angles limites des différents axes du robot => On se rapproche de la réalité

Week 8 (February 24th - March 2nd)

Objectif : - Intégration intelligente du troisème axe(la pince) du robot dans l'algorithme de déplacement en fonction de son utilité (l'axe est court et il doit etre parallèle pour récupérer un objet)

- Prise en compte de la coordonnée Z

- Détermination de la trajectoire de la pince pour récupérer un objet (Soit en utilisant la méthode des cercles mais cela risque d'être trop linéaire, soit en utilisant une trajectoire formée de plusieurs points qui seront atteint grâce à l'algorithme => flexibilité et permettra de mieux gérer les obstacles comme un axe qui passe à travers un objet)

-Correction des bugs et détermination de nouveaux objectifs

- Création d'un Socket de connexion afin de partager les ressources avec le groupe 2 .

Week 9 (March 10th - March 17th)

- Concernant l'animation du robot en vPython, le drag de la pince fonctionnne parfaitement si le second bras est orienté à droite du point d'intersection entre les deux bras. Quelques bugs sont à corrigés (et corrigeable) pour le côté gauche. Les angles limites ont été pris en compte seulement pour le bras 1. Le faire pour le bras 2 masque les bugs du côté gauche. Je préfère les résoudre avant.

- Le robot arrive à suivre une trajectoire qu'on lui donne. Mais si quelques points ne sont pas atteignables, il y a un saut des axes (suivant un angle précis). Reste à savoir de quelle manière va réagir le vrai robot. Doit-on bouger point par point, ou bien suivant un unique angle pour chaque bras qui amène directement à la destination => chaque bras doit bouger angle/100 par angle/100 par exemple. Reste à déterminer la meilleur solution pour optimiser la recherche avec la caméra et l'esquive des obstacles.

Objectif : Corriger les bugs, choisir la meilleur solution pour l'animation (trajectoire,angle...), prendre en compte la pince comme étant un petit bras : intégrer la coordonnée Z, créer une animation lorsque la pince est proche de l'objet..., recherche de la trajectoire optimale pour trouver le marqueur.

-Développement d'une l'interface afin d'intégrer l'option de sélection des ports.

Week 10 (March 17th - March 23th)

- Solution avec le groupe 2 pour communiquer avec le robot -> Comment à partir de l'image, determiner la distance et la position exact de l'objet . En effet , l'objet une fois détecté sur l'image ne donne aucune indication sur sa position . Il n'est pas forcement au centre de l'image (donc une rotation d'angle est nécessaire).Le but étant de trouver cette angle.

La première serait d'avoir une coordination entre la camera et le robot pour que l'objet soit au milieu de l'image . Il ne restera plus qu'a avancer pour attraper l'objet . Cependant cette solution pose problème au niveau de la détection. Il est pour le groupe 2 difficile de programmer cette solution.

- Programmation de algorithme de détection : Le but est d'avoir un balayage le plus efficace et d'éviter tout "angle mort". On connait la taille de la fenêtre et la distance de détection .

Week 11 (March 23th - March 30th)

- Rédaction du manuel d'utulisation du logiciel ainsi que du flyers.

- Finalisation du simulateur, amélioration de l'interface.