Projet PEIP 2A – Robot 5R

La PlotClock

Bonjour à tous !


L’objectif de ce projet est de réaliser une Plotclock où le robot a pour tâche d’écrire l’heure en temps réel. Ce robot fonctionne avec deux bras, composés tous les deux de deux avant-bras, reliés entre eux au niveau de la tête d’écriture. Les deux bras sont dirigés de manière à dessiner l’heure sur l’écran à l’aide de servomoteurs.

Notre robot est équipé, en tête d’écriture, d’une LED UV pour écrire l’heure sur l’écran phosphorescent. Après que le robot est affiché l’heure grâce à la LED UV, elle s’efface toute seule, avec le temps.


Voici quelques étapes de la conception de notre robot en passant par la CAO, la programmation, l’électronique et bien sûr quelques problèmes rencontrés.


Notre projet a débuté par une phase de recherche

Avant de nous lancer dans la conception de notre robot, nous avons cherché à comprendre comment un robot 5R fonctionne. Pour cela, nous avons fait de nombreuses recherches sur la cinématique inverse, les angles que les servomoteurs doivent réaliser afin que la tête d’impression aille aux coordonnées cartésiennes que nous souhaitons. Pour cela nous avons fait des simulations avec les servomoteurs sur TinkerCAD pour comprendre comment manipuler les servomoteurs et comment fixer les angles afin de pouvoir maîtriser les mouvements des bras.

Simulation des servomoteurs avec potentiomètres à l’aide du logiciel TinkerCAD

Après ces essais et de nombreux schémas, nous sommes parvenus à établir trois fonctions qui seront utiles pour déplacer les bras aux coordonnées souhaitées :

//consine formula function
double cosineRule(double a, double b, double c) {
    return acos((sq(a)+sq(c)-sq(b))/(2*a*c));
}

//distance computation macro 
#define dist(x,y) sqrt(sq(x)+sq(y))

//atan2 formula macro 
#define angle(x,y) atan2(y,x)


Conception de notre robot sur SolidWorks

La deuxième étape est de concevoir notre robot sur Solidworks. Nous avons modélisé les bras, les avant-bras, le socle et son couvercle. Le socle, le robot en lui-même, contient les servomoteurs ainsi que le ruban phosphorescent qui a été placé dessus. Lors de la modélisation des bras, nous avons fait face à un problème majeur. En effet, lors de la première impression, les bras et les avant-bras étaient de la même taille, en plus d’être trop long. En faisant des essais avec les servomoteurs, nous nous sommes rendus compte qu’à cause de leur taille, les bras allaient trop facilement dans leur position limite. C’est-à-dire comme le montre l’image suivante :

Voici quelques vues de nos bras, de notre socle et enfin de l’assembage de notre robot avant l’impression, après avoir rectifier le problème rencontré :

Modélisation du bras 1
Modélisation du bras 2

Ce bras ci-dessus (bras 2) est un peu plus épais que les autres afin qu’on puisse garder la tête d’écriture parfaitement parallèle par rapport à l’écran de ruban.

Modélisation du bras 4 (avec la tête d’écriture)
Vidéo de l’impression 3D des bras du robot
Modélisation du socle
Vidéo de l’impression 3D du socle de notre robot

Après avoir modélisé chaque pièce une par une, nous les avons assemblées afin de mieux visualiser notre robot final.

Modélisation de l’assemblage complet

Assemblage & programmation de notre robot

Ensuite, une fois l’impression terminée, les bras réimprimés plus petits, nous avons assemblé chaque composant entre eux, collé le ruban adhésif phosphorescent sur le robot, fixé les bras sur les servomoteurs. Après avoir reçu tous nos composants dont le module horloge afin d’écrire l’heure correctement, nous avons soudés et connectés les câbles sur la carte Arduino.

Voici une image de notre robot avec tous les câbles assemblés. Sur l’image de droite, vous pouvez voir un schéma de l’assemblage sur TinkerCad afin de mieux visualiser les branchements de chaque composant.

À partir de ce moment-là, nous devions essayer le programme que nous avions développé en même temps que la modélisation et l’impression. Lors du lancement de notre programme, le robot affichait l’heure mais à l’envers c’est-à-dire en mode miroir (comme vous pouvez le voir sur la vidéo ci-contre). Nous avions donc un problème avec notre repère des coordonnées. En effet, en faisant de multiples tests, nous avons compris que le sens de l’axe des x était inversé.

Après avoir identifié le problème, nous devions le corriger dans notre programme, inverser le sens des chiffres, mais aussi inverser le sens de l’écriture. Nous avons donc modifié les coordonnées de chaque chiffre et nous avons repensé leur position sur l’écran d’écriture. Dû au fait d’une calibration non parfaite, des petits réglages ont été effectués pour que les chiffres soient droits. Prenons l’exemple du chiffre 2 :

Avant l’ajustement :

 case 2: 
            digitStart(0,3/4);
            digitArc(1/2,3/4, 1/2,1/4, 1/2, -1/8);
            digitArc(1,0, 1,1/2, 3/8, 1/2);
            digitMove(1,0);
            break;

Après l’ajustement

case 2: 
            digitStart(1,3/4);
            digitArc(1/2,3/4, -1/2,1/4, 1/2, -1/8);
            digitArc(0,0, -1, 1/2, 3/8, 1/2);
            digitMove(0,1/4);
            break; 

Pour finir, pour que notre robot soit autonome, nous avons ajouté une batterie. De plus, nous voulions mettre un interrupteur afin qu’on puisse éteindre l’alimentation de notre carte Arduino pour que la batterie dure plus longtemps. Nous nous sommes vites rendus compte que notre module horloge devait être alimenté en continue pour qu’il écrive l’heure en temps réel. Notre projet de mettre un interrupteur n’était donc pas possible avec ce module horloge. Il existe d’autres modules horloge qui possèdent une pile intégrée afin qu’ils restent constamment alimenter pour qu’ils ne perdent pas l’heure. Nous avons donc décidé de mettre des piles rechargeables 6V de 1600mA pour éviter qu’elles ne se déchargent trop vite.


Bilan & Critiques

Ce projet a été très enrichissant et intéressant. Nous avons pu mettre à profit de nombreuses compétences notamment en conception mais aussi en électronique, en électricité et en programmation. La partie la plus dure a été la programmation avec un langage qui était nouveau pour nous.

De plus, nous avons appris à être autonome et prendre des décisions dans un projet de A à Z. Savoir se débrouiller face à différents problèmes et ne pas abandonner sont aussi deux points importants dans un projet. De plus, le travail d’équipe est une compétence essentielle pour le bon déroulement d’un projet. Nous avons donc dû savoir s’écouter entre coéquipier, exprimer chacun ses idées. Nous n’étions pas forcément toujours d’accord sur certaines choses mais en discutant ensemble, nous trouvions toujours un compromis.

Notre robot n’est qu’un prototype, il y a donc certaines choses à améliorer comme l’alimentation de la carte Arduino ou bien le module horloge. De plus, nous pourrions développer davantage notre programme pour qu’il est différente fonctionnalité comme écrire la date ou dessiner quelque chose demandée par l’utilisateur. Pour aller plus loin, développer une application pour le diriger depuis son portable pourrait être intéressant afin d’avoir de multiples fonctionnalités.

Nous tenons à remercier notre référent, M. LAGRANGE, pour nous avoir aider et guider tout au long de ce projet.

Merci pour votre lecture !!!

Mohamad DEIRI / Méline TARLEVE

Relier les centres de cercles avec le Robot Dobot Magician

Relier les centres de cercles avec le Robot Dobot Magician

Bonjours à toutes et tous !

Nous sommes trois étudiants en deuxième année du cycle préparatoire à Polytech Angers (Enzo, Hippolyte et Léo). L’objectif de notre projet est de détecter puis relier des cercles de mêmes couleurs grâce à un feutre tenu par le Robot Dobot Magician. L’une des contraintes demandées est d’avoir une caméra directement accrochée au robot et non posée à côté de ce dernier. Un robot tel que le Dobot Magician, est à but didactique, mais le fonctionnement algorithmique pourrait être utilisé à grande échelle, en usine, pour trier et réorienter un ensemble de pièces par exemple.

Si vous le souhaitez, une vidéo de présentation est disponible (avec tous les documents de notre projet) dans ce lien drive :

https://drive.google.com/drive/folders/1UxkdQfwdgCEFTwE-POVpguWi9XRQfONz?usp=sharing

Pourquoi ce projet ?

Nous avons choisi ce projet, car chacun des domaines qui allaient être abordés nous plaisaient : Conception ; Programmation ; Robotique et Impression 3D. De plus, nous avions tous les trois le souhait d’aller en SAGI l’année prochaine donc travailler sur ce projet allait nous apporter une première idée plus poussée de ces domaines

Notre Projet se compose de 5 étapes principales :

  • Expérimentation
  • Recherche de solutions et Modélisation de l’outil caméra
  • Développement du système de control
  • Développement du code de traitement d’images
  • Développement de l’interface graphique

Nous avons entamé notre projet par une phase de recherche.

Nous nous sommes appuyés sur les TP fournis par notre professeur référent pour nous familiariser au matériel. Comme le robot Dobot magician, la caméra, les mathématiques associés et les logiciels propres à notre projet.

Nous avons principalement utilisé 3 logiciels. Tout d’abord, DOBOTSTUDIO, le programme fourni par les constructeurs afin de contrôler le robot. Ensuite, SOLIDWORKS, le logiciel de CAO, que nous connaissions le mieux, il nous a permit de conceptualiser tous les prototypes. Pour finir, nous avons utilisé PYCHARM accompagné de la bibliothèque associée, un encodeur python, avec lequel nous avons développé notre traitement d’image, notre gestion de mouvement du robot et l’interface graphique.

Conception du support caméra

Notre support se divisera en 2 parties. La première est le boitier qui contiendra la carte mère ainsi que la lentille que nous avons extraite de la caméra. Afin, que la lentille soit le plus parfaitement possible parallèle à la feuille, nous avons rajouté des renforts pour fixer la carte dans le boitier. L’objectif est de réduire au maximum le décalage qu’un angle entre la lentille et la feuille puisse créer.

Le Boitier

La deuxième partie du support caméra, permet d’accrocher le boitier au robot, il se divise en 2 sous-parties qui viennent se fixer autour du feutre. Le boitier vient donc s’accrocher par l’intermédiaire d’un rail sur lequel le jeu a été calculé de façon à ce qu’il glisse facilement, et soit parfaitement stable lors des mouvements du robot.

Accroche
Accroche Solidworks

Après avoir tout imprimé et assemblé, voici le résultat :

Robot Dobot Magician avec le support caméra

Programmation du robot

On va maintenant s’intéresser à l’autre partie également importante de notre projet, à savoir la programmation.

En effet, le but étant de relier tous les cercles de la même couleur, on se doutait dès le début qu’il y aurait un travail conséquent sur le traitement d’image, domaine dans lequel nous n’avions que peu d’expérience.

Nous avons créé un programme de près de 290 lignes en langage python, car les fonctions qui permettent de contrôler notre robot sont écrites dans ce langage.

Nous avons passé nos premières séances sur la programmation à comprendre et à tester ces différentes fonctions afin de voir comment le robot réagissait aux différentes commandes et d’identifier ce qui pourrait potentiellement poser un problème par la suite.

À partir de là, il ne nous manquait plus qu’à définir ce qu’on allait devoir faire pour ensuite créer notre algorithme.

À partir de cet algorithme, nous avons pu créer un programme fonctionnel, mais une autre idée nous est venue : celle de faire une interface graphique qui permettrait à l’utilisateur de contrôler le robot étape par étape et qui serait beaucoup plus agréable esthétiquement parlant.

L’interface Graphique

L’interface graphique avait de nombreux intérêts (accompagnés de nombreux inconvénients), notamment la facilité d’utilisation pour quelqu’un ne connaissant pas notre projet.

interface graphique de notre programme

Le bouton Home (en haut à gauche) permet au robot de se placer en condition initiale et de recalibrer ses déplacements.
Juste en dessous, c’est le bouton qui place le robot en position initiale, sans la phase de recalibrage, ainsi, on évite cette étape qui peut être plutôt longue. Cependant, lors de l’activation du programme, il est conseillé d’utiliser le home du robot (premier bouton) afin d’être plus précis.
À nouveau en dessous, c’est le bouton qui active la prise de la photo. Afin d’avoir une photo de bonne qualité, mais surtout utilisable, il faut placer le robot en conditions initiales.
Enfin, les ronds de couleurs (milieu-bas) permettent de choisir quels cercles on souhaite relier. Bien sûr, cette étape nécessite d’avoir prit la photo avant.

Au milieu de cette interface se trouve le logo de notre projet, de son nom Tomi, c’est notre mascotte.

Enfin voici une vidéo de notre robot après toutes ces étapes :

Bilan

Ce projet nous a beaucoup apporté, que ce soit en programmation et sur le traitement d’image où nous n’avions aucune connaissance, ainsi que sur le fait de devoir toujours faire face à des problèmes imprévus lorsque nous commencions une tâche. On peut prendre en exemple la lumière pour le traitement d’image qui nous a posé beaucoup de problème !

Pour nous le plus important dans ce projet a été le travail de groupe et l’importance de s’entourer des bonnes personnes afin d’échanger et de s’entraider au maximum !

Vous pouvez retrouver tous nos documents ainsi qu’une vidéo de présentation du projet dans ce lien drive :

https://drive.google.com/drive/folders/1UxkdQfwdgCEFTwE-POVpguWi9XRQfONz?usp=sharing

Merci pour la lecture !

  • Bossuet Léo – Kukla Hippolyte – Richard Enzo

Création d’un robot magicien

Bonjour et bienvenue à vous sur cet article.

Nous sommes Manon Boursicot et Anthonin Devas, deux étudiants de deuxième année à Polytech Angers et comme tous les deuxième année ici, nous devions travailler sur un projet durant une centaine d’heure pendant notre second semestre.

Nous avons choisi en tant que projet de travailler sur un robot, mais pas n’importe quel robot. En effet, notre projet est de créer un robot magicien. Ce robot pourrait servir à Polytech en tant que représentant des projets de deuxième année lors des forums ou portes ouvertes car c’est un projet que l’on peut montrer facilement. Ce projet a été inspiré par un robot existant créé par Mario the Maker Magician dont vous pouvez retrouver des vidéos sur YouTube, comme celle-ci par exemple : https://www.youtube.com/watch?v=WYQEZXXEfhc

Nous n’avons malheureusement pas réussi à terminer notre projet mais nous allons tout de même vous le présenter et vous en parler.

Maintenant, vous vous demandez peut-être ce que veut-dire un “robot magicien”. C’est tout simplement un robot capable de réaliser un tour de magie. Ce projet comprenait beaucoup d’étapes différentes. Pour réaliser ce robot, nous avons dû, tout d’abord, lui trouver un tour. Nous avions comme contrainte supplémentaire qu’il devait le réaliser plusieurs fois d’affilée sans intervention humaine. Une fois trouvé, nous avons dû créer le design, puis le modéliser en 3D avant de finalement l’imprimer grâce aux imprimantes 3D présentes dans l’établissement. Tout ça représente la partie mécanique, à côté de ça, il y avait la partie programmation où nous avons dû créer tous les mouvements que ferait le robot en language Python à l’aide d’une carte Raspberry Pi ainsi que faire fonctionner un écran. 

Le design

Pour le design, nous avions comme contrainte qu’il soit facilement transportable. C’est donc pour cela que nous avons décidé de faire un cube. Nous avons rajouté un bras pour qu’il soit capable de réaliser le tour.

Modèle 3D contenant le cube (en vert) et le bras (en rouge)

Nous voulions donner de la vie à notre robot et du plastique qui bouge ne suffirait pas. Nous avons donc ajouté un écran et créé des animations qui se jouerait pour que le tour soit plus expressif et par la même occasion, cela pourrait distraire une personne qui essaierait pour ne pas qu’elle voit les secrets du tour. Les animations de l’écran représentent le visage de notre robot, nous avons choisi, à deux, de créer un chat cyclope. C’est une image familière, un chat, mais avec une touche d’originalité qui saurait capter l’attention.  Ainsi, étant un Chat Cyclope en forme de Cube, trois mots commençant par C, nous l’avons appelé C³.

Le tour de magie

Vous savez à présent à quoi ressemble le robot, mais vous vous demandez peut-être ce qu’il doit faire. Nous avons cherché plusieurs tours sur internet et avons choisi de réaliser celui-ci (à 3:38 dans la vidéo): https://youtu.be/XqmcqWW_JRg?t=218

L’idée est basiquement, avec deux pièces et un verre, de faire semblant de faire passer une des pièces à travers le verre alors qu’en réalité on a fait tomber la deuxième dedans et caché la première.

Illustration du tour de magie

Pour faire faire ce tour à un robot il y a évidemment de nombreuses étapes à modifier car il ne sera jamais aussi agile qu’un humain. Il faut prendre en compte le fait que chaque axe dans lequel le robot devra faire un mouvement représente un moteur différent que nous devrons programmer plus tard. Il faut donc limiter les mouvements nécessaires au maximum.

Pour réaliser le tour nous avons un bras qui tient le verre et une pièce visible posée en dessous (image 1). Au moment où on démarre, le bras tapera le sol au niveau de la pièce, la cachant par la même occasion. La plateforme sur laquelle se trouve la pièce tournera alors, cachant celle-ci (image 2). Au même moment, le bras qui tient le verre fera tomber la deuxième pièce qui était cachée à l’intérieur depuis le début (image 3).

La modélisation et l’impression

Nous avons passé de nombreuses heures à modéliser le robot sur le logiciel SolidWorks. Chaque partie a dû être modélisée séparément en imaginant comment elle serait attachée aux autres autours d’elle. 

Nous étions des débutants complets pour tout ce qui concerne des problèmes mécaniques en termes de création, nous avons donc trouvé des inspirations dans ce que nous connaissons : des objets du quotidien. Nous pouvons citer notamment le bouchon d’une bouteille d’eau classique duquel nous nous sommes inspirés.

En tout nous avons 13 pièces complexes et différentes que nous avons entièrement imaginé et créé.

L’ensemble de nos pièces modélisées

C’est à partir de cette partie en réalité que nous avons commencé à avoir des problèmes. En effet, mis à part les difficultés de la modélisation en elle-même, il y a eu des difficultés d’impression. La partie principale, le gros cube que vous voyez sur la photo au-dessus, ne pouvait pas être imprimé car il demandait plus d’une bobine de plastique (presque trois), ce que l’imprimante ne peut pas faire. Sans ce cube, la majorité des pièces créées n’avait pas d’utilité et nous n’avons donc imprimé que les parties composants le bras et la plaque sur laquelle se fait le tour.

La programmation : Raspberry Pi, écran et moteurs

Cette partie est la dernière du projet et n’est donc pas terminée. Nous avons fait face à de nombreux problèmes que nous ne pouvions pas régler simplement ici.

Nous avons choisi pour le projet de travailler avec une carte Raspberry Pi. Pour ceux qui ne le savent pas, c’est, dans l’idée, un petit ordinateur qu’on peut programmer pour contrôler tout notre système.

Photo d’une Raspberry Pi 3

Après avoir mis un système d’exploitation sur la carte (un équivalent à Windows ou linux mais pour Raspberry), nous avons essayé de faire fonctionner l’écran. Nous pouvons l’allumer sans problème mais nous avons compris trop tard qu’il fallait une carte SD très précise pour faire fonctionner les animations dessus. Il fallait une carte de moins de 2GO, déjà très dure à trouver, mais aussi qu’elle soit compatible avec l’écran ce qui n’est pas le cas de toutes les cartes SD. Malgré que tout soit prêt, nous n’avons donc pas pu faire fonctionner l’écran.

Photo de l’écran

Nous avons programmé les moteurs en python, langage que nous avions déjà utilisé donc il n’y avait pas trop de problèmes. Nous avons trouvé un modèle de code sur internet pour faire fonctionner des moteurs en python avec une Raspberry et avons donc modifié celui-ci pour réussir à faire tourner les moteurs. <image moteurs/code>

Bilan

 Au final, notre projet n’est pas terminé mais nous avons quand même gagné des compétences utiles grâce à celui-ci, notamment en mécanique et électronique, où nous avons pu pratiquer les domaines comme on ne le fait pas normalement en cours. Nous sommes tout de même satisfaits par certains aspects, comme l’animation où, malgré certains problèmes, les modèles que nous avons pu produire. 

Même si nous sommes déçus du résultat, nous espérons que, si ce projet est repris l’année prochaine, il pourra être fini et perfectionner grâce à ce qu’on a pu faire cette année.

Nous vous remercions de votre lecture et espérons que vous avez trouvé notre projet intéressant.

Manon Boursicot et Anthonin Devas

Images utilisées dans cet article:

Moteur: https://www.robotshop.com/ca/fr/servomoteur-a-rotation-continu-parallax-futaba.html

Écran: https://4dsystems.com.au/products/4d-intelligent-hmi-display-modules/raspberry-pi-compatible-kits/gen4-ulcd-70dt-pi

Raspberry: https://www.desertcart.ae/products/59401529-raspberry-pi-3-model-b

Conception et optimisation d’un robot DiWheel

Robot DiWheel 2021

Robot DiWheel 2021

Bonjour à toutes et à tous
Nous sommes heureux de vous présenter notre projet, le robot DiWheel. Notre robot se base sur une structure de LEGO, mais beaucoup de travail technique a été nécessaire pour mener ce passionnant projet à bien.
Si cela vous intéresse, n’hésitez pas, et cliquez sur ce lien pour en savoir plus !
-> Lire l’article complet <-

Conception et optimisation d’un Robot DiWheel

Prototype d’un robot DiWheel

Robot DiWheel 2021

Robot DiWheel 2021


Bienvenue chers visiteurs !

    Étudiant à Polytech Angers nous avons eu, Adrien Soubrane et Corentin Amoruso, la chance de travailler sur l’un des projets proposés au cours de notre dernier semestre. Notre choix s’est porté sur l’étude du robot DiWheel !

    Un DiWheel est un véhicule avec deux grandes roues latérales. Il a été inventé en 1880 mais n’a pas conquis le grand public, ce qui l’a fait disparaitre.
    En effet, les balancements sont le principal défaut de ce moyen de transport.

    L’objectif a été de concevoir un prototype de A à Z à l’aide du kit LEGO Mindstorm EV3 mais aussi d’étudier la stabilité de ce dernier.
    Ce travail est une partie très importante car il permet de modéliser le robot, à la manière d’une maquette, avant de pouvoir le répliquer à échelle humaine.
    C’est donc un projet sur la durée, et nous espérons sincèrement qu’un grand modèle verra le jour à Polytech Agers, grâce (en partie) à nos travaux.
    Le contrôle du robot doit se faire en Bluetooth, dans notre cas avec une application smartphone.

    Ce projet est très complet : nous avons dû, d’ans l’ordre, concevoir le robot, le contrôler, illustrer son comportement via des capteurs, modéliser mathématiquement le système, et mettre en place une loi de commande, pour réguler les oscillations.

  1. Pour commencer, la conception :
    La première phase du travail, probablement la plus créative, est celle de la construction du robot ! Nous utilisons Studio 2.0 pour visualiser notre système.
    Avant toute chose, nous avons cherché un logiciel nous permettant de modéliser les pièces LEGO. Après quelques recherches, nous nous sommes tournés vers Studio 2.0.
  2. Exemple de modélisation sous Studio 2.0

    Exemple de modélisation sous Studio 2.0

    Nous devons réduire au maximum les oscillations, et nous devons y penser dès la création de la structure.
    Nous avons donc choisi de placer la brique EV3 non pas au niveau de l’axe des roues mais en dessous. Cela permet d’abaisser le centre de gravité, en le plaçant sous l’axe des roues.

    Pour la conception des roues, le choix de l’imprimante 3D était intéressant, mais trop contraignant, surtout avec le confinement. Nous avons donc décidé d’utiliser des quarts de roues LEGO. Nous n’avions plus qu’à trouver un moyen de les fixer à l’EV3.

    Arc de roue dentée

    Arc de roue dentée


    Roue du robot

    Roue du robot



    Pour que le Diwheel avance sans soucis, il fallait trouver la meilleure configuration possible avec les différents engrenages et pièces LEGO à notre disposition. L’important était avant tout de réussir à transmettre le plus d’énergie possible des moteurs vers les roues. Pour cela, nous devions réfléchir à comment réduire au maximum les frottements pour permettre aux roues et aux engrenages de tourner le plus librement possible. Moins les frottements sont importants, meilleur sera le rendement.

    Mécanisme côté gauche

    Mécanisme côté gauche

  3. Après, le contrôle du robot :

    L’étape suivante du projet a été de trouver une nouvelle manière de contrôler le DiWheel. En effet, ce dernier ne dispose que d’un seul moyen pour cela : appuyer directement sur les boutons de la brique EV3. C’est pourquoi nous voulions trouver un moyen plus amusant et pratique pour faire avancer notre robot. C’est de cette réflexion qu’ont découlées les idées de contrôler le DiWheel à l’aide d’une manette et d’une application.

  4. A la manière d’un Mario Kart, nous voulions pouvoir maîtriser notre robot à l’aide d’une Wiimote et du gyroscope intégré.
    Pour cela, nous voulions nous servir de la communication Bluetooth commune à l’EV3 et à la manette. Il fallait donc trouver un moyen de programmer la Wiimote afin de communiquer avec la brique EV3. La solution la plus simple est d’utiliser GlovePIE. C’est un logiciel dédié pour la Wiimote permettant de l’utiliser avec n’importe quel périphérique.
    Malheureusement, compte tenu des conditions de travail (confinement, matériel, problème de Bluetooth…) nous n’avons pas pu connecter les deux périphériques ensembles. Néanmoins la solution reste viable si BlueSoleil ou un autre pilote fonctionne sur l’ordinateur utilisé pour la manipulation.
    Une autre solution existe : modifier le système d’exploitation de la brique pour utiliser un programme disponible sur internet. Mais cette dernière nous semblait trop risquée, nous ne voulions pas endommager l’EV3.

    Manette WiiMote Source: https://nintendo-museum.fr/wii-wheel/

    Manette WiiMote
    Source: https://nintendo-museum.fr/wii-wheel/

    Cependant, grâce à RemotEV3, une application android, nous pouvons commander le robot via bluetooth.
    Le robot peut ainsi être dirigé dans toutes les directions et tous les sens.
    La connexion étant plus simple avec un smartphone, nous n’avons eu aucun souci de fonctionnement.

  5. Ensuite, la modélisation du système :

    Elle se déroule en trois parties : l’étude du système, la représentation d’état et l’expérimentation.

    L’étude du système consiste à déterminer l’ensemble des constantes, des forces et des vitesses appliquées au robot afin de déterminer un modèle théorique. Il servira pour déterminer une représentation d’état contenant les variables que nous voulons changer. C’est pourquoi il ne faut pas perdre de vue notre but : réduire les balancements.
    Notre choix s’est donc porté sur le modèle Lagrangien nous permettant d’obtenir les formules de l’accélération angulaire des roues et du corps. En effet, en atténuant les variations d’accélération, le robot deviendra plus stable.
    Après simplification nous avons obtenus les formules respectives de l’accélération du corps et celle des roues :

  6. Équations de Lagrange

    Équations de Lagrange

    Une fois que nous avons obtenu nos formules, on s’est intéressé à la représentation d’état. Grâce à cette loi de commande on peut comprendre de manière théorique comment évoluent nos variables.
    Une représentation d’état est composée d’une entrée X, d’une sortie Y et de différentes matrices (A, B, C et D) montrant l’évolution du système.
    A l’aide de Scilab, nous avons confirmé théoriquement l’instabilité du système. En effet, après avoir reproduit virtuellement le système à l’aide de la représentation d’état, nous avons simulé et obtenu la courbe correspondant à l’angle du corps par rapport à l’axe y. Cette dernière forme une sinusoïde caractéristique d’une instabilité (ici des balancements). Certes les valeurs et le comportement obtenu sont cohérents, néanmoins pour pouvoir les utiliser il faut vérifier expérimentalement si cela concorde avec la réalité.

    courbe modélisation (sinusoïdale)

    courbe modélisation (sinusoïdale)

    Avec le logiciel (Windows) LEGO Mindstorm EV3 et grâce aux capteurs gyroscopiques et l’accéléromètre fournis dans le kit, nous avons pu prendre quelques mesures. En comparant les valeurs obtenues avec les capteurs et celles de la simulation, nous avons pu confirmer que notre modèle est utilisable pour la commande du système.

    Courbe gyroscope (robot instable)

    Courbe gyroscope (robot instable)


    positionnement des capteurs

    positionnement des capteurs

    Enfin, commander le système :

  7. Une fois la commandabilité du système étant assurée par le critère de Kalman, il ne suffisait plus qu’à trouver comment influencer le système.
    Nous avons donc décidé d’utiliser une commande par retour d’état pour asservir le système. Cette méthode se base sur l’utilisation d’un gain correcteur afin de modifier en temps réel la sortie.
    Le but est ainsi d’obtenir, par le capteur gyroscopique, non plus une courbe sinusoïdale mais une courbe de système de premier ordre. Elle est reconnaissable via deux phases : une transition (la valeur de la sortie varie) et une stabilisation (la sortie atteint une valeur limite).
    Après simulation sur Scilab ou Matlab et si les résultats sont concluants, on peut implémenter cette loi de commande sur l’EV3. Certes le robot ira moins vite, mais il est devenu beaucoup plus stable.
  8. Exemple de simulation sous Scilab

    Exemple de simulation sous Scilab

    Bilan :

    Ce projet a été pour nous une occasion de nous amuser et de travailler plus en profondeur sur des notions complexes. Il nous a permis de développer nos compétences dans différents domaines (Physique, mathématique, automatisme, conception…).
    Nous avons aussi appris à travailler en équipe, en autonomie et à surmonter les difficultés à l’aide de nos connaissances, et grâce à nos recherches.
    Même si le projet n’a pas abouti au niveau de la commande par retour d’état, nous sommes fiers d’avoir obtenu un DiWheel fonctionnel et commandable via smartphone.

    Ressources :

    Le projet touchant à sa fin, il nous tenait à cœur de pouvoir vous donner la possibilité de continuer ce dernier. En effet, si vous disposez vous aussi du kit LEGO Mindstorm EV3 et que vous souhaitez reproduire et améliorer notre robot, nous mettons à votre disposition l’ensemble des étapes de construction :
    Compte rendu et instructions de montage

    Ce drive contient également notre compte rendu de projet, que nous vous incitons vivement à consulter si vous souhaitez reproduire un robot du même style.

    Pour plus de question, n’hésitez pas à nous contacter via nos adresses mail respectives :

    • corentin.amoruso@gmail.com
    • adsoub@gmail.com

    Merci pour votre lecture ! A très vite !
    Corentin & Adrien

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.

Robot Cartographe

Introduction

Bonjour à toutes et à tous, dans cet article on va vous présenter le projet de conception de robot cartographe que l’on a effectué au cours de notre 2nde année au sein de Polytech Angers. Nous en sommes en groupe de trois : Swan, Emilien et Jean-Luc afin de réaliser ce projet qui a déjà été réalisé à plusieurs reprises les années précédentes (projet ROMULUX présenté via ce lien).

On va aborder maintenant la question de l’utilité de ce projet. Ce projet propose de concevoir un robot permettant l’acquisition de données pour tester des algorithmes de cartographie et de localisation. Ce projet a pour but premier de cartographier un étage complet des bâtiments de Polytech (cependant, on ne s’occupera pas du codage du robot).

 

Organisation

Sachant que les séances de projet de conception n’avaient pas lieu en présentiel, on a dû s’adapter et apprendre à utiliser un logiciel du nom de Gitlab. Gitlab est un outil qui permet de stocker et partager des fichiers qui fonctionne comme un cloud avec certaines spécificités telles que des checkpoints, points de contrôle, et quelques autres.

 

Cahier des charges

Afin de pouvoir réaliser un tel robot, il nous faudra plusieurs éléments (annoncés dans le cahier des charges) :

    • Utilisation d’une carte NVIDIA Jetson TX2
    • Utilisation des roues “mecanum”
    • Étage modulable permettant à minima le positionnement de 4 caméras et un capteur Lidar Velodyne (qui est un radar fonctionnant avec la lumière)

Afin de réellement commencer le projet, on a tout d’abord schématisé de diverses manières ce projet. En commençant par un schéma bête à corne :

Bête à corne

Bête à corne

 

Chaîne de fonctionnement

On a ensuite réalisé divers schémas exprimant la chaine de fonctionnement de notre robot cartographe. Voici le schéma principal :

Schéma fonctionnel

Schéma fonctionnel

 

Après cela, on a réalisé un inventaire des composants afin d’être structurés, mais aussi, afin de pouvoir définir et dimensionner le type de batterie souhaitée en faisant un bilan énergétique. Finalement, on a dû opter pour des batteries NIMH, car elles correspondaient bien à notre bilan énergétique, et car le labo n’était pas adapté pour des batteries lithium-ion.

 

Placement Lidar Velodyne

On a dû ensuite trouver un emplacement optimal pour le radar LIDAR Velodyne (afin qu’aucun obstacle ne gêne ses rayons lumineux qui lui permettent de capter à 360° autour de lui-même).

LIDAR Velodyne

LIDAR Velodyne

Pour se faire, il suffisait de choisir où le placer sur notre robot (nous avons choisi le centre). Afin de déterminer la hauteur à laquelle le placer, il suffisait d’utiliser de la trigonométrie basique. On a donc pu obtenu facilement les coordonnées du positionnement du LIDAR Velodyne.

 

Matériau

Il nous manquait donc un dernier détail à régler avant d’entamer la CAO (Conception Assistée par Ordinateur) qui était le choix du matériau. Après quelques discussions avec nos encadrants, il s’avérait que l’impression 3D n’était pas une option viable pour l’architecture que l’on voulait adopter (matériaux trop fragiles) mais que l’usinage était un moyen plus adapté notamment grâce à son matériau : l’aluminium qui allait être le matériau principal constituant notre robot.

 

CAO

On pouvait donc enfin commencer la CAO qui était au cœur de notre projet. Tout d’abord, on a conceptualisé les divers composants constituant notre robot (NVIDIA Jetson, LIDAR Velodyne, les 4 caméras, les contrôleurs moteurs, les moteurs, les batteries, …).

On a commencé à faire une première ébauche sur le logiciel SolidWorks ce qui nous a permis d’avoir un premier ressenti de notre encadrant sur l’architecture que l’on voulait adopter pour notre robot cartographe :

1ère ébauche du robot cartographe

1ère ébauche du robot cartographe

Cependant, on voit clairement un manque de rigidité sur notre structure (éléments sélectionnés en bleu), une complexité hors norme au niveau des pieds de notre robot, ainsi que la hauteur entre les 2 étages qui n’est pas adaptée.

 

Ces problèmes ont été résolus en changeant simplement la structure des éléments problématiques, ce qui nous mena à la réalisation d’une seconde et dernière ébauche :

CAO final du robot cartographe

CAO finale du robot cartographe

 

Conclusion

Malheureusement, c’est ici que s’achève ce projet pour notre groupe car nous n’avons pas été assez efficaces afin d’avoir une réalisation physique de ce robot cartographe. Mais peut être allez-vous aboutir ce projet.

 

Nos remerciements vont à nos encadrants :

M. GUILLONNEAU et M. MERCIER

 

JOTTREAU Emilien, GAUVRIT Jean-Luc, NOBILI Swan

 

Création d’un boîtier de commande pour robot Dobot Magician

Bonjour à tous, je suis étudiant en deuxième année à Polytech Angers et mon projet de fin d’année a été de construire un boîtier de commande pour le robot Dobot Magician. Le boîtier a pour but d’être utilisé pour les travaux pratiques des étudiants de SAGI (Systèmes Automatisés et Génie Informatique). J’ai pour cela déjà à disposition un boîtier métallique vide, des interrupteurs et des LED.

Photo du robot Dobot Magician

Robot Dobot Magician

Communication avec le robot :
On peut connecter le robot à un ordinateur via un câble USB. Le constructeur fournit un logiciel « Dobot Studio » qui permet de programmer en python, les librairies (morceaux de code fournis par le constructeur) sont déjà installées et on peut faire bouger notre robot.

Le robot possède plusieurs connecteurs à l’arrière, certaines broches de ces connecteurs peuvent être utilisées pour envoyer du courant (peut allumer une LED) et d’autres mesurent si il y a du courant (sers d’interrupteurs).

Photo montrant les connecteurs du robot Dobot Magician

Connecteurs Dobot Magician

Les montages suivants permettent respectivement d’allumer une LED et de détecter l’état d’un interrupteur.

Schéma électrique du branchement d'une diode

Branchement diode

Schéma électrique du branchement d'un interrupteur

Branchement interrupteur

_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_

Construction du boîtier :
Le boîtier possède 4 interrupteurs et 5 LED. Pour les placer sur le boîtier j’ai percé les trous à la perceuse. Les interrupteurs tiennent au boîtier grâce à des écrous, les LED tiennent grâce à des supports en plastique. A l’arrière du boîtier il a fallu faire un trou rectangulaire, fait à la Dremel, pour faire passer le cable.
Les composants sont soudés à l’intérieur sur une plaque de soudure qui est elle-même collée à la glue dans le boîtier.

Vue de dessus du boîtier de commande

Boîtier de commande

Programme de démonstration :
Pour montrer comment fonctionne le boîtier et comment il peut être utilisé j’ai fait un programme de démonstration.

Diagramme fonctionnement du programme de démonstration

Diagramme fonctionnement du programme de démonstration

Déclaration des variables : Initialise toutes ces variables, c’est ici qu’on déclare quelles broches sont des LED et quelles broches sont des interrupteurs.
« Home » + allumage LED : Le robot lance une routine qui lui permet de bien placer son système de coordonnées. Pendant ce temps on allume les LED pour vérifier qu’elles fonctionnent.
Récupération de l’état des interrupteurs : Stocke la valeur de chaque interrupteur dans une liste pour l’utiliser plus tard.
Déplacement + Changement des paramètres : On fait faire ce que l’on veut au robot. Ici on déplace le robot entre plusieurs points et on change la manière dont il se déplace
Changement d’état des LED : Allume ou éteint les LED si besoin

_
_

Démonstration :

Conclusion :
Le boîtier fonctionne, même si il reste encore beaucoup de choses à améliorer, notamment le câblage au robot qui est pour l’instant trop complexe pour être utilisé en TP. Ce projet m’a permis de me familiariser avec l’électronique et j’ai beaucoup apprécié programmer le robot.

Merci à Jean Louis Boimond, mon professeur référent qui m’a guidé durant ce projet, et à Franck Mercier pour m’avoir appris à souder.

Conception, modélisation, réalisation et commande d’un système mécatronique : Robot Diwheel

par Jad THALAL, Guillaume TREMBLIER, Hugo LE GUILLOUS

Bonjour à tous!

Nous sommes trois étudiants en 2ème année du cycle préparatoire d’ingénieur à Polytech Angers. Dans le cadre de notre formation, nous avons été amenés à réaliser un projet tutoré liant plusieurs domaines (mécanique, capteurs, informatique, modélisation d’un système, automatique…).

photo3

La grande source d’inspiration de ce projet se trouve dans le modèle EDWARD (Electric Diwheel With Active Rotation Damping), il s’agit d’un projet de l’université d’Adélaïde consistant en un Diwheel grandeur nature capable d’embarquer un humain.

le modèle EDWARD

Le modèle EDWARD

Ce projet consistait en la modélisation puis la réalisation d’un robot Diwheel télécommandable par wiimote et automatisé afin de s’auto-balancer. En effet, la structure du robot, avec ses deux grandes roues, a la fâcheuse tendance de se pencher d’une manière trop importante lors des accélérations et des décélérations.

  • Modélisation et représentation du système
  • La première partie du projet a consisté à représenter notre robot Diwheel en un système mécatronique composé de deux parties : les roues et le corps du Robot. En effet, le corps du Diwheel peut être représenté comme un pendule de masse m qui oscille d’un certain angle dû à l’accélérations des roues.

    Représentation du système étudié

    Représentation du système étudié

    À la suite de plusieurs calculs de vitesses, d’énergies cinétiques, d’énergies potentielles et en passant par des équations de Lagrange, qui sont détaillés dans le rapport du projet Diwheel, on a réussi à modéliser par représentation d’états notre Diwheel en utilisant un système à temps continu de type CLSS. Notre système est un système d’ordre 4.
    Cependant, comme on pouvait si attendre, le système en boucle ouverte n’est pas stable, ce qui nous contraint à établir un asservissement du système et ainsi avoir un système en boucle fermé.
    Pour ce faire on a utilisé le logiciel Scilab:

    Système en boucle fermé (Xcos Scilab)

    Système en boucle fermé (Xcos Scilab)

  • Récolte des données/capteur
  • Nous avons par la suite réalisé une expérience pour pouvoir récolter les données de l’angle de balancement de notre Diwheel à l’aide de l’application Lego Mindstorms et du capteur gyroscopique. Dans le but de reproduire le balancement de notre robot en simulation.

    Programme sur Lego Mindstorms pour la récolte des données

    Programme sur Lego Mindstorms pour la récolte des données

    Angle de balancement du Diwheel

    Angle de balancement du Diwheel


    De cette expérience on en conclut que l’angle maximal d’inclinaison et d’environ 40 degrés et qu’au bout de 5s le Diwheel se stabilise et arrête d’osciller.

  • Controle du Robot
  • Cette partie consistait à contrôler le Diwheel avec une Wiimote. Nous nous sommes donc penchés sur plusieurs pistes. Dans un premier temps nous avons essayé de connecter la wiimote directement à l’EV3. Pour ceci nous sommes allés dans les paramètres Bluetooth de l’appareil. La Wiimote était bien détectée par l’EV3 mais lors de l’appairage impossible de connecter les deux ensembles car nous revenions en permanence sur le menu d’appairage. Nous avons tenté aussi de faire un relais avec l’ordinateur, c’est-à-dire que les informations de la Wiimote seraient envoyées à l’ordinateur, et l’ordinateur à son tour les enverrait au Diwheel. Nous avons trouvé des exemples de ce type sur internet et nous avons donc installé Visual Studio Code afin d’envoyer des informations en python à l’EV3 mais nous n’avons pas réussi à envoyer les informations.

    Nous avons quand même pu contrôler le Diwheel à l’aide de nos smartphones, grâce à l’application LEGO MINDSTORMS Commander disponible dans le play store.

  • Conclusion
  • Le résultat final est conforme au cahier des charges car nous avons obtenu dans la forme un prototype capable d’effectuer les actions du cahier des charges. Cependant nous avons eu de gros problèmes avec la partie Scilab ainsi que la partie connectivité ce qui ne nous a pas permis de remplir le cahier des charges en entier. Pour des futurs projets nous pourrions améliorer nos méthodes de travail afin de travailler plus efficacement. Mais les clés qui nous ont manqué pour terminer ce projet sont les connaissances. Tant en programmation qu’en automatique, il est certain qu’avec un bagage plus important nous aurions pu venir à bout de ce projet.

    Développement d’un robot mobile pour la recherche en cartographie

    Bonjour, nous sommes deux étudiants en deuxième année préparatoire intégrée de Polytech Angers. Nous avons décidé de nous lancer dans la conception d’un robot mobile de cartographie, enfin pour être plus précis dans l’élaboration de son châssis. Le but est d’avoir un robot qui puisse accueillir différents capteurs pour acquérir des données, pour par exemple avoir une représentation 3D de l’intérieur du bâtiment de Polytech Angers.

    Un robot comme celui-ci dans le milieu professionnel peut avoir plusieurs utilisations. Par exemple, nous avons découvert dans nos recherches un robot aspirateur qui cartographie votre maison pour pouvoir mieux la connaitre et mieux l’aspirer. Vous imaginez donc qu’il y a d’autres utilisations possibles.

    Il y a eu plusieurs étapes durant la réalisation de ce projet. On a dû d’abord préparer les bases.

    Les schémas fonctionnels :
    Nous avons eu un cahier des charges à respecter. Le robot devait faire une certaine taille, pouvoir accueillir un certain nombre de capteurs plus ou moins différents, etc.
    Il a fallu faire des schémas fonctionnels, pour savoir comment aller communiquer les différentes parties du robot et aussi pour définir ces parties. On a donc eu accès aux fiches techniques des moteurs, de la carte mère et des capteurs pour pouvoir savoir comment tous ces éléments allaient communiquer.

    Ici on voit comment les différents éléments communiquent entre eux

    Ici on voit comment les différents éléments communiquent entre eux

    Le dimensionnement de la batterie :
    Après avoir réalisé ces schémas, on avait accès à pas mal d’informations techniques sur les différents éléments. On a donc pu dimensionner la batterie, c’est-à-dire savoir quel voltage et quelle intensité il fallait pour que le robot fonctionne pendant une durée déterminée. Pour cela, nous avons donc pris les informations techniques de chaque composant et fait un calcul.

    Grâce à Excel on a pu rentrer différentes informations et avec des formules trouver les bonnes dimensions pour la batterie.

    Grâce à Excel on a pu rentrer différentes informations et avec des formules trouver les bonnes dimensions pour la batterie.

    Ici, on avait besoin de 30 minutes d’autonomie et l’on arrive à 5400 mAh, ce qui équivaut à environ deux fois la batterie d’un téléphone moyen. On arrivait aussi à un certain voltage et à une certaine tension, on a donc dû trouver des convertisseurs pour alimenter les différents composants du robot, car ils n’ont pas tous besoin de la même tension/courant.

    La CAO :
    La plus grosse partie du projet. On avait posé les bases, il fallait ensuite élaborer le corps de ce robot. On a donc utilisé un logiciel de CAO pour faire cela. On voulait faire un robot à plusieurs étages avec une petite tour tout en haut pour accueillir le capteur le plus important, le Lidar. On voulait faire un étage inférieur pour accueillir les moteurs, la batterie et la carte mère, puis un étage supérieur avec plusieurs emplacements pour pouvoir poser différents capteurs.

    Le premier résultat que nous avions à montrer avec en bleu la petite tour surmontée du Lidar.

    Le premier résultat que nous avions à montrer avec en bleu la petite tour surmontée du Lidar.

    Après consultation avec nos professeurs, il y avait plusieurs défauts à corriger. Les deux gros points à corriger étaient l’emplacement des capteurs qu’on devait centraliser puis aussi l’originalité, car notre châssis n’apportait rien de spécial. On est donc reparti trouver des idées et après plusieurs essais, on a enfin trouvé une bonne solution pour corriger tous les défauts. On a donc décidé de changer la forme pour faire un robot avec une forme plus ovale, avec les deux roues motrices au centre, pour pouvoir avoir un réel centre pour placer les capteurs. Aussi, on a pris la décision de faire étage inférieur pour les moteurs et la batterie, puis un étage moyen pour la carte mère. Enfin, on a pensé à un troisième étage qui accueillerait un tour modulaire qui elle-même accueillerait les différents capteurs.

    La nouvelle proposition du robot, avec en vert la carte mère, en marron foncé les différents étages à capteurs.

    La nouvelle proposition du robot, avec en vert la carte mère, en marron foncé les différents étages à capteurs.

    Le principe de cette tour, c’est d’avoir des étages qui s’emboitent facilement, sans vis et sans collage, pour pouvoir en enlever ou en rajouter à notre guise.

    Ici on voit une vue éclatée des étages à capteurs avec en marron les troncs, et en violet les "terrasses" à capteurs.

    Ici on voit une vue éclatée des étages à capteurs avec en marron les troncs, et en violet les “terrasses” à capteurs.

    Ces différents étages auraient donc des trous où l’on pourrait emboîter n’importe quel capteur existant, il suffirait de créer un petit adaptateur à chaque fois.
    Le capteur en gris a son adaptateur en bleu qui s'emboîte dans la "terrasse" à capteurs

    Le capteur en gris a son adaptateur en bleu qui s’emboîte dans la “terrasse” à capteurs

    Pour finir, on a fait un adaptateur pour le Lidar pour qu’ils puissent s’emboîter tout en haut de la tour, quel que soit le nombre d’étages. Aussi une petite astuce pour pouvoir faire passer les différents fils entre la carte mère et les capteurs a été de creuser des demi-cercles tout autour des troncs.

    On voit ici en vue du dessus que même tout en haut de la tour on a accès à la carte mère en vert plusieurs étages plus bas.

    On voit ici en vue du dessus que même tout en haut de la tour on a accès à la carte mère en vert plusieurs étages plus bas.

    Conclusion :
    Pour finir le robot, il aurait fallu avoir plus de temps pour réaliser les différentes pièces nécessaires. Le but était de réaliser un châssis qui puisse accueillir différents capteurs et l’on a pu au moins le concevoir en CAO. Le travail des prochaines équipes, s’il y en a, sera de le construire et de le faire rouler, pour acquérir différentes données. Grâce à ce projet, nous avons appris beaucoup sur la conception d’un robot, et toutes les contraintes mécaniques et électroniques que cela implique. La plus grande difficulté sera celle d’avoir eu besoin de se remettre à l’utilisation d’un logiciel de CAO, mais c’est revenu avec le temps. On aurait aimé pouvoir construire le robot et pouvoir toucher à la partie informatique/électronique plus en profondeur, mais cela sera pour une autre équipe d’étudiants.

    Merci d’avoir lu notre article !

    Par Antoine Verin et Macine Benmansour.