Projet de Fin d’Etudes
Conception et réalisation d'un prototype de borne interactive
destinée à la visualisation en réalité augmentée de deux
modèles numériques des fortifications de Nancy Renaissance
Mission Renaissance 2013
Ville de Nancy
Communauté Urbaine de Nancy
Rapport présenté par Nicolas Eck
Département mécanique
Mécatronique - 5ème année
Septembre 2012
Tuteurs : Emmanuel Alby
Eddie Smigiel
INSA de Strasbourg
PFE Nicolas ECK MIQ 5 2011/2012 Page 2
Institut National des Sciences Appliquées de Strasbourg
PROJET DE FIN D’ETUDES
Auteur : Nicolas ECK Promotion : 2012
Titre : Conception et réalisation d'un prototype de borne
interactive destinée à la visualisation en réalité augmentée de deux modèles numériques des fortifications de Nancy
Renaissance.
Soutenance : 11 septembre 2012
Structure d’accueil : Laboratoire de photogrammétrie – département Topographie
Nb de volume(s) : 2 (rapport & annexes) Nb de pages : rapport 54 – annexes 66 Nb de références bibliographiques : 14
Résumé : Ce projet s’inscrit dans le contexte de la manifestation intitulée « Renaissance Nancy 2013 » organisée
par la Communauté urbaine du Grand Nancy et la ville de Nancy, et orchestrée par le groupe « Mission Renaissance ». Parmi le large éventail d’évènements proposé à cette occasion, l’un d’entre eux consiste à présenter au public des modèles numériques du bastion de Vaudémont et de la porte Saint George
tels que les Nancéens de l’époque de la Renaissance pouvaient les voir, par l’intermédiaire de dispositifs de réalité augmentée.
De par la nature du besoin, ce projet a été conduit en collaboration avec le département topographie de l’école. En effet, les modèles numériques ont été réalisés par un étudiant topographe au cours d’un
projet de fin d’études associé. Les différentes études et travaux au cours du projet ont abouti sur la conception et la réalisation d’un
prototype de borne interactive, ainsi que la programmation d’une interface utilisateur et de l’application de réalité augmentée, adaptable aux deux sites.
Mots clés : traitement d’images, programmation C# et C++, conception de montages électroniques,
conception et dimensionnement de systèmes mécaniques
Traduction : This project fits into the context of the event "Nancy Renaissance 2013" organized by the Urban
Community of Nancy and the city of Nancy. It is orchestrated by the group "Mission Renaissance". Among the wide range of events offered on this occasion, one of them consists in showing the public numerical models of the "bastion Vaudémont" and the "Saint George" gate such as the people of
Nancy could see them during the Renaissance, through augmented reality devices. Owing to the requirements nature, this project was conducted in collaboration with the topography
department of the school. Indeed, the numerical models have been made by a topographer student during an associated project.
The assorted studies and work resulted in the design and the manufacture of an interactive terminal prototype, and the programming of a user interface and an augmented reality application, adaptable to both sites.
PFE Nicolas ECK MIQ 5 2011/2012 Page 3
Remerciements
Je tiens à remercier M. Alain Barbillon de m’avoir offert l’opportunité d’effectuer mon projet de fin
d’études pour la Mission Renaissance, ainsi que MM. Emmanuel Alby, Eddie Smigiel, René Elter et
Jean-François Hullo pour les conseils avisés qu’ils m’ont apporté tout au long de ce projet.
Je souhaite également remercier l’ensemble des enseignants, techniciens, doctorants et étudiants du
laboratoire de photogrammétrie pour leur accueil et leur sympathie.
De même je remercie les techniciens de la Plate-Forme Mécanique pour leurs conseils et leur aide
précieuse.
PFE Nicolas ECK MIQ 5 2011/2012 Page 4
Table des matières
Introduction ........................................................................................................................................... 5
I. Etude préliminaire .......................................................................................................................... 7
A. Cahier des charges...................................................................................................................... 7
B. Détail de la borne interactive ..................................................................................................... 8
C. Implantation ............................................................................................................................. 10
II. Interface utilisateur ...................................................................................................................... 12
A. Place Stanislas .......................................................................................................................... 12
B. Porte St George ........................................................................................................................ 14
III. Application de réalité augmentée ............................................................................................ 15
A. Panorama ................................................................................................................................. 16
B. Calibration de la caméra ........................................................................................................... 17
C. OpenCV .................................................................................................................................... 18
D. Algorithme de suppression des déformations .......................................................................... 20
E. Position et orientation .............................................................................................................. 26
F. Fonctionnement global ............................................................................................................ 28
G. Initialisation de l’application .................................................................................................... 30
IV. Cartes électroniques ................................................................................................................. 31
A. Carte capteurs .......................................................................................................................... 31
B. Carte IHM ................................................................................................................................. 35
C. Bouton On/Off de l’ordinateur ................................................................................................. 38
V. Conception mécanique................................................................................................................. 39
A. Détail de la conception ............................................................................................................. 40
B. Calcul du vérin .......................................................................................................................... 43
C. Calculs de résistance des matériaux ......................................................................................... 45
D. Coques ...................................................................................................................................... 46
E. Assemblage .............................................................................................................................. 47
VI. Fabrication du prototype .......................................................................................................... 49
A. Usinage ..................................................................................................................................... 49
B. Fabrication des coques plastiques ............................................................................................ 51
Conclusion ............................................................................................................................................ 52
Webographie ........................................................................................................................................ 54
PFE Nicolas ECK MIQ 5 2011/2012 Page 5
Introduction
Ce projet s’inscrit dans le contexte de la manifestation intitulée « Renaissance Nancy 2013 »
organisée par la Communauté urbaine du Grand Nancy et la ville de Nancy. Cet événement débutera
le 4 mai 2013 et prendra fin le 4 août 2013, et est orchestré par le groupe « Mission Renaissance »
dont le responsable est M. Alain Barbillon. M. René Elter est l’archéologue chargé du suivi du projet.
A l'instar des événements de 1999 (l'Année de l'Ecole de Nancy) et de 2005 (Nancy 2005, le temps
des Lumières), « Renaissance Nancy 2013 » propose un large éventail de manifestations. L’une
d’entre elles consiste à présenter au public des modèles numériques du bastion de Vaudémont et de
la porte Saint George tels que les Nancéens de l’époque de la Renaissance pouvaient les voir, à l’aide
de dispositifs de réalité augmentée.
La réalité augmentée désigne les systèmes informatiques qui rendent possible la superposition d'un
modèle virtuel 2D ou 3D à la perception que nous avons naturellement de la réalité et ceci en temps
réel. Ces applications sont multiples et touchent de plus en plus de domaines, tels que les jeux vidéo,
l'éducation par le jeu, les chasses au trésor virtuelles, le cinéma et la télévision, les industries
(conception, design, maintenance, assemblage, pilotage, robotique, implantation, étude d'impact,
etc.) ou encore le médical.
Ainsi, une borne interactive de visualisation en réalité augmentée est un dispositif équipé d’un écran
et d’une caméra, permettant de visionner un décor réel dans lequel ont été implantés un ou
plusieurs modèles numériques. Ce type d’appareil est notamment utilisé sur le site de l’abbaye de
Cluny depuis 2008. Il s’agit alors de la borne Ray-On développée par la société on-situ. A titre
d’exemple, j’ai contacté cette société pour connaître les tarifs pratiqués. Pour un projet avec création
de modèles et installation de bornes Ray-On, il faut compter environ 60 000 euros.
Le groupe PAGE (Photogrammétrie Architecturale et GEomatique) de l’INSA de Strasbourg a répondu
à l’appel d’offre de la Mission Renaissance pour la réalisation des modèles et la mise en œuvre du
dispositif, en proposant des stages à deux étudiants de l’école. Les relevés topographiques, les
mesures photogrammétriques et la création des modèles numériques 3D ont été réalisés par un
étudiant topographe, Johann Tonnerieux, au cours d’un projet de recherche technologique puis en
projet de fin d’études. De même, j’ai réalisé l’avant-projet de conception de la borne (état des lieux
des technologies, contraintes physiques, contraintes de coût, etc.) au cours de mon projet de
recherche technologique.
Le besoin de la Mission Renaissance est l’installation de deux bornes interactives, sur la place
Stanislas et sur l’Avenue du Vingtième Corps, destinées à mettre à la disposition du grand public
respectivement des modèles numériques 3D du bastion de Vaudémont et de la porte St George. Le
groupe PAGE dispose d’un budget de 15 000 € HT pour la réalisation des deux bornes.
Cependant, les objectifs de mon projet de fin d’études sont la conception et la réalisation d’un
prototype de borne selon le cahier des charges établi lors du projet de recherche technologique, ainsi
que la programmation d’une interface utilisateur et de l’application de réalité augmentée, adaptable
aux deux sites. Le prototype est destiné à être installé sur la place Stanislas.
PFE Nicolas ECK MIQ 5 2011/2012 Page 6
Mon projet de fin d’études s’est déroulé au laboratoire de photogrammétrie de l’école et fut
ponctué de plusieurs déplacements à Nancy à l’occasion de réunions avec le groupe de la Mission
Renaissance.
L’intitulé de mon projet est : Conception et réalisation d'un prototype de borne interactive destinée à
la visualisation en réalité augmentée de deux modèles numériques des fortifications de Nancy
Renaissance.
PFE Nicolas ECK MIQ 5 2011/2012 Page 7
I. Etude préliminaire
Afin de simplifier la lecture et la compréhension de ce document, ce premier chapitre résume le
travail réalisé lors du projet de recherche technologique, ayant servi de base à l’étude du projet de
fin d’études, et présente dans les grandes lignes la conception de la borne interactive. Les chapitres
suivants détailleront un à un les différents domaines de l’étude, et présenteront également de façon
concise les solutions technologiques qui ont été envisagées mais non retenues.
A. Cahier des charges
Le cahier des charges de la borne, disponible en annexe, définit la totalité des fonctions que doit
respecter le produit final. Celles-ci sont établies sur la base de la demande du groupe Mission
Renaissance, et sont issues d’un échange permanent au cours de l’étude. Cela implique certaines
modifications par rapport au cahier des charges présenté dans le rapport de projet de recherche
technologique en janvier 2012.
L’analyse du besoin et l’étude de la faisabilité sont les outils de l’analyse fonctionnelle permettant la
définition d’un cahier des charges. Ci-dessous se trouve un extrait du cahier des charges, détaillant
l’expression du besoin fondamental :
A qui le produit rend-il service ? à l’utilisateur
Sur quoi agit le produit ? l’environnement
Dans quel but ? afficher à l’écran la superposition d’une numérisation 3D sur l’environnement, en fonction de l’orientation de l’écran
I-1 : Diagramme de l’expression du besoin fondamental
PFE Nicolas ECK MIQ 5 2011/2012 Page 8
B. Détail de la borne interactive
1. Manipulation et design
Comme présenté dans la partie V. – A., le bras articulé de la borne est constitué d’un système quatre
barres, appelé parallélogramme déformable ou encore pantographe, permettant le réglage de la
hauteur, et d’une liaison pivot permettant l’orientation sur l’axe vertical.
La conception telle que présentée sur l’illustration ci-dessous permet un delta de réglage en hauteur
de 360 mm et une plage d’orientation de 90°.
Figure I-2 : Manipulation de la borne
La borne dispose d’un coffret étanche et de coques de protection garantissant la résistance du
système aux intempéries et destinés à améliorer son esthétisme.
2. Composants internes
Schéma d’interaction :
I-3 : Composants électroniques internes
PFE Nicolas ECK MIQ 5 2011/2012 Page 9
Détail des différents composants de la borne :
PC embarqué :
Le cœur de la borne est le PC embarqué. Il communique avec les autres éléments par USB, et par l’intermédiaire de cartes électroniques pour les boutons poussoirs (IHM) et les capteurs de détection de l’orientation de la borne.
Moniteur : Il possède des haut-parleurs intégrés et une résolution de 1920 x 1080 pixels.
Caméra : De type webcam, elle possède une résolution vidéo maximale de 2 mégapixels (1920 x 1080 en 16/9).
3. Fonctionnement
Le schéma suivant détaille le fonctionnement interne de la borne :
Figure I-4 : Schéma de fonctionnement interne
L’interface utilisateur est un programme exécutable lancé automatiquement à l’allumage de
l’ordinateur. Elle contrôle le démarrage et l’arrêt du programme de l’application de réalité
augmentée.
L’utilisateur peut interagir avec l’interface à l’aide du clavier USB à quatre boutons simulé par la carte
Arduino et son montage associé (IHM : Interface Homme-Machine).
Le programme de l’application de réalité augmentée, lorsqu’il est actif, reçoit le flux vidéo de la
caméra en permanence. Afin de déterminer l’orientation de la borne, il questionne régulièrement la
deuxième carte Arduino pour obtenir l’information de position angulaire du coffret par rapport au
support, mesurée par les capteurs mécaniques (potentiomètre et microrupteurs). Ainsi, le résultat de
l’application est une fenêtre d’affichage de la vidéo en temps réel dans laquelle est ajouté le modèle
numérique en fonction de l’orientation de la borne.
PFE Nicolas ECK MIQ 5 2011/2012 Page 10
C. Implantation
1. Place Stanislas
La borne de la place Stanislas sera placée à l’angle du musée des Beaux-arts, sur un tampon non
utilisé et relié à l’hôtel de ville. Cette solution présente l’avantage de ne pas utiliser d’estrade et
permet d’épurer l’implantation.
Figure I-5 : Implantation de la borne place Stanislas
Figure I-6 : Implantation de la borne place Stanislas sur un tampon
Le tampon disponible est de forme carrée, mais l’espace disponible en dessous est cylindrique et
désaxé par rapport au tampon.
Figure I-7 : Modèle numérique du tampon
PFE Nicolas ECK MIQ 5 2011/2012 Page 11
La fixation de l’embase est en cours de validation par les services techniques de Nancy. Dans cette
proposition, l’embase est maintenue au sol à l’aide d’une poutre encastrée dans l’épaulement du
tampon.
Figure I-8 : Fixation de l'embase de la borne dans le tampon
La fabrication du support et de l’embase est attribuée aux services techniques de la ville de Nancy.
2. Porte St George
L’estrade sur laquelle sera placée la borne de la porte St George occupe entièrement l’espace de la
dernière place de parking du côté sud de l’Avenue du Vingtième Corps, au plus proche de la porte.
L’estrade sera équipée de plots de protection pour protéger des voitures la borne et ses utilisateurs.
Figure I-9 : Implantation de la borne Avenue du Vingtième Corps
La conception et la fabrication de l’estrade sont attribuées aux services techniques de la ville de
Nancy.
PFE Nicolas ECK MIQ 5 2011/2012 Page 12
II. Interface utilisateur
Pour communiquer avec le public, la borne nécessite une interface simple d’utilisation, attrayante et
conforme à la demande du groupe Nancy Renaissance. Notamment, le contenu des interfaces de
chacune des bornes est volontairement inégal.
L’utilisation d’un ordinateur de type PC possédant un système d’exploitation Windows XP a été
choisie en particulier pour faciliter la programmation. De ce fait, l’interface utilisateur est réalisée
avec Microsoft Visual Studio 2010, un logiciel permettant notamment de réaliser des applications
exécutables sur le système d’exploitation Windows. L’interface est codée en C#, un langage de
programmation orienté objet.
L’interface est le cœur du fonctionnement de la borne interactive. Elle se lance automatiquement au
démarrage du PC et coordonne les autres applications en fonction de la demande de l’utilisateur.
A. Place Stanislas
Afin de fluidifier le passage du public devant la borne, il a été choisi de simplifier au maximum son
utilisation et minimiser l’apport d’informations. En effet, la place Stanislas est un lieu hautement
touristique, et des milliers de visiteurs y circulent chaque jour durant la période estivale.
Ainsi, le contenu de l’interface se limite à une fenêtre de démarrage réservée au service technique
(non destinée au public), une page informative principale et l’application de réalité augmentée. La
page principale sert de renvoi vers l’office du tourisme, la borne de la porte St George et le lien du
site internet de la mission renaissance (la borne n’a pas accès à Internet, il s’agit de préciser le nom
du site uniquement). Elle est agrémentée par les logos des différents acteurs du projet : INSA de
Strasbourg, Ville de Nancy, Communauté urbaine de Nancy, Nancy Renaissance, Nancy Tourisme.
Au démarrage du PC embarqué, l’interface utilisateur se lance de façon automatique. De ce fait, il
n’est pas nécessaire de brancher souris et clavier à la borne pour démarrer l’interface.
II-1 : Schématisation du contenu de l'interface de la borne place Stanislas
Comme l’illustre la figure II-1, le démarrage de l’interface par le service technique lance l’application
de réalité augmentée en arrière-plan. Quand un utilisateur choisit une langue pour démarrer la
PFE Nicolas ECK MIQ 5 2011/2012 Page 13
visualisation, la page principale se ferme et laisse place aux commentaires écrits et audio, proposés
en français, anglais et allemand. Quand la temporisation s’achève, la page principale réapparait au
premier plan. En effet l’application de réalité augmentée se coupe automatiquement pour limiter le
temps d’utilisation par utilisateur. Ce temps de visualisation est de l’ordre de la minute.
PFE Nicolas ECK MIQ 5 2011/2012 Page 14
B. Porte St George
L’interface de la borne porte St George possède un contenu informatif très complet. De par son
emplacement, le nombre de visiteurs sera moins important que pour la borne de la place Stanislas.
De ce fait, les conditions d’utilisation seront plus favorables à la recherche d’information puisque
chaque utilisateur pourra disposer plus longtemps de la borne.
Le cahier des charges impose certains éléments au contenu de cette interface :
- Présentation du contexte
- Présenter tous les évènements de la manifestation
- Possibilité de changer la langue (français, anglais, allemand)
- Commentaires sonores
- Couper le son la nuit
L’interface est composée d’un menu permettant l’accès aux différentes rubriques, telles que
l’exposition du contexte de la manifestation, la présentation du travail qui a contribué au
développement des modèles numériques et de la borne interactive et le lancement de l’application
de réalité augmentée.
L’utilisateur navigue dans le menu à l’aide de quatre boutons poussoirs placé juste sous l’écran de la
borne. Afin de simplifier l’utilisation et limiter les plantages, le périmètre d’action de l’utilisateur est
volontairement réduit, c’est-à-dire limité à la sélection et la validation de boutons permettant la
navigation dans l’interface.
Figure II-2 : Boutons de navigation de l'interface
A la date de rédaction de ce document, le sommaire de l’interface se présente de la sorte :
1/ Présentation du contexte (mission renaissance, projet de modélisation, acteurs du projet,
travaux effectués, etc.)
2/ Application de réalité augmentée (avec une introduction au concept)
3/ Liste des différents événements de la manifestation
4/ Choix de la langue
Figure II-3 : Illustration du menu principal de l'interface de la borne Porte St George
PFE Nicolas ECK MIQ 5 2011/2012 Page 15
III. Application de réalité augmentée
L’application de réalité augmentée a subi quelques controverses au cours de son développement.
Initialement, telle que présentée à la fin du projet de recherche technologique, elle devait être
produite à partir du logiciel D’Fusion, appartenant à la société Total Immersion.
Ce logiciel permet d’ajouter dans un flux vidéo un modèle numérique en trois dimensions, animé ou
non, avec effets d’ombres, de lumières et de particules. La position des modèles est définie à partir
de la reconnaissance de marqueurs réels du décor, ce qui s’applique parfaitement au cas traité dans
ce projet.
Figure III-1 : Exemple d'application de RA utilisant des photographies comme marqueurs
L’inconvénient majeur est le coût de ce logiciel. En effet, la version libre ne s’applique pas à une
utilisation commerciale et l’achat d’une licence coûte entre 4 500 et 10 000 euros en fonction de la
plateforme déployée. D’autres logiciels similaires comme ARToolKit possèdent également des
versions dédiées à la détection de marqueurs réels, mais ceux-ci sont payants également.
La solution alternative employée est l’utilisation d’une bibliothèque de traitement d’images pour
afficher non pas un modèle 3D mais un rendu 2D de ce modèle. Cette alternative est rendue possible
par le fait que les bornes et les modèles à afficher sont fixes. De cette façon, le modèle ne peut être
observé que depuis un point de l’espace.
Ainsi, le modèle numérique n’est pas exploité en trois dimensions pour l’application de réalité
augmentée, mais en tant qu’image. Plusieurs rendus de celui-ci sous forme de panoramas à 360
degrés sont utilisés.
L’application de réalité augmentée a été développée avec l’environnement de développement
intégré CodeBlocks et est destinée à fonctionner sur plate-forme Windows uniquement. Ce
programme exécutable, codé en C++, s’appuie sur la bibliothèque OpenCV pour afficher le panorama
dans la vidéo issue de la caméra. Cette image est orientée en fonction de l’état de capteurs
mécaniques, communiquant avec le programme.
Un fichier LOG appelé Historique.txt recense les activités de l’application, en particulier les erreurs ou
bogues éventuels.
PFE Nicolas ECK MIQ 5 2011/2012 Page 16
A. Panorama
Le modèle est donc affiché à l’écran sous la forme d’un panorama sphérique. On peut voir ci-dessous
un exemple de panorama du laboratoire de photogrammétrie, assemblé sur sa sphère élémentaire.
Figure III-2 : Panorama sphérique du laboratoire de photogrammétrie
Ci-dessous le même panorama, en projection sphérique :
Figure III-3 : Panorama sphérique mis à plat
On observe que la projection du panorama conserve les verticales des images d’origine, mais le
rendu est déformé par rapport au décor réel.
Ces déformations sont inhérentes à la création d’un panorama sphérique puisque celui-ci est
composé d’un assemblage de prises de vue sur une sphère.
PFE Nicolas ECK MIQ 5 2011/2012 Page 17
B. Calibration de la caméra
A l’aide du logiciel PhotoModeler, la calibration de la webcam (TRUST eLight Full HD 1080p) a permis
d’obtenir les valeurs des paramètres intrinsèques de celle-ci.
Figure III-4 : Résultat de la calibration de la caméra
D’après la calibration, le champ de vue horizontal de la caméra est d’environ 47 degrés. Cette valeur
est utilisée dans l’algorithme présenté en partie III.-D.
PFE Nicolas ECK MIQ 5 2011/2012 Page 18
C. OpenCV
OpenCV (Open Computer Vision) est une bibliothèque graphique libre spécialisée dans le traitement
d'images en temps réel. Elle permet notamment de récupérer le flux vidéo d’une caméra et de le
modifier image par image. Ainsi elle a été choisie pour effectuer le traitement d’image nécessaire à la
réalisation de l’application de réalité augmentée. La programmation se code en C++, très polyvalent
et troisième langage informatique le plus utilisé. La version utilisée dans ce projet est OpenCV 2.1.
La bibliothèque OpenCV permet d’ouvrir une fenêtre Windows de dimensions prédéfinies, pour y
afficher le flux vidéo de la webcam HD 16/9. Pour insérer une image dans une autre image, on utilise
l’outil ROI (Region Of Interest) qui permet de sélectionner une zone rectangulaire dans l’image de
fond.
Figure III-5 : Fenêtre d'affichage du programme 3_OpenCV_InsertionImageDansCaptureVideo
L’ajout d’une image peut se faire avec un masque, une autre image en noir et blanc, ce qui permet de
définir des zones non visibles dans l’image ajoutée.
Figure III-6 : Fenêtre d'affichage du programme 4_OpenCV_MaskDansVideo
Il est également possible d’afficher deux images par transparence à l’aide d’une fonction prédéfinie.
PFE Nicolas ECK MIQ 5 2011/2012 Page 19
Figure III-7 : Fenêtre d'affichage du programme 16_OpenCV_TransparenceParSuperposition
L’outil ROI peut également être utilisé pour sélectionner une partie de l’image qu’on souhaite ajouter
dans celles du flux vidéo. De plus, les coordonnées de la position d’un ROI peuvent être modifiées à
tout moment. Il est donc possible de « faire glisser un panorama derrière une fenêtre ».
Figure III-8 : Illustration explicative de l'outil ROI
Sur la figure III-8, le ROI possède une largeur et une hauteur fixe et est déplacé dans le panorama
pour en sélectionner une partie uniquement.
Cette fonctionnalité est une première étape importante dans le développement de l’application.
Cependant, la solution du ROI seule n’est pas satisfaisante. Comme il a été expliqué précédemment,
le panorama est une représentation 2D déformée de l’objet initial. Il est donc nécessaire d’utiliser
une méthode de suppression de ces déformations.
PFE Nicolas ECK MIQ 5 2011/2012 Page 20
D. Algorithme de suppression des déformations
Un algorithme a été développé pour créer, à partir du panorama, une image corrigée ayant les
mêmes dimensions que la fenêtre d’affichage de l’application de réalité augmentée. Les pixels du
panorama sont copiés sur la nouvelle image de façon à éliminer les déformations.
La première solution étudiée a été l’ajout de distorsions aux images du flux vidéo, pour s’adapter aux
distorsions du panorama plutôt que de les supprimer. En effet, OpenCV possède les outils
nécessaires pour ajouter ou minimiser les distorsions dans une vidéo (voir annexes). Le code
« 20_OpenCV_ImagePotVideoDistorsion » est fonctionnel et permet de modifier les paramètres de
distorsions. Cependant, cette solution n’a pas été conservée.
1. Modèle géométrique
L’étude se base sur le modèle illustré par les figures III-9 à III-14, avec la convention en image non
inversée, pour établir les calculs présentés dans la suite de ce chapitre. Ce modèle ainsi que les
formules utilisées dans l’algorithme ont été développés avec l’aide de Jean-François Hullo, doctorant
au laboratoire de photogrammétrie de l’INSA de Strasbourg.
Figure III-9 : Modèle de superposition du panorama au champ de vision de la caméra (1/2)
Figure III-10 : Modèle de superposition du panorama au champ de vision de la caméra (2/2)
Le panorama est en gris, le champ de vue de la caméra en vert et l‘image que l’on souhaite afficher
en rose. Le sommet de la pyramide verte représente le centre optique de la caméra.
Le schéma suivant définit la méthode de travail. Pour chaque pixel de l’image construite (1280 x
720 px), on cherche le pixel qui lui correspond sur le panorama. Pour ce faire, on calcule à chaque
itération l’angle qui détermine la position du pixel par rapport à l’axe optique.
PFE Nicolas ECK MIQ 5 2011/2012 Page 21
Figure III-11 : Schématisation de la méthode de traitement des pixels
Les paramètres utilisés sont les suivants :
γ : champ de vue
: angle définissant la position du pixel
: résolution de l’image affichée à l’écran
: résolution du panorama
et : limites de la partie du panorama à afficher
f : focale (en pixels)
r : rayon du panorama (en pixels)
On utilise les schémas suivants pour calculer le rayon, avec E le centre optique de la caméra :
Figure III-12 : Représentation volumique du modèle
PFE Nicolas ECK MIQ 5 2011/2012 Page 22
Figure III-13 : Détail de la représentation volumique
On peut calculer la focale et le rayon, en nombre de pixels :
2. Détail du traitement de l’algorithme
Les calculs d’angles sont établis sur la base de deux coupes de la représentation en volume. Le champ
de vue horizontal et le champ de vue vertical sont différents puisque la caméra filme en 16/9.
Figure III-14 : Coupes de la représentation volumique
On utilise la notation présentée précédemment pour les calculs, avec l’indice i pour les colonnes et
l’indice j pour les lignes de l’image construite (voir figure III-11). Ainsi, pour chaque pixel de l’image
construite doté d’une coordonnée (i,j) correspond un pixel du panorama localisé à l’aide des angles
et .
PFE Nicolas ECK MIQ 5 2011/2012 Page 23
Pour éviter les problèmes de signe des angles, l’image est découpée en zones (haut gauche, haut
droite, bas gauche, bas droite) et donc traitée en quatre fois.
Deux boucles for sont imbriquées pour traiter l’image colonne par colonne, un pixel après l’autre. Le
traitement se fait de la façon suivante, pour l’exemple de la partie haute gauche de l’image :
// Première boucle : sélection de la colonne à traiter
for ( = 0; < (largeurImage/2); ++)
{
// Calcul de l'angle alpha_i
// Calcul de la position correspondante sur le panorama
// Calcul de la focale pour la verticale en cours de traitement
// Deuxième boucle : traitement des pixels de la colonne
for ( = 0; < (hauteurImage/2); ++)
{
// Calcul de l'angle alpha_j
// Calcul de la position correspondante sur le panorama
// Extraction des couleurs du pixel du panorama et copie des couleurs sur le pixel de l'image
}
}
Afin de gagner du temps de calcul, les quatre zones de l’image ne sont pas traitées de la même façon.
En effet, du fait de la symétrie des déformations, les calculs sont redondants et les résultats du
traitement des premières zones peuvent être adaptés aux suivantes.
PFE Nicolas ECK MIQ 5 2011/2012 Page 24
Figure III-15 : Schéma de fonctionnement simplifié de l'algorithme
La figure III-15 représente une schématisation du traitement de l’image. Chaque case représente un
pixel de l’image construite, dont l’indice indique l’ordre de traitement. Les quatre zones de l’image
sont bien délimitées et le cadre rouge indique la partie haute gauche, par laquelle commence le
traitement. Dans ce premier cas, l’indice de sélection du pixel correspond au calcul :
Pour chaque pixel de l’image, les coordonnées du pixel correspondant sur le panorama sont
enregistrées dans des tableaux. Ces valeurs sauvegardées sont ensuite adaptées aux trois autres
zones de l’image selon la figure III-16.
Figure III-16 : Partage des données
3. Utilisation de l’algorithme
Le traitement est répété à chaque nouvelle image issue du flux vidéo. Le résultat est convaincant
puisque les déformations sont corrigées. Les lignes horizontales du décor restent droites et
horizontales à l’affichage de l’image.
La figure III-17 illustre un exemple de la fenêtre d’affichage du code
« 21_OpenCV_CopierImagePixelParPixel », après correction des déformations.
PFE Nicolas ECK MIQ 5 2011/2012 Page 25
Figure III-17 : Fenêtre d'affichage du programme 21_OpenCV_CopierImagePixelParPixel
Dans un souci d’optimisation, deux algorithmes C++ ont été réalisés : copierPixelParPixel et
copierPixelParPixel_2. Le premier réalise le traitement présenté dans les paragraphes précédents.
Dans le but de gagner du temps de calcul, le deuxième algorithme utilise les résultats du premier,
sauvegardés dans le fichier Tableaux.txt, pour éviter de recalculer les coordonnées plusieurs fois
quand c’est possible.
PFE Nicolas ECK MIQ 5 2011/2012 Page 26
E. Position et orientation
La position de la zone à traiter dans le panorama est définie par une abscisse et une ordonnée. Ces
valeurs sont déterminées à partir de la position physique de l’ensemble écran de la borne. Pour
définir en temps réel les coordonnées, plusieurs pistes ont été suivies :
1. Détection d’objet dans le flux vidéo
La bibliothèque OpenCV dispose d’outils et fonctions permettant la détection d’objets dans une
image. Un tutoriel est disponible en annexe. Ainsi il est possible d’obtenir les coordonnées de la
position de l’objet détecté dans l’image et d’utiliser ces coordonnées pour intégrer une nouvelle
image dans celles issues du flux vidéo.
Cependant, si une partie de l’objet est occultée la détection est impossible, ce qui engendrerait des
défauts de fonctionnement importants. La détection d’objets a également été envisagée pour
l’initialisation uniquement, mais pour ces mêmes raisons, elle n’a pas été conservée.
2. Capteur de position mécanique
La deuxième solution est d’utiliser des capteurs mécaniques de position, placés au niveau des liaisons
de la borne.
Initialement, le cahier des charges imposait deux rotations possibles à l’écran de la borne. Une sur
l’axe vertical et l’autre sur l’axe horizontal. Avec l’accord de Mme Marie-Aude Biewer, architecte
DPLG du pôle de développement et aménagement urbain à Nancy, la rotation sur l’axe horizontal a
été supprimée du cahier des charges pour assurer une robustesse du système plus importante, et
limiter l'amplitude des mouvements. En effet, grâce à l’angle de vue important de la caméra, la
hauteur du modèle peut être observée en totalité, quelle que soit l’orientation sur l’axe vertical.
De plus, le réglage en hauteur de la borne est assuré par un « système quatre barres », de type
pantographe. L’orientation de l’écran et de la caméra n’est donc pas modifiée par le réglage en
hauteur.
Ces deux éléments ont permis la limitation du nombre de capteurs de rotation et le choix d’un
potentiomètre linéaire adopté pour sa simplicité de mise en œuvre et sa fiabilité de fonctionnement.
Figure III-18 : Potentiomètre linéaire
Afin de permettre une initialisation de la position et corriger les éventuels décalages, deux capteurs
de détection des butées sont ajoutés. Il s’agit de microrupteurs.
Figure III-19 : Microrupteur monostable
PFE Nicolas ECK MIQ 5 2011/2012 Page 27
Ainsi, l’orientation par capteurs mécaniques est la méthode exploitée.
3. Gestion de l’orientation
Comme présentée sur la figure I-4, l’application de réalité augmentée communique avec la carte
Arduino pour connaitre l’état des capteurs d’orientation. La détection des butées par les
microrupteurs permet de définir une plage de données dans laquelle varie la valeur du
potentiomètre. Celle-ci est utilisée pour déterminer l’orientation, et la valeur d’abscisse de la
position du panorama.
Cette abscisse est calculée en multipliant un facteur d’échelle (factEchelle) à la valeur du
potentiomètre. En effet, la valeur du potentiomètre est comprise entre 0 et 1024, alors que le
panorama possède environ 8 000 pixels en largeur. Le facteur d’échelle est calculé de la façon
suivante :
Le code complet de communication entre le programme et la carte est proposé en annexes.
PFE Nicolas ECK MIQ 5 2011/2012 Page 28
F. Fonctionnement global
Le schéma suivant résume la démarche de fonctionnement de l’application de réalité augmentée :
Figure III-20 : Schématisation du fonctionnement de l'application de RA
Le panorama utilisé est défini en fonction de l’heure de la journée et du résultat désiré. En effet il
existe plusieurs panoramas pour respecter au mieux les effets d’ombre et de lumières. L’abscisse est
définie en fonction de la valeur d’orientation renvoyée par les capteurs.
Le traitement pixel par pixel sélectionne une zone du panorama pour créer une image rectangulaire
sans déformation appelée image intermédiaire.
L’image intermédiaire est insérée dans la vidéo selon un traitement d’image spécifique au résultat
souhaité et le résultat est affiché à l’écran, dans une fenêtre Windows. Le panorama peut être inséré
dans le flux vidéo de trois façons, ce qui permet d’obtenir trois vues différentes :
- Panorama uniquement :
Figure III-21 : Illustration du rendu (1/3)
PFE Nicolas ECK MIQ 5 2011/2012 Page 29
- En transparence :
Figure III-22: Illustration du rendu (2/3)
- Avec l’actuel au premier plan, et le modèle derrière les bâtiments existants :
Figure III-23: Illustration du rendu (3/3)
Les images présentées sur les figures III-21 à III-23 sont illustratives uniquement.
PFE Nicolas ECK MIQ 5 2011/2012 Page 30
G. Initialisation de l’application
Deux programmes sont utilisés pour parfaire l’application de réalité augmentée. Le premier,
« AppRA_PlaceStanislas_Init », est un programme d’initialisation. Il utilise l’algorithme
copierPixelParPixel. Le deuxième programme, « AppRA_PlaceStanislas », est le programme principal.
Il utilise l’algorithme copierPixelParPixel_2.
Afin de caler la position de l’image dans la vidéo, il est nécessaire d’exécuter en premier le
programme d’initialisation. Il fonctionne comme le programme principal, mais permet, à l’aide d’un
clavier branché au préalable sur la face avant du coffret (voir figure IV-13), de modifier les
paramètres d’affichages de l’image dans la vidéo.
Ainsi, il est possible de corriger les erreurs de décalage entre les butées réelles et les butées virtuelles
(minAbs et maxAbs) à l’aide des valeurs offsetGauche et offsetDroite.
Figure III-24 : Correction des butées
De plus, la fonction « rotationImage » incluse dans le programme permet de tourner l’image ajoutée
par rapport à son centre sur un axe perpendiculaire au plan de l’image. Cette fonction permet de
corriger une éventuelle erreur de mise à niveau horizontale de la borne.
Différents paramètres sont également réglables pendant l’exécution du programme d’initialisation.
La liste complète est disponible dans le tableau suivant.
Paramètre modifié Touche + Touche -
offsetGauche Z S
offsetDroite E D
angleDeRotation O L
champDeVue_H P M
offsetVertical I K
offsetHorizontal U J
Une fois les paramètres ajustés visuellement, ceux-ci sont enregistrés automatiquement dans le
fichier Parametres.txt à la fermeture du programme d’initialisation.
A chaque démarrage du programme principal, celui-ci lit les données enregistrées dans le fichier
Parametres.txt, et utilise ces valeurs pour placer et orienter correctement l’image intermédiaire dans
le flux vidéo (voir figure III-20). Ainsi il n’est pas nécessaire d’exécuter le programme d’initialisation à
chaque démarrage de la borne, mais uniquement après le montage sur place de l’équipement.
PFE Nicolas ECK MIQ 5 2011/2012 Page 31
IV. Cartes électroniques
A. Carte capteurs
1. Montage
L’état des capteurs est relevé à l’aide d’une carte Arduino UNO. Celle-ci permet, à l’aide d’un
montage électronique très simple, d’envoyer les états des capteurs au PC, via un câble USB.
Figure IV-1 : Montage de l'ensemble "communication avec les capteurs"
Les LED sont utilisées pour signaler la fermeture du contact des microrupteurs. Cela est indispensable
pour le réglage de la position des capteurs lors du montage sur le système mécanique.
2. Programmation de la carte Arduino
L’environnement de développement nécessaire à la programmation d’une carte Arduino est
disponible gratuitement sur le site internet du fabricant. Le site propose également de nombreux
exemples et tutoriels de très bonne qualité permettant la création de scripts utilisés pour la lecture
de capteurs.
L'Arduino est une plate-forme de prototypage électronique, open source, avec une très grande
communauté sur Internet. Elle dispose d’un microcontrôleur, son environnement (quartz,
condensateur, etc.), des entrées/sorties et une connexion USB vers un PC. Pour le programmeur, il
est possible d’utiliser l'environnement de développement basé sur Processing, et utiliser un langage
proche du C.
Par exemple, on trouve sur internet des projets du type :
- communication avec des mémoires via le protocole SPI
- construction de robots marcheurs, rampants, etc.
- jeux de lumière
PFE Nicolas ECK MIQ 5 2011/2012 Page 32
Figure IV-2 : Carte Arduino UNO
3. Méthodes de communication
La communication entre la carte Arduino et le code C++ a fait l’objet de plusieurs études :
Gobetwino
Gobetwino est un logiciel libre, destiné à être un intermédiaire entre une carte Arduino et Windows.
Il permet ainsi de récupérer toutes les valeurs envoyées par la carte.
Cependant les premiers essais de ce logiciel n’ont pas été probants. La communication était trop
lente, avec un décalage de plusieurs secondes par rapport au temps réel.
Processing
Processing est un langage de programmation et un environnement de développement distribué sous
GNU GPL. L’environnement de développement Arduino est basé sur Processing ce qui permet à ce
logiciel de communiquer en série avec la carte, très simplement.
La communication se fait via le port USB, mais fonctionne comme un port série.
L’inconvénient de l’utilisation de Processing est l’échange de données nécessaire avec le code
principal de l’application de réalité augmentée en C++. La méthode employée, fonctionnelle pour
l’envoi de la valeur du potentiomètre, est l’écriture et la lecture de données dans un fichier texte
(*.txt).
Cette méthode de communication manque néanmoins de précision, d’autant plus qu’il est
indispensable de filtrer les données, car l’écriture du fichier *.txt par le code Processing engendre des
erreurs inhérentes, comme l’écriture d’un nombre sur deux lignes au lieu d’une seule, ce qui fausse
le calcul en temps réel de la position.
Bibliothèque C++ dédiée à la communication série
Afin de faire communiquer le code C++ directement avec la carte, il est nécessaire d’utiliser une
bibliothèque dédiée. Grâce à la grande communauté liée à Arduino, une bibliothèque fonctionnelle a
été trouvée, testée et validée. Elle a été nommée dans ce projet « SerialCplusplus ».
Cette méthode est bien plus performante et efficiente que les précédentes. Il n’y a pas d’erreurs
dans l’échange de données et la communication est suffisamment rapide pour le travail en temps
réel.
Ainsi la communication se déroule selon le schéma présenté sur la figure IV-3. Le code C++ envoie
régulièrement des demandes de lecture de données à l’aide d’un identifiant (0, 1 ou 2). La carte
PFE Nicolas ECK MIQ 5 2011/2012 Page 33
Arduino reconnaît ces identifiants et répond avec la donnée appropriée (une valeur entre 0 et 1024
pour le potentiomètre, 0 ou 1 pour les microrupteurs). Le code utilisé est nommé
« 10_SerialCommunication » et est disponible en annexes.
Figure IV-3 : Communication série
4. Prototypage
Le routage de la carte se fait avec le module ARES du logiciel Proteus Lite, à partir du schéma de
câblage des composants.
Figure IV-4 : Typon de la carte capteurs
Le prototypage a été réalisé dans le laboratoire de mécatronique de l’INSA avec l’aide du technicien
mécatronique, sur la base du typon de la figure IV-4.
Figure IV-5 : Carte capteurs
PFE Nicolas ECK MIQ 5 2011/2012 Page 34
Afin de protéger l’électronique, chaque carte Arduino est installée avec sa carte auxiliaire dans un
boitier plastique.
Figure IV-6 : Boitier de protection pour Arduino UNO
PFE Nicolas ECK MIQ 5 2011/2012 Page 35
B. Carte IHM
1. Présentation
L'interface homme-machine définit les moyens et outils mis en œuvre afin qu'un humain puisse
contrôler et communiquer avec une machine.
Dans le cas de la borne, l’IHM est volontairement réduite pour minimiser le nombre d’actions
possibles de l’utilisateur, et simplifier l’utilisation. L’IHM est ainsi constituée de quatre boutons
poussoirs monostables, utilisés pour naviguer dans les menus et sélectionner les éléments.
L’objectif est de réaliser un clavier USB, possédant quatre touches. Pour communiquer avec le PC
embarqué, il est nécessaire d’utiliser un microcontrôleur.
Figure IV-7 : Principe d'utilisation de la carte IHM
2. Utilisation du PIC 18F4550
Les microcontrôleurs PIC forment une famille de microcontrôleurs de la société Microchip. Leur
utilisation est très répandue et il existe une importante communauté associée.
Le PIC 18F4550 permet la communication par USB, et des tutoriels sur le sujet sont disponibles sur la
toile.
Un tutoriel a été utilisé comme base de travail. Celui-ci fournit un code fonctionnel pour une
application simpliste, mais possédant tout le script nécessaire à la communication par USB utilisant le
protocole HID (utilisé par les claviers USB en général).
Le développement autour du PIC est présenté en annexe. Son utilisation dans ce projet a échoué en
raison des trop grandes difficultés rencontrées, malgré la qualité du tutoriel.
PFE Nicolas ECK MIQ 5 2011/2012 Page 36
3. Arduino : Simulation d’un clavier USB, avec la bibliothèque V-USB
Grâce à la communauté importante associée à Arduino, un code fonctionnel pour la simulation de
clavier USB et sa bibliothèque dédiée (UsbKeyBoard.h) ont été testés et validés. Ils permettent de
simuler toutes les touches présentes sur un clavier qwerty en communicant à travers l’USB grâce au
protocole HID. Le programme réalisé, nommé 11_UsbKeyboard4Buttons et proposé en annexes,
permet de simuler quatre touches de clavier à l’aide de quatre boutons monostables : flèche haut,
flèche bas, entrée, T.
Le montage associé est très simple, mais nécessite néanmoins la création d’une carte
supplémentaire. Celle-ci comporte les connecteurs, le port USB B femelle et le petit montage à l’aide
de résistances et diodes zener qui permet la simulation du clavier.
Figure IV-8 : Montage de l'ensemble "IHM"
Lors du branchement du port USB sur l’ordinateur, l’ensemble du montage est automatiquement
détecté comme un périphérique clavier.
Figure IV-9 : Développement et test du montage
4. Prototypage de la carte IHM
Le routage de la carte supplémentaire nécessaire à la simulation d’un clavier USB a pour résultat le
typon suivant.
PFE Nicolas ECK MIQ 5 2011/2012 Page 37
Figure IV-10 : Typon de la carte IHM
Comme pour la carte capteur, le prototypage de la carte IHM est réalisé dans les locaux de l’INSA.
Figure IV-11 : Carte IHM
Le montage complet est organisé dans un boitier de protection en plastique, dédié à la carte Arduino
UNO.
Figure IV-12 : Montage carte IHM complet
Les boutons peuvent être déconnectés du montage électronique pour simplifier le démontage de la
coque avant du coffret de la borne.
Figure IV-13 : Bouton monostable
PFE Nicolas ECK MIQ 5 2011/2012 Page 38
C. Bouton On/Off de l’ordinateur
Le bouton d’allumage et de reset de l’ordinateur embarqué est déplacé à l’avant du coffret. Pour cela
le connecteur existant est débranché, pour brancher un nouveau bouton monostable OFF - (ON). Le
bouton de la face avant de l’ordinateur devient donc inutilisable.
Figure IV-14 : Connecteur du bouton de démarrage originel du PC embarqué
Figure IV-15 : Nouveau bouton de démarrage du PC embarqué
Le bouton d’allumage sera placé dans la trappe de la coque avant du coffret, ainsi que deux passe-
parois équipés de ports USB.
Figure IV-16 : Trappe du coffret
Figure IV-17 : Passe-paroi avec prise USB A femelle
PFE Nicolas ECK MIQ 5 2011/2012 Page 39
V. Conception mécanique
La conception de la borne doit respecter de nombreux critères. Le cahier des charges est disponible
en annexe. Pour résumer, voici les grandes lignes de la demande client :
- simple de manipulation
- sûr d’utilisation (sans risque de blessure pour l’utilisateur)
- utilisation possible par tous
- résistant aux manipulations brutales
- résistant au vandalisme
- système étanche aux intempéries et à l’entretien
- réglable en hauteur par l’utilisateur
- réglable en orientation par l’utilisateur
Une succession de plusieurs propositions de modèles ont été nécessaires pour obtenir une
conception entièrement validée par le groupe Mission Renaissance. L’étude a été entièrement
réalisée à l’aide du logiciel Creo (Pro/Engineer) de PTC.
Les matériaux choisis sont de l’acier inoxydable de type X10 Cr Ni 18-8 pour les pièces tournantes, de
l’acier de construction mécanique de type S 235 ou S 355 pour les pièces fixes, et du plastique pour
les coques de protection. Les pièces en acier de construction seront peintes pour répondre au critère
de résistance aux intempéries et au nettoyage.
Les vis d’assemblage utilisées sont de type torx de sécurité.
Les mises en plan de chacune des pièces ainsi que la liste des composants commandés (paliers,
roulement, etc.) sont proposées dans les annexes.
Toutes les illustrations présentées dans le rapport sont issues de la conception validée et fabriquée.
La conception de la borne, en particulier de son aspect extérieur a débuté dès la fin du PRT. Ainsi,
différents modèles se sont succédé pour aboutir à la conception validée par la Mission Renaissance.
Figure V-1 : Evolution des modèles de conception, du plus ancien au plus récent
PFE Nicolas ECK MIQ 5 2011/2012 Page 40
A. Détail de la conception
La conception est réalisée de sorte que l’assemblage de la borne est constitué de plusieurs
ensembles distincts : le support, le pantographe, l’ensemble poignet et l’ensemble écran.
1. Le support
Le support a été choisi parmi un éventail de propositions. Le modèle retenu est le
« support_tubecarré » pour sa simplicité et son apparence aérée.
Figure V-2 : Support tube carré
2. Liaison côté support
La pièce Bras_7 est montée vissée sur le support. Elle constitue la partie fixe du pantographe. Les
arbres sont montés sur la pièce Bras_7 par le biais des éléments Cyl_Support_12mm_6 et
Cyl_Support_18mm_6 et maintenus par des anneaux élastiques. Des paliers en bronze
autolubrifiants assurent la rotation des bielles autour des arbres.
Figure V-3 : Liaison côté support
PFE Nicolas ECK MIQ 5 2011/2012 Page 41
3. Pantographe
Le pantographe permet le réglage en hauteur par l’utilisateur de la position de l’écran. Le vérin sert
d’aide au levage de l’écran, mais aussi d’amortisseur pour limiter la vitesse de déplacement de
l’ensemble.
Figure V-4 : Pantographe
4. Poignet
L’ensemble poignet fait la liaison entre le pantographe et l’ensemble écran à l’aide de la pièce
Arbre_6, un roulement à rouleaux coniques en acier inoxydable, et un palier en bronze
autolubrifiant. L’Arbre_6 est maintenu en rotation dans le poignet à l’aide d’une clavette. La pièce
Couvercle_6 sert de butée en rotation, ce qui permet de limiter la plage d’orientation à 90 degrés.
Figure V-5 : Ensemble poignet
Figure V-6 : Liaison entre le poignet et la structure de l'écran
PFE Nicolas ECK MIQ 5 2011/2012 Page 42
5. Montage des capteurs
Les capteurs d’orientation sont placés à l’extrémité de la pièce Arbre_6. Un accouplement permet
l’entrainement du potentiomètre (en blanc sur la figure V-7). La pièce intermédiaire
Laison_Contact_6 (en rouge) établit le contact avec les microrupteurs (en bleu) lorsque l’ensemble
écran est en butée. La position des microrupteurs est réglable grâce aux galets plastiques (en jaune)
placés sur glissières, pour que le contact corresponde parfaitement à la position en butée.
Afin de répondre au cahier des charges sur le niveau d’étanchéité, les capteurs ont été placés
volontairement à l’intérieur du boitier étanche.
Figure V-7 : Montage des capteurs
6. Montage des éléments électroniques
Le PC embarqué et le moniteur LCD sont assemblés sur la structure à l’aide de leur support respectif.
Ces deux éléments sont montés par l’avant. En effet la coque plastique avant est facilement
démontable. Le support du moniteur dispose de quatre encoches en trou de serrure permettant
d’accrocher le moniteur. Ce type de configuration a été choisi pour limiter les dimensions du coffret
protecteur.
Figure V-8 : Montage du PC et du moniteur
PFE Nicolas ECK MIQ 5 2011/2012 Page 43
B. Calcul du vérin
Le vérin est utilisé pour compenser au mieux le poids de l’ensemble écran, mais sert aussi
d’amortisseur pour limiter la vitesse de déplacement de l’ensemble.
Il s’agit d’un vérin pneumatique de type ressort à gaz ajustable. Un ressort à gaz est un système
hermétiquement clos comprenant un tube sous pression, une tige de piston avec son piston, un gaz
en tant que vecteur d’énergie et de l’huile pour lubrifier le système d’étanchéité. L’énergie du ressort
à gaz est fonction de la compressibilité du gaz inclus dans le vérin. La figure V-9 présente le schéma
de principe de ressort à gaz.
V-9 : Schéma de principe de ressort à gaz
Comme on peut le voir sur la figure V-10, pour un ressort à gaz idéal la modification de la pression
interne du vérin fait varier la force exercée sur le piston du vérin sans modifier la pente de la courbe
caractéristique de la force en fonction de la course. Cette caractéristique permet d’ajuster la pression
du vérin de façon à obtenir une force exercée sur le piston qui compense au mieux le poids du
système.
Figure V-10 : Influence de la pression du gaz dans le vérin
La pente de cette courbe caractéristique est appelée constante de raideur du vérin (x). Elle se calcule
de la sorte :
PFE Nicolas ECK MIQ 5 2011/2012 Page 44
Avec le volume de gaz compressible à l’état sorti :
A l’aide du logiciel Matlab et des formules ci-dessus, on peut déterminer quelle valeur de force doit
exercer le piston sur le pantographe pour compenser le poids du système. Les figures V-11 et V-12
exposent les courbes de résultat. Celles-ci présentent l’évolution d’une force ou d’un moment en
fonction de la position du pantographe, l’angle de 0 degré correspondant à la position horizontale.
Figure V-11 : Comparaison des moments dus au poids et à l'action du vérin
On voit sur la figure V-11 que l’action du vérin compense approximativement celle du poids. La
différence entre les deux devra être fournie par l’utilisateur pour soulever l’écran. D’après la dernière
courbe de la figure V-12, cet effort est de 35 N environ, au maximum. Cependant cette étude est
basée sur le fonctionnement d’un vérin parfait et les résultats restent une approximation.
Figure V-12 : Courbes de résultats
PFE Nicolas ECK MIQ 5 2011/2012 Page 45
C. Calculs de résistance des matériaux
Grâce à l’application Mechanica de Pro/Engineer, toutes les pièces ont pu être simulées en situation
de travail. Cette étude a permis de vérifier la conformité de la conception vis-à-vis du cahier des
charges, et de corriger certaines faiblesses au besoin.
La totalité de l’étude est présentée en annexe. Ci-dessous un exemple de la pièce
Cyl_Support_18mm_6.
Figure V-13 : Efforts et restrictions imposés
Figure V-14 : Résultat de l'analyse
La pièce est en acier inoxydable de limite élastique Re = 320 MPa. Ce qui donne un coefficient de
sécurité minimum d’environ 2,3. Ce qui correspond au cahier des charges, ainsi la conception est
validée.
PFE Nicolas ECK MIQ 5 2011/2012 Page 46
D. Coques
Les coques de protection ainsi que les coques du coffret sont conçues en plastique. Ces éléments
sont destinés à la protection des composants sensibles de la borne, en particulier l’électronique. Le
boîtier doit donc être étanche aux intempéries et au nettoyage comme le prévoit le cahier des
charges. Celui-ci doit respecter un certain nombre de critères.
Matériau : non défini (plastique épaisseur 4 ou 5 mm)
Couleur : gris RAL 7043 (résistant aux produits de nettoyage agressifs)
Etanchéité : équivalent à IP 55
Ce niveau d’étanchéité est demandé pour le joint entre les deux coques et les joints entre chaque coque et sa
plaque transparente respective.
Résistance au choc (coques et plaques transparentes) : 600 J/m
Tolérances générales de fabrication : +/- 0,5 mm
Pour faciliter le montage et la maintenance du système, la coque arrière est vissée sur la structure
interne de l’écran, alors que la coque avant, facilement démontable, est vissée sur la coque arrière.
Les modèles de coques présentés sur les figures V-15 et V-16 ont été soumis à la société Technibox
(voir partie VI.-B.), pour la réalisation.
Figure V-15 : Coques arrière et avant du coffret
Figure V-16 : Coques pantographe et poignet
La trappe dans la coque avant est équipée d’un verrou et permet de dissimuler au public le bouton
d’allumage et de reset de l’ordinateur, ainsi que les ports USB reliés à l’ordinateur.
Figure V-17 : Trappe de la coque avant
PFE Nicolas ECK MIQ 5 2011/2012 Page 47
E. Assemblage
L’assemblage de la borne sur site nécessite un certain nombre d’outils :
Dénomination Tailles
Tournevis plat
Clé plate 6 (M3), 10 (M6), 17 (M10)
Clé à pipe 10 (M6), 17 (M10)
Clé allen 2,5 (M3)
Clé torx T 20 (M4), T 30 (M6)
Niveau à bulle
Le support de la borne sur la place Stanislas est monté sur une embase apposée sur un tampon de la
place non utilisé.
Figure V-18 : Montage du support
La pièce Bras_7 est montée sur le support à l’aide de trois boulons M10. Cet assemblage doit
permettre d’assurer la mise à niveau horizontale à l’aide d’un contre-écrou sur chacune des vis.
La coque du pantographe encadre le mécanisme. Elle doit être assemblée par le haut et les
extrémités de la pièce Arbre_S_Large_6 doivent être glissées dans les deux rainures intérieures de la
coque. Celle-ci est ensuite maintenue par les deux pièces Ecrou_Bloc_Coque_6 au niveau de
l’ensemble poignet, sur la pièce Arbre_P_Fine_6.
Figure V-19 : Montage de la coque du pantographe
PFE Nicolas ECK MIQ 5 2011/2012 Page 48
L’ensemble écran est monté sur le bras articulé à l’aide de la pièce Arbre_6 qui s’insère dans le
poignet.
Figure V-20 : Montage de l'ensemble écran
Le maintien de l’ensemble écran est assuré par une vis M6 à tête fraisée et la pièce
Bouchon_Arbre_6 (en rouge sur la figure V-21).
La coque du poignet s’assemble sur l’ensemble poignet à l’aide de deux vis de sécurité M6.
Figure V-21 : Montage de la coque poignet
PFE Nicolas ECK MIQ 5 2011/2012 Page 49
VI. Fabrication du prototype
A. Usinage
L’usinage de toutes les pièces mécaniques de la borne est réalisé dans les ateliers de l’INSA, avec
l’aide des techniciens de la plate-forme mécanique. Cette décision a été prise pour limiter les retards
engendrés par la sous-traitance.
1. Structure interne du coffret
Figure VI-1 : Structure mécanosoudée
2. Liaison entre le pantographe et le coffret
Figure VI-2 : Eléments d'assemblage
3. Bielle fine
Figure VI-3 : Bielle fine en cours d'usinage
La cote d’entre-axes entre les deux alésages ayant une tolérance d’un dixième de millimètre, les
perçages sont réalisés après la soudure des ronds sur le fer plat.
PFE Nicolas ECK MIQ 5 2011/2012 Page 50
4. Bielle large
Figure VI-4 : Bielle large en cours d'usinage
Comme pour les bielles fines, les perçages sont réalisés après la soudure des ronds sur le fer plat.
5. Arbre de la liaison entre pantographe et coffret
Figure VI-5 : Arbre en cours d'usinage
Afin d’économiser de la matière, l’arbre de liaison est constitué d’un rond en inox et d’une rondelle
en inox soudés l’un sur l’autre. La mise aux cotes se fait après la soudure.
6. Poignet
Figure VI-6 : Ensemble poignet
Après le montage du poignet, les entraxes de celui-ci sont mesurés à l’aide d’une machine à mesurer
tridimensionnelle, pour vérifier que les cotes sont incluses dans les tolérances.
7. Assemblage de l’ensemble écran
Figure VI-7 : Assemblage du poignet et des supports sur la structure
PFE Nicolas ECK MIQ 5 2011/2012 Page 51
B. Fabrication des coques plastiques
Les coques plastiques de protection ainsi que les coques du coffret sont réalisées par la société
Technibox, spécialisée dans la plasturgie sans moule et sur mesure. Plusieurs entreprises ont été
contactées (Atoplast, La Tôlerie Plastique, Okatron) mais seul Technibox a répondu positivement à la
demande.
Mon correspondant à Technibox est M. Gandoin, et les techniciens travaillant sur le projet sont MM.
Hoarau et Richer.
Informations sur la société Technibox :
Z.I des Grandes Vignes
F - 18110 FUSSY
Tél. : 02 48 70 40 74
Fax : 02 48 70 94 21
1. Le coffret
La commande pour l’étude de fabrication du coffret et la réalisation d’un prototype a été passée le
25 mai, sur la base du devis du 16 mai (disponible en annexe).
L’étude de fabrication est réalisée à partir des dessins CAO établis lors de la conception de la borne.
Cette étude a abouti sur un nouveau modèle qui a été validé à la suite de plusieurs échanges avec la
société.
Figure VI-8 : Modèle du coffret final
2. Les coques pantographe et poignet
La commande pour l’étude de fabrication des coques pantographe et poignet et la réalisation d’un
prototype de chaque modèle a été passée le 3 juillet, sur la base du devis du 27 juin (disponible en
annexe).
PFE Nicolas ECK MIQ 5 2011/2012 Page 52
Conclusion
Je retire une grande satisfaction du déroulement de ce projet. Il a répondu à mes attentes de par sa
pluridisciplinarité et son exhaustivité. En effet, j’ai été responsable et acteur de toutes les étapes du
projet, de la définition du cahier des charges et la conception jusqu’à la réalisation physique. De plus,
la variété des domaines étudiés propose différents avantages, à savoir : la mise en synergie de
connaissances variées et la recherche de nouveaux savoirs, ainsi que la possibilité de diversifier les
réflexions. En effet, on peut considérer que ce projet était composé d’un ensemble de « sous-
projets » à mener de front en raison des liens entre eux.
De plus, lors du choix du sujet en début d’année scolaire, je m’étais fixé comme objectif de mener un
projet contenant une étude en électronique et en programmation informatique, domaines que je
n’avais jamais eu l’occasion d’approfondir lors d’un stage ou un projet interne à l’école. J’ai ainsi eu
l’opportunité de satisfaire ma curiosité et d’élargir ma sphère de compétence.
Aussi, en raison du contenu archéologique du projet et mon intégration au laboratoire de
photogrammétrie de l’INSA de Strasbourg, j’ai pu apprécier en partie les disciplines des sciences dites
géographiques telles que la géodésie, la topographie et la photogrammétrie. De plus, j’ai eu la
chance de découvrir une partie du patrimoine de la ville de Nancy.
La réalisation du prototype, en particulier la fabrication des pièces mécaniques, a été plus longue que
les prévisions de la planification des tâches, effectuée au début du projet. Ce retard s’explique en
partie par les difficultés que j’ai rencontrées à l’usinage et mon manque d’expérience dans ce
domaine. Un certain nombre de pièces de la borne devraient être réusinées pour différentes raisons :
- Arbre_S_Large_6 (taraud cassé dans la pièce) quantité : 1
- Cyl_Support_12mm_6 (matériau non conforme) quantité : 2
- Cyl_Couvercle_12mm_6 (matériau non conforme) quantité : 2
- Cyl_Support_18mm_6 (erreur d’usinage) quantité : 1
- Cyl_Couvercle_18mm_6 (erreur d’usinage) quantité : 1
Néanmoins, l’attente de ces corrections n’altère pas le fonctionnement du prototype qui sera en état
d’être utilisé sur site à la réception du coffret et des coques plastiques.
En termes de perspectives pour la suite des travaux, il peut être intéressant de suivre plusieurs pistes
de réflexion. Notamment, il serait profitable d’étudier la possibilité d’alléger la structure interne de
l’écran avec une nouvelle conception et une nouvelle étude de résistance des matériaux. Egalement,
dans le but de perfectionner l’application de réalité augmentée, deux améliorations peuvent être
apportées. La première est l’utilisation d’un potentiomètre doté d’une course entre 90 et 120 degrés,
plus faible que l’existant, pour augmenter le nombre de positions par degré. La seconde est l’achat
d’une nouvelle caméra possédant un nombre d’images par seconde plus important : idéalement, 30
fps pour une résolution de 1 mégapixel par image au format 16/9. Ces deux améliorations devraient
permettre de fluidifier davantage l’affichage du résultat de l’application.
En ce qui concerne l’aspect financier, il reste 7 680 € HT sur les 15 000 € HT de budget initial.
PFE Nicolas ECK MIQ 5 2011/2012 Page 53
En comparaison aux autres stages que j’ai pu effectuer par le passé, celui-ci a été le plus formateur
sur différents points de vue. Malgré ma non-intégration au sein d’une entreprise, comme il est
souvent d’usage lors d’un projet de fin d’études, j’ai été confronté à une démarche industrielle
complète : étude de marché, définition du cahier des charges, conception, prototypage, tests et
validations, etc. Mes travaux ont été validés lors de plusieurs réunions avec le groupe de la Mission
Renaissance et au cours de présentations de mon avancement aux membres du groupe PAGE. J’ai pu
mettre en pratique mes connaissances en programmation de microcontrôleurs, développement
d’applications, et en conception de montages électroniques pour ainsi gagner en expérience dans ces
domaines.
PFE Nicolas ECK MIQ 5 2011/2012 Page 54
Webographie
http://opencv.willowgarage.com/wiki/CodeBlocks
http://www.geckogeek.fr/lire-le-flux-dune-webcam-
camera-video-avec-opencv.html
http://nashruddin.com/OpenCV_Region_of_Interest_(
ROI)
http://www.geckogeek.fr/afficher-une-image-a-fond-
transparent-sous-opencv.html
F.
Fonctionnnement
global
http://www.bibliobsession.net/2011/03/23/comment-
les-bibliotheques-sepuisent-a-rendre-des-forteresses-
seduisantes/
http://arduino.cc/en/Tutorial/HomePage
http://arduino.cc/fr/Main/DebuterInstallationWindow
s
http://www.arduino.cc/playground/Interfacing/CPPWi
ndows
www.roboticus.org
http://www.practicalarduino.com/projects/virtual-usb-
keyboard
https://github.com/practicalarduino/VirtualUsbKeyboa
rd
http://rafale.org/zineonline/online/Rafale16/Rafale16.
06.HTML
http://code.rancidbacon.com/ProjectLogArduinoUSB
http://code.google.com/p/vusb-for-
arduino/downloads/detail?name=vusb-for-arduino-
005.zip&can=2&q=
C. OpenCV
III. Application de
réalité augmentée
A. Carte Capteurs
B. Carte IHM
IV. Cartes
électroniques