Projet de Fin dEtude s - eprints2.insa-strasbourg.freprints2.insa-strasbourg.fr/1182/1/Mecatronique-2012-ECK-memoire.pdf · PFE Nicolas ECK MIQ 5 2011/2012 Page 3 Remerciements Je

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.


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.


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


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.


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.


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


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


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.


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


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.


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


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.


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


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.


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.


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.


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.


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.


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.


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


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 .


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.


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.


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.


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


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.


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)


- 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.


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.


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


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


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


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


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.

http://fr.wikipedia.org/wiki/Outil

http://fr.wikipedia.org/wiki/Machine

http://fr.wikipedia.org/wiki/Microcontr%C3%B4leur

http://fr.wikipedia.org/wiki/Microchip_Technology


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.


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


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


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


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


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


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


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 :


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


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.


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


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


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


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.


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


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

@ : [email protected]

@ : [email protected]

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


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.


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.


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

Documents

Projet de Fin dEtude s - eprints2.insa-strasbourg.freprints2.insa-strasbourg.fr/1182/1/Mecatronique-2012-ECK-memoire.pdf · PFE Nicolas ECK MIQ 5 2011/2012 Page 3 Remerciements Je