IMA3/IMA4 2021/2023 P16 : Différence entre versions
(→Faisabilité budgétaire) |
|||
| (59 révisions intermédiaires par 4 utilisateurs non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
| − | = | + | =<div class="mcwiki-header" style="border: double; border-color: #000000; border-width:5px; padding: 15px; font-weight: bold; text-align: center; font-size: 80%; background: #E40D31; vertical-align: top; width: 98%;"> PRESENTATION DU SUJET </div>= |
| − | + | [[Fichier:banniere_P16_2.png|center|1500px]] | |
== Description == | == Description == | ||
| Ligne 8 : | Ligne 8 : | ||
| − | Les règles sont disponibles ici: https://www.coupederobotique.fr/edition-2023/le-concours/reglement-2023/ | + | Les règles sont disponibles ici: https://www.coupederobotique.fr/edition-2023/le-concours/reglement-2023/ <br> |
| + | 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: | Ce projet est porté par 4 membres: | ||
| Ligne 25 : | Ligne 29 : | ||
- La partie électrique | - La partie électrique | ||
| − | - La partie | + | - 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" | 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 | + | https://www.youtube.com/watch?v=ixoq2OCdTB0&t=1s |
| − | |||
== Objectifs == | == Objectifs == | ||
| Ligne 39 : | Ligne 42 : | ||
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. | 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. | ||
| − | = | + | =<div class="mcwiki-header" style="border: double; border-color: #000000; border-width:5px; padding: 15px; font-weight: bold; text-align: center; font-size: 80%; background: #E40D31; vertical-align: top; width: 98%;"> ANALYSE DU BESOIN </div>= |
== Positionnement par rapport à l'existant == | == Positionnement par rapport à l'existant == | ||
| Ligne 54 : | Ligne 57 : | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| − | ! Robot gagnant de l'édition 2021.<br />AREM - Association de Robotique et d' | + | ! Robot gagnant de l'édition 2021.<br />AREM - Association de Robotique et d'Electronique des Mines<br /> |
! Robot de L'ARFIT à Polytech Tours | ! Robot de L'ARFIT à Polytech Tours | ||
|- | |- | ||
| Ligne 67 : | Ligne 70 : | ||
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. | 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. | ||
| − | = | + | =<div class="mcwiki-header" style="border: double; border-color: #000000; border-width:5px; padding: 15px; font-weight: bold; text-align: center; font-size: 80%; background: #E40D31; vertical-align: top; width: 98%;"> ÉTUDE DE FAISABILITÉ </div> |
== Faisabilité budgétaire == | == Faisabilité budgétaire == | ||
| − | Pour réaliser notre projet, nous devons créer un robot, mais aussi imprimer une copie du terrain, créer les couches de gâteux, acheter des balles afin de tester le robot. | + | 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. | 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. | ||
| Ligne 79 : | Ligne 82 : | ||
[[Fichier:Orga.png|center|500px]] | [[Fichier:Orga.png|center|500px]] | ||
| + | |||
| + | Finalement, nous avons dépensé près de 3700€ pour toutes les créations et les frais de déplacement. | ||
| + | |||
| + | [[Fichier:Argent pour CdFR.png|center|600px]] | ||
| + | |||
| + | Heureusement, certains organismes nous ont fourni de l'argent ou du matériel. | ||
| + | |||
| + | {| class="wikitable" | ||
| + | |- | ||
| + | ! Organisme nous ayant aidé | ||
| + | ! Aide de l'organisme | ||
| + | |- | ||
| + | | [[Fichier:IFM_CdFR.png|100px]] | ||
| + | | 300€ | ||
| + | |- | ||
| + | | [[Fichier:AI.jpg|100px]] | ||
| + | | 500€ | ||
| + | |- | ||
| + | | [[Fichier:FSDIE_CdFR.jpg|100px]] | ||
| + | | 1000€ | ||
| + | |- | ||
| + | | [[Fichier:Département_SE_CdFR.jpg|100px]] | ||
| + | | Remboursement des frais de déplacement | ||
| + | |- | ||
| + | | [[Fichier:Dagoma_CdFR.png|100px]] | ||
| + | | Imprimante 3D | ||
| + | |- | ||
| + | | [[Fichier:FriendlyElec_CdFR.png|100px]] | ||
| + | | Nanopi m4b | ||
| + | |- | ||
| + | | [[Fichier:Sitrus_CdFR.jpg|100px]] | ||
| + | | Raspberry pi | ||
| + | |- | ||
| + | |} | ||
== Faisabilité Eletronique== | == 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) <br/> | ||
| + | Il nous reste à nous assurer que les dernières fonctions (port écran, accéléromètre/Gyroscope/Magnétomètre, RTC) fonctionnent correctement. <br/> | ||
| + | Cela semble être une base solide pour permettre le développement logiciel. <br/> | ||
| + | |||
| + | Des défauts ont cependant été détectés, mais peuvent être corrigés à partir de patchs. <br/> | ||
| + | Nous avons donc mis en place un process qualité basé sur 3 feuilles GSheets par PCB. <br/> | ||
| + | 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 | ||
| + | |||
| + | [[File:amouton_correction_pcb.jpg|400px|Une correction de PCB, couper la mauvaise ligne de Reset au cutter et relier la bonne ligne]] [[File:amouton_correction2_pcb.jpg|400px|isoler un VIA qui court-circuite 5V et GND]] | ||
| + | |||
| + | 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. <br/> | ||
| + | |||
| + | Les fichies de suivi qualité sont disponibles ici : <br/> | ||
| + | [https://docs.google.com/spreadsheets/d/1K_Z1RJ5BMpk5G3NSwwMG7BLIiOSbLogbxP4zIx_rXbs/edit?usp=sharing Contrôleur moteur] <br/> | ||
| + | [https://docs.google.com/spreadsheets/d/17E7tjglp6ywglcdlILahTcoudzf9zcykt1X-73CqGes/edit?usp=sharing Carte mère] <br/> | ||
| + | |||
| + | 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. <br/> | ||
| + | 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. <br/> Cela nous permet de pouvoir re-sertir de nouveaux câbles adaptés selon la longueur requise dans le robot. <br/> | ||
| + | |||
| + | [[File:amouton_cable_pcb.jpg|400px|Un connecteur serti]]<br/> | ||
| + | Résultat final (carte de contrôle moteur, carte mère et carte addaptateur 5V=>3.3V pour les Lidar) : <br/> | ||
| + | [[File:amouton_moteur_pcb.jpg|400px|Contrôleur Moteur]] [[File:amouton_main_pcb.jpg|400px|Carte mère]] [[File:amouton_adapt_pcb.jpg|400px|Carte d'adaptation]] | ||
== Faisabilité Logicielle== | == 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. | ||
| + | |||
| + | [[Fichier: PID.png|450px]] | ||
| + | |||
| + | 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 : | ||
| + | |||
| + | [[Fichier:tableauGCode.png|450px]] | ||
| + | |||
| + | |||
| + | === 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. | ||
| + | |||
| + | [[Fichier:ROS.png]] | ||
| + | |||
| + | 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. | ||
| + | |||
| + | [[Fichier:FusionRviz2.png]] | ||
| + | |||
| + | Pour le modèle cinématique, nous avons utilisé le document suivant : https://research.ijcaonline.org/volume113/number3/pxc3901586.pdf | ||
| + | |||
| + | =<div class="mcwiki-header" style="border: double; border-color: #000000; border-width:5px; padding: 15px; font-weight: bold; text-align: center; font-size: 80%; background: #E40D31; vertical-align: top; width: 98%;"> RÉALISATION MÉCANIQUE </div> | ||
| + | |||
| + | == 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. <br> | ||
| + | ''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:''' <br> | ||
| + | 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. | ||
| + | <br>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. | ||
| + | <br>22h: remplacement du pignon grâce à l'ingéniosité des Meca et de la sauce sweet impérial KFC | ||
| + | <br>6h: Après bidouillage des PID, le robot semble enfin aller droit, prêt à être homologué le lendemain | ||
| + | |||
| + | '''Vendredi :''' <br> | ||
| + | 7h: Le robot ne roule pas droit, on est au fond du gouffre... | ||
| + | <br>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:'''<br> | ||
| + | 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. | ||
| + | <br>10h: la pièce est changée, le robot roule droit lors d'un test. | ||
| + | <br>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. <br> | ||
| + | Pour certains la réalisation du robot fait même partie des TP de cours! <br> | ||
| + | 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. <br><br> | ||
| + | |||
| + | 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 == | == 15/10 == | ||
Première séance | Première séance | ||
| Ligne 92 : | Ligne 239 : | ||
Albin travaille sur le PCB | Albin travaille sur le PCB | ||
| − | |||
| − | Etude des couts, discussion avec la responsable | + | 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 [https://gitlab.com/robotech-lille/motorcontrollerunit ici]) | ||
| + | |||
== 18/11 == | == 18/11 == | ||
| − | + | ||
| + | Subventions: | ||
Premier retour et amélioration du dossier de subventions FDIE | Premier retour et amélioration du dossier de subventions FDIE | ||
Finition de la lettre à Mr Xavier Bertrand pour la subventions HDF | Finition de la lettre à Mr Xavier Bertrand pour la subventions HDF | ||
Etude des Autres appels à Projets sur WWEEDDOO | 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 [https://gitlab.com/robotech-lille/ros_motorcontrollernode 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 [https://gitlab.com/robotech-lille/MainBoardMCU 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? | ||
Version actuelle datée du 27 mai 2023 à 15:33
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.
=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
=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?
