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.

Projet GNSS

Introduction :

Bonjour, nous sommes Antoine Stourbe et Franck Gluszek, étudiants en deuxième année préparatoire intégrée de Polytech Angers. Dans le cadre de notre projet de conception nous avons décidé d’améliorer un robot photomètre afin qu’il puisse se déplacer et se localiser précisément en milieu extérieur, notamment un stade où son usage pourrait témoigner un intérêt réel dans le milieu des médias.

Intérêt du projet :

Beaucoup pourraient se demander à quoi pourrait servir un robot ayant pour but de mesurer la lumière de manière autonome. Ce qu’il faut savoir c’est que de nombreuses normes d’éclairages sont définies dans le monde du bâtiment et aujourd’hui il est bien plus simple de sur-éclairer plutôt que de prendre manuellement chaque mesures. C’est notamment le cas pour ne nombreux stades où il est nécessaire d’avoir une bonne couverture lumineuse afin de garantir une retransmission agréable aux téléspectateurs .

Les tests :

Afin de vérifier si le gps pourrait être installé sur le robot il faut savoir s’il est suffisamment précis et nous permettra de sortir une position du robot permettant en premier lieux de le déplacer en autonomie et puis de sortir une carte des mesures fiables. C’est là que moi et mon collègue intervenons, notre rôle se constituait de tester le gps pour savoir si oui il ferait l’affaire. Et pour cela nous avons effectué trois tests.

Le premier avait pour but de vérifier si le matériel fonctionnait bien. Pour cela nous avons simplement fait le tour de notre école pour savoir s’il pouvait situer notre position de manière correcte. Le résultat ayant été très concluant nous avons décidé de pousser les expérimentations.

Le premier tests :

premier test

premier test

En rouge nous avons notre position réel et en bleue celle donnée par le gps.

Le second test a été réalisé afin d’avoir une idée de la précision du gps. Pour cela nous nous sommes servis d’un parking afin d’avoir une référence précise entre une position x et celle donnée par le gps x’. Dans ce test nous avons fait 2 tours afin d’augmenter les données récoltées. Et malgré certaines mesures vraiment défaillantes le gps à su précisément retranscrire notre parcour. Seulement les points parasites étaient suffisants à eux-même pour dire que le gps n’était pas fiable. Nous avons donc émis l’hypothèse qu’en marquant une pause à chaques “étapes” nous pourrions éliminer ces coordonnées parasites.

Second test

Second test

C’est ici que notre troisième test rentre en jeux. Lui aussi avait été fait sur un parking et consistait en deux parcours, l’un des deux serait fait en mouvement constant et l’autre se verrait marqué de pauses de 10 secondes à l’aller puis de 5 au retour afin de voir si ce temps permettrait au gps de mieux se calibrer sur notre position.

Premier parcour du troisième test

Premier parcour du troisième test


Deuxième parcour du troisième test

Deuxième parcour du troisième test

Ici nous avons constaté que les données du second parcours étaient bien plus proches de notre trajet que le parcours initial. Seulement les coordonnées n’étaient clairement pas assez précise pour situer notre robot dans ne serait-ce que 250cm².

Problématiques rencontrées :

La principale problématique à laquelle nous avons dû faire face est celle de la programmation. En effet malgré les cours fournis durant notre année scolaire nous nous sommes sentis démunis face à cet aspect très présent de notre projet, cela est principalement dû à notre manque d’expérience certain. Malgré cela nous avons réussi à dépasser nos lacunes et mettre en places des programmes réalisés par nos soins, notamment un programme récupérant les trames données par le gps et les stockant dans un fichier texte afin de pouvoir avoir une trace constante des données récupérées.
Le second problème auquelle nous avons fait face fut celui de prendre en compte tout ce qui pouvait fausser les données récupérées par le gps. En effet les données fournies par le gps peuvent être faussées en fonction des conditions météorologiques, de dégagement nuageux, de la présence de corps métalliques ou imposants tel que des bâtiments. Tout autant de choses qu’il faut aussi prendre en compte dans un cas de situation réel, la taille des tribunes d’un stade pouvant par exemple grandement fausser les données reçues par le robot et par conséquent celles qu’il renvoies.

Conclusion :

Lors de ce projet nous avons pu apprendre en quoi consistent les tests permettant de vérifier si oui ou non un composant peut remplir une fonction donnée. Que cela demande une certaine rigueur et que par dessus tout il ne faut s’attendre à rien, juste se fier aux résultats. La plus grande difficulté à laquelle nous avons dû faire face est notre lacune en programmation, mais cette dernière nous à forcer à nous dépasser. Nous aurions apprécié pouvoir effectuer des tests sur le robot mais cela aurait été dans le cas ou les tests précédents se trouvaient être concluants.
Pour finir nous pouvons affirmer que le gps ne conviendrait pas à l’élaboration de ce robot et qu’il faudrait trouver une solution alternative à ce dernier.

Le matériel à disposition :

Le rover

Le rover

Le capteur gps

Le capteur gps

La carte arduino

La carte arduino

En vous remerciant pour votre attention !
Antoine Stourbe
Franck Gluszek

Ballon stratosphérique

Chers lecteurs,

Nous regrettons fort de devoir vous le dire, mais l’article suivant n’est pas des plus joyeux.

Il raconte la triste aventure de quatre étudiants en deuxième année de classe préparatoire à Polytech’Angers qui ont toutes les malchances et collectionnent les angoisses.

Dans cet unique article, ils vont affronter les standards de la DGAC, les regards d’une centaine d’élèves en classe de quatrième, un système GPS défaillant, et des interviews incessantes. Pour notre part, il est dans notre devoir de raconter ces funestes épisodes, mais rien ne vous interdit, chers lecteurs, de passer votre chemin et de cliquer sur un autre article.

Avec nos sentiments respectueux.

Rosanne Biotteau, Ersin Duman, Juliette Trahan, Emmy Teillet. 

Bonjour à tous !

Nous sommes quatre étudiants en EI2 et pour le semestre 4, nous avons décidé de travailler ensemble sur le projet d’un ballon stratosphérique.

L’enjeu de ce projet était d’envoyer un ballon gonflé à l’hélium dans la stratosphère, de filmer le voyage et de récolter certaines données telles que la température, la pression, l’altitude, l’humidité et la quantité de CO2. De plus, nous devions nous rendre auprès des classes de quatrième du collège Clément Janequin, à Avrillé, afin de leur expliquer notre travail et de leur donner envie d’étudier les sciences.

Notre ballon et de notre chaîne de vol lors du lancer

Notre ballon et de notre chaîne de vol lors du lancer

Ce projet est un projet complexe, qui nécessite des compétences dans de nombreux domaines. Avant de commencer à travailler dessus, nous ne savions notamment pas qu’il fallait demander des autorisations, parfois plus de trois mois avant le lancer. Voici les différentes autorisations que nous avons dû demander :

  • DGAC (Direction Générale de l’Aviation Civile) !! Vous ne pouvez pas envoyer un objet traversant les voies aériennes quand vous voulez, où vous voulez !!

  • L’autorisation du Maire d’Avrillé pour lui demander son accord pour lancer notre ballon depuis le Stade Delaune d’Avrillé

  • Autorisation d’occupation du domaine public avec l’accord de la DGAC et du Maire, auprès de la Police Municipale d’Avrillé.

Dans notre nacelle, nous avions décidé de mettre deux GoPro afin de filmer le vol de la nacelle, deux capteurs de température (intérieur/extérieur), un capteur dit Baromètre mesurant la pression, l’altitude, l’humidité, un capteur GPS pour enregistrer la trajectoire de notre matériel, et un capteur de CO2.

De plus, pour retrouver tout cela une fois retombé sur terre, nous avions placé un traceur GPS ainsi qu’un téléphone connecté à un compte Google. Tous deux devaient nous communiquer leur position.

Ici vous pouvez voir l'intérieur de notre nacelle, comprenant les systèmes GPS ainsi qu'Arduino et son alimentation

Ici vous pouvez voir l’intérieur de notre nacelle, comprenant les systèmes GPS ainsi qu’Arduino et son alimentation.

Nous avons fait un exposé le lundi 13 mai 2019 auprès des classes de quatrième du collège Clément Janequin d’Avrillé, afin de leur expliquer notre projet en sachant qu’ils allaient assister au lancement de notre ballon. Cet exercice était assez intéressant puisqu’il nous a permis de pouvoir nous exprimer devant des groupes d’une cinquantaine de personnes, de devoir apprendre à expliquer simplement des concepts pouvant être compliqués à comprendre pour un niveau de quatrième (la notion de forces par exemple).

La date du jeudi 6 juin 2019 pour le lancement était prévue depuis le début du projet. Après avoir installé tout notre matériel au stade Delaune, nous avons appelé les collégiens pour qu’ils assistent à ce moment mémorable. Tout s’est bien passé, et notre ballon a décollé bien plus rapidement que ce à quoi nous nous attendions.

Lundi 6 juin, Stade Delaune Nous étions en train d'installer tout le matériel nécessaire, ici en train de gonfler le ballon. Il fallait le maintenir avec un drap afin qu'il ne s'envole pas de suite.

Lundi 6 juin, Stade Delaune, Avrillé
Nous étions en train d’installer tout le matériel nécessaire, ici en train de gonfler le ballon. Il fallait le maintenir avec un drap afin qu’il ne s’envole pas de suite.

A l’aide d’une simulation réalisée sur Internet, nous savions que notre matériel devait se rendre dans la Mayenne, et atterrir aux alentours de Vaiges, mais plein de critères étaient pris en compte et la précision de cette simulation n’était pas optimale.

Itinéraire entre le Stade Delaune d'Avrillé et Vaiges

Itinéraire entre le Stade Delaune d’Avrillé et Vaiges

 

A la recherche de notre matériel, Vaiges

A la recherche de notre matériel, Vaiges

Lancer ce ballon présentait certains risques. :

  • Traverser des voies aériennes nécessitait l’autorisation de la DGAC !

  • Il faut également savoir qu’en prenant de l’altitude, les températures peuvent descendre jusqu’à -60°C, ce qui est mauvais pour les batteries ! Pour cela notre nacelle était fabriquée en polystyrène extrudé, recouverte d’une couverture de survie. De plus, nous avions mis des chaufferettes à l’intérieur.

  • La chute du matériel n’est pas contrôlée. La nacelle peut très bien retomber sur une route et causer un accident, tomber dans l’eau, ou pire… en zone blanche, tout en sachant que nos deux systèmes GPS requièrent du réseau mobile afin de nous envoyer leur position. Le téléphone nécessite également des données mobiles afin de communiquer sa position sur une carte.

Malheureusement, 24 heures après le décollage… toujours aucune nouvelle…

C’est alors que commence notre longue et triste histoire… Sans nouvelle de notre nacelle, nous avons commencé par contacter les journaux. Quelques jours plus tard, nous retrouvions déjà notre avis de recherche sur plusieurs journaux (ici Ouest France) et même à la radio (ici Hit West) ! (une petite erreur de prénom, mais on n’a pas tout ce qu’on veut dans la vie…)

C’est alors que les témoignages fusent, mais aucun ne correspond à notre matériel…

C’est dans l’attente d’un signe de vie de notre nacelle  que nous vous quittons.

Nous vous avions prévenu, bien que nous ayons acquis de nombreuses compétences, cette histoire n’est pas des plus joyeuses.