IMA3/IMA4 2021/2023 P16

PRESENTATION DU SUJET

Description

Dans le cadre de l'association Robotech, qui souhaite participer à la coupe de France de robotique, nous allons construire un robot mobile. Ce dernier devra accomplir plusieurs tâches qui sont définis par le règlement annuel de la Coupe. Cette année le thème est centré autour de la confection de gateaux. Les robots participants devront ainsi déplacer des couches de gâteaux en carton et manipuler des cerises (balles en mousse).

Les règles sont disponibles ici: https://www.coupederobotique.fr/edition-2023/le-concours/reglement-2023/
Puisqu'une vidéo vaut mieux que 1000 mots, voici notre projet et notre participation à la Coupe de France de Robotique https://youtu.be/sR5h-Wl0wbQ

Ce projet est porté par 4 membres: - MARIE Romain

- MOUTON Albin

- SIMON Elias

- DELAHAIES Servan

Afin de mener à bien ce projet, différentes parties complémentaires devront être réalisées :

- La partie mécanique (réalisée par Charlie FASSENET et Louka CANONE en MECA3)

- La partie électrique

- La partie software

Une vidéo de présentation du projet a été réalisé le semestre dernier dans le cadre du "Projet en 180s" https://www.youtube.com/watch?v=ixoq2OCdTB0&t=1s

Objectifs

Le club de Robotique de polytech Lille réunis autour de mêmes valeurs des personnes passionnées ou présentant une appétence pour la robotique. Les valeurs de ses membres et du club sont l'échange et le transfert de connaissances et plus spécifiquement autour de tout ce qui touche à la robotique et aux nouvelles technologies.

La coupe de France de robotique est un défi ludique, scientifique et technique de robotique amateur, organisé par Planète Sciences. Cette association propose aux jeunes des activités scientifiques et techniques expérimentales dans plusieurs grands domaines tels que la robotique. Cet évènement permet à plusieurs équipes de jeunes passionnés de robotique issues de toute la France d’entrer en compétition en faisant concourir leur(s) robot(s). Chaque équipe doit concevoir puis réaliser un robot autonome, conforme au règlement, apte à participer à plusieurs matchs. Chaque match oppose deux équipes qui chercheront à réaliser le plus de tâches possibles afin de remporter un maximum de points. À l’issue de plusieurs matchs, un classement est réalisé et les trois meilleures équipes françaises sont qualifiées pour la Coupe d’Europe de Robotique : Eurobot.

Nous souhaitons donc créer un robot totalement autonome, capable de se déplacer et d'interagir avec son environnement. Cela nous permet également de mettre en œuvre nos compétences en terme de management & gestion de projet, ainsi qu'en robotique et développement informatique.

ANALYSE DU BESOIN

Positionnement par rapport à l'existant

Il existe des robots autonomes très complexes de toute sortes, mais ici, nous devons répondre à un besoin très précis. Les règles sont fixées par le règlement de la coupe de France de robotique. Nous ne pouvons donc pas vraiment nous positionner par rapport a d'autres robots existant puisque les règles de la coupe changent chaque année.

Néanmoins, nous pouvons regarder ce qui se fait habituellement pour ce genre de compétition.

Robot gagnant de l'édition 2021. AREM - Association de Robotique et d'Electronique des Mines	Robot de L'ARFIT à Polytech Tours

La compétition autorise deux robots par robots max par équipe. On peut ainsi attribuer une tache à chaque robot indépendamment ou alors les faire travailler en collaboratif sur une tache complexe!

Scénario d'usage du produit ou du concept envisagé

On place notre robot sur le plateau de jeu. Au top départ, il dispose de 100 secondes pour réaliser le maximum de gâteaux et gagner des points. Attention tout de même aux obstacles disséminés sur le terrain ainsi qu'au robot de l'autre équipe! En effet, deux équipes concourent par manche et il est interdit de toucher le robot adverse. Et puisque 2 robots sont autorisés par équipe, 4 robots peuvent évoluer sur un terrain de jeu de 2x2m.

=

ÉTUDE DE FAISABILITÉ

Faisabilité budgétaire

Pour réaliser notre projet, nous devons créer un robot, mais aussi imprimer une copie du terrain, construire les différentes structures du plateaux, Le panier, la balise centrale, les balises fixes, créer les couches de gâteux, acheter des balles afin de tester le robot. Nous avons donc besoin d'argent afin de mener à bien notre projet et gagner la coupe. Nous avons donc pu budgétiser le cout du projet et le mettre en forme dans le tableau ci dessous.

Pour mener à bien notre projet nous nous sommes occupés de démarcher différents organismes. Ils ont été choisi selon leur appétence à participer à un projet de type robotique. De notre coté, nous avons axé notre projet comme étant un projet professionnalisant, nous permettant d'acquérir des compétences en accord avec notre formation. De plus, ces subventions serviront en partie à acheter du matériel qui sera réutilisable pour les années suivantes puisque le robot est modifiable.

Finalement, nous avons dépensé près de 3700€ pour toutes les créations et les frais de déplacement.

Heureusement, certains organismes nous ont fourni de l'argent ou du matériel.

Organisme nous ayant aidé	Aide de l'organisme
	300€
	500€
100px	1000€
100px	Remboursement des frais de déplacement
	Imprimante 3D
	Nanopi m4b
100px	Raspberry pi

Faisabilité Eletronique

Les résultats sont encourageants en terme de faisabilité. La carte de contrôle de moteur passe l'intégralité des tests, et la carte principale passe la majorité des tests (tous n'ont pas été effectués)
Il nous reste à nous assurer que les dernières fonctions (port écran, accéléromètre/Gyroscope/Magnétomètre, RTC) fonctionnent correctement.
Cela semble être une base solide pour permettre le développement logiciel.

Des défauts ont cependant été détectés, mais peuvent être corrigés à partir de patchs.
Nous avons donc mis en place un process qualité basé sur 3 feuilles GSheets par PCB.
Chaque PCB a donc un suivi en terme :

• D'erreurs décelées lors de la phase de conception, qui doivent être illustrer par des photos, avec des moyens de les corriger, ainsi qu'une case à cocher si l'erreur a bien été corrigée dans le fichier numérique.
• La liste des cartes, avec leur localisation (pour éviter d'en perdre, savoir laquelle est dans le robot ou sur une paillasse), ainsi que les patchs qui ont été effectués.
• Les différentes versions du PCB

Il est à noter qu'une ébauche de feuille de test unitaires existe, mais n'est pas complète. Elle permet de tester individuellement chaque fonctionnalité de la carte. Cependant, certains tests requièrent une action commandée par logiciel (ex : envoi d'une trame via USB sur un port série sur la carte principale), cela requiert donc d'écrire toute une suite de scripts de tests qui s'avère trop chronophage dans le cadre du projet. Ces tests sont donc réalisés in-situ dans le robot, et devront, à terme être réalisé selon une procédure plus proche de celle effectuée dans l'industrie.

Les fichies de suivi qualité sont disponibles ici :
Contrôleur moteur
Carte mère

Il reste cependant à noter que la majorité de la conception a été faite lors des vacances d'été, permettant d'obtenir un résultat plus rapidement. C'est pourquoi cette conception n'est pas abordée ici.
Cependant, toutes les cartes ont été conçues sur KiCAD 6, et commandée chez JLCPCB (fabrication des PCB & assemblage de la majorité des composants). Certains composants ont été soudés manuellement pour gagner du budget (économiser la sous-traitance d'une intervention humaine pour souder les composants traversants). Ces composants ont été commandés sur AliExpress ou Amazon selon les cas. Tous les câbles ont été sertis manuellement avec une pince à sertir.
Cela nous permet de pouvoir re-sertir de nouveaux câbles adaptés selon la longueur requise dans le robot.

Résultat final (carte de contrôle moteur, carte mère et carte addaptateur 5V=>3.3V pour les Lidar) :

Faisabilité Logicielle

Micrologiciel

Afin de contrôler les moteurs nous devons implémenter une boucle de régulation qui permet d'asservir les moteurs en courant, position ou vitesse.

Chaque moteur a sa propre boucle, elle doit donc pouvoir se répeter 6 fois et le plus rapidement possible.

La valeur associée à la lettre G indiquant un type de commande différent. Par exemple, envoyer une commande de 100 tr/min aux deux premières roues et -50tr/min aux deux secondes s’écrit : G0 X100 Y100 Z-50 U-50

De même, pour obtenir la vitesse lue sur chaque roue, on peut envoyer la commande : G10 X Y Z U

où le contrôleur répondra par : G10 X98.2 Y99.5 Z-51.3 U-46

Voici la liste des commandes implémentées :

Logiciel haut niveau

Nous avons choisi d'utiliser ROS et ses bibliothèques telles que Nav2, TF2 et RpLidar pour gagner du temps.

Ainsi, il faut choisir entre ROS et ROS2.

De plus nous avons pour certains Ubuntu 22 sur nos ordinateurs. Ainsi, nous choisissons ROS2.

Nous devons donc configurer le robot pour ROS2.L'équipe mécanique ayant travaillé sur Fusion 360 pour la modélisation 3D, nous devons exporter les fichiers au format URDF/Xacro.

Pour le modèle cinématique, nous avons utilisé le document suivant : https://research.ijcaonline.org/volume113/number3/pxc3901586.pdf

=

RÉALISATION MÉCANIQUE

Base Roulante

Le robot est composé de 4 roues omnidirectionnelles afin d'optimiser la trajectoire du robot.

Compétion et résultat

Compétiton

La compétition s'est déroulée à la roche sur Yon la semaine du 15 mai 2023. Il nous restait 3 choses à faire avant le début de la compétiton: Placer le bras, coder le bras et définir une stratégie.
Nos objectif: En utilisant tous ses capteurs, le robot doit pouvoir détecter 3 gateaux, les prendre, les trier, les poser dans une zone et revenir au départ. Le robot doit savoir se repérer dans l'espace, détecter les obstacles, repérer les gateaux.Rien n'est laissé au hasard.

En arrivant, notre robot a rencontré plusieurs problèmes. Voilà comment s'est déroulée notre périple:

Mercredi:
15h: arrivée à la compétition, mise en place mécanique du bras. On rencontre des problèmes de précisions au niveau des encodeurs des roues. Ils ne permettent pas de définir correctement une position. On homologue tout de même le robot statiquement (vérifications du périmètre et taille du robot)

Jeudi : La puce wifi a cramé . On ne sait pas vraiment pourquoi. Nous avons donc du passer tout notre code sur un second raspberry. Le problème était que son linux n'était pas configuré comme il fallait. Nous devions donc réimplémenter les variables globales, l'écran etc. Cela a pris une demi journée pour avoir un résultat. Le robot quand à lui est toujours perdu sur la carte car les encodeurs de roues ne renvoient pas de données précises. Nous commençons à désespérer.
18h: après s'être battu toute la journée contre Linux, on effectue un test sur piste. Un pignon de roue se brise alors. Nous n'en avons pas de change.
22h: remplacement du pignon grâce à l'ingéniosité des Meca et de la sauce sweet impérial KFC
6h: Après bidouillage des PID, le robot semble enfin aller droit, prêt à être homologué le lendemain

Vendredi :
7h: Le robot ne roule pas droit, on est au fond du gouffre...
14h: deux heures après la fin officielle des homologations, un juge compatissant nous propose d'homologuer notre robot, ce que nous faisons. Notre robot, bien que ne roulant pas droit, sait tout de même détecter des obstacles (Lidar) et cela suffira. Un match est alors prévu le lendemain matin. Nos objectif: le robot doit prendre 2 gâteaux, les poser dans une zone puis revenir en arrière. Tout cela sans aucun moyen de vision ou de navigation.

Samedi:
8h: Lors d'un test de préhension des gâteaux, une structure imprimé casse. Il faut la changer rapidement avant le début de la compétition.
10h: la pièce est changée, le robot roule droit lors d'un test.
11h: Passage sur la grande scène (voir vidéo). Le robot avance, prend un gâteaux, puis deux. Il dévie ensuite, accroche le mur et se bloque. Fin de match.

Retour sur expérience

En discutant avec d'autres équipes, nous nous sommes rendus compte que beaucoup participent depuis plusieurs années, ou bénéficient des conseils de leurs ainées.
Pour certains la réalisation du robot fait même partie des TP de cours!
Quelques erreurs simple auraient pu être évitées ainsi, comme pour le choix de différents composants. Certains robots sont finalement très simpliste: il n'ont pas de système de détection de gâteaux, ni de tri, ni de préhension; Ils s'attachent juste à pousser les gâteaux selon un parcours prédéfinis.

En même temps se déroulait Eurobot, la même compétition mais à échelle internationale. C'était une superbe expérience, on a pu rencontrer des gens du monde entier, partager nos expériences et voir également comment se sont débrouillé les autres polytech présent (Nancy, Lyon, Grenoble, Tours)

Comptes rendus

15/10

Première séance Exploration des taches pour le semestre Explication du projet à Servan, nouvel arrivant

Etude des robots des années précédentes

Albin travaille sur le PCB

Elias doivent explorer le module ROS et l'installer

Romain commence le code pour contrôler les moteurs

Etude des couts, discussion avec la responsable communication de l'école, Mme Pageau

21/10

Subventions: Explorations des différentes possibilités pour subventionner note projet. Recherche d'un axe pour créer un dossier de subvention

Prise en main de ROS2

28/10

Subventions: Création et mise en ligne d'un projet WWEEDDOO (page web destiné à demander des subventions à l'université) https://wweeddoo.com/projets/MxedvlFW@ Envoie d'un mail à une responsable d'un centre d'aide de la région Tourangelle dans l'objectif de voir s'il y a la même chose en région HDF Débu du micrologiciel du contrôleur moteur (disponible ici)

18/11

Subventions: Premier retour et amélioration du dossier de subventions FDIE Finition de la lettre à Mr Xavier Bertrand pour la subventions HDF Etude des Autres appels à Projets sur WWEEDDOO Rassemblement des Documents avec le BDE pour l'aide HDF

Etude filtre de Kalman dans l'optique de l'essayer sur le turtlebot fourni pas Othman

Commande du PCB de contrôleur moteur

01/12

Subventions: Rencontre avec le BVEH de Lille, le projet leur plait; rassemblement des documents Demande au CROUS également pour élargir notre recherche Retour de la région qui souhaite nous accompagner également

Création du modèle dynamique pour le robot.

08/12

Subventions: Modifications sur les dossiers de subventions pour coller aux éxigences

installation de nav2 sur le robot

15/12

Subventions: Retour de la Région: Il faut plus de 50 personnes pour bénéficier de l'aide Réalisation d'un tableau pour les organismes démarchés Appel avec le BVEH

Installation de TF2 Création du noeud de contrôle de moteur (code disponible ici ) Commande du PCB principal

vacances de décembre

Achat du plateau de jeu, finalisation de l'inscription, écriture du logiciel du micro-contrôleur principal (code disponible ici

18/01

Les petits lidars fonctionnent et affichent une image dans ROS2

Objectifs courts termes: -Finir le plateau, aller voir le service bois pour faire la découpe de l’arène et des murs (demande sur la plateforme faite) -Gérer le gyroscope, récupérer les données -Créer un filtre de Kalman avec les données (Elias) -Etudier les bibliothèques de code de reconnaissance d’image avec la webcam, en choisir une, intégrer un code en Python (Servan) -Générer le plateau sur Nav2 (Romain)

25/01

Albin a réussi à envoyer une vélocité à la carte pour qu’elle envoie une vitesse pour chaque roue. Elias fusion de données Romain génération du terrain Servan :cam

25/01

Romain: faire le service de génération de carte sur ROS (pathfinding) Elias: Filtre de Kalman Albin: création d’un module pour des nouveaux moteurs pas à pas commandés par les méca Servan: reconnaissance de code sur webcam

01/02

Romain: s’est renseigné sur la carte, Montage du châssis Albin: Monte le chassis, il va manquer des vis Servan : Les AR codes sont reconnus, la distance à l’object est renvoyé, le centre est détecté et ses coordonnées sont renvoyées Elias: Toujours sur le filtre, avancé, va rapidement falloir des données

08/02

Romain: Cherche dans la doc comment utiliser le pathfinder, générer un YAML de config Albin: Préparer une deuxième CM Servan: Intégrer sur ROS le code webcam / installer RVIZ sur une VM

On a été accepté par l’univ pour les subventions Mardi Reste à faire: Affiche pour la com Mettre le petit lidar dans un package Utiliser le LIDAR

Le robot est disponible sur le réseau, on peut tous s’y connecter en ssh et bosser dessus Réparer le gyro (en demander un a Mr Lakhal)

Prise de la photo de groupe

15/02

Servan: intégrer RVIZ et faire le noeud webcam Elias intégrer le filtre de kakmann Romain & Albin: intégrer le pathfinding, régler le PID

Le robot dévie pas mal pour l’instant, on pense que c’est du aux points des roues qui ne sont pas tous coplanaires en même temps

01/03

PID ok, le robot dévie encore mais s’en rend compte Albin & Romain: s’attardent sur le pathfinding Elias: finir la conversion des données du lidar en une position du robot https://gitlab.com/es1mon/lidar_cdf.git Servan: installation de la machine virtuelle et test avec des noeuds ROS

A faire: Finaliser la méca (bras, barillet) et intégrer les drivers moteurs Décider des objectifs primordiaux du robot Ecran + interface pour pouvoir lancer rapidement le robot Communication STM32 & Raspi Faire le Noeud principal Aspect de sécu de la batterie, s’éteindre avant la mort Refaire une partie de câblage

08/03

On arrête d’utiliser nav2 pour le pathfinding, on va le faire à la main On demande à Mr Lakhal après de professeurs pour des infos concernant ROS, communication par mail Albin: configure l’écran tactile Romain: étudie l’arbre de comportement Elias: continue à faire des noeuds (noeud de l’imu finit)

Rachat d’un nouveau lidar qui correspond mieux RPLIDAR

15/03

Faire le noeud pour que le stm communique avec le bouton de démarrage

Elias fait un noeud par capteur pour renvoyer les bonnes infos au filtre Louka, un membre de l’équipe méca n’a pas été pris au S5, il part de polytech Albin pas trop dans son assiette, pas optimiste méca+robot Servan :début de la rédaction de la Machine d’état finie

Question pour le professeur spécialiste de ROS: -Bonne pratique un capteur par package? -Filtre un package séparé? -Nav2 est ce qu’est c’est une bonne pratique d’utiliser du slam? slam au début pour cartographier et modifier à la main -Map qui tourne quand le robot tourne -Slam pour la carto? -3 noeuds qui font l'arborescence et le lien entre les repères?