Version actuelle datée du 20 février 2020 à 09:12

Démonstrations

Présentation générale

Description

Ce projet se déroule dans le cadre de la préparation a la compétition Euroskills en robotique mobile. Les Euroskills sont la déclinaison européenne de la compétition internationale Worldskills, considérée comme les jeux Olympiques des métiers. Tous les deux ans, pendant 3 à 4 jours, l'affrontent dans une cinquantaine de métiers les champions nationaux de l'ensemble des pays du continent européen.

Cette année nous sommes les représentant de l'équipe de France dans le métier robotique mobile qui permet de mettre en avant les avancés de la robotique dans le domaine industriel. Ce projet fait alors partie intégrante de notre entrainement et notre préparation à la finale européenne à Graz (Autriche) en septembre 2019. Il reprend le les objectifs du sujet de robotique mobile des Worldskills 2019 à Kazan (Russie).

Objectifs

Plan de l'usine dans lequel évolue le robot

Ce projet consiste à la réalisation d'un robot autonome mais aussi pouvant être télé-opéré, évoluant sur un terrain simulant une usine.

À partir de son point de départ, le robot doit être capable de se rendre aux différentes "Workstations" disséminées sur le plateau afin de déposer un "Component carrier" après l’avoir rempli au stand de chargement. La particularité est que sur chaque "Workstation" est inscrit un code barre allant de pair avec celui de l'un des stands de chargement. Le "Component carrier" doit donc y être acheminé sans erreur. L'ordre dans lequel le robot doit se présenter aux workstations peut être soit définie au choix du compétiteur, soit définit par un tirage au sort. Une fois tous les Components carriers aux stands de chargement, le code barre qui leur est associé indique le nombre de boules, la couleur et l'ordre dans lequel y doit être rempli. Les boules sont à disposition du robot dans des emplacements prévus à cet effet.

Préparation du projet

Cahier des charges

Contexte et définition du problème:

Le métier robotique mobile permet de mettre en avant les avancés de la robotique dans le domaine industriel.

Notre PFE consiste à s’entraîner pour la compétition Euroskills en réalisant le sujet de la compétition 2019 : Media:WSC2019_TP23_pre_EN.pdf

Objectif du projet:

Le but du projet est de concevoir un robot capable d’évoluer dans un environnement simulant une usine flexible. Dans cette usine, plusieurs machines peuvent réaliser des opérations sur un produit en cours de fabrication.

Il est donc nécessaire de déplacer le produit d’une machine à une autre pour compléter sa fabrication. L’organisation du terrain est connue, ses dimensions sont de 4x2m, il est intégralement entouré de murets, le sol est globalement plat mais comporte une zone avec dénivelé. Les positions possibles des machines sur le terrain sont prédéfinies, cependant l’assignation des numéros des machines est faite aléatoirement.

Le robot devra être capable de se localiser et se déplacer dans cete environnement. La reconnaissance des machines se fait de manière visuelle via des codes barres et le robot devra comporter un manipulateur adapté au déplacement des balles représentant les produits. Une contrainte étant que les machines ne sont pas toutes situées à la même hauteur sur le terrain.

Une première étape sera de réaliser la tâche de production de manière téléopérée, ensuite le robot devra être capable de produire de manière autonome. Le robot sera construit en utilisant les éléments du kit fourni, comprenant des éléments structurels, ainsi que les actionneurs (motoréducteurs, servomoteurs), les capteurs (capteurs de distances, codeur de moteurs…), et l’électronique de commande (cartes d’interfaces, circuit de puissance pour les moteurs...) nécessaire à la réalisation de la tâche. Le robot sera commandé par un MyRIO de National Instruments programmé, principalement, en LabView.

Choix techniques : matériel et logiciel

Éléments du kit Studica Worldskills

La majorité du matériel et de logiciels utilisés lors de la compétition sont imposés par le sujet. L'ensemble du matériel doit provenir du kit fournit à savoir le kit STUDICA édition Worldskills.

Voici une liste des principaux éléments:

• Contrôleurs
  • Contrôleur MyRio de National Instrument équipé d'un FPGA Xilinx et d'un processeur double cœur ARM Cortex-A9 ainsi qu'un support Wifi. La plateforme de programmation imposée est donc LabView avec les librairies MyRio et les librairies fournies par le constructeur.
  • Carte d'I/O et contrôleur moteur MD2 permettant le branchement facile des différents capteur et actioneurs

• Capteurs
  • Accéléromètre 9 axes NavX
  • 2 Capteurs de distance ultrasons
  • 2 Capteur de distance infrarouges SHARP
  • 1 capteur de lignes
  • Webcam HD
  • Manette filaire Logitech F310

• Actionneurs
  • 4 Moteurs à courant continus équipés d'encodeurs
  • 3 servomoteurs

• Mécaniques
  • Lots de différentes pièces de métal servant au montage du robot
  • Engrenages, courroies, glissière linéaire...
  • Vis et écrous
  • 4 roues omnidirectionnelles
  • Pièces imprimées en 3D possibles

Liste des tâches à effectuer

Hardware :

• Tester et choisir la meilleur forme de châssis
• Montage du bras
• Conception de la piste WorldSkills Kazan 2019
• Electronique/Câblage
  • Acheter un convertisseur de tension pour une alimentation de tous les composants stable
  • Organiser les câbles
  • Annoter les câbles (utiliser des couleurs différentes en fonction de la tension)
  • Sécurité du montage électrique (pochette batterie, fusible, gaine thermo, ...)

Software

• Connecter le robot en Wifi (téléversement et contrôle a distance)
• LabView
  • Découvrir LabView
  • Comprendre/Utiliser les librairies myRio et Robotics
  • Utiliser du code C dans LabView
• Odométrie
• Localisation et suivie de trajectoire (Planification de trajectoire)
• Détection de couleur avec la camera
• Détection de code barre

Gestion de projet

• Définir une méthode de travail
• Déterminer un nom de robot
• Trouver une salle de travail

Calendrier prévisionnel

Etat de l'art

Le métier robotique mobile est apparue pour la première fois dans la compétition Worldskills en 2013 a Leipzig (Allemagne). C'était alors deux anciens IMA Polytech Lille, Florent CHRETIEN et Mélanie LELAURE, qui s'étaient qualifié pour les phases finales mondiales.

Dans les premières années les robots utilisés étaient des Robotinos, suite à un partenariat se sont maintenant des robots Studica qui sont utilisés depuis 2015 en compétition mondiale. Concernant l'équipe de France, une seule équipe avant nous a déjà été confronté à ce kit. Nous sommes en contact avec eux afin de discuter ensemble des problèmes rencontrés et de différentes astuces de programmation. Cependant le sujet de leur finale était très différent du sujet sur lequel nous nous entraînons. Les codes qu'ils nous ont envoyés sont donc inutilisables.

Il existe très peu d'informations sur ce kit et d'exemple de programmation sur internet. En effet étant conçu pour des compétitions internationales il existe peu d'utilisateurs, et personne ne souhaite partager ses codes aux pays adverses. Nous partons donc presque de zéro.

Réalisation du Projet

Prélude

PROMEO, découverte du kit

Stage de découverte/formation PROMEO Beauvais

Le 18 et 19 décembre 2019, nous avons été invités avec notre expert métier, Florent CHRETIEN, a PROMEO pour découvrir le kit "Studica Worldskills". Pendant ces deux jours nous avons pu faire un inventaire des pièces du kits, installer LabView et toutes les librairies utile à l'utilisation du myRio, ainsi qu'un premier châssis a trois roues et les tests moteurs.

On remercie PROMEO de nous avoir accueilli et de nous prêter un kit pour commencer la préparation et le PFE dès la rentrée.

Semaine 1

Rencontre avec Vincent Coelen

Rencontre avec notre tuteur école, Vincent Coelen, pour cadrer et définir le sujet de PFE, le sujet reprend les objectifs du sujet de robotique mobile des Worldskills 2019 à Kazan (Russie).

On discute organisation, préparation et on liste le matériel manquant à la vue d'une prochaine commande. On planifie une après midi de formation LabView avec lui dans la semaine.

Trouver une salle de travail

Dans un premier temps nous avons travaillé au Fabricarium mais avec notre matériel lourd et encombrant, une piste à monter démonter chaque jour, il était primordiale d'avoir une salle avec un espace qui nous est propre. Nous avons eu l'acces à la salle C002 de robotique.

Gestion de projet, définir une méthode de travail

Un projet de fin d'étude, se doit d'être réalisé de la façon la plus professionnelle possible, c’est-à-dire en suivant une méthode de gestion de projet.

Après discussion avec notre expert métier, il serait préférable d'adopter une gestion de projet dite "Agile", qui consiste à livrer toutes les semaines un produit opérationnel, en rajoutant à chaque fois de nouvelles fonctionnalités. Ce type de gestion de projet a plusieurs avantages:

• Permet d'avoir un logiciel et un robot opérationnel tout au long du projet
• Avoir une grande adaptation au changement (essentiel quand l'on sait que 30% du sujet change le jour de la compétition)
• Avancer par petits objectifs, les valider, s'adapter en fonction de la situation du moment, et ainsi de suite jusqu’à la fin du projet

TRELLO, gestion de projet

Pour nous aider dans l'organisation du projet, nous avons mis en place plusieurs outils:

• Microsoft TEAM: on a une équipe qui regroupe notre tuteur école, notre expert métier, ainsi que d'anciens compétiteurs français. On partage donc nos avancées, nos interrogations et récupère les retours/expériences des anciens compétiteurs.
• TRELLO: nous permet de gérer le projet, et les tâches en équipe, nous l'utilisons pour planifier et organiser tout notre travail. Chaque colonne représente un état du projet, dans lequel on glisse des "cards" qui représente une tache à réaliser. On peut donc, pour chaque aspect d’un projet, laisser nos commentaires, répartir nos tâches, centraliser des informations et suivre l’état d’avancement.
• Drive: Pour stocker et partager rapidement tous nos fichiers. Synchronisation et partage automatique de notre dossier de compétition, stocké sur nos PC respectifs.

Pour continuer dans la gestion de projet dite "Agile", la livraison d'un produit opérationnel par semaine est simulée par un feedback en fin de semaine à notre expert métier et tuteur école.

Construction du châssis

Le choix de la forme:

• Forme ronde: Si le terrain est semé d’embûche et très anguleux, il vaut mieux privilégier une forme ronde. Mais il devient alors plus difficile de trouver de la places pour la mécanique de mobilité et l’électronique avec cette configuration.

• Forme rectangulaire, anguleuse: Plus pratique pour la disposition et l'aménagement de ce qui se trouvera à l'intérieur du robot. Mais plus large qu'une forme ronde.

Disposition et nombres de roues:

Le kit Studica fournit des roues holonomes mais il est aussi possible de commander des roues classique si besoin. Les roues classiques ne permettent qu’un déplacement dans une seule direction et pose donc problème en mécanique robotique. Puisque les changements de direction ne sont pas instantanés, il faut définir une trajectoire courbe dans le cas d’une géométrie directionnelle d'Ackermann (ex: voitures) ou opter pour la méthode de direction différentielle (ex: 2 roues simples et une roue folle). Les roues holonomes, permettent quand à elle un déplacement très libre par changement instantané de direction mais inconvénient, elles ne sont utilisables que sur des terrains relativement plats et dont la surface est dure. Elles ont la particularité de disposer de galets en forme d’olive seront une répartition tangentielle le long de la roue. Chaque galet peut tourner sur lui même de manière indépendante, ce qui confère à la roue sa propriété omnidirectionnelle.

Le sujet impose au robot d’être très maniable et le terrain n’est pas accidenté. Le choix des roues holonomes est le plus judicieux. Il peut dans ce cas se mouvoir dans toutes les directions de manière fluide et sans perte de temps en limitant les rotations du robot. Cependant toutes les architecture de robots ne sont pas compatible avec les roues holonomes. Chaque roue doit être judicieusement disposées selon un angle et une position précise afin que le robot ait lui même une propriété omnidirectionnelle.

Les 4 roues holonomes sont espacées de 90° chacune avec des angles de roue à 45°. Le problème majeur d’un robot à 4 roues est de maintenir l'ensemble des roues au sol. En effet lorsque le chemin est irrégulier et sans système d'amortisseur, il y a un très fort risque que seul 3 roues touchent le sol. Dans ce cas il est très difficile de se mouvoir dans la bonne direction ou par odométrie. Nous avons donc imaginé un châssis sur lequel la partie avant et arrière du robot sont reliées selon une liaison pivot, rendant le châssis “flexible”. Ainsi les 4 roues sont constamment maintenues au sol.

Les équations pour connaître la vitesse à appliquer à chaque roue en fonction du vecteur vitesse du robot sont:

Vroue avant gauche   = |V|* sin (alpha - 3PI/4)
Vroue avant droite   = |V|* sin (alpha - PI/4)
Vroue arrière droite = |V|* sin (alpha + PI/4)
Vroue arrière gauche = |V|* sin (alpha + 3PI/4)

avec V le vecteur vitesse et alpha l'angle entre l'axe x du repère orthonormé et le vecteur vitesse

Formation LabView

Labview est un logiciel créé par National Instrument permettant la programmation de ses contrôleurs sous forme visuelle, avec des blocs à relier entre eux. Il est tout d’abord nécessaire de créer un projet qui regroupe l’ensemble des fonctions utilisées sur le robot et les caractéristiques de la carte électronique. Les programmes peuvent au choix être lancés sur l'ordinateur ou sur le myRIO en fonction de la situation. Chaque programme est appelé VI. Il peut prendre des paramètres en entrée et des sorties de tous les types usuels. Les VI sont divisés en 2 aspects: une partie programmation graphique où les fonctions sont dessinées, puis la partie panneau de contrôle. Sur ce panneau de contrôle peuvent être inclueses des “Indicateurs” qui affichent graphiquement ou textuellement différentes valeurs du programmes. Il existe également des “Contrôleurs” qui permettent de modifier en temps réel des variables du programme. Ces derniers peuvent être représentés sous la forme d’un bouton, d’une glissière, etc..

Vincent Coelen, nous a montré les bases de LabView:

• Le mode de fonctionnement de LabView
• Le câblage d'objet
• La création de constante, bloc de contrôle et indicateur
• Les raccourcis
• Le débogage
• La fenêtre d'aide
• etc...

On a maintenant les connaissances de base pour commencer à créer nos premiers VI.

Alimentation câblages et sécurités électrique

Alimentation:

Dire prendre tension converter/dispatcher

Câblages, connecteurs Wago et panneau d'alimentation

Câblages et sécurité

Pour le câblage, on a adopté un code couleur pour se repérer entre tous les fils, le noir est pour le GND, le rouge le 12V et le bleue le 5V. On réfléchie à ajouter un système d'étiquettes sur chaque câble pour un branchement sans erreur pendant le stresse de la compétition.

Pour une connexion et déconnexion rapide et facile entre les fils en phases de tests on a opté pour des connecteurs "Wago".

Le panneau de gestion d'alimentation a les fonctionnalités suivantes:

• Bouton d’arrêt d'urgence, qui coupe toute l'alimentation du robot
• Deux interrupteurs, pour mettre sous tension ou non l'alimentation des cartes moteurs, et des servomoteurs.
• Deux leds témoin, indiquent la mise sous tension du robot ou des erreurs dans l'exécution du programme
• Un bouton poussoir pour lancer le programme

Nos premiers codes VI

Testes de tous les actionneurs, capteurs

On teste indépendamment tout les actionneurs et capteurs. Tout en créant des SubVI qui leur sont propre. Ainsi, il sera plus facile et simple à utiliser dans nos futurs programmes.

Contrôle du robot a la manette

Pour contrôler le robot avec la manette deux programmes s’exécutent simultanément. L'un fonctionne sur l'ordinateur et lit les valeurs des joysticks/boutons et les concatène dans une variable globale. Cette variable est récupérée par le MyRio (qui est connecté via le PC en wifi) qui les interprète et contrôle le robot en conséquence.

• 

  Retour vidéo et affichage des vitesses de roues

• 

  Fonctionnalités de la manette

Semaine 2

Conception de la piste WorldSkills Kazan 2019

Reconstitution piste Kazan 2019

Pour se préparer au mieux, nous avons du reconstruire à l'identique une des sept "usines" du sujet Worldskills Kazan 2019. Les six autres sont composées du même nombre de composants (Workstation, Balles, Component Bins, Component Carriers,...) et donc facilement une fois la première piste constuite.

Grâce au plan fournit dans le sujet et à l'aide du menuisé de Polytech en quelques jours la piste était prête.

Le gros avantage de cette piste, est qu'elle est modulable et démontable très facilement. Le revêtement au sol est un bout de 8m^2 de lino (facile à rouler sur lui même). Chaque composant de la piste possède sa marque au sol numérotée pour un placement précis et rapide lors du montage. Les murs sont démontables rapidement grâce à leurs attaches rapides imprimés en 3D.

Odométrie 4 roues

L'odométrie est un élément essentiel dans les déplacements du robot. Elle permet de demander au robot d'avancer dans une certaine direction d'un certain nombre de centimètres. Pour cela nous disposons d'encodeurs sur nos moteurs permettant en fonction du nombre de tics par révolution, et du rayon de la roue, d'obtenir la distance parcourue par cette roue. L'architecture du robot holonome étant particulière, il est nécessaire d'établir des équations permettant de calculer la distance à parcourir par chaque roue.

distance = sqrt(pow(distance_x,2)+pow(distance_y,2));

theta = acos(distance_x / distance);

dist_encodeur1 = distance  * sin(theta - 3*PI/4);
dist_encodeur2 = distance  * sin(theta - PI/4);
dist_encodeur3 = distance  * sin(theta + PI/2);

dist_encodeur1 = distance  * sin(theta - 3*PI/4);
dist_encodeur2 = distance  * sin(theta - PI/4);
dist_encodeur3 = distance  * sin(theta + PI/2);
dist_encodeur4 = distance  * sin(theta + 3*PI/2);

Passage en trois roues et création de la pince et du lève palettes

Après avoir établi un châssis solide et les différentes commandes de roues, il est temps de penser à la fabrication d'un prince est d'un bras pour saisir les balles puis de remplir et transporter les "Component Carriers".

Un premier prototype de pince est réalisé avec les pièces du kit. Il est principalement composé d'un servo-moteur sur lequel est fixé une roue dentée qui entraîne le déplacement de 2 rails permettant d'ouvrir ou de fermer la pince. Cependant la préhension d'une balle est très difficile avec les pièces fournies. Nous avons donc dessiné et imprimé en 3D qui est un moule partiel d'une balle, permettant une bien meilleure prise. Elle est également assez fine pour pouvoir passer en dessous des "Component Carriers".

Pour le servomoteur nous disposons d'un exemplaire de 3 types:

• Un servomoteur asservi en position entre -135° et +135°. Il est utilisé pour basculer la webcam en position de lecture de code bar, ou en position prise de balle
• Un servomoteur à fort couple pouvant être asservis en rotation continue ou en position jusqu'à 3 tours et demi. Nous avons besoin d'un servomoteur asservis en position pour disposer d'un capteur pouvant pivoter dans différentes positions.
• Un servomoteur à rotation continue. Il est utilisé pour la fermeture et l'ouverture de pince.

Pour le système de lève palettes nous avons besoin d'un moteur supplémentaire pour entraîner une courroie permettant de faire monter et descendre la pince sur un axe linéaire. Nous décidons donc de repasser à un châssis à 3 roues afin de récupérer le moteur nécessaire. L'encodeur permet également de savoir à quelle hauteur se trouve la pince.

Semaine 3

Amélioration du chassis

Durant cette semaine nous continuons d'améliorer le châssis du robot en renforçant les liaisons les plus sensibles. Nous tentons également de réduire les dimensions du robot au sol. Plus il sera court et étroit, plus facilement il pourra évoluer sur la piste.

Utilisation du compas NavX

Le kit nous met à disposition un capteur appelé NavX. Ce dernier est un accéléromètre 9 axes et magnétomètre permettant de mesurer le lacet, le roulis et le tangage du robot de manière très précise. Il possède une dérive du lacet jusqu'à 1 degré par minute, ce qui est négligeable pour notre utilisation.

La mesure du lacet nous permet alors de programmer une fonction de rotation du robot performante se basant sur la position réelle du robot. Nous pouvons alors nous affranchir de la rotation par odométrie qui posait énormément de problèmes dû au dérapage potentiel des roues. La mise en place d'un régulateur PID permet d'atteindre de manière rapide et précise un angle voulu. Nous couplons également une régulation du lacet dans diverses fonctions comme le suivit de balle et les fonctions de déplacement afin d'éviter la dérive du robot et qu'il maintienne son cap.

Panneau de contrôle du NavX

Test capteur Sharp

Principe de fonctionnement d'un capteur Sharp

Pour commencer il faut savoir qu'un capteur Sharp (nom de la marque) est un capteur de distance infrarouge. Ce dernier émet grâce à une led infrarouge un signal lumineux invisible de l'oeil humain. Ce dernier va être réfléchi par l'obstacle puis reviendra vers le capteur avec un angle d’incidence variant en fonction de la distance de l'obstacle. Avec une lentille, et une bande photoréceptrice, le capteur permet de détecter cet angle d'incidence avec lequel nous pourrons calculer la distance.

Pour pouvoir utiliser le capteur Sharp nous avons besoin de traduire ce que renvoie le capteur en centimètres. En effet la tension retranscrite par ce capteur n'est pas proportionnelle à la distance. Une courbe caractéristique (Tension en fonction de la distance) est fournie dans la datasheet mais l'équation n'est pas fournie et nous préférons la mesurer par nous même. De plus il existe de nombreux type de capteurs Sharp et même si la forme est semblable, chacun a une courbe caractéristique qui lui est propre. Pour cela nous avons effectué plusieurs mesures en mettant un objet à différentes distances du capteur (de 0cm à 50cm). Le but est d'obtenir une équation traduisant la tension du capteur en distance en centimètres.

Cable management

Devant l’entremêlement des tous les câbles des actionneurs et capteurs du robot nous ne distinguions plus lequel était relié à quel élément. Nous avons donc pris deux jours pour tout débrancher et rassembler les différents fils dans des gaines passes câbles. Chacun est étiqueté pour identifier via un code couleur à quel servomoteur ou moteur il appartient. Les gaines sont quant à elles solidement fixées sur le robot à l'aide de serres-câbles. Nous avons également différencié le 5V du 12V par l'utilisation de câbles de couleur différente.

Semaine 4

Nous sommes en semaine 4, nous commençons maintenant à bien maîtriser LabView, le kit, la partie mécanique ainsi qu'indépendamment les actionneurs et capteurs du robot. C'est à partir de maintenant que les premiers algorithmes qui vont permettre l'autonomie du robot vont être imaginé.

Mais avant cela nous avons 3 gros problèmes à résoudre :

Problèmes rencontrés

Les principaux problèmes rencontrés depuis le début du PFE sont

• L'alimentation des divers composants
• La saturation de la mémoire dès lors que l'on enchaîne des SubVI
• L'oscillement du robot dès lors qu'il avance en marche avant.

La tension de la batterie

La tension de la batterie oscille entre 14,5V et 11,5V entre son état chargé/déchargé. Solution : Dans un premier temps nous avons mis un abaisseur de tension a 12V pour avoir une tension constante a l'entrée des cartes d'alimentation des moteurs et du MyRio. Mais au vu des courants qui peuvent aller jusque 3,5A l’abaisseur a fini par griller. En fin de semaine quatre nous avons reçu un module de régulateur de tension :WSR Voltage Regulator Module qui une fois connecté à la batterie possède 8 sorties :

• (2) 5V output; 500mA limit
• (2) 5V output; 2A limit
• (2) 12V output; 500mA limit
• (2) 12V output; 2A limit

Alimentation de composants en 5V

Certains composants, comme les servomoteurs et capteurs ont besoin d'une alimentation de 5V. Au début nous recéperions directement le 5V sur le MyRio. Mais au fur et à mesure que le nombre d'actionneurs sur 5V étaient ajoutés, on avait de plus en plus de problèmes d'alimentation. Du forcement à un manque de puissance du MyRio. À la réception du régulateur de tension, nous avons pu les brancher sur les sorties 5V 2A.

Mémoire saturée

Ce problème de mémoire est persistant depuis nos premiers enchaînements de SubVI. Indépendamment chaque SubVI fonctionne mais rapidement dès qu'on enchaîne deux à trois sous programmes le robot est tout de suite saturé en mémoire.

Solutions envisagées : simplifier nos SubVI, contacter Guillaume (de Polytech Montpellier) qui a déjà travaillé sur ce robot pour les Euroskills 2018

Pièces en 3D

En ce tout début de semaine nous avons imprimé en 3D les différents supports pour les capteurs ultrasons afin de les disposer sur le robot. Nous avons dessiné un nouvel élément afin d’accueillir un end-stop étant capable d'identifier l'état d'ouverture de la pince. Dans l'esprit de toujours améliorer le câblage du robot nous avons également imprimé un modèle de chaîne passe-câbles permettant de cacher et de contenir l'ensemble des câbles de la pince (des servos moteurs et des fins de coursses) tout en ne gênant pas la montée et la descente du bras.

Algorithmes de suivi de mur/ligne

Grâce à ces nouveaux capteurs nous pouvons commencer à réaliser un algorithme permettant un suivi de mur. Pour ce faire nous utilisons le capteur à ultrasons situé du côté du mur à suivre à l'avant du robot ainsi que le capteur infrarouge à l'arrière que nous orientons vers le mur grâce au servomoteur. La différence de distance entre les deux capteurs permet de maintenir le robot parallèle au mur, et la distance moyenne des deux sert de référence pour maintenir une distance voulue entre le robot et le mur, deux régulateurs PID sont donc nécessaires pour stabiliser le robot.

Un capteur de ligne a également été ajouté au robot permettant un suivi de ligne et le recalibrage du robot sur une courte ligne comme celles présentes sur les component carrier du terrain.

Fonctions de gestion du bras et de la pince

Pince avec sélection d'ouverture grâce au EndStop

Pour automatiser le robot le plus simplement possible, il était nécessaire de créer des fonctions (Sub VI) pour la gestion du bras et de la pince. L'utilisation de deux Sub VI de reset pour le bras et pour la pince nous permette de réinitialiser à zéro l'encodeur du moteur du bras (on descend le bras jusqu'à l'activation du EndStop, puis on reset à zéro l'encodeur moteur bras). Le servomoteur de la pince est un servo commandé en vitesse donc, on le réinitialise en le fermant pendant 1,5 secondes (temps max qui lui faut pour se fermer).

Ensuite le bras peut glisser de 0 à 22cm de hauteur, la hauteur du bras est retournée par l'encodeur moteur, donc il est facile à commander en position. L'ajout d'un PID le rend encore plus précis.

Étant donné que la pince est gérée par un servo commandé en vitesse, on ne peut pas choisir l'ouverture exacte de la pince. Un EndStop et des butées judicieusement bien placées, nous permette de commander trois ouvertures de pince : "Pince fermé", "Pince middle", "Pince full"

Tracking de balles

La saisie d'une balle dans les emplacements prévu à cet effet n'est pas une étape aussi facile qu'on pourrait le penser. En effet les balles ne se situent pas à un endroit précis mais dans une zone rectangulaire, il est donc impossible de les attraper par simple odométrie. Une reconnaissance et un suivi par caméra est donc indispensable. Afin d'identifier une balle sur une image plusieurs traitements d'images seront nécessaires.

• Seuil colorimétrique :

Les balles étant colorées et le sol étant de couleur clair, elles peuvent facilement se démarquer en analysant la valeur colorimétrique des différents pixels de l'image. La première étape pour localiser une balle orange est donc de binariser l'image en mettant à 1 les pixels correspondant à de l'orange et à 0 les autres. Il faut donc définir ce qu'est la couleur orange, pour ce faire il faut relever son code RGB. Cependant la luminosité ambiante peut varier, et les ombres sur la balle peuvent changer cette valeur. Il est donc important de ne pas prendre des valeurs discrètes mais plutôt des plages de valeurs couvrant l'ensemble des combinaisons RGB pouvant être originaire de l'élément à reconnaître. Sur l'image de calibration des seuils RGB ci-contre nous avons sélectionné une zone de l'image dans laquelle se trouve uniquement la balle et afficher l'histogramme de cette zone. Cela permet de régler facilement les seuils en prenant en compte les variations de couleur. Nous laissons tout de même une marge d'erreur dans nos réglages afin d'être insensible à des potentiels variations de luminosité ambiante. Comme vous pouvez le voir sur l'image binarisée les balles sont parfaitement identifiables.

• Filtre de particules :

Le seuil colorimétrique n'est pas parfait, il peut alors apparaître dans des environnements peu propices ou peu lumineux des pixels éparpillés étant identifié comme étant de la couleur de la balle. Afin d'éliminer ce bruit nous appliquons un filtre qui identifie les formes dans l'image selon une connexité 4/8 et élimine toutes celles de petite surface.

• Remplissage des trous :

Comme nous pouvons le voir sur les images, les balles possèdent des écritures qui ne sont par reconnues comme "orange". Cela crée des trous dans l'image binaires qui sont remplis grâce à cet algorithme afin d'uniformiser la zone.

• Reconnaissance de cercles :

Cette dernière fonction permet d'identifier des formes circulaires dans l'image, qui correspondent ici à nos balles. Elle renvoie le rayon et les coordonnées dans l'image du centre des cercles.

• 

  Calibration RGB du filtrage colorimétrique

• 

  Processus de reconnaissance de balles

Semaine 5

Réception et installation du nouveau matériel

En ce début de semaine nous avons reçu du nouveau matériel permettant de résoudre certains de nos problèmes.

Nous disposons à présent d'un module de point d'accès sans fil. Nous l'avons configuré afin d'améliorer grandement la communication entre le myrio et l’ordinateur avec un wifi Dual Band à 1.17 Gbps. Nous pouvons à présent réaliser du streaming vidéo pour une vue à la première personne du robot avec une cadence de 30 images par secondes. Il a également permit de résoudre les coupures intempestives de la communication avec le myrio en instaurant une communication beaucoup plus stable.

Le second élément est un régulateur de tension. Auparavant nous avons rencontré de nombreux problèmes au niveau des alimentations qui perturbaient le bon fonctionnement du robot. Les différents servomoteurs doivent être alimentés en 5V via une entrée sur les cartes MD2. Or, sans régulateur nous connections cette entrée à la sortie 5V du myRio qui n'arrivais pas à sortir assez de courant pour faire fonctionner tous les moteurs en même temps. Le deuxième problème majeur était un pic de chute de tension liée à l’activité des moteurs qui provoquait le redémarrage du myRio. Grâce aux différentes sorties 5V et 12V du régulateur, l'ensemble de ces problèmes ont été résolus.

Algos de déplacement du robot vers les workstations

Les déplacements vers les workstations se font principalement grâce à des fonctions de suivi et de calage de mur avec PID, on obtient ainsi des déplacements fluides et précis sur la piste (notre objectif pour les semaines d'entrainement qui suivent serai d’intégrer un algorithme de SLAM, qui permettrait de cartographier la piste et de localiser le robot dans ce plan)

Enfin pour se placer précisément devant une workstation on s'aide de la ligne noire de 15cm de long qui est devant chaque Workstation. Le retour se fait de la même manière.

Algos de remplissage de component carriers

Le remplissage des component carriers est une tache délicate puisque la zone de dépôt est très petite, à peine plus grande que la taille des balles. Pour le remplir sans échouer on utilise simultanément trois capteurs :

• Le suiveur de ligne, pour attraper la ligne noire en face du component carrier, nous sommes maintenant bien positionnés en X
• Le capteur Sharp arrière qui garde une distance constante avec le mur pour se placer correctement en Y
• Le NavX pour s'assurer que le robot ne dérive pas de son angle d'origine.

Résolution du problème d'oscillementdu robot

Les pièces du kit Studica permettent d'orienter les roues de trois manières différentes: 0°, 45°, et 90°. Lorsque l'on est passé en trois roues nos deux roues avant étaient orienté a 45° et -45° par rapport a l'axe de Y du robot. Et c'est cet angle trop fermé qui entraînait un fort déhanchement de gauche à droite du robot.

Dans un premier temps nous avons essayé d'alourdir le robot, d'abaisser son centre de gravité, d'écarter les roues mais sans succès. Et ce n'est qu'en imprimant en 3D une pièce custom qui permet une orientation des roues a 60°/-60° par rapport a l'axe Y, que le problème a été résolue. Ainsi maintenant les trois roues ont le même angle, de 120°, les unes par rapport aux autres.

Algos de lecture de code bar

Le module 'vision' de LabView permet la lecture de code bar via plusieurs réglages. Pour que cela puisse fonctionner sur le MyRio sans problème de mémoire et rapidement. La camera a été mise en noir et blanc avec une qualité réduite et un FPS bas à 7,5 Frame/second. Un même code bar est lu plusieurs fois et si et seulement s'il est lu trois fois de suite avec le même code alors il est considéré comme correcte et passe à sa tâche suivante.

Semaine 6

Résolution du problème de mémoire

Nous étions toujours freinés par un problème encore inconnu qui nous empêchait d'utiliser à la fois la partie bras du robot et la partie déplacement. Pour trouver la source du problème nous avons établi une routine de test avec un enchaînement de petites actions qui provoquaient des problèmes afin d'essayer de remonter dans l'architecture des VI (fonctions) et trouver le problème. Nous sommes finalement tombé sur un code d'erreur indiquant un problème d'allocation de mémoire. Avec l'aide de Vincent Coelen, nous avons exploré cette piste en affichant en temps réel l'utilisation de la mémoire du myRio. Nous avons alors remarqué qu'il ne possède que 71Mo de mémoire libre et qu'au fil des actions elle commençait à réduire jusqu'à saturation. En remontant jusqu'à la racine de la librairie de lecture des différentes entrées/sorties, nous avons découvert qu'à chaque appel d'un capteur/actionneur la fonction copie en mémoire le bitfile du FPGA afin de pouvoir communiquer avec. Cependant ce fichier n'est pas supprimé et avec une taille de 2.8Mo, il remplie rapidement la mémoire rendant impossible la lecture de nouveaux capteurs.

La solution proposée est donc de restructurer en partie cette librairie fournie par le constructeur. Nous avons donc refait les fonctions d'ouverture du FPGA, des DIO et des PWM en prenant en entrée directement le pointeur du bitfile et ainsi éviter de créer un copie en local. Une fois ces différentes fonctions de base refaites il faut actualiser l’ensemble de la librairie de STUDICA pour fonctionner avec et que toutes prennent également le bitfile en entrée pour également éviter les doublons internes. Nous disposons maintenant de notre version de la librairie avec une optimisation de l'utilisation de la mémoire. Cependant il faut également actualiser avec cette dernière toutes nos fonctions précédemment développées.

Nous profitons de cette restructuration pour améliorer l'ensemble de nos programmes. À la manière de ROS nous souhaitons séparer la partie haut niveau de la partie bas niveau du projet. Au lieu de faire appel à chaque capteur/actionneur dans nos fonctions, nous faisons fonctionner deux boucle en parallèle du programme principal. La première lit la valeur de l'ensemble des capteurs et la publie dans une variable partagée (sous la forme d'une classe) comme le ferait ROS avec les topics. La seconde permet, elle, de lire sur une autre variable partagée les commandes qui sont données au robot et de l'envoyer aux différents actionneurs. Le programme principal ne fait donc plus que des calculs et se contente de lire la valeur des capteurs et publier la commande correspondante.

Nouvelle pince ergonomique

Nouvelle forme de pince

La pince précédente posaient quelques soucis malgré sa très bonne préhension de la balle. Elle était trop épaisse, ce qui rendait difficile la prise des workstations, mais aussi la prise des balles disposées sur le bord des compartiments ou lorsqu’elles étaient regroupées. Nous avons donc redessiné la pièce en conservant la forme principale, mais en affinant l’extrémité de la préhension pour qu'elle se glisse plus facilement entre 2 balles. Le bout est maintenant pointu pour faciliter l'insertion du lève palette dans la workstation. Nous avons également pensé à imprimer la pince en noir afin de ne pas perturber la reconnaissance de couleur.

Suite du programme principal

Maintenant que le problème de mémoire est réglé et que nous avons revu l’architecture logicielle de nos programmes, nous pouvons relier toutes nos fonctions entre elles afin de réaliser la tâche. De nombreux ajustement sont encore à réaliser afin de faire fonctionner tous les programmes au mieux ensembles. Il a fallu également alléger au maximum le programme de reconnaissance de balles afin de ne pas être ralenti par le traitement d'images. Nous avons testé tous les programme après la mise à jour de la librairie et regroupé des programmes similaires entre eux.

Documents Rendus

Rapport: Fichier:P26 PITRE DUPRE.pdf

Présentation: Fichier:Diapo Oral PFE P26.pdf

Fichiers STL des éléments conçus par nos soins: Fichier:STL PFE P26.zip

Fichiers de codes LabView: Fichier:LabView P26.zip