asservissement visuel d’un robot parallèle à câbles...

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


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


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


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


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.


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.



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.


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)



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.



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


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



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



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.



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.



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.



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.


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.



×

× ×

×

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



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.



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



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



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.



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



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


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



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



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



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.



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



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.



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


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.



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



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.



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.



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



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



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.



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



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


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.



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.



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.



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.



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.



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



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



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



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.



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



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.



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


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.



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.



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.


https://www.raspberrypi.org/learning/infrared-bird-box/worksheet/

https://www.raspberrypi.org/learning/infrared-bird-box/worksheet/


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é



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



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é



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



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.



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-



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.


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.


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


https://www.khronos.org/opengles/sdk/docs/man/

https://hal-enpc.archives-ouvertes.fr/hal-00835096/document

http://archimede.bibl.ulaval.ca/archimede/fichiers/25528/25528.pdf

http://link.springer.com/chapter/10.1007/978-90-481-9262-5_33#page-1

http://www.raspberrypi.org/products/raspberry-pi-2-model-b/

http://icube-avr.unistra.fr/fr/index.php/Raspberry_Pi_Simulink_Coder_target_(RPIt)


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


http://www.opengl.org/registry/doc/GLSLangSpec.4.40.pdf

http://icube-publis.unistra.fr/7-Lese14

http://scholar.google.fr/scholar?q=merlet&btnG=&hl=fr&as_sdt=0%2C5

http://scholar.google.fr/scholar?q=merlet&btnG=&hl=fr&as_sdt=0%2C5

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



http://link.springer.com/chapter/10.1007/978-94-015-9064-8_11#page-1


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


http://www.prasa.org/proceedings/2007/prasa07-26.pdf

http://www.prasa.org/proceedings/2007/prasa07-26.pdf

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é


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


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


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






Figure C.1 – Réglage d’un correcteur PID par approches successives


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


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



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;



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



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


asservissement visuel d’un robot parallèle à câbles...

Documents