IMA3/IMA4 2021/2023 P12
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 en amont
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 :
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 sur laquelle le robot élévateur déposerait les charges.
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.
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
Nous avons alors fait le choix d'utiliser le robot Khepera IV. 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.
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.
Solution retenue
TurtleBot3
Le TurtleBot3 est un robot mobile autonome qui présente plusieurs avantages par rapport à d'autres robots tels que le Robotino et le robot Khepera. Tout d'abord, le TurtleBot3 dispose d'un Lidar 2D haute résolution qui permet une reconnaissance de l'environnement précis et efficace. Cette fonctionnalité est cruciale pour la navigation autonome du robot et sa capacité à éviter les obstacles et à se déplacer de manière fluide dans des environnements complexes.
En outre, le TurtleBot3 est équipé de capteurs de détection de distance qui permettent une cartographie 3D en temps réel de son environnement, ainsi qu'un système de localisation et de cartographie simultanées (SLAM). Cette technologie avancée permet une planification de trajectoire intelligente pour le robot, ce qui le rend très efficace dans les tâches de surveillance, de patrouille et de maintenance.
Comparé au Robotino, le TurtleBot3 est plus léger, plus petit et plus maniable, ce qui le rend plus adapté pour les environnements encombrés et les tâches qui nécessitent une grande agilité. Il est également plus abordable et facile à utiliser que le Robotino, grâce à son architecture modulaire et sa facilité d'intégration avec des logiciels open-source.
Enfin, en comparaison avec le robot Khepera, le TurtleBot3 offre une meilleure autonomie de batterie, une vitesse de déplacement plus rapide et une capacité de charge plus importante, ce qui le rend plus polyvalent pour les tâches de collecte de données et d'inspection.
Nous avons donc décidé de modifier le cahier des charges initial en ajoutant une fonctionnalité importante pour notre projet : la reconnaissance de l'environnement à l'aide d'un Lidar. Cette fonctionnalité nous permettra d'obtenir des informations précises sur l'environnement dans lequel notre robot évolue, ce qui est essentiel pour une navigation autonome efficace et sûre. En utilisant le Lidar, nous pourrons générer une carte 2D ou 3D de l'environnement et l'utiliser pour la localisation, la cartographie et la planification de trajectoire.
Simulation Turtlesim
Durant notre projet, nous avons décidé d'utiliser deux outils de simulation très utiles pour notre travail. Le premier outil est Turtlesim, qui nous a permis de visualiser la communication entre les différents composants de notre robot en utilisant le middleware ROS (Robot Operating System). Grâce à cet outil, nous avons pu tester la communication entre les différents nœuds ROS et ainsi nous assurer que toutes les données sont bien transmises de manière efficace et cohérente.
Code du noeud "control" :
import rospy from std_msgs.msg import String from geometry_msgs.msg import Twist
#iniation du noeud permettant de commander le robot
rospy.init_node('control')
#action du robot
def movement():
pub = rospy.Publisher ("/turtle1/cmd_vel", Twist, queue_size = 1)
msg = Twist()
msg.linear.x = 1
for i in range (0,3):
pub.publish(msg)
rospy.sleep(1)
msg.linear.x = 0
rospy.sleep(1)
msg.linear.y = 1
for i in range(0,3):
pub.publish(msg)
rospy.sleep(1)
msg.linear.y = 0
rospy.sleep(1)
msg.linear.x = -1
for i in range(0,3):
pub.publish(msg)
rospy.sleep(1)
msg.linear.x = 0
rospy.sleep(1)
msg.linear.y = -1
for i in range(0,3):
pub.publish(msg)
rospy.sleep(1)
msg.linear.y = 0
rospy.sleep(0)
msg.linear.x = 1
for i in range(0,3):
pub.publish(msg)
rospy.sleep(1)
msg.linear.x = 0
#communication entre noeud : émission
def talker():
pub = rospy.Publisher('chatter', String, queue_size=10)
rate = rospy.Rate(10) # 10hz
for i in range(0,10):
hello_str = "good"
rospy.loginfo(hello_str)
pub.publish(hello_str)
rate.sleep()
if __name__ == '__main__':
movement()
talker()
Code du noeud "listener" :
import rospy from std_msgs.msg import String from geometry_msgs.msg import Twist
#action du robot une fois la réponse reçue
def callback(data):
rospy.loginfo('%s', data.data)
if(data.data == "good"):
pub = rospy.Publisher('/turtle2/cmd_vel', Twist, queue_size = 1)
msg = Twist()
msg.linear.x = 1
for i in range (0,3):
pub.publish(msg)
rospy.sleep(1)
msg.linear.x = 0
rospy.sleep(1)
msg.linear.y = 1
for i in range(0,3):
pub.publish(msg)
rospy.sleep(1)
msg.linear.y = 0
rospy.sleep(1)
msg.linear.x = -1
for i in range(0,3):
pub.publish(msg)
rospy.sleep(1)
msg.linear.x = 0
rospy.sleep(1)
msg.linear.y = -1
for i in range(0,3):
pub.publish(msg)
rospy.sleep(1)
msg.linear.y = 0
rospy.sleep(0)
msg.linear.x = 1
for i in range(0,3):
pub.publish(msg)
rospy.sleep(1)
msg.linear.x = 0
while not rospy.is_shutdown():
rospy.sleep(1)
#communication entre noeuds : réception
def listener():
rospy.init_node('listener', anonymous=True)
rospy.Subscriber('chatter', String, callback)
#spin() simply keeps python from exiting until this node is stopped rospy.spin()
if __name__ == '__main__':
listener()
Mapping avec Gazebo
Le second outil de simulation que nous avons utilisé est Gazebo. Cet outil nous a permis de simuler l'environnement dans lequel notre robot pourrait être déployé. Gazebo est capable de simuler un environnement 3D réaliste et de mapper grâce à l'utilisation de capteurs comme le Lidar. En utilisant Gazebo, nous avons pu tester la capacité de notre robot à se déplacer et à agir dans des environnements inconnus et à s'adapter à des situations imprévues. De plus, grâce à Gazebo, nous avons pu automatiser les actions à effectuer par notre robot et ainsi simuler des scénarios qui seraient difficiles à mettre en place dans la vie réelle. En somme, ces deux outils de simulation se sont avérés indispensables pour le développement de notre projet et nous ont permis de valider certaines de nos hypothèses et de tester notre robot dans des environnements virtuels.
Réalisations
Dans le cadre de notre projet, nous avons monté deux TurtleBot en suivant les instructions fournies par le fabricant. Nous avons vérifié que tous les composants étaient correctement assemblés et installés, y compris le Lidar, les capteurs de distance, les caméras et les moteurs. Nous avons également effectué des tests pour nous assurer que les robots étaient en bon état de fonctionnement.
Après avoir terminé le montage, nous avons procédé à l'initialisation du matériel en configurant les Raspberry Pi disponibles sur les robots. Nous avons installé les logiciels nécessaires pour la reconnaissance de l'environnement à l'aide du Lidar, ainsi que pour la planification de trajectoire et la navigation autonome.
Malheureusement, nous avons rencontré des difficultés lors de l'utilisation de ROS avec les machines virtuelles et avec les versions à notre disposition. Cela a entraîné un blocage important dans notre projet, en particulier en ce qui concerne l'utilisation du Turtlebot. Nous avons tenté de transférer le code nécessaire pour faire bouger le robot, mais cela s'est avéré impossible en raison de différentes versions du système Linux. Cette incompatibilité a créé un blocage important dans notre projet, car nous ne pouvions pas tester notre code sur le robot réel.
Face au blocage que nous avons rencontré, nous avons décidé d'adopter une approche proactive pour résoudre le problème. Nous avons alors pris l'initiative de consulter un professeur-chercheur travaillant dans le laboratoire Cristal à proximité de l'école. Nous avons pensé que cela pourrait nous aider à résoudre notre problème de compatibilité du code et à transférer les données nécessaires pour faire bouger le Turtlebot.
Cependant, malgré cette initiative, il s'est avéré que son ordinateur pouvait transférer le code, mais pas les nôtres, ni ceux de l'école. Malgré cela, nous avons apprécié son aide et son soutien dans notre projet.
Pistes d'améliorations
Avec plus de temps, nous aurions voulu trouver un ordinateur présentant les mêmes caractéristiques que celui de l’enseignant chercheur, et nous aurions ainsi pu téléverser le code dans les robots. Cela nous aurait permis d’avoir une démonstration concrète de la communication entre les robots. En effet, nous aurions voulu qu’un premier Turtlebot symbolisant le “robot élévateur” réalise un trajet, puis une fois ce trajet fini, qu’il envoie une notification au second turtlebot afin que ce dernier réalise un trajet à son tour. Nous avons déjà codé ces fonctionnalités et simulées sur Turtlesim. Il ne manque donc plus que l’étape du téléversement pour avoir une démonstration concrète.
L’objectif final de cette solution (TRL 9) serait un kit livrable à tout entrepôt désirant cette technologie. Une fois arrivé sur place, avec une manipulation simple les robots pourraient réaliser une procédure de mapping à l’aide du lidar, rendant les robots capables de se repérer dans l’entrepôt et de repérer les autres robots du système ainsi que tous objets fixes ou mouvant dans l’entrepôt. Suite à une programmation simple, il serait possible de désigner un rôle et une zone d’activité précise pour chacun des robots dans l’entrepôt, ainsi que les emplacements de dépôt des marchandises et de transfert des marchandises entre les robots. Cette solution serait donc facile d’utilisation pour son acheteur et surtout modulable à chaque entrepôt et chaque manière de travailler dans un entrepôt.
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
