Le projet de localisation des robots Nao a été réalisé par Mathieu GARDIN, apprenti en DUT Génie Electrique et Informatique Industrielle auprès de Endress-Hauser Flowtec AG.
Introduction
Les robots Nao sont une avancée innovante dans la robotique. Grâce à sa panoplie de capteurs et d’articulations mécaniques, il se rapproche des fonctionnalités de l’être humain. On y retrouve entre autre un moyen vocal de répondre à des injonctions, des capteurs pour pouvoir entendre la voix, une fonction « visuelle » pour observer son environnement à l’aide de caméras ainsi que des capteurs permettant aux Naos de marcher. La majorité des fonctionnalités du Nao le destinent à une interaction avec son environnement extérieur. Cependant, à l’heure actuelle, aucun système n’existe pour pouvoir créer une fonction de géo-localisation dans cet environnement. A travers cette présentation, nous allons chercher à développer cette fonctionnalité et ainsi élargir les possibilités du Nao.
Présentation du Sujet
Pouvoir localiser un Nao lors de ces déplacements dans une pièce, tels a été le projet qui nous a été confié par Mr CUDEL. L’intérêt de ce projet résidait de pouvoir localiser à l’aide d’une interface graphique doublé par un serveur de base de données. L’objectif est que le Robot Nao puisse écrire dans la base de donnée et que l’interface graphique située dans un navigateur internet puisse effectuer une demande auprès de la base de donnée et se mettre à jour automatiquement.
Pour la réalisation du projet, on utilisera un raspberry pi 2 model b qui hébergera la base de donnée et sera connecté à l’aide d’une clée 3G sur le routeur pour communiquer avec le robot Nao
Organisation du Projet
La réalisation de ce projet a suivis un ordre précis:
Phase de concept :
Évaluation de la problématique actuelle et des solutions à mettre en place
Réflexion sur les langages de programmation à utiliser
Découverte et Apprentissage de l’utilisation des outils numériques (Raspberry pi 2 model b)
Analyse des fonctionnalités:
Création d’une base de donnée
Création d’une interface graphique
Création d’un moyen de communication entre Raspberry et Nao
Mise à jour automatique de l’interface graphique
Intégration des données spatio-temporel du Robot
Création de la partie design :
Réalisation d’un plan de la pièce
Intégration des balises sur l’environnement graphique
Intégration des fonctionnalités :
Mise en place de la base de donnée
Intégration de l’interface graphique au navigateur Web
Utilisation de la communication entre Robot et Raspberry
Phase de test:
Test des fonctionnalités
Correction des erreurs
Cahier des Charges
Base de donnée
La question de la base de donnée a surtout été conditionné par un choix technologique. MySQL ou SQlite. Dans un premier temps, il était prévu de partir sur une base de donnée en MySQL mais après quelques recherches, il a été montré que l’utilisation de SQlite économiserait les ressources du Raspberry
Interface / Gestion base de donnée
Pour pouvoir créer les bases de données et les organiser, le choix s’est porté sur l’interface Phpmyadmin. Un outil conçu en PHP permettant l’administration des bases de données. Travaillant sur un système Linux, il était plus facile d’utiliser cet outil que de passer par l’invite de commande.
Interface graphique
Pour la création du plan d’une salle de Tp, on a utilisé un logiciel d’architecture appelé Kozikaza, permettant de re-constituer la salle de travaux pratiques avec ces obstacles et ces dimensions
Langages de programmations
Concernant les langages de programmation, plusieurs solutions ont été proposés. On pouvait utiliser un langage python presque exclusivement ou se porter sur des langages de programmation de type Web => PHP, HTML, AJAX, et JAVASCRIPT.
L’objectif de ce projet étant de travailler sur une interface graphique Web, il a été décidé d’utiliser PHP, HTML, AJAX, et JAVASCRIPT
Communication
La communication entre le robot Nao et le Raspberry se fera à l’aide d’un protocole de type UDP. Le robot enverra sa position dans une chaîne de caractère qui sera ensuite traduit par une table de transcodage au niveau du raspberry
Développement
PHPmyadmin
L’utilisation de PHPmyadmin se fait en local sur le raspberry : 127.0.0.1
Sur les besoins de ce projet, il a été demandé 3 types de données:
La première se base sur quel robot Nao envoie les données
La deuxième concerne le jour et l’heure à laquelle les informations ont été envoyés
La troisième nous renseignera sur la position du robot, si il se trouve à la balise 1, 2, 3 ou 4. Ces « balises » seront placés à différents endroits dans la pièce
Dans notre cas, on pouvait créer les tables de données manuellement, une pour chaque information ou programmer en SQL la création automatique de ces tables (visible ci-dessous en rouge). Pour les besoins du test, il a été décidé de créer une auto-incrémentation des données comme détaillés dans le document ci-dessous en bleu.
La table Robot identifie quel Nao a envoyé l’information
La position correspond à quelle balise a été repéré le robot
La date elle nous indique donc la position temporelle du robot
Plan de la salle de travaux pratiques
Le design de l’interface graphique réalisé à l’aide du logiciel d’architecture prend en compte une partie du mobilier de la salle ainsi que ces dimensions.
Dans le cadre du projet, il a été intégré de manière très simple 4 balises numérotés de 1 à 4 avec des couleurs différentes représentant les positions du robot Nao comme montré dans l’image ci-dessous :
Programmation PHP / HTML
La programmation de l’interface graphique et de sa communication avec le raspberry s’est effectué avec code en PHP. Le principe est d’initier la communication en lui donnant les « username » et « password » de PHPmyadmin pour aller lire ce qui est écrit dans la base de donnée
Le reste de la programmation s’effectue en HTML pour pouvoir donner « vie » à l’interface graphique et implémenter les données sur la plate-forme Web
Perspectives / Difficultés rencontrées
Une des premières difficultés a été l’installation et la mise à jour des logiciels sur le raspberry. L’intégration de PHPmyAdmin et du langage SQL à l’aide de la console linux intégrée a montré des réticences et a entraîné une perte de temps importante. La communication UDP qui devait s’ajouter comme partie finale du projet n’a finalement pas pu être réalisée par un manque de temps et une adaptation du code difficile à mettre en œuvre à notre niveau.
Les perspectives si la communication UDP était correctement installée et que le traitement des informations en provenance du Robot Nao se réalisait sans conflit, permettrait une étude de la localisation du robot sur une plus grande échelle. On pourrait travailler sur le bâtiment B en entier et pas juste au niveau de la salle de travaux pratiques.
Par la suite, l’intérêt du projet deviendrait plus prononcé si le raspberry émettrait des ordres de déplacements aux robots Nao. La localisation avec les capteurs du robot permettrait de créer un système d’acquisition quand le Nao arrive à destination.
Enfin en dernier lieu, transformer cette plate-forme Web pour l’intégrer dans une application Android permettant une utilisation mobile du projet.
Bilan
Par ce projet, j’ai eu la plaisir de pouvoir travailler sur des langages de programmation qui m’était jusqu’à lors inconnu. J’ai pu acquérir des compétences de programmation en base de données (SQL), langages Web (Ajax, Jquery, HTML, PHP, Javascript et CSS). Ce défi de travailler dans d’autres langages de programmation était une source de difficultés en plus mais m’a permis de créer un défi personnel pour la réalisation de ce projet.
Il est vrai qu’à l’heure actuelle, la localisation du robot Nao s’arrête à une simulation avec la plate-forme Web et il est toujours décevant d’un point de vue personnel de ne pouvoir mener à 100% la réalisation d’un projet. Mais les bases ont été crées et fonctionnent sans erreur. Pouvoir améliorer ces bases et en faire la naissance de nouveaux projets pour de futurs réalisations justifie le besoin d’un tels projet et surtout son importance dans l’enseignement du GEII.
A ce titre, je tiens à remercier Mr Cudel d’avoir autorisé la réalisation de ce projet même en étant seul dessus. Cela m’a permis de réaliser ce projet personnel de travailler avec des outils Web et pouvoir appréhender le croisement entre Robotique et environnement Web.
Ce projet a été réalisé par Alexandre COLICCHIO et Loïc MONJOUSTE, élèves en DUT GEII par apprentissage (resp. Electro Ohms et PSA Peugeot-Citroën).
Introduction
La chaîne de production miniature Festo étudiée en Travaux Pratiques (TP) d’automatisme et de supervision permet de différencier, à chaque étape, les « bonnes » pièces (qui correspondent au gabarit prévu) des « mauvaises ». Cependant, aucun système automatisé n’est prévu pour retirer les « mauvaises » pièces de la chaîne. C’est pourquoi, il est nécessaire de créer un tel système.
Présentation du Sujet
Alors qu’un bras robotisé (actuellement fictif et non étudié dans le projet) retire les pièces imparfaites de la station Festo du palpeur (cf. Fig.1) pour les poser dans un stock, un second robot (suiveur de ligne) aura pour tâche de récupérer, une à une, chaque pièce afin de les entreposer dans un nouveau stock en début de ligne. Un autre bras robotisé (non étudié) pourra récupérer la pièce et la réintroduire en début de chaîne sur la station de distribution (cf. Fig.2).
Cahier des Charges
Les fonctions du stock de pièces :
Gérer le stock :
Image :
Cette carte ne gère que la partie liée au stock en milieu de chaîne. C’est elle qui fait le lien entre le détecteur de présence pièce et l’émetteur FM.
Choix :
Arduino est une marque fiable pour les circuits électroniques programmables. Les produits proposés sont à des prix abordables pour de petits projets. De plus, les constructeurs revendiquent la liberté de droits de leurs produits. Il n’est donc pas difficile de trouver de l’aide pour la programmation. Pour cette fonction (gérer le stock), les besoins en nombre d’entrées et de sorties étant faible (1 entrée et 1 sortie numériques), le petit modèle (14 E/S numériques) est suffisant pour apporter la gestion nécessaire.
Détecter les pièces à déplacer :
Image :
Le stock est équipé d’un capteur fin de course normalement ouvert afin de détecter la présence de pièce(s) en attente. Au moment où une pièce appuie sur le capteur, celui-ci se ferme et laisse alors passer la tension d’alimentation de cinq volts jusqu’à la carte de gestion du stock.
Choix :
Les capteurs à fin de course sont les plus basiques capteurs de présence d’obstacle. Ainsi, les prix sont extrêmement faibles alors que leur fiabilité est prouvée. En outre, il est possible de choisir le mode de fonctionnement (Normalement Ouvert ou Normalement Fermé).
Communiquer avec le robot :
Image :
Le stock en milieu de ligne possède une station FM (Modulation de Fréquence) émettrice. A partir de l’information de la fonction de détection de pièce à déplacer, le transmetteur envoie un signal binaire modulé en 2FSK (2 Frequencies Shift Keying) à la station FM réceptrice se trouvant sur le robot. Lorsque le robot reçoit un « 1 » logique, la carte de gestion du robot interprète cette information et débute le mouvement en direction du stock en milieu de ligne.
Choix :
Le robot doit recevoir une information à propos de l’état du stock. La première solution serait de relier le robot au stock à l’aide d’un câble. Cependant, bien que ce soit le moyen le moins onéreux, la connexion filaire implique énormément d’encombrement pour le robot : enroulement, écrasement du câble, etc. Il faut donc trouver une technologie sans fil et à des prix convenables. La modulation de fréquence est un bon choix puisque la transmission est protégée du bruit environnant sur la faible distance à parcourir. Par ailleurs, le signal à transmettre étant numérique, les changements d’état peuvent être extrêmement rapide, ce que la modulation de fréquence peut gérer.
Les fonctions du robot :
Gérer les entrées et sorties du robot :
Images :
C’est le cerveau du robot. En effet, la carte Arduino contient la gestion complète des actions que doit entreprendre le robot en fonction des différents paramètres qu’il reçoit grâce aux capteurs. L’avantage de Arduino est que le logiciel est Open Source et facile d’utilisation. Ainsi, des millions de personnes partagent leurs programmes et idées afin d’aider les utilisateurs à traiter des fonctions. De plus, la carte est adaptative à divers systèmes. Dans notre cas, l’alimentation et le contrôle des moteurs de roues se font à partir d’un module moteur connecté à la carte.
Choix :
De même que la carte de gestion de stock, la carte choisie est de marque Arduino. On lui ajoute un module moteur (Motor Shield) afin de pouvoir y connecter et gérer les moteurs. Cette fois-ci, nous disposons d’un plus large panel d’entrées et sorties puisqu’il y a plus de périphériques à contrôler.
Communiquer avec le stock :
Image :
Le robot doit recevoir l’information en provenance du stock pour démarrer son cycle de fonctionnement. Il est alors nécessaire de se doter d’un récepteur FM.
Choix :
Il est nécessaire de choisir un récepteur en FM configuré à la même fréquence que l’émetteur. Ensuite, selon le codage de l’information par le transmetteur, le récepteur doit pouvoir comprendre et décoder cette information.
Se déplacer :
Images :
Un système à trois points de contact au sol a été choisi avec l’utilisation de deux roues motrices et d’une bille libre. Cette dernière permet au robot de rester en équilibre. Les rotations sont effectuées à l’aide des roues motrices : une roue est à l’arrêt pendant que la seconde continue son mouvement. Les roues sont entraînées par des moteurs asynchrones.
Choix :
Les moteurs ont été récupérés sur un ancien robot, ce qui rend parfait le côté financier du déplacement du robot. De plus, la puissance est correcte par rapport au poids du robot (non négligeable).
Détecter la ligne :
Image :
Les deux phototransistors à l’avant du robot permettent de détecter la ligne noire que le robot doit suivre. Selon le contraste de la surface observée, les phototransistors envoient une information numérique à la carte de gestion.
Choix :
Différentes technologies permettent de détecter une ligne (capteur de couleur, capteur à ultrason, etc.). La ligne étant sombre et la surface autour claire, un capteur de contraste permet de différencier la ligne du sol à moindre prix. L’inconvénient est que le capteur est très sensible à la luminosité extérieure. Il faut donc isoler les capteurs de l’environnement parasite.
Détecter le stock :
Image :
Le robot ne doit en aucun cas entrer en collision avec la structure du stock. C’est pourquoi, il est nécessaire de mesurer la distance séparant le robot du stock jusqu’à ce qu’il se trouve à la place prévue.
Choix :
Il existe plusieurs technologies pour mesurer des distances, mais son (émetteur à ultrasons) cône de détection est plus grand, ce qui est utile lorsque les capteurs ne sont pas directement en face de l’obstacle à mesurer. De plus, son prix est convenable et sa détection par rapport à une surface connue reste fiable selon l’inclinaison. Enfin, la distance maximale est d’environ 2,5 mètres. Cette distance est très largement suffisante puisqu’on ne travaille que sur 5 centimètres maximum.
Récupérer la pièce :
Images :
Une pince placée à l’avant du robot permet de prendre la pièce et la garder entre ses deux « doigts » le temps du trajet jusqu’au stock en début de ligne. Un capteur de fin de course est présent au fond de la cavité de la pince afin de s’assurer de la présence de la pièce attrapée.
Choix :
La pince a été créée par impression 3D à partir d’un modèle sous SolidWorks. Son coût de fabrication est dérisoire et les modifications à y apporter peuvent être faites facilement. En outre, la résistance du matériau rigide reste suffisante pour maintenir une pièce. Le servomoteur est directement adapté à la commande par carte Arduino et fonctionne en pas à pas. Le degré de liberté est de 180°, ce qui est suffisant pour commander la pince à l’ouverture complète et à la fermeture.
Etude des fonctions
Détecter les pièces à déplacer :
Le stock est un tube vertical ouvert à sa base (cf. Fig. 3). Ainsi, les pièces déposées, par la force d’attraction gravitationnelle, se placent directement à la sortie du stock. Le capteur fin de course, déclenché par l’appui de la pièce, est placé à la sortie. Câblé en normalement fermé, le capteur n’envoie aucune tension tant qu’il n’est pas activé. A l’activation, le capteur est ouvert : la tension d’alimentation est directement reliée à l’entrée de la carte de gestion du stock à une résistance de tirage près (cf. Fig. 4).
Communiquer avec le robot :
L’information de présence de pièce reçue, la carte de gestion ne retient que le front montant de ce signal pour mettre à jour le signal numérique de sortie. La carte de gestion du stock envoie la lettre « a » (16#97) au robot afin de palier à tout problème de perturbations parasites. Ainsi, le code hexadécimal de « a » aura moins de chance d’apparaître par du bruit qu’un simple état logique haut. Le transmetteur module en fréquence (434MHz) les états logiques. Ainsi, un état bas aura une fréquence de modulation f0 alors que l’état haut sera modulé à une fréquence f1 (cf. Fig.6). L’antenne a été dimensionnée de façon à ne pas avoir de retour d’onde qui pourrait dégrader l’émetteur. Le calcul de la longueur de l’antenne se porte sur un cas de moitié d’onde (cf. Fig.7).
Communiquer avec le stock :
A ce moment, le récepteur FM placé sur le robot reconnaît la fréquence d’émission de 434MHz et la décode. On mesure, sur la patte de sortie numérique, les états haut et bas qui ont été émis (cf. Fig.8). Nous apercevons, cependant un problème d’impulsions indésirables en début de réception (cf. Fig.9). Ce problème peut facilement se résoudre à l’aide d’un filtre analogique passe-bas composé d’une résistance et d’un condensateur (cf. Fig.10). Les signaux reçus pendant le fonctionnement réel du robot sont sur une grande période (environ 1 seconde), donc les hautes fréquences peuvent être atténuées sans porter atteinte aux fonctionnalités utilisées. On remarque qu’en moyenne, la période d’une impulsion intempestive est d’environ 12,5ms. On en déduit une fréquence de 80Hz. On peut alors trouver les valeurs de R et C afin de lisser ces impulsions (cf. Fig. 11).
Se déplacer :
Les moteurs sont alimentés par une batterie externe de 15 volts et connectés sur le module moteur de la carte de gestion du robot. La carte envoie l’information aux moteurs du sens de rotation et de la vitesse souhaitée selon la situation du robot. En effet, la carte Arduino (via le Motor Shield) envoie une valeur analogique (PWM) qui gère l’intensité reçue par les moteurs.
Détecter la ligne :
Les capteurs de contraste sont composés d’une LED (lumière invisible à l’oeil nu) et d’un phototransistor. Selon la réflexion de la lumière provenant de leur LED, la valeur numérique en sortie des capteurs est plus ou moins élevée. Sur une surface claire, les phototransistors renvoient une valeur faible (entre 0 et 100) alors que la valeur augmente lorsque le contraste est plus sombre (aux alentours des 800). Connectés à la carte de gestion, le robot « sait » s’il tente de franchir la ligne ou s’il est sur la bonne voie. Les capteurs sont très proches de la surface à observer puisque leur portée est de 3mm. En outre, deux LEDs blanches ont été ajoutées (cf. Fig.12) afin d’éclairer la surface et réduire les erreurs de contraste dues à l’ombre provoquée par la faible distance des capteurs par rapport au sol. Le bâti du robot joue un grand rôle dans cette ombre puisque le but est d’isoler au maximum le système des capteurs de la lumière ambiante (cf. Fig.13).
Détecter le stock :
Arrivé près du stock, le robot n’est pas forcément aligné pour récupérer la pièce selon la trajectoire qu’il a utilisé pour l’atteindre. Il faut donc mesurer la distance entre le robot et le stock en deux points (la gauche et la droite du bâti du robot). Plus les capteurs sont éloignés et plus précis sera le parallélisme entre le stock et le robot. Chacun de ces capteurs sont composés d’un émetteur et d’un récepteur. L’émetteur envoie une onde d’environ 40 kHz qui, réfléchie sur la surface à mesurer, est captée par le récepteur. Le temps du trajet de l’onde définit la distance (cf. Fig.14).
Récupérer la pièce :
Correctement aligné devant le stock, le robot attrape la pièce à l’aide de la pince. En effet, le servomoteur relié à l’un des doigts entraîne le second doigt à l’aide d’un engrenage situé à la base des doigts de la pince. Celle-ci est composée de caoutchouc sur les bords des doigts afin d’augmenter l’adhérence de la pince et ainsi maintenir la pièce en place. Ensuite, un capteur fin de course est également positionné sur le fond de la pince dans le but de connaître la présence de la pièce au sein de la pince.
Ce que le robot devrait faire
Initialement, les stocks en milieu et début de ligne sont vides. Le robot est installé sur sa position de départ (le stock de départ se trouvant sur sa droite), perpendiculairement à la ligne à suivre (cf. Fig.15). Au moment de la détection de la présence d’une pièce dans le stock en milieu de chaîne, le robot reçoit l’information et débute un déplacement en avant. Les capteurs de contraste passent alors sur la ligne noire (les deux à la fois, comme sur la Fig.16). Le robot entame alors une rotation sur la droite jusqu’à ce qu’un des capteurs ne détecte plus la ligne. C’est alors que la phase de suivi de ligne débute (cf. Fig.17).
A chaque fois que le robot tente de franchir la ligne par inadvertance, il se repositionne correctement, de sorte qu’il se recentre sur la ligne (cf. Fig.18). Une bande noire, mise en perpendiculaire de la ligne à suivre est le signal d’approche du stock où sont entreposées les pièces à déplacer. En effet, le programme de suivi de ligne s’arrête une fois la bande détectée par les deux phototransistors à la fois. Le robot s’arrête dans sa position (cf. Fig.19).
A l’aide de ses capteurs à ultrason, le robot mesure la distance qu’il a de chacun de ses côtés par rapport au stock. Si l’une des valeurs de distance est différente de l’autre, le robot pivote de sorte que les valeurs des deux capteurs s’égalisent (cf. Fig.22). Il entame ensuite un léger mouvement en avant jusqu’à atteindre une valeur nulle sur ses capteurs de distance. Pendant ce même temps, la pince s’ouvre à son maximum afin d’avoir la pièce entre ses doigts une fois arrivé contre le stock (cf. Fig.21). Lorsque le robot est contre le stock, la pièce est complètement à l’intérieur de la pince, le fin de course placé au fond de la pince est déclenché. Ainsi, le robot referme les doigts afin de maintenir la pièce (cf. Fig.22).
Il entame ensuite un déplacement arrière jusqu’à ce qu’il ne détecte plus la bande noire posée sur la ligne à suivre (cf. Fig.23). A ce stade, le robot entame une rotation sur 180 degrés afin de se repositionner sur la ligne a suivre et le programme de suivi de ligne débute (cf. Fig.26). Le robot répète les mêmes mouvements que précédemment, jusqu’à arriver au stock de dépose de la pièce (cf. Fig.25).
Arrivé, il ouvre la pince, la pièce tombe et atterrit directement dans un petit logement prévu à cet effet. Comme pour le stock précédent, le robot recule, ne détecte plus la bande noire et entame un demi-tour sur lui-même. C’est la fin du cycle pour le robot : il doit recevoir une nouvelle information de présence pièce avant de chercher la suivante (cf. Fig.26).
Ce que le robot fait réellement
En position de départ, le robot est en attente de l’information d’une présence pièce. On appuie alors sur le capteur fin de course pour envoyer la trame correspondante au robot. Ce dernier comprend l’information et s’avance jusqu’à la ligne. Il entame alors une rotation de 90 degrés vers la droite sur lui-même puis suit la ligne jusqu’à la bande noire devant le stock. Il est ensuite capable de faire marche arrière jusqu’à ne plus capter la bande et à faire un demi-tour pour se diriger vers le stock en début de chaîne. De même, une fois arrivé, il entame une marche arrière et un demi-tour, pour enfin s’arrêter et attendre une seconde information de présence pièce afin d’entamer un second cycle.
Conclusion
Bien que nous ne soyons pas arrivé au terme des objectifs fixés, nous en avons appris énormément aussi bien sur le plan organisationnel que sur le plan technique. En effet, le projet nous a apporté une grande expérience sur le métier de concepteur de nouveaux systèmes. Nous ne souhaitions pas simplement appliquer les diverses connaissances acquises pendant les deux années en GEII, mais en obtenir de nouvelles. Cet objectif est rempli puisque nous savons désormais programmer une carte Arduino et utiliser les capteurs mis en place. En effet, de nos erreurs nous avons su tirer les leçons dans le but de les comprendre et de ne plus les commettre.
Perspectives
Ce projet, une fois achevé, pourrait par la suite être dupliqué et utilisé sur les différentes stations Festo afin de rapporter les pièces en début de chaîne. Ainsi, la chaîne serait entièrement autonome et pourrait fonctionner sans arrêt (sauf en cas de défauts). Par ailleurs, le coût de production de ce système est dérisoire, ce qui le rend particulièrement abordable quelle que soit l’organisme souhaitant se le procurer.
Nous sommes deux étudiants en 2e année de DUT génie électrique et informatique industrielle à Mulhouse, Alexis ROSENKRANZ et Anthony WELTER. Au début de la deuxième année, nous avions à choisir un projet à réaliser durant celle-ci. Après quelque temps de réflexion, nous avons choisi de réaliser un bras robotisé, projet que notre professeur accepta.
L’idée de réaliser un bras robotisé est pour nous un rêve d’enfant qui se concrétise…
Présentation du Sujet :
Piloter directement les moteurs n’a pas été notre premier but dans ce projet. Nous avions surtout l’envie de pouvoir piloter ce bras robotisé à l’aide de coordonnées cartésiennes, c’est à dire selon des axes que l’on nommera X, Y et Z.
Des calculs seront donc nécessaires dans le programme afin d’affecter les angles des moteurs de chaque axe à leur position pour que l’outil du robot soit à la position demandée dans le repère cartésien.
Imaginez que l’on veuille tracer une ligne, il sera donc nécessaire de calculer une multitude de points très proches puis d’affecter les moteurs à l’angle calculé pour chacun des points.
Il faut donc bien comprendre que pour réaliser un mouvement linéaire avec un bras robotisé, tous les axes devront bouger en même temps.
Si on veut rajouter une pince au bout d’un bras robotisé 3 axes, la pince restera fixe et l’on ne pourra pas choisir l’angle qu’elle aura par rapport au sol. C’est pour ces raisons que nous avons décidé de rajouter deux autres axes. L’un, pour que la pince soit toujours perpendiculaire par rapport au sol quelque soit l’inclinaison du bras. L’autre axe, pour que la pince puisse réaliser une rotation sur elle-même, c’est-à-dire pour qu’on puisse attraper un objet face à elle-même et à 90 degrés.
Maintenant vous comprenez pourquoi notre bras robotisé est composé de 5 axes alors que l’on précise que uniquement 4 axes sont réellement pilotables.
Problématique :
La problématique qui se pose est donc :
Comment pouvoir gérer en données cartésiennes un bras robotisé 4 axes ?
Cahier des Charges :
– Réaliser un bras robotisé 5 axes dont 4 réellement pilotables
– Celui-ci devra pouvoir être pilotable dans un repère cartésien avec des déplacements linéaires
– La partie commande sera réalisée sur une carte type Arduino
– Le robot devrait pouvoir évoluer dans une demie sphère de 300 mm de rayon et prendre en compte les zones interdites
– La précision au bout du bras devrait être au moins de 4 mm
– Les coordonnées de position du robot devront pouvoir être entrées à l’aide d’un clavier
– Le robot devrait également être pilotable à l’aide d’une télécommande comportant 2 joysticks selon deux modes : angulaire ou linéaire.
– La position réelle du robot ainsi que les coordonnées tapées au clavier seront affichées sur un écran LCD.
– Les déplacements devront se faire en suivant une courbe d’accélération et de décélération.
– Le robot devra pouvoir se déplacer avec une charge d’au moins 200g dans sa pince.
– Le robot devrait comporter un bouton d’arrêt d’urgence de type coup de point.
Étude :
Nous avons commencé par vérifier si notre projet était réalisable à notre échelle. Pour ceci, nous devions réaliser plusieurs études notamment la manière à affecter la valeur à tous les angles en fonction des coordonnées cartésiennes. Nous avons principalement utilisé le théorème de Pythagore et le rapport entre le cosinus, les angles et l’hypoténuse afin de réaliser la conversion entre la position et les angles.
Exemple : pour calculer l’angle A (celui de la rotation de la tourelle), on utilise les coordonnées X et Y afin de calculer l’hypoténuse. Dans ce cas, l’hypoténuse correspond à la distance entre le bout de la pince et la base du robot. A partir de cet hypoténuse, on réalise le calcul suivant : cos-1 (X/hypoténuse). On obtient l’angle A.
C’est le même principe pour trouver les angles B (épaule du robot) et C (coude du robot). Il suffit de calculer la deuxième hypoténuse qui prend cette fois ci l’axe Z en compte. Avec cette hypoténuse 2 et les valeurs XYZ on peut retrouver les angles B et C. À l’aide des angles B et C, on peut retrouver l’ angle D afin que la pince soit toujours perpendiculaire au sol. L’angle E est la rotation de la pince sur elle-même et est égal à l’angle A, afin que la pince soit toujours face à nous quelque soit la rotation bras.
Une fois que nous savions comment trouver chaque angle en fonction des coordonnées cartésiennes, il fallait que l’on choisisse correctement tous les matériaux et le matériel que nous allions utiliser afin de réaliser le bras.
Pour la partie commande, nous voulions utiliser un microcontrôleur de la marque Arduino pour plusieurs raisons. La première étant le budget. Un Arduino en moyenne coûte 30 €. De plus, il possède une puissance de calcul suffisante ainsi qu’un grand nombre d’entrées/sorties. Nous avons choisi l’Arduino mega car :
– Il possède 54 entrées-sorties
– 16 entrées analogiques
– Un processeur 8 bits
– Une fréquence d’horloge de 16 MHz
– Alimenter en 12 volts, elle génère un 5 V et un 3 volts à l’aide de son régulateur interne
Pour la partie puissance, nous avons choisi d’utiliser des drivers de moteur pas à pas. On envoie dans ces drivers un signal carré ainsi qu’une entrée booléenne pour le sens. C’est-à-dire qu’à chaque fois que l’on envoie un front montant sur l’entrée du driver, il réalise un pas sur le moteur pas à pas dans le sens choisi par l’entrée booléenne.
Pour la partie commande, nous avons choisi d’utiliser un clavier, une matrice 4×4 pour rentrer les valeurs cartésiennes et de petits joysticks afin de piloter manuellement les coordonnées cartésiennes.
Afin de visualiser les coordonnées, nous avons choisi d’utiliser un écran LCD à 2 x 16 caractères qui nous permet d’afficher les valeurs XYZ en temps réel ainsi que les valeurs tapées au clavier lorsqu’on l’utilise.
Pour les actionneurs, nous avons choisi d’utiliser des moteurs pas à pas réductés. Avec des moteurs pas à pas réductés, on peut gérer facilement la vitesse ainsi qu’une position. On connaît la valeur de l’angle d’un pas. Le réducteur est nécessaire afin d’avoir assez de couple pour faire bouger chaque axe du robot. Nos moteurs ont un couple de 30 kg/cm c’est-à-dire qu’au bout de 40 cm le moteur peut soulever 750 g. L’idéal aurait été des servomoteurs avec retour de la position mais ceux-ci n’étaient malheureusement pas dans notre budget.
Possédant personnellement une imprimante 3D, on choisira d’imprimer la plus grande partie des pièces nécessaires.
Tout d’abord, l’ensemble du robot à été modélisé en 3D sur SolidWORKS afin de vérifier le design et le fait que rien n’entre en collision.
Les pièces à imprimer ont été converties en format STL depuis cette modalisation.
Pour les pièces que nous avons fait usiner, on a réalisé une mise en plan de ces pièces toujours sous SolidWORKS.
Schéma de câblage simplifié :
Réalisation :
Dans les premières heures que nous avons consacrées au projet, nous avons réalisé plusieurs parties de programme, notamment le programme appelé calcul afin de réaliser des tests qui nous ont permis de vérifier la faisabilité du projet. Il faut savoir que tout le projet se base sur la conversion entre les données cartésiennes qui sont en mm et les angles de chaque moteur qui sont en radian. Par conséquent, sans ce programme calcul le robot ne fonctionnerait pas.
Bien sûr, le programme calcul n’est pas le seul programme que l’on utilise pour le fonctionnement du robot. Nous avons par la suite programmé plusieurs autres parties que nous avons bien sûr testé, comme le programme rampe qui permet quand nous sommes en mode clavier d’accélérer progressivement la vitesse du robot sur la moitié de la distance à parcourir et de le décélérer sur la deuxième moitié. Cela permet au bras d’atteindre une vitesse maximale lorsqu’il réalise de grandes distances et de rester à une vitesse faible pour des courtes distances. Nous avons continué à créer et tester des bouts de programmes notamment pour décoder la matrice 4 x 4 qui nous sert de clavier, ainsi que le programme clavier en lui-même avec un protocole : Ecrire la coordonnée puis ensuite appuyer sur moins. Exemple pour avoir la coordonnées – 200 il faut taper 2 puis 0 plus 0 puis – et valider. Et beaucoup d’autres programmes dans ce type.
Nous avons passé beaucoup d’heures à réfléchir pour les mouvements du robot ainsi que les programmes afin de trouver toutes les erreurs potentielles avant qu’elles se produisent. Une fois tous les programmes écrits, nous avons assemblé dans un programme principal le Main.
Pour la mécanique, nous avons réalisé tous les plans de chaque pièce sur Solidworks : chaque pièce à été réfléchi pour :
– Limiter les efforts
– L’ergonomie du bras
– La précision pour qu’elles correspondent aux angles calculés
On peut voir ici l’axe creux permettant le passage des fils :
Notre imprimante est une petite imprimante d’entrée de gamme, gérée par un Arduino. Elle fonctionne à l’aide de moteurs pas à pas et courroies. Elle procède un volume d’impression de 200*200*200 ce qui fait que certaines grandes pièces ont du être imprimées en deux fois.
Il faut compter une vingtaine d’heures pour imprimer un bras comme celui-ci.
Au fur et à mesure des tests avec un moteur puis deux, puis un moteur avec un bout de bras puis avec un switch de fin de course, le câblage devenait compliqué. Nous avons donc décidé de tout décâbler et de faire un câblage définitif sur une planche pour que ça soit clair et qu’il n’y ait pas de faux contact. L’idéal aurait ici été de réaliser un circuit imprimé supportant les drivers, et comprenant des résistances de tirages afin de limiter les problèmes des parasites.
Lors de la réalisation et des tests, nous avons rencontré plusieurs
problèmes notamment les moteurs pas à pas non reductés qui servent à l’angle D et E chauffaient beaucoup. Par conséquent, on ne pouvait pas les englober dans une pièce plastique. Ces moteurs sont donc fixés sur une plaque en aluminium.
Vu que nous utilisons des moteurs pas à pas réductés, l’angle qui correspond à un pas est très faible. Par conséquent, il faut faire beaucoup de pas pour réaliser un angle en sortie de réducteur. Le problème étant que même en envoyant une impulsion à chaque tour de cycle avec l’Arduino mega, nous ne pouvions pas utiliser les moteurs à leurs vitesses maximum. Nous avons donc décidé de changer d’Arduino et de prendre un due. C’est un Arduino qui remplit les mêmes caractéristiques que le Mega c’est-à-dire 54 entrées-sorties, mais il fonctionne en 3,3 volts au lieu des 5 volts du méga. Il possède un processeur 32 bits au lieu des 8 bits. C’est à dire qu’il va falloir beaucoup moins de temps pour réaliser des calculs. Et enfin il est cadencé à 84 MHz au lieu des 16 MHZ du mega. Quelques temps après, nous nous sommes rendus compte que c’était la bibliothèque gérant l’écran LCD qui ralentissait beaucoup le programme. Nous avons donc limité l’affichage sur l’écran tous les 100 tours de cycles. Aujourd’hui avec l’Arduino due, on est capable d’aller plus vite que la vitesse des moteurs.
Les drivers pas à pas eux aussi chauffent beaucoup, ils délivrent le courant nécessaire au moteur seulement quand ils sont froids : par conséquent, on a installé un ventilateur pour faire circuler l’air. Une fois la maquette réalisée, le programme installé dans l’Arduino, on a pu réaliser des tests concrets avec un programme fini : nous nous sommes rendus compte que les moteurs pas à pas saccadaient un peu, par conséquent nous avons passé les drivers en commande demi pas et le bras robotisé se comporte mieux depuis.
Par la suite, nous avons géré les temporisations et les vitesses afin d’avoir des mouvements fluides avec différentes positions au moteur pour un certains nombres de points. Nous avons aussi constaté des parasites au niveau de la télécommande constitué du joystick, c’est-à-dire que de temps en temps le robot se déplace légèrement, alors que nous n’avons pas touché au joystick. On pourrait régler la sensibilité des joysticks, mais dans ce cas on aurait plus la possibilité de le déplacer lentement quand on déplace à peine le joystick.
L’utilisation des moteurs pas à pas nous oblige à utiliser des fins de courses sur tous les axes afin de fixer l’angle à une certaine valeurs lors de la mise sous tension du robot. Par exemple, à la mise sous tension de l’Arduino, on ne sait pas dans quelle position se trouve le moteur pas à pas. On lancera donc une séquence de calibration lors de la mise sous tension.
Nous avons rempli le cahier des charges. Nous pouvons déplacer un bras robotisé avec trois possibilités :
– A l’aide du clavier, on peut rentrer les valeurs XYZ et même la valeur de l’angle E, si on veut que la pince se retrouve perpendiculaire à nous. Une fois que l’on appuie sur valider, le robot se dirige vers ces valeurs en ligne droite avec rampe d’accélération et de décélération.
Vidéo Mode cartésien clavier :
– À l’aide de la télécommande, chaque joystick est composé de deux axes, c’est-à-dire que l’on peut avec un joystick augmenter ou diminuer X et idem pour Y. Avec l’autre joystick, on fait de même avec les paramètres Z et E. Plus on incline le joystick, plus la valeur s’incrémente ou se décrémente rapidement, c’est-à-dire le bras ira plus vite. Si l’on incrémente seulement X, le bras réalisera une ligne droite sur X, sans changer la valeur Y et Z.
Vidéo Mode cartésien Télécommande :
– Avec la même télécommande, on peut en basculant un switch sur le premier joystick gérer l’angle à la rotation de la tourelle ainsi que l’angle B. Et avec l’autre joystick, on gère l’angle C ainsi que l’angle E. C’est comme sur le mode cartésien, plus on incline le joystick plus la décrémentation ou l’incrémentation sera rapide.
Vidéo Mode angulaire :
Si l’on demande au bras d’aller à une coordonnée impossible pour lui, il affichera erreur sur l’écran et ne bougera pas. Exemple, si on lui demande un Z négatif donc sous le sol, il n’essayera pas d’y aller.
Vidéo Erreur :
Afin de connaître la position du bras et donc la position de chaque angle après la mise sous tension, on réalise une séquence de calibration. À la mise sous tension de l’Arduino, le premier programme que l’on réalise est la calibration. Il demande à tous les moteurs de tourner dans le même sens jusqu’au fin de course. A partir de là, il s’arrête et dans les valeurs du programme, on affecte la position actuelle du robot. De là, on connaît la position du bras. Ensuite le programme calibration se termine sur l’envoi du bras robotisé sur une position « home ».
Vidéo Calibration :
L’outil de notre robot est une pince.
Vidéo montrant le fonctionnement de la pince :
Gestion de Projet
Nous avons pris du retard sur la partie mécanique du robot, et nous avons perdu du temps à régler des problèmes de parasite sur le signal envoyé aux drivers pas à pas mais malgré cela le projet a été fini dans les temps.
Perspectives
Le bras robotisé est composé de 4 axes complètement automatisés et nous lui avons rajouté un cinquième axe qui correspond à la rotation du poignet sur un bras humain. Nous utilisons uniquement cet axe afin que la pince soit toujours perpendiculaire au sol. Nous pouvons l’utiliser pour donner un angle à la pince par rapport au sol mais dans ce cas-là, les calculs des angles deviendraient beaucoup plus lourds à réaliser car cela voudrait dire qu’il y aurait plusieurs possibilités d’angles pour la même position. C’est pour cette raison que nous gardons la pince perpendiculaire au sol. Il y a donc une évolution à ce niveau-là pour rendre le robot en 5 axes. Il suffirait de réaliser les calculs nécessaires. Dans cette optique, nous pourrions même le rendre mobile sur 6 axes afin de donner à l’outil une position mais également un angle dans l’espace.
Aujourd’hui le bras robotisé est pilotable de deux façons. L’une avec le clavier en rentrant des coordonnées cartésiennes sur X,Y et Z et l’autre, avec la télécommande constituée de deux joysticks pour faire varier directement les coordonnées X,Y et Z. Il y aurait une évolution au niveau de la manière de piloter le robot car on pourrait très bien imaginer pouvoir le piloter à l’aide d’une interface web ou d’autres moyens de communication sans fil.
Bilan
– Réaliser un bras robotisé 5 axes dont 4 réellement pilotables
Le robot comporte ses 5 axes dont 4 pilotables
– Celui-ci devra pouvoir être pilotable dans un repère cartésien avec des déplacements linéaires
– La partie commande sera réalisée sur une carte type Arduino
– Le robot devrait pouvoir évoluer dans une demi sphère de 300 mm de rayon et prendre en compte les zones interdites
Le robot peut se déplacer dans une zone de 400mm autour de sa base et prend en compte les zones interdites
– La précision au bout du bras devrait être au moins de 4 mm
Le jeu dans les réducteurs des moteurs pas à pas ne nous permet pas d’atteindre cette précision quelque soit la position du robot dans l’espace.
– Les coordonnées de positions du robot devraient être entrées à l’aide d’un clavier
– Le robot devrait également être pilotable à l’aide d’une télécommande comportant 2 joysticks selon deux modes : angulaire ou linéaire.
– La position réelle du robot ainsi que les coordonnées tapées au clavier seront affichées sur un écran LCD.
– Les déplacements devront se faire en suivant une rampe d’accélération et de décélération.
– Le robot devrait pouvoir se déplacer avec une charge de 200g max dans sa pince.
Le robot peut soulever environ 500g
– Le robot devrait comporter un bouton d’arrêt d’urgence de type coup de point.
Conclusion
Voilà un petit extrait de notre projet, qui vous montre notre implication. On pourrait l’expliquer pendant des heures mais ce n’était pas le but, par conséquence on s’est contenté de vous expliquer les parties les plus intéressantes.
Le projet a été très intéressant, il nous a permis d’acquérir et de mettre en pratique beaucoup de connaissances. Aujourd’hui nous pouvons être fiers de notre réalisation car le bras robotisé fonctionne correctement. Il a été un projet complexe qui a demandé beaucoup d’heures de travail.
Ce projet de bras robotisé vous est présenté par MANTOT Thomas apprenti en génie électrique et informatique industriel chez ACTEMIUM ainsi que ALLENBACH Timothée aussi apprenti en génie électrique et informatique industriel chez CLEMESSY Nucléaire.