Gérer la Maintenance et la Sécurité dans un bâtiment en réalité augmentée

  • Présentation du groupe

Bonjour à toutes et à tous !
Sur ce projet, nous sommes un groupe de 4 étudiants : Daniel, Paul, Tomas et Valentin. Nous avons choisi ce projet car nous avons directement aimé la fusion entre l’univers de la réalité augmentée et le bâtiment. De plus, nous sommes, certains plus que d’autres, intéressés par le secteur du bâtiment.

  • C’est bien beau tout ça, mais quel est le but de notre projet ?

L’objectif de notre projet est d’exploiter la réalité augmentée afin de faciliter l’évacuation d’un bâtiment en cas d’incendie. Pour ce faire, nous nous sommes fixés plusieurs objectifs :

  • Afficher le plan en 3D de Polytech Angers
  • Afficher, lorsque l’on scanne l’étiquette d’un extincteur, son utilisation
  • Afficher les extincteurs, lorsque l’on scanne le numéro de porte, sur le plan en 3D de l’étage sur lequel nous sommes
  • Afficher la sortie de secours la plus proche de la salle à laquelle nous nous trouvons tout en réalisant une simulation d’incendie
  • Afficher sur l’application le tracé du chemin vers la sortie de secours la plus proche

Afin de répondre a la problématique posée, nous avons décidé de créer une application sur smartphone basée sur la réalité augmentée et pour y parvenir nous avons utilisé un logiciel de modélisation : Unity.

  • Réflexion

Au départ, nous ne savions pas par où commencer étant donné que notre projet est assez large. Nous avons d’abord cherché à en savoir davantage sur le sujet en lisant différents documents sur le domaine du bâtiment, en regardant de nombreuses vidéos et notamment sur le fonctionnement du logiciel Unity : la prise en main, comment modéliser des structures en 3D, comment créer une application de réalité augmentée à partir de Unity. Nous avons eu également accès en parallèle aux documents sur la sécurité incendie et aux différents plans d’évacuations du bâtiment Polytech.

Ensuite, nous avons commencé à nous questionner sur comment allons nous adapter notre projet pour répondre a la problématique : gérer la maintenance et la sécurité incendie en réalité augmentée.

Dans un premier temps, l’idée qui nous est venue en tête était de développer une application pour smartphone à partir de Unity dans laquelle l’objectif serait de pouvoir afficher en réalité augmenté la composition intérieur des murs au niveau de la tuyauterie, les câbles électriques ou encore les systèmes de ventilations par exemple. Cependant, nous n’avons pas pu donner suite à cette première idée car faute de documentation : nous n’avions aucun document expliquant quoi que ce soit sur la composition des murs de Polytech.

Dans un second temps, nous avons également pensé à créer une application ( toujours à partir de Unity ) dans laquelle le but aurait été de créer un GPS qui nous indiquait notre position actuelle au sein du bâtiment de Polytech. Il nous afficherait également le chemin le plus court vers une sortie en évitant un potentiel départ d’incendie. Encore une fois, nous avons du laisser cette idée de côté car actuellement les géants tels que google, waze, etc… commencent petit à petit à développer ce type de GPS et sur internet, nous n’avons également rien trouvé de concret sur le type de GPS que nous voulions concevoir.

  • Une Idée convaincante

Finalement, nous avons trouvé une idée qui nous a convaincue, qui répondait à nos objectifs et à notre problématique. Nous avons décidé de développer une application (toujours à partir de Unity) qui ressemble un peu à la fusion de nos deux premières idées : l’objectif de notre application est dans un premier cas de pouvoir scanner avec son smartphone le numéro d’une salle qui par la suite affichera sur l’écran le chemin le plus court vers la sortie, et ce, en évitant un potentiel incendie.

Image
Image

Dans un deuxième cas, de pouvoir scanner un extincteur qui afficherait sur notre écran tout ce qu’il faut savoir à propos de cet outil, comme le manuel d’utilisation, les précautions à prendre ou encore dans quelle genre de situation il faut l’utiliser.

  • Réalisation du projet

La réalisation de notre projet final présenté ci-dessus, s’est faite en plusieurs étapes. Nous avons tout d’abord commencé par télécharger les plans des différents étages de Polytech. Ensuite nous avons ouverts ses fichiers sur Unity pour pouvoir ensuite partir sur la conception 3D de nos différents étages.

Désormais, à partir de nos plans nous avons donc commencé la modélisation 3D : le but était de partir de notre plan comme une base et il fallait créer des éléments 3D tels que des rectangles pour modéliser les murs et des cylindres pour modéliser les piliers.

Ensuite, il suffisait juste de créer notre élément en 3D et de le superposer à notre base. Une fois que nous avions fini de modéliser l’entièreté de notre base en 3D, nous nous sommes penchés sur la création de nos chemins de sortie. Nous avons décidé de les représenter sous forme de flèches rectangulaires.

Au cours de notre projet on ne s’est pas simplement limités à la conception 3D du bâtiment de Polytech, nous avons voulu aller plus loin en créant des animations tels que : le feu pour simuler un potentiel incendie et nous avons choisi de créer une petite animation de surbrillance pour nos chemins de sortie afin qu’il soient plus visibles :

En parallèle, nous avons exploité la réalité augmentée à partir de Unity grâce à un module nommé Vuforia. Nous avons commencé par prendre en photo les numéros de salles des différents étages que nous avons, puis, nous avons déposé en ligne sur le site de Vuforia. Par la suite il nous a fallu télécharger la base de données de ces images sur Unity. Ainsi, il suffisait d’associer les images de nos étages finaux modélisés en 3D à nos images prises antérieurement. Pour finir, afin de créer notre application il suffisait juste de “build” l’application à partir du module Vuforia sur Unity : c’est a dire que le logiciel Unity créé automatiquement notre application de réalité augmenté.

Pour conclure, une fois tout réalisé nous avons testé notre application sur les différents étages de Polytech. Nous obtenons ainsi les résultats suivants qui nous sembles très réussis :

  • Nos problèmes rencontrés

Notre premier problème rencontré, comme précisé précédemment à été le manque de documentation et d’information concernant la composition interne des murs en terme de tuyauterie et d’électricité et par conséquent nous avons du laisser de côté cette idée.

Au cours de notre projet, nous avons eu des difficultés avec le logiciel Unity. En effet, au démarrage, nous n’avions aucune connaissance sur le logiciel, c’est pourquoi nous nous sommes énormément informés sur le sujet par le visionnage de tutoriels sur internet ou encore en consultant des sites web spécialisés dans le domaine. Cependant, bien qu’on ait réussi à finaliser notre projet, la prise en main du logiciel à été relativement compliquée.

Nous avons également rencontré des problèmes avec nos fichiers, notamment sur le transfert de fichier entre Unity et le téléphone ou parfois même à gérer des fichiers dans Unity car le logiciel ne pouvait pas supporter des fichiers trop volumineux (principalement pour le module vuforia qui ne supporte pas des images de plus de 2 Mo). Par conséquent, il était parfois difficile voir même impossible de transférer des fichiers.

  • Bilan

Ce projet nous a permis d’apprendre énormément de chose : tout d’abord sur l’aspect purement technique on a appris à utiliser le logiciel de modélisation Unity, notamment sur la manipulation 3D : comme la modélisation du bâtiment de Polytech par exemple.

D’autres part, ce projet nous a involontairement obligé à nous intéresser davantage sur le domaine du bâtiment à propos de la maintenance, l’entretien et la sécurité : nous avons fait de nombreuses recherches, nous avons lu énormément de documents sur le sujet et nous avons aussi appris à lire des plans d’évacuation par exemple.

Finalement, notre projet qui reste technique sur la partie Unity et intuitif sur l’ensemble, nous à permis d’apprendre énormément sur le monde du bâtiment et l’informatique à travers la modélisation 3D.

Création d’un robot magicien

Bonjour et bienvenue à vous sur cet article.

Nous sommes Manon Boursicot et Anthonin Devas, deux étudiants de deuxième année à Polytech Angers et comme tous les deuxième année ici, nous devions travailler sur un projet durant une centaine d’heure pendant notre second semestre.

Nous avons choisi en tant que projet de travailler sur un robot, mais pas n’importe quel robot. En effet, notre projet est de créer un robot magicien. Ce robot pourrait servir à Polytech en tant que représentant des projets de deuxième année lors des forums ou portes ouvertes car c’est un projet que l’on peut montrer facilement. Ce projet a été inspiré par un robot existant créé par Mario the Maker Magician dont vous pouvez retrouver des vidéos sur YouTube, comme celle-ci par exemple : https://www.youtube.com/watch?v=WYQEZXXEfhc

Nous n’avons malheureusement pas réussi à terminer notre projet mais nous allons tout de même vous le présenter et vous en parler.

Maintenant, vous vous demandez peut-être ce que veut-dire un “robot magicien”. C’est tout simplement un robot capable de réaliser un tour de magie. Ce projet comprenait beaucoup d’étapes différentes. Pour réaliser ce robot, nous avons dû, tout d’abord, lui trouver un tour. Nous avions comme contrainte supplémentaire qu’il devait le réaliser plusieurs fois d’affilée sans intervention humaine. Une fois trouvé, nous avons dû créer le design, puis le modéliser en 3D avant de finalement l’imprimer grâce aux imprimantes 3D présentes dans l’établissement. Tout ça représente la partie mécanique, à côté de ça, il y avait la partie programmation où nous avons dû créer tous les mouvements que ferait le robot en language Python à l’aide d’une carte Raspberry Pi ainsi que faire fonctionner un écran. 

Le design

Pour le design, nous avions comme contrainte qu’il soit facilement transportable. C’est donc pour cela que nous avons décidé de faire un cube. Nous avons rajouté un bras pour qu’il soit capable de réaliser le tour.

Modèle 3D contenant le cube (en vert) et le bras (en rouge)

Nous voulions donner de la vie à notre robot et du plastique qui bouge ne suffirait pas. Nous avons donc ajouté un écran et créé des animations qui se jouerait pour que le tour soit plus expressif et par la même occasion, cela pourrait distraire une personne qui essaierait pour ne pas qu’elle voit les secrets du tour. Les animations de l’écran représentent le visage de notre robot, nous avons choisi, à deux, de créer un chat cyclope. C’est une image familière, un chat, mais avec une touche d’originalité qui saurait capter l’attention.  Ainsi, étant un Chat Cyclope en forme de Cube, trois mots commençant par C, nous l’avons appelé C³.

Le tour de magie

Vous savez à présent à quoi ressemble le robot, mais vous vous demandez peut-être ce qu’il doit faire. Nous avons cherché plusieurs tours sur internet et avons choisi de réaliser celui-ci (à 3:38 dans la vidéo): https://youtu.be/XqmcqWW_JRg?t=218

L’idée est basiquement, avec deux pièces et un verre, de faire semblant de faire passer une des pièces à travers le verre alors qu’en réalité on a fait tomber la deuxième dedans et caché la première.

Illustration du tour de magie

Pour faire faire ce tour à un robot il y a évidemment de nombreuses étapes à modifier car il ne sera jamais aussi agile qu’un humain. Il faut prendre en compte le fait que chaque axe dans lequel le robot devra faire un mouvement représente un moteur différent que nous devrons programmer plus tard. Il faut donc limiter les mouvements nécessaires au maximum.

Pour réaliser le tour nous avons un bras qui tient le verre et une pièce visible posée en dessous (image 1). Au moment où on démarre, le bras tapera le sol au niveau de la pièce, la cachant par la même occasion. La plateforme sur laquelle se trouve la pièce tournera alors, cachant celle-ci (image 2). Au même moment, le bras qui tient le verre fera tomber la deuxième pièce qui était cachée à l’intérieur depuis le début (image 3).

La modélisation et l’impression

Nous avons passé de nombreuses heures à modéliser le robot sur le logiciel SolidWorks. Chaque partie a dû être modélisée séparément en imaginant comment elle serait attachée aux autres autours d’elle. 

Nous étions des débutants complets pour tout ce qui concerne des problèmes mécaniques en termes de création, nous avons donc trouvé des inspirations dans ce que nous connaissons : des objets du quotidien. Nous pouvons citer notamment le bouchon d’une bouteille d’eau classique duquel nous nous sommes inspirés.

En tout nous avons 13 pièces complexes et différentes que nous avons entièrement imaginé et créé.

L’ensemble de nos pièces modélisées

C’est à partir de cette partie en réalité que nous avons commencé à avoir des problèmes. En effet, mis à part les difficultés de la modélisation en elle-même, il y a eu des difficultés d’impression. La partie principale, le gros cube que vous voyez sur la photo au-dessus, ne pouvait pas être imprimé car il demandait plus d’une bobine de plastique (presque trois), ce que l’imprimante ne peut pas faire. Sans ce cube, la majorité des pièces créées n’avait pas d’utilité et nous n’avons donc imprimé que les parties composants le bras et la plaque sur laquelle se fait le tour.

La programmation : Raspberry Pi, écran et moteurs

Cette partie est la dernière du projet et n’est donc pas terminée. Nous avons fait face à de nombreux problèmes que nous ne pouvions pas régler simplement ici.

Nous avons choisi pour le projet de travailler avec une carte Raspberry Pi. Pour ceux qui ne le savent pas, c’est, dans l’idée, un petit ordinateur qu’on peut programmer pour contrôler tout notre système.

Photo d’une Raspberry Pi 3

Après avoir mis un système d’exploitation sur la carte (un équivalent à Windows ou linux mais pour Raspberry), nous avons essayé de faire fonctionner l’écran. Nous pouvons l’allumer sans problème mais nous avons compris trop tard qu’il fallait une carte SD très précise pour faire fonctionner les animations dessus. Il fallait une carte de moins de 2GO, déjà très dure à trouver, mais aussi qu’elle soit compatible avec l’écran ce qui n’est pas le cas de toutes les cartes SD. Malgré que tout soit prêt, nous n’avons donc pas pu faire fonctionner l’écran.

Photo de l’écran

Nous avons programmé les moteurs en python, langage que nous avions déjà utilisé donc il n’y avait pas trop de problèmes. Nous avons trouvé un modèle de code sur internet pour faire fonctionner des moteurs en python avec une Raspberry et avons donc modifié celui-ci pour réussir à faire tourner les moteurs. <image moteurs/code>

Bilan

 Au final, notre projet n’est pas terminé mais nous avons quand même gagné des compétences utiles grâce à celui-ci, notamment en mécanique et électronique, où nous avons pu pratiquer les domaines comme on ne le fait pas normalement en cours. Nous sommes tout de même satisfaits par certains aspects, comme l’animation où, malgré certains problèmes, les modèles que nous avons pu produire. 

Même si nous sommes déçus du résultat, nous espérons que, si ce projet est repris l’année prochaine, il pourra être fini et perfectionner grâce à ce qu’on a pu faire cette année.

Nous vous remercions de votre lecture et espérons que vous avez trouvé notre projet intéressant.

Manon Boursicot et Anthonin Devas

Images utilisées dans cet article:

Moteur: https://www.robotshop.com/ca/fr/servomoteur-a-rotation-continu-parallax-futaba.html

Écran: https://4dsystems.com.au/products/4d-intelligent-hmi-display-modules/raspberry-pi-compatible-kits/gen4-ulcd-70dt-pi

Raspberry: https://www.desertcart.ae/products/59401529-raspberry-pi-3-model-b

Compteur binaire motorisé

Salut les polypotes !

    Nous sommes Maëlys DUBOIS et Thomas BLAIN, étudiants en deuxième année de cycle préparatoire intégré à Polytech Angers. Pour notre quatrième semestre, nous sommes amenés à mettre en œuvre un projet, de A à Z. Notre objectif est de concevoir puis construire une maquette de démonstration (salons, forum, etc.) d’un compteur binaire motorisé, que l’on pourra facilement déplacer. Nous avons choisi ce projet car il nécessite des compétences en mécanique/conception et en informatique/électronique, domaines sur lesquels nous sommes complémentaires.

I. Présentation du projet

    Le système est composé de 8 pièces double face sur lesquelles il est écrit 0 d’un côté et 1 de l’autre, les pièces sont suspendues à une tige et la première est reliée à un moteur pas à pas qui, quand il tourne, entraîne la première pièce, qui peut ensuite, selon si elle affiche 0 ou 1, entraîner la pièce suivante… Cette disposition permet d’afficher les 255 premiers nombres en binaire dans l’ordre.
    Le cahier des charges du projet était très ouvert ; il demandait uniquement de concevoir le compteur et de le faire fonctionner électroniquement. Nous étions totalement libres sur les options de fonctionnement, le nombre de bits, etc. Les contraintes comprenaient la facilité de transport (poids, taille) et la création d’options en électronique à partir de matériaux simples.

    Vous pouvez voir ci-dessous le principe du système :

    Valeur 0 en binaire

    Valeur 0 en binaire

    Valeur 1 en binaire

    Valeur 1 en binaire

    Valeur 2 en binaire

    Valeur 2 en binaire

    Notre compteur comporte de nombreuses pièces, dont une partie imprimée en 3D, d’autres sont en dibond (plaque plastique entourée de plaques d’aluminium), et d’autres sont en bois.
    Notre objectif avec ce système est de pouvoir retranscrire au grand public le principe du langage binaire, tout en pouvant manipuler un système facile d’utilisation.
    Le principe de base est que vous choisissiez un nombre quelconque pour que le compteur vous affiche son équivalent en binaire.
    Vous pouvez expérimenter 3 modes de fonctionnement différents et indépendants parmi les suivants :
    – Incrémenter un à un grâce à un bouton poussoir. (incrémenter = +1)
    – Incrémenter en continu grâce à un bouton poussoir.
    – Choix du nombre à afficher (entre 0 et 255) en sélectionnant le chiffre souhaité avec un encodeur rotatif (avec bouton) qui commande un afficheur.

II. Travail réalisé

    Nous pouvons distinguer deux parties concernant la mise en forme de notre projet tutoré. Il est composé d’une partie informatique / électronique ainsi que d’une partie mécanique / conception / impression 3D.
    Nous avons débuté notre projet par une phase de discussion sur la conception de notre compteur en général et ses caractéristiques. Nous avons fait un premier choix non définitif concernant les fonctionnalités disponibles et leur application, la taille, le nombre de plaquettes numérotées (soit le nombre de bits), le type de moteur et son mode de transmission, le type de carte de commande de notre compteur, etc.

    Nous nous sommes par la suite lancés dans le dimensionnement des pièces pour que l’ensemble puisse rentrer dans notre valise et dans les essais de composants électroniques dont nous pourrions avoir besoin.
    Après avoir dimensionné les pièces sur le logiciel FUSION 360, nous nous sommes rendu compte que certaines pièces ne pouvaient pas être imprimés en 3D, étant donné leur taille trop importante.

    Modélisation plaquette numérotée sur Fusion360.

    Modélisation plaquette numérotée sur Fusion360.

    La partie électronique du système est dirigée par une carte de commande Arduino UNO. Nous avons pu tester et configurer les fonctionnalités de comptage sur les afficheurs après avoir appris à utiliser le langage Arduino et son logiciel. Nous avons commencé à tester et programmer indépendamment chaque élément électronique dont nous pourrions avoir besoin pour ensuite commencer à les lier ensemble ou améliorer leur fonctionnement.

    Système électronique sous le fond de commande.

    Système électronique sous le fond de commande.

    Système électronique "partie commande".

    Système électronique “partie commande”.

    Nous sommes passés par des phases de recherche de composants que nous ne pouvons pas forcément concevoir en impression 3D.
    Nous avons recherché quel moteur pas à pas serait le plus à même de convenir à notre système, quelles rondelles utiliser pour séparer les plaquettes, quelles charnières utiliser pour basculer notre compteur, quel système poulie-courroie utiliser pour la transmission.

    Notre moteur "pas à pas" et son système de transmission "poulies-courroie".

    Notre moteur “pas à pas” et son système de transmission “poulies-courroie”.

    Étant donné que nous nous sommes rendu compte lorsque nous voulions faire l’impression 3D de nos fonds et de nos potences que ce n’était pas possible pour celles-ci, nous avons opté pour des plaques de dibond pour les fond ainsi que du bois pour les pieds servant à soutenir nos fonds et les blocs de maintien des potences

    Pour finir, nous avons enfin pu procéder à l’assemblage de notre compteur binaire et le relier à son système de commande.

III. problèmes rencontrés

    Concernant la partie mécanique, le premier problème apparu est le dimensionnement finalement peu pertinent autour d’une potence de maintien, afin d’accueillir notre servomoteur, pour que l’on se rende compte qu’un moteur pas à pas serait plus pertinent pour notre système. A la suite de cela, nous avons redimensionné et modifié la potence de maintien censée accueillir le servomoteur, pour l’accueil du moteur pas à pas choisi. Cependant, après discussion avec notre professeur encadrant, il est ressorti qu’il serait préférable d’inclure un système poulie-courroie pour la transmission de notre moteur au compteur. Le moteur ne doit donc plus se trouver sur l’axe de la tige de maintien des plaquettes, ce qui rend le dimensionnement d’un espace moteur dans la potence inutile.
    De plus, nous avons dû changer à quelques reprises les dimensions de nos pièces, mais cela provient plus d’une évolution de notre projet que d’un problème réel.

    Ensuite, nous avons voulu commencer l’impression test de nos pièces en 3D mais nous avons attendu 2 mois sans que cela ne puisse être possible. Les files d’attente étaient très longues et toutes les imprimantes 3D étaient HS. Jusqu’à la fin de notre projet, nous n’avons donc jamais pu imprimer nos pièces. De ce fait, nous avons dû chercher à contacter une connaissance possédant une imprimante 3D et qui pourrait nous aider pour la conception de nos pièces finales.

    Concernant la partie électronique, c’est notre manque de connaissance qui nous a causé le plus de tort. Nous sommes donc assez limités lorsque des problèmes surviennent. Lorsque les programmes ne fonctionnent pas comme nous l’attendions, cela peut nous prendre beaucoup de temps afin de résoudre le problème.
    Ensuite, nous avons eu quelques soucis avec le logiciel Arduino. Nous avions un problème de bibliothèque, qui ne fonctionnait pas sous linux. Il a donc fallu passer sous Windows, mais ça n’a pas fonctionné dès le début. C’est en passant sur le logiciel Arduino en ligne que notre programme a pu fonctionner normalement.
    Il a aussi fallu adapter, tout au long du projet, les options du compteur au fur et à mesure des essais des composants. Il y avait des composants auxquels nous n’avions pas pensé au préalable, d’autres qui étaient finalement trop compliqués à utiliser, etc.

IV. Conclusion

    Pour conclure, nous sommes plutôt satisfaits du résultat final par rapport à notre idée initiale du projet. Notre système fonctionne très bien dans les grandes lignes.
    Il arrive de temps en temps que les plaquettes poussantes ne tombent pas parfaitement à l’emplacement qui leur est dédiée et les potences de maintien ont un léger jeu avec les blocs de support, ce qui pose un léger problème de tension de notre courroie de transmission. Exceptés ces deux points, le compteur binaire est fonctionnel, même s’il pourrait être amélioré. Nous pourrions régler ces problèmes de potence et de pièces, ajouter un décompte sur le compteur ou encore améliorer l’esthétique du projet.
    La réalisation de ce projet a été pour nous très instructive. Ce dernier s’est reposé sur un travail coopératif où nous avons beaucoup appris. Nous avons fait face à différentes problématiques, que nous avons su résoudre.

    Voici donc le résultat de notre compteur binaire :

    Position "utilisation du système"

    Position “utilisation du système”

    Position "repos/transport"

    Position “repos/transport”

    Vous pouvez consulter notre compte rendu qui vous expliquera plus en détail le déroulé du projet ici :

    Merci de votre attention !

    Maëlys et Thomas, PeiP 2A, Polytech Angers

Développement d’un robot mobile pour la recherche en cartographie

Bonjour, nous sommes deux étudiants en deuxième année préparatoire intégrée de Polytech Angers. Nous avons décidé de nous lancer dans la conception d’un robot mobile de cartographie, enfin pour être plus précis dans l’élaboration de son châssis. Le but est d’avoir un robot qui puisse accueillir différents capteurs pour acquérir des données, pour par exemple avoir une représentation 3D de l’intérieur du bâtiment de Polytech Angers.

Un robot comme celui-ci dans le milieu professionnel peut avoir plusieurs utilisations. Par exemple, nous avons découvert dans nos recherches un robot aspirateur qui cartographie votre maison pour pouvoir mieux la connaitre et mieux l’aspirer. Vous imaginez donc qu’il y a d’autres utilisations possibles.

Il y a eu plusieurs étapes durant la réalisation de ce projet. On a dû d’abord préparer les bases.

Les schémas fonctionnels :
Nous avons eu un cahier des charges à respecter. Le robot devait faire une certaine taille, pouvoir accueillir un certain nombre de capteurs plus ou moins différents, etc.
Il a fallu faire des schémas fonctionnels, pour savoir comment aller communiquer les différentes parties du robot et aussi pour définir ces parties. On a donc eu accès aux fiches techniques des moteurs, de la carte mère et des capteurs pour pouvoir savoir comment tous ces éléments allaient communiquer.

Ici on voit comment les différents éléments communiquent entre eux

Ici on voit comment les différents éléments communiquent entre eux

Le dimensionnement de la batterie :
Après avoir réalisé ces schémas, on avait accès à pas mal d’informations techniques sur les différents éléments. On a donc pu dimensionner la batterie, c’est-à-dire savoir quel voltage et quelle intensité il fallait pour que le robot fonctionne pendant une durée déterminée. Pour cela, nous avons donc pris les informations techniques de chaque composant et fait un calcul.

Grâce à Excel on a pu rentrer différentes informations et avec des formules trouver les bonnes dimensions pour la batterie.

Grâce à Excel on a pu rentrer différentes informations et avec des formules trouver les bonnes dimensions pour la batterie.

Ici, on avait besoin de 30 minutes d’autonomie et l’on arrive à 5400 mAh, ce qui équivaut à environ deux fois la batterie d’un téléphone moyen. On arrivait aussi à un certain voltage et à une certaine tension, on a donc dû trouver des convertisseurs pour alimenter les différents composants du robot, car ils n’ont pas tous besoin de la même tension/courant.

La CAO :
La plus grosse partie du projet. On avait posé les bases, il fallait ensuite élaborer le corps de ce robot. On a donc utilisé un logiciel de CAO pour faire cela. On voulait faire un robot à plusieurs étages avec une petite tour tout en haut pour accueillir le capteur le plus important, le Lidar. On voulait faire un étage inférieur pour accueillir les moteurs, la batterie et la carte mère, puis un étage supérieur avec plusieurs emplacements pour pouvoir poser différents capteurs.

Le premier résultat que nous avions à montrer avec en bleu la petite tour surmontée du Lidar.

Le premier résultat que nous avions à montrer avec en bleu la petite tour surmontée du Lidar.

Après consultation avec nos professeurs, il y avait plusieurs défauts à corriger. Les deux gros points à corriger étaient l’emplacement des capteurs qu’on devait centraliser puis aussi l’originalité, car notre châssis n’apportait rien de spécial. On est donc reparti trouver des idées et après plusieurs essais, on a enfin trouvé une bonne solution pour corriger tous les défauts. On a donc décidé de changer la forme pour faire un robot avec une forme plus ovale, avec les deux roues motrices au centre, pour pouvoir avoir un réel centre pour placer les capteurs. Aussi, on a pris la décision de faire étage inférieur pour les moteurs et la batterie, puis un étage moyen pour la carte mère. Enfin, on a pensé à un troisième étage qui accueillerait un tour modulaire qui elle-même accueillerait les différents capteurs.

La nouvelle proposition du robot, avec en vert la carte mère, en marron foncé les différents étages à capteurs.

La nouvelle proposition du robot, avec en vert la carte mère, en marron foncé les différents étages à capteurs.

Le principe de cette tour, c’est d’avoir des étages qui s’emboitent facilement, sans vis et sans collage, pour pouvoir en enlever ou en rajouter à notre guise.

Ici on voit une vue éclatée des étages à capteurs avec en marron les troncs, et en violet les "terrasses" à capteurs.

Ici on voit une vue éclatée des étages à capteurs avec en marron les troncs, et en violet les “terrasses” à capteurs.

Ces différents étages auraient donc des trous où l’on pourrait emboîter n’importe quel capteur existant, il suffirait de créer un petit adaptateur à chaque fois.
Le capteur en gris a son adaptateur en bleu qui s'emboîte dans la "terrasse" à capteurs

Le capteur en gris a son adaptateur en bleu qui s’emboîte dans la “terrasse” à capteurs

Pour finir, on a fait un adaptateur pour le Lidar pour qu’ils puissent s’emboîter tout en haut de la tour, quel que soit le nombre d’étages. Aussi une petite astuce pour pouvoir faire passer les différents fils entre la carte mère et les capteurs a été de creuser des demi-cercles tout autour des troncs.

On voit ici en vue du dessus que même tout en haut de la tour on a accès à la carte mère en vert plusieurs étages plus bas.

On voit ici en vue du dessus que même tout en haut de la tour on a accès à la carte mère en vert plusieurs étages plus bas.

Conclusion :
Pour finir le robot, il aurait fallu avoir plus de temps pour réaliser les différentes pièces nécessaires. Le but était de réaliser un châssis qui puisse accueillir différents capteurs et l’on a pu au moins le concevoir en CAO. Le travail des prochaines équipes, s’il y en a, sera de le construire et de le faire rouler, pour acquérir différentes données. Grâce à ce projet, nous avons appris beaucoup sur la conception d’un robot, et toutes les contraintes mécaniques et électroniques que cela implique. La plus grande difficulté sera celle d’avoir eu besoin de se remettre à l’utilisation d’un logiciel de CAO, mais c’est revenu avec le temps. On aurait aimé pouvoir construire le robot et pouvoir toucher à la partie informatique/électronique plus en profondeur, mais cela sera pour une autre équipe d’étudiants.

Merci d’avoir lu notre article !

Par Antoine Verin et Macine Benmansour.

Virtual City

Matthieu MOREAU – Matthieu HIRON
Encadré par Paul RICHARD

Vue sur le parc

Vue sur le parc

Notre projet consistait à créer une ville virtuelle à l’aide d’un logiciel de jeu création de jeu : unity 3D. Le but était de créer un joueur suivant un parcours précis. Sur ce parcours, on trouve une ribambelle d’événements. Le joueur qui suit le parcours peut regarder où il veut à l’aide d’un casque de réalité virtuelle. A la fin du parcours, il doit se rappeler quels événements il a rencontré et leur ordre d’apparition. Cette activité est très utile pour les personnes atteintes de maladies entraînant une perte de mémoire aussi bien à court terme qu’à long terme. On pense notamment à la maladie d’Alzheimer par exemple.

On y trouve même un aéroport !

On y trouve même un aéroport !

La conception de notre projet s’est effectuée en 3 grandes phases :

DOCUMENTATION
Dans un premier temps, nous avons eu une longue phase de documentation et de recherche sur l’utilisation du logiciel Unity que nous ne connaissions pas du tout. Nous avons notamment regardé de nombreux tutoriels pour découvrir aussi bien le fonctionnement général du logiciel que certaines fonctionnalités plus spécifiques. Nous avons également fait quelques recherches au cours de la conception du projet lorsque que nous avions besoin de fonctions particulières pour la programmation en C#.

ETUDE
Une fois que nous avions les bases du logiciel, nous savions ce qui était réalisable avec ce dernier. Nous avons pu établir un plan de la ville que nous voulions créée. Ce plan a toutefois été adapté au fil de la conception puisqu’il était parfois difficilement applicable en réalité. Ensuite, nous avons cherché sur “l’Asset Store” d’Unity des packs de bâtiments, véhicules, personnages…

Représentation en couronnes de la ville que nous voulons créée

Représentation en couronnes de la ville que nous voulons créée

CONCEPTION
La phase de conception s’est déroulée en 2 partie : une partie création de la ville et une partie programmation afin d’animer les véhicules, le parcours du joueur, les évènements… Cette phase a été plutôt intuitive, même pour la programmation en C#. Une fois cette phase finie, nous avons donc un joueur qui suivait un parcours à travers la ville et qui pouvait observer tout autour de lui. Nous allons aborder un peu plus en détail l’aspect du développement.

Le centre ville

Le centre ville

La conception de la ville s’est effectuée grâce aux “assets” sur Unity. Certains sont gratuits mais plus la qualité augmente, plus les assets sont coûteux. Nous avons choisi de nous diriger vers des textures low-poly, des modèles 3d avec peu de polygones, car c’est plus simple à concevoir et assembler, ce qui nous facilite le travail étant donné que nos compétences étaient plutôt basiques au départ. Cela limite l’aspect réaliste du projet mais ce n’était pas un des objectifs premiers.
Nous sommes partis d’un modèle de ville que nous avons obtenu d’un Asset et nous l’avons modifié et avons ajouté certains aspects pour la rendre plus réaliste et plus compatibles avec nos idées.

Phase de développement sous Unity - On y voit les contours de la ville

Phase de développement sous Unity. On peut remarquer les montagnes installées autour

Pour finir, nous avons installé un “joueur” symbolisé par un point de vue fixé à un scooter. Nous avons choisi un scooter pour que le déplacement de notre joueur soit plus rapide et puisse ainsi découvrir plus de parties de notre ville. La programmation était plutôt intuitive et rapide à l’aide des différents scripts à notre disposition.

Illustration du sytème de noeud, la technique pour programmer les déplacements du scooter

Illustration du sytème de noeud, la technique pour programmer les déplacements du scooter

Une fois le trajet du joueur définit, il restait à positionner les différents évènements comme une cabine téléphonique qui sonne, un chien qui aboie, sur le chemin et déclencher le dit-événement au passage du joueur.
Par manque de temps, nous n’avons pas pu rendre notre jeu jouable au casque de réalité virtuelle. Il n’est jouable que sur pc mais nous avons pour objectif de continuer son développement afin de le rendre le plus efficace possible, le but ultime étant de pouvoir le tester avec des personnes malades.

Voici le trajet du joueur en bonne qualité :

Vous l’aurez compris, c’est un véritable “Serious Game” que nous avons eu l’occasion de développer. Remerciements à Monsieur Richard pour son aide précieuse qui nous a permis de réaliser ce projet.