Version du 29 janvier 2020 à 15:15

Présentation générale

Description

Ce projet à pour but de réaliser un robot autonome capable de se déplacer en toute sécurité et d'interagir avec les personnes aux alentours. Son utilisation première sera d'accueillir les visiteurs à Polytech et de les conduire à une salle particulière en empruntant le chemin le plus optimisé (pour lui et pour la personne).

Objectifs

Pour réaliser ce robot, il faut pouvoir le programmer pour qu'il puisse se repérer dans son environnement, à l'aide de capteurs et d'une kinect. Il faut ensuite intégrer une synthèse vocale et gérer l'écran pour qu'il puisse communiquer. Pour accompagner au mieux la personne, il devra savoir prendre les ascenseurs (en appuyant sur les bons boutons ou en demandant aux personnes d'appuyer sur tel ou tel bouton). Enfin, il faudra gérer la batterie et la recharge de ce robot.

Analyse du projet

Positionnement par rapport à l'existant

Analyse du premier concurrent : Pepper

"Pepper de SoftBank Robotics"

SoftBank Robotics est une société de robotique japonaise parmi les leaders mondiaux dans le domaine de la robotique humanoïde. Ils ont de nombreux clients comme par exemple Renault, BMW, Carrefour... Son affiliation avec une banque lui permet de bénéficier de gros apports financiers pour la conception de leurs robots. En 2014, le robot Pepper est lancé. Il doté d'un écran et de caméras pour intéragir avec son entourgae. Par exemple, il reconnait les visages et les émotions. Il peut communiquer grâce à son écran tactile et la parole grâce à la synthèse vocale.

Caractéristiques techniques:

• Dimensions (en cm): 120 x 42.5 x 48.5
• Poids: 28 kg
• Charge utile: 500g à bout de bras
• Automonie: environ 12h
• Vitesse max: 5km/h

https://www.softbankrobotics.com/emea/fr/pepper

Analyse du second concurrent : Heasy

"Heasy de Hease Robotics"

Notre deuxième concurrent est la compagnie HEASE Robotics créée en 2016, qui se situe à Villeurbanne, près de Lyon. Cette compagnie s’attache particulièrement au marché des robots de service professionnel dans les domaines du retail et de la relation client avec son robot HEASY. Ce robot est présent dans des environnements tels que des centres commerciaux, des aéroports, des gares ou encore des entreprises. Il est capable de divertir, de guider, d'accueillir et de donner des informations simples aux clients, pour des informations plus complexes il met directement le client en relation avec un agent d'accueil. Avec la possibilité d’une mise en place d’un ensemble de robot HEASY dans un de ces lieux, l’agent d'accueil pourrait alors voir ses capacités démultipliées.

"Exemples d'application d'Heasy"

https://heaserobotics.com/heasy-for-retail/

Analyse du troisième concurrent : Keylo

"Keylo de Wycas Robotics"

Wycas Robotics est une start up toulousaine lancée en octobre 2015,qui développe des solutions d'accueil et d'assistance physique du client à distance. La start up commercialise Keylo, un robot d'accueil à navigation autonome qui accompagne le visiteur dans les centres de stockage et le met en relation avec des téléopérateurs par visioconférence. Après avoir fait une levée de fonds de 350 000 euros auprès de ses actionnaires, la société à décidée d'exporter son robot Keylo dans le milieu médical. Dans cette situation le robot sera destinée à l'accueil et au service du patient en milieu hospitalier. Dressé sur roues, Keylo se déplace grâce à un laser complété par une caméra 3D et un odomètre.

http://www.wyca-robotics.com/

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

Le robot envisagé se présenterait à l'accueil de l'école. Comme souvent, des intervenants extérieurs viennent faire des présentations. Il peut être difficile de trouver certaines salles quand on ne connaît pas l'école. C'est à ce moment là que le robot Centaure intervient. Le visiteur se dirige vers le robot. Ce-dernier va le repérer et lui proposer ses services (indiquer le chemin ou guider la personne jusqu'à la salle). Le visiteur sélectionne le service souhaité (directement sur l'écran ou vocalement).

• Dans le premier cas, il affiche le plan de l'école et décrit l'itinéraire.
• Dans le second cas, il accompagne la personne jusqu'à la destination souhaitée en empruntant le chemin le plus adapté (prendre l'ascenseur, éviter les couloirs bondés).

Une fois la mission accomplie, il retourne à l'accueil, prêt à accueillir une nouvelle personne. Il peut aussi recevoir une requête d'une personne perdue dans Polytech via le site internet du robot.

Réponse à la question difficile

Questions difficiles :

Comment le robot gère t-il l'ascenseur?
Dans l'idéal, pour accompagner au mieux les personnes, c'est le robot qui appuie lui même sur le bouton de l'étage où la personne veut aller. Pour cela, il lui faudrait un bras robotisé muni de moteurs et de capteurs pour appuyer sur les boutons. Il faudrait donc pouvoir repérer les boutons des ascenseurs à l'aide d'une caméra et savoir s'il est bien déclenché. Cela représente trop de complications et ce n'est pas le but principal du robot. La fonction principale du robot est de guider la personne jusqu'à la salle demandée. La robot demandera donc simplement à la personne d'appuyer sur le bon bouton. Cependant, il se peut que la personne comprenne mal le robot ou appuie sur le mauvais bouton. Le robot doit donc vérifier qu'il est bien au bon endroit. Pour cela, nous allons utiliser des QR codes qui seront présents à la sortie de chaque ascenseur en indiquant l'étage et le bâtiment. On utilisera ce même système pour s'assurer que le robot est arrivé à la bonne salle.

Bibliographie et webographie

Site robot Pepper : https://www.softbankrobotics.com/emea/fr/pepper
Site robot Heasy : https://heaserobotics.com/heasy-for-retail/
Site robot Keylo : http://www.wyca-robotics.com/

Préparation du projet

Cahier des charges du groupe

La mission du robot Centaure est de guider une personne dans Polytech jusqu'à la salle requise. Pour cela, le robot doit prendre contact avec la personne. Il repère la personne ou cette dernière interagit avec lui à l'aide de l'application/site Web et lui donne sa requête (le conduire à telle salle ou lui indiquer le chemin à prendre pour rejoindre telle salle). Soit le robot affiche la carte de l'école sur l'écran, soit il conduit la personne à la salle. Pour cette dernière mission, le robot va se déplacer de manière autonome dans Polytech jusqu’à la salle. Il va se repérer dans l'espace grâce à des capteurs et des qr code disposés dans l'école. Il pourra ainsi prendre l'ascenseur et s'assurer qu'il est au bon endroit.

Objectif du semestre 6:

Nous devons faire le bilan technique du robot et analyser les améliorations que nous pouvons apporter comme par exemple réorganiser la partie mécanique. Nous devons aussi pouvoir utiliser la kinect pour lire des QR codes et faire en sorte que le robot se déplace de manière autonome à l'aide de ses capteurs.

• Repérage dans l'espace
  • Utiliser différents capteurs: Ne pas heurter les utilisateurs
  • Cartographier l'école avec les différentes positions des salles (QR code ascenseur, triangularisation pour la position)
  • Effectuer le déplacement vers les salles

• Communication extérieure
  • Gestion de la synthèse vocale
  • Créer une interface Homme/Machine

Cahier des charges des équipes

Equipe 1 : Théo et Valériane: Communication extérieure

Notre équipe s'occupe de la communication du robot avec les personnes qui l'entourent. Nous allons gérer la partie interaction du robot en réalisant une reconnaissance vocale et une synthèse vocale. On s'occupera aussi de l'affichage sur l'écran intégré au robot. On affichera des informations diverses sur les services qu'il propose (affichage d'une carte interactive, choix de la salle à atteindre).

Equipe 2 : Corentain et Loïc

Notre équipe s'occupant du traitement des images renvoyées par la Kinect nous devront apprendre à utiliser la librairie C libfreenect ce qui nous permettra d'analyser les informations reçues par la Kinect.
Nous devrons donc réussir à repérer un visage qui se trouvera devant la Kinect mais aussi repérer les différents QR code disposés dans l'école par l'équipe 3 et utiliser les informations qu'ils donneront.

Equipe 3 : Thibault et Pierre

• • Savoir se repérer dans l'espace à l'aide d'une triangulation par le Wi-Fi de Polytech et un système odométrique.
  • Savoir recalibrer sa position en lisant des balises placées dans Polytech.
  • Eviter les obstacles ou s'arrêter en cas d'urgence.
  • Calculer un itinéraire afin de trouver le chemin le plus court.

Choix techniques : matériel et logiciel

Equipe 1

• Ecran:
  • Ecran actuel non tactile (à changer ?)

• Synthèse vocale:
  • Haut parleur
  • Logiciel :

• Reconnaissance vocale:
  • Utilisation de la reconnaissance vocale de la Kinect

Equipe 2 : Loïc et Corentain

Matériel :

• D'une Kinect

Logiciel :

• Nous utiliseront seulement de la programmation en C ainsi que la librairie libfreenect pour l’analyse et le traitement d’image.

Equipe 3

Logiciel : https://www.indooratlas.com/

QR code

Kinect

Liste des tâches à effectuer

Equipe 1: Communication extérieure

Notre équipe s'occupe de la communication entre le robot et l'utilisateur. Cela se fera par l'intermédiaire de l'écran, d'un site internet ou application et d'une synthèse vocale.

• Ecran:
  • Affichage d'un visage, animation de celui-ci
  • Affichage du texte
  • Affichage de la carte de l'école

• Synthèse vocale:
  • Prise de contacte avec l'humain
  • Donner des indications de parcours
  • Plusieurs langues disponibles

• Reconnaissance vocale:
  • Micro pour entendre la requête de l'humain
  • Plusieurs langues reconnues

• Site internet / application
  • Soumettre des requêtes au robot

Equipe 2 : Loïc et Corentain

Notre équipe s'occupant du traitement des images renvoyées par la Kinect nous devront mettre en place :

• Le repérage d'une ou de plusieurs personnes se situant devant l'écran.
• Le scan des QR codes présent dans Polytech

Equipe 3

Notre équipe s'occupera de la partie déplacement du robot :

• Cartographier l'école Polytech
• Définir des zones de tags
• Effectuer un déplacement vers un endroit précis

Calendrier prévisionnel

Le calendrier prévisionnel peut se concrétiser sous la forme d'un diagramme de GANTT.

• 

  De Fevrier à Avril

• 

  De Mai à Juillet

Réalisation du Projet

Projet S6

Eventuellement créer des sous-pages par équipe avec le compte-rendu des réunions de groupe sur cette page principale.

Semaine 4

Lors de cette séance, nous avons établi le cahier des charges par équipe pour nous répartir le travail. Nous avons ensuite rédigé le calendrier prévisionnel complet pour le projet.

Semaine 5

Nous avons profité de cette séance pour prendre connaissance de l'avancement des IMA 5 sur le projet. Nous avons discuté avec eux des différentes spécificités du robot (allumage du robot, présence du bouton d'urgence, problème avec l'écran..). Nous avons aussi récupéré les différents documents présentant le robot (rapport de PFE, codes du robot et du site) pour être complètement autonome lors du départ des IMA5.

Semaine 6

Le projet IMA5 étant terminé, nous allons pouvoir commencer à prendre en main le robot. Nous avons tout d'abord essayé de l'allumer. Cependant, lors de la démonstration des IMA5, ils avaient modifié le code pour commander le robot avec le site web. N'ayant pas encore les bonnes configurations pour utiliser le site web, nous avons modifié le code pour remettre par défaut la liaison série. Lors du démarrage, nous avons remarqué un dysfonctionnement au niveau de la roue droite. Après vérification des branchements, nous avons remarqué un faux contact au niveau du variateur de vitesse. Après avoir resserré le câble, la roue tournait. Il ne restera plus qu'à gonfler les pneus et améliorer la direction. En effet, il ne suit pas exactement les directions qu'on lui donne.

Semaine 7

Prise en main du projet. Nous avons remplacé l'écran de base qui s'éteignait au bout de 10 secondes par un autre. Mais le problème persiste. On pense à un problème d'alimentation car lorsque l'on branche un écran alimenté sur secteur, tout fonctionne. Ensuite, nous avons décidé d'installer l'IDE Arduino directement sur le robot pour simplifier la programmation de ce dernier.

Semaine 8

Comme le problème de l'écran n'était pas encore résolu, nous nous sommes concentrés sur celui-ci. Durant la séance, nous avons remarqué que l'écran ne s'éteignait pas, mais c'était le rétroéclairage de l'écran qui diminuait considérablement après quelques secondes. Nous avons donc mesuré la tension d'entrée de l'écran et nous nous sommes rendu compte que cette tension était égale à 11,7V. Nous avons donc testé l'écran sur secteur et nous avions bien une tension de 12,4V. L'écran était donc sous alimenté, ce qui explique la diminution du rétroéclairage de l'écran. Après avoir lu la datasheet du convertisseur DC/DC RSD-150-B-12, nous avons décidé de l'utiliser pour le robot, car celui là délivre une tension modulable. En parallèle, nous avons remarqué que le câblage interne n'était pas assez organisé pour pouvoir manipuler l'intérieur du robot avec aisance. En effet, les câbles prenaient beaucoup de place dans le robot, ce qui fait que nous ne pouvions pas accéder correctement aux différents ports du PC. Nous avons donc décidé de réorganiser le câblage interne.

Semaine 9

Nous avons commencé par réaliser des schémas de câblage et étiqueter les câbles que nous allons réutiliser lors du nouveau câblage. Nous avons aussi commencé à prendre en main la kinect et à se renseigner sur son fonctionnement.

Semaine 10

Nous avons lancé la commande du convertisseur DC DC pour l'alimentation de l'écran. Nous avons divisé le groupe pour s'occuper des deux enjeux majeurs: refaire une carte PCB sur Altium dans le but d'améliorer le câblage et réaliser la synthèse et la reconnaissance vocale. Pour la carte PCB, nous voulons utiliser des borniers pour les pins pour que le câblage soit plus propre et plus solide.

Semaine 11

HARDWARE:

Nous avons reçu le nouveau convertisseur DC DC. Nous avons procédé à des test de celui-ci. Il semble chauffer un peu trop (Pierre a dit: "On a dead ça")

aperçu de notre robot en ce jour

Le nouveau convertisseur alimente l'écran correctement, en un peu plus de 13V, cela corrige le problème de luminosité de l'écran, cependant après quelques minutes de la fumée semble se dégager du robot. A la vue de l'inquiètante fumée se dégageant du robot, nous décidons de procèder au décablage complet dans le but d'identifier les éventuels éléments ayant brûlés. De plus le décablage complet du robot nous permettra de mieux comprendre le fonctionnement de celui-ci et de procéder à un recâblage plus propre.

SOFTWARE:

Des recherches sont effectuées dans le but de trouver et comprendre le fonctionnement d'une synthèse vocale. Le système MaryTTS semble être un bon candidat, cependant nous ne parvenons pas à l'installer. Nos recherches continuent donc dans le but de trouver une synthèse vocale si possible codée en C.

Semaine 12

HARDWARE Finition de la dissection du robot, cette manipulation nous prend du temps, en effet chaque câble retiré est retranscrit sur un schéma de câblage, dans l'espoir d'être capable de remonter le robot. Les couleurs correspondent aux vraies couleurs des câbles et ne respectent pas les couleurs conventionnelles.

Plan du câblage

En parallèle on commence la conception d'un nouveau shield sur le logiciel Altium. L'objectif de ce nouveau shield est de permettre l'utilisation de borniers pour maintenir les différents câbles et ainsi obtenir un câblage plus propre et plus sécurisé. Cependant notre méconnaissance du logiciel Altium complique cette tâche. Découverte du site snapeda pour télécharger les empreintes des borniers que nous allons utiliser car ils ne sont pas présents dans la bibliothèque de base.

SOFTWARE Les recherches d'une synthèse vocale continuent.

https://community.gladysassistant.com/t/tutoriel-gladys-et-la-reconnaissance-vocale/1419

https://community.gladysassistant.com/t/tutoriel-installation-kinect-pour-la-reconnaissance-vocale/1495

Semaine 13

Nous avons entièrement démonté la partie supérieure du robot pour s'assurer qu'il n'y avait pas de câbles défecteux qui auraient pu causer la fumée. Dans un même temps, nous faisons des tests avec la Kinect pour comprendre le fonctionnement et réussir à utiliser la caméra pour la future reconnaissance faciale et le micro pour la future reconnaissance vocale. Cependant, après quelques échecs, on se demande s'il ne faudrait pas plutôt utiliser une simple webcam à la place de la kinect.

Semaine 14

Nous travaillons sur la nouvelle carte PCB, cependant, nous avons uniquement pu récupérer le fichier .PCBdoc des IMA5 sans leur schematic. Cela ralentit notre progression car cela nous impose l'utilisation du logiciel Altium que nous ne maitrisons pas. Aussi, nous n'arrivons pas à relier le nouveau bornier aux autres composants avec des pistes. Nous demandons l'aide d'Alexandre Boé pour nous expliquer. Le problème venait des noms des pistes qui n'étaient pas les mêmes, donc le logiciel refusait de les relier. Une fois les pistes renommées, nous avons pu relier les anciennes pistes aux nouveaux borniers. Dans un même temps, nous avons réussi à faire fonctionner la caméra de la kinect à l'aide du logiciel freenect. Cependant, nous n'arrivons pas à récupérer le flux vidéo. Nous décidons d'essayer avec une simple webcam et d'OpenCV. Nous n'avons pas réussi à installer complètement sur Linux. En réessayant sur le PC de Théo qui fonctionne sous Windows, on a pu vérifier qu'OpenCV fonctionnait et qu'on arrivait à avoir une reconnaissance faciale qui fonctionne approximativement.

En parallèle, nous nous occupons de la structure du robot. Après avoir démonté l'étage supérieur du robot, nous avons analysé ce qui aurait pu entraîner la création de fumée dans le robot. Comme la fumée semblait venir de l'espace entre les variateurs de vitesse, nous nous sommes dit que cela venait d'un des variateurs. Cependant, en aucun cas le nouveau convertisseur n'était relié aux variateurs et les variateurs n'avaient pas d'anomalies lorsque nous étions avec l'ancien convertisseur DC/DC. La fumée ne venait donc pas des variateurs. Ensuite, nous avons cherché des endroits où il y aurait pu avoir des court-circuits ou des câbles en mauvais état pouvant entraîner une surchauffe de la gaine protectrice des fils électriques. Mais là encore, les câbles n'avaient pas de défauts en particulier. Les seuls câbles étant en mauvais état ont été retirés et changés lorsque nous avons commencé à refaire le câblage de la partie supérieure de l'intérieur du robot.

Semaine 15

En démontant le robot, nous avons remarqué que la kinect était restée branchée. Elle ne doit pas être alimenté en plus de 12V. Cependant, nous lui avons donné du 13,3. Après vérification, la kinect n'est pas endommagé mais le transformateur de l'alimentation ne fonctionne plus. D'après nos observations, il se trouvait à l'endroit d'où venait la fumée. On pense donc que la fumée venait de là. Il faudra analyser le transformateur pour savoir si on peut en faire un nous même.

En parallèle, nous avons programmé la reconnaissance vocale et la reconnaissance faciale que nous voulons utiliser pour le robot. Pour le moment, la reconnaissance vocale fonctionne mais n'est pas assez précise et pour la reconnaissance faciale, la caméra détecte bien les visages. Cependant, elle ne peut pas différencier un visage d'un autre, c'est-à-dire que le logiciel sait qu'il y a un visage en face de lui, mais il ne connait pas l'identité de celui-ci. De plus, il nous reste maintenant à utiliser cette reconnaissance faciale dans un programme qui permette ensuite de faire une interaction avec l'utilisateur.

Nous avons aussi commencé à modifier le programme Arduino du robot. Ce dernier fonctionnait pour une utilisation avec une manette ou via le site Web. Nous avons modifié le code pour qu'il prenne en compte les obstacles dans ces deux cas, mais aussi pour qu'il sache directement si on le commande via la manette ou via le site Web (précédemment, il fallait modifier une variable manuellement dans le code Arduino pour faire le changement de mode). Maintenant, il écoute le port série et s'il ne reçoit rien c'est qu'on le commande via le joystick. Nous allons aussi modifier le code pour intégrer un mode de déplacement autonome. Nous étudions la possibilité de faire aller le robot dans l'autre sens, pour avoir la roue folle à l'arrière et qu'il soit donc plus stable lors de ses mouvements.

Nous avons également fini le nouveau PCB qui nous facilitera grandement les branchements et réduira les risques de faux-contact du à des câbles mal branchées ou autres. Celui-ci reste encore à faire vérifier par M.Boé avant son impression :

"Nouveau PCB"

Concernant le serveur, pour effectuer des tests sur celui-ci nous avons choisi d'ajouter deux boutons à la page internet, ainsi que de modifier le code en Node.js pour envoyer des caractères sur la liaison série à l'appuie sur ces deux boutons. Nous avons également réaliser un programme simple sur Arduino pour qu'à la réception de ces messages sur son port série il allume ou éteigne une led. Cependant nous rencontrons des difficultés à démarrer le serveur, nous avons donc contacté les IMA5 pour avoir plus d'explications sur son démarrage, nous sommes dans l'attente d'une réponse.

Pour permettre un rendu plus propre, nous avons conçu une boîte à l'aide du logiciel On shape qui intègre le PC et l'arduino.

Bilan

À la fin du semestre, nous pouvons poser un bilan de notre avancement par rapport aux objectifs initiaux. Nous devions réaliser la commande autonome du robot, la reconnaissance et la synthèse vocale et faire en sorte que le robot se repère dans Polytech. En récupérant le robot, ces objectifs ont été modifiés. Nous devions en priorité modifier le câblage de ce robot. Nous avons donc à l'heure actuelle un robot réorganisé et qui contient une reconnaissance vocale et faciale et une synthèse vocale. Un nouveau shield a été réalisé et n'attend que la validation et la disponibilité de la machine pour être fait. Un prototype d'une boîte à été réalisé pour ranger le PC ainsi qui l'arduino, le relai et le disque dur du PC.

Pour l'année prochaine, les objectifs sont d'imprimer le nouveau PCB, rendre autonome le robot et le faire se repérer dans Polytech.

Documents Rendus

Le software: https://we.tl/t-taSvegTQXq

Le rapport : Fichier:Rapport Projet IMA3.pdf

Projet S7

Etat des lieux au début du semestre 7

Nous reprenons le projet Centaure avec des modifications dans l'équipe. Nous accueillons Clément et Samuel. Nous devrons donc premièrement réorganiser les sous équipes. Suite à l'état des lieux, des priorités ont été établies. Les objectifs du semestre 7 pour le projet était principalement d'avoir une base solide sur les différentes parties du robot pour être efficace au semestre 8. Nous devons tout d'abord nous réapproprier le robot et son matériel. Nous récupérons la caisse avec notre matériel que nous devrons trier. Nous devrons ensuite nous concentrer sur la partie mécanique du robot et refaire tout son câblage et finir le shield Arduino pour permettre au robot de rouler à la fin du semestre. Cela nous permettra de réaliser la suite des tâches au semestre suivant. Le câblage fait, nous pourrons travailler sur le déplacement du robot et son repérage dans l'espace. Pour cela, il faudra récupérer des informations grâce à la kinect et relancer le serveur réalisé par le dernier groupe à avoir travaillé sur le projet.

Nous avons choisi d'organiser notre équipe sous 3 pôles : la partie câblage du robot, la partie Arduino/serveur et la partie kinect. En effet, nous ne pouvons pas être 6 à travailler sur le câblage du robot car cela ne serait pas optimal et nous ferait prendre du retard pour le semestre suivant. Voici donc les différentes avancées de ces 3 pôles.

Partie câblage du robot

Au début du semestre, nous récupérons le robot avec le câblage de la fin du semestre 6.

Le premier constat est le manque de schéma de fonctionnement clair. Après avoir parcouru les différents wiki concernant le robot Centaure, nous nous sommes rendu compte qu'il fallait le redéfinir complètement.

En effet, si l'on prend par exemple le schéma électrique de l'année 2017/2018 (Projet P50), nous nous apercevons de la présence d'un étage dédié à la recharge des batteries sur le secteur. Or dans le robot, aucun équipement ne permet cette fonction. De plus, nous utilisons deux convertisseurs de tension (1 pour la Kinect et 1 pour la carte Arduino) ce qui n'est pas le cas sur ce schéma. De par sa caducité, il nous est impossible de l'exploiter. Etant donné les différentes modifications matérielles qui ont été réalisées les dernières années, nous nous basons sur le schéma de l'an dernier pour réaliser le nôtre.

Un deuxième constat s'est fait vis-à-vis du cablâge en place sur le robot.

Nous avons remarqués plusieurs problèmes de fond au câblage :

• fusibles non utilisés,
• gaines des câbles entaillées et "réparées" avec du scotch,
• câbles volants.

Nous pouvons noter le choix peu judicieux de conducteurs rigides, alors qu'il est conseillé d'employer des conducteurs multibrins étant donné l'utilisation visé (Robot mobile).

Enfin, le dernier constat concerne la disposition des éléments dans le robot, certains équipements de sécurité, comme le porte fusible ou le bouton d'arrêt d'urgence n'étaient pas (ou peu) accessibles.

Nous réalisons que nous ne devons pas juste réorganiser le câblage mais bien tout recommencer dès le départ. Nous étudions la manière de réorganiser l'intérieur même du robot. Nous avons pu récupérer les fichier SVG de la plaque de plexiglas qui maintenait les batteries en place. Nous modifions cette plaque pour correspondre à notre nouvelle organisation. Aussi, lorsque nous pourrons réserver un créneau au Fab et que nous aurons reçu le plexiglas, nous découperons cette plaque ainsi que la nouvelle boîte, elle aussi en plexiglas.

Nous sommes aussi en attente de notre commande chez RS pour réaliser le câblage. Nous avons commandé de nouveau variateurs qui prendront beaucoup moins de place dans le robot, ainsi que des goulottes pour passer les câbles plus proprement. Nous sommes donc à la fin du semestre 7 bloqués par les délais de livraison pour finir le câblage.

Partie Arduino/Serveur

Durant ce semestre notre objectif était de reprogrammer la carte Arduino et de remettre en route le serveur pour pouvoir faire rouler le robot. Nous nous sommes donc réparti les tâches : l'un s'occupant de la carte Arduino et l'autre du serveur.

Shield Arduino

Le shield Arduino réalisé en fin d'année passée a été modifié afin de correspondre a nos nouvelles attentes, une fois vérifié il a été imprimé puis brasé. L'impression, le brasage, ainsi que le test de cette nouvelle carte nous aura pris un grand nombre de séance de projet du semestre 7, mais elle est entièrement fonctionnelle.

Carte Arduino

Pour pouvoir programmer la carte Arduino, nous devions savoir comment utiliser les nouveaux contrôleurs moteurs, malheureusement nous ne les avons pas reçu à temps pour commencer à travailler dessus. Mais nous avons commencé le programme en y ajoutant les valeurs reçues par le joystick et les capteurs de distance qui sont d'ailleurs très similaires aux anciens. En effet, nous avons fait le choix de remplacer les anciens capteurs de distance par des nouveaux captant des distances plus faibles et donc plus raisonnable pour éviter les obstacles.

Serveur

Côté serveur nous avons eu beaucoup de mal à remettre en route celui effectué par les IMA5, leurs indications n'étaient pas assez claires et nous avons donc dû faire du débogage. Nous sommes finalement parvenus à le lancer en apprenant à programmer en nodejs . A ce jour nous sommes capables de pouvoir contrôler une carte Arduino en envoyant des données sur le port série grâce au serveur et au client.

Partie Kinect

A la fin du semestre 6, l'équipe avait eu des difficultés à utiliser la kinect et s'était donc rabattu sur une reconnaissance vidéo grâce à une webcam. Cependant nous pensons que l'utilisation d'une kinect est bien plus appropriée à l'utilisation du robot. La kinect nous permettant de reconnaître la présence d'un humain et de déterminer la distance puisqu'elle est dotée de 2 lentilles ainsi que d'un capteur infrarouge. Nous avons donc utilisé le kit de développement logiciel fourni par Microsoft pour adapter les fonctions de la kinect à notre programme. Nous sommes parvenus à avoir un programme qui fonctionne (i.e. reconnaissance de personnes dans le champ de vision, détection d'un obstacle et de la distance à laquelle il se situe). A noter que le robot n'étant pas encore opérationnel, tous ces tests ont été réalisés à partir d'une kinect fixe (donc pas en conditions réelles).

L'objectif est maintenant double:

• Savoir quand un humain souhaite inter-agir avec le Centaure
• Détecter et éviter des obstacles tout en maintenant une trajectoire définie

La kinect étant les yeux de notre robot (les capteurs infrarouges servent eux à avoir une redondance d'information), c'est elle qui doit envoyer des consignes de déplacement à l'arduino.

L'idée est la suivante:

• La kinect envoie un octet au serveur, l'arduino interroge le serveur pour obtenir l'octet envoyé. Cet octet contient une consigne de vitesse ainsi qu'une consigne de direction

Détection/Esquive d'obstacles:

On conçoit un algorithme ayant pour objectif d'éviter les obstacles de façon douce et progressive. Plus l'obstacle est près et centré, plus la consigne de déviation sera importante.

Documents Rendus

Projet S8

Bilan de la soutenance du S7 :

De nombreuses inquiétudes envers la capacité du robot à rouler et les nouveaux contrôleurs moteurs achetés. Le groupe doit se recentrer sur l'aspect hardware du robot avant de s'aventurer sur les outils softwares, qui sont inutiles si le robot ne roule pas. Les choix entrepris doivent également être mieux justifier avec des motivations claires (par exemple le choix du matériau pour la boite, le choix d'utiliser des QR Codes au lieu de formes géométriques qui peuvent être plus simples ou encore notre choix concernant nos capteurs de distance qui fonctionnent en infrarouge). D'autre propositions ont été faites telle que rajouter un bumper (pare-choc) autour du robot en guise de sécurité.

Début du S8:

Le groupe se recentre donc sur l'objectif principal de faire rouler le robot. La Kinect est laissée en suspens pour permettre un avancement plus rapide de la partie hard. Cependant, la partie serveur web est maintenue, afin de ne pas accumuler trop de retard et pouvoir enchainer sur le programme Arduino pour le controle des moteurs dès que la partie cablage sera achevée.

Semaine 2 :

Partie Hard : Les nouveaux variateurs ont été reçu, on les tests alors. Plusieurs problèmes de compréhension de leurs fonctionnements, dus à une datasheet peu exhaustive. En outre, nous ne parvenons pas à réguler la tension de sortie des variateurs malgré l'envoi d'une pwm variable en entrée. De plus, les test en charge semblent de trop de courant pour les variateurs qui se mettent en défaut.

Partie Soft : Le serveur est relancé et nous modifions les différents envoies de données sur la console du serveur et sur la liaison série. nous avons décidé qu’un message typique envoyé par le serveur aurait la forme suivante X+255Y-500. Le X et Y majuscule servent à vérifier que le message reçu est bien le bon. Le + ou - servent à indiquer si la valeur X/Y est positive ou négative et lavaleur envoyée ira ensuite au maximum jusqu’à 500, trois caractères pour la valeur seront donc suffisant. Des premiers tests sont effectués et les valeurs reçues sur la console correspondent avec les valeurs envoyées du joystick sur le serveur.

Semaine 3 :

Partie Soft : La mise en forme du serveur n'a pas été une priorité puisque ce dernier ne nous sert au final qu'a utiliser un joystick. Pour tester nos envoies nous avons utilisé une carte Arduino MEGA afin de lire ce que nous envoyons sur la liaison série, celle ci est réglé sur une vitesse de communication égale à 115 200 bauds. Lorsque nous récupérons l'ensemble de nos caractères dans une variable char et que nous l'affichons directement, nous remarquons que des "?" sont envoyés lorsque nous bougeons rapidement le joystick. Pour palier à ce problème nous stockons ce qui est envoyé sur la liaison série dans un tableau contenant l'ensemble de la trame. Nous rappelons que cette trame est de la forme X+255Y-500. Les caractères "X" et "Y" nous permettent d'identifier qu'un nouveau message est reçu, si ce dernier est correctement reçu il est affiché. Lorsque nous bougeons le joystick trop rapidement des valeurs sont perdues mais il nous suffira de le manipuler en douceur.

Un mail est donc envoyé

Documents Rendus