Imhof Yannick

cmd
CONCEPTION ET RÉALISATION
D’UN
SCANNER 3D LASER EMBARQUÉ
Travail de Bachelor
Auteur Imhof Yannick

Conseiller Bressy Pierre
Mandant HEIG-VD
Orientation Systèmes embarqués
Période Juillet – septembre 2016
Formation en emploi
Scanner 3D embarqué
Travail de Bachelor Formation en emploi
2 Imhof Yannick
Formation en emploi
Travail de Bachelor
Travail de Bachelor
Préambule
Ce travail de Bachelor est réalisé en vue de l'obtention du titre de Bachelor of Sciences en Ingénierie.
Son contenu, sans préjuger de sa valeur, n'engage ni la responsabilité de l'auteur, ni celles du jury du travail
de Bachelor et de l'Ecole.
Aucune utilisation, même partielle, de ce travail ne peut être faite sans l'autorisation écrite préalable de la
Direction. Toutefois, l'entreprise ou l'organisation qui a confié un sujet de travail de Bachelor peut utiliser les
résultats du travail pour ses propres besoins.
La cheffe du
Département de la formation
En Emploi
L. Larghi
Yverdon-les-Bains, novembre 2015
Imhof Yannick 3
Résumé
Le scanner 3D est un module portatif, monté sur trépied, conçu pour scanner un volume intérieur tel qu’une
salle, une pièce d’appartement ou une grotte, de manière à obtenir les données nécessaires à la création
d’un modèle virtuel.
Outre le module en lui-même, l’architecture du système comprend une centrale de données implémentée
sous la forme d’un service web, et une application cliente permettant de commander le scanner.
Figure 1 - Architecture générale du projet
Un laser, réfléchi par un miroir, est orienté selon deux axes de

rotation. La mesure de la distance en Time Of Flight associée à la
position angulaire de chacun des axes situe un point dans l’espace,
en coordonnées sphériques. L’ensemble de ces points constitue la
surface intérieure du volume scanné.
La mesure de la distance est assurée par un télémètre laser modifié

pour permettre l’acquisition des données par un microcontrôleur.
Ce dernier pilote également l’orientation du laser au moyen de deux
moteurs pas-à-pas.
La centrale relaie les commandes de l’application cliente vers le

scanner. Elle reçoit en retour les données de mesure, en assure le
Figure 2 - Principe de mise en œuvre
stockage et convertit les coordonnées sphériques vers un
référentiel rectangulaire plus classique.
Finalement, elle les transmet à l’application cliente

laquelle reste néanmoins libre de se déconnecter sans
risque de perte de données.
Une fois les données reçues, le client permet d’exporter

les mesures vers un logiciel de traitement 3D.
Figure 3 - Application cliente connectée et en attente
4 Imhof Yannick
Formation en emploi
Travail de Bachelor
Table des matières
Préambule ..........................................................................................................................................................3
Résumé ...............................................................................................................................................................4
Table des matières .............................................................................................................................................5
Introduction........................................................................................................................................................7
Complément aux éléments de la pré-étude ......................................................................................................8
Conception mécanique ..................................................................................................................................8
Composants électroniques et électromécaniques .........................................................................................8
Servomoteur SG51R ...................................................................................................................................8
Schéma électronique ..................................................................................................................................8
Géométrie de l’optique ................................................................................................................................10
Scanner complet...........................................................................................................................................11
Développement logiciel....................................................................................................................................12
Architecture du projet ..................................................................................................................................12
Infrastructure ...............................................................................................................................................13
Outils ............................................................................................................................................................13
Préparation du microcontrôleur Arduino Yùn .............................................................................................14
Mise à jour de l’image système du Yùn ....................................................................................................14
Configuration de la pile réseau OpenWRT ...............................................................................................15
Invalider la réinitialisation automatique de la configuration Wifi ...........................................................17
Obtenir la date courante avec une précision à la nanoseconde ..............................................................18
Configuration préalable du télémètre .........................................................................................................18
Firmware ......................................................................................................................................................19
Mise en œuvre de l’IDE Arduino ..............................................................................................................19
Problème de téléchargement du sketch via Wifi .....................................................................................20
Bus SPI ......................................................................................................................................................21
Gestion des moteurs pas-à-pas ................................................................................................................24
Gestion du télémètre ...............................................................................................................................32
Gestion du servomoteur ..........................................................................................................................34
Schéma de classes ....................................................................................................................................34
Fonctionnalités .........................................................................................................................................37
Centrale ........................................................................................................................................................47
Service Windows ......................................................................................................................................47
Imhof Yannick 5
Service web WCF ..................................................................................................................................... 48

Base de données ...................................................................................................................................... 54
Application cliente ....................................................................................................................................... 55
Vue d’ensemble ....................................................................................................................................... 55
Structure de la solution ........................................................................................................................... 56
Configuration système............................................................................................................................. 57
Exportation des données ......................................................................................................................... 57
Matières à amélioration .................................................................................................................................. 58
Eléments mécaniques .................................................................................................................................. 58
Eléments électromécaniques ...................................................................................................................... 59
Eléments logiciels ........................................................................................................................................ 60
Fonctionnalités ............................................................................................................................................ 60
Conclusion ....................................................................................................................................................... 61
Remerciements................................................................................................................................................ 61
Dossier de gestion ........................................................................................................................................... 62
Rencontres avec M. Bressy .......................................................................................................................... 62
Résumé d’activités ....................................................................................................................................... 62
Authentification ............................................................................................................................................... 64
References ....................................................................................................................................................... 65
Table des illustrations .................................................................................................................................. 65
Documentation ............................................................................................................................................ 67
Annexes ........................................................................................................................................................... 70
Paramétrage détaillé du routeur ................................................................................................................. 70
Connexion via Putty ..................................................................................................................................... 72
Connexion via WinSCP ................................................................................................................................. 73
Exemple de données renvoyées par le LR4 ................................................................................................. 74
Liste des dessins de fabrication ................................................................................................................... 76
Lot de fabrication n°1 .............................................................................................................................. 76
Lot de fabrication n°2 .............................................................................................................................. 76
6 Imhof Yannick
Formation en emploi
Travail de Bachelor
Introduction
Ce document détaille les étapes ayant permis la réalisation d’un scanner 3D laser embarqué, selon le cahier
des charges défini par l’analyse préliminaire du même projet, à laquelle il fait suite.
Quelques considérations viennent compléter et corriger certains des éléments présents dans ladite analyse,
notamment l’ajout du second axe de rotation du module, alors à peine évoqué. Le schéma électronique
s’adapte en conséquence à ces nouveautés, et le système de calibrage, manuel dans le cadre de l’analyse,
est maintenant automatisé.
Le présent document présente de manière succincte les outils utilisés dans le cade de ce projet, et se
concentre sur les aspects propres au développement logiciel. Un accent particulier est donné aux
problématiques rencontrées durant l’implémentation du firmware, par exemple :
 Quelle configuration adopter pour chaque périphérique du bus SPI permettant la communication
avec chacun depuis la carte Arduino Yùn ?
 Quels paramètres définir pour les pilotes de moteur pas-à-pas en vue d’obtenir les meilleures
performances possibles ?
 Quelle stratégie adopter avec le télémètre, dans le cadre de l’acquisition des mesures, dans le but
de conserver, voire optimiser, les vitesses déjà très faibles, définies en analyse ?
 Quel système d’axe choisir dans lequel exprimer les mesures, et comment calibrer le scanner de
manière à s’y conformer ?
 Comment communiquer les données de mesures au monde extérieur ?
Au second plan viennent les questions relatives à la commande du scanner et à la gestion des données, avec
entre autres :
 Quelles sont les commandes auxquelles le scanner doit pouvoir répondre et dans quelles
circonstances ?
 Qui persiste les données, de la centrale ou l’application cliente, et sous quelle forme ?
 Quel doit être le format final des données de mesure ?
Figure 4 - Le scanner 3D réalisé
Imhof Yannick 7
Complément aux éléments de la pré-étude

Conception mécanique
La pré-étude s’est focalisée sur le mouvement rotatif du miroir, selon son axe horizontal, permettant de
scanner l’un des méridiens de la sphère théorique. Mais le système, pour être capable de réaliser un scan
complet, nécessite les éléments permettant sa rotation selon son axe vertical.
Les éléments conçus durant la pré-étude ont donc été complétés par un second moteur, deux poulies de
transmission et une seconde courroie crantée. Les caractéristiques mécaniques de ces nouveaux éléments
sont identiques à celles des précédents, et les deux moteurs sont du même type. Les deux axes peuvent être
pilotés indépendamment l’un de l’autre, mais restent solidaires. Lors de la rotation selon l’axe vertical c’est
donc le module complet qui bouge, reposant sur un ensemble de roulements au sein de la poulie réceptrice,
laquelle constitue la base fixe du système.
Figure 5 - Système de rotation selon l'axe vertical (vu de
Composants électroniques et électromécaniques

Servomoteur SG51R
Le processus de calibrage a été repensé, et le positionnement du gabarit,
prévu manuel à l’origine, est devenu automatique par la mise en œuvre d’un
servomoteur piloté par le firmware.
Le composant choisi est un SG51R de Tower Pro1 de faible encombrement

et sans particularité dans la prise en charge par le firmware.
Schéma électronique
Le complément mécanique, avec l’ajout d’un moteur et du servomoteur du système de calibrage, induit
également la modification du schéma électronique. De plus, malgré l’attention particulière dont ce dernier a
bénéficié durant la pré-étude, il est à noter que certaines erreurs s’y étaient glissées et que certains éléments
se sont avérés manquants durant le développement du firmware.
1
(Micro servo SG51R)
8 Imhof Yannick
Formation en emploi
Travail de Bachelor
Le second moteur est piloté par un second pilote L6470, lequel nécessite son propre chip select (gear CS), et
le servo sera directement piloté depuis le Yùn via une broche compatible avec les signaux PWM (servo cmd).
Le système admet aussi maintenant la possibilité de réinitialiser les périphériques chaînés sur le bus SPI, non
seulement de manière logicielle, mais également via un signal délivré par une broche du Yùn dédiée à cette
tâche (SPI dev rst). Une autre broche permet aux pilotes des moteurs de notifier un problème, comme par
exemple un dépassement de limite de courant (stp flagn).
Figure 6 - Schéma électronique, pilotes des moteurs
Imhof Yannick 9
Deux autres broches seront dédiées à l’écoute d’interruptions permettant d’une part de savoir que les
moteurs ont atteint la position demandée (stp busy), et d’autre part que des données de mesure sont en
attente au niveau du pont SPI-UART de la part du télémètre (uart rx irq).
Ces connexions supplémentaires se prolongent jusqu’au pont SPI-UART, ce qui induit la nécessité de
dédoubler également l’adaptateur de tension TTL, puisque ce dernier n’offre que quatre broches utiles.
Il reste encore à noter la correction de la connectique relative aux signaux Rx/Tx du télémètre, à l’inverse de
ce que spécifiait la pré-étude.
Figure 7 - Schéma électronique, intégration du télémètre
Géométrie de l’optique
La conception mécanique du système dans son ensemble était basée sur l’hypothèse d’un laser émis au
centre de la lentille principale du télémètre. En réalité, le laser est émis en périphérie de cette lentille à tel
point que dès le premier essai, après à peine un quart de cercle de rotation du miroir, le système de fixation
de ce dernier est entrée en conflit avec le laser. Ce dernier n’étant plus réfléchi, le scanner a connu son
premier « trou noir », c’est-à-dire un point où aucune mesure de distance ne peut être réalisée.
Cet événement a bien sûr induit un certain nombre d’adaptations au niveau mécanique :
 Le diamètre du puit de lumière au centre du système a été augmenté

 Le système de fixation du miroir a été modifié pour laisser l’intégralité de la surface réfléchissante à
la disposition du système optique.
10 Imhof Yannick
Formation en emploi
Travail de Bachelor
 Le télémètre a été déplacé de manière à permettre le bon fonctionnement conjoint de l’ensemble

émetteur laser et récepteur.
De manière plus positive, ce problème a également mis en évidence la notion de trou noir citée
précédemment, avec comme suite l’implémentation de la prise en charge et du traitement de ces points par
le firmware et le logiciel client final.
Les dessins de fabrication modifiés selon les nouvelles spécifications sont annexés au présent document.
Scanner complet
Après assemblage des deux systèmes de rotation et ajout des compléments électroniques, le scanner peut
être fixé sur un trépied d’appareil photo standard. Son poids total est de 1.75 kg pour un encombrement de
162/208 x 234 mm, câbles inclus.
Figure 8 - Vue en coupe des éléments mécaniques des axes de rotation
Figure 9 - Scanner 3D complet
Imhof Yannick 11
Développement logiciel
Architecture du projet
Le schéma ci-dessous donne une vue d’ensemble des éléments composant le système et des articulations
qui les lient. Chaque élément est détaillé dans les pages qui suivent.
Figure 10 - Architecture du projet
12 Imhof Yannick
Formation en emploi
Travail de Bachelor
Dans le cadre d’un développement basé sur la carte Arduino Yùn, la particularité se situe dans le fait qu’elle
abrite non seulement le microcontrôleur mais également une déclinaison embarquée du système Linux
intégrant la pile réseau OpenWRT. Dès le démarrage, le système Linux se rend disponible en Wifi selon son
paramétrage courant. Par défaut, la carte se définit en point d’accès Wifi publiant son propre SSID ARDUINO-
YUN90XXXXXX en accès libre à l’adresse 192.168.240.1.
Dans le cadre de ce projet, les valeurs par défaut ne seront utilisées qu’aux premières connexions lors du
paramétrage définitif.
Infrastructure
Comme le précisait la pré-étude, un routeur physique est dédié à la mise en œuvre du réseau Wifi. Ce routeur
est un Netgear N600 gibabit double bande.
Il publie deux SSID :
 SCAN3DG en b/g/n 2.4 GHz

 SCAN3DN en a/n 5.0 GHz
Chacun de ces réseaux masque son SSID et applique un cryptage de sécurité en WPA2-PSK. A noter au final
que, le Yùn n’étant pas compatible avec la bande passante des 5.0 GHz, le SSID SCAN3DN restera inactif.
Le routeur fait également office de serveur DHCP pour son sous-réseau et filtre les accès par adresse
physique. Trois réservations d’adresse existent :
 Interface Wifi des services web : 192.168.24.43

 Interface Wifi du microcontrôleur : 192.168.24.44
 Interface RJ45 du client : 192.168.24.45
Le paramétrage détaillé du routeur est disponible en annexe du présent document.
Outils
Pour pouvoir interagir avec le système Linux embarqué, différents outils sont nécessaires.
 Un terminal de connexion SSH tel que Putty2 permet un accès à la ligne de commande.
 Un outil de déploiement de fichiers tel que WinSCP3 offre une vue graphique de l’arborescence des
fichiers distants, et permet la synchronisation des répertoires.
Des exemples de connexion avec chacun d’eux sont disponibles en annexe du présent document.
Pour pouvoir tester et visualiser les requêtes REST ou SOAP, deux autres outils ont été mis en œuvre :
 SoapUI 4 permet, entre autre, de mémoriser des requêtes REST ou SOAP et d’en visualiser les
réponses données par le service cible.
 Fiddler5 est un sniffer qui permet de visualiser également la structure des requêtes et réponses HTTP.
Tous ces outils sont en libre accès au téléchargement.
2
(PuTTY Download Page)
3
(WinSCP Downloads)
4
(SoapUI homepage)
5
(Fiddler homepage)
Imhof Yannick 13
Préparation du microcontrôleur Arduino Yùn

Le microcontrôleur n’est pas directement utilisable en l’état à sa première mise sous tension. Différentes
étapes de mise à jour et de configuration sont requises pour qu’il puisse s’insérer dans le projet et assurer
son rôle de chef d’orchestre.
Mise à jour de l’image système du Yùn

En ce qui concerne le microcontrôleur, le produit reçu est en fait un fork Linino du Yùn Arduino. Les accès
sont presque identiques, et le mot de passe par défaut, qui lui ne l’est pas, est finalement découvert dans les
pages d’un forum.
Figure 11 - Login du serveur web Linino, mot de passe "doghunter"
Quelques vérifications permettent de constater que la documentation disponible pour le système Arduino
natif semble plus riche et plus facile d’accès. L’image système du Yùn doit donc préalablement être mise à
jour vers la version 1.5.3, dernière version disponible, ainsi que recommandé par sur le site Arduino6,7.
Figure 12 - Mise à jour de l'image du microcontrôleur en ligne de commande
6
(Arduino Yún)
7
(Upgrading the OpenWrt-Yun image on the Yún)
14 Imhof Yannick
Formation en emploi
Travail de Bachelor
La procédure requiert l’utilisation d’une carte SD formatée. L’image doit être téléchargée et placée à la racine
de la carte SD. Une connexion SSH permet ensuite de lancer la commande de mise à jour. Cette procédure
peut aussi être réalisée via l’interface du serveur web.
Une fois la mise à jour réalisée, les différentes interfaces correspondent un peu plus à ce qui était attendu,
et le système va pouvoir être paramétré selon les prérequis du projet.
Figure 13 - Login du serveur web LuCI, mot de passe "arduino"
Figure 14 - Terminal SSH connecté au système Linux du Yùn
Configuration de la pile réseau OpenWRT

Les éléments qui suivent ont été appliqués au paramétrage du système Linux embarqué via l’interface de
configuration web LuCI.
Système général :
 Nouveau mot de passe système : yunscan3d
 Nouveau nom d’hôte plus parlant : YUNSCAN3D
 Synchronisation de l’horloge.
Imhof Yannick 15
Figure 15 - Configuration générale du système Linux
Configuration réseau :
 Désactiver le serveur DHCP pour les deux interfaces.
 Définir les deux interfaces en clients DHCP.
Figure 16 - Configuration DHCP du système Linux
Configuration Wifi :
 Définir l’interface Wifi en client du réseau dédié SCAN3DG
 Clé de cryptage WPA2-PSK:
gxUxD99=t_9,PKkiyTaQvII(8#;PCts6sUoi{W5t$Z94Eb6p2\5!BL"*X}df%z!
16 Imhof Yannick
Formation en emploi
Travail de Bachelor
Figure 17 - Configuration Wifi du système Linux en client
Invalider la réinitialisation automatique de la configuration Wifi

Une option de la configuration d’OpenWRT sur le Yùn implique que ce dernier se donne un délai maximum
d’une minute au démarrage pour se connecter au réseau Wifi. Passé ce délai, une partie de la configuration
est réinitialisée aux valeurs d’usine.
Mais même lorsque le routeur est pleinement opérationnel et le Wifi actif, le system du Yùn nécessite plus
d’une minute pour se connecter, ce qui implique la perte systématique des données de configuration.
Pour remédier à cette situation, il suffit de commenter la ligne « wifi-live-or-reset » du script de démarrage
dans l’onglet system > startup.
Imhof Yannick 17
Figure 18 - Invalider la réinitialisation automatique de la configuration Wifi
Obtenir la date courante avec une précision à la nanoseconde

Busybox, le shell par défaut n’est pas compatible avec l’option standard « %N » de la commande « date » qui
autorise une précision à la nanoseconde. Pour obtenir les nanosecondes, il est nécessaire d’installer le
package « coreutils-date » au moyen des commandes suivantes :
 opkg update
 opkg install coreutils-date
Une seconde commande « date » complète est ensuite disponible dans le répertoire /usr/bin, laquelle est
compatible avec l’option « %N ».
Cette option était attendue afin de permettre la gestion d’un journal d’activité sur le microcontrôleur en
remplacement des messages console. Mais nous verrons que la taille mémoire disponible pour le sketch a
induit certaines restrictions, et si le code source des classes de journalisation est encore disponible, il n’est
ni utilisé, ni compilé.
Configuration préalable du télémètre

Pour rappel, le télémètre est un Flucke 414D modifié avec la carte additionnelle LR4 de Porcupine Labs. Cette
carte offre deux possibilités d’interface avec le télémètre, la plus usitée étant un port USB, et, dans le cas du
scanner, un port série limité aux signaux RX/TX.
La particularité vient du fait que le paramétrage de la carte ne peut être réalisé qu’au moyen du port USB. Le
port série ne donne pas accès à ces options, aucune commande sérielle n’étant définie à cette fin 8 . Le
paramétrage doit donc être réalisé avant l’insertion du télémètre dans le scanner.
L’idée initiale était, dans la séquence d’acquisition des données, d’activer le laser, prendre une unique
mesure, puis désactiver le laser, ceci pour chaque point du volume. Mais force a été de constater par la
pratique que le temps nécessaire au laser pour s’activer, de même que pour se désactiver, varie entre 3 et 5
[s]. Une telle séquence aurait alors induit un temps de 8 à 12 [s] pour une unique mesure.
8
(LR4 Data Sheet 10-11)
18 Imhof Yannick
Formation en emploi
Travail de Bachelor
Afin de garder le temps nécessaire à la prise d’une mesure le plus bas possible, le démarrage du laser et son
arrêt ne sont finalement effectués qu’une unique fois, en début, respectivement en fin, de cycle de scanning,
avec une activité en continu entre ces deux moments.
Le prix de ce choix est une nette perte de maîtrise sur les évènements durant le scanning, où toute la
séquence sera en définitive structurée autour de la prise en charge la plus rapide possible d’un flux de
mesures en continu.
Au final, les paramètres appliqués sont les suivants :
 Les mesures sont réalisées en mètres.

 Les mesures sont délivrées en continu à la fréquence la plus élevée possible.
 Chaque mesure est simple, sans seconde vérification.
 Les erreurs détectées au niveau du LR4 sont filtrées.
 Envoyer toutes les mesures, mêmes identiques.
Figure 19 - Paramétrage de la carte additionnelle LR4
Malgré ce paramétrage tout à fait normal et standard, il faut remarquer que les données reçues sur le port
série peuvent adopter un caractère assez erratique. L’extrait d’un journal de debug en annexe permet de se
faire une idée. Et ce ne sont pas les exemples de code9 fournis par le fabriquant qui auraient pu permettre
de s’y attendre.
Firmware
Mise en œuvre de l’IDE Arduino
L’environnement de développement propre à la plateforme Arduino est en libre accès au téléchargement10
et bénéficie d’un installeur. La dernière version stable au moment de ce travail de Bachelor est la version
1.6.11, et propose des déclinaisons pour chacun des trois principaux systèmes d’exploitation.
9
(LR4 Sample software with source code)
10
(Download the Arduino Software)
Imhof Yannick 19
Si l’installation est simple et rapide, l’environnement n’offre que très peu d’aide au développement. Et à part
les fonctionnalités essentielles de compilation et de transfert du binaire sur le microcontrôleur, il est possible
de formater automatiquement son code selon le principe usuel d’indentation, et de faire vérifier la
compatibilité du code caractère avec le système. Mais celui qui espérait une assistance au code voit ses
attentes quelque peu déçues. En contrepartie, une bibliothèque d’exemples très riche est immédiatement
accessible via l’interface et le néophyte a tout loisir d’essayer de compiler et de tester chaque exemple pour
comprendre comment le système s’articule.
Il est à noter que la configuration par défaut de l’IDE active un compilateur C++11, ainsi que l’atteste la
présence du flag « -std=gnu++11 » dans les options de compilation. Cette observation permet de mieux situer
le cadre de compatibilité de l’IDE avec le langage.
Problème de téléchargement du sketch via Wifi

Si le sketch est téléchargé via Wifi plutôt que par le port micro-USB, l’un des avantages est que le
téléchargement ainsi que la mise à jour des fichiers web sont pris en charge par l’IDE Arduino (contenu du
sous-répertoire « www » dans le répertoire du sketch).
Lors du téléchargement, la signature du microcontrôleur est vérifiée. Au moment de ce contrôle, le bus SPI
est utilisé, et une réponse inadéquate, sur la broche MISO en particulier, induit un échec lors du transfert
avec un message AVR device not responding :
Figure 20 - Erreur au téléchargement du sketch via Wifi
Dans le cas du scanner 3D, le bus SPI est connecté à une série de périphériques, et le problème apparaît. Le
côté déroutant vient du fait qu’en débranchant une partie des périphériques du bus SPI, depuis le second
pilote de moteur, le transfert s’effectue sans problème. Par acquis de conscience, le fonctionnement du Yùn
a été vérifié sur la base d’une procédure définie par un forum11 référençant le même problème.
Figure 21 - Procédure de vérification de la tension délivrée par la broche MOSI
11
(avrdude - not responding & other problems)
20 Imhof Yannick
Formation en emploi
Travail de Bachelor
Mais au final, la broche MOSI du Yùn utilisé pour ce projet donne la tension attendue de 5V, et le problème
reste sans vraie solution, à part le transfert du sketch via le port micro-USB et un transfert manuel des fichiers
web.
Bus SPI
Comme l’illustre le schéma électronique, si le Yùn est le cerveau du système, le bus SPI n’est rien de moins
que son épine dorsale, faisant le lien entre le Yùn et tous les périphériques, excepté le servomoteur.
Le SPI12 est un bus de communication série synchrone utilisé pour le transfert de données sur une courte
distance, ayant la faveur particulière des systèmes embarqués. La communication est en full-duplex selon
une architecture maître-esclave. Dans le cas du scanner, les périphériques sont connectés en mode
indépendant.
Figure 22 - Schéma de connexion SPI repris de Wikipedia
Le maître initie la communication en définissant sur le bus trois paramètres avec les valeurs attendues par
l’esclave ciblé. Ces paramètres sont :
 la fréquence de l’horloge
 l’ordre dans lequel transmettre les bits
 le mode de transmission
L’ordre dans lequel transmettre les bits revient à dire quel bit, du plus significatif ou du moins significatif,
doit être envoyé et/ou lu en premier. Généralement, le bit le plus significatif est transmis en premier.
Le mode de transmission est composé de la polarité de l’horloge CPOL et de la phase de l’horloge CPHA :
 Pour une polarité CPOL = 0, le bus est actif à l’état logique haut, et en attente à l’état logique bas :
o Pour une phase CPHA = 0, les données sont échantillonnées sur le flanc montant et envoyées
sur le flanc descendant.
o Pour une phase CPHA = 1, les données sont échantillonnées sur le flanc descendant et
envoyées sur le flanc montant.
12
(Serial Peripheral Interface Bus)
Imhof Yannick 21
 Pour une polarité CPOL = 1, le bus est actif à l’état logique bas, et en attente à l’état logique haut :
o Pour une phase CPHA = 0, les données sont échantillonnées sur le flanc descendant et
envoyées sur le flanc montant.
o Pour une phase CPHA = 1, les données sont échantillonnées sur le flanc montant et envoyées
sur le flanc descendant.
Figure 23 – Diagramme séquentiel du bus SPI

CPHA = 0 en rouge, CPHA = 1 en bleu
L’environnement Arduino met à disposition une bibliothèque SPI.h dédiée à la communication sur le bus SPI.
Cette bibliothèque intègre une classe SPISettings, laquelle rassemble les trois paramètres en un unique
conteneur logique. Deux constantes prédéfinies, MSBFIRST et LSBFIRST, donnent l’ordre de transmission, et
quatre autres permettent le paramétrage aisé du mode13 :
Figure 24 - Constantes Arduino pour la librairie SPI
Au final, les valeurs de ces trois paramètres sont définies par les spécifications de chacun des périphériques
et ne varient pas durant l’exécution du programme.
ST L6470 – pilote de moteur pas-à-pas

Le L6470 admet une fréquence de communication maximum de 5 [MHz]. Le mode de transmission demande
que le bit le plus significatif soit transmis en premier dans les deux sens. A l’écriture, les données du registre
SDI sont échantillonnées par le pilote sur le flanc montant de l’horloge, et en lecture, les données peuvent
être lues dans le registre SDO sur le flanc descendant, avec un bus actif à l’état logique bas14.
13
(SPI library)
14
(L6470 ch. 8 – p. 38)
22 Imhof Yannick
Formation en emploi
Travail de Bachelor
Figure 25 - Diagramme séquentiel SPI du L6470
 Fréquence d’horloge : 5'000'000 [Hz]

 Ordre de transmission : MSBFIRST
 Mode de transmission : SPI_MODE3
A noter que le L6470 demande que le signal CS soit maintenu à l’état logique haut (inactif) pendant un
minimum de 800 [ns] après la lecture/écriture de chaque octet de manière à décoder la commande et
renvoyer la réponse lors du transfert suivant. Le côté full duplex de la communication devient dès lors un peu
plus circonstanciel.
SC16IS750 – pont SPI – UART

Le SC16IS750 admet une fréquence de communication maximum de 400 [kHz]. Le mode de transmission
demande que le bit le plus significatif soit transmis en premier. A l’écriture, les données du registre SI sont
échantillonnées par le pilote sur le flanc montant de l’horloge, et en lecture, les données peuvent être lues
dans le registre SO sur le flanc descendant, avec un bus actif à l’état logique haut 15.
Figure 26 - Diagramme séquentiel SPI du SC16IS750
15
(SC16IS740/750/760 ch. 11 – p. 43)
Imhof Yannick 23
 Fréquence d’horloge : 400'000 [Hz]

 Ordre de transmission : MSBFIRST
 Mode de transmission : SPI_MODE0
Le SC16SI750 propose un mode de lecture en FIFO ininterrompu, et, au contraire du L6470 n’impose pas une
modification du signal CS à chaque octet.
Gestion des moteurs pas-à-pas

Généralités
Un moteur pas-à-pas transforme une impulsion électrique en mouvement de rotation. Un noyau
magnétique, le plus souvent un aimant permanent, s’oriente selon le mouvement d’un champ magnétique
tournant, généré par un certains nombres d’électroaimants, et suivant une séquence déterminée en vue de
provoquer la rotation.
Figure 27 - Les phases d'un moteur pas-à-pas bipolaire en mode « full step »
Le nombre de pas de rotation est déterminé par construction, et les moteurs à aimant permanent peuvent
compter jusqu’à 48 pas dans le cas des moteurs de style can stack16.
Figure 28 - Moteur pas-à-pas construit selon le style "can stack"
La séquence de pilotage des électroaimants détermine le sens de rotation du moteur, et selon le type de
construction, peut permettre la création de demi-pas de positionnement.
La période du cycle influence la vitesse du moteur et par extension son comportement général (glissement
par perte de pas, vibrations, bruit).
16
(Stepper Motors)
24 Imhof Yannick
Formation en emploi
Travail de Bachelor
La tension aux bornes de ces mêmes bobines influence le couple fourni par le moteur, et par voie de
conséquence, en fonction de la charge, définit l’accélération et la décélération maximum admissibles, ainsi
que son taux d’échauffement.
Ce sont-là les principes de base, qui exposés aussi succinctement, peuvent donner à penser que la gestion
d’un moteur pas-à-pas relève de l’évidence. Mais il n’en est rien, et la lecture de notes telles que celles de
Sorin Manea (Microchip)17 permet d’en prendre la mesure, et d’admettre que c’est un sujet qui aurait à lui
seul pu faire l’objet de ce travail de bachelor.
En conséquence, c’est le développement de pilotes hardware dédiés comme le L6470 qui a permis l’essor
des moteurs pas-à-pas, au détriment de leurs prédécesseurs, les servomoteurs, dans tout système qui
nécessite un contrôle de vitesse ou de positionnement. Globalement, le moteur pas-à-pas bénéficie
d’avantages non négligeables comme une relative simplicité de mise en œuvre, une bonne précision, un
couple correct à des vitesses modérées et un faible coût. Les servomoteurs restent en lice dès qu’une charge
importante s’associe à une accélération importante. Les pilotes dédiés facilitent donc grandement la gestion
d’un moteur pas-à-pas et offrent en particulier la possibilité de générer le courant d’alimentation des bobines
en respectant une approximation de la sinusoïde d’un courant alternatif. Ce procédé est communément
appelé microstepping, et permet au moteur d’adopter un comportement plus doux en phase d’accélération
ou de décélération tout en évitant les pics de courant présents dans un signal carré.
Figure 29 - Activation du microstepping pour le L6470
17
(Stepper Motor Control with dsPIC DSCs)
Imhof Yannick 25
Moteur PG35S-D48-HHC2
Le type de moteur utilisé pour le scanner est un bipolaire à aimants permanents alimenté en courant continu
à une tension de 24 [V]18.
Figure 30 - Spécifications du type de moteur
Ce moteur a de base 48 pas de rotation, lesquels, associés à un réducteur 1/35.4, permettent d’obtenir 1698
pas de rotation, tout en offrant un couple de transmission relativement élevé pour ce type de matériel.
Figure 31 - Caractéristiques du couple délivré et du courant consommé en fonction de la vitesse
Les caractéristiques à retenir sont :
 Tension d’alimentation : 24 [V]

 Résistance de bobine 8 [Ω]
 Inductance de bobine 7 [mH]
 Constante de force électromotrice (inconnue) [V * rad/s]
18
(Standard PG Step Motors)
26 Imhof Yannick
Formation en emploi
Travail de Bachelor
Configuration du L6470
Selon ce qui précède, faire fonctionner un moteur pas-à-pas sans pilote dédié n’est pas une mince affaire. Et
derrière l’idée d’utiliser le L6470, se profilait l’espoir de simplicité et de facilité d’accès. La réalité est tout
autre et, il est dès lors difficile d’imaginer le niveau réel de difficulté d’une implémentation sans pilote
lorsqu’on prend conscience de celui que l’on rencontre avec un pilote.
Le L6470 intègre un nombre impressionnant de paramètres permettant aussi bien d’optimiser que de
personnaliser le comportement du moteur piloté. Dans le cadre de ce projet, plusieurs tentatives ont été
menées afin d’atteindre les performances mises en avant par les spécifications du type de moteur choisi,
comme par exemple une vitesse maximum de 2100 [pps] (~ 1.27 s-1 compte tenu du réducteur). Mais force
est de reconnaître que cela n’a pas été possible, ni même d’appliquer les éléments de calcul exposés par la
documentation technique19.
Selon les circonstances, le moteur commençait à vibrer tout en émettant des bruits pour le moins
inquiétants. Des échauffements très importants ont pu être constatés, ainsi que des arrêts brutaux suite à
un dépassement de courant maximum. A l’inverse, il est également arrivé que le moteur ne démarre pas, ou
tourne à un rythme très ralenti, comme hésitant. A noter également qu’il n’a pas été possible de faire
fonctionner le moteur en mode full step, à moins d’invalider la protection contre le dépassement de courant
ou de s’en tenir à des vitesses très faibles. Ces échecs ne sont pas tous détaillés, et leur origine n’a pas pu
être précisément déterminée faute de temps, mais la compatibilité entre le moteur et le pilote choisis est
peut-être en cause.
Exemple de calcul manuel pour les valeurs KVAL_x :

La documentation technique donne les relations suivantes :
𝑉𝑂𝑈𝑇 𝐼𝑝𝑘 ∙ 𝑅
0 < 𝐾𝑉𝐴𝐿 = = ≤1
𝑉𝑆 𝑉𝑆
0 < 𝐾𝑉𝐴𝐿 = [(𝐾𝑉𝐴𝐿𝑥 + 𝐵𝐸𝑀𝐹𝑐𝑜𝑚𝑝 ) ∙ 𝑉𝑆𝑐𝑜𝑚𝑝 ∙ 𝐾𝑡ℎ𝑒𝑟𝑚 ] ∙ 𝜇𝑠𝑡𝑒𝑝 ≤ 1
 𝐾𝑉𝐴𝐿𝑥 : paramètre dont on cherche à définir la valeur

 𝐼𝑝𝑘 : courant de pic désiré 400 [mA] à 900 [step/s]
 𝑉𝑆 : tension d’alimentation des moteurs 24 [V]
 𝑅 : résistance de bobine 8 [Ω]
 𝐵𝐸𝑀𝐹𝑐𝑜𝑚𝑝 : compensation de la réaction électromotrice
 𝑉𝑆𝑐𝑜𝑚𝑝 : compensation d’alimentation du moteur 1 (sans compensation)
 𝐾𝑡ℎ𝑒𝑟𝑚 : coefficient de compensation thermique 1 (sans compensation)
 𝜇𝑠𝑡𝑒𝑝 : nombre de micro-steps composant un step 128
19
(L6470 34 - Ch 7)
Imhof Yannick 27
Déterminer le coefficient 𝐵𝐸𝑀𝐹𝑐𝑜𝑚𝑝 maximum :
Figure 32 - Déterminer le coefficient BEMF maximum
La documentation technique donne les valeurs par défaut suivantes :
 Taux de croissance initial ST_SLP = 0x19 25 ∙ 0.000015 = 0.000375 [s/step]

 Taux de croissance final FN_SLP_ACC = 0x29 41 ∙ 0.000015 = 0.000615 [s/step]
 Vitesse de palier intermédiaire INT_SPEED = 0x4080 1032 ∙ 0.0596 = 61.5072 [step/s]
 Vitesse maximum MAX_SPEED = 0x39 57 ∙ 15.25 = 869.25 [step/s]
𝐵𝐸𝑀𝐹𝑐𝑜𝑚𝑝 = 0.000375 ∙ 61.5072 + (869.25 − 61.5072) ∙ 0.000615 = 0.5198 [−] = 52 %
En conséquence :
𝐾𝑉𝐴𝐿 𝐼𝑝𝑘 ∙ 𝑅
𝐾𝑉𝐴𝐿𝑥 = − 𝐵𝐸𝑀𝐹𝑐𝑜𝑚𝑝 = − 𝐵𝐸𝑀𝐹𝑐𝑜𝑚𝑝
𝜇𝑠𝑡𝑒𝑝 ∙ 𝑉𝑆𝑐𝑜𝑚𝑝 ∙ 𝐾𝑡ℎ𝑒𝑟𝑚 𝑉𝑆 ∙ 𝜇𝑠𝑡𝑒𝑝 ∙ 𝑉𝑆𝑐𝑜𝑚𝑝 ∙ 𝐾𝑡ℎ𝑒𝑟𝑚
0.4 ∙ 8
𝐾𝑉𝐴𝐿𝑥 = − 0.5198 = −0.5188 [−]
24 ∙ 128 ∙ 1 ∙ 1
En admettant que le déroulement mathématique, ainsi que les valeurs appliquées, soient corrects, cette
dernière valeur est peut-être exacte mathématiquement parlant, mais ne peut en aucun cas être définie
physiquement.
Exemple de calcul automatique pour les valeurs KVAL_x :

Un second document technique20 aurait pu permettre d’aller plus loin dans la voie mathématique, mais les
relations se basent en partie sur la constante de force électromotrice du moteur, valeur inconnue pour le
type de moteur choisi. En contrepartie, ledit document fait référence à un outil d’optimisation et de
configuration pour le L6470 disponible chez ST Microelectronics21, lequel se base malheureusement sur la
même constante.
20
(Voltage mode control operation and parameter optimization)
21
(Evaluation software with graphical user interface for STSPIN motor driver ICs)
28 Imhof Yannick
Formation en emploi
Travail de Bachelor
Partant des données techniques du moteur relatives au couple en fonction de la vitesse, et d’une méthode
de calcul22 confirmée par les relations qui suivent23, le calcul d’une pseudo-constante de force électromotrice
a pu être tenté.
𝑀𝑚 = 𝐾𝑡 ∙ 𝐼(𝑡) et 𝐾𝑒 = 𝐾𝑡
Avec
 𝑀𝑚 : couple moteur [Nm]

 𝐼(𝑡) : courant [A]
 𝐾𝑡 : constante de couple [Nm/A]
 𝐾𝑒 : constante de force électromotrice [V * rad/s]
𝑓 300 600 900 1200 1500 1800 2100

𝑀𝑚 0.6277 0.5688 0.5492 0.5492 0.5296 0.4413 0.3923
𝐼 0.3320 0.3670 0.4000 0.4220 0.4420 0.4490 0.4400
𝐾𝑒 = 𝐾𝑡 1.8905 1.5499 1.3730 1.3014 1.1981 0.9829 0.8915
Comme chacun peut le constater, le caractère constant de 𝐾𝑒 n’est pas des plus évident. En désespoir de
cause, c’est la moyenne de ces valeurs qui sera utilisée :
𝐾𝑒 = 1.3124
Mais au final, il semble que les caractéristiques de ce type de moteur ne sont que difficilement prises en
charge par le pilote :
Figure 33 - Outil de configuration automatique de la compensation BEMF
22
(Reading the motor constants from typical performance characteristics)
23
(Moteur à courant continu)
Imhof Yannick 29
Les outils mathématiques ayant échoué, les valeurs des paramètres adoptées ci-après ont été définies par
voie empirique et itérative, en ayant préalablement posé les hypothèses suivantes :
 Le L6470 intègre un mécanisme de protection automatique où le moteur est brutalement stoppé et

maintenu en position lorsqu’un dépassement de courant maximum est détecté. La configuration doit
activer cette option, qui accessoirement protégera également le système dans le cas où le câble
d’alimentation entraverait le mouvement.
 Le moteur doit pouvoir fonctionner sans vibration ni bruit suspects, quels que soient les mouvements
imposés par la commande.
 Le moteur doit être maintenu dans un état d’échauffement acceptable, admis comme légèrement
sensible à température ambiante, en fonctionnement comme à l’arrêt.
Ces règles ont conduit au paramétrage suivant :
 Le microstepping est activé à sa valeur maximum de 128 [µsteps]

 Le moteur demande 250 [mA] en régime normal et 500 [mA] lors des pics. Les options du L6470, en
termes de protection contre le dépassement de courant, proposent 375 [mA] ou 750 [mA]. La
première valeur est trop restrictive et ne permet pas d’atteindre les meilleures performances. Le
choix se porte donc sur 750 [mA] compte tenu des règles qui précèdent.
 Les différents seuils de vitesses sont les suivants :
o Vitesse minimum 105 [step/s]
o Vitesse d’activation automatique du mode full step : 847 [step/s]
o Vitesse maximum (~ 0.51 s ) -1
870 [step/s]
 L’optimisation dans les vitesses faibles est activée (entre 0 et 105 [step/s])
 Les coefficients de régulation de la tension aux bornes des enroulements sont les suivants :
o A l’arrêt 6% de Vs
o En régime continu 6% de Vs
o En phase d’accélération 12% de Vs
o En phase de décélération 12% de Vs
 Les paramètres du profil d’accélération, de décélération et de compensation de la réaction
électromotrice sont laissés à leurs valeurs par défaut.
 L’horloge interne de 16 [MHz] fait référence et n’est pas répercutée en sortie.
 La fréquence de modulation PWM est à sa valeur maximum 62.5 [kHz]
 Le taux d’augmentation de la tension aux enroulements est au minimum 75 [V/µs]
 Le dépassement de courant stoppe le moteur.
 Par construction de la carte, pas de compensation de tension d’alimentation du moteur.
30 Imhof Yannick
Formation en emploi
Travail de Bachelor
Par curiosité, ces valeurs ont été introduites dans l’outil de configuration automatique et donnent la courbe
de compensation suivante :
Figure 34 - Compensation BEMF résultante
Commandes et gestion
Une fois le paramétrage du profil de vitesse réalisé et relativement correct, la gestion du moteur devient
effectivement simple. Le L6470 gère en temps réel une position angulaire absolue. La seule particularité vient
du fait que si le microstepping est actif, cette position correspond à un nombre de microsteps depuis l’origine
angulaire. Un signal BUSY permet de connaître le moment auquel le déplacement est terminé, et un second
signal FLAG informe qu’un problème est survenu.
Le registre dédié à la position a une taille de 22bits et accepte une plage allant de -221 à +221-1. Il est accessible
aussi bien en lecture qu’en écriture, à la condition que le moteur soit arrêté. Le moteur admet 1’698 steps
de progression, et le pilote définit 128 µsteps intermédiaires. En conséquence, un tour complet du moteur
demande 217’344 µsteps. Cette valeur doit encore être doublée du fait de la réduction induite par le système
de transmission par courroie crantée, soit 434'688 µsteps.
Cette valeur de position est utilisée par la commande goTo, laquelle définit automatiquement le
déplacement incrémental nécessaire à atteindre une nouvelle position absolue. Le sens de rotation peut être
laissé à l’appréciation du pilote (chemin minimum optimal) ou imposé. Dans le premier cas, la notion
d’optimisation semble un peu surfaite étant donné que pour revenir à l’origine après avoir parcouru deux
tours le pilote refait effectivement les deux tours en sens inverse. Dans le second cas, il faut être prudent,
puisque par exemple retourner à l’origine depuis la position 1000 en imposant un sens positif, va induire un
déplacement infini.
Ajoutons encore la commande goHome permettant de revenir à l’origine et, concernant les déplacements,
tous les outils nécessaires à l’implémentation du scanner sont définis.
Connectique
Concernant le câblage, outre les éléments relatifs au bus SPI, les pilotes de moteur utilisent les broches
suivantes sur le microcontrôleur Yùn.
Imhof Yannick 31
Broche 3 – signal BUSY

La broche 3 est dédiée à l’écoute du signal BUSY des moteurs. Le design du chip et de la carte permettent de
n’utiliser qu’une unique broche pour être informé de l’état d’occupation des pilotes. Au niveau du
microcontrôleur, la broche est liée à un gestionnaire d’interruption sur le flanc montant, qui signale que tous
les déplacements en cours sont terminés.
Broche 5 – signal FLAG

Les moteurs peuvent rencontrer différents problèmes au cours des mouvements. Un registre de statut
rassemble toutes les causes d’alarme possibles et un flag unique est activé lorsque l’une des alarmes est
présente dans le registre. La broche 5 est à l’écoute de ce flag. Etant donné que les moteurs gèrent
automatiquement les cas les plus graves (dépassement de courant) en figeant le mouvement à la position
courante, il n’y a pas de nécessité de gestion via une interruption.
Broche 6 – signal RESET

La broche 6 permet de réinitialiser les pilotes aux valeurs par défaut des registres (power ON state). Cette
broche est partagée par tous les périphériques du bus SPI.
Broche 9 – signal CS du pied

La broche 9 sélectionne sur le bus SPI le moteur affilié aux mouvements de rotation du module complet (axe
vertical).
Broche 10 – signal CS du miroir

La broche 10 sélectionne sur le bus SPI le moteur affilié aux mouvements de rotation du miroir (axe
horizontal).
Gestion du télémètre
Commandes de la carte d’acquisition, le LR4
Le télémètre, interrogé depuis le microcontrôleur via le port série du LR4, n’offre pas de grande particularité.
Le port série doit être configuré avec une vitesse de 9600 bauds, pour une taille de mot de 8 bits, sans parité
et 1 bit de stop.
Le LR4 n’est capable d’interpréter que trois commandes24 :
 Le caractère « g » démarre les mesures en mode continu.

 Le caractère « s » stoppe les mesures.
 Le caractère « i » renvoie les éléments d’identification de la carte (fournisseur, n° de série, etc.)
La réception d’une commande est quittancée par une chaîne « ok » si ladite commande correspond à l’un
des deux premiers caractères précités. Sinon, pour tout autre élément que le « i », une chaîne « badcmd »
est renvoyée.
Les données de mesure sont formatées en chaînes d’une longueur systématique de sept caractères dont les
cinq premiers constituent la mesure en elle-même exprimée en millimètres, et les deux derniers font office
de séparateur adoptant le format standard Linux du retour de ligne « \r\n », ou en ASCII, un caractère 13
(0xD) suivi d’un caractère 10 (0xA).
Exemple : « 12345\r\n » équivaut à 12.345 [m]
24
(LR4 Data Sheet)
32 Imhof Yannick
Formation en emploi
Travail de Bachelor
Ces éléments constituent la base prévisible du comportement du LR4, mais comme évoqué précédemment,
les données reçues peuvent adopter un autre format beaucoup plus difficile à anticiper et à gérer.
En particulier dans la phase de démarrage du laser, il arrive que tous les digits d’une même mesure soient
des caractères « 0 » (0x30), ou plus ennuyeux, que le buffer de réception du port série soit presque
instantanément saturé de ces mêmes caractères.
Configuration du SC16IS750
Au même titre que le L6470, le pont SPI-UART SC16IS750 offre beaucoup d’options de configuration. Mais
les capacités limitées de son client, le LR4, en invalide une bonne partie. La particularité du chip relève du
fait que certains registres ne sont accessibles qu’en fonction de valeurs présentes dans d’autres et dès lors
la séquence d’affectation des registres doit obéir à un ordre logique.
Différentes interruptions, selon différentes priorités, sont disponibles, en fonction des éléments de
transmission mais également des erreurs à traiter. En particulier, l’interruption programmable en fonction
du nombre de caractères reçus dans le FIFO RX est intéressante. Mais la résolution, en octets, de cette
interruption est un multiple de 4, alors que, comme nous l’avons vu, la taille d’une mesure renvoyée par le
LR4 est de 7 octets. En guise de sécurité, si la quantité de données reçues reste inférieure au niveau de
déclanchement paramétré, imaginons ce dernier défini à 8 caractères par exemple, le SC16IS750 génère alors
une autre interruption déclenchée par un timeout équivalent au temps nécessaire à la réception de 4
caractères. Donc le choix est posé, et après divers essais visant à définir l’option avec la meilleure réactivité,
le niveau de déclanchement est fixé à 4 caractères, chaîné avec une attente active des 3 caractères
manquants. Accessoirement, une interruption est également générée lors du retour à un état où toutes les
interruptions en attente ont été traitées, et qu’il faudra filtrer.
La vitesse de transmission est fonction de la fréquence de l’horloge embarquée, qui est, dans le cas présent,
de 14.7456 [MHz]. Le diviseur de fréquence est défini comme suit25 :
𝑐𝑟𝑦𝑠𝑡𝑎𝑙 𝑖𝑛𝑝𝑢𝑡 𝑓𝑟𝑒𝑞𝑢𝑒𝑛𝑐𝑦 14745600
𝑝𝑟𝑒𝑠𝑐𝑎𝑙𝑒𝑟 1
𝑑𝑖𝑣𝑖𝑠𝑜𝑟 = = = 96 = 0𝑥60
𝑑𝑒𝑠𝑖𝑟𝑒𝑑 𝑏𝑎𝑢𝑑 𝑟𝑎𝑡𝑒 ∙ 16 9600 ∙ 16
Les octets de poids fort et faible de ce diviseur sont chargés respectivement dans les registres DLL et DLM.
En accord avec ce qui précède et les éléments attendus par le LR4, les options suivantes sont appliquées :
 Le contrôle de flux est désactivé, en particulier le RTS/CTS.

 La détection de caractères spéciaux est désactivée.
 Les options avancées sont activées (pour permettre l’utilisation des interruptions).
 Le niveau de déclanchement de l’interruption relative au FIFO de réception est fixé à 4 caractères.
 Les données seront transmises sur 8 bits, sans parité et un unique bit de stop.
 Le mode de transmission en FIFO est activé.
Connectique
Concernant le câblage, le pont SPI-UART étant l’un des périphériques connectés au bus SPI, il partage une
partie de son câblage avec les pilotes des moteurs, et s’octroie quelques broches supplémentaires sur le
microcontrôleur Yùn.
25
(SC16IS740/750/760)
Imhof Yannick 33
Broche 2 – signal de présence de données dans le FIFO

La broche 2 est dédiée à l’écoute d’un signal d’interruption en provenance du pont SPI-UART. Au niveau du
microcontrôleur, la broche est liée à un gestionnaire d’interruption sur le flanc descendant. Ce signal est
générique et différentes interruptions internes du pont peuvent en être l’origine. Un registre de statut
permet de connaître et traiter les différentes causes.
Broche 6 – signal RESET

La broche 6 permet de réinitialiser le pont SPI-UART aux valeurs par défaut des registres (power ON state).
Cette broche est partagée par tous les périphériques du bus SPI.
Broche 8 – signal CS
La broche 8 active la communication avec le pont SPI-UART sur le bus SPI.
Gestion du servomoteur
Généralités
Un servomoteur peut être comparé à un moteur pas-à-pas en ce sens qu’il se destine à la gestion d’un
système asservi de positionnement. Selon le domaine d’utilisation (hydraulique, modélisme, prototypage,
etc.) la taille d’un servomoteur peut être très variable, de même que le niveau de charge et le type de
mouvement généré (fraction de tour, multitours, déplacement linéaire)26.
Dans le cas de ce projet, le servomoteur utilisé doit permettre la

mise en œuvre automatique du gabarit de calibration pour le calcul
de la position d’origine du miroir. Il s’agit d’un asservissement
simple de positionnement angulaire.
Un tel servomoteur, outre son alimentation, reçoit un signal PWM

dont la largeur d’impulsion est proportionnelle à la position
angulaire désirée. Le signal est répété généralement à une
fréquence de 50 [Hz], si bien que l’électronique du servomoteur
vérifie et adapte continuellement la position courante. Figure 35 - Signal PWM à destination d'un
servo
Configuration du SG51R
Ce type de composant ne demande aucune configuration particulière. Les consignes de positionnement sont
définies empiriquement et mémorisées dans des constantes.
Connectique
Le signal de commande PWM, nécessaire au servomoteur, est directement par le microcontrôleur Yùn, sur
une broche compatible avec ce type de signal.
Broche 11 – signal PWM du servomoteur

La broche 11 est dédiée à l’émission du signal PWM de commande du servomoteur.
Schéma de classes
Le langage de programmation étant le C++, le firmware est structuré en différentes classes.
Chaque périphérique matériel piloté bénéficie de sa classe propre. Les périphériques connectés au bus SPI
ont clairement une base de fonctionnalités commune, lesquelles ont été rassemblées dans une classe
parente.
26
(Servomoteur)
34 Imhof Yannick
Formation en emploi
Travail de Bachelor
Ces classes de gestion de matériel offrent leurs services au système de gestion des fonctionnalités, lequel
bénéficie également de sa propre classe.
Le code est structuré en différents fichiers, chaque classe étant définie dans son propre fichier d’en-tête et
implémentée dans le fichier source associé.
Figure 36 - Schéma de classes du firmware (signatures masquées)
Par ailleurs, le système Arduino met à disposition du développeur bon nombre de classes de gestion bas
niveau dont les classes décrites ci-après tirent parti.
A noter également que l’implémentation s’est fortement inspirée des exemples disponibles dans le domaine
public, que ce soit dans les forums de développement, la littérature Sparkfun, ou surtout Arduino, en
particulier les éléments relatifs à la communication entre les deux mondes hébergés par la carte Arduino
Imhof Yannick 35
Yùn, la bibliothèque Bridge 27 . Les liens vers les références principales sont disponibles dans la table de
documentation.
BaseSpiDevice
La classe BaseSpiDevice est la classe de base pour tous les périphériques connectés au bus SPI.
Elle rassemble les propriétés nécessaires à la configuration du bus propre au périphérique, ainsi que les
méthodes de transfert de données sur le bus, et utilise à cette fin la bibliothèque SPI d’Arduino. C’est une
classe abstraite qui laisse à ses héritiers le soin d’implémenter leurs spécificités en termes de configuration
et d’initialisation.
Le signal RESET étant partagé par tous les périphériques du bus SPI, il est accessible par des méthodes de
classe présentes dans chaque héritier. La réinitialisation logicielle, quant à elle, est propre à chaque instance.
SpiStepperDriver
La classe SpiStepperDriver hérite de BaseSpiDevice, et offre les fonctionnalités de gestion propre au moteur
au moyen d’une interface de communication transparente avec le L6470.
Cette classe est instanciée deux fois pour permettre le paramétrage et la gestion des moteurs
indépendamment l’un de l’autre.
Les signaux BUSY et FLAG étant partagés par les deux instances, ils sont accessibles par des méthodes de
classe, en particulier le statut de l’interruption BUSY qui par nécessité doit être accessible au gestionnaire de
l’interruption.
SpiRangeFinder
La classe SpiRangeFinder hérite de BaseSpiDevice, et offre les fonctionnalités de gestion propre au télémètre.
Elle reprend à son compte toute la gestion de la chaîne de communication avec le LR4, via le pont SPI-UART
et les adaptateurs de tension.
Le signal d’interruption signalant des données en attente est défini en propriété de classe, là aussi pour être
accessible au gestionnaire de l’interruption.
ServoDriver
La classe ServoDriver utilise la bibliothèque Arduino Servo28, et hérite de la classe du même nom.
Elle encapsule simplement les constantes des deux positions extrêmes du composant et le numéro de broche
délivrant le signal PWM. Deux méthodes permettent de positionner le gabarit dans l’une ou l’autre des
configurations.
ScanningEngine
La classe ScanningEngine constitue le cœur du firmware et utilise les ressources mises à disposition par toutes
les autres classes.
Les procédures de calibration et de scanning sont orchestrées sous sa houlette.
Elle est en lien avec l’extérieur grâce au serveur et au client HTTP, et exploite un dictionnaire de commandes
lui permettant de répondre aux sollicitations de la centrale.
27
(Bridge Library for Yún devices)
28
(Servo library)
36 Imhof Yannick
Formation en emploi
Travail de Bachelor
Fonctionnalités
Conventions géométriques et système d’axes
Les valeurs des données de mesure retournées par le scanner sont basées
sur la convention des géographes29, avec quelques particularités.
Le sens de rotation positif sur les deux axes correspond au sens

trigonométrique.
La longitude θ correspond à la rotation du module complet selon l’axe

vertical. La plage de valeurs s’étend de 0 à 180°, ou en µsteps, de 0 à 217'344.
L’origine est sur l’axe X.
La latitude δ correspond à la rotation du miroir selon l’axe horizontal. La

plage de valeurs s’étend de 0 à 360°, ou en µsteps, de 0 à 434’688. L’origine Figure 37 - Convention des
géographes
est sur le plan équatorial.
Le rayon ρ correspond à la distance mesurée.
Cette convention reportée sur la configuration

géométrique du scanner donne le système d’axes illustré
ci-contre, correspondant à la position à l’origine du miroir
(θ = 0, et δ = 0).
Deux éléments devront être pris en compte lors des calculs

de passage du référentiel sphérique au référentiel
cartésien :
 l’axe de rotation physique Z du module est décalé

par rapport à l’axe théorique Z’. En d’autres
termes, à (θ ; δ) = (0 ; 0), Y est différent de 0.
 le laser ne pointe pas vers le centre du miroir. La
Figure 38 - Système d'axes du scanner
rotation de ce dernier induit donc une variation du
décalage O-O’, et par extension de la position du
point de mesure.
Principe de calibrage
Le calibrage est une fonctionnalité du scanner lui permettant de définir la position de son référentiel par
rapport à son environnement. En elle-même, cette fonctionnalité n’est pas réellement nécessaire pour
réaliser un scan, c’est-à-dire faire l’acquisition des distances entre le module et les obstacles formant son
environnement. Un scanning réalisé sans calibrage ne serait pas très différent du même scanning après
calibrage, excepté le fait que l’affichage en environnement 3D virtuel montrerait un résultat orienté de
manière aléatoire et difficile à appréhender. Le calibrage est donc là pour permettre aux données de
s’accorder au mieux avec la représentation humaine.
Le processus de calibrage comprend deux phases en vue de calibrer premièrement la position du miroir
permettant au laser de trouver le plan horizontal, et deuxièmement la position globale du module
permettant au laser de coïncider avec l’axe X.
29
(Coordonnées sphériques)
Imhof Yannick 37
Le calibrage utilise les fonctionnalités de mesure du scanner et selon l’environnement peut partiellement
échouer. Dans un tel cas, l’origine correspondra à la position du système au moment de son démarrage.
Calibrage du miroir
Figure 39 - Principe de calibrage du miroir (plan XZ du référentiel)
Lors du calibrage du miroir, un gabarit de forme triangulaire est présenté face au laser, avec la particularité
d’être l’élément de l’environnement le plus proche du module. Un processus de recherche, basé sur cette
distance minimale, permet ensuite de prendre six mesures à intervalle de 17° le long du gabarit. Sur ces six
points, quatre sont utilisés pour définir les équations de deux droites dont on cherche ensuite le point
d’intersection30 (Xi ;Yi). La position de ce dernier point est enfin utilisée pour calculer le décalage angulaire
nécessaire pour retrouver l’horizontale depuis l’origine courante, compte tenu de la position décalée du
laser.
Exemple pour la droite 𝑑0 , 𝑦 = 𝑚0 ∙ 𝑥 + 𝑏0 :

 Pente d’une droite définie par deux points :
𝑦01 − 𝑦00
𝑚0 =
𝑥01 − 𝑥00
 Ordonnée à l’origine :
𝑏0 = 𝑦00 − 𝑚0 ∙ 𝑥00
Intersection de deux droites 𝑑0 et 𝑑1 :
𝑏1 − 𝑏0
𝑥𝑖 =
𝑚0 − 𝑚1
𝑦𝑖 = 𝑚0 ∙ 𝑥𝑖 + 𝑏0 = 𝑚1 ∙ 𝑥𝑖 + 𝑏1
30
(Gieck p. F1)
38 Imhof Yannick
Formation en emploi
Travail de Bachelor
A titre d’exemple, sans correspondance de valeurs avec le schéma qui

précède, un extrait de journal de debug ci-contre illustre les différentes
étapes.
1. recherche du bord du gabarit : « CM :1503 » désigne la première

mesure au-delà du gabarit
2. le miroir revient ensuite en arrière et prends 6 mesures.
« CM :234 ;MP :393289 » correspond à la dernière mesure (234
[mm] à env. 326°).
3. les coordonnées polaires (le travail se fait dans un pseudo plan
XY correspondant au plan XZ du référentiel) sont converties en
coordonnées cartésiennes.
4. le décalage est enfin calculé : « MO :7956 » correspond à une
correction de base de 6.6° en positif, auxquels sont ajoutés les
presque 11° en positif de décalage du laser. Figure 40 - Calibrage du miroir
Légende :
 CM = calibration measure
 MP = mirror position
 MO = mirror offset
Calibrage du module
Figure 41 - Calibrage du module (plan XY du référentiel)
Le principe de calibrage de la position globale du module est assez similaire. Le gabarit est retiré, puis neuf
mesures propres à l’environnement sont prises à l’horizontale sur une plage de 180°, tous les 20°. Ces neuf
points, appartenant au plan XY du référentiel, sont ensuite analysés pour en extraire trois, consécutifs et
alignés, c’est-à-dire appartenant à la même équation de droite, moyennant une tolérance de ± 20 [mm]
Imhof Yannick 39
définie empiriquement. On admet implicitement que la droite identifie quelque chose qui ressemble à un
mur.
Lorsque ces conditions sont réunies, le décalage est calculé pour placer le module parallèlement à la droite,
cette dernière étant assimilée à l’axe Y du référentiel, avec une résultante perpendiculaire pour la direction
du laser correspondant à l’axe X.
Selon les conditions rencontrées pendant les mesures, ce calibrage peut facilement échouer, et l’origine du
module reste à sa valeur initiale. C’est la raison pour laquelle la mise en place initiale du module dans son
environnement n’est pas anodine.
Toujours sans correspondance de valeurs avec le schéma qui précède, un

autre extrait de journal de debug ci-contre lors de la calibration du
module.
1. les mesures démarrent depuis l’origine courante

2. le module prend les 9 mesures. « CM :6080 ;GP :193194 »
correspond à la dernière mesure (6.08 [m] à 160°).
3. les coordonnées polaires dans le plan équatorial sont converties
en coordonnées cartésiennes.
4. les données sont analysées par calculs successifs (sept au
maximum) où deux points servent à calculer l’équation de leur
droite, dont on teste la validité sur le point suivant.
5. le décalage est défini pour permettre au laser de pointer dans la
direction de l’axe X. « GO :2831 » correspond à une correction de
2.3° en positif. Figure 43 - Calibrage du miroir
Légende : Figure 42 - Calibrage du module
 CM = calibration measure
 GP = gear position
 GO = gear offset
Processus de scanning
Le processus de scanning constitue la fonctionnalité principale du scanner, et son bon déroulement peut être
perturbé par différents facteurs dont les plus évidents sont détaillés ci-dessous.
1. Phénomène de Black Hole : le trou noir est un phénomène stellaire dont la principale caractéristique
est une gravité telle que pas même la lumière ne s’en échappe. Du point de vue du scanner, l’effet
est identique à chaque point de mesure où la lumière du laser est incapable de revenir. Ce sont par
exemple les points à « l’infini » (la distance de mesure maximum du télémètre est dépassée), les
surfaces « absorbantes » comme un épais tapis ou d’indice de réflexion trop faible comme celles de
couleur noire matte.
2. Arrêt de l’un des moteurs : étant donné le paramétrage empirique des pilotes de moteurs, un
déplacement long et rapide peut occasionner un dépassement de courant avec un arrêt d’urgence à
la clé. Le câble d’alimentation peut s’emmêler, entraver le déplacement et provoquer l’arrêt par
débranchement ou dépassement de courant.
3. Erreur de connexion vers la centrale : dans un réseau Wifi, toutes sortes de facteurs peuvent rompre
une connexion établie et fonctionnelle.
40 Imhof Yannick
Formation en emploi
Travail de Bachelor
Figure 44 - Processus de scanning
Imhof Yannick 41
Après une phase d’initialisation dépendante de la résolution de scanning à mettre en œuvre, le processus se
structure en une séquence de quatre activités principales répétées en boucle jusqu’à compléter le cycle par
la dernière mesure.
1. Acquisition et traitement de la mesure courante

Le télémètre délivre ses données en continu et impose au processus de tout traiter, y compris les
mesures inutiles prises pendant un déplacement, ces dernières étant simplement occultées. Il est
également nécessaire de gérer un déclencheur qui, lorsqu’aucune mesure n’est délivrée
(comportement lors d’un Black Hole), provoque la poursuite du cycle par la notification d’une mesure
nulle.
Une telle mesure correspond simplement aux coordonnées de l’origine ce qui la rend facile à filtrer
lors de l’exportation. Elle fait néanmoins partie des données de mesure au même titre que les autres
et dans cette optique elle est également envoyée à la centrale et persistée en base de données.
2. Gestion des déplacements
Une fois la mesure disponible, les déplacements peuvent être initiés. Cette phase calcule la prochaine
position angulaire de chacun des axes et envoie les commandes correspondantes aux moteurs. C’est
également à ce moment que les erreurs notifiées par les moteurs sont traitées. Dans un tel cas, le
cycle est interrompu et l’utilisateur est notifié au moyen d’une led allumée en rouge.
Il faut être conscient qu’à l’échelle de la fréquence de travail du microcontrôleur, les moteurs sont
d’une lenteur exaspérante, et le cycle passe une grande partie du temps à attendre que ces derniers
notifient leur arrivée à la position de consigne.
3. Transmettre les données de la mesure courante
Les mesures valides, prises moteurs arrêtés, sont transmises à la centrale en temps réel. Une
interruption de connexion est détectée après trois tentatives d’envoi de la même mesure en échec.
Un tel cas provoque l’arrêt du cycle.
4. Interpréter les éventuelles commandes de la centrale.
Durant le processus de scanning, le temps d’attente induit par le déplacement des moteurs est mis
à profit pour répondre aux requêtes en provenance de la centrale. Le dictionnaire des commandes
accessibles à ce moment est un extrait du dictionnaire de base, toutes les commandes étant
invalidées, sauf la demande de statut et la demande d’interruption du cycle.
Il reste encore à préciser que le premier point de mesure ne se situe pas à la latitude 0. Si tel était le cas, les
résolutions de scanning induisant des positions angulaires multiples de 90° répèteraient inutilement la
mesure des deux points à la verticale du module, sur l’axe Z, à chaque méridien. En conséquence, les mesures
démarrent à une latitude équivalente au demi-angle de la résolution.
Résolution de scanning
Afin de laisser à l’utilisateur le choix de privilégier la qualité au détriment de la vitesse, le scanner est capable
de gérer 11 niveaux de résolution. Par défaut, il adopte la résolution la plus grossière offrant la durée de
scanning la plus courte.
Les durées indiquées dans le tableau ci-dessous sont des estimations extrapolées à partir des tests réalisés,
et ne peuvent être considérées comme absolues.
Index Angle Pts / méridien Pts total Résolution Durée

[°] - - [m] [h]
0 45 8 32 7.65 0.007
1 30 12 72 5.18 0.016
2 20 18 162 3.47 0.037
42 Imhof Yannick
Formation en emploi
Travail de Bachelor
3 15 24 288 2.61 0.065

4 10 36 648 1.74 0.147
5 5 72 2’592 0.87 0.588
6 2 180 16’200 0.35 3.672
7 1 360 64’800 0.17 14.7
8 0.5 720 259’200 0.09 58.8
9 0.143 2’514 3’160’098 0.02 716
10 0.057 6’284 19'744’328 0.01 4’475
Figure 45 - Résolutions de scanning
Bibliothèque Arduino Bridge

La carte Arduino Yùn est le résultat d’un mariage plus ou moins heureux entre un microcontrôleur
ATmega32u4 et un processeur Atheros AR933131, lequel héberge une déclinaison Linux basée sur OpenWrt.
Cette carte est maintenant en fin de vie mais elle peut être reproduite par l’association d’un microcontrôleur
Arduino Leonardo et d’un shield Yùn, moyennant quelques différences dans le mode de communication
entre les deux composants.
Figure 46 - Structure du microcontrôleur Arduino Yùn
Ainsi que le montre le schéma ci-dessus, l’idée générale est d’augmenter notablement les capacités
d’interface du microcontrôleur avec l’extérieur, et en particulier du point de vue réseau avec la présence
d’une interface Wifi.
La répartition des « tâches » entre les deux mondes est assez évidente :
 Le microcontrôleur gère les périphériques tels que les sondes, les moteurs, les accéléromètres et
autres capteurs.
 Le processeur offre des services de connexion au monde via le réseau, de stockage étendu par l’USB
ou la carte SD et d’acquisition audio et vidéo.
Ces deux mondes doivent pouvoir communiquer et c’est là le rôle du Bridge. C’est aussi là que le mariage
trouve rapidement quelques limites. Pour citer les principaux exemples, l’unique contrôleur UART est
monopolisé dans ce cadre, 3 des 5 interruptions disponibles du microcontrôleur lui sont également dédiées,
31
(Arduino Yún)
Imhof Yannick 43
et il est préférable d’éviter d’utiliser les broches 0 et 1 du Yùn, toujours pour la même raison. Le bon
fonctionnement du bus SPI pourrait également être influencé mais cela ne s’est heureusement pas vérifié.
Une fois ces éléments pris en compte, la bibliothèque Bridge livre tout son potentiel, qui n’est de loin pas
négligeable. C’est typiquement elle qui donne accès au serveur web disponible sous l’environnement Linux
et permet donc de rendre le microcontrôleur « visible » depuis Internet. C’est elle également qui publie la
console sérielle permettant de visualiser les traces de debug si utiles au développeur. Et la création de
processus permettant l’exécution de commandes Linux est également de son ressort.
Concernant le dialogue sur le réseau, en utilisant le protocole REST et en respectant une certaine syntaxe
attendue par le serveur dans la racine de l’URL, il est possible d’envoyer des commandes à ce dernier, qu’il
transmettra ensuite au microcontrôleur lorsque ce dernier est à l’écoute.
Les adresses REST réservées sont les suivantes32,33 :
 Envoi d’une commande au microcontrôleur

http://<adresse ip>[:port ip]/arduino/<commande>
 Accès au sous-répertoire www du sketch
http://<adresse ip>[:port ip]/sd/<nom de sketch>
 Modification d’une valeur dans le dictionnaire partagé
http://<adresse ip>[:port ip]/data/put/<nom de variable>/<valeur>
 Lecture d’une valeur dans le dictionnaire partagé (format JSON)
http://<adresse ip>[:port ip]/data/get/<nom de variable>
 Suppression des données du dictionnaire partagé
http://<adresse ip>[:port ip]/data/delete
 Envoi d’un message au microcontrôleur via une queue système
http://<adresse ip>[:port ip]/mailbox/<message>
Dans le cadre du scanner, la première option a pris toute son importance dans la prise en charge du
dictionnaire de commandes.
Le fait d’avoir un second processeur à disposition permet également au microcontrôleur de déléguer

certaines tâches. Typiquement, le traitement des chaînes de caractères est extrêmement coûteux en termes
d’empreinte de firmware au niveau du microcontrôleur. Par contre, en créant une série de scripts bash
exécutables par le processeur Linux, il est possible de lui demander de réaliser certains traitements et d’en
retourner le résultat au microcontrôleur.
Ce type de tâche déléguée a été intensivement utilisée dans le cadre de la gestion de échanges HTTP entre
le Yùn et la centrale. Ainsi le formatage au formalisme JSON de tous les acquittements de commandes, ou
des données de mesures est réalisé par le processeur.
Dictionnaire de commandes
La liste ci-dessous détaille les URLs auxquelles le scanner répond, et la commande correspondante qui sera
exécutée.
32
(Getting Started with the Arduino Yún)
33
(Beginner's Introduction to Yun Web Services)
44 Imhof Yannick
Formation en emploi
Travail de Bachelor
 Mouvements généraux :
o Augmentation de la latitude, ou rotation du miroir dans le sens trigonométrique (5°).
http://192.168.24.44:8068/arduino/Cmd/EB/
o Diminution de la latitude, ou rotation du miroir dans le sens anti-trigonométrique (5°).
http://192.168.24.44:8068/arduino/Cmd/EC/
o Augmentation de la longitude, ou rotation du module dans le sens trigonométrique (5°).
http://192.168.24.44:8068/arduino/Cmd/ED/
o Diminution de la longitude, ou rotation du module dans le sens anti-trigonométrique (5°).
http://192.168.24.44:8068/arduino/Cmd/EE/
o Réinitialisation manuelle de l’origine.
http://192.168.24.44:8068/arduino/Cmd/EF/
 Transmettre son statut courant
http://192.168.24.44:8068/arduino/Cmd/H/
 Réaliser une calibration
http://192.168.24.44:8068/arduino/Cmd/F/
 Réaliser un scanning
http://192.168.24.44:8068/arduino/Cmd/Gx/
x étant la résolution de scanning (valeur entre B et L)
 Stopper le scanning en cours
http://192.168.24.44:8068/arduino/Stop/
 Se réinitialiser (ATmega32u4)
http://192.168.24.44:8068/arduino/Cmd/D/
 Redémarrer (AR9331 + ATmega32u4)
http://192.168.24.44:8068/arduino/Cmd/C/
Réduction de la taille d’empreinte du firmware

Le Yùn bénéficie de la présence d’un système parallèle sous Linux. Le corollaire est que pour accéder à ces
fonctionnalités parallèles, le sketch doit compiler la bibliothèque Bridge, laquelle n’a pas une taille
d’empreinte mémoire négligeable, surtout si la console est utilisée.
L’un des problèmes principaux rencontré de manière récurrente durant le développement du firmware, a
été la nécessité de conserver une taille compatible avec les 28 ko disponibles en mémoire flash.
Figure 47 - Taille d'empreinte du sketch
Et malgré le fait de respecter au mieux certaines règles34, au fur et à mesure des développements et de
l’extension des fonctionnalités, la nécessité de cibler les modules absolument nécessaires au travail en cours
s’est imposée. Le code intègre donc une dizaine de directives qui permettent de compiler le sketch de
manière sélective.
34
(How to reduce program size)
Imhof Yannick 45
Mais en définitive, la principale mesure pour rester dans la cible a été, dans la version RELEASE du code, de
supprimer la console, et donc au même titre toutes les constantes de chaînes des messages. La conséquence
directe est que dans sa version finale, le scanner ne délivre plus aucun message sur la console SSH.
Les directives de compilation s’inscrivent dans une hiérarchie de dépendance que le code gère
automatiquement. Néanmoins, typiquement dans le cas des tests relatifs au calibrage, le développeur devra
également choisir entre les messages du miroir ou ceux du module en commentant les lignes appropriées.
 DEBUG, directive générale activant la plupart des messages de la console :

o SPIDEBUG Validation du transfert des données sur le BUS SPI.
o DRVCFGDEBUG Validation de la configuration des moteurs pas-à-pas.
o RFNDCFGDEBUG Validation de la configuration du télémètre.
o MEASUREDEBUG Gestion des mesures de distance.
o DEVICESDEBUG Routines de tests généraux des périphériques.
o FUNCTIONDEBUG Tests des commandes générales du menu hors calibrage et scan.
o CALIBRATEDEBUG Test du processus de calibrage.
o SCANDEBUG Test du processus de scanning.
 RELEASE, directive générale pour laquelle la console est désactivée.
Séquence de démarrage
Le parallélisme des systèmes induit encore une dernière problématique dont il faut tenir compte. Si
l’ATmega32u4 démarre en quelques fractions de secondes, il n’en va pas de même pour le système Linux35.
De plus, chaque système est indépendant, et redémarrer l’un n’implique pas le redémarrage de l’autre.
Néanmoins, l’interdépendance fonctionnelle, dans le cas du scanner, n’est pas symétrique : le
microcontrôleur a besoin du système Linux, l’inverse n’est pas vrai. La priorité va donc au fait que Linux soit
opérationnel au moment où le microcontrôleur démarre.
Deux éléments permettent de s’assurer que la séquence nécessaire soit respectée :
 Au niveau du microcontrôleur, l’instruction Bridge.begin() au début du sketch permet d’attendre que

la communication série soit établie entre les deux systèmes, ce qui implique un système Linux
pleinement opérationnel. Cette instruction doit encore être précédée d’une attente active, dont la
durée est à définir empiriquement, et qui interdit tout démarrage intempestif du microcontrôleur
lors d’un redémarrage simultané des deux systèmes.
 La ligne reset-mcu du script de démarrage, modifiable depuis l’interface LuCi doit être activée. Ceci
impose le redémarrage du microcontrôleur après un démarrage complet de Linux.
Figure 48 - S'assurer de la séquence de démarrage
D’un côté plus fonctionnel, une fois les deux systèmes disponibles, le scanner commence par une calibration.
Puis lorsqu’il est prêt à l’emploi, il se connecte à la centrale, transmet son adresse IP, et requiert un
identifiant.
35
(Arduino Yún)
46 Imhof Yannick
Formation en emploi
Travail de Bachelor
Après avoir reçu son identifiant, il se met à l’écoute des commandes en provenance de l’application cliente
relayées par la centrale.
Centrale
L’architecture de la centrale se compose de trois éléments interconnectés :
1. Un service Windows, implémenté en .Net C#, sous Visual Studio 2015

2. Un service web WCF36, implémenté en .Net C#, sous Visual Studio 2015.
3. Une base de données, hébergée par SQL Server Express 2016.
Service Windows
Figure 49 - Service Windows du scanner 3D
Le service Windows au cœur du système du scanner peut presque être assimilé à une coquille vide. C’est un
processus qui offre un espace de fonctionnement et des droits système à un ou plusieurs services web WCF
en self-hosting. Sa particularité est d’être structuré de manière à permettre la gestion de ces services sous la
forme d’add-ins, selon une architecture définie par Microsoft37,38.
Figure 50 - Structure d'une application pouvant accueillir des add-ins selon Microsoft
Le principal avantage de cette solution est une séparation des

fonctionnalités métier de celles relatives au système. Le service
Windows une fois créé et installé n’a plus besoin d’être modifié. Le
déploiement d’un add-in se fait par copie des binaires vers
l’arborescence du service, dans un répertoire dédié.
Ceci autorise une procédure allégée lors de la mise à jour de l’add-

in, par simple remplacement de ses binaires.
Figure 51 - Répertoire dédié aux add-ins.
36
(What Is Windows Communication Foundation)
37
(Walkthrough: Creating an Extensible Application)
38
(AddIn Enabled Applications)
Imhof Yannick 47
Un redémarrage du service Windows permet ensuite la

prise en charge de l’add-in, dans sa nouvelle version.
Dans le cas du service web du scanner, le journal des

évènements affiche l’URL sur laquelle la centrale écoute
lorsque l’add-in est chargé par le service Windows.
Figure 52 – Prise en charge de l’add-in
Le détail de l’implémentation ne sera pas abordé, étant donné qu’elle est intégralement basée sur différents
didacticiels provenants de la documentation Microsoft, ainsi que sur l’expérience professionnelle de l’auteur.
Cette implémentation met en œuvre un pipeline de communication entre le host et ses add-ins au moyen de
deux interfaces identiques (contrats de fonctionnalités) mais propres à chacun des deux « côtés » du pipeline.
S’ajoutent à cela les mécanismes de « traduction » depuis et vers chacune de ces deux interfaces. Pour le
lecteur passionné, les références de ces didacticiels sont disponibles dans la table de documentation.
Service web WCF

Structure de la solution et diagramme de classes
L’implémentation du service web se répartit en cinq assemblies.
Figure 53 - Solution de l'add-in de service web WCF
 Common :
Cet assembly rassemble à la fois les classes permettant l’intégration du service web comme add-in
du service Windows, ainsi que toutes les classes nécessaires à la traduction des erreurs systèmes en
faults propres au protocole SOAP39. Il publie également la classe permettant la création d’éléments
dans le journal des évènements Windows40.
 DAL (Data Access Layer)
Cet assembly publie la classe S3DDAL, laquelle formalise la couche métier. Elle fait le lien entre les
éléments de contrats publics publiés par le service web, et la base de données. C’est elle qui
implémente toutes les fonctionnalités à orientation métier comme par exemple la conversion des
coordonnées sphériques en coordonnées cartésiennes.
 Entity
L’assembly Entity publie les entités de la base de données et les fonctionnalités CRUD. Il est
implémenté sur la base d’Entity Framework 6, la technologie d’accès aux données recommandées
par Microsoft41.
39
(Planned and Unplanned Exceptions in WCF)
40
(Tracing and Message Logging)
41
(Entity Framework)
48 Imhof Yannick
Formation en emploi
Travail de Bachelor
Figure 54 - Service WCF, interfaces REST et SOAP publiés
Imhof Yannick 49
 ScanCmd et DataContracts
Les assemblies ScanCmd et DataContrats définissent toutes les classes relatives à la publication du
service web par WCF. Les tâches de conversion des commandes de l’application cliente à destination
du scanner, et des réponses du scanner à destination de l’application cliente, leur sont dévolues.
Considérations techniques concernant les flux de communication

Le serveur web, hébergé par le Yùn, communique avec l’extérieur sur la base du protocole REST42. Du côté
du client, le protocole de communication est SOAP43, traditionnellement mis en œuvre par WCF. Le service
doit donc être capable de dialoguer selon les deux « langues » différentes de chacun de ses deux
protagonistes. Ces formalismes différents sont mis en œuvre au moyen des deux interfaces dédiées,
accessibles sur deux endpoints différents, définis au niveau de la configuration. Chacune des deux interfaces
publie les fonctionnalités propres à son destinataire final.
<services>
<service name="Scanner3D.Services.WCFAddins.ScanCmd.Scanner3DService"
behaviorConfiguration="authSvcBehavior">
<endpoint address="rest" binding="webHttpBinding" bindingName="authWebHttpBinding"
behaviorConfiguration="poxBehavior"
contract="Scanner3D.Services.WCFAddins.ScanCmd.IScanner3DServiceREST" />
<endpoint address="soap" binding="basicHttpBinding"
contract="Scanner3D.Services.WCFAddins.ScanCmd.IScanner3DServiceSOAP" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://192.168.24.43:8069/Scn3DSvc/Cmd" />
</baseAddresses>
</host>
</service>
</services>
En second point, le format traditionnel des données échangées sous REST est JSON. Les requêtes SOAP quant
à elles adoptent la structure XML. A titre de comparaison, les données d’une même mesure sont présentées
ci-dessous en provenance du scanner et à destination de l’application cliente après conversion :
Scanner (JSON):
{
"id":"0100",
"ix":"00000283",
"ro":"04df",
"tt":"00030a40",
"dt":"000563a0"
}
Application cliente (XML):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:rem="http://www.scanner3d.ch/RemoteControlService">
<soapenv:Header/>
<soapenv:Body>
<rem:AddMeasurePoint>

<rem:measure>

<rem:Client>80744CE7-D84F-4485-BA79-378022E031E9</rem:Client>

42
(Representational state transfer)
43
(Simple Object Access Protocol)
50 Imhof Yannick
Formation en emploi
Travail de Bachelor
<rem:Index>283</rem:Index>

<rem:Scanner>3D004DE4-0447-498A-BDFC-49E1C2E8CE1D</rem:Scanner>

<rem:X>-421.9811</rem:X>

<rem:Y>177.2566</rem:Y>

<rem:Z>-1094.7972</rem:Z>
</rem:measure>
</rem:AddMeasurePoint>
</soapenv:Body>
</soapenv:Envelope>
Enfin, que ce soit du côté du scanner, ou du côté de l’application cliente, la centrale entretient des flux de
communication bidirectionnels. Elle est donc, pour chacun des deux partenaires, à la fois serveur et cliente.
Si la part serveur est en permanence à l’écoute des requêtes extérieures, les clients sont instanciés
dynamiquement à la demande.
Conversion des coordonnées sphériques en coordonnées cartésiennes

Comme évoqué dans le cadre de la définition du système d’axes, le décalage du miroir par rapport à l’axe de
rotation Z physique du module implique que les coordonnées sphériques doivent être adaptées avant de
réaliser la conversion vers le système d’axes cartésien.
Figure 55 - Décalage du miroir (M) par rapport à l'origine (O)
De plus, le décalage du laser par rapport à l’axe Y induit une variation du décalage ̅̅̅̅̅
𝑂𝑀 en fonction de la
latitude courante. En prenant le miroir comme plan de référence, il est possible de visualiser les positions
extrêmes du point M.
Imhof Yannick 51
Figure 56 - Positions extrêmes du point M
Constatations :
 Le décalage du miroir ̅̅̅̅̅

𝑂𝑂′ est dû à la géométrie du système. C’est une constante connue.
 Le décalage du laser par rapport à l’axe Y est également dû à la géométrie. C’est une constante
connue.
 Le décalage ̅̅̅̅̅
𝑂𝑀 est une fonction du décalage du miroir, du décalage du laser et de la latitude
courante.
Le centre du laser se positionne au point (-5 ;7) du plan XZ. L’amplitude du décalage est donc de
−5
√(−5)2 + 72 = 8.6 [mm]. Les maxima sont donnés pour les latitudes valant tan−1 ( ) ± 180°. Compte
7
tenu de la position du miroir, 𝑀𝑚𝑎𝑥 intervient à 144.5° et 𝑀𝑚𝑖𝑛 à 324.5°. Il est dès lors possible de définir la
variation ̅̅̅̅̅̅
𝑂′𝑀 comme :
̅̅̅̅̅̅ = √(−5)2 + 72 ∙ sin (𝛿 − tan−1 (−5) − 𝜋)

𝑂′𝑀
7 2
Figure 57 - Variation O'M en fonction de δ
52 Imhof Yannick
Formation en emploi
Travail de Bachelor
Les coordonnées sphériques finales observent les règles suivantes :
 ̅̅̅̅̅ + 𝑀𝑆
La distance mesurée physiquement 𝜌 correspond à 𝑂𝑀 ̅̅̅̅, mais le système d’axes demande 𝜌′ =
̅̅̅̅
𝑂𝑆.
 Dans le référentiel relatif xy, ̅̅̅̅̅
𝑂𝑀 est une quantité systématiquement négative sur l’axe y. En
conséquence, la longitude 𝜃 doit être diminuée de ∆𝜃 pour cos 𝛿 > 0 et augmentée de ∆𝜃 pour
cos 𝛿 < 0.
 La latitude 𝛿 doit devenir 𝛿′
Les règles de transformation peuvent donc être définies comme suit :
ℎ = ̅̅̅̅ ̅̅̅̅̅) ∙ sin 𝛿

𝑆𝑆′ = (𝜌 − 𝑂𝑀
𝑑𝑥𝑦 = ̅̅̅̅̅
𝑀𝑆′ = (𝜌 − ̅̅̅̅̅
𝑂𝑀) ∙ cos 𝛿
𝜌𝑥𝑦 = √(𝜌 − ̅̅̅̅̅

𝑂𝑀)2 + ℎ2
̅̅̅̅ = √𝜌𝑥𝑦 2 + ℎ2
𝜌′ = 𝑂𝑆
̅̅̅̅̅
𝑂𝑀
𝜃 ′ = 𝜃 − 𝑠𝑖𝑔𝑛(cos 𝛿) ∙ ∆𝜃 = 𝜃 − 𝑠𝑖𝑔𝑛(cos 𝛿) ∙ tan−1 ( )
𝑑𝑥𝑦
ℎ
𝛿 ′ = tan−1 ( )
𝜌𝑥𝑦
avec 𝑑𝑥𝑦 et 𝜌𝑥𝑦 différents de 0.
A partir de ces nouvelles coordonnées sphériques, les lois de transformation normales44 peuvent s’appliquer.
Traitement asynchrone des mesures

Le scanner ne doit pas avoir à attendre que le traitement d’une mesure qu’il envoie soit terminé avant de
pouvoir continuer. Dans cette optique, le service traite l’arrivée des mesures de manière asynchrone.
Lorsque le service reçoit les données d’une mesure, une séquence de trois tâches parallèles
interdépendantes est instanciée. Le scanner retrouve la main dès que la couche réseau a terminé le transfert
des données.
Les données de mesure sont :
1. Persistées en base de données.

2. Envoyées à l’application cliente.
3. Marquées comme envoyées.
Chacune de ces tâches est liée à une seconde tâche de traitement d’erreur le cas échéant. Si l’application
cliente se déconnecte, une erreur à l’envoi est détectée et les tentatives de connexion cessent. L’application
reçoit ses données dès qu’elle se reconnecte.
44
(Coordonnées sphériques)
Imhof Yannick 53
Configuration système
Pour pouvoir fonctionner, le service web demande une certaine configuration au niveau du système.
1. Autoriser la publication de la définition du service pour Net.TCP (endpoint « mex »)

Dans une console Windows en mode administrateur, lancer la commande suivante :
netsh http add urlacl url=http://+:8069/ user=\everyone
L’utilisateur everyone peut être remplacé par l’utilisateur du service Windows s’il est défini.
2. Au niveau du firewall, autoriser le trafic en entrée et en sortie sur le port IP 8069.
Accessoirement, si deux add-in de gestion du scanner sont installés sur la même machine (configuration test
et production fonctionnant en parallèle par exemple), il y a de fortes chances qu’ils utilisent les deux le même
port IP. Dans ce cas, le service de partage de port Net.Tcp Port Sharing Service doit être démarré, et
l’utilisateur du service Windows doit être ajouté dans la configuration présente dans le fichier
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\SMSvcHost.exe.config.
Base de données
Figure 58 - Définition de la base de données
La principale tâche de la base de données est bien évidemment de persister les coordonnées des mesures.
Chaque scanning est répertorié avec le scanner ayant fait le travail ainsi que le client l’ayant requis. Les
caractéristiques générales du scanning sont mémorisées de même qu’une statistique des temps de
54 Imhof Yannick
Formation en emploi
Travail de Bachelor
traitements. Les données originelles de chaque point de mesure sont conservées à côté du résultat des deux
transformations (coordonnées sphériques « corrigées » et coordonnées cartésiennes).
La base de données conserve également la liste des scanners et clients inscrits, avec leurs adresses et ports
IP. C’est ce qui permet au service d’officier comme agent de liaison entre chaque scanner et chaque
application cliente. Du côté du scanner sont également mémorisées les constantes géométriques nécessaires
aux changements de référentiels.
Un script développé en Transact-SQL permet de créer l’intégralité des éléments moyennant l’installation
préalable de SQL Server et la modification des chemins d’accès aux fichiers de données et de journalisation.
A noter, que l’add-in du service web hérite des droits du login utilisé pour le démarrage du service Windows.
Etant donné que le service web doit pouvoir accéder à la base de données, différentes possibilités existent
pour qu’il y soit autorisé. Dans l’idéal, un utilisateur dédié au service doit être créé et répercuté dans les
sécurités de SQL Server. Un rôle doit ensuite lui être attribué au niveau de la base de données avec les
autorisations nécessaires sur les objets. Dans la cadre de ce projet, le login utilisé est membre du groupe des
administrateurs, ce qui simplifie les choses mais n’est pas très probant du point de vue de la sécurité.
Application cliente
Vue d’ensemble
L’application cliente peut être vue comme une télécommande un peu plus évoluée. L’interface définit deux
parties distinctes, d’un côté tous les éléments nécessaires au pilotage du scanner, et de l’autre l’affichage du
résultat du scanning, avec l’état courant de l’avancement du travail, et la possibilité d’exporter les données.
Figure 59 - Interface utilisateur de l'application cliente
L’une des idées, en début de projet, envisageait la création d’une application mobile, avec un développement
cross-platforms au moyen du framework Xamarin45. Mais d’une part le temps restant à disposition après les
développements du firmware et des services était insuffisant, et d’autre part, les plateformes mobiles ne
sont pas en adéquation avec la finalité visant à pouvoir exploiter les données au moyen d’un logiciel tiers.
45
(Download Xamarin)
Imhof Yannick 55
L’application cliente se base donc finalement sur le framework Windows Forms, et se concentre sur les
aspects fonctionnels plutôt qu’esthétiques. Il faut encore préciser que ce n’est pas une application de gestion,
en ce sens qu’elle ne permet pas de gérer les données de scanning dans leur globalité.
Pour être pleinement fonctionnelle, l’application s’attend d’une part à pouvoir se connecter à la centrale, et
d’autre part à trouver un scanner disponible. A la connexion, elle informe la centrale de son existence en lui
transmettant son adresse IP et demande en retour un identifiant au sein du système.
Puis, selon le contexte actif lors de sa dernière déconnexion, le client va chercher à obtenir les dernières
données qui lui sont destinées ou simplement la liste des scanners connectés s’il n’était à l’origine d’aucune
demande de scanning.
Une fois le scanner cible sélectionné, il est possible de le piloter. L’activation des boutons de commandes est
fonction de ce que le contexte métier autorise. La plupart des commandes sont par exemple inaccessibles
pendant un scanning. Toutes les commandes sont lancées de manière asynchrone et affichent des messages
d’erreurs détaillés en cas de problème. A noter que ces messages, en l’état, s’adressent plus à un développeur
qu’à l’utilisateur lambda. A titre d’exemple, ci-dessous, le message affiché lorsque la connexion à la centrale
n’est pas possible.
Figure 60 - Message d'erreur à la connexion à la centrale
Structure de la solution
L’implémentation de l’application cliente se répartit en quatre assemblies.
Figure 61 - Solution de l'application cliente
 Ressources :
Cet assembly rassemble tous les éléments de ressources statiques. Ce sont typiquement les textes
des messages d’erreurs ou des retours de statuts. Les ressources graphiques comme les icônes de
boutons ou les GIFs animés de gestion de progression s’y trouvent également.
 Services
Cet assembly publie deux choses essentielles pour l’application qui sont d’une part le proxy WSDL en
vue de la connexion au service WCF de la centrale, et d’autre part les classes du service WCF en self-
56 Imhof Yannick
Formation en emploi
Travail de Bachelor
hosting permettant à l’application de recevoir les données de mesure du scanning en cours en

provenance de la centrale. Au même titre que le service de la centrale, celui de l’application cliente
est basé sur les didacticiels de Microsoft, et intègre, entre autres, les mécanismes de conversion des
erreurs système en faults SOAP.
 Engine
L’assembly Engine est comme son nom l’indique, le cœur de l’application. C’est lui qui implémente
toutes les règles de gestion métier et le comportement général de l’application en toute
circonstance. Il constitue en quelque sorte la boîte à outils de l’interface graphique, sans laquelle ce
dernier ne serait qu’une coquille vide. Cette séparation entre la couche métier et le GUI permettrait
de réutiliser cet assembly, moyennant quelques adaptations mineures, dans un projet cross-
platforms.
 S3DRemoteControl
L’assembly S3DRemoteControl contient l’interface graphique et constitue le point d’entrée
exécutable de l’application. On y trouve également le fichier de configuration des éléments de
services aussi bien client que serveur.
Configuration système
Pour pouvoir fonctionner, le client demande une certaine configuration au niveau du système.
1. Autoriser la publication de la définition du service interne pour Net.TCP (endpoint « mex »)

Dans une console Windows en mode administrateur, lancer la commande suivante :
netsh http add urlacl url=http://+:8070/ user=\everyone
Si l’application est lancée en mode administrateur ce n’est pas obligatoire.
2. Au niveau du firewall, autoriser le trafic en entrée et en sortie sur le port IP 8070.
Exportation des données

L’application n’offre en l’état que la possibilité d’exporter les données dans un format de fichier de type
« nuage de points »46. Ce type de fichier est le résultat typique de mesures prises sur une surface quelconque
par un procédé de scanning 3D. Ce sont des données en lignes au format texte ASCII, dont chaque ligne
correspond à un point de mesure en coordonnées cartésiennes x, y et z, séparées par des espaces :
Figure 62 - Exemple de données présentes dans un fichier xyz
L’ordre des lignes correspond à la séquence selon laquelle les points de mesure ont été définis par le scanner.
La séquence et les liens nécessaires à la création des vertex permettant l’affichage du volume dans une scène
3D ne sont pas présents et doivent être définis par traitement.
46
(Point cloud)
Imhof Yannick 57
Ce type de fichier peut ensuite être ouvert dans un logiciel de traitement approprié comme Meshlab47.
Figure 63 - Nuage des points de mesure du scanner 3D
Au moment de la rédaction de ces lignes, le temps a malheureusement manqué pour aller plus avant dans
l’apprentissage de l’utilisation de ce logiciel de manière à pouvoir traiter le nuage et recréer le volume scanné
en réalité virtuelle.
Matières à amélioration
Du point de vue de la conception dans son ensemble, certains choix se sont avec le recul avérés discutables.
Les principaux sont détaillés ici dans l’optique d’être simplement formalisés et permettre des choix futurs
plus avisés.
Eléments mécaniques
 Goupilles élastiques
Les alésages des goupilles élastiques positionnant les paliers de l’axe de transmission du miroir
étaient volontairement cotés sans tolérances, pensant que l’élasticité des goupilles compenserait les
défauts de concentricité. Mais au montage, les roulements étaient sur-contraints, offrant un frein
sensible à la rotation de l’axe. Ce défaut a été finalement corrigé grâce aux compétences des gens
de l’atelier, et le palier du module, lui, est positionné avec des goupilles rectifiées.
 Roulements à cage ouverte.
Pour des raisons de coût et de disponibilité, les roulements permettant la rotation du miroir étaient
à cage ouverte. Malheureusement, durant la phase de montage, des corps étrangers se sont logés
dans l’un des roulements occasionnant de légers à-coups durant la rotation. Il n’a pas été possible
d’éliminer complétement ce défaut. En conclusion, dans le cas d’un prototype tel que le scanner il
est préférable d’utiliser systématiquement des roulements fermés.
47
(Meshlab homepage)
58 Imhof Yannick
Formation en emploi
Travail de Bachelor
 Montage et outillage nécessaire.

Les contraintes de montage ont toujours fait partie de la conception du système mécanique, ainsi
que le choix de la visserie dans une optique d’uniformisation de l’outillage. Mais séparer la
conception en deux parties (rotation miroir puis rotation module) a induit la nécessité dans la
seconde partie de faire « avec l’existant ». Il n’était simplement pas possible de tout anticiper et force
est de reconnaître que le système mécanique n’est pas facile à monter et nécessite certains outils
appropriés.
 Transmission par courroie crantée, denture T5.
L’idée sous-jacente à l’utilisation d’une transmission par courroie crantée voulait limiter au maximum
les erreurs de mesures dues au glissement d’une courroie simple ou au jeu d’engrenage à rattraper.
Mais cette solution n’est pas absolue et il existe un léger jeu entre la denture de la courroie et celle
des deux poulies, lequel permet un double glissement. Comme tout le système est basé sur des
déplacements et des mesures angulaires, plus la distance mesurée est importante et plus l’erreur de
positionnement du point de mesure l’est également en cas de glissement. Le firmware impose un
sens de rotation unique lors du scanning ce qui permet de continuellement rattraper le jeu de la
courroie dans le même sens durant tout le processus. Mais pour les résolutions les plus grossières,
les déplacements sont plus importants, les vitesses plus grandes, et allant de pair, l’inertie des
éléments en rotation également. Il est alors possible que le jeu change de côté et que le
positionnement physique ne corresponde plus à l’information délivrée par le pilote du moteur.
Eléments électromécaniques
 Positionnement du gabarit par servomoteur.
Lors de la pré-étude, le gabarit de calibrage devait être placé et retiré manuellement. L’ajout du
servomoteur est venu en réponse à la volonté de créer un système un peu plus autonome. Cette idée
est intervenue durant la seconde phase de conception, où il a fallu « faire avec l’existant », et surtout
avec la place disponible. Le servomoteur est donc sans doute l’un des plus petits que l’on puisse
trouver. C’est là, peut-être, la raison du fait que, lors de la mise en place ou du retrait du gabarit, le
servo semble osciller rapidement autours de la position de consigne. Le gabarit est des plus légers,
mais sa géométrie induit une inertie assez importante au vu de son poids et il semble que le servo
ne soit pas en mesure de la contrecarrer, avec ce phénomène de vibration à la clé. La régulation du
servo est arrêtée durant le calibrage ce qui stoppe les vibrations et autorise les mesures.
 Corrélation moteur – précision de positionnement
La précision angulaire d’un moteur pas-à-pas vient en grande partie de sa construction et de sa
géométrie interne. C’est encore accentué par le fait d’être associé à un réducteur favorisant une
correspondance entre la position physique et les échelles angulaires courantes. Ce projet se base sur
un moteur équipé d’un réducteur 1/35.4. Aucune loi de proportionnalité entière ne lie la structure
interne des 48 positions du moteur aux presque 1698 positions de celle de l’axe extérieur (1698.11
ou 1699.2 selon la méthode de calcul). Dès lors, sans une référence extérieure, cette légère erreur
se propage et se cumule proportionnellement au nombre de tours.
 Adéquation moteur – pilote.
Le moteur choisi lors de la pré-étude l’a été pour son angle de stepping très faible, et son couple
relativement important. Ce choix n’a pas pris en compte le fait que pilote et moteur doivent être en
adéquation l’un avec l’autre pour bénéficier des meilleures performances. Ce facteur s’avère être en
définitive le premier à prendre en compte dans le choix de ce type de composants, les autres
paramètres étant indirectement conditionnés par cette adéquation. Le présent point, appuyé par le
précédent, pousserait aujourd’hui à un autre choix de moteur, en faveur par exemple d’un moteur
Imhof Yannick 59
pas-à-pas hybride48. De tels moteurs offrent de par leur construction un pas de progression déjà très
fin avant réduction.
Eléments logiciels
 Sécurité réseau.
Dans un projet de système embarqué, le réseau informatique est semblable à une colonne vertébrale
sans laquelle rien ne fonctionne. La présence du réseau implique que la question de la sécurité soit
abordée. Dans le cadre de ce projet où Linux et Windows doivent se parler, la seule possibilité de
gérer la sécurité se situe au niveau du transport sous le protocole HTTPS. Mais cette option demande
la mise en œuvre de certificats et de connaissances qui restent à acquérir. En conséquence le projet
ne gère que certains éléments très basiques des aspects sécuritaires.
 Précision des mesures
La précision de mesure du télémètre s’inscrit dans une tolérance de ± 1 [mm]. Mais cela ne fait pas
tout, et du fait de l’inadéquation partielle entre les moteurs et leurs pilotes, ajouté aux possibilités
de glissement, dues au jeu des courroies ou au microstepping, les valeurs angulaires des mesures ne
sont pas totalement fiables.
 Calibrage au moyen du gabarit
La procédure de calibrage telle que définie précédemment nécessite encore d’être améliorée, voire
partiellement repensée. Il arrive qu’en fin de processus, le calibrage ait échoué et que le référentiel
soit visiblement incorrect. Il est alors nécessaire de relancer un calibrage, ou de mettre
manuellement le scanner en position attendue avant de réinitialiser l’origine des axes.
 Présence de Black Hole au sein du gabarit de calibrage.
Le principe du gabarit de calibrage est fondé sur le fait que les mesures
réalisées dans son champ de présence soient sans surprise. Mais il est
arrivé que le télémètre délivre un résultat erroné. Lorsque le laser pointe
précisément à l’angle du triangle, la distance mesurée peut être très
largement supérieure à la distance physique. Le cas n’a été formellement
identifié qu’une unique fois, mais compte tenu du point précédent, cela
suffit à remettre en question cette solution. Figure 64 - Black Hole au sein
du gabarit
Fonctionnalités
 Calibrage au moyen de switches
Le L6470 peut accepter le signal d’un switch en entrée et sur la base de ce signal stopper la rotation
du moteur. Ce principe pourrait être utilisé en lieu et place du gabarit afin de permettre une
calibration automatique sans calcul et peut-être plus précise. Le principe pourrait être généralisé au
deux axes de rotation et le positionnement du référentiel sphérique ne serait dépendant que de la
qualité de la mise en œuvre du scanner sur son trépied (niveau, orientation, etc.)
 Référence de positionnement par capteur angulaire
Les valeurs angulaires des coordonnées sont fournies par les pilotes des moteurs pas-à-pas. Même
dans le cas d’un moteur correctement apparié à son pilote, le microstepping peut induire un
glissement entre la position angulaire effective et celle maintenue par le pilote. L’ajout de capteurs
angulaires permettrait d’obtenir la position physique indépendamment du pilote de manière plus
objective.
48
(Stepper Motors)
60 Imhof Yannick
Formation en emploi
Travail de Bachelor
Conclusion
Le scanner 3D existe bel et bien, et sa réalisation respecte le cahier des charges défini lors de l’analyse
préliminaire. Un seul point fait exception, le temps ayant manqué pour l’intégration de Sketchup.
La conception mécanique a révélé une faiblesse dans le choix du type de la transmission, mais globalement
elle répond aux attentes qui lui sont adressées.
Malgré une capacité en termes de mémoire flash un peu restrictive, le microcontrôleur Yùn remplit son rôle
de chef d’orchestre. Les possibilités offertes par la présence de Linux n’ont certainement pas toutes été
identifiées.
Le télémètre a surpris par son comportement erratique au démarrage et à l’arrêt du laser, mais il a rendu ce
projet réalisable. A noter que sa fréquence de mesures est finalement en adéquation avec la structure
logicielle en grande partie asynchrone et dépendante d’implémentations tierces (bibliothèque Bridge). Le
fait d’avoir du temps entre deux mesures facilite la synchronisation.
Les pilotes moteurs ont offerts des capacités très riches, qui n’ont malheureusement pas pu être exploitées
du fait d’un mauvais choix en termes de moteurs pas-a-pas. C’est là certainement le principal élément
négatif, étant donné que ce seul point remet en cause jusqu’à la validité des coordonnées de mesures.
La méthodologie de calibrage pourrait être considérée comme le second point négatif si elle s’avérait
impossible à stabiliser.
La structure logicielle orientée services a pu être mise en œuvre malgré les différences en termes de
protocoles et de structure de données.
Plus personnellement, le simple fait de pouvoir tenir le scanner dans les mains et le voir fonctionner est déjà
une réussite. Ce projet devient ainsi la réalisation d’un vieux rêve : créer quelque chose de concret de bout
en bout.
Remerciements
Je tiens à remercier ma femme, Martine, souvent seule à gérer la maison, ainsi que mes enfants, Maël et
Aurélien, pour leur soutien sans faille à tous les trois durant ces 52 mois d’études, et pour qui ma présence a
pris trop souvent un aspect fantomatique. Je leur suis profondément reconnaissant pour leur patience, et
leur compréhension face aux absences répétées, et à tous les « bonne journée et à demain » lancés à 7h30
du matin sur le pas de porte.
Je remercie également Corine et ma maman pour leur relecture courageuse et les corrections d’orthographe.
Je remercie mon père pour ses encouragements et son aide matérielle.
Je remercie mes beaux-parents pour avoir pris le relai dans les améliorations de la maison attendues par ma
femme, et la conception du caisson de validation des mesures, ainsi qu’à Martine et Sébastien pour sa
réalisation.
Je remercie enfin tous ceux qui nous ont soutenu plus discrètement, que ce soit en gardant nos enfants dans
certains moments chargés, ou simplement en ayant une petite pensée positive à l’occasion, et je sais qu’ils
sont nombreux.
Imhof Yannick 61
Dossier de gestion
Rencontres avec M. Bressy
Date Objectifs
08.12.2015 Entrée en matière concernant le sujet du TB
Ebauche du cadre à donner au TB.
11.03.2016
Principe du concept basé sur un laser et une caméra.
Abandon du premier concept.
19.04.2016
Nouvelle orientation basée sur un télémètre.
Point de situation.
13.05.2016
Validation du schéma électronique.
02.09.2016 Point de situation Skype.
Signatures de l’affiche GAPS et du résumé.
16.09.2016
Démonstration du scanner.
Résumé d’activités
Les éléments qui suivent résument les activités de réalisation des semaines 27 à 38 2016, c’est-à-dire du
travail de bachelor en lui-même, sans le temps d’analyse préliminaire. Le détail complet est disponible dans
le CD accompagnant le présent document.
Semaine Heures Activités

Création du document de rédaction.
Réception du matériel électronique commandé.
27 25 Prise en main de la carte Arduino Yùn (IDE, mise à jour, configuration routeur).
Coordination avec l’atelier concernant l’axe de rotation du miroir.
Conception mécanique de l’axe de rotation du module.
Montage de l’axe de rotation du miroir.
28 23 Conception mécanique de l’axe de rotation du module.
Réalisation des dessins de fabrication du second lot.
Coordination avec l’atelier concernant l’axe de rotation du module.
Modification du télémètre et préparation des éléments électroniques.
Soudure et câblage.
29 34
Premier contact avec les bibliothèques Arduino.
Premières rotation des moteurs.
Rédaction.
Démarrage de l’implémentation du firmware.
Classe de base des périphériques SPI.
30 63 Classe de gestion des moteurs.
Classe de gestion du pont SPI/UART + LR4.
Ajout d’un second adaptateur de tension.
Premières mesures réalisées.
Problèmes de synchronisation et utilisation des interruptions.
31 45
Classe de gestion des cycles.
Stabilisation.
32 43 Premiers contacts avec la bibliothèque Bridge.
62 Imhof Yannick
Formation en emploi
Travail de Bachelor
Premières connexions depuis et vers l’extérieur.

Implémentation des cycles de scanning et de calibrage.
Implémentation du service de la centrale.
Premiers échanges entre le firmware et la centrale.
33 34 Implémentation de l’interpréteur de commandes.
Directives de compilation pour une compilation sélective.
Implémentation de l’interface côté REST
Première version beta du firmware et stabilisation.
Réception et montage du second axe de rotation.
34 51
Détection problème optique.
Démontage complet dû à la nécessité de modifier les pièces.
Rédaction.
Rédaction.
Implémentation de l’interface SOAP.
35 43
Réception des pièces modifiées et remontage de l’ensemble.
Problèmes de déphasage des moteurs partiellement résolus.
Double crash machine.
Double réinstallation complète du système.
36 73 Rédaction.
Développement de l’application cliente.
Affiche GAPS.
Développement de l’application cliente.
Affiche et résumé déposés sur GAPS.
37 81
Rédaction.
Démonstration du scanner à M. Bressy.
Rédaction et administratif.
38 24 Préparation du CD.
Remise du mémoire.
Imhof Yannick 63
Authentification
Le soussigné, Imhof Yannick, atteste par la présente avoir réalisé seul ce travail et n’avoir utilisé aucune autre
source que celles expressément mentionnées, si ce n’est les connaissances acquises durant ses études et son
expérience acquise dans une activité professionnelle.
Cugy, le 23.09.2016
Imhof Y.
64 Imhof Yannick
Formation en emploi
Travail de Bachelor
References
Table des illustrations
Figure 1 - Architecture générale du projet .........................................................................................................4
Figure 2 - Principe de mise en œuvre.................................................................................................................4
Figure 3 - Application cliente connectée et en attente ......................................................................................4
Figure 4 - Le scanner 3D réalisé..........................................................................................................................7
Figure 5 - Système de rotation selon l'axe vertical (vu de .................................................................................8
Figure 6 - Schéma électronique, pilotes des moteurs ........................................................................................9
Figure 7 - Schéma électronique, intégration du télémètre ..............................................................................10
Figure 8 - Vue en coupe des éléments mécaniques des axes de rotation .......................................................11
Figure 9 - Scanner 3D complet .........................................................................................................................11
Figure 10 - Architecture du projet ....................................................................................................................12
Figure 11 - Login du serveur web Linino, mot de passe "doghunter" ..............................................................14
Figure 12 - Mise à jour de l'image du microcontrôleur en ligne de commande ..............................................14
Figure 13 - Login du serveur web LuCI, mot de passe "arduino" .....................................................................15
Figure 14 - Terminal SSH connecté au système Linux du Yùn ..........................................................................15
Figure 15 - Configuration générale du système Linux ......................................................................................16
Figure 16 - Configuration DHCP du système Linux ...........................................................................................16
Figure 17 - Configuration Wifi du système Linux en client ..............................................................................17
Figure 18 - Invalider la réinitialisation automatique de la configuration Wifi .................................................18
Figure 19 - Paramétrage de la carte additionnelle LR4 ....................................................................................19
Figure 20 - Erreur au téléchargement du sketch via Wifi.................................................................................20
Figure 21 - Procédure de vérification de la tension délivrée par la broche MOSI ...........................................20
Figure 22 - Schéma de connexion SPI repris de Wikipedia ..............................................................................21
Figure 23 – Diagramme séquentiel du bus SPI .................................................................................................22
Figure 24 - Constantes Arduino pour la librairie SPI ........................................................................................22
Figure 25 - Diagramme séquentiel SPI du L6470..............................................................................................23
Figure 26 - Diagramme séquentiel SPI du SC16IS750 ......................................................................................23
Figure 27 - Les phases d'un moteur pas-à-pas bipolaire en mode « full step » ...............................................24
Figure 28 - Moteur pas-à-pas construit selon le style "can stack" ...................................................................24
Figure 29 - Activation du microstepping pour le L6470 ...................................................................................25
Figure 30 - Spécifications du type de moteur ..................................................................................................26
Figure 31 - Caractéristiques du couple délivré et du courant consommé en fonction de la vitesse ...............26
Figure 32 - Déterminer le coefficient BEMF maximum ....................................................................................28
Figure 33 - Outil de configuration automatique de la compensation BEMF....................................................29
Figure 34 - Compensation BEMF résultante.....................................................................................................31
Figure 35 - Signal PWM à destination d'un servo ............................................................................................34
Figure 36 - Schéma de classes du firmware (signatures masquées) ................................................................35
Figure 37 - Convention des géographes ...........................................................................................................37
Figure 38 - Système d'axes du scanner ............................................................................................................37
Figure 39 - Principe de calibrage du miroir (plan XZ du référentiel) ................................................................38
Figure 40 - Calibrage du miroir .........................................................................................................................39
Figure 41 - Calibrage du module (plan XY du référentiel) ................................................................................39
Figure 42 - Calibrage du module ......................................................................................................................40
Figure 43 - Calibrage du miroir .........................................................................................................................40
Imhof Yannick 65
Figure 44 - Processus de scanning ................................................................................................................... 41

Figure 45 - Résolutions de scanning ................................................................................................................ 43
Figure 46 - Structure du microcontrôleur Arduino Yùn................................................................................... 43
Figure 47 - Taille d'empreinte du sketch ......................................................................................................... 45
Figure 48 - S'assurer de la séquence de démarrage ........................................................................................ 46
Figure 49 - Service Windows du scanner 3D ................................................................................................... 47
Figure 50 - Structure d'une application pouvant accueillir des add-ins selon Microsoft ................................ 47
Figure 51 - Répertoire dédié aux add-ins. ....................................................................................................... 47
Figure 52 – Prise en charge de l’add-in ........................................................................................................... 48
Figure 53 - Solution de l'add-in de service web WCF ...................................................................................... 48
Figure 54 - Service WCF, interfaces REST et SOAP publiés .............................................................................. 49
Figure 55 - Décalage du miroir (M) par rapport à l'origine (O) ....................................................................... 51
Figure 56 - Positions extrêmes du point M...................................................................................................... 52
Figure 57 - Variation O'M en fonction de δ ..................................................................................................... 52
Figure 58 - Définition de la base de données .................................................................................................. 54
Figure 59 - Interface utilisateur de l'application cliente.................................................................................. 55
Figure 60 - Message d'erreur à la connexion à la centrale .............................................................................. 56
Figure 61 - Solution de l'application cliente .................................................................................................... 56
Figure 62 - Exemple de données présentes dans un fichier xyz ...................................................................... 57
Figure 63 - Nuage des points de mesure du scanner 3D ................................................................................. 58
Figure 64 - Black Hole au sein du gabarit ........................................................................................................ 60
Figure 65 - Configuration des réseaux Wifi sur le routeur N600 ..................................................................... 70
Figure 66 - Filtrage des accès par adresse physique ....................................................................................... 71
Figure 67 - Paramètres DHCP et réservation d'adresses ................................................................................. 71
Figure 68 - Exemple de connexion Putty ......................................................................................................... 72
Figure 69 - Alerte de sécurité à la première connexion Putty ......................................................................... 72
Figure 70 - Exemple de connexion via Putty ................................................................................................... 72
Figure 71 - Exemple de connexion via WinSCP................................................................................................ 73
Figure 72 - Arborescences locale et distante .................................................................................................. 73
66 Imhof Yannick
Formation en emploi
Travail de Bachelor
Documentation
Arduino. Arduino Yún. 2016. <http://playground.arduino.cc/Hardware/Yun>.
—. avrdude - not responding & other problems. 17 05 2014.

<http://forum.arduino.cc/index.php?topic=240802.msg1727359#msg1727359>.
—. Beginner's Introduction to Yun Web Services. 13 04 2015.

<http://forum.arduino.cc/index.php?topic=315554.0>.
—. Bridge Library for Yún devices. 2016. <https://www.arduino.cc/en/Reference/YunBridgeLibrary>.
—. Download the Arduino Software. 2016. <https://www.arduino.cc/en/Main/Software>.
—. Getting Started with the Arduino Yún. 2016. <https://www.arduino.cc/en/Guide/ArduinoYun>.
—. How to reduce program size. 04 07 2012. <http://forum.arduino.cc/index.php?topic=112878.0>.
—. Language Reference. 2016. <https://www.arduino.cc/en/Reference/HomePage>.
—. Servo library. 2016. <https://www.arduino.cc/en/Reference/Servo>.
—. SPI library. 2016. <https://www.arduino.cc/en/Reference/SPI>.
—. Upgrading the OpenWrt-Yun image on the Yún. 2016.

<https://www.arduino.cc/en/Tutorial/YunSysupgrade>.
Chimpler. Chimply Home. 2013. <http://www.chimply.com/Generator#classic-spinner,animatedCircle>.
Dr Scher, Aaron. Arduino Yun WiFi Example. 10 09 2014.

<http://aaronscher.com/Arduino_tutorials/Arduino_WiFi_Tutorial/arduinoyunwifi.html>.
Fraser, Simon. How to Use the vi Editor. 03 05 2013.

<https://www.washington.edu/computing/unix/vi.html>.
Gabarra, Mark. Is there an easy way to enumerate the bindings listed in configuration? 27 04 2006.
<https://blogs.msdn.microsoft.com/markgabarra/2006/04/27/is-there-an-easy-way-to-enumerate-
the-bindings-listed-in-configuration/>.
Gieck, K & R. Gieck - Formulaire technique - 11 ème édition. Bienne, 2007.
Hopkins, Tom. Simplifying Stepper Motor Systems. 2016.

<http://www.mouser.ch/simple_stepper_motor/>.
Kuphaldt, Tony R. Stepper Motors. 1996. <http://www.allaboutcircuits.com/textbook/alternating-

current/chpt-13/stepper-motors/>.
Manea, Sorin. «Stepper Motor Control with dsPIC DSCs.» 2009. Microchip.
<http://ww1.microchip.com/downloads/en/AppNotes/01307A.pdf>.
Meshlab. Meshlab homepage. 02 04 2014. <http://meshlab.sourceforge.net/>.
Microsoft. Entity Framework. 2015. <https://msdn.microsoft.com/en-us/data/ef.aspx>.
—. Extending Control Over Error Handling and Reporting. 2016. <https://msdn.microsoft.com/en-

us/library/ms751439(v=vs.110).aspx>.
Imhof Yannick 67
—. How to: Use a Custom User Name and Password Validator. 2016. <https://msdn.microsoft.com/en-
us/library/aa702565(v=vs.110).aspx>.
—. Planned and Unplanned Exceptions in WCF. 2016. <https://msdn.microsoft.com/en-

us/library/ff647138.aspx>.
—. Tracing and Message Logging. 2016. <https://msdn.microsoft.com/en-

—. Walkthrough: Creating a Windows Service Application. 2016. <https://msdn.microsoft.com/en-

us/library/zt39148a(v=vs.110).aspx>.
—. Walkthrough: Creating an Extensible Application. 2016. <https://msdn.microsoft.com/en-

us/library/bb788290(v=vs.110).aspx>.
—. Walkthrough: Passing Collections Between Hosts and Add-Ins. 2016. <https://msdn.microsoft.com/en-

us/library/bb384207(v=vs.100).aspx>.
—. What Is Windows Communication Foundation. 2016. <https://msdn.microsoft.com/en-

NMB Technologies Corporation. «Standard PG Step Motors.» s.d. Minebea Motors.

<http://www.nmbtc.com/pdf/motors/standard-pg/PG35S-D48-HHC2.pdf>.
NXP Semiconductors. «SC16IS740/750/760.» juin 2011. NXP products.

<http://www.nxp.com/documents/data_sheet/SC16IS740_750_760.pdf>.
Poli, Enrico. «Voltage mode control operation and parameter optimization.» 03 2015. STMicroelectronics.
<http://www.st.com/content/ccc/resource/technical/document/application_note/ad/fc/fb/f0/f7/c
7/4c/48/DM00061093.pdf/files/DM00061093.pdf/jcr:content/translations/en.DM00061093.pdf>.
Porcupine Electronics LLC. «LR4 Data Sheet.» 05 02 2013. LR4 - USB Laser Rangefinder.
<http://static1.squarespace.com/static/53a4c712e4b095f006b5b72c/t/53af20a1e4b02786d79e1b
4c/1403986081191/LR4+Data+Sheet.pdf>.
—. LR4 Sample software with source code. 05 02 2013. <http://www.porcupinelabs.com/lr4-sample-

software>.
Precision Microdrive. «Reading the motor constants from typical performance characteristics.» 02 02 2014.
Precision Microdrive. <https://www.precisionmicrodrives.com/tech-blog/2014/02/02/reading-
motor-constants-typical-performance-characteristics>.
Prikryl, Martin. WinSCP Downloads. 12 08 2016. <http://winscp.net/eng/download.php>.
Sacha, Barber. AddIn Enabled Applications. 05 2008. <http://www.codeproject.com/Articles/25866/AddIn-

Enabled-Applications>.
Saha, Prodip K. Custom Error Behavior by implementing IErrorHandler at WCF Service. 10 02 2013.
<http://www.aspnet4you.com/wcf/index.php/2013/02/10/76/>.
Simon Tatham followers. PuTTY Download Page. 10 03 2016.

<http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html>.
68 Imhof Yannick
Formation en emploi
Travail de Bachelor
Singh, Rahul Rajat. A Beginner's Tutorial on Creating WCF REST Services. 03 04 2013.
<http://www.codeproject.com/Articles/571813/A-Beginners-Tutorial-on-Creating-WCF-REST-
Services>.
SmartBear. SoapUI homepage. 2016. <https://www.soapui.org/>.
SparkFun. Getting Started with the AutoDriver. s.d. <https://learn.sparkfun.com/tutorials/getting-started-

with-the-autodriver>.
—. SparkFun AutoDriver Arduino Library. 04 05 2015.

<https://github.com/sparkfun/SparkFun_AutoDriver_Arduino_Library>.
ST Microelectronics. «Evaluation software with graphical user interface for STSPIN motor driver ICs.» 2016.
ST Microelectronics. <http://www.st.com/content/st_com/en/products/development-
tools/software-development-tools/motor-control-software-development-tools/stsw-
spin002.html>.
—. «L6470.» mars 2015. ST Microelectronics. <http://www.st.com/resource/en/datasheet/l6470.pdf>.
Telerik. Fiddler homepage. 2016. <http://www.telerik.com/fiddler>.
Tower Pro. Micro servo SG51R. 2016. <http://www.towerpro.com.tw/product/sg51r/>.
Wikimeca. Moteur à courant continu. 06 12 2015.

<http://wikimeca.org/index.php?title=Moteur_%C3%A0_courant_continu>.
Wikipedia. Coordonnées sphériques. 11 05 2016.

<https://fr.wikipedia.org/wiki/Coordonn%C3%A9es_sph%C3%A9riques>.
—. Point cloud. 04 06 2016. <https://en.wikipedia.org/wiki/Point_cloud>.
—. Representational state transfer. 15 09 2016.

<https://en.wikipedia.org/wiki/Representational_state_transfer>.
—. Serial Peripheral Interface Bus. 17 07 2016.

<https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus>.
—. Servomoteur. 16 06 2016. <https://fr.wikipedia.org/wiki/Servomoteur>.
—. Simple Object Access Protocol. 17 09 2016. <https://en.wikipedia.org/wiki/SOAP>.
Xamarin. Download Xamarin. 2016. <https://www.xamarin.com/download-

it?_bt=101035044668&_bk=xamarin&_bm=e&gclid=CNml_I3Qmc8CFcW4GwodbeQAQA>.
Imhof Yannick 69
Annexes
Paramétrage détaillé du routeur
Type de routeur : Netgear N600 gigabit dual band
Version du firmware : V1.0.7.98
Connexion à l’interface web :
 Adresse IP : 192.168.24.42
 Login administrateur : admin
 Mot de passe : yunscan3d
Paramétrage Wifi :
Figure 65 - Configuration des réseaux Wifi sur le routeur N600
70 Imhof Yannick
Formation en emploi
Travail de Bachelor
Figure 66 - Filtrage des accès par adresse physique
Clé de cryptage WPA2-PSK :

gxUxD99=t_9,PKkiyTaQvII(8#;PCts6sUoi{W5t$Z94Eb6p2\5!BL"*X}df%z!
Paramétrage DHCP :
Figure 67 - Paramètres DHCP et réservation d'adresses
Imhof Yannick 71
Connexion via Putty

Saisir l’adresse IP de l’hôte cible sur le port par défaut 22 en spécifiant le type de connexion SSH :
Figure 68 - Exemple de connexion Putty
Valider la connexion lors de l’alerte de sécurité :
Figure 69 - Alerte de sécurité à la première connexion Putty
Saisir les éléments de login sur le terminal :
 Utilisateur : root
Quelques commandes utiles :
 Console du microcontrôleur :
telnet localhost 6571
 Reset du microcontrôleur
reset-mcu
 Reboot Linux
/sbin/reboot
Figure 70 - Exemple de connexion via Putty
72 Imhof Yannick
Formation en emploi
Travail de Bachelor
Connexion via WinSCP

Saisir l’adresse IP de l’hôte cible sur le port par défaut 22 en spécifiant le protocole SCP. Les éléments de login
peuvent être prédéfini et enregistrés :
 Utilisateur : root
Figure 71 - Exemple de connexion via WinSCP
Naviguer jusqu’aux répertoires à synchroniser :
Figure 72 - Arborescences locale et distante
Imhof Yannick 73
Exemple de données renvoyées par le LR4

Les lignes qui suivent sont extraites d’un journal de debug généré pendant l’un des tests d’acquisition de
données réalisés sur le télémètre. Elles donnent une idée du caractère erratique des données reçues au
démarrage du laser et du temps nécessaire à la stabilisation du flux.
Les mesures sont reconnaissables à leur séquence de 7 codes ASCII terminée par un retour de chariot (cariage
return #13 – line feed #10, ou « 0xD-0xA »). A noter le fait qu’une bonne partie de ces mesures sont des
caractères « 0 » (ASCII 0x30)
Le problème principal est constitué par les séquences ininterrompues de « 0 », lesquelles la plupart du temps,
saturent le buffer du FIFO UART.
- < Start > - 30-30-30-30-30-D-A
Range finder (CS:8) is online RHR FIFO empty.
Triggered! (3) - Count:4
Manufacturer: Porcupine Electronics 30-30-34-37-35-D-A
Product: LR4 + Fluke 414D 30-30-34-37-35-D-A
Hardware Version: Rev 5 30-30-34-37-35-D-A
Firmware Version: 2.0.3 30-30-34-37-35-D-A
Serial Number: 002051 30-30-34-37-35-D-A
30-30-34-37-35-D-A
2051 30-30-34-37-35-D-A
Enabling laser 30-30-34-37-35-D-A
- < End > - 30-30-34-37-35-D-A
Triggered! (2) - Count:0 30-30-34-37-35-D-A
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-RHR FIFO empty. 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
Triggered! (2) - Count:1 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-D-A 30-30-30-30-30-30-30-30-30-30-30-RHR FIFO
RHR FIFO empty. empty.
Triggered! (3) - Count:2 Triggered! (2) - Count:5
30-30-34-37-35-D-A 30-30-30-30-30-D-A
30-30-34-37-35-D-A RHR FIFO empty.
30-30-34-37-35-D-A Triggered! (3) - Count:6
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-34-37-35-D-A
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-34-37-35-D-A
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-34-37-35-D-A
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-34-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
30-30-30-30-30-30-30-30-30-30-30-30-RHR FIFO 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
empty. 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
Triggered! (2) - Count:3 30-30-30-30-30-30-30-30-30-30-30-30-30-30-30-
74 Imhof Yannick
Formation en emploi
Travail de Bachelor
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-34-37-35-D-A
30-30-30-30-30-RHR FIFO empty. RHR FIFO empty.
30-30-30-30-30-D-A 30-30-34-37-35-D-A
RHR FIFO empty. RHR FIFO empty.
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-34-37-35-D-A 30-30-34-37-35-D-A
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- RHR FIFO empty.
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- Triggered! (2) - Count:16
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-34-37-35-D-A
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- RHR FIFO empty.
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- Triggered! (2) - Count:17
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-34-37-35-D-A
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- RHR FIFO empty.
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- Triggered! (2) - Count:18
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-34-37-35-D-A
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- RHR FIFO empty.
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- Triggered! (2) - Count:19
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-34-37-35-D-A
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- RHR FIFO empty.
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- Triggered! (2) - Count:20
30-30-30-30-30-30-30-30-30-30-30-30-30-30-30- 30-30-34-37-35-D-A
30-RHR FIFO empty. RHR FIFO empty.
Triggered! (2) - Count:9 Disabling laser
30-30-30-30-30-D-A
RHR FIFO empty.
Triggered! (2) - Count:10
Imhof Yannick 75
Liste des dessins de fabrication

Lot de fabrication n°1
 Dessins d’usinage
o YIM001-02 Flasque de poulie réceptrice
o YIM002-02 Flasque de poulie moteur
o YIM006-00 Palier
o YIM007-00 Longeron
o YIM008-00 Support
o YIM009-00 Coupleur
o YIM011-00 Longeron
o YIM015-02 Butée de miroir
o YIM015-03 Mord de miroir
o YIM017-00 Tige
o YIM102-01 Poulie motrice
o YIM104-01 Axe de tendeur
o YIM110-00 Axe moteur
o YIM113-00 Entretoise extérieure
o YIM114-00 Entretoise intérieure
o YIM201-01 Poulie réceptrice
o YIM203-00 Axe de miroir
o YIM315-01 Support de miroir
 Impressions 3D
o YIM316-00 Support de l’électronique
o YIM018-00 Interface de trépied
Lot de fabrication n°2

 Dessins d’usinage
o YIM019-01 Poulie réceptrice
o YIM020-00 Axe
o YIM021-00 Châssis
o YIM022-01 Poulie motrice
o YIM023-00 Palier
o YIM024-01 Axe de tendeur
 Impressions 3D
o YIM025-00 Support de servo
o YIM026-00 Gabarit de calibrage
o YIM027-00 Support des adaptateurs TTL
76 Imhof Yannick
4 3 2 1
F F
1
1
15° A
E E
49 H7
56.75
61
Ra 0.8
A
1.50
D D
COUPE A-A
C C
0.2 0.3
Ra 3.2
( )
B B
Tolérances générales ISO 2768-m
SAUF INDICATION CONTRAIRE: FINITION: CASSER LES
LES COTES SONT EN MILLIMETRES ANGLES VIFS
NE PAS CHANGER L'ECHELLE REVISION 01
ETAT DE SURFACE: Ra 3.2
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
HEIG-VD - Scanner 3D
NOM SIGNATURE DATE TITRE:
AUTEUR
VERIF.
Imhof Y. 31.05.2016
Flasque suiveuse
APPR.
FAB.
A MATERIAU: No. DE PLAN

A
YIM001-02
QUAL.
C45 A4
Dim: Ø 65
Nb: 2
MASSE: ECHELLE:1:1 FEUILLE 1 SUR 1
4 3 2 1
4 3 2 1
F F
15°
1
A
E E
A
21 H7
29.75
34
Ra 0.8
D D
1.50
COUPE A-A
C C
0.2 0.3
Ra 3.2
1:1
( )
B B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 31.05.2016
Flasque moteur
APPR.
FAB.

A
YIM002-02
QUAL.
C45 A4
Dim: Ø 35
Nb: 2
4 3 2 1
8 7 6 5 4 3 2 1
F F
56
28
22.50 22.50
10 10
B
6.40
E E
4x
0.50
R0
.30
C
22.50
.30
R0
47 H7
60
45°
45°
D D
22.50
Ra 0.8
30
DÉTAIL C
ECHELLE 2 : 1
B
2x M6 COUPE B-B
C C
13 13
0.2 0.3
Ra 3.2
( )
14
B Tolérances générales ISO 2768-m B

28
1:2
TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
AUTEUR
VERIF.
Imhof Y. 31.05.2016
Palier
APPR.
FAB.
A MATERIAU:
AIMgSi1 No. DE PLAN
A
YIM006-00
QUAL.
Dim: 60 x 30
A3
Nb: 1
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
100
F 4 F
28 37 2x 15 x 45
22.50 22.50
A 2x 0.5 x 45
8 ±0.05
Ra 0.8
E 8.50 9 E
22.50
3.
4 H12
20.50
40
43
8.50
9
16
18 ±0.05
60
8.50
D D
22.50
60
3.
2
6.
40
30
4 H1
8.50
4x
18 ±0.05
C A C
COUPE A-A
0.2 0.3
Ra 3.2
( )
1:2
TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
AUTEUR
VERIF.
Imhof Y. 16.09.2016
Longeron
APPR.
FAB.
A MATERIAU:
EN AW-6060 No. DE PLAN
A
YIM007-00
QUAL.
Dim: 4 x 60
A3
Nb: 1
8 7 6 5 4 3 2 1
4 3 2 1
F 8.50 9 F
A
B
4 H12
8.50
19
18 ±0.05
E E
8.50
4 H12
A 8.50
4x 1 x 45 COUPE A-A
18 ±0.05
D 25 6 D
M3 3.40
C C
COUPE B-B
0.2 0.3
Ra 3.2
( )
B 1:1 B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 16.09.2016
Support
APPR.
FAB.

A
YIM008-00
QUAL.
EN AW - 6082 A4
Dim: 25
Nb: 2
4 3 2 1
4 3 2 1
F F
15
4.50 4.50
A 4x M3
E E
Ra 0.8
5 H7
14
A COUPE A-A
0.5 x 45 0.5 x 45
D D
C C
0.2 0.3
Ra 3.2
1:1
( )
B B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 31.05.2016
Coupleur
APPR.
FAB.

A
YIM009-00
QUAL.
9SMnPb28 A4
Dim: Ø14
Nb: 1
4 3 2 1
8 7 6 5 4 3 2 1
F 100 F
28 54
23.50 23.50
22.50 22.50
2x 15 x 45 4
E 3 E
2xM
43
22.50
21
3
4x M
24
9
60
D D
9
22.50
21
0
6.6
30
4x
C C
0.2 0.3
Ra 3.2
( )
B 1:2 Tolérances générales ISO 2768-m B
TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
AUTEUR
VERIF.
Imhof Y. 15.05.2016
Longeron
APPR.
FAB.
A MATERIAU:
A
YIM011-00
QUAL.
Dim: 4 x 60
A3
Nb: 1
8 7 6 5 4 3 2 1
4 3 2 1
F F
15
Ra 1.6
3
E E
12
3.40
3
3
D D
C C
0.2 0.3
Ra 3.2
( )
B B
ETAT DE SURFACE: N8
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
Butée miroir
AUTEUR Imhof Y. 14.05.2016
VERIF.
APPR.
FAB.

A
YIM015-02
QUAL.
EN AW-6060 A4
Dim: 4 x 15
Nb: 1
4 3 2 1
4 3 2 1
F F
15
E 12 E
3
M3
12
3.40
6
3
D 3 D
Ra 1.6
C C
0.2 0.3
Ra 3.2
( )
B B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 14.05.2016
Mord miroir
APPR.
FAB.

A
YIM015-03
QUAL.
EN AW-6060 A4
Dim: 4 x 15
Nb: 1
4 3 2 1
4 3 2 1
F F
65
E E
0.50 x 45 0.50 x 45
5 h6
M3
4.50
9.50
D D
C C
0.2 0.3
Ra 3.2
( )
B 1:1 B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 20.05.2016
Tige
APPR.
FAB.

A
YIM017-00
QUAL.
C45 rectifié ( h6 ) A4
Dim: Ø5h6
Nb: 3
4 3 2 1
8 7 6 5 4 3 2 1
F F
6.50 16 3.50
1.50 1.50
Angle vif Angle vif
Ra 0.8 Denture T5
z = 18
E 21 p6 E
21 p6
27.80
Ra 0.8
5 H7
14
14
1.50
D D
Ra 0.8
2 x M3
15° 15°
3.50
C 1 x 45 1 x 45 C
0.2 0.3
1:1 Ra 3.2
( )
R1
R1

TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
AUTEUR
VERIF.
Imhof Y. 20.05.2016
Poulie motrice
APPR.
FAB.
A MATERIAU:
EN AW - 6082 No. DE PLAN
A
YIM102-01
QUAL.
Dim: T5 z=18 Ø27.80
A3
Nb: 1
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
F F
3 26
9 14.50
-0.10
8 -0.20
E 0.5 x 45 0.5 x 45 E
0.5 x 45 0.5 x 45
4 h6
0.5 x 45
A
0
.2
2
R0
M6
14
8
20
R0.
3.70 -0.10
0
D D
7 0.50
11 13
Angles vifs
+0.10
12.40 0
DÉTAIL A
C ECHELLE 5 : 1 C
0.2 0.3
Ra 3.2
( )
B 1:1
Tolérances générales ISO 2768-m B
TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
AUTEUR
VERIF.
Imhof Y. 20.05.2016
Axe tendeur
APPR.
FAB.
A MATERIAU:
9SMnPb28 No. DE PLAN
A
YIM104-01
QUAL.
Dim: Ø14
A3
Nb: 1
8 7 6 5 4 3 2 1
4 3 2 1
F F
49
E 6 6 E
3
Ra 0.8
5 h6
0.50 x 45 0.50 x 45
D D
C C
0.2 0.3
Ra 3.2
1:1
( )
B B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 14.05.2016
Axe moteur
APPR.
FAB.

A
YIM110-00
QUAL.
C45 A4
Dim: Ø5 h6
Nb: 1
4 3 2 1
4 3 2 1
F F
0
10 -0.10
0.5 x 45 0.5 x 45 A
E E
+0.30
30 +0.10
34
D D
A
COUPE A-A
C C
0.2 0.3
Ra 3.2
( )
B 1:1 B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 14.05.2016
Entretoise ext.
APPR.
FAB.

A
YIM113-00
QUAL.
EN AW - 6082 A4
Dim:Ø 35
Nb: 1
4 3 2 1
4 3 2 1
0
10 -0.10
F
0.5 x 45 0.5 x 45 A F
E E
-0.10
47 -0.30
42
D D
A
COUPE A-A
C C
0.2 0.3
Ra 3.2
( )
B 1:1 B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 14.05.2016
Entretoise int.
APPR.
FAB.

A
YIM114-00
QUAL.
EN AW - 6082 A4
Dim: Ø50
Nb: 1
4 3 2 1
8 7 6 5 4 3 2 1
F F
21
19 ±0.05
1.50 1.50
15
° 15°
A
1.50
1.50
Denture T5
Ra 0.8 z=36
E E
3.40
19 ±0.05
6.50
°
B
4x 30
38
4x
4x
49 p6
30 H7
56.45
D D
0.02 B
5 H7
0.50 x 45
2x
19 ±0.05
Ra 0.8 0.50 x 45
3x
Ra 0.8
C C
Angle vif Angle vif A

COUPE A-A
0.2 0.3
Ra 3.2
( )
B !! Adaptation d'une poulie existante !! Tolérances générales ISO 2768-m B
TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
AUTEUR
VERIF.
Imhof Y. 20.05.2016
Poulie suiveuse
APPR.
FAB.
A MATERIAU:
EB AW - 6082 No. DE PLAN
A
YIM201-01
QUAL.
1:1 Dim: T5 z=36 Ø56.45
A3
Nb: 1
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
F F
63
32 8 17.50 A
0.50 x 45 0.50 x 45 0.50 x 45
C B 0.50 x 45
E E
4x 3
0°
28.60 -0.10
0.05 D
30 H7
30 H7
0
34
25
48
D D
Ra 0.8 Ra 0.8
Ra 1.6
8x M3
+0.20
1.60 0
+0.10 38
C 29.50 0 Ra 1.6 C
COUPE A-A
0.2 0.3
Ra 3.2
2.50 0.20 1:2 ( )
B 15°
R0.16 Tolérances générales ISO 2768-m B
15°

TOLERANCES:
LINEAIRES: ± 0.1 HEIG-VD - Scanner 3D
R0
ANGULAIRES: ± 30'
.4 NOM SIGNATURE DATE TITRE:

0
Axe miroir
1
0.30
DÉTAIL C
VERIF.
DÉTAIL B ECHELLE 4 : 1
APPR.
FAB.
A ECHELLE 4 : 1 MATERIAU:
A
YIM203-00
QUAL.
Dim: Ø 50
A3
Nb: 1
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
19 ±0.05 19 ±0.05
21
F 10 A F
0.50 x 45 0.50 x 45
E E
0.50 x 45
30
20
50
6.50
5 H7
12.50
19 ±0.05
Ra 1.6
3x
D Ra 1.6 D
3
COUPE A-A
A
Ra 1.6
2x M3 3x M3
Ra 1.6
12
C 25.40 C
0.2 0.3
Ra 3.2
( )
TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
3
AUTEUR
VERIF.
Imhof Y. 28.08.2016
Support mirroir
APPR.
9 FAB.
A MATERIAU:
A
YIM315-01
QUAL.
A3
5 Dim: Ø 50
Nb: 1
8 7 6 5 4 3 2 1
4 3 2 1
F F
E E
D D
C C
0.2 0.3
Ra 3.2
( )
B B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 16.09.2016
Support
APPR.
FAB.
électronique
A
YIM316-00
QUAL.
n/a A4
4 3 2 1
4 3 2 1
F F
E E
D D
C C
0.2 0.3
Ra 3.2
( )
B B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 16.09.2016
Interface trépied
APPR.
FAB.

A
YIM018-00
QUAL.
n/a A4
4 3 2 1
8 7 6 5 4 3 2 1
27
21
F 14 1.50 F
12 0.50 x 45
1.50 15°
15
°
COUPE A-A A
1.50
1.50
Ra 0.8 Denture T5
z = 36
E E
2x M6
D B
13
E
C
49 p6
0.05 D
0.1 D
40 H7
17 H7
56.45
34
14
38
D D
Ra 0.8
2x
13
Ra 0.8
R0.3
0
C C
Angle vif Angle vif A

Ra 0.8
Ra 0.8
10.50 0.2 0.3

Ra 3.2
4.50 ±0.05
0.05 E !! Adaptation d'une poulie existante !! ( )
B Rainure de clavette héritée à
positionner selon dessin. Tolérances générales ISO 2768-m B
R0
0
.3
.3
R0

TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
0.20
0.90
15°
Poulie suiveuse
15
1.40
0.20

°
VERIF.
15° 15°
APPR.
FAB.
trépied
A DÉTAIL C MATERIAU:
EB AW - 6082 No. DE PLAN
A
YIM019-01
QUAL.
0.10 A3
DÉTAIL B 2 0.10 Dim: T5 z=36 Ø56.45
ECHELLE 5 : 1 Nb: 1
1.50
ECHELLE 5 : 1 MASSE: ECHELLE:2:1 FEUILLE 1 SUR 1
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
F F
37.50 26.50
0
A
3.60
24.50 -0.10
12
6x
E
+0.20
8 0
R1 0.05 E
E 6
Ra 0.8
E
D
B C
30°
Ra 0.8
0.05 D
17 j6
6 x 60°
9 j6
60
42
34
12
26
52
M4
D D
6.60
11
Ra 0.8
2x
2x
Ra 0.8
°
135
0.50 x 45
C 1 x 45 0.50 x 45 C
3
COUPE A-A A
7
11
25
0.2 0.3
Ra 3.2
0.10 2 1.50 ( )
B 15° 0.10 1:2 Tolérances générales ISO 2768-m B
15°
TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
SIGNATURE DATE TITRE:
15°
NOM
Axe trépied
15°
0.20
0.90
0.20
1.40

0
.3
VERIF.
R0
APPR.
DÉTAIL C
FAB.
A DÉTAIL B MATERIAU:
A
YIM020-00
QUAL.
Dim: Ø 60
A3
ECHELLE 5 : 1 ECHELLE 5 : 1 Nb: 1
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
F F
150
30 94
16.50 47 26 ±0.05
10.51 13 ±0.05
5
E
7.50 A 11.5011.50
2x 0.50 x 45 E
30°
30°
2 M3
2
14
8 ±0.05
x
7 Ra 0.8
x
M
2x
4
M3
13 ±0.05
11.5011.50
30°
15
26 ±0.05
60
R1 2x
41.25
3 5 H7
D D
30
M3
6.04
30°
6xM 30°
R21
3
6
30° A
6 x 60°
14 COUPE A-A
C C
0.2 0.3
Ra 3.2
1:2 ( )
TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
AUTEUR
VERIF.
Imhof Y. 15.07.2016
Chassis trépied
APPR.
FAB.
A MATERIAU:
A
YIM021-00
QUAL.
Dim: 60 x 5
A3
Nb: 1
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
F F
13 16
1.50 1.50
8 15° 15°
A
COUPE A-A 2 x M3
1.50
Denture T5
E Ra 0.8 z = 18 E
Ra 0.8
B
0.50 x 45
21 p6
0.1 C
27.80
10 k6
Ra 0.8
5 H7
15
10
2x
D 0.05 C D
C
Angle vif
10
Angle vif A
1.10
0.20
R0
.40
15°
C C
8°
2 0.10
DÉTAIL B
ECHELLE 5 : 1 0.2 0.3
Ra 3.2
1:1 ( )
TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
10.50 AUTEUR
VERIF.
Imhof Y. 15.07.2016
Poulie motrice
APPR.
FAB.
trépied
A MATERIAU:
A
YIM022-01
QUAL.
Dim: T5 z=18 Ø27.80
A3
Nb: 1
8 7 6 5 4 3 2 1
4 3 2 1
26 ±0.05
13 ±0.05
F A 11.50 11.50
F
COUPE A-A
B
13 ±0.05
11.50
5 H7
E E
26 ±0.05
26 H7
2x
11.50
D 4x 1 x 45 A D
35
COUPE B-B
8
C C
2x 4.50
0.2 0.3
1:1 Ra 3.2
( )
B B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 16.07.2016
Support
APPR.
FAB.

A
YIM023-00
QUAL.
EN AW - 6082 A4
Dim:  35
Nb: 1
4 3 2 1
8 7 6 5 4 3 2 1
F F
3 29.50
9
0.50 x 45 0.50 x 45
13
0.50 x 45 0.50 x 45
0.50 x 45
E E
4 h6
Ra 0.8
-0.10
8 -0.20
M6
14
B
2
.20
R0
A
3.70 -0.10
7
0
D 11 D
+0.10
12.40 0
14.50
C C
0.50
R0
.3
0
Angle vifs
0.2 0.3
0.20
Ra 3.2
( )
°
0.90
15

15°
0.10 DÉTAIL A DÉTAIL B SAUF INDICATION CONTRAIRE: FINITION: CASSER LES
1.50 ECHELLE 5 : 1 ECHELLE 5 : 1
LES COTES SONT EN MILLIMETRES
ANGLES VIFS
TOLERANCES:
LINEAIRES: ± 0.1
ANGULAIRES: ± 30'
AUTEUR
VERIF.
Imhof Y. 15.07.2016
Axe tendeur
APPR.
FAB.
trépied
A MATERIAU:
9SMnPb28 No. DE PLAN
A
YIM024-01
QUAL.
Dim: Ø14
A3
Nb: 1
8 7 6 5 4 3 2 1
4 3 2 1
F F
E E
D D
C C
0.2 0.3
Ra 3.2
( )
B B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 16.09.2016
Support servo
APPR.
FAB.

A
YIM025-00
QUAL.
n/a A4
4 3 2 1
4 3 2 1
F F
E E
D D
C C
0.2 0.3
Ra 3.2
( )
B B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
AUTEUR
VERIF.
Imhof Y. 16.09.2016
Gabarit
APPR.
FAB.

A
YIM026-00
QUAL.
n/a A4
4 3 2 1
4 3 2 1
F F
E E
D D
C C
0.2 0.3
Ra 3.2
( )
B B
TOLERANCES:
LINEAIRES:
ANGULAIRES:
± 0.1
± 30'
Support
adaptateurs TTL
VERIF.
APPR.
FAB.

A
YIM027-00
QUAL.
n/a A4
4 3 2 1

Imhof Yannick

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Imhof Yannick

Transféré par

Droits d'auteur :

Formats disponibles

cmd

Auteur Imhof Yannick

Yverdon-les-Bains, novembre 2015

Figure 1 - Architecture générale du projet

Un laser, réfléchi par un miroir, est orienté selon deux axes de

La mesure de la distance est assurée par un télémètre laser modifié

La centrale relaie les commandes de l’application cliente vers le

Finalement, elle les transmet à l’application cliente

Une fois les données reçues, le client permet d’exporter

Figure 3 - Application cliente connectée et en attente

Table des matières

Service web WCF ..................................................................................................................................... 48

Figure 4 - Le scanner 3D réalisé

Complément aux éléments de la pré-étude

Figure 5 - Système de rotation selon l'axe vertical (vu de

Composants électroniques et électromécaniques

Le composant choisi est un SG51R de Tower Pro1 de faible encombrement

Figure 6 - Schéma électronique, pilotes des moteurs

Figure 7 - Schéma électronique, intégration du télémètre

 Le diamètre du puit de lumière au centre du système a été augmenté

 Le télémètre a été déplacé de manière à permettre le bon fonctionnement conjoint de l’ensemble

Figure 8 - Vue en coupe des éléments mécaniques des axes de rotation

Figure 9 - Scanner 3D complet

Figure 10 - Architecture du projet

Il publie deux SSID :

 SCAN3DG en b/g/n 2.4 GHz

 Interface Wifi des services web : 192.168.24.43

Le paramétrage détaillé du routeur est disponible en annexe du présent document.

Tous ces outils sont en libre accès au téléchargement.

Préparation du microcontrôleur Arduino Yùn

Mise à jour de l’image système du Yùn

Figure 11 - Login du serveur web Linino, mot de passe "doghunter"

Figure 12 - Mise à jour de l'image du microcontrôleur en ligne de commande

Figure 13 - Login du serveur web LuCI, mot de passe "arduino"

Figure 14 - Terminal SSH connecté au système Linux du Yùn

Configuration de la pile réseau OpenWRT

Figure 15 - Configuration générale du système Linux

Figure 16 - Configuration DHCP du système Linux

Figure 17 - Configuration Wifi du système Linux en client

Invalider la réinitialisation automatique de la configuration Wifi

Figure 18 - Invalider la réinitialisation automatique de la configuration Wifi

Obtenir la date courante avec une précision à la nanoseconde

Configuration préalable du télémètre

Au final, les paramètres appliqués sont les suivants :

 Les mesures sont réalisées en mètres.

Figure 19 - Paramétrage de la carte additionnelle LR4

Problème de téléchargement du sketch via Wifi

Figure 20 - Erreur au téléchargement du sketch via Wifi

Figure 21 - Procédure de vérification de la tension délivrée par la broche MOSI

Figure 22 - Schéma de connexion SPI repris de Wikipedia

Figure 23 – Diagramme séquentiel du bus SPI

Figure 24 - Constantes Arduino pour la librairie SPI

ST L6470 – pilote de moteur pas-à-pas

Figure 25 - Diagramme séquentiel SPI du L6470

 Fréquence d’horloge : 5'000'000 [Hz]

SC16IS750 – pont SPI – UART

Figure 26 - Diagramme séquentiel SPI du SC16IS750

 Fréquence d’horloge : 400'000 [Hz]

Gestion des moteurs pas-à-pas

Figure 28 - Moteur pas-à-pas construit selon le style "can stack"

Figure 29 - Activation du microstepping pour le L6470

Figure 30 - Spécifications du type de moteur

Figure 31 - Caractéristiques du couple délivré et du courant consommé en fonction de la vitesse

Les caractéristiques à retenir sont :