rapport final

ÉCOLE DE TECHNOLOGIE SUPÉRIEURE
UNIVERSITÉ DU QUÉBEC
RAPPORT TECHNIQUE
PRÉSENTÉ À L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE
DANS LE CADRE DU PROJET DE FIN D’ÉTUDES
SIMPLIFICATION AU PROBLÈME DE DÉFINITION
DE POINTS DE RÉFÉRENCE D’UN ROBOT
PAR
MASSÉ, Éric
MONTRÉAL, LE 12 AVRIL 2010
RÉSUMÉ
Ce projet est la conception d'une application pour le "FlexPendant" d'un robot ABB.
L'application permet de modifier les "RobTarget" du contrôleur à l'aide d'un écran simple et
visuel. L'édition des trois valeurs de positions (x,y,z) est directement modifiée à l'aide du clavier
numérique et l'orientation se modifie à l'aide de six boutons effectuant des rotations selon un
seul axe à la fois. Une représentation de l'orientation du référentiel peut être dessinée en 3D par
projection orthogonale ou centrale. Les données sont bien sûr sauvegardées dans le contrôleur.
Ce rapport porte sur les étapes de conception du projet en plus de parler de certaines notions
importantes à son développement.
LISTE DES FIGURES
Figure 1 Calculs de projection centrale ..................................................................................... 5
Figure 2 Deux types de projection ............................................................................................ 6
Figure 3 Schéma de l’objet « Controller » .............................................................................. 12
Figure 5 Classe CControleur ................................................................................................... 13
Figure 6 Classe CAngleEuler .................................................................................................. 13
Figure 4 Classe CRobTarget ................................................................................................... 13
Figure 7 Méthode Sauvegarder ............................................................................................... 16
Figure 8 Fenêtre principale de l'application ............................................................................ 17
Figure 9 Fenêtre d'édition ........................................................................................................ 18
Figure 10 Fenêtre d'édition avec représentation orthogonale.................................................. 19
Figure 11 Clavier numérique................................................................................................... 20
Figure 12 Validation des résultats ........................................................................................... 22
ii
TERMINOLOGIE
Classe : En programmation orientée objet, modèle abstrait définissant des variables et des
méthodes pour un type donné d'objet, et à partir duquel sont créés des objets concrets
possédant des valeurs particulières.
Une classe d'objets est un moule général sur lequel on crée des objets. Elle se
caractérise par ses variables et ses méthodes. Ainsi, lorsqu'on déclare l'appartenance
d'un objet à une classe, on le fait hériter automatiquement des propriétés de la classe.
Définition tirée du Grand Dictionnaire Terminologique1
FlexPendant : Le FlexPendant est la commande de contrôle du robot avec un écran tactile, des
boutons, un manche à balai (joystick) et des boutons de sécurités.
Méthode : En programmation orientée objet, fonction associée à une classe d'objets, qui
contribue à définir le comportement des objets de ce type de classe. 2
Persistante : Une persistante peut être décrite comme étant une variable “persistante”. Lorsqu’un
programme est sauvegardé, la valeur d’initialisation reflète la valeur actuelle de la
persistante.3
RobTarget : Un RobTarget est une structure d’enregistrement permettant de définir la position
d’un outil du robot par rapport à un référentiel. La structure comprend la position,
l’orientation, la configuration des articulations et d’autres paramètres de contrôle.
Dans ce projet, seules la position et l’orientation seront utilisées.
Pour plus d’information, voir consulter la page 4 des notes de cours du cours de robot industriel, GPA5464
1
http://www.olf.gouv.qc.ca/ressources/gdt.html
2
Ibid
3
http://www.gpa.etsmtl.ca/cours/gpa546/Notes/Cours03.pdf, page 14
4
http://www.gpa.etsmtl.ca/cours/gpa546/Notes/DocSup2.pdf
iii
TABLE DES MATIÈRES
Page
Introduction ............................................................................................................................... 1
CHAPITRE 1 REVUE DE LA DOCUMENTATION ........................................................... 3
1.1
L’environnement de développement ............................................................................. 3
1.2
La représentation 3D ..................................................................................................... 4
1.2.1
La projection orthogonale ............................................................................... 4
1.2.2
La projection centrale ...................................................................................... 5
1.3
La gestion de matrices ................................................................................................... 6
CHAPITRE 2 MÉTHODOLOGIE DE TRAVAIL ................................................................ 7
2.1
La documentation .......................................................................................................... 7
2.2
La stratégie de développement ...................................................................................... 7
2.3
Les tests préliminaires ................................................................................................... 8
2.4
Les quaternions et les angles d’Euler ............................................................................ 8
2.5
Les référentiels à dessiner ............................................................................................. 9
2.6
Les matrices ................................................................................................................... 9
2.7
L’interaction avec l’opérateur ..................................................................................... 10
CHAPITRE 3 PROCESSUS DE CONCEPTION ................................................................ 11
3.1
La préparation de l’environnement de développement ............................................... 11
3.2
Le développement de classes d’objets......................................................................... 11
3.2.1
Le contrôleur ................................................................................................. 12
3.2.2
La classe CControleur ................................................................................... 12
3.2.3
La classe CRobTarget ................................................................................... 14
3.2.4
La classe CAngleEuler .................................................................................. 14
3.3
Les méthodes de gestion des contrôles visuels ........................................................... 17
3.4
Installation de l’application ......................................................................................... 20
3.4.1
Pour un système virtuel ................................................................................. 20
3.4.2
Pour un vrai contrôleur .................................................................................. 20
CHAPITRE 4 INTERPRÉTATION DES RÉSULTATS ET DISCUSSION ...................... 21
4.1
La représentation 3D ................................................................................................... 21
4.2
La validation des résultats ........................................................................................... 22
4.3
Les résultats manquants............................................................................................... 22
Conclusion et recommandations ............................................................................................. 23
Références ............................................................................................................................... 24
Annexes ................................................................................................................................... 25
iv
INTRODUCTION
Dans le cadre du projet de fin d’études en production automatisée, il est intéressant de
concevoir une application pour la manette de contrôle, appelée « FlexPendant », d’un Robot
ABB. Cette application permettra d’étudier les possibilités de développement des outils
disponibles capable de répondre à différents besoins. Dans le cas présent, l’objectif est de
développer une application capable de gérer l’orientation des « RobTarget » avec la notion des
angles d’Euler.
Des « RobTarget » sont des points de référence du robot dans le jargon des robots ABB.
Présentement, il est très difficile de modifier l’orientation d’un « RobTarget » manuellement
parce que les robots ABB utilisent les quaternions. Le seul moyen disponible pour modifier
l’orientation par le « FlexPendant » est de l’enseigner en mode « Jogging » soit le mode de
déplacement manuel du robot. Pour modifier l’orientation en inscrivant des valeurs à l’aide du
pavé numérique, c’est pratiquement impossible puisque les valeurs d’un quaternion doivent
toujours être normalisées. En plus, il est difficile de se faire une image du résultat d’un
quaternion. Ce n’est vraiment pas intuitif.
Pour remédier à ce problème, il faudrait une application utilisant les angles d’Euler. De cette
façon, il serait très facile d’inscrire directement une valeur d’angle entre 0° et 360° pour chacun
des axes de rotation. De plus, il faudrait avoir dans le même écran, un référentiel représentant
graphiquement l’orientation en cours d’édition. Pour modifier les rotations, il serait fort simple
pour l’opérateur de manier le « joystick » ou d’appuyer sur de simples boutons. En associant
les trois mouvements de rotation aux trois axes du « joystick » en plus de présenter en temps
réel le nouveau référentiel à l’écran, ça deviendrait très intuitif d’enregistrer des orientations de
« RobTarget » bien précise. Il faudrait ajouter la possibilité d’effectuer les rotations par rapport
au référentiel d’origine ou par rapport au nouveau référentiel transformé en tout temps. Pour
que l’application soit plus complète, il serait intéressant de pouvoir gérer et modifier les
informations des « RobTarget » en entier comme la position, le nom et les autres informations
de déclarations. Permettre de créer, supprimer ou copier de nouveau « RobTarget » rendrait
l’application capable de faire pratiquement toute la gestion de ceux-ci.
Le projet sera développé par étapes. Au début, il faut bien sûr apprendre à utiliser les outils,
surtout les nouveaux logiciels dans ce cas-ci. Une fois un peu plus familier avec
l’environnement de développement, il faut créer des fonctions et des procédures pour gérer les
données du contrôleur, gérer une orientation à l’aide de matrices, représenter des référentiels
en trois dimensions et finalement utiliser le tout à l’aide de l’écran tactile du « FlexPendant ». Il
faudra développer des algorithmes pour convertir les quaternions en angles d’Euler et viceversa ainsi que pour récupérer les angles d’Euler d’une matrice d’orientation.
Tout au long de ce rapport, on y retrouvera plusieurs sections concernant le déroulement du
projet. Un résumé des points importants de la documentation consultée tout au long du
développement permettra de comprendre d’où viennent certains concepts et d’en expliquer
leur utilité au projet. Ensuite, il y aura une description de la méthodologie de travail adoptée
pour résoudre la problématique. Suivra l’explication du processus de conception détaillé du
projet. Cette section porte sur les parties développées en parlant des buts à atteindre
initialement pour chaque étape, des méthodes de création et de la solution finalement
implantée. Une interprétation des résultats finaux et une discussion accompagneront le rapport
pour analyser le projet plus en profondeur et valider les objectifs en fonction des résultats. Le
rapport se terminera d’une conclusion afin de faire un retour sur l’ensemble du projet et des
recommandations seront suggérées pour améliorer ou continuer l’application.
2
CHAPITRE 1 REVUE DE LA DOCUMENTATION
1.1 L’environnement de développement
Sur le site Internet de ABB5, on retrouve beaucoup de documentation sur leurs logiciels. Le
document portant sur l’application « Robot Application Builder » est très bien fait. Il contient
une très bonne base pour démarrer une application pour le robot et possède même des
exemples de programmation.
Parmi les points intéressants de la documentation, on retrouve les manœuvres d’installation
de l’environnement de développement. Il faut respecter un ordre d’installation spécifique des
logiciels pour que chacun fonctionne correctement. Il y a une section décrivant comment
démarrer une nouvelle application et la tester dans un « FlexPendant » virtuel. Un des sujets
très utiles de la documentation est l’explication des différents moyens permettant de
déverminer le code d’une application. La façon de démarrer un suivi pas à pas pour tester
notre application est un peu plus longue et plus compliquée qu’une application conventionnelle
puisque l’exécution n’est pas à l’intérieur de l’environnement de développement. Il faut
démarrer l’application par le « FlexPendant » virtuel dans Robot Studio et ensuite lier ce
processus Windows avec l’application par l’environnement de développement Visual Studio.
Il y a aussi plusieurs descriptions des différents contrôles disponibles et des modèles
d’utilisation. Une section spécialement conçue pour aider à développer une application robuste
explique bien les limites de mémoire du contrôleur et donne des conseilles de programmation
pour améliorer la performance.
De plus, un peu de documentation a été consulté dans le but de créer un algorithme pour
convertir des quaternions en angles d’Euler. Cette recherche n’a finalement pas servi puisque
le contrôleur possède déjà toutes les méthodes nécessaires.
5
ABB, http://www.abb.ca/product/seitp327/4a08adf3b8bd7976c12570fc00348b3f.aspx
3
1.2 La représentation 3D
Pour gérer graphique les référentiels dans une application « FlexPendant », il a fallu
beaucoup de recherche pour trouver la possibilité d’y arriver. Il y a plusieurs méthodes en
programmation pour faire de la représentation 3D, mais plusieurs d’entres elles ne semblent
pas être compatibles pour un « FlexPendant » ou du moins, pour l’environnement virtuel. Par
contre, de nombreuses sources offrent des moyens de faire des dessins par projections en
trois dimensions. Un des sites retenus est le site « The code Project »6 qui offre du code
complet pour dessiner et effectuer des rotations dans l’espace. Ce code a plus tard été laissé
de côté puisqu’il ne permet pas une bonne gestion des rotations et de l’affichage des
référentiels. Les raisons seront expliquées davantage un peu plus loin dans ce rapport.
1.2.1
La projection orthogonale
C’est finalement les bases mêmes de la projection orthogonale qui ont été utilisées et
complètement codées à l’aide d’une référence en mathématique « MathWorld »7 et du soutien
du professeur Ilian Bonev. Ce dernier a fourni les équations suivantes prêtes à être codé dans
l’application afin de faire une projection orthogonale :
0 1
0 0
0
1
Les matrices de rotation :
1
0
0 cos 0 sin cos 0
sin cos sin 0
6
http://www.codeproject.com/KB/GDI-plus/Plot3D.aspx
7
http://mathworld.wolfram.com/Plane.html
0
sin cos 0 sin 1
0 0 cos sin cos 0
0
0
1
4
Pour dessiner le référentiel fixe :
!"
Extrémité de l’axe des X : 30° 45° 0
0
0
Extrémité de l’axe des Y : 30° 45° !" 0
0
0
Extrémité de l’axe des Z : 30° 45° !"
Le même principe est utilisé pour le référentiel transformé, mais avec une matrice d’orientation
R de plus et une longueur d’axe différente. Cette matrice est modifiée avec les mêmes
matrices de rotation , % .
!(
Extrémité de l’axe des X : 30° 45° ' 0
0
0
Extrémité de l’axe des Y : 30° 45° ' !( 0
0
0
Extrémité de l’axe des Z : 30° 45° ' !(
1.2.2
La projection centrale
On n’est pas vraiment habitué à voir des systèmes d’axes avec une projection orthogonale à
l’écran. On voit plus souvent des représentations 3D par une projection centrale. Cette
projection a été développée pour ainsi donner le choix à l’opérateur de la projection qu’il désire.
Les équations se trouvent facilement à l’aide d’un graphique comme la figure suivante.
+
· sin ,
· cos Y
*
X
Figure 1 Calculs de projection centrale
5
Donc, les équations pour obtenir les coordonnées (x, y) dans l’écran pour un point 3D (x, y,
z) sont les suivantes :
é./01 23 23 cos é./01 23 23 sin Les équations semblent beaucoup plus complexes dans le code du projet, mais c’est
l’ajustement de l’écran par rapport à l’origine qui augmente légèrement l’équation. Il y a aussi
des facteurs de profondeur qui ont été ajoutés pour donner une certaine perspective de
profondeur. Voici donc les deux types de représentations disponibles dans l’application.
Projection orthogonale
Projection centrale
Z
Z
Y
X
Y
X
Figure 2 Deux types de projection
1.3 La gestion de matrices
Puisque l’application est basée sur des manipulations d’orientation de point, la notion de
matrice est très utile. Malheureusement, aucune librairie de gestion de matrice n’est fournie par
le langage VB.net. Pour pallier ce manque, plusieurs sources de code sont disponibles sur
Internet et la classe « Matrice » offerte sur le site de « Codes-Source »8 a été intégrée au
projet.
Pour créer les matrices de rotations et obtenir les angles d’Euler d’une matrice d’orientation, il
faillait programmer les algorithmes nécessaires. Initialement, les définitions des matrices ont
8
http://www.csharpfr.com/code.aspx?ID=34171
6
été faites à l’aide de sources Internet comme le site non officiel, mais très complet sur le sujet,
« EuclideanSpace »9 réalisé par monsieur Martin John Baker.
Ce site contient beaucoup
d’information sur les quaternions, les angles d’Euler, les matrices et contient même du code
pour programmer et gérer les méthodes expliquées informatiquement. Par contre, on peut se
rendre compte que ce site n’est pas une référence très fiable et une validation des principes
est nécessaire. Heureusement qu’une vérification a été faite puisque la procédure pour obtenir
les trois angles d’Euler à partir d’une matrice d’orientation ne semble pas fonctionner. C’est
l’événement qui a donné l’idée de réutiliser les fonctions offertes pour la calculatrice graphique
dans le cadre du cours de robots industriels, GPA546. L’utilitaire est disponible sur le site du
cours10 et il ne reste plus qu’à adapter le code des fonctions dans le code du projet VB.net.
CHAPITRE 2 MÉTHODOLOGIE DE TRAVAIL
2.1 La documentation
Tout d’abord, la première étape est bien sûr la lecture de documentation. Il faut comprendre
l’environnement de développement et apprendre comment démarrer un projet. Le guide portant
sur l’application « Robot Application Builder » est très bien fait et possède toutes les bases
nécessaires à la création du projet. Par exemple, l’installation des logiciels nécessaires et les
configurations requises sont bien expliquées. La création d’un nouveau projet est décrite étape
par étape et plusieurs méthodes sont possibles pour tester et déverminer l’application. Il est
très facile d’explorer le comportement de l’application sur un « FlexPendant » virtuel avec le
logiciel « Robot Studio ».
2.2 La stratégie de développement
Avant de se lancer directement dans le code de l’application finale, le plus simple est de
fractionner les objectifs du projet en plusieurs parties. De cette façon, plusieurs miniapplications sont créées pour les tester efficacement individuellement et ensuite les intégrer au
projet global avec une meilleure structure.
9
http://www.euclideanspace.com/maths/geometry/rotations/conversions/matrixToEuler/index.htm
10
GPA546, http://www.gpa.etsmtl.ca/cours/gpa546/index.htm
7
2.3 Les tests préliminaires
La première étape de programmation est de maitriser les contrôles graphiques et la librairie
du contrôleur de robot. Pour ce faire, l’objectif est de recueillir et afficher tous les
« RobTarget » dans une liste. Cette partie est la plus simple, mais donne un bon point de
départ pour se familiariser avec le langage de programmation VB.net, l’environnement de
développement Visual Studio et l’environnement de test Robot Studio. Selon les méthodes
d’obtention des données dans le contrôleur, il est probablement plus pratique de créer des
classes contenant toutes les données membres et les méthodes nécessaires. Une meilleure
structure des données simplifie et clarifie le code par la suite.
2.4 Les quaternions et les angles d’Euler
Puisque les robots ABB utilisent les quaternions pour définir les orientations, le plus simple
est de la convertir en angles d’Euler pour faciliter les traitements. La définition des quaternions
par Techno-Sciences.net est la suivante : « Les quaternions, notés
, sont un type de
nombres hypercomplexes, constituant une extension des nombres complexes, extension
similaire à celle qui avait conduit des nombres réels aux nombres complexes. »11. On peut le
représenter sous la forme linéaire d’une somme de parties réelles et imaginaires comme
l’équation suivante :
4 5·167·869·:6;·<
Un quaternion est un vecteur unitaire de quatre valeurs (q1, q2, q3, q4) comprises entre -1 et
1. Étant unitaire, la racine carrée de la somme des carrées est toujours égale à 1 :
=>" ( 6 >( ( 6 >2 ( 6 >? ( 1
Il est beaucoup plus simple de travailler avec les angles d’Euler et une méthode simple de les
obtenir est de passer par la matrice de rotation. Voici comment on peut construire cette
matrice :
11
5( 6 7 ( 9 ( ; (
2 · 5 · ; 6 2 · 7 · 9
2·7·;2·5·9
2·7·92·5·;
5( 7 ( 6 9 ( ; (
2·5·762·9·;
2·5·962·7·;
2 · 9 · ; 2 · 5 · 7
5( 7 ( 9 ( 6 ; (
http://www.techno-science.net/?onglet=glossaire&definition=5067
8
L’ensemble des fonctions permettant de convertir les quaternions et les angles d’Euler sont
des algorithmes assez complexes. Heureusement, le contrôleur du robot possède déjà les
outils pour effectuer les conversions. Le type de données « Orient » qui est le type pour
l’orientation possède la méthode « ToEulerAngles » pour convertir les quaternions en angles
d’Euler et pour faire l’inverse, il suffit d’utiliser la méthode « FillFromEulerAngles ».
2.5 Les référentiels à dessiner
Dessiner les référentiels est la section qui est sans aucun doute la plus complexe et la plus
longue de toutes. Pour représenter l’orientation des « RobTarget » graphiquement, il faut
commencer par analyser le code téléchargé à partir du site « The code Project »12. Il est
important de s’assurer que ce code source permet de faire des référentiels à l’écran dans une
orientation fournie. Puisque ce code est développé en langage C-Sharp.Net, il faudra soit le
convertir en VB.Net ou le jumeler en tant que deuxième projet dans « Visual Studio ». Il est
certain qu’il faudra personnaliser les classes de code, car elles sont conçues pour dessiner des
cubes et les faire pivoter par rapport à différentes références. Dans le cadre du projet, il faut
définir les trois axes des référentiels pour qu’ils deviennent les axes de rotation. Les seuls
paramètres envoyés pour dessiner les référentiels devraient être des angles ou une matrice
d’orientation. Ici, il y aura peut-être des problèmes concernant la gestion de mémoire comme le
prévoit le guide de l’application « Robot Application Builder ».
2.6 Les matrices
Par la suite, on peut programmer les matrices de rotations ainsi que leurs fonctions de
gestion. Cela est pour permettre de changer l’orientation du référentiel par des calculs
matriciels. Les rotations peuvent se faire par rapport à deux systèmes d’axes. Il faut ajouter un
paramètre indiquant le référentiel à utiliser pour pouvoir effectuer des rotations en fonction du
référentiel fixe ou du référentiel transformé. Cela affecte seulement l’ordre de multiplication des
matrices. Le plus compliqué est d’obtenir les angles d’Euler à partir d’une matrice résultante
12
http://www.codeproject.com/KB/GDI-plus/Plot3D.aspx
9
puisqu’il existe toujours au moins deux réponses possibles. Les cas de singularités quant à eux
possèdent une infinité de réponses qui faut tenir compte dans l’algorithme.
2.7 L’interaction avec l’opérateur
Ensuite, c’est surtout de la gestion de l’interaction avec l’opérateur qu’il faut faire. Comme
rendre le « joystick » responsable de faire les rotations selon la direction des mouvements. Il
suffit de lier chacun de ses axes à un axe de rotation du référentiel. Lorsque le « joystick » est
poussé vers la droite, c’est une rotation en X dans le sens positif qui se fait. Pour un
mouvement vers le haut, c’est une rotation en Y dans le sens positif et pour un mouvement de
rotation du « joystick » dans le sens horaire, c’est une rotation selon l’axe Z dans le sens
positif. Si par incapacité ou par manque de temps la gestion du « joystick » n’est pas possible,
les rotations pourront être faites par de simples boutons à l’écran.
Finalement, il reste à rendre le tout fonctionnel et fiable. Il devrait y avoir deux fenêtres, une
pour la liste des points et une autre pour modifier l’orientation. Il ne faut pas seulement modifier
l’orientation des « RobTarget », mais aussi sauvegarder les modifications dans le contrôleur. Si
le temps le permet, il faudrait rendre l’application robuste pouvant gérer tout ou presque tous
les cas d’exceptions d’opération normale.
10
CHAPITRE 3 PROCESSUS DE CONCEPTION
3.1 La préparation de l’environnement de développement
La première étape après avoir fait la recherche et lu sur le sujet est d’installer et organiser
tout le nécessaire pour la conception. Afin de concevoir une application pour le
« FlexPendant », il faut respectivement installer les logiciels « Robot Studio » qui contient le
contrôleur et le « FlexPendant » virtuel, « Visual Studio » qui est l’environnement de
programmation et « Robot Application Builder ». Il est très important que « Robot Application
Builder » soit le dernier à être installé pour que les deux autres héritent des librairies de
programmation du contrôleur de robot. Pour ce projet, le langage de programmation choisi est
du VB.Net, mais cette décision est tout à fait arbitraire.
Au départ, il faut se familiariser avec l’environnement de développement et le meilleur moyen
est d’expérimenter les exemples offerts dans la documentation pour créer un nouveau projet.
En créant une application tout à fait bidon, ça permet d’explorer les possibilités de
programmations et de faire l’essai de différents contrôles graphiques qui seront utilisés plus
tard pour le vrai projet. Les sections importantes à parcourir sont l’affichage de liste avec
plusieurs colonnes pour afficher plusieurs informations, la gestion d’une application à plusieurs
écrans et surtout la capacité d’explorer les données du contrôleur comme les « RobTarget ».
3.2 Le développement de classes d’objets
Une fois les tests préliminaires faits, il est temps de démarrer le vrai projet. Malgré le fait que
ce ne soit pas un travail de fin d’études en génie de la production automatisée et non pas en
génie logiciel, la programmation est réalisée dans le but d’avoir un code le mieux structuré
possible respectant les normes apprises tout au long des études. C’est pour cette raison que la
conception de classes13 orientées objets a été réalisée. Pour le projet, les deux objets
principaux sont le contrôleur et les « RobTarget » qui sont deux classes importantes. Ces deux
classes permettent d’englober toutes leurs méthodes et leurs données membres nécessaires.
13
Voir définition au début du document.
11
3.2.1
Le contrôleur
Le contrôleur est l’objet qui représente le robot. Lorsqu’on veut communiquer avec le robot,
c’est à partir du contrôleur qu’il faut le faire. Il possède les programmes, les variables dont les
« RobTarget » font partie et les procédures nécessaires pour bouger. Voici un petit schéma
pouvant aider à se le représenter :
Figure 3 Schéma de l’objet « Controller »
On peut donc voir que pour accéder à une variable « RobTarget » qui fait parti des
« RapidData », il faut passer par la « Task » et le « Module ».
3.2.2
La classe CControleur
La classe principale nommée CControleur, dont son schéma UML est illustré dans la figure 5
de la page suivante, possède une instance du contrôleur du robot et une liste de tous les
« RobTarget ». Il y a donc une méthode pour récupérer tous les « RobTarget » de toutes les
« Task »
et
de
tous
les
modules
du
contrôleur.
La
méthode
s’appelle
« ObtenirListeRobTarget » et peut être consultée dans l’annexe A. Par contre, les
« RobTarget » de type constante ne sont pas récupérés, seulement les persistants et les
variables puisqu’il n’est pas possible de modifier une constante. Cette classe contient aussi
12
d’autres utilitaires dont la méthode « RobTargetSelonNom » présente dans l’annexe B qui
permet d’obtenir l’instance d’un objet « RobTarget » en spécifiant son nom. Il faut bien sûr que
la variable existe et qu’elle soit de type « RobTarget » sinon la méthode retourne un message
d’erreur qui sera affiché à l’opérateur. Il y a finalement une dernière méthode dans cette
classe, « RemplirListView » présente en annexe C, qui permet de remplir une liste avec
plusieurs colonnes de tous les « RobTarget » du contrôleur. Dans le schéma UML, on peut voir
ces trois méthodes énoncées précédemment plus son constructeur « New » qui permet de
créer l’objet « CControleur » et d’initialiser toutes données membres. Il n’y a que deux données
membres avec chacune leur propriété respective. Une pour l’instance du contrôleur du robot et
une liste de « CRobTarget » qui est défini dans la section qui suit.
Figure 4 Classe CControleur
Figure 6 Classe CRobTarget
Figure 5 Classe CAngleEuler
13
3.2.3
La classe CRobTarget
La classe « CRobTarget » est une classe personnalisée très proche de la classe
« RobTarget » qui existe déjà. La nécessité de créer cette nouvelle classe permet d’ajouter et
de regrouper de l’information qui n’est pas directement atteignable par la classe de base. Par
exemple, la classe « RobTarget » ne possède aucune propriété faisant référence à l’objet
« Task » pour lequel il appartient, ou le module. Ce sont deux informations importantes
puisqu’ils sont nécessaires lorsqu’on veut obtenir l’instance d’un « RobTarget » à l’aide de la
méthode « GetRapidData(<Nom_Tache>, <Nom_Module>, <Nom_Variable>) » pour ensuite lire
leurs informations. Donc cette classe possède des données membres avec leur propriété
associée pour le nom de module, le nom de la « Task », le nom du « RobTarget » lui-même et
l’instance de l’objet « RobTarget » pour toutes les autres informations comme sa position et
son orientation. La classe implémente aussi l’interface « IComparable » qui permet d’ajouter
une méthode de comparaison entre deux instances « CRobTarget ». La comparaison est
basée sur le nom du « RobTarget » pour permettre de les trier en ordre alphabétique dans une
liste.
3.2.4
La classe CAngleEuler
La classe qui a demandé le plus de temps de développement a été la classe
« CAngleEuler ». Celle-ci permet de gérer l’orientation d’un « RobTarget », les rotations et
d’afficher graphiquement les référentiels. Afin d’accélérer la conception et de réduire l’ampleur
du projet, l’idée initiale était d’utiliser du code déjà tout fait pour faire les dessins de projection
en 3D à l’écran et pour gérer des matrices. Finalement, seul l’usage d’une classe pour les
matrices a été retenu puisqu’elle répond exactement aux besoins. La classe « Matrice »14 a été
compilée et ajoutée directement aux références du projet puisqu’il n’y avait aucune
modification à faire. Cette classe permet de créer un objet « Matrice » en spécifiant le nombre
de lignes et de colonnes désirées. On peut aussi lui assigner des valeurs très facilement
comme avec des tableaux. La classe possède toutes les méthodes nécessaires, dont les
opérateurs de multiplication de matrices qui est fort utile pour les rotations.
14
http://www.csharpfr.com/code.aspx?ID=34171
14
Par contre, l’ensemble de classes de dessin initialement trouvé sur le site « The code
Project »15 et modifié pour s’adapter au projet a été laissé de côté. La base de l’orientation des
référentiels demandait en paramètre de recevoir trois angles de rotation, les situations de
singularité ne pouvaient donc pas être gérées convenablement. En fait, chaque fois que l’angle
de rotation autour de l’axe des Y donnait ±90º, il y avait une infinité de possibilités avec l’axe X
et Z pour afficher le référentiel. On peut observer la cause de cette lacune en analysant
l’algorithme de la procédure « GetAngles » en annexe D. Pourtant, une seule représentation
est censée exister. C’est pourquoi les méthodes de dessin ont complètement été développées
dans la classe « CAngleEuler ».
Pour revenir plus particulièrement au contenu de la classe « CAngleEuler » qui englobe la
plus part des méthodes de calculs, elle possède toutes les méthodes qui gèrent les rotations.
Elle a plusieurs données membres dont une pour la matrice d’orientation du référentiel
transformé, trois autres pour retenir les trois angles d’Euler équivalent, une pour savoir si les
rotations se fond par rapport au référentiel original ou par rapport au nouveau et une dernière
donnée membre qui fait directement référence à la fenêtre sur laquelle les référentiels sont
dessinés. Il y a ensuite trois méthodes qui retournent une matrice de rotation selon l’angle
fournie. Il aurait été possible de faire seulement une méthode capable de retourner la matrice
de rotation pour les trois axes ensemble, mais c’est plus simple et plus clair d’en avoir une par
axe. Une autre méthode effectue la rotation en multipliant la matrice d’orientation courante
avec la matrice de rotation spécifiée. Selon le référentiel sur lequel la rotation doit se faire,
l’ordre de multiplication est ajusté. La méthode « GetAngles » retourne les trois angles d’Euler
de la matrice d’orientation. L’algorithme est tiré de la fonction fournie sur le site du cours de
GPA546 pour la calculatrice graphique Voyage200. L’algorithme a été légèrement adapté pour
éviter les doubles solutions avec un calcul de différence entre l’orientation précédente et la
nouvelle pour conserver le résultat le plus proche. Ce n’est pas vraiment un calcul nécessaire,
mais cette approche est surtout pour éviter de grand changement d’angles à chaque rotation.
15
http://www.codeproject.com/KB/GDI-plus/Plot3D.aspx
15
D’autres méthodes servent à afficher le référentiel d’origine et celui orienté à l’aide
d’équations de projection. Il y deux méthodes puisqu’il est possible de choisir le type de
projection désiré. Soit la projection orthogonale et centrale.
Au départ, cette classe devait aussi avoir une méthode pour convertir les quaternions en
angles d’Euler, mais finalement le contrôleur du robot possède déjà la méthode nommée
« ToEulerAngles » pour l’orientation en quaternions d’un « RobTarget » qui est de type
« Orient ». L’inverse existe aussi avec la méthode « FillFromEulerAngles » pour enregistrer la
nouvelle rotation.
L’enregistrement d’une variable dans le contrôleur semble une tâche simple, mais plusieurs
étapes sont nécessaires. Premièrement, il faut créer une nouvelle instance de « RobTarget » à
partir de celui déjà existant afin d’avoir la même base d’informations. Ensuite, il faut modifier ce
nouveau
« RobTarget »
par
les
nouvelles
données
avec
des
méthodes
comme
« FillFromString » et « FillFromEulerAngles ». Jusqu’ici, aucune donnée n’a été changée dans
le contrôleur. Afin que les données soient modifiées dans le contrôleur, il faut absolument
affecter la propriété « Value » du RapidData avec le nouveau « RobTarget ». Sans cette étape,
il n’est pas possible de modifier directement une valeur dans le contrôleur. On peut voir la
méthode de sauvegarde dans la figure suivante.
Figure 7 Méthode Sauvegarder
16
3.3 Les méthodes de gestion des contrôles visuels
Le reste de la conception vise à rendre l’application opérationnelle. Tout le corps du
traitement est dans les classes présentées jusqu’ici et le restant fait l’appel à ces méthodes par
des contrôles dans les fenêtres de l’écran. La première fenêtre, qu’on peut voir dans la figure
8, est la fenêtre de démarrage de l’application. Elle liste tous les « RobTarget » du contrôleur
du robot en ordre alphabétique et permet d’en sélectionner un pour le modifier. Pour ouvrir la
fenêtre d’édition d’un « RobTarget », il faut soit double cliquer sur celui-ci ou cliquer sur
« Modifier la valeur » dans le menu du bas. Le bouton « Mettre à jour » permet seulement de
recharger la liste avec les données actuelles. La liste possède trois colonnes, la première pour
afficher le nom de variable du « RobTarget », la deuxième pour afficher les valeurs de position
et d’orientation en angles d’Euler et la dernière colonne pour afficher le module
d’appartenance.
Figure 8 Fenêtre principale de l'application
La fenêtre d’édition de la figure 9, possède tous les contrôles nécessaires pour modifier la
position du « RobTarget » ou son orientation. Pour modifier l’orientation, six boutons permettre
de changer séparément l’orientation par rapport à l’axe des X, Y ou Z selon le référentiel choisi
par les options Xr, Yr, Zr ou Xt, Yt, Zt. Une barre de défilement permet de choisir le pas
d’incrémentation en degré pour chaque clique de rotation entre 1º et 45 º. Si les boutons de
rotation sont maintenus, la rotation est continue et la vitesse de rotation augmente jusqu'à un
17
certain maximum. Le maintien d’un bouton de rotation ne modifie pas la valeur
d’incrémentation de la barre de défilement. Bien sûr, l’affichage des angles d’Euler et les
référentiels à droite de la fenêtre sont constamment mis à jour après chaque modification. Le
bouton « Réinitialiser » permet de ramener les valeurs du « RobTarget » aux dernières
données sauvegardées. Le bouton « Enregistrer » permet d’enregistrer les valeurs
actuellement visibles à l’écran dans le contrôleur. Le bouton « Ok » permet de quitter la fenêtre
d’édition après avoir sauvegardé les nouvelles données dans le contrôleur pour retourner à la
fenêtre initiale puis réafficher la liste des « RobTarget » qui sont toutes mises à jour. Le bouton
« Annuler » fait exactement la même chose que le bouton « Ok » à l’exception qu’il ne fait
aucune sauvegarde de données.
Figure 9 Fenêtre d'édition
18
Le bouton « Projection » permet de choisir le type de projection des référentiels comme le
démontre la figure 10. Les choix sont bien entendu les mêmes que vue dans la classe
« CAngleEuler » soit une projection orthogonale et centrale. La figure 9 montre une projection
centrale tandis que celle-ci montre une projection orthogonale.
Figure 10 Fenêtre d'édition avec représentation orthogonale
En cliquant dans l’une des boîtes d’éditions de la position X, Y, Z ou EX, EY, EZ, un clavier
numérique apparaît et tous les autres contrôles deviennent inaccessibles, comme le démontre
la figure 11.
19
Figure 11 Clavier numérique
3.4 Installation de l’application
3.4.1
Pour un système virtuel
Pour installer l’application sur un « FlexPendant » virtuel, il suffit de copier les fichiers
assemblés de l’application dans le dossier « Home » du projet « Robot Studio ». Ce dossier se
trouve
par
défaut
dans
l’arborescence
de
dossiers
suivant :
« \Mes
documents\RobotStudio\Systems\<NOM_DU_PROJET_ROBOT_STUDIO>\HOME ». Dans ce
cas-ci, les fichiers à copier se nomment « TpsViewRobTargetAvecAngleEuler.gtpu.dll » et
« TpsViewRobTargetAvecAngleEuler.dll » plus le fichier contenant les fonctions des matrices
« Maths.dll ». Il faut absolument redémarrer le « FlexPendant » pour que ça fonctionne. Il faut
absolument que « Robot Ware » soit installé sur le système pour que ça fonctionne. S’il y a des
problèmes, il est possible qu’il manque des fichiers de références dans le dossier système de
« Robot Studio ». On peut donc copier tous les « .dll » qui sont dans le dossier de compilation
du projet « Visual Studio » (ce dossier peut être soit « …\Bin\Debug\ » ou « …\Bin\Release\ »)
vers le dossier source qui
est par défaut « C:\Program Files\ABB Industrial IT\Robotics
IT\RobotStudio 5.12\Bin » selon la version du logiciel ».
3.4.2
Pour un vrai contrôleur
Pour installer l’application sur un vrai « FlexPendant », il faut copier les mêmes fichiers que
sur le virtuel, mais l’endroit de destination est différent. Il faut télécharger les fichiers « .dll »
dans le dossier « System » ou « Home » du contrôleur. Il est préférable de les mettre dans le
dossier « Home » puisqu’ils feront partie des éléments de sauvegarde. La méthode la plus
simple pour transférer les fichiers est par la commande « File Transfer » du menu « Online »
de « Robot Studio ». Pour avoir plus d’informations ou connaitre d’autre méthode de transfert,
le manuel16 de « Robot Application Builder » possède une section entière sur l’installation d’une
application dans la section « Run-time environnement».
16
http://www05.abb.com/global/scot/scot352.nsf/veritydisplay/e44ab257b45db7ccc125766d003a46db/$File/
3HAC028083-001_RevD_en.pdf
20
CHAPITRE 4 INTERPRÉTATION DES RÉSULTATS ET DISCUSSION
La grande problématique du projet se situe à la gestion des angles et des rotations. Le
problème de conversion de quaternions vers les angles d’Euler et vis versa à finalement
disparue lorsque les méthodes fournit par le contrôleur ont été trouvées.
4.1 La représentation 3D
L’affichage de référentiel en trois dimensions n’a pas été aussi simple. D’abord, ça a
nécessité une longue recherche avant de trouver un ensemble de classes fournissant les
utilitaires pouvant faire le travail. Plusieurs solutions existent pour faire de la représentation
dans l’espace, mais les possibilités du « FlexPendant » semblent assez limitées. La plus part
des codes sources trouvés utilisent le « DirectX » qui exécute du traitement par une carte
graphique. Ça fonctionne bien pour les ordinateurs, mais les librairies du contrôleur de robot
pour le « FlexPendant » ne semblent pas aussi développées et ne prennent pas en compte ce
genre de méthode. C’est pour cela qu’une solution basée sur la librairie « Drawing » a été
utilisée. C’est une librairie bien simple qui est capable de tracer des lignes ou des points sur un
système cartésien (x;y) pratiquement identique à celle de la librairie Windows, mais un peu
plus restreint. C’est une solution beaucoup plus limitée, mais ça permet quand même d’obtenir
des résultats d’affichage respectable. C’est certain qu’il manque l’effet de réel 3D qui
permettrait à coup sûr de comprendre l’orientation du référentiel. Quelques fois, selon
l’orientation, il faut analyser correctement le dessin pour comprendre l’orientation des axes. La
troisième dimension n’est pas toujours évidente et il faut parfois regarder l’ordre des axes pour
savoir si l’axe se dirige en profondeur de l’écran ou sort de l’écran. Le fait d’avoir un choix de
projection peut aider dans ce sens.
De plus, la représentation d’un référentiel selon l’orientation demandée n’a vraiment pas été
une chose simple. Certaines classes de dessin qui ont été téléchargées ont dû subir une
grande adaptation de code pour répondre aux objectifs précis du projet. Par contre, après
discussion avec le superviseur de projet, les classes ont dû être abandonnées parce que
l’orientation dans l’espace était basée sur trois angles. Ce qui provoque de nombreuses
complications de représentation en situation de singularités. Ce problème n’a aucune raison
d’exister dans le dessin puisque la matrice d’orientation possède toute l’information nécessaire
à l’unique représentation. C’est pourquoi les méthodes de dessins ont complètement été
refaites à l’aide des équations de projection 3D sur un écran 2D.
21
4.2 La validation des résultats
Pour valider les angles en fonction de la représentation du référentiel, il y a eu des séances
d’analyse de rotation pas à pas avec le logiciel « RobotStutio ». La méthode était simple, mais
assez longue. Le but était de faire des rotations avec l’application créée et d’observer la
rotation du référentiel. Ensuite, aller en mode « Jogging » du robot pour atteindre la nouvelle
orientation du point. On peut donc comparer les vues des référentiels pour s’assurer que
l’orientation est la même comme à la figure 12. Pour que le résultat soit bon, il faut aussi que
les valeurs affichées en angle d’Euler soient les mêmes que le logiciel « RobotStudio » l’affiche
dans son mode « Jogging ». Tous les types de rotation ont été testés selon le référentiel
d’origine et le nouveau référentiel transformé.
Figure 12 Validation des résultats
4.3 Les résultats manquants
Par manque de temps, l’application ne gère pas beaucoup des cas d’exception. La plupart
des méthodes du contrôleur devraient avoir une validation, car plusieurs problèmes peuvent
survenir. Par exemple, des « RobTarget » peuvent être modifiés ou simplement effacés
pendant que l’application roule et la sauvegarde ne fonctionnera pas. Il y aurait surement
d’autres validations du genre à faire selon l’état du contrôleur.
Tout le projet à été testé dans un environnement virtuel du « Robot Studio ». La contrainte de
temps n’a pas permis d’explorer les possibilités sur un contrôleur réel, l’application a déjà
fonctionné sur une « FlexPendant » réel. On peut malheureusement voir que l’application n’a
pas été optimisée pour fonctionner dans un environnement réel puisqu’un message d’erreur
spécifiant une erreur de mémoire se manifeste assez rapidement.
22
CONCLUSION ET RECOMMANDATIONS
Ce projet vise à modifier l’orientation de « RobTarget » d’un robot ABB à l’aide de soutien
visuel pour simplifier la représentation. L’application est développée en langage VB.Net pour
s’intégrer au système du « FlexPendant ». Il faut gérer l’orientation avec des angles d’Euler
plutôt que des quaternions comme le suggèrent présentement les applications présentes dans
le système. L’application s’intègre avec les autres programmes déjà existants du robot afin de
pouvoir être lancée lorsque l’opérateur le désire. Cet utilitaire permet à l’opérateur de
sélectionner un « RobTarget » et de modifier sa position manuellement à l’aide du clavier
numérique ou de modifier l’orientation axe par axe à l’aide de boutons. Le soutien visuel est un
ensemble de deux référentiels, un pour l’origine et l’autre pour l’orientation du « RobTarget ».
Ces référentiels sont dessinés à l’aide de simples lignes voulant représenter l’effet trois
dimensions selon une projection orthogonale ou centrale. La représentation graphique serait
un des points à améliorer de l’application. Si le réel effet 3D est possible comme il était
question dans l’hypothèse initiale, il faudrait plutôt l’utiliser puisque de simples lignes donnent
un effet visuel souvent difficile à comprendre.
Le développement s’est fait en suivant le plus possible les normes de programmation
apprises tout au long du cheminement collégial et universitaire. C’est pourquoi plusieurs
classes ont été développées pour regrouper les méthodes et les données membres
nécessaires. D’autres classes ont été jointes au projet pour répondre à différents besoins
comme la gestion de matrices.
L’application avait initialement été pensée pour gérer les rotations de chaque axe à l’aide du
« joystick ». Par manque de temps, le contrôle a plutôt été fait par de simples boutons, mais
peut facilement être adapté si les méthodes de gestion du « joystick » sont découvertes plus
tard.
Pour terminer, le projet semblait assez simple au début, mais tout au long du développement,
la complexité devenait de plus en plus intense. Un des buts du projet était d’évaluer les
possibilités de développement des outils. On peut donc voir que les possibilités sont assez
grandes. Il reste aussi à voir si les mêmes tests faits sur un contrôleur virtuel fonctionnent bien
sur un contrôleur de robot réel. Il y a vraisemblablement les problèmes de mémoire, qui
faudrait gérer pour permettre de fonctionner sans erreur.
23
RÉFÉRENCES
ABB. « ROBOT APPLICATION BUILDER OVERWIEW ». IN LE SITE DE LA
DOCUMENTATION ABB. EN LIGNE.
<HTTP://WWW.ABB.CA/PRODUCT/SEITP327/4A08ADF3B8BD7976C12570FC00348B3F.A
SPX>. CONSULTÉ LE 24 JANVIER 2010.
CODES-SOURCES. 2005. « CLASSE MATRICE ». IN LE SITE DE CODES-SOURCES. EN
LIGNE. <HTTP://WWW.CSHARPFR.COM/CODE.ASPX?ID=34171>. CONSULTÉ LE 15
FÉVRIER 2010.
ÉCOLE DE TECHNOLOGIE SUPÉRIEURE. SITES DE COURS. « GPA546 ». IN LE SITE DU
COURS DE ROBOTS INDUSTRIELS. EN LIGNE.
<HTTP://WWW.GPA.ETSMTL.CA/COURS/GPA546/INDEX.HTML>. CONSULTÉ LE 27
FÉVRIER 2010.
TECHNO-SCIENCE.NET. QUATERNION. IN LE SITE DE TECHNO-SCIENCE.NET. EN
LIGNE. <HTTP://WWW.TECHNOSCIENCE.NET/?ONGLET=GLOSSAIRE&DEFINITION=5067>. CONSULTÉ LE 8 AVRIL
2010.
THE CODE PROJECT. 2006. « A 3D PLOTTING LIBRARY IN C# ». IN LE SITE THE CODE
PROJECT. EN LIGNE. <HTTP://WWW.CODEPROJECT.COM/KB/GDIPLUS/PLOT3D.ASPX>. CONSULTÉ LE 3 MARS 2010.
WOLFRAM MATHWORLD. « PLANE ». IN LE SITE DE WOLFRAM MATHWORLD. EN
LIGNE. <HTTP://MATHWORLD.WOLFRAM.COM/PLANE.HTML>. CONSULTÉ LE 31 MARS
2010.
24
ANNEXES
ANNEXE A ObtenirListeRobTarget
''' <summary>
''' Obtenir la liste de tous les RobTarget du controleur
''' </summary>
Public Sub ObtenirListeRobTarget()
Dim
Dim
Dim
Dim
Dim
Dim
Tache As Task
SProp As RapidSymbolSearchProperties
ListRapidSymbol As RapidSymbol()
RpdSbl As RapidSymbol
RpdTgt As RobTarget
LeRobTarget As CRobTarget
'La tâche
'Options de recherche de RapidData
'Liste des RapidData trouvé
'
'Un RobTarget
'Le RobTarget à ajouter à la liste
'Définir les options de recherche pour récupérer tous les RobTarget
SProp = RapidSymbolSearchProperties.CreateDefault()
SProp.IsInUse = False
SProp.SymbolType = SymbolTypes.RapidData
'Supprimer la liste des RobTarget
m_ListRobTarget.Clear()
'Parcourir tous les tâches du contrôleur
For Each Tache In m_Controleur.Rapid.GetTasks
'Récupérer tous les RobTarget de la tâche reçue en paramêtre
ListRapidSymbol = Tache.SearchRapidSymbol(SProp, "robtarget", String.Empty)
'Parcourir tous les RobTarget obtenus
For Each RpdSbl In ListRapidSymbol
'Obtenir les valeurs de positionnement du RobTarget courant
'Scope(1): C'est le nom du module
RpdTgt = RobTargetSelonNom(RpdSbl.Name, Tache.Name, RpdSbl.Scope(1))
LeRobTarget = New CRobTarget(RpdSbl.Name, Tache.Name, RpdSbl.Scope(1),
RpdTgt)
m_ListRobTarget.Add(LeRobTarget)
Next
Next
'Libérer les variables
Tache = Nothing
RpdSbl = Nothing
RpdTgt = Nothing
SProp = Nothing
LeRobTarget = Nothing
ListRapidSymbol = Nothing
End Sub
25
ANNEXE B RobTargetSelonNom
''' <summary>
''' Retourner un RobTarget selon le nom, la tache et le module reçus en paramètre
''' </summary>
''' <param name="NomRobTarget">Nom du RobTarget</param>
''' <param name="NomTache">Nom de la "task"</param>
''' <param name="NomModule">Nom du module</param>
Public Function RobTargetSelonNom(ByVal NomRobTarget As String, ByVal NomTache As
String, ByVal NomModule As String) As RobTarget
Dim RpdData As RapidData
Dim IRpdData As IRapidData
Dim RpdTgt As RobTarget
'Obtenir les valeurs de positionnement du RobTarget courant
RpdData = m_Controleur.Rapid.GetRapidData(NomTache, NomModule, NomRobTarget)
IRpdData = RpdData.Value
RpdTgt = DirectCast(IRpdData, RobTarget)
Return RpdTgt
End Function
26
ANNEXE C RemplirListView
'Remplir une ListView dont la référence est reçue en paramètre de tous les points du
contrôleur
Public Sub RemplirListView(ByRef List As ListView)
Dim
Dim
Dim
Dim
Dim
RpdRbt As CRobTarget
LstAdd As ListViewItem
Yaw As Double
Pitch As Double
Roll As Double
'Point courant (RobTarget courant)
'Ligne à ajouter dans la ListView
'Rotation autour de l'axe des X
'Rotation autour de l'axe des Y
'Rotation autour de l'axe des Z
'Obtenir tous les RobTarget du contrôleur
ObtenirListeRobTarget()
'Vider la liste
List.Items.Clear()
m_ListRobTarget.Sort()
'Parcourir tous les RobTarget et les ajouter à la ListView
For Each RpdRbt In m_ListRobTarget
'Créer une nouvelle ligne
LstAdd = New ListViewItem(RpdRbt.Nom)
'Obtenir les angles d'Euler du RobTarget
RpdRbt.LeRobTarget.Rot.ToEulerAngles(Yaw, Pitch, Roll)
'Ajouter les informations du point courant dans la nouvelle ligne
LstAdd.SubItems.Add(RpdRbt.LeRobTarget.Trans.ToString() & "[" &
Math.Round(Yaw, 2).ToString() & ", " & Math.Round(Pitch, 2).ToString() & ", " &
Math.Round(Roll, 2).ToString() & "]")
LstAdd.SubItems.Add(RpdRbt.LeModule)
'Ajouter la ligne à la liste
List.Items.Add(LstAdd)
Next
End Sub
27
ANNEXE D GetAngles
'Retourner les angles d'Euler de la matrice reçue en paramètre.
'La fonction retourne faux si la représentation des angles retournés n'est pas
l'unique solution.
Private Function GetAngles(ByVal m As Matrice, ByRef Roll As Double, ByRef Pitch As
Double, ByRef Yaw As Double) As Boolean
Dim vRoll As Double
Dim vPitch1 As Double
Dim vPitch2 As Double
Dim vPitchGarde As Double
Dim vYaw As Double
Dim UniqueSolution As Boolean
'Vérifier les singularités
If m(2, 0) > 0.998 Then
vYaw = 0
vPitchGarde = -Math.PI / 2
vRoll = Math.Atan2(-m(1, 2), m(1, 1))
UniqueSolution = False
ElseIf m(2, 0) < -0.998 Then
vYaw = 0
vPitchGarde = Math.PI / 2
vRoll = Math.Atan2(m(1, 2), m(1, 1))
UniqueSolution = False
Else
'Il y aurait 2 solutions, mais seulement le complément au angles de 180 degrée
UniqueSolution = True
'Cette étape n'est pas nécessaire, mais les résultats sont plus constants en
'comparant les deux possibilités.
'Calculer les deux possibilités
vPitch1 = Math.Atan2(-m(2, 0), (-1) * Math.Sqrt(m(0, 0) * m(0, 0) + m(1, 0) * m(1, 0)))
vPitch2 = Math.Atan2(-m(2, 0), Math.Sqrt(m(0, 0) * m(0, 0) + m(1, 0) * m(1, 0)))
'Prendre la réponse la plus proche de l'angle avant la rotation
If Math.Abs(m_Pitch - (vPitch1 * (180/Math.PI))) < Math.Abs(m_Pitch - (vPitch2 * (180/Math.PI))) Then
vPitchGarde = vPitch1
Else
vPitchGarde = vPitch2
End If
Dim t As Double = Math.Cos(vPitchGarde)
vRoll = Math.Atan2(m(1, 0) / t, m(0, 0) / t)
vYaw = Math.Atan2(m(2, 1) / t, m(2, 2) / t)
End If
'Retourner les angles en degré
Roll = vRoll * (180 / Math.PI)
Pitch = vPitchGarde * (180 / Math.PI)
Yaw = vYaw * (180 / Math.PI)
'Retrouner vrai s'il n'y a pas de situation de singularité
Return UniqueSolution
End Function
28
ANNEXE E DessinerRefCentrale
'Dessiner les référentiels selon une projection centrale
Private Sub DessinerRefCentrale()
Const FACTEUR_PROFONDEUR_FIXE As Double = 0.65
l'axe de profondeur
Const FACTEUR_PROFONDEUR_VAR As Double = 0.75 / 200
l'axe de profondeur selon la valeur en X
Const FACTEUR_PROFONDEUR_INIT As Double = 0.625
longeur de l'axe de profondeur
Const ANGLE_CAMERA As Double = Math.PI / 4
Dim
Dim
Dim
Dim
Dim
Dim
Dim
'Facteur qui réduit la longueur de
'Facteur qui réduit la longueur de
'Facteur initiale qui réduit la
'Angle de l'axe de profondeur
canvas As Graphics
crayon As Pen = New Pen(Color.Red)
Police As Font = New Font("Arial", 10, FontStyle.Italic)
ValeurY, ValeurZ As Integer
ProfondeurX, ProfondeurY As Double
Facteur As Double
EcranX, EcranY As Integer
canvas = m_Form.CreateGraphics()
canvas.Clear(m_Form.BackColor)
'Mettre le référentiel fixe plus épais
crayon.Width = 2
'Axe des Xr---------------------------------------------------------ValeurY = 0
ValeurZ = 0
'Nx * Longueur*(0.625 + Nx*Longueur*0.75/200)
Facteur = LONGUEUR_REF_R * ((FACTEUR_PROFONDEUR_INIT + LONGUEUR_REF_R *
FACTEUR_PROFONDEUR_VAR)) * FACTEUR_PROFONDEUR_FIXE
'Facteur transposé sur l'axe des x ou y
ProfondeurX = Math.Cos(ANGLE_CAMERA) * Facteur
ProfondeurY = Math.Sin(ANGLE_CAMERA) * Facteur
'Valeur en X,Y à l'écran
EcranX = Convert.ToInt32(ORIGINE_X + ValeurY - ProfondeurX)
EcranY = Convert.ToInt32(ORIGINE_Y - ValeurZ + ProfondeurY)
crayon.Color = Color.Red
canvas.DrawLine(crayon, ORIGINE_X, ORIGINE_Y, EcranX, EcranY)
'Axe des Yr---------------------------------------------------------crayon.Color = Color.Green
canvas.DrawLine(crayon, ORIGINE_X, ORIGINE_Y, Convert.ToInt32(ORIGINE_X + LONGUEUR_REF_R),
Convert.ToInt32(ORIGINE_Y))
'Axe des Zr---------------------------------------------------------crayon.Color = Color.Blue
canvas.DrawLine(crayon, ORIGINE_X, ORIGINE_Y, Convert.ToInt32(ORIGINE_X),
Convert.ToInt32(ORIGINE_Y - LONGUEUR_REF_R))
'Dessiner nouveau référentielle
crayon.Width = 1
'Axe des Xt---------------------------------------------------------'Valeur catésienne directe (Y,Z).
ValeurY = Convert.ToInt32(m_MatriceOrientation(1, 0) * LONGUEUR_REF_T)
ValeurZ = Convert.ToInt32(m_MatriceOrientation(2, 0) * LONGUEUR_REF_T)
29
'Nx * Longueur*(0.625 + Nx*Longueur*0.75/200)
Facteur = m_MatriceOrientation(0, 0) * LONGUEUR_REF_T * ((FACTEUR_PROFONDEUR_INIT +
m_MatriceOrientation(0, 0) * LONGUEUR_REF_T * FACTEUR_PROFONDEUR_VAR)) * FACTEUR_PROFONDEUR_FIXE
'Facteur transposé sur l'axe des x ou y
ProfondeurX = Math.Cos(ANGLE_CAMERA) * Facteur
ProfondeurY = Math.Sin(ANGLE_CAMERA) * Facteur
'Valeur en X,Y à l'écran
EcranX = Convert.ToInt32(ORIGINE_X + ValeurY - ProfondeurX)
EcranY = Convert.ToInt32(ORIGINE_Y - ValeurZ + ProfondeurY)
crayon.Color = Color.Red
canvas.DrawLine(crayon, ORIGINE_X, ORIGINE_Y, EcranX, EcranY)
canvas.DrawString("Xt", Police, New SolidBrush(Color.Red), EcranX, EcranY)
'Axe des Yt---------------------------------------------------------'Valeur catésienne directe (Y,Z).
ValeurY = Convert.ToInt32(m_MatriceOrientation(1, 1) * LONGUEUR_REF_T)
ValeurZ = Convert.ToInt32(m_MatriceOrientation(2, 1) * LONGUEUR_REF_T)
'Nx * Longueur*(0.625 + Nx*Longueur*0.75/200)
Facteur = m_MatriceOrientation(0, 1) * LONGUEUR_REF_T * ((FACTEUR_PROFONDEUR_INIT +
m_MatriceOrientation(0, 1) * LONGUEUR_REF_T * FACTEUR_PROFONDEUR_VAR)) * FACTEUR_PROFONDEUR_FIXE
'Facteur transposé sur l'axe des x ou y
ProfondeurX = Math.Cos(ANGLE_CAMERA) * Facteur
ProfondeurY = Math.Sin(ANGLE_CAMERA) * Facteur
'Valeur en X,Y à l'écran
EcranX = Convert.ToInt32(ORIGINE_X + ValeurY - ProfondeurX)
EcranY = Convert.ToInt32(ORIGINE_Y - ValeurZ + ProfondeurY)
crayon.Color = Color.Green
canvas.DrawLine(crayon, ORIGINE_X, ORIGINE_Y, EcranX, EcranY)
canvas.DrawString("Yt", Police, New SolidBrush(Color.Green), EcranX, EcranY)
'Axe des Zt---------------------------------------------------------'Valeur catésienne directe (Y,Z).
ValeurY = Convert.ToInt32(m_MatriceOrientation(1, 2) * LONGUEUR_REF_T)
ValeurZ = Convert.ToInt32(m_MatriceOrientation(2, 2) * LONGUEUR_REF_T)
'Nx * Longueur*(0.625 + Nx*Longueur*0.75/200)
Facteur = m_MatriceOrientation(0, 2) * LONGUEUR_REF_T * ((FACTEUR_PROFONDEUR_INIT +
m_MatriceOrientation(0, 2) * LONGUEUR_REF_T * FACTEUR_PROFONDEUR_VAR)) * FACTEUR_PROFONDEUR_FIXE
'Facteur transposé sur l'axe des x ou y
ProfondeurX = Math.Cos(ANGLE_CAMERA) * Facteur
ProfondeurY = Math.Sin(ANGLE_CAMERA) * Facteur
'Valeur en X,Y à l'écran
EcranX = Convert.ToInt32(ORIGINE_X + ValeurY - ProfondeurX)
EcranY = Convert.ToInt32(ORIGINE_Y - ValeurZ + ProfondeurY)
crayon.Color = Color.Blue
canvas.DrawLine(crayon, ORIGINE_X, ORIGINE_Y, EcranX, EcranY)
canvas.DrawString("Zt", Police, New SolidBrush(Color.Blue), EcranX, EcranY)
End Sub
30