Version du 1 avril 2020 à 16:33 (voir la source) Vsalingu (discussion | contributions) (→‎Semaine 10 : 01/04) ← Modification précédente		Version du 1 avril 2020 à 16:38 (voir la source) Vsalingu (discussion | contributions) (→‎Semaine 10 : 01/04) Modification suivante →
Ligne 737 :		Ligne 737 :
	Cela correspond au pré-traitement du réseau de neurones. Pour traiter ces données, nous pouvons utiliser Tensorflow et Google Colab.		Cela correspond au pré-traitement du réseau de neurones. Pour traiter ces données, nous pouvons utiliser Tensorflow et Google Colab.
	Une fois l'architecture globales des algorithmes, il nous suffira de remplacer nos données par un circuit à Polytech.		Une fois l'architecture globales des algorithmes, il nous suffira de remplacer nos données par un circuit à Polytech.
		+
		+	TensorFlow est une librairie entièrement programmée en Python qui fournit une API pour les utilisateurs qui souhaiteraient utiliser des techniques de machine learning. Il s'agit en réalité d'un ensemble de fonctions mathématiques et de méthodes de calcul qui permettent de développer des fonctions d'apprentissage par la machine à adapter à chaque cas de figure.
	''' Interaction Homme-Machine '''		''' Interaction Homme-Machine '''

---

Version du 1 avril 2020 à 16:38

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

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.

Points forts	Points faibles
Reconnaissance vocale Reconnaissance faciale Liberté/Fluidité de mouvement Perception du regard Ecran tactile Caméra 2D/3D pour la navigation Dialogue en 15 langues	Lenteur Sensible au bruit Petite taille Ecran peu lisible

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

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.

Points forts	Points faibles
Taille d'un adulte Grand écran tactile HD 19" Interface ergonomique Autonomie de 8h et recharge intelligente rapide (3h)	Lenteur Pas d'assistance vocale Pas d'interaction autonome avec l'utilisateur

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

Analyse du troisième concurrent : Keylo

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.

Points forts	Points faibles
Grand écran tactile Interface ergonomique Vidéoconférence enregistrée Longue autonomie Distributeur d'objet	Très imposant Lenteur Pas d'assistance vocale Pas d'interaction autonome avec l'utilisateur

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")

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.

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 :

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'autres 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.
Pour mieux gérer notre organisation ce semestre nous choisissons de tout de suite réaliser un diagramme de Gantt.

Semaine 2 :

Partie Hard : Les nouveaux variateurs ont été reçu, on les testes 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 envois 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+xxxY-yyy.
Le X et Y en 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 la valeur envoyée ira ensuite au maximum jusqu’à 500, trois caractères pour la valeur seront donc suffisants (représentée par "xxx" et "yyy").
Des premiers tests sont effectués et les valeurs reçues sur la console du PC correspondent avec les valeurs envoyées du joystick sur le serveur.
La prochaine étape est la vérification de ces envois sur le port série.

Semaine 3 :

Partie Hard :

La caractérisation des moteurs nous ont permis de constater que nous ne pourrons malheureusement pas utiliser les nouveaux contrôleurs moteurs.
Pour ne pas perdre de temps nous choisissons de réutiliser les anciens, nous avons un peu de mal à les allumer car ils sont capricieux.

Partie Soft :

La mise en forme du serveur n'a pas été une priorité puisque ce dernier ne nous sert au final qu'à utiliser un joystick virtuel. Un codage plus propre sera mis en oeuvre dès que ce dernier sera totalement fonctionnel et répondra à nos attentes.
Pour tester nos envois nous avons utilisé une carte Arduino MEGA afin de lire ce que nous envoyons sur la liaison série.
Celle-ci est réglée 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 pallier à 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, c'est à dire de la forme attendue, il est affiché.
Lorsque nous bougeons le joystick trop rapidement des valeurs sont perdues car mal reçue mais il nous suffira de manipuler le joystick en douceur pour recevoir l'ensemble des valeurs.

Nous avons pris du retard sur la partie de gestion des moteurs à cause de notre erreur dans les commandes.

Semaine 4 :

Partie Hard : Fichier:Centaure parois V1.svg
Nous recommençons l'entièreté du châssis du robot pour nous permettre de déplacer les différents éléments qui le compose.
Comme expliqué lors de la soutenance, nous déplaçons principalement les éléments de l'étage du bas. Nous déplaçons le bouton de démarrage et le bouton d'arrêt d'urgence à ce qui est désormais l'avant du robot.
En effet, nous avons aussi pris la décision de placer la roue folle à l'arrière du robot.
Nous rendons l'accès aux fusibles plus facile en le mettant à côté de la porte.
Pour découper ces plaques, nous nous rendons au Fablab de Centrale.
En effet, la découpeuse laser du Fabricarium était indisponible car ils n'avaient plus de lentille.
Clément étant Fabmanager au Fabricarium, nous avons eu l'autorisation d'aller utiliser la découpeuse laser de Centrale.

Plans SVG des plaques intérieures :

Plans SVG des parois extérieurs :

Nous avons réussie à démarrer les anciens variateurs des moteurs avec ce schéma de câblage :

Pour démarrer les controleurs moteurs, il faut :

- 24V sur la pin 1 (clé d'anti-démarrage) 

- Rien sur les pins 3,4,8 

- Une résistance d'au moins 5kohms entre les pins 5 et 7 

- Une tension d'au moins 130mV(à vérifier) sur la pin 6 

Pour ce faire nous avons donc branché une résistance de 10kohms entre les pins 5 et 7. Nous envoyons la tension de 130mV grâce à des DAC. Et nous redirigeons la tension de sortie de la pin 2 vers une carte de relais, celle-ci nous permet de choisir le sens de rotation des moteurs en activant l'un ou l'autre des relais. Le contrôleurs moteurs est équipé de sécurité au cas ou les deux seraient activés en même temps.

Partie Soft :

Le format de nos trames et les valeurs envoyées par notre joystick sont modifiés.
En effet, envoyer un octet pour chaque valeur de consigne X et Y au lieu de 10 caractère ASCII (ce qui constitue une trame de 10 octets) nous parait être une bien meilleure solution, moins volumineuse et plus rapide d’envoi mais également plus simple pour le traitement sur l’Arduino MEGA.
Ce problème nous a d'ailleurs été souligné dans les commentaires au milieu du semestre.
Pour ne pas avoir de problème avec le signe des valeurs X et Y, les valeurs de ces derniers varieront entre 0 et 127 (afin d’utiliser 7 bits sur les 8 bits qui constitue l’octet), la position au repos du joystick sera X = 63 et Y = 63.
La distinction entre X et Y se fera à l’aide du bit de poids fort.
Un octet représentant la valeur de X sera la forme 1xxx xxxx et un octet pour la valeur de Y sera de la forme 0yyy yyyy.
Ces trames envoyées sur la liaison série seront également de la même forme pour la partie Kinect ce qui permettra de mettre en place une duplication de code sur l’Arduino MEGA pour le traitement.

Semaine 5 :

Partie Hard

Nous commençons le câblage du robot.
Toutes les pièces ont été découpées et s'assemblent.
Nous commençons par tirer des morceaux de ruban pour simuler les câbles.
De cette manière, nous pouvons estimer à moindre coût l'encombrement général des câbles, leurs longueurs, leurs agencements les uns vis-à-vis des autres. L'intérêt est de limiter la coupe de câbles trop court.

Nous pouvons ensuite passer au câblage réel de l'étage de puissance, remarque importante : la convention de couleur des câbles est inversée (Noir pour le + et Bleu pour le -). Le respect des couleurs a été impossible, en effet, les câbles de puissance des batteries étant de grosse section et étant donné l'absence de matériel pour resertir ces câbles, nous avions pas d'autres choix que ceux déjà sertis. Leurs longueurs nous imposé de les utiliser en inversant la convention des couleurs.
L'emploi de goulottes nous permet de une meilleure organisation de l'étage.

L'ajout d'étiquettes sur les câbles nous permet un repérage plus simple, et donc un montage ou démontage facilité.

Les remarques vis-à-vis d'un deuxième bouton d'Arrêt d'Urgence et de longueur de câbles suffisamment grande pour permettre le retrait de l'étage de commande, ont été prise en compte.

Partie Soft

Les différentes parties Soft se finalisent, les derniers tests sont effectués afin de valider la partie Serveur et la partie Kinect. Une hiérarchie de priorité est également mise en place dans le code de l'Arduino MEGA. En effet, pour le contrôle du robot 2 modes sont mis en place :

- Un mode automatique : Géré par la Kinect. 

- Deux modes manuel : Géré par le joystick physique et le joystick virtuel.

Ces différents modes de contrôle peuvent changer au cours du fonctionnement du robot, pour autant si plusieurs modes de contrôle essayent de contrôler le robot au même instant il semble évident que l'un d'entre eux doit être prioritaire et devenir bloquant pour les autres.

• Priorité 1 : (Maximale) La priorité la plus élevée est celle des capteurs situés autour du robot. Ces derniers sont constamment vérifiés peut importe le mode de contrôle du robot afin d'éviter toute collision.
  
• Priorité 2 : La deuxième priorité la plus élevé est celle du contrôle du robot grâce au joystick physique connecté à l'Arduino via un port RJ11.
  
• Priorité 3 : Le troisième et avant dernière priorité est celle du contrôle grâce au joystick virtuel mis en place sur le Serveur Web en NodeJS.
  
• Priorité 4 : (Minimale) La priorité la plus faible est celle qui est constituée de la partie Kinect ce qui correspond au fonctionnement du robot en mode autonome.
  

Bilan de mi-semestre

En ce milieu de semestre, nous effectuons un bilan avec les encadrants sur l'avancement du projet. Le robot a maintenant de nouvelles parois. Nous avons fait le choix d'encocher la plaque du milieu pour éviter que l'étage supérieur ne repose sur les batteries. Cela soulève des inquiétudes concernant la maintenance du robot. Il est vrai que nous n'avions pas pris en compte dans notre cahier des charges le fait que le robot soit facilement démontable pour des éventuelles modifications. Il faudrait donc que la plaque du milieu soit facilement démontable. En fait, nous pouvons la retirer facilement. Il suffit pour cela:

• D'enlever le profilé supérieur du côté
• Desserrer les deux profilés du côté

Cela permet d'enlever la plaque. Cependant, de nombreux câbles relient l'étage supérieur à l'étage intérieur. Il faudrait donc débrancher tous ces câbles si l'on veut réellement intervenir sur l'étage inférieur. Cependant, nous réfléchissons à une solution pour effectuer de petites modifications sans devoir tout débrancher. Pour cela, nous réarrangeons le câblage. En effet, nous gardons un peu de marge au niveau des câbles de l'étage supérieur pour pouvoir déboîter la plaque du milieu et accéder à l'étage inférieur en gardant l'étage supérieur câblé.

Nous avons aussi eu des inquiétudes concernant l'emplacement du bouton d'arrêt d'urgence qui avait été au préalable balidé par Mr Redon. Nous allons donc modifier notre câblage pour permettre d'ajouter un bouton d'arrêt d'urgence qui sera placé sur le dessus du robot.

Concernant la partie soft :

Semaine 6: (04/03)

Partie Hard

Voici l'état actuel du robot :

• Toute la partie alimentation est câblée
  
• Les variateurs sont alimentés mais il nous manque les connecteurs MOLEX pour les contrôler. Nous réalisons un branchement temporaire pour nous permettre de tester la partie soft
  

• Le PC ne semble pas s'allumer malgré l'alimentation 12V
  
• L'écran ne reste pas allumé. Il est bien alimenté en 13V à la sortie du convertisseur, puis sa tension chute à 8V. Puis, lorsque l'écran est éteint, la tension de sortie du convertisseur repasse à 13V.

Nous avons aussi replacé le mat avec l'écran et la kinect.

Nous avons inversé le sens du mat, et donc le sens de marche du robot pour deux raisons :

• Permettre d'avoir une distance minimale entre les personnes et la kinect pour empêcher tout problème de détection si la personne se trouvait trop près du robot
  
• Améliorer le déplacement du robot en mettant la roue folle à l'arrière et non plus à l'avant
  

Enfin, voici la nouvelle disposition des boutons :

Ils sont tous présents à l'avant du robot, avec le coupe batteries, le bouton de démarrage et le bouton d'arrêt d'urgence. Comme discuté avec les encadrants, nous avons rajouté deux câbles avec un domino pour permettre l'ajout d'un autre bouton d'arrêt d'urgence, lui placé sur le dessus du robot.

En parallèle, réalisation d'un livret explicatif du câblage et du fonctionnement du robot. Réalisation sur Onshape des nouveaux supports pour les 6 capteurs que l'on peut voir ci-dessous :

Partie Soft

Nous testons donc la partie soft avec le câblage temporaire. Lorsque le serveur envoie l'ordre d'aller vers l'avant, les deux moteurs tournent bien dans le même sens. Cependant, lorsqu'on lui demande d'aller vers l'arrière, nous avons qu'une seule roue qui tourne. Nous remarquons que sur les relais, une des Leds ne s'allume pas. Nous avons donc plusieurs hypothèses pour ce problème :

• Problème au niveau du code
• Problème au niveau du shield
• Problème au niveau de l'arduino

Nous enlevons le shield pour tester l'arduino et le code. On réalise un code pour envoyer 5V sur la pin 47, qui correspond à la pin du moteur gauche pour aller en marche arrière. On reçoit bien 5V sur cette pin. Le problème ne vient pas de l'arduino. Nous testons donc le code. Nous recevons bien des données. Le problème viendrait donc du shield. On vérifie d'abord que sur le shield, le bornier est bien reliée à la pin qui s'enfiche dans la pin 47 de l'arduino. Il n'y a pas de problème de ce niveau là. En regardant le shield, on remarque que les soudures sont assez grosses et pourraient empêcher le shield de bien s'emboîter dans l'arduino. En nettoyant les soudures, on rebranche tout. Nous recevons bien les 5V sur le bornier, il s'agissait donc uniquement d'un faux contact. Nous avons encore des modifications à réaliser sur le code pour gérer les cas spécifiques.

Semaine 7: (11/03)

Partie Hard

Finalisation du câblage :

Après réception des connecteurs Molex, nous avons, avec l'aide de Thierry, confectionner des câbles permettant de relier les variateurs de vitesse au shield arduino de façon propre.

Voici le câblage :

De plus, le câblage entre les commutateurs et le shield a également était revu. Il est maintenant composé de câble de longueur adapté, maintenus par des borniers. Nous finissons d'imprimer les capteurs :

Intégration des capteurs :

Nous quittons donc le robot pour une période indéterminée.

Partie Soft

Le code Arduino a été revu afin d'offrir une meilleure mobilité au robot. La stratégie est la suivante :

Une vitesse initiale identique est attribuée aux deux moteurs en fonctions de l'axe y lorsque le robot est contrôlé par le joystick. Cette vitesse est ensuite modifiée en fonction de l'axe x, en tournant à gauche, on va ainsi ralentir le moteur gauche et accélérer le moteur droit

vit_motD = val_y + ((63 - val_x)/2);
vit_motG = val_y + ((val_x- 63)/2);
Pour rappel, la position (63;63) correspond à la position centrale du joystick

Lors du déplacement en autonomie le calcul est le même, la Kinect envoie alors une valeur 'val_y' en liens avec la distance de l'obstacle le plus proche et une 'val_x' en lien avec la localisation de l'obstacle (à gauche ou à droite du robot) Les fonctions qui calculent val_y et val_x sont linéaires, ce qui permet un évitement progressif des différents obstacles.

Bilan du projet avant le début du confinement La réorganisation de l'intérieur du robot a été entièrement réalisé. Les moteurs sont contrôlés grâce aux variateurs. Le robot est entièrement ré-assemblé et il ne manque qu'a relier les capteurs pour finir le câblage. Nous arrivons à le faire rouler grâce a un joystick virtuel et le PCB du joystick physique et en cours de validation. Le serveur et la kinect sont synchronisés grâce a la gestion de priorité. Le contrôle du robot grâce a la kinect n'a pas encore pu être testé mais le programme est fonctionnel seul des ajustements de variable seront à effectuer.

Semaine 8: (18/03)

Pour palier notre absence due au confinement, nous avons de nouveaux axes à traiter qui se concentrent sur la partie soft du robot. Avant de partir, toute la partie câblage été finié, à l'exception des capteurs qu'il faut encore brancher à l'arduino. Le code prenait déjà en compte les capteurs et nous ferons les tests quand nous aurons accès au robot. Nous nous concentrons donc sur 2 axes :

• OpenCV : Suivre une piste au sol en détectant les murs et les escaliers. Ceci est une solution à court terme pour le robot. (Pierre et Samuel)
• Interaction Homme-Machine : Créer un visage pour le robot, proposer des services aux utilisateurs (Loïc et Théo)
• Intelligence artificielle : Réaliser un réseau de neurones (apprentissage de circuit) permettant de donner la direction au robot. Ceci est la solution sur le long terme. (Valériane et Clément)

Deux pistes principales pour l'IA sont : https://atsushisakai.github.io/PythonRobotics/ https://blog.floydhub.com/teaching-my-robot-with-tensorflow/  : pytorch / tensorflow qui est du deep learning

Semaine 9: 25/03

Point Kinect :

Nous sommes capable, avec la Kinect, de récupérer le flux vidéo et d'en extraire des informations tels que l'abscisse, l'ordonnée et la profondeur d'un point dans l'espace.

L'enjeu est donc, à partir de ce flux vidéo, de déduire une consigne de direction à transmettre à l'Arduino, à savoir une consigne de la forme {val_y ; val_x}

Pour se faire, à chaque nouvelle image fournie par le capteur, on scanne chaque pixel pour localiser le pixel le plus proche. Celui-ci est donc considérer comme l'obstacle le plus urgent à éviter :

• La distance de ce pixel est utilisée pour établir une 'val_y' entre 0 et 127. Plus l'obstacle est proche, plus la valeur se rapproche de 0.
• L'abscisse de ce pixel est utilisée pour déterminer une 'val_x' entre 0 et 127. La consigne 'val_x' s'adapte afin d'éviter de façon progressive les obstacles, plus celui-ci est centrée par rapport au robot, plus la consigne de changement de direction sera importante.

Problème : Un des problèmes rencontré fut les ombres. En effet le capteur infrarouge de la Kinect est sensible aux infrarouges et s'avère très peu fiable dans des environnements fort lumineux (près d'une fenêtre par exemple). Le capteur retourne donc, pour tous les pixels sur-exposés, une distance par défaut de 2 mètres) ce comportement est dangereux car il peut amener le robot à percuter un obstacle en pleine lumière.

Solution : On implémente donc un algorithme de gestion des ombres, on se sert des pixels adjacents aux ombres dans le but d'attribuer une valeur arbitraire de profondeur à chaque pixel, qui correspond à son environnement proche (cf image) :

Intelligence artificielle

Nous faisons des recherches pour nous former au développement d'un réseau de neurones, pour pouvoir, sur le long terme, avoir un robot autonomequi arrive à conduire des personnes à différents endroits de Polytech. De nos premières recherches, nous avons différents outils pour réaliser ce réseau de neurones :

• Pytorch
• Tensorflow
• Mathlab

Les deux premiers utilisent Python alors que le dernier utilise C++. Nous étudions ces différentes possibilités car nous avions remarqué que le PC du Centaure ralentissait significativement lorsqu'on lui a demandé de faire du traitement d'image avec Python. En utilisant OpenCV, nous n'avons plus ce problème de ralentissement. Aussi, nous ne sommes pas sûrs d'avoir accès à toutes les fonctionnalités de Mathlab avec la version gratuite mise à disposition pendant le confinement.

Voici les grandes étapes à suivre pour réaliser un réseau de neurones :

• 1. Accès et préparation de nos données
• 2. Création du réseau de neurones
• 3. Configuration des entrées et sorties du réseau
• 4. Réglage des paramètres du réseau (poids et biais) afin d'optimiser les performances
• 5. Apprentissage du réseau
• 6. Validation des résultats du réseau
• 7. Intégration du réseau dans notre système

Semaine 10 : 01/04

Intelligence artificielle

Nous nous renseignons sur l'algorithme de Dijkstra. Cet algorithme permet de trouver le chemin le plus court pour aller d'un point A à un point B. Pour pouvoir l'utiliser dans l'enceinte de Polytech, il faudrait au préalable remplir un tableau avec toutes les destinations possibles depuis le hall.

Un autre algorithme, qui se base sur celui de Dijkstra, est l'algorithme A*. Il a été utilisé sur le premier robot capable de raisonner sur ses actions, le robot Shakey.

Cet algorithme utilise une méthode heuristique pour déterminer le meilleur chemin, à partir de nœud. Il ne nécessite pas de prétraitement et consomme peu de mémoire. Cela pourrait donc nous permettre de ne pas avoir de ralentissement en utilisant cet algorithme sur le Centaure.

Après discussion, nous nous recentrons vers l'utilisation du deep learning pour l'apprentissage de circuits.

N'ayant pas accès à Polytech, nous ferons d'abord des tests chez nous. Voici la méthode que nous devons suivre pour réaliser un réseau de neurones capable de se déplacer de manière autonome sur un circuit qu'il a appris :

• Faire circuler le robot d'un point A à un point B en prenant de nombreuses captures d'images
• Utiliser un algorithme d'augmentation des données (ombre, luminosité..) pour travailler les images avant de les labelliser

Cela correspond au pré-traitement du réseau de neurones. Pour traiter ces données, nous pouvons utiliser Tensorflow et Google Colab. Une fois l'architecture globales des algorithmes, il nous suffira de remplacer nos données par un circuit à Polytech.

TensorFlow est une librairie entièrement programmée en Python qui fournit une API pour les utilisateurs qui souhaiteraient utiliser des techniques de machine learning. Il s'agit en réalité d'un ensemble de fonctions mathématiques et de méthodes de calcul qui permettent de développer des fonctions d'apprentissage par la machine à adapter à chaque cas de figure.

Interaction Homme-Machine

Il est maintenant temps de mettre à profit l'écran mis à disposition sur le véhicule. Celui-ci doit remplir les missions suivantes :

• Etre clair
• Susciter l'intérêt des passants
• Etre acceptable esthetiquement

Par l'intermédiaire de cet affichage, les personnnes de passages devraient être capables de communiquer rapidement avec le robot. On s'attèle donc à lui donner un visage qui sera afficher lors des déplacements du robot et lorsqu'il communique avec des utilisateurs.

Plusieurs designs furent proposés et testés, pour finalement s'orienter vers un visage sobre et épuré (et bien moins terrifiant):

Concrêtement, l'interface visible à l'écran est gérée par un fichier source multithreadé "display.c" et fait appel à la libSDL (utilisée pour la création d'applications multimédias). On décompose le visage en différentes sous images :

• oeil
• iris
• bouche

De cette manière il est possible d'animer notre personnage à l'écran. Une fonction est dédiée au mouvement des yeux et est lancée au sein d'un thread (l'utilisation des threads est d’ailleurs encapsulée dans une bibliothèque libthread). De plus, le programme communique en IPC avec le programme de détection faciale, ainsi, lorsque qu'aucun visage n'est détecté par le robot, les yeux présentent un mouvement aléatoire, à l'inverse, lorsqu'un visage est détecté, ses coordonnées sont transmises et le robot suit la personne du regard.

On note cependant la lenteur du traitement des images en C++ à l'aide d'openCV. En étant le plus minimaliste possible le programme traite péniblement 1 image par seconde sur un PC récent...Difficile alors de savoir si le programme sera supporté par le PC embarqué du robot.

L'utilisation de threads a pour but final de pouvoir mouvoir indépendamment différentes parties du visage et de pouvoir par exemple lancer des fichiers sonores en parallèle de l'animation du visage.

L'ensemble du code de l'interface et disponible sur ce dépot git : https://archives.plil.fr/lringot/Centaure_IHM.git

Documents Rendus