DobotNet Arduino – Réseau de robots Dobots Magician

Bienvenue à toutes et à tous !

Dans cet article, nous allons partager avec vous les découvertes que nous avons faites lors de notre projet de deuxième année de classe préparatoire à Polytech Angers !

Ça, c’est ce qu’on a fait…

Vidéo de démonstration du projet DobotCity, by DobotNet

Oui oui, nos deux petits bras robotisés essaient de construire une ville miniature… Vous voulez savoir comment ? Et bien c’est parti !

1. Présentation du matériel

Notre objectif lors de ces six derniers mois était de créer une solution pour permettre la communication entre plusieurs Dobots Magician via une carte Arduino.

Les Dobots Magician sont des petits robots comme celui-ci, auxquels on peut ajouter une extension telle qu’une ventouse ou une pince pour attraper des objets, un crayon pour dessiner, ou même un laser pour graver dans la matière !

Ils ont une portée allant de 15cm à 32cm par rapport à leur base et une répétabilité des mouvements de 0.2mm.

Robot Dobot Magician
Carte Arduino MEGA

La carte Arduino MEGA va agir comme le cerveau de notre projet. Elle se verra attribuer diverses lourdes tâches comme relayer les informations entre les Dobots, mémoriser l’avancement de la construction de la ville, recevoir des commandes de la part de l’utilisateur…

Au début, nous avions une carte Arduino UNO, mais elle n’avait pas assez de RAM pour assumer toutes ces responsabilités, nous n’avons donc pas eu d’autre choix que de la changer !

Source de beaucoup d’ennuis, certes, mais la construction de notre ville ne pourrait pas se faire sans la caméra

En effet, nous allons avoir besoin de repérer des cubes dans l’espace, elle sera donc utile pour traiter le flux d’images qu’elle capture et récupérer en temps réel des informations précieuses que nous allons aborder dans quelques instants.

La caméra

2. Choix du projet

Comme nous l’avons expliqué, notre but lors de ces six derniers mois était de parvenir à faire collaborer deux Dobots Magician connectés à une carte Arduino. Nous souhaitions profiter au maximum de ces 100 heures de projet pour découvrir de nouveaux domaines liés à l’informatique, il est donc évident que le projet que nous vous présentons aujourd’hui ait piqué notre curiosité. Voici quelques raisons pour lesquelles nous avons choisi ce projet au-dessus des autres :

  • Satisfaction visuelle offerte par le travail en équipe de deux robots lors de la réalisation d’une tâche complexe
  • Publication en source libre pour apporter sa participation au développement de la communauté Dobot
  • Découverte de pratiques courantes en robotique qui seront nécessairement utiles dans le futur
  • Introduction et apprentissage autonome à la vision par ordinateur
  • Familiarisation avec du matériel électronique

Enfin bref, c’est finalement la liberté offerte par ce projet, que ce soit dans sa finalité comme dans les procédés pour l’atteindre, qui nous l’a fait remarquer au-dessus des autres.

Maintenant que vous savez pourquoi on l’a choisi, voyons comment nous nous y sommes pris pour construire une petite ville.

3. Premiers pas : Découverte de DobotStudio

Nous avons passé les premières heures de projet à expérimenter et à nous familiariser avec les robots grâce à l’interface de contrôle DobotStudio. Cette application propose de nombreux modes amusants et interactifs pour faire se mouvoir les Dobots. On retrouve notamment le Teach and Playback, où le robot exécute une série de mouvements prédéfinis, et le Write and Draw, qui laisse le robot dessiner un texte ou une image téléversée sur l’application.

En revanche, le mode qui nous intéressait réellement pour le début de ce projet était la programmation en Blockly, puisqu’il offre un accès simplifié aux commandes d’un Dobot grâce à des blocs préprogrammés. En seulement quelques minutes, nous pouvons créer le programme ci-dessous:

Illustration des mouvements d’un Dobot avec DobotStudio | Programme Blockly

Le résultat obtenu lors de l’exécution de ce programme est le suivant :

Illustration des mouvements d’un Dobot avec DobotStudio | Vidéo

Avec quelques essais supplémentaires, nous avions une bonne appréhension de la manière de se déplacer des Dobots. Il était donc temps de passer à l’étape suivante : leur interface de communication.

4. Communication en série avec les Dobots

Nous vous l’avions caché jusqu’à maintenant, mais nos petits robots disposent de diverses interfaces de connexion. La zone 6 sur la photo ci-dessous permet l’alimentation et le contrôle des extensions telles que la ventouse ou la pince.

En revanche, celle qui nous intéresse actuellement est l’interface de communication en zone 3. Parmi les 10 pins exposés dans cette zone, 2 d’entre eux (nommés RX et TX) constituent une interface UART, qui permet le transfert bidirectionnel et asynchrone de données en série.

Interface de contrôle d’un Dobot
Ports UART Arduino MEGA

Cette interface est d’autant plus intéressante qu’elle peut être associée à l’une des quatre interfaces UART installées par défaut sur une carte Arduino MEGA (entourées en rouge). Pour ce faire, il suffit de connecter les pins RX et TX à l’arrière du Dobot respectivement aux pins TX1 et RX1 de la carte Arduino. Une troisième connexion nécessaire est celle entre le GND de l’Arduino et celui du Dobot.

Une fois cette connexion réalisée, l’Arduino peut, avec le programme approprié, envoyer des commandes au robot à laquelle elle est liée.

Après quelques heures de recherche, nous sommes entrés en possession de deux fichiers importants. Le premier détaille le protocole de communication des Dobots (format des paquets de données) et contient une liste de leurs commandes enregistrées. Le second est un programme de démonstration faisant bouger un Dobot en connectant ses pins RX et TX à une carte Arduino MEGA.

Voici le résultat obtenu grâce au code de démonstration :

Une très bonne nouvelle pour nous fut que cette démonstration contenait l’implémentation d’une dizaine de commandes et d’un système assez modulaire (bien que parsemé de bugs embêtants) pour établir une communication à double sens avec un Dobot.

Après avoir passé plusieurs heures à lire, comprendre et corriger le code de démonstration, nous étions fin prêts à relever notre plus gros défi jusqu’à présent : la création d’une bibliothèque open-source pour permettre le contrôle de un ou plusieurs robots Dobot Magician depuis une unique carte Arduino Mega.

Démonstration Arduino

5. Création de DobotNet

C’est ici que naquit DobotNet. Avec un temps considérable passé à découvrir et à réorganiser la démonstration, nous avons été capables de marquer les parties du code nécessitant une réécriture complète et celles pouvant être utilisées sans grosse modification.

Il s’agissait de notre première expérience de création d’une bibliothèque open-source. Aussi, nous avons concentré nos efforts pour améliorer au maximum la lisibilité du code grâce à des fonctions documentées et simples à utiliser.

Voici l’évolution de la syntaxe pour faire se déplacer un robot vers un point donné, en commençant avec la méthode initialement proposée par la démonstration :

// Long, peu pratique et sans support pour plusieurs Dobots
PTPCmd gPTPCmd;
gPTPCmd.x = 200;
gPTPCmd.y = 0;
gPTPCmd.z = 0;
SetPTPCmd(&gPTPCmd, true,  &gQueuedCmdIndex);

Et maintenant, l’équivalent du code précédent en utilisant DobotNet, où “dobot” est une variable pouvant représenter n’importe lequel des robots connectés à la carte :

dobot.MoveTo(MOVL_XYZ, 200, 0, 0, 0);

En comparant ces deux extraits, on remarque que le gain de temps, de place et par conséquent de lisibilité du code source n’est pas négligeable, surtout pour des procédures de mouvements plus longues et complexes.

Nous avons également ajouté des exemples à notre bibliothèque DobotNet pour permettre une prise en main rapide et accompagnée. Elles vont d’une simple reproduction de la démonstration sur laquelle est basée notre bibliothèque, au code complet de la solution dont vous avez vu un extrait au début de cet article. On retrouve ci-dessous le résultat de l’exécution de l’exemple “NetworkDemo.ino

Exécution de l’exemple NetworkDemo.ino avec DobotNet

6. Création de la ville

Maintenant que nous pouvons facilement faire bouger nos Dobots, passons à la création de notre ville. Pour ce faire, il nous faut dessiner un plan aux proportions suffisamment impressionnantes pour l’aspect visuel, tout en restant dans la portée des robots. Il faut également faire attention à ce que les structures dans la ville ne soient pas trop proches les unes des autres pour s’assurer que l’ouverture de la pince ne démolisse pas des bâtiments adjacents.

Plusieurs versions ont été nécessaires, mais nous sommes finalement parvenus à un plan satisfaisant nos attentes :

Chaque couleur représente un type de bâtiment :

  • Maison (rouge) [2×1]
  • Arbre (vert) [2×1]
  • Immeuble (jaune) [3×2]
  • Voiture (bleu) [1×2]
  • Zone de transition (blanc)
Plan final de la ville DobotCity

La zone de transition est un emplacement auquel les deux Dobots ont accès, permettant le transfert des blocs d’une zone à l’autre.

En plaçant la tête du Dobot sur le point de calibration (rouge) au centre de l’image, nous pouvons récupérer un point de référence dans le système de coordonnées du Dobot, ce qui permet de convertir les coordonnées en millimètres des bâtiments. Il en est de même pour le Dobot de la partie suivante.

7. Création de la zone de stockage

Nous entrons maintenant dans la partie qui s’est avérée être la plus problématique de toutes pour notre projet : la zone de stockage. Il s’agit de l’endroit où les blocs sont déposés par l’utilisateur, pour ensuite être récupérés par un Dobot et placés sur la zone de transition. C’est maintenant que nous faisons appel à la caméra, dont la capture sera traitée pour essayer de déterminer la position des blocs dans la zone de stockage.

Voici ce à quoi ressemble notre zone de stockage (Théorique | Capturée par la caméra) :

Représentation de la zone de stockage
Capture réelle de la zone de stockage

Les quatre carrés noirs étranges autour de la zone de stockage sont appelés des marqueurs Aruco. Ils sont parfois utilisés en vision par ordinateur pour délimiter une zone, déterminer un repère ou traquer un objet mobile.

En utilisant la bibliothèque de traitement d’image OpenCV (Open Computer Vision) disponible sur Python, nous pouvons réaliser les étapes suivantes pour isoler la zone de stockage et détecter les cubes.

1) Trouver le centre des marqueurs Aruco sur l’image avec cv2.aruco.detectMarkers()

2) Transformer l’image de sorte que les centres trouvés soient aux coins de l’image avec cv2.getPerspectiveTransform(centres, coins) et cv2.warpPerspective(). Le résultat est présenté ci-dessous :

Image de la zone de stockage après transformation de la capture

3) Appliquer un flou gaussien pour réduire le bruit

4) Appliquer un algorithme de détection des contours avec cv2.Canny() et deux paramètres sélectionnés par l’utilisateur. Nous avons créé une interface qui permet de visualiser l’effet des deux paramètres (En vert sont les contours détectés)

Interface de calibration des paramètres de la caméra

5) Validation des dimensions des contours, calcul des centres et de la couleur des blocs

6) Compilation des résultats dans l’interface de contrôle

Interface de contrôle à distance

Il nous aura fallu beaucoup de temps pour comprendre les fonctions proposées par OpenCV et trouver une combinaison d’algorithmes donnant un résultat fiable. Nous avons cependant découvert de nombreux concepts en lien avec la manipulation d’image qui ont changé notre perception de ce domaine.

8. Interface Utilisateur Graphique (GUI)

Comme nous venons de le voir sur les deux captures précédentes, nous avons ajouté à notre projet des interfaces utilisateur pour faciliter le contrôle depuis un ordinateur. Ces interfaces ont été réalisées avec Tkinter. Chaque bouton sur l’interface de contrôle communique une commande à la carte Arduino via un module Bluetooth que nous avons ajouté. Un exemple simple est le bouton Construire qui permet de lancer / arrêter la procédure de construction de la ville, ou le bouton Reset qui permet de recommencer la procédure de zéro.

Nous avons également ajouté un écran LCD 4×20 connecté à l’Arduino pour afficher l’état actuel de la procédure. Le voici dans deux états différents :

Ecran LCD – Mode inactif
Ecran LCD – Mode construction

9. Perspectives d’amélioration

Comme nous vous l’avons expliqué au début de cet article, l’une des raisons principales pour laquelle nous avons choisi ce projet est sa capacité à constamment pouvoir être amélioré. Nous avions de nombreuses idées pour compléter le travail que nous avons fait jusqu’à présent, mais le temps nous a manqué pour réaliser certaines d’entre elles.

Nous souhaitions par exemple imprimer une carte électronique pour réduire le nombre de câbles apparents qui dégradent actuellement l’apparence extérieure de notre projet, mais par manque de temps, nous n’avons pas eu l’occasion d’aller au bout de cette idée.

Prototype de carte électronique, réalisée sur EAGLE by AutoDesk

Sans carte électronique et par conséquent sans certitude des dimensions, nous ne pouvions pas prendre le risque d’imprimer une boîte de rangement pour la carte Arduino et les modules qui y sont connectés.

Vision intérieure de la boîte
Vision extérieure de la boîte

Enfin, une dernière amélioration que nous aurions réellement aimé ajouter est celle laissant l’utilisateur dessiner sa propre ville. Elle correspond au bouton Dessiner sur l’interface de contrôle. Seul le temps pour créer une interface de dessin du plan nous manquait, puisque le code Arduino est déjà adapté pour accueillir ce genre de fonctionnalité.

10. Bilan

Si vous êtes encore là, merci beaucoup d’avoir pris le temps de lire cet article !

Ce projet a été pour nous une expérience inoubliable. Même si, comme nous venons de le voir, nous n’avons pas eu le temps d’aller au bout de nos perspectives, nous sommes tout de même très heureux du travail accompli lors de ces six derniers mois. Nous n’étions que deux pour réaliser ce projet, et les défis que nous a causé notre ambition ont été de taille. Même si notre technique pour aborder certains problèmes n’était pas parfaite, nous sommes fiers d’avoir accompli ce qui est notre projet aujourd’hui.

Vision par ordinateur, programmation sur Arduino, création d’une bibliothèque, design d’une carte électronique, modélisation 3D. Toutes ces compétences ne pourront que nous être bénéfiques pour le futur, et nous garderons un très bon souvenir de ce travail d’équipe pour surmonter les obstacles rencontrés sur le chemin.

11. Remerciements

Nous remercions évidemment l’ensemble des enseignants qui ont pu nous aider durant ce projet, et plus particulièrement :

  • Mr. BOIMOND Jean-Louis, notre référent de projet
  • Mr. LAGRANGE Sébastien
  • Mr. VERRON Sylvain

Ce projet a demandé beaucoup de rigueur, il aurait donc été impossible sans leur aide précieuse.

12. GitHub Repositories

Kind Regards, us

by Paquereau–Gasnier Alexis, Cholet Byron

RUBIBOX – Robot d’arcade Rubik’s cube

Présentation de notre projet :

Bonjour à tous !

Nous sommes Lou Bénier, Erwann Miloux et Maxime Toublanc, étudiants de 2ème année à Polytech Angers.

Cet article est dédié à notre projet de fin d’année porté sur le domaine de la robotique.

Nous vous présentons donc Rubibox, notre robot d’arcade de réalisation du Rubik’s cube.
Le but étant de résoudre ce célèbre casse-tête au moyen de boutons poussoirs en ajoutant comme difficulté l’incapacité de pivoter la face orange.

logo

Le cube à résoudre est à l’intérieur d’une boîte en plexiglas transparent, rendant la manipulation manuelle impossible.

L’idée est d’intégrer ce projet à un autre bien plus grand : Escape Polytech.
En effet nous l’avons conçu dans le but qu’il soit encastré dans un bloc de l’armoire d’Escape Game pour l’édition Escape Polytech à venir.


Conception & Réalisation :

Nous sommes partis sur l’idée d’un cube dans un cube.

Les moteurs sont vissés sur les faces intérieures d’un cube en plexiglas, tenant le Rubik’s Cube au centre.
La pièce orange non pivotable est face à l’utilisateur du robot, sa vue n’étant pas obstruée par un sixième moteur.

CAO SolidWorks

Modélisation CAO de Rubibox (SolidWorks)

Pour ce qui est de la commande des moteurs, ils sont activés suite à l’appui d’un bouton d’arcade de la couleur de la face correspondante.

Ces derniers sont disposés sur un petit boîtier au-devant du cube en plexiglas.
On ajoute un bouton « mélange » (shuffle en anglais) à l’avant du boîtier.
Associés à ces boutons, des LED de même couleur s’allument lors de la rotation d’une face.
La liaison entre les boutons poussoirs et les moteurs, se fait via 3 cartes Arduino UNO.

Il nous a fallu songer à une méthode pour décider du sens de rotation (horaire ou anti-horaire).

Pour ce faire, nous utilisons un interrupteur levier ON OFF ON, qui activé à « gauche » pivote la face dans le sens anti-horaire, et activé à « droite » donne une rotation horaire.
C’est dans l’esprit du robot d’arcade, que nous voulons donner à cet interrupteur l’apparence d’un joystick d’arcade.

Au cours de ce projet nous avons dû utiliser différentes machines spécifiques telles que :

  • La découpe laser du fablab des Beaux-Arts pour le cube en plexiglas transparent et le boîtier que nous avons fait de la même matière par efficacité.
  • découpe laser plexi

    Découpe laser du plexiglas (Beaux-Arts)


    pièces de plexiglas

    Pièces de plexiglas à la sortie de la découpe

    Afin d’encastrer les faces du cube les unes avec les autres, nous avons eu l’idée de donner aux côtés une forme de remparts. Ainsi nous avons un unique fichier SolidWorks pour les 6 faces.

  • L’imprimante 3D du fablab de Polytech Angers pour les petites pièces liant les 5 moteurs aux centres des faces du Rubik’s Cube, et les pièces liant les moteurs aux faces en plexiglas.
  • impression 3D

    Impression 3D des pièces qui contiendront les moteurs

  • La perceuse du fablab de Polytech Angers effectuant des trous dans le plexiglas pour y fixer les moteurs et les équerres.
  • perceuse plexiglass

    Nous perçons les trous qui serviront à visser les moteurs


Principe du code :

Notre code repose sur la communication de 3 cartes Arduino UNO branchées en série.

On appelle ce système un bus I2C (Inter-Integrated Circuit) composé d’une Arduino dite MASTER, et des 2 autres dites SLAVE 1 et SLAVE 2.

Le principe de ce bus est que la MASTER contient le programme principal et envoie des ordres aux SLAVE 1 et SLAVE 2. Elle peut aussi demander une « requête » à celles-ci.

Pour illustrer au mieux ce processus voici un exemple où l’on veut faire tourner une face du Rubik’s Cube pour laquelle le bouton déclencheur se situe sur la MASTER, le moteur et la LED sur la SLAVE 1, et l’interrupteur levier sur la SLAVE 2 :

schéma explicatif

Schéma explicatif du principe de communication entre les Arduino


code

Code Arduino correspondant au schéma précédent

Test de ce code en vidéo (moteur vert sur SLAVE 1 actionné par bouton bleu sur MASTER) :

Le choix d’utiliser 3 cartes Arduino est lié au fait d’avoir 5 moteurs. Sur chaque Arduino est placée une carte Shield ne pouvant contenir que 2 moteurs chacune.

On a alors réparti les différents composants comme suit : les 6 boutons sur la MASTER, les LED sur la SLAVE 1 où sont branchés leur moteur respectif, et l’interrupteur sur la SLAVE 2.

En voici le schéma électrique :


Fabrication & Assemblage :

Nous avons conçu les faces de la boîte en plexiglas dans le but de les encastrer les unes avec les autres grâce aux remparts.

Seulement, à cause du jeu existant entre elles, nous avons décidé de les fixer à l’aide d’équerres.

Pour ce qui est du joystick, nous avons préféré le fabriquer nous-même, l’imprimante 3D étant très prisée. Dans la boule de joystick taraudée, commandée au préalable, on y a inséré une vis (dont on a coupé la tête), à laquelle nous avons collé un tube métallique pour la tige. Le tout fixé sur l’interrupteur levier lui-même vissé au boîtier.

Puis nous avons dû sectionner, diviser et rallonger notre alimentation de 9V afin d’alimenter notre robot via la carte Arduino MASTER par l’embout d’alimentation DC, et les trois cartes Shield par les fils + et – qui en découlaient.


Rendu final :

Nous finissons notre projet en tournant deux faces sur les cinq requises.

En effet, nous avons rencontré divers problèmes que nous n’avons pas pu régler. Néanmoins, nous sommes capables de tourner ces faces en choisissant le sens de leur rotation grâce au joystick orange, ce qui est un point positif.

Pour l’assemblage final, nous avions convenu de glisser les cartes Arduino sous le boîtier des boutons, mais par manque de place elles ont été déposées dans la boîte en plexiglas.

Assemblage final de Rubibox

Assemblage final de Rubibox


Problèmes rencontrés :

Au cours de notre projet, nous avons rencontrés plusieurs obstacles.

Pour commencer, le plus flagrant, tous les moteurs ne tournent pas. En effet, nous suspectons le fait que l’une des deux SLAVE ne puisse plus recevoir d’informations venant de la MASTER. Nous ignorons encore la raison, peut-être qu’un problème est survenu lors de l’assemblage du robot ou bien lors du soudage à l’étain des fils de branchement sur les cartes Shield.

Autre problème : nous avions commencé le projet avec un Rubik’s cube différent.

Nous avons conçu Rubibox de manière à encastrer les moteurs dans les centres du cube. Or, lors de l’assemblage, nous nous sommes rendus compte que les centres tournaient curieusement indépendamment du reste de la face. En conséquence, le moteur tournait correctement, mais la face ne suivait pas. Nous avons donc dû prendre un de nos Rubik’s cubes personnels n’ayant pas ce problème, pour mener à bien notre projet.

S’ajoute à tout ceci un problème esthétique.

En effet nous manquions de place sous le boîtier des boutons pour y insérer les cartes Arduino ce qui encombra la boîte en plexiglas dans laquelle sont déjà placés le cube et les moteurs. De plus nous voulions fabriquer un boîtier opaque pour cacher tous les fils. Malheureusement le Fablab des Beaux-Arts, lieu où nous avons utilisé la découpe laser, ne pouvait nous céder uniquement du plexiglas transparent pour toutes nos pièces.

Puis, sur ce même boîtier nous avons constaté un défaut de conception pour l’emplacement du bouton de mélange du Rubik’s cube.

Effectivement, lors de l’assemblage, il nous a été difficile d’intégrer ce bouton à cause de la forte proximité des boutons blanc et jaune. Nous aurions dû le placer à gauche, près de l’interrupteur levier, plutôt qu’à droite à l’encontre des boutons.


Conclusion :

Malgré les quelques complications survenues, nous ne pouvons que conclure positivement.

Nous avons mené ce projet en équipe, et sommes ravis du rendu de Rubibox même si nous sommes un peu frustrés de ne pas le voir fonctionner dans son entièreté comme prévu.
Tout au long de ce projet, nous avons été actifs et les idées fusaient.
Ce projet nous a permis d’acquérir de nouvelles compétences, d’apprendre à utiliser certaines machines, et surtout d’avoir le plaisir de mettre en pratique nos idées, notre imagination.

Voici quelques points à améliorer sur Rubibox :

Points à améliorer :

Nous avions intégré dans le code une partie calculatoire permettant de connaître la position des couleurs sur le cube à tout instant. Ainsi, lorsque le cube aurait été résolu, les LED se seraient allumées telles une guirlande.

Pour améliorer le robot, on pourrait ajouter un émmeteur de son faisant retentir une petite mélodie au même instant que la guirlande de LEDs.
Pourquoi pas aussi un petit écran LCD servant de chronomètre, indiquant le temps de résolution mis par le joueur.
De plus, dans l’idée de l’intégrer à l’armoire d’Escape Polytech, une pose de miroirs à l’arrière pourrait être intéressante.

Caméra pour robot KUKA KRC3

image1

Fixer une caméra à un bras robot. Qu’est-ce que pourrait mal se passer?

Nous sommes Théotime Aubin et Antoine Grimault, notre objectif a été de fixer une webcam au bras robot KUKA et de lui faire détecter des objets sur un plan (fixe) défini au préalable.
La première étape a été de choisir l’emplacement de la webcam.

image2

  • On aurait pu choisir de fixer la caméra dans l’espace de travail du robot.
  • image3

  • Il était aussi possible de la fixer sur le côté du robot, et d’avoir une position de prise de vue différente de la position d’action.
  • image4

  • Enfin, on pouvait fixer la caméra directement sur la flasque du bras, avant l’outil.
  • Nous avons choisi la dernière option car ce système limite faiblement les mouvements du bras,
    et le repère de la caméra est “simple” à définir par rapport au repère de la flasque. C’est aussi plus facile de la fixer solidement ici.
    Il est possible que l’outil soit visible sur l’image, cela pourrait poser problème pour la détection des objets, mais d’après nos mesures cela a peu de chances d’arriver.

    Une fois ce choix fait, nous avons démonté la webcam pour n’en garder que l’électronique (PCB), puis modélisé un boitier sur SolidWorks que nous avons ensuite imprimé en 3D.

    Capture5
    Capture2


    Capture1
    Capture4


    Capture

  • Vient ensuite la phase deux… le traitement d’image :

  • Pour ceci nous avons décidé d’utiliser Python avec le module OpenCV sur un ordinateur séparé du robot. On a codé une application qui permet à l’utilisateur du robot d’avoir un retour vidéo pour calibrer la ‘‘visée’’, fait une détection de contour et donne les coordonnées d’un objet situé sur l’espace de travail défini au préalable, en convertissant au passage des pixels en millimètres.

    nnwn
    Capture6

  • Vient ensuite la phase trois… la programmation du robot :


  • Capture10

    Le but est simple. Le robot est capable de connaitre en temps réel la position de la flasque. Notre travail dans ce programme est de donner au robot les translations et rotations de repère afin de disposer des coordonner de la caméra en temps réel.

    Capture720210604_184736

    Après s’être bien creusé les méninges on finit par comprendre et ça donne un beau petit programme :



    Capture8

  • Conclusion :
  • Quand on fait tout fonctionner ensemble le robot est capable de localiser une pièce, en déduire ses coordonnées et la pointer. il aurait été possible d’aller un peu plus loin en communiquant directement les coordonnées au robot via une carte d’entrée sortie utilisant le protocole TCP/IP, mais celle ci a mis trop de temps a arriver.

    Capture9

    Bras Robot

    Salut les Polypotes !

    Actuellement en deuxième année de cycle préparatoire ingénieur, nous avons choisi de nous intéresser à la robotique dans le cadre de notre projet de conception. Notre groupe se compose de Victor, Emma et Stanislas. Nous sommes trois étudiants souhaitant rejoindre la filière SAGI, la robotique nous intéresse donc tout particulièrement. Le projet du bras robot nous a permis d’avoir une première approche de ce domaine, de découvrir le fonctionnement des actionneurs et du microcontrôleur (carte Arduino Uno). De plus, nous avons eu l’occasion de nous essayer à la cinématique afin de modéliser notre bras sur Matlab ou Python. Notre professeur référent, M.Chatti nous a guidé étape par étape tout du long de notre projet.

    IMG_3467

    Au commencement de notre projet, nous avons reçu le bras tel qu’il est sur la photo ci – dessus. Il venait d’être fabriqué à l’aide de l’imprimante 3D à Polytech Angers et était composés de 6 servomoteurs qui effectuent des rotations lui permettant de se déplacer dans toutes les direction de l’espace. A première vue, nous avons décelé quelques défauts, par exemple, certains servomoteurs n’avaient pas un assez grand couple pour soulever le bras et porter un objet, de plus d’autres ne fonctionnaient même pas.

    Pour commencer nous avons décidé de nous intéresser aux actionneurs; les servomoteurs. Il fallait les tester afin d’être sûr de leur bon fonctionnement. Pour ce faire nous avons utilisé des potentiomètres ainsi qu’une carte Arduino. Les potentiomètres avaient pour objectif de donner une consigne au microcontrôleur qui avait lui même pour but d’envoyer un signal aux actionneurs, les servomoteurs. Nous avons simulé notre programme et nos branchements sur le logiciel TinKerCad.

    tinkercad

    Après avoir testé et changé les servomoteurs qui ne fonctionnaient pas bien nous nous sommes occupés de connecter la carte Arduino au smartphone. Pour ceci on a utilisé un module Bluetooth à brancher sur la carte, et une application Android que nous avons créé à l’aide d’une application développée par Google et le MIT; MIT app inventor, qui permet de créer des applications installables sur tous les smartphones Android.

    Interface de MIT app inventor avec notre code en block

    Interface de MIT app inventor


    Nous avons configuré l’interface de l’application pour y installer six curseurs (un pour chaque moteur) et ainsi contrôler toutes les articulations du bras.

    L’application, une fois connectée au module Bluetooth de la carte, envoie un signal Bluetooth à chaque déplacement d’un curseur, qui indique le moteur concerné ainsi que la position désirée par l’utilisateur. La carte reçoit ce signal et pilote les servomoteurs en fonction de la position donnée.
    Sur l’image ci-dessus on peut voir deux boutons clap numérotés 1 et 2. Ce sont les boutons scénario. Sur Arduino, nous avons programmé un enchaînement de positions pour chaque servomoteur qui va créer un mouvement en répétition, ce qui permet de répéter une action comme on peut voir dans la vidéo ci-dessous, où le bras vide une boîte de chewing-gum puis la replace à un autre endroit.

    Nous avons aussi ajouté à notre programme un moyen d’enregistrer les positions de servomoteurs envoyées depuis l’application pour ensuite répéter automatiquement la série mouvement demandé précédemment par l’utilisateur, pour que chacun puisse créer son propre scénario directement depuis l’application.

    Cinématique directe/inverse:
    Par la suite, nous nous sommes renseignés sur:
    – La cinématique directe(calculer la position finale de la pince à partir des positions de toutes les articulations.)
    – La cinématique inverse(calculer les positions nécessaires aux articulations pour obtenir une position finale du bras, à partir de la position de la pince.)
    Cependant, par manque de temps, nous n’avons pas pu approfondir la cinématique inverse. Avec une étude de cinématique inverse nous pourrions donner une position en X,Y,Z d’un objet et le bras ferait les mouvements nécessaires pour que la pince atteigne cette position le plus rapidement possible.

    Pour la cinématique directe, il est possible de calculer la position finale de la pince avec plusieurs approches différentes, par exemple à l’aide des relations trigonométriques existantes dans un triangle rectangle ou à l’aide d’équations de cercles. Nous avons donc fait des programmes sur Python et Matlab pour effectuer ces calculs, ce qui nous à permis de modéliser le bras en fonction des positions qu’on lui à donné.

    Interface final  de la cinematique du bras, sur matlab

    Interface finale de la cinématique du bras, sur Matlab

    Problèmes:
    Quelques problèmes sont apparus, liés aux branchements et à la puissance des servomoteurs, nous avons donc eu besoin de changer deux des 6 servomoteurs car il avaient besoin d’un plus grand couple. Nous avons donc acheté deux servomoteurs d’un couple supérieur à 20kg.cm pour soulever le bras. Nos anciens servomoteurs ne dépassaient pas 13kg.cm. Les nouveaux moteurs n’étant pas de la même taille, nous avons imprimé une nouvelle pièce adaptée aux nouvelles dimensions(en blanc ci-dessous).


    Malgré l’acquisition de moteurs plus puissants, nous avions toujours des problèmes pour contrôler le bras. Ces problèmes étaient en fait dû au manque d’alimentation, la carte Arduino avait du mal à alimenter les 6 servomoteurs. Nous avons donc branché la moitié des moteurs sur un générateur pour leurs fournir 6V et ainsi leur donner une plus grande puissance, ce qui a fonctionné, puisque nous avons fini par faire fonctionner parfaitement le bras avec une charge dans la pince.

    Pour finir, nous avons trouvé ce projet très intéressant car il nous à permis d’approfondir nos connaissances en robotique et de découvrir de nouvelles choses telles que la cinématique qui nous sera probablement très utiles pour la suite de nos études.

    Merci de nous avoir lu jusqu’au bout!