Création d’un mur de lumières pour Escape Polytech

Bonjour à toutes et à tous ! Nous sommes trois étudiants de 2ème année actuellement en fin de cycle préparatoire de Polytech Angers et nous allons vous présenter notre projet réalisé plus tôt dans l’année : Le Mur-Lumières.


CAO

Rendu 3D de notre mur lumière

Nous avons utilisé des outils de CAO pour perfectionné le design de l’ensemble et éviter les erreurs de conceptions.

Programmmation

Une petit partie du code de notre projet

Un script python permet de contrôler le comportement de l’ensemble des élements.

Assemblage

Assemblage de la machine

Pour concrétiser le projet nous avons réalisé la fabrication de tout le bâti et le câblage nécessaire au bon fonctionnement.


Introduction de notre projet :

Vue générale du Mur Lumières

Ce projet fait partie d’un lot de projets associés à l’escape Polytech, un escape-game réalisé par les enseignants chercheurs de Polytech qui ont décidés de demander de l’aide aux étudiants pour créer des mini-jeux futurs. Le nôtre consiste à reproduire une forme sur un écran d’ampoules Philips HUE 5×5 à l’aide de boutons qui pilotent les ampoules : à vous de trouver la bonne combinaison !

Création du bâti :

Dans notre projet, il nous a fallu créer un bâti pour pouvoir stocker tous les autres composants et déplacer le tout facilement. Ainsi, l’utilisation de SolidWorks nous a paru nécessaire pour créer ce que nous avons choisi de faire : une borne d’arcade. Cette partie du projet n’a pas été la plus longue du fait que le bâti était plutôt simple à réaliser.
Cette CAO a ensuite permis la découpe puis l’assemblage des pièces dans du bois acheté chez un de nos fournisseurs.

Création du programme gérant les Ampoules Philips :

Pour contrôler les ampoules connectées, nous avons utiliser un pont Philips Hue se connecte aux ampoules avec le protocole ZigBee. Aussi, les 16 boutons que nous avons utiliser requièrent une carte PacLed 64 pour changer leurs couleurs simplement. Pour faire fonctionné tout les composants électronique ensemble nous avons utiliser un script python sur un Raspberry Pi 4. Ce programme permet de contrôler le clavier à l’aide d’un Arduino Uno, l’écran LCD, le pont, les boutons de couleurs avec la PacLed. Le code est pensé pour être le plus modulable et évolutif possible. Nous avons fait attention à ce que le code permette une grande résilience face aux éventuels petites interférences et perturbations qui pourrait survenir à cause de l’utilisation de fils non isolé pour transmettre de l’information entre les composants.

Assemblage et Tests réalisés à Polytech :

Une fois toute la partie programmation terminée, nous avons pu amener les planches découpées à Polytech pour y faire l’assemblage. Par la suite, nous nous sommes occupés de la longue partie concernant le branchement des multiples câbles (électriques et électroniques) avant de relier les cartes Arduino et Raspberry à nos autres composants.
Malgré quelques heures de complications à performer le code pour satisfaire toutes les conditions souhaitées, nous sommes arrivés à terminer le projet en temps et en heure !

Vue arrière du boîtier ouvert

Vue arrière du boîtier ouvert

Déroulement d’une partie :

Une partie peut donc se dérouler de la façon suivante :
– Le joueur arrive et sélectionne son niveau à l’aide du clavier qui lui confirme par la suite grâce au LCD

Ampoules de toutes les couleurs
panneau de commandes avec les boutons de couleurs

– Il essaye de trouver la bonne combinaison de boutons pour avancer dans le jeu et parvenir à trouver le résultat désiré
– Lorsqu’il trouve, un code s’affiche sur l’écran LCD et le joueur peut passer au niveau suivant.

Conclusion :

Grâce à l’importance de la communication et du travail d’équipe au sein de notre groupe, nous avons pu répondre à un cahier des charges qui semblait impossible si l’on s’y attaquait seul. Ce projet nous a d’autre part permis de développer nos compétences en CAO, en programmation et surtout nous a offert des connaissances en matière d’électricité, de moyens d’assemblages et sur bien d’autres domaines. Nous tenons à remercier encore une fois toutes les personnes ayant contribué au projet et nous espérons que ce projet, dont nous avons pris beaucoup de plaisir à réaliser, sera amené à être améliorer les prochaines années.

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