Version actuelle datée du 19 mai 2023 à 15:56

Résumé

Le projet BraVeD (projet n°14) acronyme de "Bras Virtuel Distant" consiste en un système de manipulation d'un bras robotique à distance qui recopie les mouvements du bras de l'utilisateur avec un retour visuel dans un casque de réalité virtuelle. Des caméras placées autour de l'opérateur permettent de capter les mouvements de son bras, de les analyser et de les reproduire avec le bras robotique. Le casque de réalité virtuelle permet à l'opérateur de contrôler le bras comme s'il s'agissait de son propre bras. L'ajout de la vision 3D augmente encore cette immersion en offrant un retour en temps réel des actions du bras. Le but final est de pouvoir contrôler le bras robot depuis n'importe quel endroit possédant une connexion internet. Nous pourrions de ce fait déplacer le savoir-faire humain, ses compétences et son analyse dans des situations où ce dernier ne serait agir. Nous inscrivons BraVeD dans l'avenir. En cette nouvelle ère de digitalisation, notre projet offre la possibilité à n'importe qui de travailler n'importe où.

Voici le lien de la vidéo de présentation du projet : Vidéo de présentation du projet BraVeD

Présentation générale

Un projet est avant tout incarné par les personnes travaillant à sa réalisation. Nous nous présentons à vous. Nous sommes un groupe de 4 étudiants de SE4 :

• Julien CHARLEUX
• Karl HABRE
• Thomas LEFRANC
• Tanguy RIDREMONT

Le projet BraVeD est constitué de 3 parties majeures :

• Le système mécanique : bras robotique et sa supervision
• La reconnaissance d'image : intelligence artificielle et traitement des données
• La transmission des données : transfert des flux vidéo et des commandes au bras

Contexte

Avant de commencer, nous devons mieux définir le sujet qui nous est donné, lui donner un cadre. Pour nous aider, nous réalisons le diagramme “bête à cornes” ci-dessous :

Nos recherches d’idées seront donc axées sur le principe suivant : le bras robot doit être capable de reproduire les mouvements du bras de son utilisateur tout en offrant une commande intuitive. Nous offrons aussi un retour visuel afin que l’opérateur ait l’impression que le bras robotique est un prolongement de son propre bras. Nous ajoutons la possibilité d’utiliser notre système depuis n’importe quel endroit.

Nous souhaitons réaliser un bras manipulateur pouvant s’adapter à plusieurs situations, il est donc difficile de fixer un client type. Cependant, nous pouvons cibler certains domaines : la manutention, l’art, la santé et l’industrie.

Pour donner un exemple, prenons un joaillier. Son savoir-faire est unique et lui permet de travailler avec précision. Notre bras pourrait lui permettre d’appliquer son art à une différente échelle tout en gardant une utilisation simple afin de pleinement lui permettre de réaliser son travail.

Objectif

Cahier des charges

Le sujet donné étant assez large, nous devons nous fixer un cadre et approfondir. Le but est de construire un bras manipulateur contrôlé par la réalité virtuelle. Nous choisissons de définir plusieurs points clés qui définissent notre projet. Nous appelons ces points “fonctions principales” :

• FP1 : Doit permettre des manipulations efficaces
• FP2 : Doit pouvoir communiquer avec l’utilisateur
• FP3 : Doit respecter les normes de sécurité
• FP4 : Doit être modulable
• FP5 : Doit être résistant
• FP6 : Doit être ergonomique
• FP7 : Doit avoir un prix raisonnable
• FP8 : Doit être respectueux de l’environnement

A partir de ces axes principaux, nous avons explicité des fonctions complémentaires permettant de créer un cahier des charges détaillé. Ce cahier des charges contient l’ensemble des points que l’objet final doit pouvoir respecter ou effectuer. Les priorités sont fixées pour la réalisation du prototype. Nous fixons des limites à notre projet afin de le rendre réalisable mais en gardant les fonctions qui semblent intéressantes à implémenter.

Diagramme pieuvre / APTE :

En partant de ces différentes fonctions complémentaires, nous définissons les fonctions complémentaires qui sont détaillées dans le cahier des charges : Fichier:Cdc P14.pdf

Description

Faire un choix parmi les idées proposées ne fut pas une étape facile. Cependant, nous nous sommes vite accordés. L’idée permettant de contrôler un bras robotique à partir des mouvements de son propre bras semblait assez novatrice. De plus, après une rapide étude de faisabilité, cette solution nous a paru la meilleure. Nous aurions aimé pouvoir ajouter l’option du retour de force au système, mais faute de moyen et de temps nous avons abandonné cette idée.

Ce schéma nous montre comment l’ensemble du système que nous souhaitons développer est censé fonctionner. De gauche à droite, nous avons : 2 à 3 caméras permettant d’observer les mouvements de l’utilisateur. Une 3ème caméra servirait dans le cas où nous voudrions implémenter la retranscription des mouvements des 2 bras de la personne. Le flux vidéo est ensuite transmis vers une unité de traitement de données (Raspberry PI) qui va convertir le mouvement des bras en vecteurs dans un référentiel en 3 dimensions. Ce même Raspberry PI servira à transmettre le flux vidéo reçu vers le casque de réalité virtuelle. Pour envoyer et recevoir des données, nous passons par un routeur WiFi connecté, de préférence, au réseau en Ethernet pour une meilleure stabilité et une connexion plus rapide. Celui-ci transmettra vers un deuxième routeur situé à distance (quelques mètres ou à des milliers de kilomètres) communiquant avec la deuxième unité de traitement des données (Raspberry PI) Le rôle de ce Raspberry PI sera de transmettre les informations de déplacement au bras manipulateur directement (si nous utilisons un protocole UDP, sinon nous passerons par l’intermédiaire d’une carte Arduino). De plus, il servira à combiner le flux vidéo des 2 caméras situées au niveau du robot pour former une image 3D visualisable par un casque de réalité virtuelle.

Ce modèle peut être amené à changer au fur et à mesure de notre avancement, des potentielles difficultés rencontrées ou si de meilleures solutions sont trouvées. Par exemple, si nous disposons d’une caméra 3D, nous pourrions éviter la conversion des 2 flux vidéo si cela nous permet de garder une bonne qualité d’image. D’autres changements dans le même genre pourront être envisagés en fonction de notre avancement l’année prochaine.

Etude du projet

Etat de l'art

Notre projet étant défini, il est intéressant de se renseigner sur les projets similaires au nôtre. Cette étude de l'existant nous permet de voir les marchés potentiels ainsi que l’attrait que représente cette technologie. Lors de nos recherches, nous avons découvert plusieurs projets similaires :

• MAESTRO
• Robot Da Vinci / ZEUS
• SARCOS

Maestro

Le bras robotique Maestro est un système téléopéré utilisé dans le démantèlement de centrales nucléaires. Projet de l’entreprise Cybernetix, né suite à plus de 10 ans de recherche et développement et utilisé par le CEA, il permet à l’homme d'opérer dans des environnements hostiles (Centrale). Pour déplacer le robot, l’opérateur manipule un bras “maître” dont les mouvements sont retranscrits sur le bras “esclave”. Le retour des actions est assuré par des flux vidéo du champ de travail et de simulations 3D. Le robot est conçu pour résister à la forte radioactivité des sites et possède plusieurs modules et accessoires lui permettant de réaliser les tâches qui lui sont assignées.

Système Da Vinci

Le système Da Vinci Si HD, créé par la société Intuitive, est utilisé dans le domaine chirurgical. Il se base sur la téléopération de plusieurs bras permettant au chirurgien d’opérer un patient. La téléopération est effectuée grâce à un retour visuel 3D de l’action des bras. A l’aide d’un zoom puissant et d’une haute qualité d’image, le chirurgien peut effectuer des opérations plus précises et moins invasives. Cela a pour effet de limiter la durée des opérations, les risques d’infections et maintes complications. Cependant, la distance entre l’opérateur et le bras reste limitée à quelques mètres. Mais cette distance tend à grandir.

SARCOS, Guardian XT

Sarcos est une entreprise leader dans le domaine de la robotique proposant de nombreux produits ayant pour but d’assister le travail de l’Homme. Nous nous intéressons ici au Guardian XT, un robot téléopéré ayant pour objectif d’apporter le savoir-faire humain dans des environnements hostiles. Le robot est placé sur une nacelle télescopique et se compose de deux bras fixés sur un support mobile. Le Guardian XT est ainsi capable de reproduire les mouvements de l’opérateur situé en lieu sûr. Un casque de réalité virtuelle permet un retour visuel et l’opérateur contrôle le robot par deux manettes. Tous ces projets possèdent des avantages et des inconvénients. Notre but est de synthétiser le meilleur de ces robots pour n’en garder que le meilleur. C'est-à-dire pouvoir contrôler un bras robotique et robuste à partir des mouvements du bras de l’utilisateur tout en ayant un retour visuel 3D. C’est donc ici que nous apporterons notre savoir-faire pour innover.

Risques potentiels

Au vu des projets déjà existants, nous devons nous démarquer. Il est donc nécessaire de créer un robot basé sur un unique principe, que les concurrents n’ont pas. Nous pouvons ajouter à cela, un temps de recherche et développement long qui cause un retour sur investissement tardif.

Lors de nos recherches, nous n'avons pas pu trouver le prix des différents systèmes. Le positionnement du prix est pourtant un point très important. Si nous fixons un prix trop haut, le consommateur risque de ne pas acheter. Or, sans connaître le prix de vente des systèmes dans le marché, il est difficile de définir un prix de vente acceptable.

Etude de faisabilité

En comparant notre projet avec ceux que nous avons pu trouver, nous pouvons conclure que notre idée est réalisable. Ces entreprises ont pu développer leurs prototypes et même commercialiser un produit fini. Cependant, la plupart de ces projets ont nécessité beaucoup d'années de développement. Pour prendre l’exemple du bras MAESTRO, le temps de recherche et développement s’élève à 10 ans. De son côté, le Guardian XT a nécessité 20 ans de travail.

Compte tenu du temps nécessaire au développement de ces produits, il est difficile de réaliser un produit fini dans le temps imparti. Nous réalisons la construction d’une maquette de notre projet fonctionnelle. Il s'agit de notre objectif principal pour ce projet.

Réalisations et résultats du semestre 7

Le bras que nous utilisons pour ce projet et le bras NED de la société Niryo. Nous avons choisi ce bras (ci-contre) car il remplissait la majorité de nos attentes :

• Ses proportions sont proches de celles d’un bras humain.
• Ses articulations permettent plus de liberté dans les mouvements possibles.
• La communication sans fil nous permet de contrôler le bras en aillant un espace de travail sans câble.
• Le robot peut être commandé par un programme Python qui est un langage de programmation que nous connaissons bien.

Pour la commande du bras, nous avons décidé de développer deux modes pour laisser le choix en fonction des performances obtenues pour chacun d'entre eux.

• Le premier utilise les commandes fournies par le package du robot Niryo NED. Nous saisissons les valeurs de rotation des angles souhaitées sur un ordinateur. Le robot se déplace alors à cette position.
• Le second se base sur les coordonnées de l'articulation du "poignet" par rapport au socle du robot. En utilisant les touches du clavier, nous changeons les coordonnées X, Y et Z de cette articulation. Le robot effectue les mouvements choisis. Ce mode de commande nécessite plus de calcul car il se base sur la résolution d'un système d'équations pour trouver les valeurs des angles nécessaires pour atteindre les coordonnées.

Lien de la démonstration du second mode de commande : Vidéo de démonstration

Le développement du modèle mathématique nous a également permis de créer une représentation graphique du bras pour vérifier que la position dans laquelle est le robot est bien celle ordonnée par les commandes. Cependant, le développement de la modélisation a retardé l'interface de contrôle du robot qui n'est pour l'instant qu'à l'état d'ébauche :

Les résultats de notre travail sont présents. Les deux modes de commandes fonctionnent et offre une précision correcte. Cependant, nous relevons plusieurs problèmes suites aux essais que nous avons réalisé :

• Le temps de réponse du robot est long. Si le déplacement demandé est très éloigné la position actuelle du robot, son déplacement prendra du temps à s'exécuter. A chaque déplacement lancé par le code Python, ce dernier n'effectue pas d'autre calculs tant que ce déplacement n'est effectué.
• Le modèle mathématique actuel ne présente que 3 des 6 articulations que possède le bras. La prise en compte des autres augmentera significativement le temps de résolution du système d'équations.

Nous avons donc cherché des solutions et des changements que nous devrons réaliser pour obtenir un meilleur résultat :

• Si le programme de commande des moteurs du robot fourni avec le package Pyniryo est lent, nous pouvons essayer de trouver un moyen de commander nous même les moteurs et de refaire l'asservissement. Dans le cas où l'opération serait impossible, il faudra refaire la commande sur un autre bras offrant une meilleure réactivité.
• Le modèle mathématique doit être améliorer afin de prendre en compte l'intégralité des articulations. Cependant comme le calcul des coordonnées se fait à partir de la pince, le système d'équation resterait identique.

Intelligence artificielle

L’intelligence artificielle est un script python basé sur le réseau de neurone Pose de MediaPipe celui-ci renvoie la position des différentes articulations ou points importants pour décrire la position du corps. Le programme fait tourner l'algorithme suivant deux points de vue gérés par des caméras dont les informations sont elles même récupérées via OpenCV. Cela permet de reconstituer plus précisément la position 3D du corps et de corriger de potentielles erreurs. L’objectif à terme est de récupérer uniquement les coordonnées du bras et de transformer ces coordonnées en l’angle des articulations qui pourra permettre de restituer les mouvements sur le bras d’un robot.

Le principale inconvénient de cette méthode est la puissance de calcul nécessaire. Il faut faire tourner un algorithme relativement demandeur en puissance de calcul en double sur une seule machine ce qui nécessite d’optimiser l'algorithme et donc de perdre en précision. Le prototype devant rester portable, il n’est pas possible de faire porter à l’utilisateur une grosse machine alors que ce même utilisateur doit déjà porter la structure de maintien des caméras.

Plusieurs solutions d’optimisation existent : -La première consiste à réduire dans un premier temps la précision de l’algorithme même si les coordonnées du bras sont relativement peu précises puis à zoomer sur l’image à la position relative du bras et faire tourner l’algorithme que sur cette position à plus haute performance la réduction du nombre de pixel permettra à l’algorithme de réduire son temps de calcul et les données du bras resteront précise. -La seconde consiste à réduire la fréquence des images pour laisser plus de temps à l’algorithme pour calculer ces coordonnées mais dans cette situation on prend le risque de réduire le temps de réponse du système. Les tests du prochain semestre nous diront ce qu’il adviendra de ces solutions.

Transmission de données

Interface graphique du logiciel Hamachi

Concernant la transmission des données, encore une fois nous avons choisi de nous servir de scripts Python, ce qui permet de faire facilement le lien avec les autres programmes en développement pour notre projet. Dans un premier temps, on récupère un ou plusieurs flux vidéo (image par image) à l'aide de la librairie cv2 (OpenCV) à partir de cameras que l'on branche sur les ports séries de notre machine.

Ensuite, notre script permet d'établir la communication entre deux ordinateurs distants via le réseau Internet. Pour outrepasser les sécurités des réseaux de l'université, nous créons un réseau local virtuel via Hamachi. La communication se fait via des paquets en UDP/IP et sert principalement à envoyer un flux vidéo en temps réel entre les deux ordinateurs.

La seconde majeure partie concerne la liaison entre un ordinateur et le casque de réalité virtuelle. Pour le moment, nous nous servons de Vizard pour établir la communication entre le casque et l'ordinateur en Python. Cet outil nous permet d'envoyer le flux vidéo directement vers le casque, tout en ayant la possibilité d'y ajouter l'affichage d'informations importantes. Cependant, cet outil étant limité à des utilisations de 5 minutes maximum, nous sommes actuellement à la rechercher d'alternatives plus viables.

Bilan

Lors de ce semestre, nous avons acquis de nombreuses compétences techniques dans les domaines sur lesquels nous avons travaillé. Que ce soit le maîtrise de moyen de connexion distant, la commande d'un bras ou la gestion d'une intelligence artificielle. Ce projet nous force à développer nos compétences transversales. De ce fait, nous apprenons à gérer une équipe, à se transmettre les informations nécessaires. La planification est importante car elle structure le projet et permet à chacun d'adapter son travail à celui des autres. Ce point sera particulièrement important au prochain semestre pour coordonnées les avancements de chacun si les séances de projets n'ont pas lieu en même temps pour chaque membre de l'équipe.

Réalisations et résultats du semestre 8

Contrôle du bras robot Niryo NED

Après avoir développé des commandes manuelles lors du semestre 7, nous avons remplacé ces commandes par un mode complètement automatique. Avec la lecture des commandes envoyées par le logiciel de reconnaissance d’images, nous récupérons une liste de 6 angles. Nous pouvons ensuite en déduire des commandes à envoyer au robot. Pour ce faire, nous réalisons un package permettant de gérer des contrôleurs PID. La structure du PID définie est la suivante :

Comme nous ne connaissons pas le dynamique du système, nous ajustons les paramètres des contrôleurs à la main pour obtenir le meilleur temps de réponse possible.

Ce système de commande corrige le problème principal du semestre précédent. En effet, les commandes sont maintenant calculées en temps réel à partir des ordres envoyés par le logiciel de reconnaissance d'image. Nous avons effectué de nombreux tests pour assurer le meilleur temps de réponse sans oscillations. Pour les tests, nous appliquons des échelons de commande prenant les valeurs extrêmes de déplacement des articulations. Ainsi, nous assurons que le robot n'oscille pas même pour des variations de commandes extrêmes. Cependant, le temps de réponse reste un frein à la réactivité de notre système. Le bras Niryo NED est fermé logiciellement, ce qui nous empêche d'accéder aux contrôleurs internes du robot. Nous ne pouvons qu'ajouter des contrôleurs par dessus ceux existant afin d'obtenir une dynamique du système qui correspond à nos attentes. De plus, les ordres de commandes sont envoyés en TCP au bras robot ce qui diminue la réactivité des contrôleurs. Si nous avions accès à un bras robot plus ouvert, nous pourrions avoir une réactivité bien meilleur en accédant directement aux contrôleurs internes.

Interface Homme-machine de supervision du bras

La surveillance du système est importante pour nous. Ainsi, nous avons développé des interfaces Homme-machine pour aider la commande du bras ainsi que les développements des commandes avec le logiciel de reconnaissance d'image :

Ces deux interfaces sont des améliorations directes des interfaces réalisées au semestre précédent. L'interface de gauche se base sur la modélisation directe du bras Niryo NED que nous avons refait en prenant en compte les problèmes de l'ancienne modélisation. Contrairement à la modélisation du semestre 7, celle présentée ci-dessus est en temps-réelle et suit l'évolution des commandes et de la position du bras en fonction du temps. Nous pourrions améliorer ces projets en affichant plus d'informations sur la seconde interface. Par exemple, il serait intéressant d'afficher les status de connexion entre les programmes ou encore le temps d'envoi des commandes au Niryo NED, etc...

Conception du nouveau bras

Le bras mis à notre disposition nous a permis de faire des tests et d’arriver à un rendu convenable, mais n’était pas optimal en termes de fonctions et de contrôlabilité. C’est pourquoi l’idée exposée au semestre précédent est devenue possible quand nous nous sommes rendu compte que nous aurions assez de temps pour faire un prototype.

Le robot conçu est initialement destiné à servir de modèle pour expliquer les concepts de base de la mécanique et de l'électronique au sein du Fabricarium de l'école. Il permet également de découvrir la programmation et la commande d'un robot manipulateur en utilisant différents langages et protocoles de communication. Dans notre situation, il permet aussi de résoudre les problèmes d’environnement fermé du Niryo NED.

Pour ce faire, il est nécessaire de développer aussi bien l’aspect électronique que mécanique du projet. Étant étudiant en système embarqué et appréciant particulièrement l’électronique, j’ai choisi de commencer par la conception et la programmation de PCB fait maison et de faire la mécanique avec le temps restant.

Le choix le plus important a été la masse transportable à bout de bras de 0,5 kg et la possibilité pour chaque pivot sauf une (la deuxième) de tourner sans limitation d’angle de rotation. Aussi un système d'interfaçage simplifié pour différentes applications est d’une grande importance.

Reconnaissance d'image

L’intelligence artificielle est un script python basé sur le réseau de neurones Pose de MediaPipe. Celui-ci renvoie la position des différentes articulations ou points importants pour décrire la position du corps. Le programme fait tourner l'algorithme suivant deux points de vue gérés par des caméras dont les informations sont elles-mêmes récupérées via OpenCV. Cela permet de reconstituer plus précisément la position 3D du corps et de corriger de potentielles erreurs. L’objectif à terme est de récupérer uniquement les coordonnées du bras et de transformer ces coordonnées en angle des articulations. Ceci permet de restituer les mouvements sur le bras d’un robot.

Mediapipe Pose propose une estimation de la profondeur en utilisant un seul flux vidéo. Cependant, nos tests ont montré que l'estimation est parfois fortement en décalage avec les positions réelles. Pour éliminer ce problème, nous utilisons deux caméras pour recréer une projection 3D sans l'estimation :

En utilisant les deux caméras nous recréons un espace 3D sans estimation logicielle. L'écart entre les deux caméras est maintenu à 90° par la structure ci-dessous pour simplifier les calculs :

Dans les schémas ci-dessus, nous n'utilisons pas les axes z1 et z2 fournit par le réseau de neurone. Les résultats sont probants en utilisant cette méthode et offrent une détection plus fidèle à la réalité. Cependant, un point important remet en question cette méthode. En utilisant plusieurs caméras, nous augmentons également le nombre de flux vidéos à traiter. Les deux flux vidéos sont traités par deux réseaux de neurones en simultané. Ce procédé nécessite une machine avec une puissance de calcul importante. En théorie, plus il y a de caméra, plus le résultat sera probant. Mais ce problème limite le nombre de caméra que nous pouvons utiliser.

Le package Mediapipe Pose amène également quelques erreurs. Quand nous avions fait le choix du module de reconnaissance d'image, nous avons choisi Mediapipe pour sa rapidité d'exécution. En effet, de ce point de vu il est plus rapide que ses concurrents. Mais ces performances sont parfois obtenus au détriment de la précision. Ainsi, quand les conditions de captures sont difficiles (contre-jour, scène avec peu de contraste) la détection perd en précision :

Dans les cas ci-dessus, nous voyons différentes erreurs de détection. Dans le premier, le coude n'est pas placé à la bonne place ce qui amène des erreurs dans les commandes transmises au robot. Le second est plus problématique car il détecte un corps là où il n'y en a pas. Ces fausses détections rendent les calculs des commandes inutiles en donnant des ordres incorrectes au bras.

Calcul des commandes

Maintenant que les points de la structure du corps humain sont récupérés à partir de Mediapipe Pose, nous pouvons réaliser les commandes du bras. Pour ce faire, nous nous basons sur le calcul suivant :

En utilisant cette formule pour des vecteurs en 3 dimensions, nous pouvons obtenir les angles des différentes articulations du corps (comme montré sur la photo ci-dessus). Nous réalisons les commandes aux deux bras pour choisir par la suite quel bras nous souhaitons copier. Ces calculs doivent également adaptés pour compenser le manque d'un degré de liberté au niveau de l'épaule du bras robot ainsi que les conditions de singularité du système.

Transmission des données

Par rapport au semestre dernier, nous avons amélioré la qualité de transmission du flux vidéo, car devenait trop instable lorsque nous envoyions 2 flux en même temps. Pour ce faire, nous avons retravaillé nos programmes Python pour effectuer des tâches en multicœur sur l'ordinateur. Cela a notamment permis une stabilisation du débit et surtout des pertes de paquets bien moins importants. Un exemple d'image obtenue à la réception est le suivant :

Nous avons une image nette, cependant si les milieus où se déroulent les transmissions sont sujets à des interférences ou au contraire, atténuent les signaux reçus, alors des pertes plus importantes peuvent être observés.

De plus, nous avons pu mettre en place la transmission des commandes du bras robot en parallèle de la réception du flux vidéo. Celle-ci se fait en TCP/IP, notamment car il s'agit d'informations cruciales à transmettre. En cas de demande d'arrêt d'urgence, il faut absolument que le bras robot reçoive la consigne pour des raisons de sécurité.

Ensuite, pour des raisons de simplification d'utilisation, nous avons rajouter une fonction permettant de retrouver automatiquement le client pour le serveur et le serveur pour le client. Puis, par rapport au semestre dernier, nous avons fait en sorte de pouvoir lancer les programmes dans n'importe quel ordre, alors qu'avant, il fallait lancer le serveur avant le client.

Affichage dans le casque de réalité virtuelle

Pour mieux répondre à nos attentes, nous avons finalement développer une application avec Unity au semestre 8. Pour rappel il fallait implémenter un moyen pour transmettre l'image jusqu'au casque en 3D.

La 3D s'effectue en affichant 2 vidéos différentes provenant de 2 caméras légèrement décalées pour chaque yeux.

On utilise comme sur Python la librairie socket pour recevoir les paquets vidéos

Enfin il reste à convertir les paquets de données en texture affichable sur des objets avec Unity.

On obtient finalement bien un flux vidéos mais nous avons une réduction importante du débit. Ce problème peut s'expliquer par le fait que nos tests ont été réalisés en utilisant l’outil debug sans exécuter le programme entièrement sur le casque. Il faudrait, pour améliorer les performances, compiler et installer l’application sur le casque. Ceci est très coûteux en temps pour les tests. Cependant, nous pouvons considérer cette partie comme étant fonctionnelle à des fins de démonstration de notre projet.

Gestion de projet

Lors des premières séances de travail, nous avons décidé de répartir les rôles pour la création du système complet. Ainsi, chacun des membres est responsable d'une partie décrite précédemment. Cette organisation a changé au semestre 8 suite à l'avancée plus rapide de certaines tâches. Vous pouvez trouver la répartition que nous avons utilisé sur les semestres 7 et 8 :

• Julien CHARLEUX, Karl HABRE : mise en place de la partie transmission des données et de l'affichage dans le casque VR
• Thomas LEFRANC : création du nouveau bras et implémentation de la reconnaissance d'images
• Tanguy RIDREMONT : création de la commande du bras (Niryo NED), implémentation de la reconnaissance d'images et de l'extraction des commandes

Cette méthode de travail permet à chacun des membres de se concentrer entièrement sur sa partie. De plus, comme nous travaillons dans la même salle, nous échangeons souvent afin d'adapter notre travail selon l'avancement de chacun.

GANTT prévisionnel du semestre 6 :

Cette version du diagramme de GANTT a été réalisé au semestre 6 lors de l'étude du projet donc avant toutes réalisations physiques. En foncé, il s'agit du temps incompressible alloué à chaque tâche. En clair, il s'agit des créneaux horaires sur lesquels chaque tâche peut déborder. Cette convention sera gardée pour chaque diagramme réalisé plus tard.

GANTT prévisionnel du semestre 7

Ce diagramme de GANTT montre l'organisation adoptée pour le semestre 7 et celui a adopté pour le semestre 8. Les parties en bleues sont réservées pour assurer le fonctionnement du système et faire les derniers réglages. Nous avons appliqué beaucoup de modification par rapport à celui établi au semestre précédent. Ces modifications sont liées directement à la répartition des tâches que nous avons choisies. Comme nous avions mieux définis le projet à ce moment, nous pouvions mieux définir ce qu'il restait à faire.

GANTT réel du semestre 8

Nous avons appris de nos erreurs des semestres précédents et voyons que le diagramme réel du semestre 8 est proche du diagramme prévisionnel au semestre 7. La création du nouveau bras impose cependant une nouvelle répartition des tâches. Comme la commande du bras Niryo se termina plus rapidement, nous avons modifié la répartition sur la partie intelligence artificielle pendant le semestre pour avancer sur la création de ce nouveau bras. Les deux semaines gardées pour les tests ont finalement été utilisées pour la création du système afin d’assurer un système fonctionnel.

Compte-rendu 18/01/2023

Avancement cette semaine :

• Recherche d’alternatives à Vizard pour la communication avec le casque de réalité virtuelle
• Exploration de nombreuses librairies sur git, mais aucune de fonctionnelle avec notre casque
• Téléchargement et découverte de Unity permettant de développer une application pour le casque
• Communication entre Unity et Python via l’ouverture d’un socket en 127.0.0.1 (c’est à dire en interne de l’ordinateur)
• Création d’un API implémentant des PIDs
• Utilisation d’un nouveau mode de commande du bras
• Construction d’un support pour les 2 caméras afin d’avoir un grand angle
• Mesure, découpe, perçage, ponçage, rigidification, tests

Points à développer la semaine prochaine :

• Mettre la solution unity + python en pratique sur le casque
• Voir comment installer un APK sur le casque (adb debugging)
• Mise en place de la communication entre unity et notre programme python
• Manque des rallonges usb pour le support de caméras
• Adaptation des algorithmes à la structure construite
• Changer les structures de données du programme de commande du bras

Equipements

Liste des équipements demandés

• Bras robotisé Niryo Ned + alimentation + câble Ethernet (reçu)

• Raspberry Pi 3 1.2B + câble micro USB (reçu)

• Raspberry PI 4 (reçu ×2)

• Routeur WiFi TP-Link (reçu)

• Caméra 3D (à disposition)

• Casque VR HTC Vive Pro (à disposition)

• 2x Rallonge USB (male-femelle)

• 1 câble USB male vers Ethernet RJ45 femelle

Mode d'emploi

Système de démonstration du bras

Pour commencer, il faut assembler les parties physiques du projet avant de démarrer la partie logicielle.

Étape 1 : Assemblez le support des caméras permettant de garder un angle fixe entre les deux. Pour ce faire, suivez les schémas ci-dessous :

Chaque élément est marqué soit par “cam1” soit par “cam2”. Fixez chaque élément marqué “cam1” ensemble selon les instructions ci-dessus et “cam2” ensemble également.

Étape 2 : Connectez ensuite les câbles USB des webcams fixées sur le support à des ports USB de la machine, qui sera destinée à exécuter le programme de démonstration. Le code de “Camera_correlation.py” devra être ajusté en fonction des ports sur lesquels sont connectées les caméras sur votre ordinateur. Ainsi en fonction de votre machine, vous devrez changer les numéros mis aux lignes 218 et 219. La caméra portant l’inscription “cam1” doit être ouverte à la ligne 218. La caméra portant l’inscription “cam2” doit être ouverte à la ligne 219. Attention les numéros utilisés sur ces deux lignes ne peuvent pas être identiques.

Étape 3 : Une fois les étapes précédentes réalisées, vous devez connecter le bras Niryo NED à la machine. Pour ce faire, vous disposez de plusieurs options.

Étape 3.1 : Pour la connexion sans fil, activez le WiFi de votre machine et connectez-vous au réseau WiFi créé par le bras. Le nom du réseau WiFi est du type “NiryoRobot *”. Le mot de passe dépend de votre configuration. Pour plus de renseignements, consultez le site du constructeur.

Étape 3.2 : Pour la connexion en Ethernet, il suffit de connecter un câble RJ45 entre le bras et la machine :

Vous pouvez maintenant passer au démarrage des applications nécessaires au fonctionnement du projet BraVeD.

La démonstration du logiciel a été développée sur Windows 11. Pour démarrer le programme ouvrez cinq instances de PowerShell ou de Terminal et suivez les instructions suivantes. Vérifiez bien que votre instance PowerShell ou Terminal soit bien localisée dans le dossier où se situent les fichiers d’exécution.

Étape 4 : Lancez le programme de transfert des données dans une instance PowerShell avec cette commande :

Une fois la commande exécutée vous devriez voir affiché le logo du projet ainsi qu’un message d’attente :

Étape 5 : Allez dans une seconde instance de PowerShell et exécutez la commande suivante pour lancer le programme de reconnaissance d’images :

Le logo du projet s’affiche pour le démarrage de chaque programme. Ainsi vous aurez un message vous demandant si vous voulez afficher les flux vidéo des caméras :

Tapez Y pour oui et N pour non. Une fois fait, si le programme n’affiche rien sur le terminal alors le programme s’est correctement lancé. Si le programme affiche “Ignoring empty camera frame” alors il ne s’est pas exécuté correctement.

Étape 6 : Dans les deux cas, retournez sur l’instance du terminal exécutant “Data_traitment”. Vous voyez à présent le message suivant :

Étape 6.1 : Si vous saisissez Y et que le programme vous affiche le message suivant, passez à l’étape suivante :

Étape 6.2 : Si vous saisissez N, annulez l’exécution de “Camera_correlation” en appuyant sur Ctrl+C et recommencez l’étape 5 jusqu’à la bonne exécution du programme.

Étape 6.3 : Si le programme “Camera_correlation” continue à ne pas fonctionner correctement, retournez à l’étape 2 en vérifiant les ports de connexions puis si le problème persiste, testez différents chiffres aux lignes 218 et 219.

Étape 7 : Le programme “Data_traitment” vous demande maintenant d’exécuter un des programmes d’IHM appelé “Debug_GUI”. Exécutez cette commande dans un nouveau terminal :

Si l’exécution se passe correctement, une fenêtre devrait s’ouvrir et le programme “Data_traitment” affichera un message :

Étape 7.1 : Si l’application ne s’affiche pas mais que “Data_traitment” affiche ce message, vous devrez reprendre à l’étape 4. Vous pouvez, si vous le souhaitez, continuer les étapes suivantes mais le programme s’arrêtera automatiquement après la dernière étape.

Étape 7.2 : Si l’application démarre mais que le programme n’affiche pas le message de confirmation de connexion, appuyez sur STOP pour quitter l’application et recommencez l’étape 4.

Étape 8 : Vous devez maintenant lancer le programme “Arm_kinematic”. Pour ce faire, exécutez la commande suivante dans une nouvelle instance de PowerShell :

Si l’exécution s’est bien déroulée, une fenêtre devrait s’ouvrir et le programme “Data_traitment” doit vous afficher un message de confirmation :

Étape 8.1 : Si la fenêtre ne s’affiche pas mais que “Data_traitment” affiche ce message, vous devrez reprendre à l’étape 4. Si vous le souhaitez, vous pouvez continuer les étapes suivantes mais le programme s’arrêtera automatiquement après la dernière étape.

Étape 8.2 : Si la fenêtre démarre mais que le programme n’affiche pas le message de confirmation de connexion. Arrêtez l’exécution de “Arm_kinematic” avec Ctrl+C et recommencez l’étape 8.

Étape 9 : Vous pouvez maintenant exécuter le programme de contrôle du bras en tapant cette commande dans un terminal :

Si le programme s’exécute correctement, le programme “Data_traitment” devrait afficher le message de confirmation suivant :

Étape 9.1 : Si ce message ne s’affiche pas, arrêtez le programme “Robot_Movement” avec Ctrl+C. Vous pouvez revenir ensuite à l’étape 9.

Étape 9.2 : Si le message est affiché mais que “Robot_Movement” ne demande aucune autre instruction, alors vous devez reprendre l’exécution depuis l’étape 4 en fermant tous les programmes précédemment exécutés.

Étape 10 : Une fois la commande exécutée et que “Data_traitment” affiche la confirmation de connexion, vous devez indiquer la méthode de connexion au bras Niryo NED :

• Si vous avez connecté le bras par WiFi avec la machine exécutant les programmes, veuillez saisir “wifi”

• Si vous êtes connecté en Ethernet avec un câble RJ45, veuillez saisir “ethernet”

• Si votre bras Niryo NED possède une adresse de connexion différente de celle par défaut donnée par le constructeur, veuillez appuyer sur “Entrée”. Vous pourrez ensuite renseigner l’adresse IP du robot que vous avez définie :

Vous pouvez à présent utiliser le projet BraVeD dans son intégralité. Pour tout autre problème de synchronisation des programmes ou de connexions, tuez les processus liés aux programmes lancés, fermez les terminaux ouverts et recommencez à partir l’étape 4.

Transmission des données et affichage dans le casque

Cette partie se découpe en deux grandes étapes qui peuvent varier en fonction du système d'exploitation.

Si les deux ordinateurs sont sous Windows :

Téléchargez le logiciel libre Hamachi à partir du lien suivant : vpn.net. Si vous n'avez pas déjà de compte LogMeIn, vous devez vous en créer un.

Après avoir téléchargé Hamachi, vous devez vous créer votre propre réseau virtuel privé si ce n'est pas déjà fait dans l'onglet 'Réseau->Créer'. Vous arriverez alors sur la page suivante :

Prenez bien en note le mot de passe et l'identifiant. Ensuite il faut rejoindre ce réseau à partir de l'ordinateur côté Homme et de celui côté machine à partir de l'onglet 'Réseau->Rejoindre'. Entrez l'identifiant et le mot de passe créés au préalable.

Attention, il ne peut pas y avoir plus de deux utilisateurs sur un même réseau, sinon le logiciel devient payant.

Si un des ordinateurs est sous Linux :

Téléchargez le logiciel libre ZeroTier à partir du lien suivant : zerotier.com/download. Si vous n'avez pas déjà de compte ZeroTier, vous devez vous en créer un.

Une fois que c'est fait, il faut configurer un réseau virtuel privé à partir de leur site.

Après avoir téléchargé ZeroTier, il faut rejoindre le réseau à partir de l'ordinateur côté Homme et de celui côté machine. Attention, y a une limite de 25 utilisateurs et un administrateur sur un même réseau, sinon le logiciel devient payant.

Mise en place du retour pour le casque :

Il faut installer manuellement l'application que l'on a développer et la lancer, une fois que le flux vidéo sera recu par l'ordinateur communiquant avec le casque, le flux devrait s'afficher dans le casque. Sinon il est possible de lancer l'application sans avoir à la lancer depuis Unity en mode debug.

Mise en place de la communication :

Il suffit d'exécuter dans un terminal le programme Python 'client.py' du côté Homme et 'serveur.py' du côté machine. Normalement tout se fait automatiquement, cependant il se peut que certaines librairies soient manquantes lors de la première exécution, notamment 'netifaces2', 'opencv-python' et 'numpy'. Vous pourrez les récupérer avec la commande 'pip install <nom_de_la_librairie>', en remplaçant <nom_de_la_librairie> par le nom de la librairie souhaitée.

Dans le casque VR, il faut exécuter le logiciel compilé de Unity pour le casque voulu. Enfilez le casque et vous serez transporté vers le bras robot.