Upload
haphuc
View
230
Download
0
Embed Size (px)
Citation preview
Mémoire de fin d’études
Asservissement visuel d’un robot parallèle à
câbles pour la réalisation d’une fresque verticale
de grande taille
Maximilien Lesellier
INSA de Strasbourg, Mécatronique
Université de Strasbourg, Master IRIV, Parcours AR
Sous la direction de Pr. Jacques Gangloff
Septembre 2015
Mémoire de fin d’études Condensé
Institut National des Sciences Appliquées de Strasbourg
PROJET DE FIN D’ÉTUDES
Auteur : LESELLIER Maximilian Promotion : 2015
Titre : Asservissement visuel d’un robot paral-lèle à câbles pour la réalisation d’une fresqueverticale de grande taille
Soutenance : Septembre
Structure d’accueil : Icube, équipe AVR
Nb de volume(s) : 1 Nb de pages : 78
Nb de références bibliographiques : 34
Résumé :
La robotique parallèle à câbles est une approche récente en robotique, qui offre la possibilitéd’atteindre un espace de travail vaste par rapport aux dimensions du robot, mais au prix d’uneprécision faible. Un robot parallèle à câbles ayant moins de câbles que de degrés de libertéest dit sous contraint, c’est le cas dans cette étude.
En traçant en boucle ouverte une fresque au tableau avec le robot à deux câbles, on constateune importante distorsion de l’image. On tente dans un premier temps de compenser cetteerreur de distorsion en boucle ouverte ; en modifiant la consigne de façon à éliminer cetteerreur. Cela permet d’améliorer significativement la fresque, mais le résultat n’est pas parfait.
La solution était alors de fermer la boucle en apportant une information visuelle supplémen-taire. La plateforme du robot permettant d’ajouter une caméra et un programme de vision,on utilise cette solution. Le traitement d’images a été développé mais l’étude s’est arrêtée làpour des raisons techniques.
Mots clés : Robot à câbles, asservissement, vision
Traduction :
Cable driven parallel robotics is a recent approch in the robotics field, that allows to reacha wide workspace according to the robot’s dimensions, but at the price of a low accuracy. Acable driven parallel robot with less cables than degrees of freedom is underconstrained, it iscurrently the case for this work.
Tracing a fresco with the two cables robot used open loop, we can see an important distorsionof the picture. We first try to compensate this error in open-loop, by modifying the commandto eliminate this error. This does significantly improve the fresco, but the result is far fromperfect.
The solution is then to add a visual information. The platform of the robot already allows toadd a camera and run a vision application, so we will use this solution. The vision applicationhas been developped so far but the study had to stop there for technical reasons.
0 de 79 Maximilian Lesellier
Mémoire de fin d’études Sommaire
Sommaire
Condensé 1
Sommaire 2
Table des figures 4
Remerciements 6
Introduction 7
1 Contexte du stage 8
1.1 Présentation du cadre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1 Laboratoire Icube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2 Équipe AVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1.3 Pôle API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Robotique parallèle à câbles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.1 Présentation du concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.2 Travaux de l’équipe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.3 Des problèmes de stabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2.4 Actionnement embarqué . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2.5 Le projet PiSaRo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Approche mécanique 17
2.1 Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.1 Notations utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.2 Calcul de l’angle α . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.3 Gestion du stylo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2 Modélisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.1 Fonction de transfert du robot . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2 Mesure de la position du robot dans le repère R1 . . . . . . . . . . . . . . . 27
2 de 79 Maximilian Lesellier
Mémoire de fin d’études Sommaire
2.2.3 Tension et déformation des câbles . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.4 Réglage du correcteur sur la consigne en position . . . . . . . . . . . . . . 29
2.2.5 Générateur de trajets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Essais sur le système réel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1 Caractérisation de l’erreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.2 Influence du stylo sur l’erreur . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.3 Compensation de la distorsion . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.3.4 Autre approche de la compensation de l’erreur . . . . . . . . . . . . . . . . 38
3 Vision par ordinateur 40
3.1 Réalisation d’un traitement d’images adapté . . . . . . . . . . . . . . . . . . . . . 42
3.1.1 Les techniques utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.2 Construction du filtre utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.3 Seuillage par hystérésis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.1.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.5 Segmentation et classification . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Programmation embarquée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.1 Considérations matérielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.2 Capture de l’image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.3 Partie GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2.4 Boucle principale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.2.5 Résultats de la partie vision . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Concusion 64
Bibliographie 65
Annexes 69
A Détermination expérimentale du centre de gravité 69
B Modèle du robot 70
C Réglage d’un correcteur PID par approches successives 71
D Générateur de trajectoires 75
E Source des shaders 76
E.1 Vertex shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
E.2 Fragment shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3 de 79 Maximilian Lesellier
Mémoire de fin d’études Table des figures
Table des figures
Chapitre 1 - Contexte du stage 8
1.1 Organisation du laboratoire Icube et projets communs . . . . . . . . . . . . . . . 10
1.2 Télécom Physique Strasbourg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Exemple d’un robot à 2 câbles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Le robot FALCON-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Lego : la brique EV3 et quelques périphériques . . . . . . . . . . . . . . . . . . . 15
1.6 Schéma de l’utilisation de RPIt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapitre 2 - Approche mécanique 17
2.1 Schéma du système avec les notations employées . . . . . . . . . . . . . . . . . . 19
2.2 Tableau des paramètres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Les efforts appliqués au système . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Variation de α dans l’espace de travail . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Pseudo-code de l’algorithme de recherche par dichotomie . . . . . . . . . . . . . 23
2.6 Utilisation du processeur par l’asservissement . . . . . . . . . . . . . . . . . . . 23
2.7 La position du feutre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.8 Gestion du feutre dans RPIt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.9 Modélisation d’un moteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10 Schéma de la mesure de position du robot . . . . . . . . . . . . . . . . . . . . . . 28
2.11 Comparaison entre consigne et mesure de position du robot . . . . . . . . . . . 29
2.12 Schéma du correcteur utilisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.13 Valeur des correcteurs du PID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.14 Comparaison de la précision pour un échelon de consigne de 100mm . . . . . . 31
2.15 Générateur de trajets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.16 Tracé d’un carré distordu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.17 Essai de répétabilité de l’erreur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4 de 79 Maximilian Lesellier
Mémoire de fin d’études Table des figures
2.18 Mesure de la distorsion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.19 Distorsion avec/sans stylo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.20 Influence du frottement visqueux sur le suivi de trajectoire . . . . . . . . . . . . 36
2.21 Lieux des points réels et mesurés . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.22 Image après correction par matrice de distorsion . . . . . . . . . . . . . . . . . . 38
Chapitre 3 - Vision par ordinateur 40
3.1 Exemple d’érosion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Opérateur d’érosion choisi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3 Somme des valeurs des pixels voisins . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4 Filtre conjuguant érosion et somme . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5 Pseudo-code de l’algorithme de traitement des images . . . . . . . . . . . . . . . 50
3.6 Visualisation du traitement d’images . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7 Pseudo-code de l’algorithme de floodfill . . . . . . . . . . . . . . . . . . . . . . . 51
3.8 Algorithme de segmentation et classification . . . . . . . . . . . . . . . . . . . . 53
3.9 Module caméra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.10 Composant camera MMAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.11 Modes d’acquisition de la caméra . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.12 Pipeline de rendu graphique avec les différents shaders . . . . . . . . . . . . . . 59
3.13 Algorithme de traitement d’images . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Annexes 69
A.1 Détermination du centre de gravité . . . . . . . . . . . . . . . . . . . . . . . . . . 69
B.1 Modèle du robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
C.1 Réglage d’un correcteur PID par approches successives . . . . . . . . . . . . . . 71
D.1 Source du générateur de trajectoires . . . . . . . . . . . . . . . . . . . . . . . . . 75
E.1 Source du vertex shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
E.2 Source du fragment shader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5 de 79 Maximilian Lesellier
Mémoire de fin d’études Remerciements
Remerciements
Je tiens à remercier Jacques Gangloff, Professeur des Universités, en premier lieu pour
m’avoir permis de réaliser ce projet de fin d’études ; et deuxièmement pour la qualité et la
pertinence de son suivi en tant qu’encadrant au cours de ce stage.
Je remercie ensuite particulièrement Xavier Weber, doctorant, pour le suivi et l’intérêt
qu’il a apportés à mon travail ainsi que pour son aide précieuse durant ce semestre.
Je voudrais également exprimer ma gratitude à Danda Pani Paudel, doctorant, pour l’aide
et les conseils techniques qu’il m’a donnés.
Je tiens enfin à remercier toute l’équipe AVR pour l’ambiance sérieuse et détendue qui a
régné pendant toute la durée de ce stage.
6 de 79 Maximilian Lesellier
Mémoire de fin d’études Introduction
Introduction
Le présent mémoire décrit le travail effectué dans le cadre du projet de fin d’études, né-
cessaire à l’obtention du diplôme d’ingénieur de l’INSA Strasbourg spécialité mécatronique
et du Master IRIV. Ce stage s’est déroulé du 1 mars au 31 juillet 2015 au sein de l’équipe AVR
du laboratoire Icube, dans ses locaux situés au pôle API à Illkirch.
L’objectif du stage était de permettre à un robot parallèle à deux câbles, nommé PiSaRo,
de tracer des fresques de grande taille dans le but d’obtenir un démonstrateur des capacités
d’un tel robot en termes de précision. Le PiSaRo possède trois moteurs : deux sont utilisés
pour se déplacer dans le plan pour tracer un dessin et le troisième moteur pour actionner un
stylo lui permettant de tracer ledit dessin.
Après que les précisions nécessaires aient été apportées sur le contexte, on verra que
le travail effectué a été divisé en deux parties : en premier lieu l’étude mécanique du robot
afin de déterminer les causes d’imprécision et de les régler mécaniquement, puis en second
lieu la réalisation d’une application de vision par ordinateur adaptée à la plateforme. Une
ultime étape devait réunir les deux dernières pour obtenir un asservissement visuel, mais des
difficultés techniques et un manque de temps n’ont pas permis d’y arriver.
7 de 79 Maximilian Lesellier
Mémoire de fin d’études
Partie 1
Contexte du stage
1.1. Présentation du cadre
1.1.1. Laboratoire Icube
Le laboratoire des sciences de l’ingénieur, de l’informatique et de l’imagerie, est une unité
mixte de recherche (UMR 1) issue d’un partenariat entre le Centre National de Recherche
Scientifique (CNRS), l’Université de Strasbourg (UdS), l’Institut National des Sciences Appli-
quées de Strasbourg (INSA) et l’École Nationale du Génie de l’Eau et de l’Environnement de
Strasbourg (ENGEES).
Cette unité a été fondée en 2013 par la fusion des unités mixtes de recherche des domaines
Sciences et Technologies de l’Information et de la Communication (STIC) et Sciences pour
l’Ingénieur (SPI) à Strasbourg : les anciens LSIIT, InESS, IMFS, IPB-LINC. Elle n’a cessé
depuis d’évoluer en effectif et en diversité. Elle pratique à la fois de la recherche fondamentale
et de la recherche appliquée dans les domaines des sciences physiques et des technologies
de l’information, de la communication et de l’image.
1. Une unité mixte de recherche est un regroupement d’organismes de recherche et d’établissements d’ensei-gnement supérieur qui est sous la tutelle du Ministère de la Recherche. Cette entité juridique a une validité de 4ans.
8 de 79 Maximilian Lesellier
Mémoire de fin d’études 1.1. Présentation du cadre
L’organisation du laboratoire Icube est explicitée Figure 1.1. On peut y voir que l’unité de
recherche est divisée en 4 départements et 14 équipes de recherche :
1. Département Informatique Recherche (D-IR)
— Équipe Informatique Géométrique et Graphique (IGG)
— Équipe Réseaux (R)
— Équipe Informatique et Calcul Parallèle Scientifique (ICPS)
— Équipe Bioinformatique théorique, Fouille de données et Optimisation stochastique
(BFO)
— Équipe Modèles, Images et Vision (MIV)
2. Département Imagerie, Robotique, Télédétection & Santé (D-IRTS)
— Équipe Modèles, Images et Vision (MIV)
— Équipe Automatique, Vision et Robotique (AVR)
— Équipe Télédétection, Radiométrie et Imagerie Optique (TRIO)
— Équipe Imagerie Multimodale Intégrative en Santé (IMIS)
3. Département Électronique du Solide, Systèmes & Photonique (D-ESSP)
— Équipe Matériaux pour Composants Électroniques et Photovoltaïques (MaCEPV)
— Équipe Systèmes et Microsystèmes Hétérogènes (SMH)
— Équipe Instrumentation et Procédés Photoniques (IPP)
4. Département Mécanique (D-M)
— Équipe Mécanique des Fluides (MécaFlu)
— Équipe Matériaux Multi échelles et Biomécanique (MMB)
— Équipe Génie Civil et Énergétique (GCE)
Cinq programmes de recherche transversaux internes au laboratoire mobilisent plusieurs
équipes de recherche simultanément et structurent le projet de recherche du laboratoire (ils
sont détaillés Figure 1.1) :
1. Imagerie et robotique médicales et chirurgicales (IRMC)
2. Environnement et développement durable (EDD)
3. Calcul scientifique et masses de données (CSMD)
4. Imagerie physique et systèmes (IPS)
5. Ingénierie des matériaux pour l’énergie et l’environnement (IMEE)
9 de 79 Maximilian Lesellier
Mémoire de fin d’études 1.1. Présentation du cadre
Département Informatique Recherche
D-IR
Équipe
IGG
IMRC
CS
Équipe
Réseaux
IMRC
CS
EDD
Équipe
ICPS
CS
Équipe
BFO
IRMC
IPS
CS
EDD
Équipe
MIV
IRMC
IPS
CS
Département Imagerie, Robotique,
Télédétection et Santé D-IRTS
Équipe
AVR
IRMC
CS
EDD
Équipe
TRIO
IRMC
IPS
EDD
Équipe
IMIS
IRMC
IPS
Département Électronique du Solide,
Systèmes et Photonique
D-ESSP
Équipe
MaCEPV
IPS
EDD
IMEE
Équipe
SMH
IRMC
IPS
EDD
IMEE
Équipe
IPP
IRMC
IPS
IMEE
Département Mécanique
D-M
Équipe
MécaFlu
IPS
CS
EDD
Équipe
MMB
IRMC
IPS
CS
EDD
IMEE
Équipe
GC
EDD
IMEE
Équipes Programmes IGG Informatique, Géométrique et Graphique ----- Réseaux ICPS Informatique et Calcul Parallèle Scientifique BFO Bioinformatique théorique, Fouille de données et Optimisation stochastique MIV Modèles, Images et Vision AVR Automatique, Vision et Robotique TRIO Télédétection, Radiométrie et Imagerie Optique
IMIS Imagerie Multimodale Intégrative en Santé MaCEPV Matériaux pour Composants Electroniques et Photovoltaïques SMH Systèmes et Microsystèmes Hétérogènes IPP Instrumentation et Procédés Photoniques MécaFlu Mécanique des Fluides MMB Matériaux Multi-échelles et Biomécanique GC Génie Civil
Programme Imagerie et Robotique Médicale et Chirurgicale IGG-Réseaux-BFO-MIV-AVR-TRIO-IMIS-SMH-IPP-MMB
Programme Imagerie Physique et Systèmes BFO-MIV-TRIO-IMIS-MaCEPV-SMH-IPP -MécaFlu-MMB
Calcul scientifique IGG-Réseaux-ICPS-BFO-MIV-AVR-MécaFlu-MMB
Programme Environnement et développement durable Réseaux-BFO-AVR-TRIO-MaCEPV-SMH-MécaFlu-MMB-GC
Programme Ingénierie des matériaux pour l’énergie et l’environnement MaCEPV-SMH-IPP –MMB-GC
IRMC
CS
IPS
EDD
IMEE
05-09-2013 (version 3)
Figure 1.1 – Organisation du laboratoire Icube et projets communs
Le laboratoire Icube est actuellement dirigé par Michel De Mathelin et emploie un effectif
de près de 500 personnes.
Il fait partie du pôle de compétitivité alsacien «Innovations Thérapeutiques» et participe
à de nombreux projets communs avec le pôle Image Alsace (Iconoval), le Centre National de
la Recherche Scientifique (CNRS), le Ministère de l’Éducation Nationale, de l’Enseignement
Supérieur et de la Recherche (MENESR), le Réseau National de Recherche en Télécommu-
nication (RNRT), le Réseau National Technologies pour la Santé (RNTS), l’Institut National
de Recherche en Informatique et Automatique (INRIA) et l’Institut National des Sciences de
l’Univers (INSU) et compte de nombreux partenaires industriels. Icube s’implique aussi très
largement au niveau des formations en accueillant des professeurs, des maîtres de confé-
rences, des postdocs, des doctorants et des stagiaires.
10 de 79 Maximilian Lesellier
Mémoire de fin d’études 1.1. Présentation du cadre
1.1.2. Équipe AVR
J’ai effectué mon stage au sein de l’équipe Automatique, Vision et Robotique (EAVR), du
département RTS. Cette unité du laboratoire Icube se consacre aux thèmes de la robotique,
de la vision par ordinateur et de l’automatique. Quatre thèmes y sont abordés :
1. Asservissement visuel et métrologie in vivo
2. Modélisation, identification et commande
3. Conception mécanique et mécatronique
4. Radiologie interventionnelle et chirurgie guidée par l’image
L’activité de l’EAVR est dirigée par le Professeur Pierre Renaud. Une équipe de 55 personnes
y travaille ainsi qu’une dizaine stagiaires.
1.1.3. Pôle API
Le laboratoire Icube est implanté sur en plusieurs sites. De même l’équipe de recherche
qui m’a accueilli, l’équipe AVR, est partagée entre deux sites. La majeure partie de l’équipe
travaille sur un site situé dans les locaux de l’Institut de Recherche contre les Cancers de
l’Appareil Digestif (IRCAD) à l’Hôpital Civil de Strasbourg. Ce site est situé en plein cœur du
monde médical strasbourgeois ; cette situation permet de favoriser la recherche médicale qui
est un sujet de recherche majeur pour l’équipe. Le second site se situe dans les locaux de Té-
lécom Physique Strasbourg à Illkirch au pôle d’Application et Promotion de l’Innovation (pôle
API), voir Figure 1.2, qui est aussi le siège du laboratoire Icube. Cet emplacement permet de
délocaliser la recherche vers la banlieue Strasbourgeoise et être au plus près des entreprises
de haute technologie. C’est là que j’ai effectué mon stage.
Figure 1.2 – Télécom Physique Strasbourg
11 de 79 Maximilian Lesellier
Mémoire de fin d’études 1.2. Robotique parallèle à câbles
1.2. Robotique parallèle à câbles
Dans le domaine de la robotique, la robotique parallèle à câbles est une approche récente
mais offrant des possibilités intéressantes. Notamment, les robots parallèles à câbles per-
mettent d’atteindre un espace de travail très grand avec une structure simple et bon marché.
Ce type de robot s’avère intéressant pour parcourir une grande surface. Par exemple, dans le
cadre de ce sujet il permettra de réaliser une fresque de grande taille.
1.2.1. Présentation du concept
Un robot parallèle à câbles est un robot parallèle 2 actionné par la variation de tension dans
des câbles. Ces câbles sont enroulés et déroulés par des moteurs, ce qui permet de déplacer
et d’orienter la plateforme - l’effecteur du robot - voir Figure 1.3. L’exemple le plus connu
d’utilisation commerciale de robot à câbles et la Cablecam, où une caméra est posée sur la
plateforme ; le système permet de déplacer cette plateforme grâce à des câbles suspendus
au-dessus de la scène à filmer.
Figure 1.3 – Exemple d’un robot à 2 câbles
L’approche d’utiliser des câbles que l’on enroule pour déplacer une charge permet d’ex-
ploiter la légèreté, la résistances et la capacité d’enroulement desdits câbles. Ce concept
présente un important potentiel applicatif, les avantages sont notables par rapport aux robots
dits « classiques » [22], on peut citer entre autres :
— Un espace de travail très important et facile à remanier, tout à fait adapté pour réaliser
un dessin dont la taille est très grande par rapport à celle du robot (l’utilisation de tels
2. Mécanisme dont l’organe terminal est relié à la base par plusieurs chaînes cinématiques indépendantes
12 de 79 Maximilian Lesellier
Mémoire de fin d’études 1.2. Robotique parallèle à câbles
robots pour effectuer une tâche sur de grandes surfaces a déjà été envisagée [12])
— Un encombrement faible, une motorisation réduite et donc un prix bas et une consom-
mation d’énergie faible
Cependant, ces avantages sont obtenus au prix d’une plus grande complexité de modélisation
et d’une rigidité bien moins importante, qui entraîne des difficultés de modélisation et des
erreurs de précision [14].
Parmi les robots à câbles, on distingue deux sous catégories [5],
— les robots pleinement contraints, avec plus de câbles que de degrés de liberté. Le ro-
bot est muni de câbles pour pouvoir générer des efforts dans toutes les directions en
contrôlant la longueur et la tension dans ces câbles
— les robots partiellement contraints, avec un nombre de câbles inférieur au sens large au
nombre de degrés de liberté ; où la tension dans les câbles est provoquée par le poids,
le nombre de degrés de liberté est moindre mais il n’y a pas alors besoin de contrôler la
tension des câbles
Ici on choisit une structure semi-contrainte puisque tous les degrés de liberté ne sont pas
nécessaire pour se déplacer dans le plan.
D’après Bouchard [3], il y a quatre conditions à vérifier pour réaliser une tâche dans une
configuration donnée. L’intersection des espaces associés à ces conditions décrit l’espace
atteignable par le robot. Ces quatre conditions sont les suivantes :
1. Les câbles doivent pouvoir générer les torseurs nécessaires à la tâche : il faut que la
tension soit suffisamment forte pour que les câbles soient toujours tendus et assez faible
pour qu’ils ne cassent pas.
2. Les câbles ne doivent pas interférer entre eux : ceci afin de préserver le modèle pour
la commande, s’applique surtout pour les architectures à câbles croisés pour lesquelles
une distance minimale entre câbles est imposée.
3. Les câbles ne doivent pas interférer avec la plateforme : il ne faut pas qu’ils gênent dans
la réalisation de la fonction principale de l’effecteur.
4. La longueur des câbles doit être comprise entre un minimum et un maximum
Dans de nombreuses réalisations du domaine des robots parallèles à câbles, il a été pos-
sible de constater les difficultés associées à ce type d’architecture.
L’un des tous premiers modèles de robot à câbles présentés est le FALCON-7 de Kawa-
mura et al. [18], représenté Figure 1.4. Ce robot a permis de mettre en évidence les fortes
13 de 79 Maximilian Lesellier
Mémoire de fin d’études 1.2. Robotique parallèle à câbles
dynamiques que peuvent fournir les robots à câbles, avec des erreurs de positionnement qui
peuvent être importantes.
Figure 1.4 – Le robot FALCON-7
Enfin il n’est pas possible de commander à la fois en tension et en position les câbles ; on
ne peut garantir d’avoir à la fois la bonne tension dans les câbles et la bonne position [19].
1.2.2. Travaux de l’équipe
Le sujet de la robotique à câbles est traité dans l’équipe AVR depuis plusieurs années.
Diverses méthodes et outils ont déjà été développés, des études déjà réalisées dans le contexte
de l’équipe et ce projet les réutilisera.
Également, une méthode de modélisation de robot à câbles a été développé au sein de
l’équipe [7, 23]. Notamment les câbles ont été modélisés afin d’obtenir leur modèle de défor-
mation en fonction des contraintes qu’ils subissent. Cette modélisation a pu permettre par la
suite de réaliser un outil de simulations réalistes de robots parallèles à câbles sous Matlab.
1.2.3. Des problèmes de stabilité
Parmi les difficultés récurrentes rencontrées dans le domaine de la robotique à câbles,
entre autres, se trouvent une faible raideur des câbles et des problèmes de vibrations [31]
[8].
Un des apports de l’équipe sur ce sujet est la compensation active des vibrations [32].
C’est à dire qu’on adapte la consigne des actionneurs du robot en fonctions des vibrations
mesurées ou estimées du robot. Il s’agit d’une brique très intéressante qui compense un des
principaux inconvénients des robots parallèles à câbles.
14 de 79 Maximilian Lesellier
Mémoire de fin d’études 1.2. Robotique parallèle à câbles
1.2.4. Actionnement embarqué
Une des contributions principales de l’équipe au thème de recherche est l’idée d’embar-
quer les moteurs d’enroulement sur la plate-forme mobile au lieu de les déporter à l’extrémité
des câbles. De même, le PC de traitement des données ou encore les capteurs sont embarqués
sur la plateforme. Cette vision a permis d’adopter un nouveau modèle avec des intérêts mé-
catroniques nouveaux, principalement de simplifier le réseau entre les actionneurs en s’épar-
gnant un bus de communication entre les moteurs avec un calcul de consigne fait sur un PC
déporté. L’approche d’embarquer les actionneurs a en revanche l’inconvénient d’alourdir la
plateforme du robot. De plus le matériel pouvant être embarqué sur la nacelle doit être léger
et l’alimentation en énergie doit pouvoir être assurée par des batteries.
Le matériel utilisé dans ce PFE est issu de la gamme Lego Mindstorms (voir Figure 1.5).
Il a l’avantage d’être léger, petit, et bon marché. Les moteurs qui enroulent les câbles sont
des moteurs Lego, qui sont les plus compacts et les plus légers de leur gamme de puissance,
ce qui permet d’éviter d’avoir une plateforme trop lourde. Les actionneurs sont gérés par
une brique Mindstorms EV3 qui utilise le firmware EV3.14 développé dans l’équipe [20]. Ce
firmware est destiné à assurer une communication par USB 3 avec un RaspberryPi 4 embarqué
sur la plateforme, ce qui permet d’utiliser le projet RPIt [13] (voir Figure 1.6) - une autre
réalisation de l’équipe. Ce setup permet aussi d’alimenter le RaspberryPi avec la sortie USB
de l’EV3.
Figure 1.5 – Lego : la brique EV3 et quelques périphériques
3. Le Universal Serial Bus (USB, en français Bus universel en série) est une norme relative à un bus informatiquede transmission série entre des périphériques et un ordinateur. Le bus USB permet de connecter des périphériquesà chaud et il peut alimenter les périphériques peu gourmands en énergie
4. Le Raspberry Pi est un nano-ordinateur tenant sur une seule carte, développé par la Raspberry Pi Foundationavec pour intention de développer le goût de la programmation chez les jeunes. C’est une solution à bas coût pourobtenir un ordinateur embarqué tournant sous Linux, avec un processeur ARM qui offre des possiblités intéressantes.
15 de 79 Maximilian Lesellier
Mémoire de fin d’études 1.2. Robotique parallèle à câbles
Figure 1.6 – Schéma de l’utilisation de RPIt
1.2.5. Le projet PiSaRo
Le but en soi du PFE est de réaliser un démonstrateur de la stabilité et de la précision
des robots à câbles. Pour pouvoir prouver cela, l’idée était de réaliser une fresque de grande
taille sur un tableau blanc avec un robot capable de travailler dans un plan. Pour réaliser des
mouvements plans, 2 câbles suffisent, le robot est accroché par deux de ses extrémités en
face du tableau. Deux moteurs suffisent à enrouler les câbles. Cependant, d’après Otis, pour
utiliser une telle structure pleinement contrainte avec n degrés de liberté, il faut au minimum
n + 1 câbles [16] ; le robot sera donc ici sous-contraint. Un troisième moteur est utilisé pour
amener un stylo sur la surface du tableau afin de tracer ou pour le retirer.
16 de 79 Maximilian Lesellier
Mémoire de fin d’études
Partie 2
Approche mécanique
La première étape de ce projet est de déterminer la capacité du robot à effectuer le dessin.
Il faut s’assurer que le robot peut sans erreur tracer des formes simples en compensant les
défauts intrinsèques aux robots à câbles. Principalement, le robot étant semi-contraint, il faut
compenser la rotation qu’il fait en s’éloignant du centre de son espace de travail ; ceci est
possible par odométrie en constatant que la loi à laquelle obéit ce mouvement dépend de la
position du robot. Il faut aussi compenser les vibrations du robot.
Pour ce faire, une première partie est d’identifier tous les paramètres du robot. Cela fait,
on créera un modèle en simulation afin de déterminer des valeurs de correcteur à appliquer
sans risquer d’endommager le système expérimental. On pourra alors enfin effectuer la tâche
de dessin et évaluer les aptitudes du robot à la réaliser et les limites de cette approche.
17 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.1. Identification
2.1. Identification
2.1.1. Notations utilisées
On choisit comme origine du repère monde R0 une des attaches de câbles, celle de gauche.
On attache à cette origine un repère orthonormé. L’origine du repère sera nommée A1. On
attache au robot un repère R1 dont l’origine sera située en B1. On nomme L la distance qui
sépare entre elles les deux attaches A1 et A2. La position dans le repère R0 de l’enrouleur su-
périeur gauche du robot, qui sera représentée par le point B1 est repérée par les coordonnées
[X Y ]T dans ce repère.
Quand le robot se déplace en enroulant ou déroulant ses fils, il n’effectue pas seulement
deux translations, il subit également une rotation autour de l’axe normal au plan. On nomme
α cet angle. Connaissant cet angle on en déduit la position de l’enrouleur droit matérialisé
par le point B2 : [X + l.cos(α) Y + l.sin(α)]T , avec l la distance entre les points B1 et B2.
Les mouvements décrivant un plan, on étudie ce problème uniquement selon les deux di-
mensions de ce plan. On matérialise par le point G le centre de gravité du robot. Ce point
est localisé dans le plan par les deux vecteurs−−→GB1 et
−−→GB2 qui sont respectivement nom-
més−→b1 et
−→b2 . Les coordonnées selon les axes −→x et −→y du repère R1 lié au robot sont notées
respectivement Gx et Gy de façon que :
−→b1 =
−Gx
Gy
Dans la direction des deux câbles, et dans le sens de−−−→B1A1, respectivement
−−−→B2A2, on place
les vecteurs unitaires −→u1 et −→u2.
18 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.1. Identification
×
× ×
×
−→u1 −→u2
×G
0
0
XY
X + l.cos(α)
Y + l.sin(α)
L0
−→b1
−→b2
A1 A2
B1 B2
l
L
−→y
R0
−→x
−→y
R1
−→x
Figure 2.1 – Schéma du système avec les notations employées
Pour assurer les déplacements de ce robot, c’est dans un premier temps le point B1 qui
sera déplacé. Les coordonnées initiales de ce point peuvent être données par l’équation 2.1 :
X
Y
=
X0 + x
Y0 + y
(2.1)
avec x et y la valeur du déplacement demandé au robot par rapport à sa position initiale.
On place la position d’origine du robot telle que celui-ci se trouve au milieu du tableau
dans le cas où [x y]T = [0 0]T ; on vérifie qu’à cette position, α0 est nul. On obtient ainsi une
valeur mesurable de X0 et Y0.
Les paramètres précédemment cités sont explicités sur la Figure 2.1. La tableau 2.2 donne
leur valeur expérimentalement mesurée. Toutes les valeurs sont mesurées dans le repère R0.
19 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.1. Identification
Paramètre Description Valeur
L distance A1A2 2250 mm
l distance B1B2 150 mm
R rayon d’un enrouleur 5 mm
g accélération de la pesanteur 9.81 N/kg
m masse du robot 0.895 kg
Gx abscisse du point G 80 mm
Gy ordonnée du point G 120 mm
X0 abscisse du point B1 1060 mm
Y0 ordonnée du point B1 −970 mm
Figure 2.2 – Tableau des paramètres
2.1.2. Calcul de l’angle α
2.1.2.1. Principe
À chaque position, le système est stable dans le cas statique. On en déduit qu’il est alors
possible d’appliquer le principe fondamental de la statique pour déterminer les efforts aux-
quels il est soumis. Comme le système est au repos, d’après la première loi du mouvement de
Newton, la somme des forces et la somme des moments qui lui sont appliqués respectivement
sont nulles. Le système est soumis à trois forces (voir Figure 2.3) :
1. son poids, m.−→g appliqué en G
2. la tension dans le premier câble, −→τ1 selon −→u1, appliquée en B1
3. la tension dans le second câble, −→τ2 selon −→u2, appliquée en B2
4. l’effort généré par l’appui du feutre contre le tableau. Cet effort n’étant pas situé dans
le plan, il n’est pas pris en compte lors de cette étude.
20 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.1. Identification
−→x
−→y×
× ×
×
−→τ1 −→τ2
−→g
×G
l
A1 A2
B1 B2
Figure 2.3 – Les efforts appliqués au système
En appliquant le principe fondamental de la statique au point G, on a :τ1.−→u1 + τ2.
−→u2 −m.−→g =−→0
−→b1 ⊗ τ1.−→u1 +
−→b2 ⊗ τ2.−→u2 =
−→0
(2.2)
Pour (2.2), on a en particulier sur l’axe perpendiculaire au plan :
−τ1.Gx.−→u1.−→y − τ2.Gy−→u1−→x + τ2.(l −Gx).−→u2.−→y − τ2.Gy.−→u2.−→x = 0 (2.3)
À partir de l’équation (2.2) on obtient une expression en fonction de α des valeurs τ1 et τ2.
Pour trouver la valeur correcte de α, on fait parcourir à celle-ci l’intervalle [0, 2π] ; la valeur
recherchée est celle qui annule l’équation (2.3).
21 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.1. Identification
2.1.2.2. Implémentation
En premier lieu, on a commencé par programmer un algorithme qui recherchait littérale-
ment le minimum de l’équation (2.3) en procédant de façon discrète. Cette façon de recher-
cher est extrêmement coûteuse en temps de calcul ; il s’agit d’un algorithme de complexité
O(n).
Une première optimisation envisagée a été de réduire l’intervalle de calcul. Pour assurer
le fonctionnement du robot, la valeur de α est toujours comprise dans l’intervalle [−π4 ;π4 ]. On
divise ainsi par 4 le temps de calcul.
Figure 2.4 – Variation de α dans l’espace de travail
Cependant celui-ci reste élevé, puisqu’on cherche à parcourir l’intervalle avec un pas de
quantification très petit pour augmenter la précision. On se tourne alors vers des méthodes
de recherche de minimum local. On peut d’abord vérifier que la variation de l’angle α en
fonction des valeurs de x et y est monotone dans l’espace de travail. Cette expérimentation
peut être faite avec l’algorithme précédent. On obtient le tracé donné Figure 2.4. L’hypothèse
est vérifiée expérimentalement.
Une méthode efficace pour la recherche de minimum local est la méthode de recherche
par dichotomie. Cette méthode est de complexité algorithmique O(ln(n)). L’algorithme en
pseudo-langage est donné Figure 2.5.
1 debut ← minimum %minimum de l'intervalle
2 fin ← maximum %maximum de l'intervalle
3 trouve ← faux
4
22 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.1. Identification
5 Repeter
6 mil ← ((debut + fin)/2)
7 Si t[mil] = val Alors
8 trouve ← vrai
9 SinonSi val > t[mil] Alors
10 debut ← mil+1
11 Sinon
12 fin ← mil-1
13 FinSinonSi
14 FinSi
Figure 2.5 – Pseudo-code de l’algorithme de recherche par dichotomie
Cet algorithme est beaucoup plus léger et permet d’obtenir une bonne précision sans
consommer trop de temps processeur. On peut observer l’utilisation du processeur pendant
le fonctionnement normal du robot avec un bloc prévu à cet effet dans la toolbox RPIt. Le
résultat est donné Figure 2.6. Les pics visibles sur cette figure sont un artefact de mesure dû
à la latence de la communication par wifi. On constate qu’on n’utilise qu’une faible partie des
ressources pour le fonctionnement de l’asservissement dans son ensemble, ce qui permettra
alors d´en allouer beaucoup au traitement d’images qui lui est gourmand en temps de calcul.
(a) Outil de mesure (b) Mesure
Figure 2.6 – Utilisation du processeur par l’asservissement
On peut vérifier que la correction de l’angle α est bonne en observant les données accé-
lérométriques du robot : si la correction de l’angle est correcte, alors le robot est toujours
orienté de sorte que le poids ne soit exercé que dans la direction de l’axe −→y . Un accéléro-
mètre embarqué sur le robot fait déjà partie du setup RPIt, il s’agit du InvenSense MPU9250.
23 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.1. Identification
On vérifie que l’accélération de la pesanteur - la seule accélération que le robot subit quand
il est à l’arrêt - est bien orientée selon l’axe vertical seul et n’a pas de composante selon −→x .
2.1.3. Gestion du stylo
2.1.3.1. Position du stylo
Jusqu’à présent, le point du robot qui était piloté était le point B1. Mais un asservissement
en position de ce point pour effectuer le dessin provoquerait une distorsion du dessin réalisé,
car il y a une transformation elle aussi dépendante entre autres de l’angle α entre ce dernier
point et le point d’application du feutre. On nomme Xf0 et Y f0 les coordonnées initiales du
feutre, Xf et Y f ses coordonnées actuelles. À tout moment, la position du feutre dans le
repère R1 est donnée par l’équation suivante :
Xf
Y f
=
x+Xf0.cos(α)− Y f0.sin(α)−Xf0
y + Y f0.cos(α) +Xf0.sin(α)− Y f0
(2.4)
Par la mesure, on obtient les valeurs des paramètres Xf0 et Y f0 ; on a respectivement
Xf0 = 170 mm et Y f0 = −75 mm.
×
××
×
B1
α
×
Xf
Yf
Figure 2.7 – La position du feutre
On peut dès lors depuis la position du feutre interpoler la position du point B1 à piloter
24 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.1. Identification
et ainsi réutiliser les résultats précédents pour obtenir un asservissement en position de la
pointe du feutre.
2.1.3.2. Actionnement du stylo
Le stylo est actionné par un troisième moteur relié à l’EV3.14. Il est asservi en position
par une boucle décrite dans le sous-système nommé Feutre. On commande le feutre avec un
consigne en position, le détail de l’asservissement sous Simulink est donné Figure 2.8. Les
deux positions « au contact du tableau » et « levé » doivent être redéfinies à chaque change-
ment de feutre. L’asservissement aussi doit être recalibré dans ce cas, c’est la raison de la
présence de la routine de calibration dans ce bloc.
(a) Bloc Feutre (b) Asservissement du feutre
Figure 2.8 – Gestion du feutre dans RPIt
25 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.2. Modélisation
2.2. Modélisation
Une fois les principaux paramètres du robot identifiés, on est en mesure de modéliser le
robot. Un modèle du robot simulé avec Matlab Simulink permettra de régler certains para-
mètres, de vérifier l’intégrité du modèle et enfin de régler les correcteurs de l’asservissement.
2.2.1. Fonction de transfert du robot
Sur le modèle réel du robot qui sera exécuté avec RPIt, l’asservissement en position du
robot est assuré par deux boucles. L’une dans l’espace opérationnel du robot compare une
consigne de position avec la mesure extrapolée par odométrie 5, pour restituer une commande
du robot. Cette commande est ensuite intégrée en déplacement simple et en utilisant le mo-
dèle géométrico-statique 6 inverse du robot, en consigne de position articulaire.
À cette étape il convient de vérifier que la position obtenue par le modèle géométrico-
statique est juste. En effet, le robot étant un robot parallèle, le modèle géométrique direct a
plusieurs solutions pour une position articulaire donnée. D’après Merlet [22], dans le cas d’un
robot à deux câbles, il y a trois solutions :
1. une première configuration S1
2. une configuration S2 qu’on obtient en effectuant une rotation de π rad autour de l’axe
−→z R0de la configuration S1
3. une configuration S3 obtenue en effectuant une rotation de π rad autour de l’axe −→x R0
de la configuration S1
Cependant, on peut vérifier que de ces trois configurations, les deux positions S2 et S3 ne
sont pas atteignables à partir d’une solution S1. En partant d’une solution S1 il faut ajouter
de l’énergie pour obtenir la rotation nécessaire. En partant donc d’une configuration don-
née, on peut trouver de proche en proche les solutions suivantes sans risquer de changer de
configuration. C’est pourquoi le point de départ du robot est dans une configuration donnée.
5. L’odométrie est la technique qui consiste à estimer la position d’un système en mouvement grâce aux mesuresde capteurs embarqués.
6. Le modèle géométrico-statique est un modèle qui fait intervenir le modèle géométrique du robot et y ajoutel’influence sur ce modèle des forces à l’état statique
26 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.2. Modélisation
Une deuxième boucle d’asservissement en position compare la consigne de position articu-
laire avec le retour des encodeurs de position restitué par l’EV3, la commande étant envoyée
à l’EV3. Cette commande est obtenue avec une commande numérique RST qui permet un
asservissement en position rapide des moteurs.
Compte tenu de la rapidité de cette commande, on peut dans un premier temps estimer que
cette seconde boucle est parfaite et que la consigne en position des moteurs est parfaitement
suivie et l’ignorer.
Dans un second temps, le modèle a été perfectionné en ne considérant plus que le moteur
est parfait ; cela consiste à ajouter au modèle ladite boucle. Pour simuler le fonctionnement
d’un moteur, il a fallu déterminer une relation entre la tension de commande des moteurs et
la vitesse de rotation. C’est la relation (2.5), qui donne la vitesse V de rotation du moteur en
fonction de la tension de commande Ucom et de l’intensité maximale Isat et de la résistance
interne du moteur Rmot qui sont des constantes propres à celui-ci.
V =180
π.
1
0.5036.(Vmax.Ucom −Rmot.Isat.Ucom) (2.5)
Figure 2.9 – Modélisation d’un moteur
On peut alors placer des mesures pour visualiser les divers signaux du modèle obtenu
Figure 2.9, en particulier sur le retour de position pour s’assurer que le robot a un bon suivi
de la trajectoire imposée.
2.2.2. Mesure de la position du robot dans le repère R1
À partir du retour de position fourni par les codeurs du Lego EV3.14 - qui ont une résolu-
tion de 720 impulsions par tour[13] -, on peut reconstituer la position [X Y ]T du point B1 du
robot dans le repère R1.
Pour cela, on estime la position angulaire du robot à partir des derniers X et Y mesu-
rés et on multiplie l’erreur entre la position mesurée et la position estimée par le Modèle
27 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.2. Modélisation
Géométrico-statique Inverse du robot, comme sur la Figure 2.10. Ce résultat donne une erreur
en position qui est alors intégrée pour obtenir une valeur de [X Y ]TR1. Le modèle géométrico-
statique inverse ainsi que la matrice jacobienne sont eux-mêmes calculés en fonction des
dernières valeurs de X et Y.
La position angulaire estimée et la matrice jacobienne du robot sont recalculées en fonc-
tion de α, puisque l’inclinaison du robot intervient dans leur formulation. À cette étape il faut
donc effectuer une nouvelle fois le calcul de α.
La présence du gain visible en orange sur la Figure 2.10 est permet de s’assurer que
la constante de temps de cette boucle d’estimation des paramètres est largement inférieure
à celle du système global. On évite ainsi de créer un nouveau pôle que l’on ne puisse pas
immédiatement négliger.
Figure 2.10 – Schéma de la mesure de position du robot
2.2.3. Tension et déformation des câbles
En robotique à câbles, les câbles sont souvent considérés comme indéformables. Or la
déformation des câbles sous tension est un phénomène visible qui apporte une erreur de
position. Xavier Weber [33] a notamment travaillé sur le phénomène et déterminé que le câble
peut être modélisé comme un ressort linéaire. Dans ce cas, l’élongation des câbles vaut :
kS + τ
kS.l2 = l1 (2.6)
avec l2 la longueur à vide du câble (distance AB) et l1 la longueur sous charge.
Le terme kS désigne la raideur spécifique du câble, c’est à dire, avec E le module d’Young
28 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.2. Modélisation
du matériau constituant le câble et S sa section,
kS = E.S
Dans le cas de ce robot, la raideur spécifique d’un fil vaut kS = 140.18 N ; mais comme les
câbles, sont doublés, leur raideur est de 2.kS .
Cette élongation dépend de la tension τ du câble, qui elle-même dépend de la position du
robot dans R1. Elle est donc recalculée à chaque itération. On obtient la longueur réelle en
multipliant la longueur qu’ont mesurée les codeurs par le terme kS+τkS
.
On obtient ainsi le modèle donné en annexe page 71. La partie en rouge est la partie qui
modélise le fonctionnement du robot, l’autre est commune au modèle et au système réel, elle
pourra être réutilisée telle quelle.
2.2.4. Réglage du correcteur sur la consigne en position
En pilotant sans correction le robot en position, on constate la présence d’une erreur
statique 7 de 8% et une vitesse de convergence faible, le temps de réponse à 5% est d’à peu
près 10 s (voir Figure 2.11). On peut améliorer ces performances en introduisant un correcteur
PID 8 , illustré Figure 2.12 .
Figure 2.11 – Comparaison entre consigne et mesure de position du robot
7. Il s’agit de l’écart entre la sortie souhaitée et la sortie réelle en régime permanent.
8. Correcteur Proportionnel Intégral Dérivé (PID) : c’est un contrôleur permettant d’effectuer une régulation enboucle fermée d’une grandeur physique. Le correcteur PID a 3 actions, ajustables en réglant 3 gains :
a) action proportionnelle : l’erreur est multipliée par un gain P
b) action intégrale : l’erreur est intégrée puis multipliée par un gain I
c) action dérivée : l’erreur est dérivée et multipliée par un gain D
Ces actions sont en général sommées pour obtenir la correction.
29 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.2. Modélisation
Figure 2.12 – Schéma du correcteur utilisé
En premier lieu, il convient de noter qu’afin d’éviter d’engendrer des vibrations parasites,
la vitesse maximale de déplacement selon chaque axe de R1 est seuillée. Ce seuillage a ten-
dance à ralentir le système. Dans le cas présent, cette vitesse est limitée entre −25 mm/s et
25 mm/s. On règle le correcteur PID par approches successives (voir Annexe C). Pour amélio-
rer le temps de réponse, on règle en premier le coefficient P. On cherche une valeur de P qui
provoque un faible dépassement, de l’ordre de 10%, la valeur P = 5 y correspond.
Pour accélérer la réponse, on introduit un coefficient D. Son action d’anticipation améliore
grandement le temps de réponse, le réduisant d’à peu près 30%. On le règle de façon à ce
que le dépassement reste inférieur à 15%. On atteint la valeur D=0.1.
Pour compenser l’erreur statique, visible sur la Figure 2.11, le correcteur PD ne suffit pas.
Pour compenser cette erreur statique, on règle le coefficient I à 3.
La précision en position est nettement améliorée par l’introduction de ce correcteur PID.
On peut voir Figure 2.14 l’apport de l’introduction de ce correcteur. Les valeurs des correc-
teurs obtenus sont résumées dans le tableau ci-dessous :
Coefficient Valeur
P 5
I 3
D 0.1
Figure 2.13 – Valeur des correcteurs du PID
30 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.2. Modélisation
Figure 2.14 – Comparaison de la précision pour un échelon de consigne de 100mm
2.2.5. Générateur de trajets
Le générateur de trajets est un algorithme dont le but est de transformer un dessin en
trajectoires afin que le robot puisse le reproduire.
Le trajet choisi dans cette application est de parcourir les contours du dessin. Comme le
robot est asservi en position, l’approche choisie est de donner au robot une liste de points à
parcourir.
Pour obtenir une trajectoire à partir d’une image, l’algorithme effectue les opérations sui-
vantes :
1. charger l’image
2. binariser l’image
3. détecter les contours
4. réaliser une ouverture morphologique 9 sur l’image résultante
5. trouver les frontières de l’image sous forme de courbes
6. identifier les points d’inflexion des différentes courbes
Il faut ensuite, au début et à la fin de chacune des courbes trouvées à l’étape 5, respecti-
vement abaisser et relever le stylo pour tracer ou non.
La sortie de cet algorithme est composées de 3 listes, les coordonnées en X (Xlist), en Y
(Ylist) et la position du stylo à chacun de ces points (Plist). Ces trois listes sont copiées dans
9. C’est la composition d’une érosion et d’une dilatation (dual de l’érosion) : γB(X) = δB(εB(X)) (voir 3.1.1.2).Cette opération permet d’éliminer les petites zones de pixels tout en ne modifiant pas l’allure des grandes zones.
31 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.2. Modélisation
l’espace de travail de Matlab. Elles peuvent donc être lues par PiSaRo directement dans le
workspace.
Du point de vue de la commande, on décide qu’un point est atteint si l’erreur de position
sur chacun des deux axes est assez faible, c’est à dire inférieure à un seuil fixé par l’utilisateur.
Une fois un des points atteint on passe au robot comme consigne le point suivant. Chaque
point contient comme information ses coordonnées et la position du stylo. Le bloc Figure 2.15,
est chargé de déterminer l’indice du point courant dans la liste des points.
(a) Position suivante (b) Compteur de points
Figure 2.15 – Générateur de trajets
32 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.3. Essais sur le système réel
2.3. Essais sur le système réel
La raison d’être de PiSaRo est de réaliser une fresque de grande taille, c’est à dire, dans le
cadre de ce PFE, un dessin sur un tableau blanc à l’aide d’un feutre. Il faut donc caractériser
la trajectoire suivie par le robot pour effectuer le tracé. En effectuant les dessins, on constate
que le robot commet une erreur de suivi de trajectoire : il y a une différence entre entre les
coordonnées attendues des points atteints et celles effectivement atteintes.
2.3.1. Caractérisation de l’erreur
En traçant le dessin d’un carré dans l’espace de travail, on constate la présence d’une
erreur de distorsion en trapèze selon les deux axes du plan. Pour un carrée de 30 cm de côté,
on obtient le résultat visible Figure 2.16.
Figure 2.16 – Tracé d’un carré distordu
En parcourant plusieurs fois le même trajet, le tracé est approximativement identique. Le
système est donc répétable. Entre deux parcours d’un même itinéraire, l’erreur est inférieure
à 5 mm. Plusieurs essais sont venus confirmer ce résultat, dont un est visible Figure 2.17.
33 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.3. Essais sur le système réel
Figure 2.17 – Essai de répétabilité de l’erreur
On peut dès lors mesurer cette erreur de façon certaine. On obtient les résultats donnés
Figure 2.18.
30.2
30.6
31.6
30.8
Figure 2.18 – Mesure de la distorsion
Plusieurs facteurs sont susceptibles d’être la cause de l’erreur, entre autres :
— une erreur d’estimation des paramètres
— une erreur d’estimation de la tension des câbles due à la 3ime dimension négligée
— le frottement du stylo
— le décollement du robot provoqué par le stylo
Parmi eux, l’influence du stylo a été approfondie.
2.3.2. Influence du stylo sur l’erreur
Lorsque l’on place le stylo au contact du tableau, on ajoute au système un frottement sec
et un frottement visqueux. Le stylo devient également un nouveau point d’appui du robot et
34 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.3. Essais sur le système réel
change l’état d’équilibre de celui-ci : il fausse l’équation d’équilibre des efforts en décollant
le robot du tableau.
Toutes ces perturbations peuvent générer une erreur. On effectue un essai en vue de com-
parer les positions relevées avec et sans appuyer le stylo contre le tableau (dans ce deuxième
cas on fait le point manuellement). Cet essai est visible Figure 2.19, avec un point en bleu pour
l’essai avec stylo et un point noir pour l’essai sans. Les résultats des mesures sont donnés Fi-
gure 2.19. On constate que la distorsion est effectivement plus faible sans le stylo. Cependant,
il y a toujours une distorsion du même type, le stylo n’est pas le seul facteur de distorsion.
30.2
30.6
31.6
30.8
30.9
30.8
31.0
30.4
Figure 2.19 – Distorsion avec/sans stylo
Le frottement visqueux dépend de la vitesse de déplacement, s’il y en a alors on peut le
réduire en réduisant la vitesse. Par contre son signe est aussi le signe de la vitesse, donc il
doit générer une erreur de traînage. Pour estimer l’influence du frottement visqueux du stylo,
on effectue un essai à très basse vitesse : 5 mm/s. On fait faire plusieurs aller-retours au robot
et on mesure l’erreur. Le résultat est donné Figure 2.20, on peut voir qu’il n’y a presque pas
de déformation, l’erreur due à ce paramètre est négligeable. Donc la vitesse de déplacement
n’a pas d’influence sur la précision du robot - les vibrations mises à part.
35 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.3. Essais sur le système réel
Figure 2.20 – Influence du frottement visqueux sur le suivi de trajectoire
2.3.3. Compensation de la distorsion
Pour compenser la distorsion vue plus haut, on peut utiliser une technique issue du do-
maine du traitement d’images. En effet, toute caméra introduit sa propre distorsion, aussi il
est courant dans le domaine de la vision de chercher à caractériser les défauts d’une caméra
et d’en obtenir une transformation entre l’image mesurée et la réalité [30]. Une transforma-
tion affine revient à une erreur de caméra linéarisée.
On essaie de déterminer la transformation entre la valeur mesurée par le robot des coor-
données de différents points de l’espace de travail et leur valeur réelle. Pour cela on relève la
position mesurée par le robot en différents points.
36 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.3. Essais sur le système réel
Figure 2.21 – Lieux des points réels et mesurés
Il reste ensuite à trouver la relation entre ces deux séries de valeurs. La transformation
étant supposée affine, on a une relation du type :
X = a.x + b.y + c.x.y + d
Y = e.x + f.y + g.x.y + h
On effectue une procédure de calibration pour les coefficients a, b, c, d, e, f, g et h de la
transformation. On appelle x la matrice telle que x = [a b c d e f g h]T et on construit deux
matrices A et b telles que :
A =
X1 Y1 X1.Y1 1 0 0 0
0 0 0 X1 Y1 X1.Y1 1
X2 Y2 X2.Y2 1 0 0 0
......
......
......
et b =
x1
y1
x2
...
Il ne reste alors qu’à inverser le système d’équations pour obtenir la transformation entre les
deux :
A.x = b ⇒ x = A\b
Une fois obtenue la matrice de distorsion, il reste à multiplier la consigne par celle-ci pour
37 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.3. Essais sur le système réel
obtenir une consigne comprenant la distorsion qui permettra au robot de tracer l’image at-
tendue.
La norme de la différence sans correction entre les matrices A et b vaut 92 mm. Après
correction, la norme de l’erreur entre A.x et b tombe à 22 mm en simulation et on obtient
30 mm après essai sur le système réel. La correction en multipliant par la matrice de distorsion
est donc efficace.
Le résultat, visible Figure 2.22 est probant. Multiplier par la matrice de distorsion s’avère
donc efficace. Cependant, toute l’erreur n’est pas corrigée, on peut encore constater une
déformation même après ce traitement.
Figure 2.22 – Image après correction par matrice de distorsion
2.3.4. Autre approche de la compensation de l’erreur
La méthode de compensation de la distorsion précédemment décrite nécessite une cali-
bration longue et précise du robot à chaque fois qu’un paramètre, comme exemple le type de
feutre, change ou à chaque ajout d’un composant. Cette méthode n’est pas très répétable, les
chances de commettre une erreur de mesure sont grandes.
Alors que la mesure par odométrie devient insuffisante, il devient nécessaire d’introduire
un capteur supplémentaire pour déterminer l’erreur en position commise par le robot. Il
38 de 79 Maximilian Lesellier
Mémoire de fin d’études 2.3. Essais sur le système réel
convient de trouver un capteur efficace, pouvant être embarqué et ne nécessitant pas de
calibration à chaque changement de l’environnement. Une caméra pouvant réaliser un asser-
vissement visuel semble être la solution adéquate.
Le système embarquant déjà un RaspberryPi pour l’utilisation de RPIt, il est possible d’en-
visager une solution de vision embarquée sur cette plateforme.
39 de 79 Maximilian Lesellier
Mémoire de fin d’études
Partie 3
Vision par ordinateur
Le système produit une erreur de position que les moyens de mesure déjà embarqués ne
parviennent pas à caractériser, il faut donc rajouter un capteur supplémentaire pour identifier
la distorsion et pouvoir la corriger par la suite.
En l’absence de capteurs proprioceptifs 10 supplémentaire, comme c’est le cas dans cette
application, on utilise des capteurs extéroceptifs 11, souvent une caméra, pour repérer le ro-
bot. Une commande avec comme capteur une caméra est appelée asservissement visuel. L’ob-
jectif est de positionner le robot par rapport à des objets dont la localisation est inconnue dans
son espace de travail [10]. Dans le cadre de ce PFE, la caméra sera embarquée sur la plate-
forme du robot à câbles, il s’agit d’une configuration dite eye-in-hand [27, 10].
Ainsi on peut tirer partie la présence du RaspberryPi et les possibilités qu’offre cette pla-
teforme : il est possible d’exécuter le traitement d’images dessus. La visée de ce PFE était
d’utiliser une caméra embarquée sur la plateforme qui devait filmer la portion d’espace de
travail sur laquelle le robot travaille et utiliser ces images pour faire un recalage visuel. Cette
solution a été étudiée dans cette partie.
Dans un premier temps la réflexion s’est portée sur la stratégie de vision, quelles fonctions
de l’image doit-on repérer pour avoir un asservissement fiable et des traitements simples ? Il a
10. Capteurs qui effectuent leurs mesures par rapport à ce qu’ils perçoivent localement du déplacement du robot
11. Capteurs qui se basent sur des mesures prises par rapport à repère absolu
40 de 79 Maximilian Lesellier
Mémoire de fin d’études
été décidé de détecter des points que le robot peut dessiner à l’aide de son stylo. En effet, un
point de stylo peut s’apparenter à une ellipse, et donc son centre peut être déterminé aisément
par un calcul de moyenne. Pour détecter une ellipse, on commence par seuiller l’image. On
peut ensuite éliminer le bruit par érosion pour ne détecter que les grandes zones, composées
de suffisamment de pixels. On peut aussi se contenter de travailler avec les contours de la
forme uniquement, pour alléger le calcul de détection. La détection se fera donc en parcourant
le contour fermé des objets.
Dans un second temps, on a réfléchi à l’implémentation de cet algorithme sur le PC em-
barqué dans le robot. Cette implémentation a dû tenir compte des limitations imposées par le
matériel. En effet, pour réaliser un asservissement visuel à fréquence élevée, il faut réduire le
temps d’acquisition de l’information de mesure. L’étape critique car souvent la plus longue est
le traitement de l’image pour détecter les fonctions de l’image à suivre. Au cours de ce PFE
une attention particulière a été portée au traitement de l’image, en particulier à la légèreté
de ce traitement en terme de complexité de calcul. Ceci afin de pouvoir utiliser le Raspber-
ryPi et son unité de traitement graphique sans ajouter de composant supplémentaire sur la
plateforme.
41 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
3.1. Réalisation d’un traitement d’images adapté
3.1.1. Les techniques utilisées
3.1.1.1. Seuillage
Le seuillage est la technique de traitement d’image qui consiste à séparer les pixels l’image
capturée en plusieurs régions, ici 2. Selon la luminance 12 des pixels, ceux-ci seront considérés
comme appartenant à l’une ou l’autre des classes. Souvent on s’en sert pour distinguer les
informations au premier plan du fond d’une scène.
De nombreuses méthodes existent [28], nécessitant plus ou moins de calcul pour détermi-
ner le seuil auquel on compare la luminance de chacun des pixels. Ici, le robot n’embarquant
qu’un stylo, le dessin sera monochrome. On peut donc réduire les pixels de l’image à une don-
née binaire en séparant les pixels tracés par le stylo des autres. Pour ce faire, on comparera
la luminance en niveaux de gris des pixels à une référence. La caméra employée peut four-
nir directement une image en niveaux de gris sans qu’aucun calcul supplémentaire ne soit
nécessaire.
En fonction de la qualité de l’éclairage ou de la couleur du stylo employé, la luminance des
pixels perçus peut varier beaucoup. Aussi, le seuil auquel sont comparés les pixels doit être
réglable manuellement par l’utilisateur.
L’image à traiter est donc une image binaire que l’on obtient après avoir comparé la lumi-
nance des pixels à un seuil, ce qui allège les prochains calculs de vision.
3.1.1.2. Érosion
Sur les images capturées par une caméra, on observe souvent du bruit de mesure, carac-
térisé par des faux positifs dans une image seuillée. De plus, comme la surface de travail du
robot est un tableau blanc, il est éventuellement possible que des traces mal effacées soient
12. La luminance est la grandeur qui correspond à la sensation visuelle de luminosité. On la définit comme l’inten-sité du rayonnement par unité de surface rapportée à la direction de l’observation.
42 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
détectées. Pour s’affranchir des éventuelles traces déjà présentes sur le tableau, le seuillage
ne suffit pas.
Les objets que l’on cherche à repérer sont des ellipsoïdes qui occupent une grande surface
dans le champ de vision de la caméra - au moins 100 pixels. Les pixels isolés doivent donc être
éliminés car leur détection ralentit le calcul de détection des objets.
Pour écarter ces parasites, on se sert d’un outil issu de la morphologie mathématique :
l’érosion [15]. Le principe est que chacun des pixels a une valeur qui est fonction des pixels
voisins ; en l’occurrence il s’agit d’appliquer à l’image un opérateur morphologique qui est
défini comme la somme de Minkowski [26], on a :
AB = {z|(B)z ⊂ A}
ou bien en représentation graphique :
Figure 3.1 – Exemple d’érosion
L’érosion se faisant sur toute l’image, elle enlève les pixels de frontière de toutes les zones.
Mais comme elle modifie pareillement tous les pixels de l’image, cela ne change pas la position
du centre d’une zone pleine et fermée.
En augmentant la taille du masque d’érosion on augmente le nombre de pixels minimal
d’une zone pour être conservée. Cela permet de simplifier l’image et d’alléger considérable-
ment le traitement.
3.1.1.3. Détection de contours
L’application de vision consistera en la détection d’ellipsoïdes. Moins les pixels apparte-
nant à la région à détecter seront nombreux et plus les calculs seront légers. Il est possible
alors pour identifier une marque de stylo par exemple de la réduire à ses contours.
43 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
La détection de contours est un sujet récurrent en traitement d’images.Il existe un nombre
très important de méthodes.
L’approche la plus couramment envisagée est qu’un contour correspond à une variation
brusque d’intensité lumineuse, c’est à dire à une valeur élevée de la dérivée spatiale de l’in-
tensité lumineuse [21]. Les techniques de détection de contours sont donc basées sur la déri-
vation selon les deux coordonnées de la luminance. Le principe des méthodes de détection de
contour par convolution est que la dérivation agit comme un filtre passe-haut. Les techniques
les plus utilisées sont basées sur la convolution par un tel filtre, on peut citer notamment :
— le filtre dérivées premières : il consiste à calculer les différences entre pixels voisins sur
les horizontales puis sur les verticales. Chaque extremum est un point de contour.
— le filtre de Prewitt : ce filtre introduit un flou, chacune des deux matrices étant le produit
du filtre dérivation dans la direction considérée par un filtre de flou rectangulaire selon
l’autre direction [24].
— le filtre de Sobel : amélioration de la technique précédente en remplaçant le filtre rec-
tangulaire par un filtre triangulaire [29].
— le filtre de Canny : c’est un filtre de Sobel précédé par un lissage gaussien et suivi par
un seuillage [4].
— le filtre de Deriche : variante du filtre de Canny [9].
— le filtre dérivées secondes : on les calcule en différences finies et c’est un changement
de signe qui correspond à un point de contour.
— le filtre de Marr-Hildreth : le calcul du laplacien est précédé par un lissage gaussien
pour filtrer les hautes fréquences [21].
Une autre approche peut être de définir un contour comme une zone de transition : tous
les voisins d’un pixel de contour n’ont pas la même luminance.
La zone à détecter est alors circonscrite à une frontière de quelques pixels d’épaisseur
de la région de pixels qui représente la marque du feutre. Pour le traitement envisagé, c’est
à dire trouver le centroïde de la forme, on peut conserver la méthode de la moyenne : la
moyenne des coordonnées selon chaque axe des pixels de la forme est le centre de gravité de
la forme, correspondant au centre de l’ellipse.
44 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
3.1.2. Construction du filtre utilisé
Le type de filtre à appliquer dépend beaucoup de l’architecture utilisée. L’avantage d’utili-
ser un GPU 13 est qu’il est possible de faire de nombreux traitements en parallèle, il est donc
très intéressant d’appliquer un masque de convolution à l’image. Cependant, le GPU du Rasp-
berryPi est limité en termes de mémoire, il ne peut atteindre des zones de plus de 32 pixels.
Il faudra donc veiller à la taille du filtre utilisé.
Les temps d’accès à la mémoire sont aussi très longs. Pour être certain d’assurer la
contrainte de temps réel imposée, on essaye d’éviter les images intermédiaires, donc de réa-
liser le plus possible d’opérations en un seul filtre.
Pour générer un masque de convolution adéquat, on se tourne vers les outils de la morpho-
logie mathématique [26]. La morphologie mathématique est une théorie mathématique dont
une des idées de base est d’étudier ou de traiter des ensembles à l’aide d’un autre ensemble,
appelé élément structurant. À chaque position de l’élément structurant dans un premier en-
semble, on regarde s’il touche ou s’il est inclus dans cet ensemble initial. En fonction de la
réponse, est construit un ensemble de sortie.
3.1.2.1. Seuillage
L’opération de seuillage est très simple, elle consiste à comparer la luminance du pixel
courant à la valeur du seuil. Cette opération peut être faite en même temps que le masque de
convolution est appliqué.
L’image ayant été binarisée, les valeurs des pixels sont 0 ou 1.
On peut admettre que si la valeur d’un pixel est 0, celui-ci ne fait pas partie de la forme à
détecter et sauter tous les autres test.
13. Graphics Processing Unit : synonyme de processeur graphique. C’est une puce à l’architecture hautementparallèle qui assure les fonctions de calcul de l’affichage.
45 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
3.1.2.2. Érosion
Les zones de bruits de mesure observées ont pu aller jusqu’à une taille de l’ordre de 10
pixels. Afin de les éliminer, on a donc dû prendre un opérateur d’érosion suffisamment grand.
On choisit aussi un opérateur qui ait la même action dans toutes les directions de l’image.
L’opérateur choisi est le suivant :
ε =
1
1
1
1 1 1 1 1 1 1
1
1
1
Figure 3.2 – Opérateur d’érosion choisi
3.1.2.3. Détection de contours
La détection de contours suit une méthode topologique. À chaque pixel on associe la
somme des valeurs des pixels voisins en appliquant le masque suivant :
σ =
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
Figure 3.3 – Somme des valeurs des pixels voisins
On compare ensuite à deux seuils : un pixel est un pixel de contour uniquement si il a des
voisins dont la valeur est 0 et des voisins dont la valeur est 1.
3.1.2.4. Filtre unique
Une fois la binarisation effectuée on peut réduire les deux opérations précédents en une
seule en additionnant les filtres. On peut montrer que le filtre F résultant est bien un filtre
morphologique.
46 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
F = (ε⊕ σ)(X) = {x ∈ X|(x ∈ ε(X) ) ∨ ( x ∈ σ(X))}
1
1
1
1 1 1 1 1 1 1
1
1
1
⊕
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
=
1
1 1 1 1 1
1 1 1 1 1
1 1 1 1 1 1 1
1 1 1 1 1
1 1 1 1 1
1
Figure 3.4 – Filtre conjuguant érosion et somme
Un opérateur est un filtre morphologique si et seulement si il est croissant et idempotent.
Prouvons que F est croissant. Les filtres ε et σ sont des filtres morphologiques standard,
donc ils sont croissants et vérifient :
— X ⊂ Y ⇒ ε(X) ⊂ ε(Y )
— X ⊂ Y ⇒ σ(X) ⊂ σ(Y )
On rappelle que dans la théorie des ensembles,
X ⊂ Y ⇔ ∀x ∈ X,x ∈ Y
or,
x ∈ (ε⊕ σ)(X)⇒ x ∈ {x ∈ X|(x ∈ ε(X) ) ∨ ( x ∈ σ(X))}
et
{x ∈ X|(x ∈ ε(X) ) ∨ ( x ∈ σ(X))} ⊂ {y ∈ Y |(y ∈ ε(Y ) ) ∨ ( y ∈ σ(Y ))}
donc
X ⊂ Y ⇒ (ε⊕ σ)(X) ⊂ (ε⊕ σ)(Y )
Donc F est croissant
F est idempotent si et seulement si F 2 = F
47 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
On a :
x ∈ (F ◦ F )(X) ⇒ x ∈ {x ∈ X|x ∈ ε((ε⊕ σ)(X)) ∨ σ((ε⊕ σ)(X))}
⇒ x ∈ {x ∈ X|x ∈ ε2(X) ∨ σ2(X) ∨ ((ε⊕ σ)(X))}
Soit, x ∈ F ◦ F (X) si et seulement si :
1. ε(X) est idempotente
2. σ(X) est idempotente
3. x ∈ (σ ◦ σ)(X)
or, ε et σ sont des filtres morphologiques donc ils sont idempotents,
ε2(X) = (ε ◦ ε)(X) et σ2(X) = (σ ◦ σ)(X)
Les deux premières conditions étant vérifiées,
x ∈ (F ◦ F )(X)⇔ x ∈ F (X)
Donc F est idempotent.
On en déduit que l’opérateur F est un filtre morphologique.
3.1.3. Seuillage par hystérésis
Cette technique de seuillage permet d´obtenir les pixels avoisinant les contours les plus
significatifs de l’image en s’assurant de leur continuité[4]. On définit deux seuils pour uti-
liser cette technique, un seuil haut et un seuil bas. Le seuil haut permet de sélectionner les
contours les plus significatifs dans l’image obtenue après convolution par le filtre de détection
de contours. Le seuil bas permet de rejeter les contours moins forts de l’image. Le voisinage
est défini dans notre cas par les pixels sélectionnés par le filtre F . La difficulté de cette tech-
nique réside dans le choix des seuils haut et bas.
L’utilisation de cette méthode intervient juste après le filtrage. L’opérateur F appliqué à
chaque pixel de l’image renvoie une valeur dépendant d’une zone centrée sur ce pixel, le
nombre de pixels à l’état logique haut. Si à l’origine la valeur du pixel était l’état bas, alors
le pixel ne fait pas partie de la région à détecter et donc pas de son contour, par conséquent
48 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
le traitement doit retourner 0. Si le pixel fait partie de la région à détecter alors la valeur
renvoyée par F vaut au moins 1. Un contour est donc significatif à partir de cette situation, le
seuil bas est fixé à 1.
Si on réduit le seuil haut de détection de contour - i.e. le nombre maximal de pixels voisins
qui sont à la valeur haute pour pouvoir considérer le pixel courant comme étant d’un contour -
on réduit la largeur de ce contour. Réduire la largeur de la région considérée comme contour
réduira d’autant la durée qu’il faut pour la détecter entièrement. Si on choisit comme seuil
haut 20 voisins noirs, on constate que le contour de la forme renvoyée par F aura une épais-
seur moindre.
On peut alors redéfinir la couleur du pixel pour isoler les contours des formes, c’est ce qui
est fait dans le pseudo-code détaillé de cette étape donné Figure 3.5.
1 Lire seuil
2 Lire pixel courant
3 Lire les valeurs des pixels voisins selectionnes par le masque
4 Copier les valeurs des pixels dans p
5 Trigger ← 0
6
7 seuil_bas ← 1
8 seuil_haut ← 20
9
10 Pour i entre 0 et 29 :
11 Si p[i] < seuil_haut Alors
12 p[i] ← 0
13 Sinon
14 p[i] ← 1
15 FinSi
16 Si p[i] == 0 Et p[i] n'est pas l'origine Alors
17 incrementer trigger
18 FinSi
19 FinPour
20 Si trigger >= seuil_bas Et trigger < seuil_haut Alors
21 couleur ← 1 % la couleur (luminance) du pixel
49 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
22 Sinon
23 couleur ← 0
24 FinSi
25 Si origine == 0 Alors
26 couleur ← 0
27 Finsi
28 Retourner couleur
Figure 3.5 – Pseudo-code de l’algorithme de traitement des images
3.1.4. Résultats
Partant d’une image brute comme l’image Figure 3.6a, en appliquant le filtre on arrive à
l’image Figure 3.6b.
(a) Image de points brute (b) Image de points filtrée et tournée de 10◦
Figure 3.6 – Visualisation du traitement d’images
Après ce traitement initial, il est plus facile d’utiliser l’image de sortie pour effectuer des
opérations plus complexes, comme par exemple de la segmentation 14.
14. Opération de traitement d’images qui a pour but de rassembler des pixels entre eux en suivant des critèrespré-définis. Les pixels sont ainsi regroupés en régions partageant des propriétés commune comme la même couleurpar exemple. La binarisation est une segmentation en 2 régions.
50 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
3.1.5. Segmentation et classification
Une fois les contours des formes tracées isolés, il reste à les détecter et à en extraire les
informations attendues, ie la position du centroïde de la forme.
Une forme est un contour nécessairement fermé, de faible épaisseur. Pour la détecter
on parcourt l’image pixel par pixel. Si la valeur de luminance sur le canal rouge (le canal
choisi pour mettre l’information à l’étape précédente) est 0, le pixel appartient au fond. En
revanche, si cette valeur est non nulle, le pixel est intéressant. On cherche alors tous les pixels
du contour. Puisqu’on est assuré que le contour est continu et a une certaine épaisseur, on
peut le trouver en cherchant de proche en proche : on utilise un algorithme de recherche par
diffusion, plus connu sous le nom de floodfill (voir Figure 3.7).
1 floodfill(pixel, couleur_recherchee)
2 Si couleur(pixel) == couleur_recherchee Alors
3 couleur(pixel) ← autre_couleur
4 floodfill(pixel au nord, couleur_recherchee)
5 floodfill(pixel au sud, couleur_recherchee)
6 floodfill(pixel à l'est, couleur_recherchee)
7 floodfill(pixel à l'ouest, couleur_recherchee)
8 FinSi
Figure 3.7 – Pseudo-code de l’algorithme de floodfill
Quand un pixel est trouvé, on modifie sa valeur sur le deuxième canal de couleur. Le
deuxième canal est aussi traité dans notre cas, pour s’assurer de ne pas trouver deux fois le
même pixel.
Quand un pixel est repéré, on ne se contente pas de le repeindre, on ajoute aussi ses
coordonnées selon chaque axe à la somme des coordonnées et on incrémente un compteur
de pixels. Une fois la pile d’appel des floodfill exécutée, on vérifie que la région est assez
grande pour être considérée : les formes ayant une taille déterminée, leur contour doit avoir
un nombre minimal de pixels ; dans le cas contraire, c’est un faux positif. Si la région est
considérée, alors on divise par le nombre de pixels les sommes des coordonnées en x et en
51 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
y pour avoir la moyenne. Il s’agit du centre de la forme. On sauvegarde toutes ces données
dans une structure prévue à cet effet.
La structure de cet algorithme est détaillée Figure 3.8
Comme la recherche du pixel de départ de la zone se fait à partir du coin supérieur gauche
de l’image et compte tenu de la façon de repérer le contour, on peut s’épargner la recherche
de voisins vers le nord. N’avoir que 3 directions de propagation accélère le processus. Une
autre optimisation peut être faite sur le parcours de l’image : si le parcours suivant l’axe
vertical doit bien être fait pixel par pixel, selon l’axe horizontal en revanche, on peut ne tester
qu’un pixel sur quatre car l’épaisseur est d’au moins 4 pixels.
Une fois cette étape terminée, on itère sur toutes les classes pour effectuer une régression
linéaire sur les centroïdes afin de déterminer le coefficient directeur de la ligne qu’elle lit.
Une idée de méthode de positionnement du robot par vision, était de tracer ligne par
ligne une série de points, encodée de façon a produire un schéma reconnaissable et non
ambigu sur l’axe horizontal. Le coefficient directeur de la ligne lue permet ainsi de déterminer
l’inclinaison du robot, laquelle est à son tour utilisée pour redresser l’image de la caméra pour
les prises de vue suivantes. Le décryptage du code permet de trouver la position selon l’axe
horizontal du robot, le nombre de lignes sa position selon l’axe vertical.
52 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.1. Réalisation d’un traitement d’images adapté
Init
i←jmax
i>jmin
j←imini-=1
j<imax
j++
img[i][j]est noir ?
floodfill
nombrede pixels
suffi-sant ?
nbclasses++
enregistrerla classe
Fin
Non
Non
Non
Oui
Oui
Oui
Oui
Figure 3.8 – Algorithme de segmentation et classification
53 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.2. Programmation embarquée
3.2. Programmation embarquée
3.2.1. Considérations matérielles
L’algorithme de traitement d’images devra être exécuté sur un RaspberryPi B version 2 15
-qui est déjà intégré au robot- le plus rapidement possible pour assurer un fonctionnement
proche du temps réel. Le PC embarqué choisi est muni d’un processeur ARM quad-core et
d’une puce graphique Broadcomm BCM2835 [11]. Ce type de matériel embarqué est très
proche de celui d’un smartphone actuel. En particulier la puce graphique est encore vendue
de nos jours, c’est pourquoi ses données techniques ne sont pas accessibles librement. Voici
une liste des principales caractéristiques techniques du RaspberryPi :
— 1 processeur quad-core ARM Cortex-A7 cadencé à 900MHz
— 1GB de mémoire vive
— 4 ports USB
— 40 pattes GPIO
— 1 port Ethernet
— 1 port Camera interface (CSI)
— 1 slot pour carte micro-SD
— 1 processeur graphique VideoCore IV 3D
Une des difficultés de développer sur cette plateforme est l’utilisation du GPU. En effet, au-
cune documentation de la puce n’est fournie et les sources du firmware, encore propriétaires,
ne sont pas publiées. En conséquence de quoi, toutes les applications et les utilisations de la
puce que l’on peut consulter sont dues à des hackers. Tous les outils et toutes les possibilités
de la puce ne sont pas exploités, ce qui a pu poser des problèmes dans le développement du
présent traitement. En particulier certaines limites matérielles ont été atteintes. Il a fallu me-
ner des tests pour déterminer expérimentalement les capacités de la puce. De plus, la caméra
est gérée par cette puce, mais le signal de synchronisation de la prise de vue n’a pas pu être
obtenu, ce qui s’est avéré handicapant pour la réalisation d’un asservissement visuel.
15. Le RaspberryPi est un mini-PC sur une seule carte développé par la fondation Raspberry Pi. Le but de ceprojet était de fournir une solution bon marché d’ordinateur sous Linux à destination des écoles pour démocratiserl’informatique.
54 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.2. Programmation embarquée
Dans l’idée d’adapter le programme pour le rendre le plus efficace possible deux chemins
peuvent être empruntés. Premièrement, prendre avantage du multicœur. Le système d’exploi-
tation Linux répartit la charge d’un programme multithreadé (en plusieurs thread 16. ) à raison
d’un thread par cœur [25], donc le programme sera écrit en quatre thread pour effectuer le
traitement au mieux quatre fois plus vite.
En second lieu, le RaspberryPi est muni d’une puce graphique. Il est possible d’utiliser
cette puce pour effectuer des calculs à la place du processeur ; cette technique est de plus
en plus couramment utilisée par exemple pour détecter des points de transition (technique
issue de la détection de contour) [2] ou encore pour réaliser un filtre de Canny [34]. Utiliser
la puce graphique permet de faire du calcul massivement parallèle, et si le gain en temps de
traitement est très élevé [6], malheureusement, les accès en mémoire de la puce graphique
sont très limités, ce qui permet de n’interagir qu’avec un nombre faible de pixels voisins.
Quoi qu’il en soit il est possible d’effectuer des tests sur quelques uns des pixels voisins
du pixel courant. La mémoire dévolue à chaque unité de traitement du GPU Broadcomm
BCM2835 est limitée à 31 unités de surface ; ce résultat a été obtenu expérimentalement.
L’opérateur déterminé au 3.1.3 fait intervenir 29 valeurs, ce qui est très intéressant dans
notre cas d’application puisque ce filtre est optimisé pour ce GPU.
3.2.2. Capture de l’image
Le RaspberryPi est muni d’un port CSI sur lequel on peut brancher un module caméra
conçu exprès. Cette caméra est compacte et très légère, idéale pour être embarquée. La
caméra permet de prendre des images à la résolution HD (1920x1024 px) à une fréquence
de 30Hz. En baissant la résolution de l’image à VGA (640x480 px), les images peuvent être
prises à une fréquence pouvant atteindre 90Hz.
16. Un thread ou fil d’exécution ou tâche représente l’exécution d’un ensemble d’instructions d’un processeur. Tousles threads d’un même processus se partagent sa mémoire virtuelle, mais tous les threads possèdent leur propre piled’appel. Sur un processeur à plusieurs cœurs, il est possible d’exécuter un thread par cœur simultanément.
55 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.2. Programmation embarquée
Figure 3.9 – Module caméra
Un des inconvénients majeurs de cette caméra est que la distance focale est fixe. Il n’y a
en théorie pas moyen de la changer. En pratique il a été possible de bouger la lentille en la
désolidarisant du boîtier, c’est à dire en coupant des points de colle. La manipulation à suivre
est donnée ici 17.
Le périphérique de la caméra est commandé par le GPU, lequel gère la capture de l’image,
son encodage jusqu’à l’affichage. Pour communiquer avec ce type de périphérique, on fait
appel à la bibliothèque MMAL 18. Le composant caméra de MMAL existe déjà en librairie.
Comme on peut le voir sur la Figure 3.10, il est muni de 3 ports, un pour l’affichage direct
de la capture, un pour le flux vidéo et un pour la capture statique d’image. C’est le dernier
qui sera principalement utilisé, puisqu’il a l’avantage de capturer les images une à la fois. On
commence donc le programme en instanciant les ports et en leur affectant une sortie.
Figure 3.10 – Composant camera MMAL
17. https://www.raspberrypi.org/learning/infrared-bird-box/worksheet/
18. MMAL (Multi-Media Abstraction Layer) est un framework qui offre une interface plutôt bas niveau et côtéclient, pour une interface avec les composants multimédia sur VideoCore. MMAL permet aussi de créer de nouveauxcomposants et de les interfacer simplement.
56 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.2. Programmation embarquée
La librairie a aussi des fonctions qui permettent d’accéder à des réglages bas-niveau de
la caméra. Entre autres on peut dès la capture paramétrer le mode de fonctionnement de
la caméra. Ces modes, dont les principales caractéristiques sont détaillées dans le tableau
Figure 3.11, déterminent entre autres le framerate 19 maximal admissible, la résolution de
l’image capturée ou encore l’utilisation de binning 20. On choisit ici le mode 6.
Mode Résolution Rapport h/l Framerates Binning
1 1920x1080 16 :9 1-30fps Non
2 2592x1944 4 :3 1-15fps Non
3 2592x1944 4 :3 0.1666-1fps Non
4 1296x972 4 :3 1-42fps 2x2
5 1296x730 16 :9 1-49fps 2x2
6 640x480 4 :3 42.1-60fps 4x4
7 640x480 4 :3 60.1-90fps 4x4
Figure 3.11 – Modes d’acquisition de la caméra
On peut aussi choisir dès cette étape de régler la vitesse de l’obturateur (shutter en an-
glais) ; dans le cas présent elle est réglée à 15ms. Enfin, l’interface permet de réaliser immé-
diatement à la capture le DRC 21 ; cette possibilité est aussi utilisée, en plaçant sa valeur à
fort.
Les images capturées par la caméra sont ensuite stockées dans des buffers gérés eux
aussi par la bibliothèque MMAL. Ces buffers sont en réalité dans une liste de buffers (une
liste par port de sortie), puisqu’il faut à la fois pouvoir capturer l’image et faire transiter
l’image précédente vers l’espace mémoire accessible depuis le processeur. La capture étant
19. Nombre d’images par seconde, Frames Per Second (FPS) en anglais
20. Le binning consiste à regrouper plusieurs pixels du capteur de la caméra lors de l’acquisition d’une image. Lesvaleurs des pixels sont généralement cumulées,cela permet d’augmenter la sensibilité du capteur au détriment de sarésolution. Le binning est aussi utilisé pour réduire le temps de lecture du capteur ou la taille de l’image lorsque lapleine résolution n’est pas nécessaire.
21. Dynamic Range Compression, compression de gamme dynamique. C’est une technique de compression quiaccentue les signaux faibles et affaiblit les forts, c’est à dire qui augmente l’importance des tons sombres. Celaaméliore la qualité de l’image en environnement peu éclairé
57 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.2. Programmation embarquée
faite avec un rolling shutter, l’image est capturée par déroulement du shutter. Les pixels sont
donc transférés en flux continu et non pas d’un coup en bloc et le buffer de réception se
remplit petit à petit, travailler directement avec ce buffer présente alors le risque de capturer
une image fausse. On laisse au GPU le soin de gérer une pile de 3 buffers pour assurer la
capture de l’image.
On remarque ici, que, pour assurer un asservissement visuel rapide performant, il est
nécessaire de connaître l’instant de capture de l’image. Cette possibilité n’est malheureuse-
ment pas offerte par la librairie MMAL, puisqu’il n’y a pas de flag qui déclare une prise de
vue terminée. Tout au plus, il est possible d’attendre le remplissage d’un des buffers de la
liste suscitée. L’interface caméra-RaspberryPi ne permet pas d’assurer la contrainte temps-
réel d’un asservissement visuel. À notre niveau, l’élément déclenchant du traitement d’image
sera le remplissage d’un buffer. Ce buffer fait partie d’une liste d’au moins trois buffers qui se
remplissent alternativement cette partie est gérée de façon transparente par le GPU. On doit
donc compter avec une à trois frames de retard pur.
Une fonction appelée dans la boucle principale est chargée d’attendre le remplissage du
buffer. Lorsque cet évènement est repéré, le contenu de ce buffer est chargé dans une texture
OpenGL.
3.2.3. Partie GPU
Pour utiliser le chipset graphique, on passe par la bibliothèque logicielle OpenGL 22 - ici
dans sa version embarquée (OpenGL ES 2.0) - [1], qui permet de compiler des shaders 23. Le
langage de programmation des shaders est le GLSL [17].
Les shaders forment un pipeline 24 présenté Figure 3.12. Le fonctionnement est le suivant :
1. On déclare une géométrie d’objet au vertex shader. Dans notre cas, la géométrie est un
22. (Open Graphics Library) est un ensemble de près de 250 fonctions de calcul d’images qui décrit la géométried’objets sous forme de points, de vecteurs ou de textures. OpenGL effectue ensuite des calculs de projection en vuede déterminer l’image à l’écran, en tenant compte de la distance, de l’orientation etc.
23. Un shader est un programme informatique utilisé pour le processus de rendu réalisé par une carte graphique.Il sert à décrire l’absorption et la diffusion de la lumière, la texture à utiliser, le déplacement de primitives et biend’autres effets post-traitement. Par la conception même du processus de rendu, les shaders sont les candidats idéauxpour une exécution parallèle par le processeur graphique d’une carte graphique
24. Un pipeline est l’élément dans lequel l’exécution des instructions par le processeur est découpée en étages, ondit aussi chaîne de traitement
58 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.2. Programmation embarquée
carré dont on passe les coordonnées des sommets. À ce moment, on peut aussi faire une
rotation de l’image en entrant un angle. En connaissant un angle de rotation du robot,
on peut alors redresser l’image.
2. À l’étape suivante la surface déclarée est découpée en triangles. Elle est ensuite tramée
en polygones.
3. L’étape suivante est celle qui fait apparaître les couleurs. C’est l’étape durant laquelle
est chargée et générée la texture sur l’objet. Dans notre cas la texture est le canal de
luminance de l’image capturée présente dans le buffer. C’est à ce moment que l’image
est divisée en pixels (ou fragments) et c’est aussi ici que l’algorithme intervient en chan-
geant la valeur des pixels et en lisant celle des voisins.
4. Ensuite est calculée la profondeur de l’image, qui est plane dans ce cas.
5. Les couleurs sont calculées à partir des valeurs laissées dans la couleur du fragment,
puis la transparence est appliquée.
6. Enfin l’image obtenue est copiée dans le buffer de rendu graphique.
Sur le schéma 3.12 qui résume ce processus, les étapes auxquelles on peut accéder depuis
OpenGL sont en orange. Il s’agit des deux shaders que l’on programme soi-même : le vertex
shader pour spécifier la géométrie de l’objet et le fragment shader pour spécifier la couleur
des pixels.
Figure 3.12 – Pipeline de rendu graphique avec les différents shaders
On termine cette étape avec une image monochrome des contours d’épaisseur faible des
objets colorés. Cette image est transférée de l’espace mémoire du GPU vers l’espace mémoire
du CPU en utilisant la fonction OpenGL glReadPixels. Dans le portage d’OpenGL en embarqué
59 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.2. Programmation embarquée
- OpenGL ES - cette fonction a été simplifiée et a perdu beaucoup d’options qui permettent
dans la version originale d’accélérer les transferts. Ainsi il n’est possible de transférer que
des images avec 4 canaux de couleur (RGBA) et les couleurs sont obligatoirement codées sur
8 bits chacunes. Ceci fait que cette étape devient le goulet d’étranglement du programme,
puisque ce chargement est à lui seul l’étape la plus longue, d’une durée de 12 ms pour une
image de taille VGA.
3.2.4. Boucle principale
La fonction principale initialise le contexte OpenGL, ainsi que les différents outils MMAL.
C’est elle qui instancie les différents buffers. C’est enfin elle qui lance la boucle principale.
Elle permet aussi moyennant deux options à déterminer dans main.h avant compilation du
programme pour réaliser des essais et des test de performances du code :
1. le flag VISUAL, qui permet de lancer un environnement supplémentaire, OpenCV 25,
pour afficher le résultat des prises de vue de la caméra et le résultat des calculs : les
régions repérées sont colorées, leurs centres sont affichés ainsi que les droites résultant
de la régression linéaire.
2. le flag TIME, qui permet de mesurer le temps d’exécution d’une boucle et des diffé-
rents threads. Utile pour déterminer la consommation de temps processeur et la vitesse
d’exécution du programme, donc les capacités de l’asservissement visuel.
La boucle principale continue tant que le signal d’arrêt n’est pas donné. Pour permettre
de profiter pleinement des quatre cœurs du processeur, la boucle principale va lancer trois
autres thread pour permettre de faire 4 opérations en même temps.
Un premier thread est chargé de la capture de l’image. Il commence par reprendre le
contexte OpenGL, lance la fonction qui attend le flag de remplissement du buffer MMAL
puis transforme cette image en texture, envoie ensuite un buffer vide dans la liste de buffers
MMAL ; ensuite effectue la régression linéaire sur les centroïdes qu’il lit dans la liste des
classes remplie par d’autres thread.
25. OpenCV (pour Open Computer Vision) est une bibliothèque graphique libre, dotée de nombreuses fonctionnali-tés très diversifiées pour effectuer entre autres du traitement d’images ou encore la création d’interfaces graphiquesbasiques.
60 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.2. Programmation embarquée
Un deuxième thread récupère en premier lieu le contexte OpenGL, puis il appelle la fonc-
tion glReadPixels pour transférer l’image de l’espace mémoire du GPU vers celui du CPU,
enfin il relâche le contexte OpenGL. Les deux derniers threads ont interagi avec le contexte
OpenGL. En fait ce contexte, qui contient entre autre un certain nombre d’objets et de poin-
teurs utiles au fonctionnement d’OpenGL ne peut être partagé entre plusieurs thread. Pour
pouvoir utiliser les mêmes ressources dans deux threads différents, il faut donc pouvoir se
faire passer ce contexte. On initialise les threads avec un pointeur sur ce contexte et on met
un sémaphore pour déterminer qui a le contrôle. Le sémaphore est la méthode utilisée cou-
ramment pour restreindre l’accès à des ressources partagées et synchroniser les processus
dans un environnement de programmation concurrente. C’est une variable dont la valeur peut
être testée et modifiée en une opération atomique. Dans cet exemple d’utilisation, les deux
thread commencent par une fonction qui attend de façon bloquante la mise à l’état haut de ce
sémaphore. Immédiatement il est remis à 0 et le thread qui a pris la main peut poursuivre son
déroulement. Quand il a fini, une opération remet le sémaphore à 1. Ainsi un seul des deux
thread peut utiliser le contexte OpenGL à la fois.
Les deux derniers threads lancés exécutent la fonction de segmentation et classification
vue à la partie 3.1.5. Au lieu de s’exécuter sur l’image entière, chacun de ces deux threads
reçoit la moitié de l’image à parcourir : l’image est coupée en deux dans le sens de la lon-
gueur. Cela permet d’accélérer considérablement la vitesse de lecture de l’image qui est une
opération lente. Pour éviter le cas où une des formes à détecter se trouve à cheval entre deux
zones - ce qui ne devrait pas arriver dans le cas normal d’utilisation - une zone d’exclusion a
été mise en place pour le coordonnée en y du centroïde. Ces deux threads partagent aussi des
objets en commun : la liste des classes et l’index actuel de la liste. Pour éviter les conflits, une
exclusion mutuelle 26 a été mise en place pour protéger ces variables.
26. Un Mutex est une primitive de synchronisation utilisée pour éviter que des ressources partagées ne soientutilisées en même temps. Ces algorithmes permettent de réguler l’accès aux données, en permettant par exemple àun seul thread d’y accéder à la fois.
61 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.2. Programmation embarquée
Init stop ? Fin
charger imagecourante
segmentation segmentation
semaphore
charger contexteOpenGL
semaphore
charger contexteOpenGL
glReadPixels
relâcher lecontexte OpenGL
mutex
mutex
déterminerles centroïdes déterminer
les centroïdes
charger buf-fer MMAL
transformerl’image en tex-ture OpenGL
relâcher lecontexte OpenGL
envoyer buffervide à MMAL
régression li-néaire sur les
centroïdes
vers le GPU
Figure 3.13 – Algorithme de traitement d’images
3.2.5. Résultats de la partie vision
Le schéma Figure 3.13 résume cet algorithme. On arrive bien à déterminer les centres des
points observés et à déduire la ligne moyenne. Les performances en termes de temps de l’al-
62 de 79 Maximilian Lesellier
Mémoire de fin d’études 3.2. Programmation embarquée
gorithme ont été mseurées pour vérifier qu’on utilise suffisamment peu de temps processeur
pour permettre à l’asservissement et à RPIt de fonctionner correctement, soit moins de 65%.
On a ainsi posé une brique nécessaire pour obtenir un asservissement visuel rapide effi-
cace. En utilisant cet outil il va désormais être possible de mesurer l’erreur en position et de
refermer la boucle de contrôle du robot. Un bloc de vision exécutant ce programme est en
train d’être développé pour la toolbox RPIt.
63 de 79 Maximilian Lesellier
Mémoire de fin d’études Conclusion
Conclusion
Au terme de ce PFE, on obtient un robot à câbles à deux degrés de liberté pouvant tracer
un dessin. Après avoir mis en évidence les difficultés techniques du repérage en position d’un
robot à deux câbles dans un plan, on a utilisé deux types d’approches différentes pour les
résoudre. En premier lieu on a tenté en utilisant le modèle mécanique de corriger le système.
Les résultats n’ayant pas été concluants, on a réfléchi à la mise en place d’un asservisse-
ment visuel, avec comme contrainte supplémentaire d’utiliser le matériel déjà présent. Entre
autres, un algorithme de vision adapté à la tâche a été développé. Ce travail n’a malheureu-
sement pas pu aboutir à un asservissement visuel complet pour des raisons liées au matériel
utilisé. En effet, l’impossibilité de connaître l’instant exact de la prise de vue et la durée du
retard pur, rendent impossible l’implémentation d’un asservissement visuel rapide.
L’asservissement visuel qui utilisera la caméra actuellement fonctionnelle, une fois que
son code aura été porté avec succès sous Simulink, pourra être envisagé par deux approches.
Soit on pourra effectuer un recalage préalable sur l’image au moment de la mise en place
du robot puis fonctionner en boucle ouverte, soit on pourra introduire l’asservissement visuel
dans une boucle et corriger le tracé de proche en proche. Les deux approches sont rendues
possibles par le code de vision déjà développé.
Une fois l’asservissement visuel réalisé, le PiSaRo sera entièrement fonctionnel et pourra
exécuter des fresques dans un espace de travail de grande taille limité seulement par la
longueur des deux câbles.
64 de 79 Maximilian Lesellier
Mémoire de fin d’études Bibliographie
Bibliographie
[1] OpenGL ES 2.0 Reference. URL : https://www.khronos.org/opengles/sdk/docs/man/.
[2] Renaud Keriven Alexandre Chariot. GPU-boosted online image matching. Tampa, United States, December
2008. IEEE. URL : https://hal-enpc.archives-ouvertes.fr/hal-00835096/document.
[3] Samuel Bouchard. Géométrie des Robots Parallèles entraînés par des Câbles. PhD thesis, Université Laval,
2008. URL : http://archimede.bibl.ulaval.ca/archimede/fichiers/25528/25528.pdf.
[4] John Canny. A computational approach to edge detection. Pattern Analysis and Machine Intelligence, IEEE
Transactions on, (6) :679–698, 1986.
[5] M Carricato and Jean Pierre Merlet. Geometrico-Static Analysis of Under-Constrained Cable-Driven Parallel
Robots - Springer. In Advances in Robot Kinematics : Motion in Man and Machine, Springer, pages 309–319.
2010. URL : http://link.springer.com/chapter/10.1007/978-90-481-9262-5_33#page-1.
[6] Daniel Castaño-Díez, Dominik Moser, Andreas Schoenegger, Sabine Pruggnaller, and Achilleas S. Frangakis.
Performance evaluation of image processing algorithms on the GPU. Journal of structural biology, 164(1) :153–
160, 2008.
[7] Ryad Chellal, Edouard Laroche, Loïc Cuvillon, and Jacques Gangloff. An Identification Methodology for 6-DoF
Cable-Driven Parallel Robots Parameters Application to the INCA 6d Robot. In Cable-Driven Parallel Robots,
pages 301–317. Springer, 2013.
[8] Tej Dallej, Marc Gouttefarde, Nicolas Andreff, Redwan Dahmouche, and Philippe Martinet. Vision-based mode-
ling and control of large-dimension cable-driven parallel robots. In Intelligent Robots and Systems (IROS), 2012
IEEE/RSJ International Conference on, pages 1581–1586. IEEE, 2012.
[9] Rachid Deriche. Using Canny’s criteria to derive a recursively implemented optimal edge detector. International
journal of computer vision, 1(2) :167–187, 1987.
[10] Bernard Espiau, François Chaumette, and Patrick Rives. A new approach to visual servoing in robotics. Robotics
and Automation, IEEE Transactions on, 8(3) :313–326, 1992.
[11] Raspberry Pi Foundation. Raspberry Pi 2 Model B. http ://www.raspberrypi.org/products/raspberry-pi-2-model-
b/. URL : http://www.raspberrypi.org/products/raspberry-pi-2-model-b/.
[12] Lorenzo Gagliardini, Stéphane Caro, Marc Gouttefarde, Philippe Wenger, and Alexis Girin. A Reconfigurable
Cable-Driven Parallel Robot for Sandblasting and Painting of Large Structures. In Cable-Driven Parallel Robots,
pages 275–291. Springer, 2015.
[13] Jacques Gangloff. Raspberry Pi Simulink Coder target (RPIt) - Équipe Automatique Vision et Robotique. URL :
http://icube-avr.unistra.fr/fr/index.php/Raspberry_Pi_Simulink_Coder_target_(RPIt).
65 de 79 Maximilian Lesellier
Mémoire de fin d’études Bibliographie
[14] Clément Gosselin and Simon Foucault. Experimental Determination of the Accuracy of a Three-Dof Cable-
Suspended Parallel Robot Performing Dynamic Trajectories. In Cable-Driven Parallel Robots, pages 101–112.
Springer, 2015.
[15] Robert M Haralick, Stanley R Sternberg, and Xinhua Zhuang. Image analysis using mathematical morphology.
Pattern Analysis and Machine Intelligence, IEEE Transactions on, (4) :532–550, 1987.
[16] Martin J-d Otis, Thien-Ly Nguyen-Dang, Thierry Laliberte, Denis Ouellet, and Denis Laurendeau. Cable tension
control and analysis of reel transparency for 6-dof haptic foot platform on a cable-driven locomotion interface.
2009.
[17] Dave Baldwin John Kessenich and Randi Rost. The OpenGL® Shading Language, volume 1. John Kessenich,
LunarG, June 2014. URL : http://www.opengl.org/registry/doc/GLSLangSpec.4.40.pdf.
[18] Sadao Kawamura, Won Choe, Satoshi Tanaka, and Shunmugham R Pandian. Development of an ultrahigh speed
robot FALCON using wire drive system. In Robotics and Automation, 1995. Proceedings., 1995 IEEE Interna-
tional Conference on, volume 1, pages 215–220. IEEE, 1995.
[19] Pascal Lafourcade. Étude des manipulateurs parallèles à câbles, conception d’une suspension active pour souf-
flerie. École Nationale Supérieur de l’Aéronautique et de l’Espace, 2004.
[20] Maximilian LESELLIER and Pr Jacques GANGLOFF. Development of an improved firmware for the Lego EV3.
2014. URL : http://icube-publis.unistra.fr/7-Lese14.
[21] David Marr and Ellen Hildreth. Theory of edge detection. Proceedings of the Royal Society of London. Series
B. Biological Sciences, 207(1167) :187–217, 1980.
[22] Jean Pierre Merlet. Parallel robots. Springer, 2006. URL : http://scholar.google.fr/scholar?q=merlet&
btnG=&hl=fr&as_sdt=0%2C5.
[23] Tien-Thanh Nguyen, Edouard Laroche, Loïc Cuvillon, Jacques Gangloff, and Olivier Piccin. Identification du
modèle phénoménologique d’un robot parallèle à câbles. Journal Europeen des Systemes Automatises-JESA-
APII, 46(6) :673, 2012.
[24] Judith MS Prewitt. Object enhancement and extraction. Picture processing and Psychopictorics, 10(1) :15–19,
1970.
[25] Suzanne Rivoire. A breadth-first course in multicore and manycore programming. In Proceedings of the 41st
ACM technical symposium on Computer science education, pages 214–218. ACM, 2010.
[26] Jean Serra. Mathematical Morphology and Image Segmentation.
[27] Gregory D. Hager Seth A. Hutchinson and Peter Corke. A tutorial on visual servo control. In A tutorial on visual
servo control, pages 651–670, 12 (6), 1996. IEEE. URL : http://scholar.google.fr/scholar_url?url=http:
//eprints.qut.edu.au/50025/1/&hl=fr&sa=X&scisig=AAGBfm1PG9Se9v2fmYxV2McueP5o6f7Yug&nossl=1&
oi=scholarr&ei=atAOVefmEMGMaLqRgNgE&ved=0CB8QgAMoADAA.
[28] Mehmet Sezgin. Survey over image thresholding techniques and quantitative performance evaluation. Journal
of Electronic imaging, 13(1) :146–168, 2004.
[29] Irwin Sobel and Gary Feldman. A 3x3 isotropic gradient operator for image processing. 1968.
[30] Roger Y Tsai. A versatile camera calibration technique for high-accuracy 3d machine vision metrology using
off-the-shelf TV cameras and lenses. Robotics and Automation, IEEE Journal of, 3(4) :323–344, 1987.
[31] R Verhoeven, M Hiller, and S Tadokoro. Workspace, Stiffness, Singularities and Classification of Tendon-Driven
Stewart Platforms - Springer. In Advances in Robot Kinematics, Analysis and control, Springer. 1998. URL :
http://link.springer.com/chapter/10.1007/978-94-015-9064-8_11#page-1.
66 de 79 Maximilian Lesellier
Mémoire de fin d’études Bibliographie
[32] Xavier Weber, Loic Cuvillon, and Jacques Gangloff. Active vibration canceling of a cable-driven parallel robot
using reaction wheels. In Intelligent Robots and Systems (IROS 2014), 2014 IEEE/RSJ International Conference
on, pages 1724–1729. IEEE, 2014.
[33] Xavier Weber, Loïc Cuvillon, and Jacques Gangloff. Active vibration canceling of a cable-driven parallel robot in
modal space. Seattle, 2015.
[34] Willem Visser Yuko Roodt and Willem A. Clarke. Image Processing on the GPU : Implementing the Canny
Edge detection Algorithm. South Africa, November 2007. URL : http://www.prasa.org/proceedings/2007/
prasa07-26.pdf.
67 de 79 Maximilian Lesellier
Annexes
Mémoire de fin d’études Annexe A
Annexe A
Détermination expérimentale du
centre de gravité
On procède en considérant le robot PiSaRo comme un objet plan. Pour déterminer la posi-
tion du centre de gravité, le protocole expérimental est le suivant :
1. attacher un fil à l’un des coins du robot
2. attacher un fil à plomb au fil précédent
3. suspendre le robot par son fil
4. reporter la ligne suivie par le fil à plomb
Cette ligne tracée par le fil à plomb représente la verticale. Or, on sait que le centre de
gravité d’un objet est situé le long de cette ligne. En reprenant la manipulation précédente
avec deux autres points, on obtient le centre de gravité à l’intersection des lignes tracées. En
réalité, les incertitudes de mesure font plutôt tracer un triangle qu’un point unique. Le centre
de gravité du robot se trouve alors dans ce triangle, on choisit le centre de gravité du triangle,
celui fournit une bonne approximation de ses coordonnées.
Figure A.1 – Détermination du centre de gravité
69 de 79 Maximilian Lesellier
Réglage manuel
Y(t)
Y
0
XY Graph
XDist
X(t)
X
0
Rampe X
Rampe
x
y
X
Y
fcn
Position1PID(z)
Ref
PID(z)Ref
Mot2
In1Out1
Mot1
In1Out1
Mesure_position
d2
d1
x
y
alpha_
Mes d2
Mes d1
Mes Y
Mes X
MGI
x
y
d1
d2
J_inv
alpha_
J
Ind
Générateur de consigne
xlist
ylist
ErrX
ErrY
Cnt
Out
-K-
-K-
1
1
0.5
1
1
-K-
-K- 0.5
From
Workspace1
Ylist
From
Workspace
Xlist
Erreur pos
Distorsion
x
y
X
Y
Dist
Discrete-Time
Integrator2
K Ts
z-1
K Ts
z-1
Correction feutre
x
y
alpha_
yf
xf
fcn
Consgne mot3
Consgne mot
Consgne X
Commande mot
Bloc RST2
RST
Ref
Mes
U
Bloc RST1
RST
Ref
Mes
U
Annexe B
Modèle du robot
Figure B.1 : Modèle du robot
Mémoire de fin d’études Annexe B
70 de 79 Maximilian Lesellier
Mémoire de fin d’études Annexe C
Annexe C
Réglage d’un correcteur PID par
approches successives
Ce tutoriel est aussi disponible sur le site du fabricant de moteurs Esco : voir ici 27.
La méthode expliquée ci-dessous est à destination des utilisateurs d’un correcteur indus-
triel et contient des instructions spécifiques à ce matériel. Cependant on peut en extraire le
principe du réglage par approches successives.
27. https://www.google.fr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0CDEQFjACahUKEwiq9u7ozILHAhWC0xQKHYmNC_s&url=http%3A%2F%2Fwww.esco.be%2FProtect%2FPLC%2520Hitachi%2FHardware%2FOthers%2FManuals%2FPID%2520Tunning.pdf&ei=Nfa5VeqHJoKnU4mbrtgP&usg=AFQjCNHeep5ZuGuzOUvcqlq37Iz3SnUIQw&sig2=6J_5qG5M_gVGWxUHWaHb3w
71 de 79 Maximilian Lesellier
Mémoire de fin d’études Annexe C
72 de 79 Maximilian Lesellier
Mémoire de fin d’études Annexe C
73 de 79 Maximilian Lesellier
Mémoire de fin d’études Annexe C
Figure C.1 – Réglage d’un correcteur PID par approches successives
74 de 79 Maximilian Lesellier
Mémoire de fin d’études Annexe D
Annexe D
Générateur de trajectoires
1 I=flipdim(I,1);
2 I=rgb2gray(I);
3 I=im2bw(I,0.4);
4 I=edge(I,'canny',0.4);
5 I = bwareaopen(I,130);
6
7 [B,L,N]=bwboundaries(I,4);
8
9 coord=[];
10
11 for k = 1:length(B)
12 boundary = B{k};
13 coord=[coord;[boundary(1,2), boundary(1,1), up]];
14 coord=[coord;[boundary(:,2), boundary(:,1), down*ones(length(boundary
),1)]];
15 coord=[coord;[coord(end,1), coord(end,2), up]];
16 end
17
18 Xlist=coord(:,1)';
19 Ylist=coord(:,2)';
20 Plist=coord(:,3)';
Figure D.1 – Source du générateur de trajectoires
75 de 79 Maximilian Lesellier
Mémoire de fin d’études Annexe E
Annexe E
Source des shaders
E.1. Vertex shader
1 /*
2 * Implementing filter as GLSL shaders.
3 * The input image is a greyscale texture from the MMAL buffer Y plane.
4 * Vertex takes as an input an angle to rotate the image
5 */
6
7 attribute vec2 vertex;
8 uniform float angle;
9 void main(void) {
10 vec2 b;
11 b.x = vertex.x*cos(angle)-vertex.y*sin(angle);
12 b.y = vertex.y*cos(angle)+vertex.x*sin(angle);
13 texcoord = 0.5 * (vertex + 1.0);
14 gl_Position = vec4(b,0.0,1.0);
15 }
Figure E.1 – Source du vertex shader
76 de 79 Maximilian Lesellier
Mémoire de fin d’études Annexe E
E.2. Fragment shader
1 /* The texture format for EGL_IMAGE_BRCM_MULTIMEDIA_Y is a one byte per
2 * pixel greyscale GL_LUMINANCE.
3 *
4 * At first the image is binarized.
5 * Then a filter is applied that acts as an edge detector and also as an
6 * eroding filter by testing the neighboring pixel values. The convolution
7 * mask applied is represented below. After the convolution, the value is
8 * tested and if it is between 2 limits, the pixel is a non isolated (no
9 * noise) border pixel.
10 * If the pixel is from the background, it is ignored
11 */
12 /* x5 x3 v1 x x2 x4 x6
13 * y6 1
14 * y4 1 1 1 1 1
15 * y2 1 1 1 1 1
16 * y 1 1 1 1 1 1 1
17 * y1 1 1 1 1 1
18 * y3 1 1 1 1 1
19 * y5 1
20 *
21 * */
22
23 extension GL_OES_EGL_image_external : require
24 uniform samplerExternalOES tex;
25 varying vec2 texcoord;
26 uniform vec2 tex_unit;
27 uniform float threshold;
28
29 void main(void) {
30 float x = texcoord.x;
31 float y = texcoord.y;
32 float x1 = x - tex_unit.x;
33 float y1 = y - tex_unit.y;
77 de 79 Maximilian Lesellier
Mémoire de fin d’études Annexe E
34 float x2 = x + tex_unit.x;
35 float y2 = y + tex_unit.y;
36 float x3 = x - 2.0*tex_unit.x;
37 float y3 = y - 2.0*tex_unit.y;
38 float x4 = x + 2.0*tex_unit.x;
39 float y4 = y + 2.0*tex_unit.y;
40 float x5 = x - 3.0*tex_unit.x;
41 float y5 = y - 3.0*tex_unit.y;
42 float x6 = x + 3.0*tex_unit.x;
43 float y6 = y + 3.0*tex_unit.y;
44
45 vec2 p[29];
46 vec4 t[29];
47 float col;
48 vec4 minValue=vec4(1.0);
49
50 p[0] = vec2(x3, y3);
51 p[1] = vec2(x1, y3);
52 p[2] = vec2(x, y3);
53 p[3] = vec2(x2, y3);
54 p[4] = vec2(x4, y3);
55 p[5] = vec2(x3, y1);
56 p[6] = vec2(x1, y1);
57 p[7] = vec2(x, y1);
58 p[8] = vec2(x2, y1);
59 p[9] = vec2(x4,y1);
60 p[10] = vec2(x3,y);
61 p[11] = vec2(x1,y);
62 p[12] = vec2(x,y);
63 p[13] = vec2(x2,y);
64 p[14] = vec2(x4,y);
65 p[15] = vec2(x3,y2);
66 p[16] = vec2(x1,y2);
67 p[17] = vec2(x,y2);
68 p[18] = vec2(x2,y2);
69 p[19] = vec2(x4,y2);
78 de 79 Maximilian Lesellier
Mémoire de fin d’études Annexe E
70 p[20] = vec2(x3,y4);
71 p[21] = vec2(x1,y4);
72 p[22] = vec2(x,y4);
73 p[23] = vec2(x2,y4);
74 p[24] = vec2(x4,y4);
75
76 p[25] = vec2(x5,y);
77 p[26] = vec2(x,y5);
78 p[27] = vec2(x,y6);
79 p[28] = vec2(x6,y);
80
81 int trigger=0;
82 for(int i=0;i<29;i++)
83 {
84 t[i] = vec4(lessThanEqual(texture2D(tex, p[i]),vec4(threshold)));
85 if(t[i].r==0.0 && i!=12)
86 trigger=trigger+1;
87 }
88 if(trigger>=1 && trigger <20)
89 col=1.0;
90 else
91 col=0.0;
92 if(t[12].r==0.0)
93 col=0.0;
94 gl_FragColor = vec4(col,0.0,0.0,1.0);
95 }
Figure E.2 – Source du fragment shader
79 de 79 Maximilian Lesellier