IMA3/IMA4 2021/2023 P12
Sommaire
Présentation du Projet
Contexte
Collaboration de deux robots pour la gestion d'un entrepôt :
Dans le cadre de notre projet ingénieur, nous avions choisi pour sujet la “Conception et commande d'un robot élévateur” dont le but était de concevoir un robot élévateur que nous imaginions parfaitement s'intégrer dans un entrepôt pour soulever des charges et qui pourrait coopérer avec un autre. Cependant, après analyse, nous avons constaté que quelques prototypes existaient déjà or nous tenions à ce que notre projet puisse être une réelle valeur ajoutée ce qui nous a amené à revoir nos plans. Il se trouve que l'un des problèmes des entrepôts concerne la sécurité puisqu'on compte plusieurs cas d'accidents mortels chaque année.
Afin de pouvoir apporter plus de sécurité au sein des entrepôts et de rendre plus efficace le traitement des marchandises, nous avons décidé qu'il serait plus intéressant de concevoir 2 robots légèrement différents et qui coopéreraient entre eux. Nous avons donc décidé de nous concentrer sur la communication entre les robots à partir de modèles déjà existants. Nous avons alors redéfini notre projet comme suit : “Collaboration de deux robots pour la gestion d'un entrepôt”.
Ainsi, nous voulons faire communiquer deux robots autonomes que nous pourrions intégrer par la suite dans des entrepôts en plus grande quantité, dans le but de rendre ceux-ci automatisés. Le premier robot serait un robot élévateur capable de soulever et déplacer des charges tandis que le second serait un robot transporteur de charges d’un point A à un point B.
Objectifs
Etudes du projet
Tout d’abord, pour déterminer les objectifs de notre projet, nous sommes passés par une phase d’études en amont dans le but d’affiner notre idée principale. Nous en avons réalisé plusieurs, dont une étude d’opportunité et un état de l’art.
Tout d’abord, la pertinence de notre solution, la communication entre deux robots autonomes, nous a été confirmée par une étude d’opportunité que nous avons pu réaliser. Celle-ci nous a permis de définir concrètement le contexte dans lequel nous réalisions notre projet et dans lequel il pourrait s’exprimer. Une analyse de la situation actuelle dans le monde de l'industrie et comment pouvoir résoudre le problème principal, à savoir, rendre les entrepôts automatisés et plus sécurisés tout en gardant une efficacité dans la réalisation de la tâche. En effet, dans un contexte où il est nécessaire de répondre aux besoins des consommateurs de manière efficace, l'intérêt de voir apparaître des entrepôts autonomes est un gage de rapidité et de fiabilité.
Cependant, au fur et à mesure que nous avancions dans la conception de notre projet, nous ressentions le besoin de savoir si notre projet n’existait pas déjà ou s’il n’était pas tout simplement inutile car personne ne recherchait ce type de technologie. Cela nous a donc poussé à mener un travail de recherche sur ce qui existait déjà et sur les besoins dans les entrepôts à travers un état de l’art et une étude de marché. L’état de l’art nous a permis de faire le lien entre ce que nous souhaitions mettre en place avec nos robots et les différents mécanismes déjà utilisés dans le monde de l'industrie. En parallèle, l’étude de marché que nous avons réalisée nous a permis d’avoir une idée plus concrète de ce qui était recherché dans le secteur de l’industrie.
Une fois l’idée générale de notre projet détaillée, nous avons commencé une réflexion sur les fonctions nécessaires aux deux types de robots que nous voulions faire communiquer..
Pour cela, nous avons tout d’abord schématisé au travers de différents diagrammes les fonctionnalités de nos robots dans une analyse fonctionnelle afin d’exprimer le problème actuel des entrepôts et d’y trouver une solution. Cela nous a par la suite mené à rédiger le cahier des charges, à travers lequel nos objectifs sont clairement définis. Nous avons tout d’abord réalisé des diagrammes APTE pour déterminer le besoin auquel répond notre solution.
Cahier des Charges
Dans le cadre de l’industrie du futur, l’industrie 4.0, nous pouvons imaginer des entrepôts de plus en plus automatisés, avec moins de présence humaine, tout en restant rapide et fiable dans le traitement des charges, des marchandises. Ces entrepôts seraient peuplés de robots réalisant les tâches actuellement réalisées par les manutentionnaires qui sont souvent pénibles et répétitives.
L’objectif de notre projet est de concevoir un prototype échelle quasi-réelle de robots autonomes collaborant entre eux dans le but idéal de pouvoir gérer les marchandises de tout un entrepôt en imaginant d’autres robots collaborant avec eux. C’est un projet d’une échelle TRL 5.
Le premier robot serait un chariot élévateur automatique et le second serait un robot transporteur de charges appelé “robot train”. Le robot élévateur déposera des palettes, des charges sur le robot train. Ce dernier, une fois chargé en charges, les amènera à un point final. Le robot train se déplacerait dans l'ensemble de l'entrepôt et s'arrêterait à des "stations" auxquelles le robot élévateur lui amènerait des charges. Après avoir chargé un certain nombre de charges, il les amènerait à un point final. Dans le cadre d’un projet TRL 5, nous souhaitons mettre en place une “maquette”, un environnement spécifique dans lequel se déplaceront les robots avec différentes lignes au sol déterminant : les limites à ne pas dépasser, les stations du robot train. Ce projet se déroule sur un ensemble de 3 semestres au bout desquels les robots devront présenter les fonctions suivantes : (insérer tableau des fct)
Réalisations et résultats
Solutions envisagées
Robotinos
Après avoir identifié les besoins de nos robots ainsi que leurs différentes fonctions, nous nous sommes tournés vers une solution matérielle nous permettant d’être au plus proche de ce que nous souhaitions mettre en place. Nous avons alors choisi les Robotinos, disponibles au sein de l’école et avec l’un d’entre eux équipé d’un module d’élévation correspondant parfaitement avec notre idée de robot élévateur.
Pour développer notre solution, nous avons donc premièrement décidé de travailler avec les Robotinos. Un premier Robotino possédant un module d'élévation servirait de robot élévateur, et un second Robotino auquel nous ajouterons une remorque jouera le rôle du robot train. Celui-ci serait équipé d’un chariot/remorque auquel nous souhaitions ajouter des capteurs de présence.
Il existe plusieurs manières d’utiliser ses robots et de les faire communiquer, dans notre cas nous sommes passer par ROS qui permet une programmation complète des robots en C/C++ et/ou Python de gérer facilement la communication entre les différents robots de notre système. Cette manière d’utiliser les robots est efficace mais elle nous demande contrairement à la programmation par bloc de robotinoView de nous former à la programmation sur ROS.
Pour mettre en place cette solution technique nous nous sommes alors répartis en deux binômes afin de travailler parallèlement sur différents points de notre projet. Un binôme était donc chargé du choix des capteurs ainsi que de la réalisation de la remorque afin de réaliser la remorque utilisée par l’un des robots. Tandis que le deuxième binôme était chargé de se former à la programmation ROS et de rassembler les fonctions C/C++ déjà existantes pour le Robotino. Et c'est justement dans le travail sur ce dernier point que nous avons rencontré un problème majeur.
Robotino est un système complexe produit par une grosse entreprise (Festo), il est nécessaire de passer par leur documentation et surtout d’utiliser le code de base en C++ fournis sur leur site wiki.openrobotino. Mais pour faire fonctionner ce code il est nécessaire d’utiliser la librairie API2 fournis sur le site, pour que les fonctions de bases puissent fonctionner. Seulement, il nous est impossible de télécharger la librairie. Que ce soit sous linux ou sous window il nous fut impossible d’obtenir cette librairie. Et sans librairie et code source nous ne pouvions tout simplement pas utiliser les Robotinos avec ROS. Nous ne pouvions pas utiliser uniquement RobotinoView pour les programmer car cela ne nous permettait pas de faire communiquer les Robotinos entre eux. Nous avons tout de même persévéré et contacté un ingénieur ayant longtemps travaillé sur les Robotinos. Mais même après l’appel de cette personne, nous n'avons pas trouvé de solutions. Le site actuel de robotino ne permet pas de télécharger la librairie.
Ce problème nous a donc contraint à revoir notre stratégie, abandonner la solution des Robotinos, et à en considérer de nouvelles.
Khepera IV
Afin de rebondir rapidement, nous avons choisi une solution simple et qui nous semblait facile à mettre en place. Cette solution est l'utilisation du robot Khepera IV. Le Khepera IV est un robot en forme de disque pouvant se déplacer dans toutes les directions à une vitesse relativement faible. Grâce à ses multiples capteurs il est aussi capable d'exécuter une détection d’obstacle et de se déplacer en conséquence. Ce robot était en effet simple d’accès pour nous puisque nous pouvions implémenter du code en C directement sur l’environnement Linux du robot. De plus, nous avions déjà utilisé ce robot lors de l’année précédente en TP.
Pour ce qui est du réseau nous n’avions qu’à le configurer sur un point d’accès wifi afin de réaliser la connexion entre l’ordinateur de contrôle et d’autres robots. Ce modèle était donc une bonne solution pour réaliser un prototype de notre projet, bien qu’avec ce modèle, la configuration des actions d’élévation et de déplacements des charges n’était plus possible. Ce prototype nous permettait uniquement de nous intéresser à la communication et aux déplacements dans l’ensemble du système de robot. Les objectifs ont donc été revus à la baisse car il n’était plus question d’atteindre le TRL 5 mais le TRL 4 à savoir, un prototype échelle réduite.
Dans un premier temps nous avons paramétré les robots ainsi qu’un point d’accès wifi afin de pouvoir faire communiquer les robots entre eux en utilisant un réseau wifi. Malheureusement nous avons rapidement rencontré un problème de programmation et d'implémentation du code avec ce robot .Une fois les codes de test exécutés, le robot fonctionnait correctement, mais lorsque d’autres exécutables étaient implémentés depuis un ordinateur sur ce robot, cela nous était impossible de les utiliser même si le code était identique au code de test. Le robot ne reconnaissait tout simplement pas tout exécutable, fichier ou autres données qui venait d’un autre système. Et sans possibilité de pouvoir transférer du code sur ce robot, il nous était impossible de mener à bien notre projet sur ce robot dans ces conditions.
Nous avons donc contacté le constructeur de ce robot et nous leur avons envoyé notre projet en leur expliquant le problème que nous avions rencontré. Ils nous ont répondu une première fois puis après plus de réponses. Nous avons donc dû trouver une autre solution.
Sans aucun autre choix, nous avons de nouveau changé de robots. Cette fois-ci nous avons utilisé les robots TurtleBot3.
Après avoir mis en place notre plan d'action pour les semestres S7 et S8 et avoir établi notre diagramme de Gantt, nous nous sommes attaqués à la seconde phase de notre projet. Tout d'abord, on souhaite utiliser les Robotinos, un Robotino qui servira de "Robot Élévateur", l'autre sera utilisé comme Robot Train. Pour cela, on s'appuie sur 2 modèles de Robotinos présents dans l'école.
Si on prévoyait initialement de coder chaque Robotino avec le logiciel RobotinoView, nous nous sommes rapidement ravisés puisque il est impossible de faire communiquer les 2 robots via RobotinoView. Pour pouvoir faire communiquer les 2 mais aussi pour les coder, nous devons passer par ROS1 (ROS2 ne permettant pas de gérer les Robotinos). Il nous faut donc prendre en main ROS. C'est un logiciel très complet qui permet de réaliser tout ce que l'on souhaite faire pour nos robots tout en nous permettant de programmer ceux-ci en python, langage maîtrisé par chacun des membres du projet ou bien en C++. On dispose même d'un simulateur 3D, Gazebo, nous permettant d'aller très loin dans les tests. Sur le site officiel de ROS est disponible un tutoriel complet permettant de comprendre les grands principes notamment à l'aide de turtlesim, un outil créer spécialement pour comprendre ROS. Enfin, sur le wiki de Robotino est disponible des fonctions déjà faîtes en C++ permettant d'utiliser l'ensemble des fonctionnalités des Robots.
Cependant, nous avons rencontré un problème majeur : ce code présent sur le wiki robotino nécessite l’installation de la bibliothèque API2, or l’installation de celle-ci ne peut être faîte sur les ordinateurs de l'école et ce même après une intervention extérieure. Ainsi il nous était impossible d’essayer le code présent sur le wiki. Bien qu'il existe d'autres façons de coder les Robotinos, en passant par MATLAB par exemple, nous avons fait le choix d'utiliser d'autres robots pour réaliser notre projet.
Nous sommes passé sur les robots KHEPERAS IV, dont 2 modèles sont présents dans l'école également. Bien que l'on doive revoir légèrement notre cahier des charges, ces robots présentent quelques avantages. En effet, ils sont de plus petites taille que les Robotinos, plus pratiques pour nos démonstrations. De plus, on peut les coder en C ce qui est très avantageux pour nous puisque c'est un langage que l'on maîtrise bien contrairement au C++. Enfin, pour la communication entre les 2, nous n'aurons plus à utiliser ROS, nous utiliserons un Routeur D-link pour connecter les 2 robots sur un même réseau et les faire communiquer.
Jusqu'à présent, nous avons réussi à nous connecter sur les KHEPERAS IV en USB via le programme de communication série minicom et à lancer un code test depuis le robot nous permettant d'accéder à ses différentes fonctionnalités.
Bilan
Finalement, lors ce projet nous n’avons pas réussi à atteindre l’objectif souhaité du TRL4. En effet, à la fin de ces trois trimestres, nous n’avons pas réussi à obtenir de prototype aboutis de notre projet. Et en prenant du recul nous avons pu comprendre certaines erreurs que nous avons effectué dans ce projet.
Et arrivé au terme de ce projet nous avons compris avec du recul que la principale erreur que nous avons fait est de sous-estimer certaines parties du cahier des charges tel que l’analyse des risques. En effet, nous n’avons pas saisi le sens de cette étape du cahier des charges au semestre 6, cependant il représente exactement tout ce dont nous avons manqué. En effet, lors de notre projet nous avons sans cesse rencontré des problèmes lors de la réalisation, et il nous aura fallu un certain temps pour rebondir sur une autre solution lorsque à chaque fois que nous nous sommes rendus compte que la solution actuelle ne convenait pas. Si nous avions réalisé une analyse des risques avec des contre solutions (plan B, plan C …) en cas de problème dès le début du projet nous aurions pu gagner du temps et peut être atteindre le TRL4.
Grâce à ce projet, nous avons compris l’importance d’avoir un cahier des charges rigoureusement rédigé. Le cahier des charges permet d’avoir un socle commun à tous les collaborateurs afin de réaliser le projet dans les temps en toutes circonstances. Mais plus simplement il est le document officiel constituant chaque projet et se doit d’être respecté à la lettre car celui-ci comporte la volonté du client et celle-ci doit être respectée. Lors d’un projet, le cahier des charges est essentiel pour tous, c’est pour cela qu’il doit être rédigé méticuleusement et en prenant le maximum de paramètre en considération, pour ne pas revenir dessus (ce qui peut poser d’énorme problème une fois qu’il est signé par le client). De cette manière toutes les personnes travaillant à la réalisation de ce projet peuvent s’y référer en cas de doutes ou d’imprévu.
En prenant ce recul nécessaire sur le projet nous nous sommes aussi rendu compte de la quantité importantes de compétences que nous avons pu utiliser ou développer tout au long de ce projet. Des compétences Humaines importantes dans la gestion de projet tel que la communication, l’organisation ou l’adaptation; tant bien que des compétences techniques propre à notre projet tel que la programmation sur ROS ou la programmation de systèmes pour créer des moyens de communication. Bien que nous n’ayons pas atteint les objectifs souhaités, nous considérons que ce projet est un succès. En effet ce projet à vertu principalement pédagogique, nous aura ouvert les yeux sur de nombreuses pratiques essentielles lors de la réalisation d’un projet.
Gestion de Projet
Outils Gestion de Projet
- Google Drive
- Plan d'action
Matériel de l'école utilisé
- Robotino (anciennement)
- Robots Khepera IV (anciennement)
- Routeur D-Link (et son alimentation) (anciennement)
- TurtleBot3 Burger
