Upload
ngongoc
View
232
Download
3
Embed Size (px)
Citation preview
Rapport de stage de deuxieme annee
Paul Chavent
Kubrick
16 septembre 2003
Projet Kuka
(juin-septembre 2003)
1
Rapport du stage Kuka
2
Remerciements
Avant toutes choses, je tiens a remercier les personnes sans qui mon stage n’aurait pas pu avoir lieu :
– M. SCHOULLER, mon employeur, directeur d’IMERIR.
– MlleECKERT, ma tutrice, enseignante en robotique.
– M. SALVAT, mon tuteur, enseignant les matieres d’IA.
Je remercie egalement les personnes de chez qui m’ont donne de leur temps pour m’aider :
– Emmanuel BERGEROT (Responsable Technico-commercial region Sud-Ouest France)
– Jean-Louis RENOUX (Ingenieur Developpeur Kuka France)
– Didier SUTTY (Technicien Kuka France)
– Laurent HALTER (Ingenieur Developpeur Kuka France)
Enfin, je remercie aussi le personnel d’IMERIR que j’ai cotoye tous les jours et particulierement Michel
Juanola pour son assistance technique.
3
Rapport du stage Kuka
Glossaire
API : Application Programming Interface (interface de programmation applicative).
COM : Component Object Model.
DCE RPC : Distributed Computing Environment Remote Procedure Call.
DCOM : Distibuted COM.
IA : Intelligence Artificielle.
IDL : Interface Definition Language (language de definition d’interface).
IHM : Interface Homme Machine.
KR6/2 : Kuka Robot 6Kg 2e version. C’est un robot a six axes de libertes.
KRC : Kuka Robot Cabinet.
KRL : Kuka Robot Language.
OLE : Object Linking and Embending.
ONC RPC : Open Network Computing Remote Procedure Call.
OPC : OLE for Process Control (OLE pour commande de processus).
RPC : Remote Procedure Call (appel de procedure distante).
SDK : Software Developpement Kit (boıte a outils pour le developpement de logiciels).
4
Table des matieres
Table des matieres
1 Introduction 10
2 L’entreprise et le contexte 12
2.1 Le personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Le lieu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Etude du projet 14
3.1 Sujet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Etude du besoin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Etat de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1 Liaison serie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.2 VxWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.3 OPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.4 CrosscommExe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.5 En conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Conception d’une solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.1 La base : le “crosscommexe” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4.2 La base : le programme de commande . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.3 La base : resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4.4 L’extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.5 Les details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5
Rapport du stage Kuka
4 Realisation 27
4.1 Le produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.1 La documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.2 Le serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.3 Le client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.4 Partie commune . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Les tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Tests unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.2 Tests d’integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Le produit, aujourd’hui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1 Performances et limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.2 Le jeux de dame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.3 Le jeux de morpion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Le produit, demain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5 Gestion du projet 35
5.1 Methodologie et planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Ressources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.1 Ressources materielles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.2 Ressources humaines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6 Conclusion 38
6
Table des matieres
7 Annexes 39
7.1 Annexe 1 : communication.pdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.2 Annexe 2 : comdcom.pdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.3 Annexe 3 : opc.pdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
7.4 Annexe 4 : opcproconos.pdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.5 Annexe 5 : comparatif.pdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.6 Annexe 6 : crosscommexe.pdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7
Rapport du stage Kuka
Table des figures
1 Le robot au centre de quelques exemples d’applications aux cours enseignes a IMERIR . . 10
2 Architecture logicielle de la commande du robot. . . . . . . . . . . . . . . . . . . . . . . . 15
3 Solution ”serie” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Solution ”vxWorks” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5 Solution ”OPC” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6 Solution ”CrossCommExe” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7 Description d’un objet OLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8 Les six degres de liberte du robot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9 Architecture du systeme de base. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10 Architecture du systeme definitif. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11 Les differentes couches de l’implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12 Propagation des erreurs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8
Table des figures
9
Rapport du stage Kuka
1 Introduction
En aout 2002, IMERIR fait l’acquisition d’un robot de la marque . On retrouve frequemment ces
robots dans l’industrie pour des applications diverses : palettisation, embouteillage, chaıne d’assemblage,
etc. En effet, la societe dispose d’une gamme complete de robots pouvant porter, a leur extremite,
des charges allant de 3Kg a 570Kg. Le robot d’IMERIRest un KR6/2, c’est a dire qu’il peut porter des
charges de 6Kg en bout de bras. En industrie, ce modele est essentiellement utilise pour du percage et
de la soudure car il s’agit d’un robot rapide et precis (c’est le plus deuxieme robot le plus precis de la
gamme avec une repetatibilite inferieure a ± 0,1mm).
A l’IMERIR, ce robot sert a mettre en application les cours de robotique a travers des seances de TP qui
nous permettent :
– La manipulation des changements de bases, des deplacements relatifs et absolus, des trajectoires li-
neaires circulaires etc.
– L’observation des configurations singulieres.
– L’etude des modeles cinematiques et dynamiques, directs et inverses.
Des ses premiers essais, le robot suscite beaucoup d’interet aupres :
– des etudiants qui ont la possibilite de mettre en pratique les cours de facon ludique,
– des enseignants qui ont un moyen d’etendre la portee de leurs travaux pratiques et ainsi d’attirer
l’attention des eleves. Par exemple les algorithmes d’IA qui permettent de resoudre des parties d’echec
seront mis en application sur un jeux d’echec reel. Aussi les travaux de visionique serviront a controler
le robot.
Ainsi le robot Kuka est l’element central qui permet de faire le lien entre les differentes matieres enseignees
a l’ecole, comme le schematise la figure 1.
Fig. 1 – Le robot au centre de quelques exemples d’applications aux cours enseignes a IMERIR
Pour envisager d’utiliser le robot dans un tel contexte, il fallait une interface qui nous permettrait de
communiquer avec lui. Or une des particularite des robots est qu’ils sont controles a partir d’un PC
(fait assez rare dans le monde industriel pour le signaler), et qu’ils proposent une multitude de moyens
de communication (bus, interface logicielles etc.).
Dans notre cas, le controle du robot devait se faire via un langage de programmation standard (le c
10
1 Introduction
semblait tout designe), et si possible a distance de maniere a repartir les applications et a etre independant
du systeme d’exploitation. Le stage Kuka a donc ete mis en place afin de concevoir une telle interface
logicielle.
Ce document presente l’evolution du travail durant les 4 mois de stage.
Une version numerique de ce document se trouve sur le serveur de l’ecole a :
nestor:///Projets/Stages/Kuka/documents/organisation/rapport.pdf
Egalement sur internet a :
http ://www.imerir.com/kuka/kukaApi/doc/rapport.pdf
Ces fichiers ont ete generes avec LATEX. Les sources sont disponibles a :
nestor:///Projets/Stages/Kuka/documents/organisation/rapport/rapport.tex
11
Rapport du stage Kuka
2 L’entreprise et le contexte
Le stage s’est deroule au sein de l’Institut Mediterraneen d’Etude et de Recherche en Informatique et
Robotique :
Avenue Pascot BP 2013 - 66011 Perpignan Cedex - FRANCE.
Tel : 04 68 56 80 18 - Fax : 04 68 55 03 86.
mail : [email protected]
L’IMERIR est une association loi 1901, a but non lucratif et est administree depuis 1989 par la Chambre
de Commerce et d’Industrie des Pyrenees Orientales. L’ecole delivre un titre en ” ingenierie informatique
et robotique ” homologue par l’etat (Niveau I) au bout de 3 annees d’etudes.
L’ecole est composee de 180 eleves et d’une douzaine de salaries. Les salaries de l’ecole sont les professeurs
et l’administration.
2.1 Le personnel
L’equipe des responsables et enseignants d’IMERIR comprend :
– Le directeur : Jean-Pierre SCHOULLER
– L’attachee de Direction : Gisele JACQUEMIER
– Le secretariat : Christina WATKINS
– Un responsable des etudes : Christian DELMOTTE
– Une responsable de la scolarite : Martine BOLTE
– Les professeurs permanents : Martine BOLTE, Pierre BOURDIN, Frederique
COUDRET, Christian DELMOTTE, Martine ECKERT, Nicolas PECH-GOURG, Yves RANCOULE,
Ahmed RHARMAOUI , Eric SALVAT.
– Un responsable technique : Michel JUANOLA
– Les relations internationales : Marie-Noelle STEVENS
L’equipe de travail etait composee d’un stagiaire (moi-meme) sous la tutelle de MlleEckert et M. Salvat.,
respectivement responsables de la partie robotique et IA du stage.
12
2 L’entreprise et le contexte
2.2 Le lieu
L’ecole se situe entre Toulouges et Perpignan (66-France). Elle met a disposition des eleves :
– quatre salles informatiques dont une est renouvelee chaque annee,
– un ateliers de reseau avec du materiel Cisco (routeurs, switches, etc.),
– un ateliers de robotique avec une partie robotique mobile (Peekee) et une partie “Kuka”,
– un ateliers de CAO/Infographie avec un robot Charlie (usinage de pieces) et des ordinateurs plus puis-
sants pour les travaux d’infographie.
Le stage s’est deroule dans l’atelier de robotique. Nous expliquons en details les ressources utilisees dans
la partie 5.2 page 36.
13
Rapport du stage Kuka
3 Etude du projet
Cette partie presente les premieres etapes qui nous ont permis de cerner le sujet et de concevoir une
solution.
3.1 Sujet
IMERIR a besoin d’une interface pour piloter son robot Kuka par un PC du reseau de l’ecole. MlleEckert
connaıt deja le robot et sait qu’il existe des solutions. Avec M. Salvat, ils proposent un stage qui aura
pour but d’etudier les solutions existantes, et d’en choisir une, ou, a defaut, d’en concevoir une nouvelle.
L’interface de programmation, ou API, doit etre accessible pour un programme ecrit en c, c++, Lisp,
Prolog, ou autre. Le c etant extensible aux autres langages, nous orienterons notre developpement en c.
A l’issue du stage, l’ecole souhaite avoir obtenu un moyen de piloter le robot a distance. Le produit final
sera donc compose :
– d’un serveur qui attend des commandes,
– d’un client (sous forme de librairie) qui permet d’envoyer des commandes au robot.
3.2 Etude du besoin
Le robot Kuka est commande par un PC qui tourne sous VxWin.
VxWin (contraction de VxWorks et Windows r©) est un systeme d’exploitation qui offre les avantages du
temps reel associe a ceux des interfaces ergonomiques. VxWorks (le systeme temps reel) est le processus
prioritaire. Lorsqu’il est inactif, il laisse les ressources libres a Windows r© (l’interface utilisateur). Par
exemple, lorsque le robot est en action ou qu’une interruption se produit, VxWorks est prioritaire sur
les ressources et met Windows r© a l’arriere plan. Lorsque le robot est inactif et que nous editons des
programmes sur le robot, c’est l’inverse.
Le robot est donc commande, au plus bas niveau, par VxWorks. VxWorks execute des instructions qu’il
lit dans un programme que nous lui avons charge en memoire.
Ce programme de commande est charge depuis Windows. C’est d’ailleurs dans Windows que l’utilisateur
cree/modifie le programme.
Ces passages de l’espace utilisateur a l’espace robot sont transparents et son geres par une IHM : le
KukaBOF. Ainsi l’utilisateur ecrit un programme (en KRL), le modifie, le charge et le fait executer
14
3 Etude du projet
depuis le KukaBOF.
La figure 2 illustre cette architecture. De plus elle met en evidence le fait que Windows r© communique
Fig. 2 – Architecture logicielle de la commande du robot.
avec VxWorks via le CROSS. Ce composant jouera un role important dans notre produit final.
Bien que cette conception soit exceptionnelle pour le monde de l’entreprise (en terme d’accessibilite et
d’evolutivite) par rapport a ce qui se faisait, elle ne l’est pas autant dans notre contexte. En effet, a
IMERIR, les eleves sont habitues a developper des applications au plus bas niveau et auront besoin
d’acceder aux commandes de Kuka par des appels de fonctions en c ou c++ par exemple. De plus
les programmes qu’ils developperont pourront etre repartis sur le reseau. Il etait alors impossible de
commander le robot dans ces conditions pour deux raisons :
– la programmation du robot se fait uniquement en KRL (impossible de controler des peripheriques
complexes, tels des camera, ou impossible de developper des algorithmes optimise pour du traitement
d’image),
– nous devons intervenir sur le robot (modifier le programme et le recharger) lorsque nous voulons modifier
le comportement du robot.
Le but du stage a donc ete de combler ce manque.
15
Rapport du stage Kuka
3.3 Etat de l’art
Lorsqu’ils ont propose le stage, MlleEckert et M. Salvat savaient que l’objectif pourrait etre atteint. En
effet, il existe deja quelques solutions qui permettent au robot de communiquer avec l’exterieur. D’ailleurs
c’est aussi cette ouverture vers l’exterieur qui contribue a la qualite des robots . Par contre il restait
a determiner :
– comment ces solutions fonctionnaient ?
– etait-elles adaptes au probleme ?
– combien nous couteraient-elles ?
– quelles en sont les avantages et les inconvenients ?
– pouvions-nous developper notre propre solution ou etions-nous contraints d’utiliser l’existant ?
Nous avons donc consacre le premier mois du stage a repondre a ces questions. Nous avons fait des
recherches sur l’existant, developpe des programmes de test afin d’essayer certaines voies d’exploration,
pour enfin choisir la direction a prendre.
Les parties qui suivent sont un resume des solutions que nous avons pris en compte pour notre choix
definitif.
3.3.1 Liaison serie
La premiere voie d’exploration fut internet. Nous avons trouve un seul projet se rapprochant de ce que
nous voulions faire. Ce projet1 fut developpe dans une universite allemande pour faire des experiences de
coordination entre leur deux robots ( des KR6/2, avec une KRC 1).
La figure 3 represente la facon dont les differentes entites sont reliees. Nous avons des postes clients re-
partis sur le reseau. Ils envoient un ordre au serveur via une liaison TCP/IP. Le serveur decode l’ordre
qui arrive et le re-encode pour le faire passer par la liaison serie. Le KRC recoit l’ordre, le decode et
l’execute.
De plus, le serveur permet de gerer les requetes simultanees, de gerer des authentifications simples (connec-
tions administrateur ou normal).
Cette solution etait fonctionnelle, son installation necessitait juste de mettre en service un PC avec Linux
temps reel qui aurait servi de serveur. L’experience nous a demontre que quelques complications se faisait
ressentir au niveau de l’installation, notamment a cause de problemes de configuration :
– ils disposaient de deux robots, nous d’un seul,
1http ://pdv.cs.tu-berlin.de/forschung/KUKA PJ-WS00/
16
3 Etude du projet
Fig. 3 – Solution ”serie”
– ils utilisaient la version 1 du robot, nous la 2. Ceci impliquait des adaptations a faire au niveau du port
serie.
Pour palier a ces problemes nous avons passe un certain temps a etudier la solution plus en profondeur.
Nous avons donc appris a faire fonctionner un systeme temps reel, appris comment fonctionnait les
programmes qui s’executent dessus, et appris comment fonctionne le protocole serie du robot (3964R).
Sur ce dernier point, Didier Sutty (technicien de chez ) nous a apporte une aide precieuse en nous
fournissant de la documentation et des programmes d’exemple.
Alors que nous essayons en vain de faire fonctionner cette solution, nos recherches s’etaient deja orientees
vers d’autres choix possibles. . .
3.3.2 VxWorks
Les recherches sur internet ont aussi evoque la possibilite de communiquer directement avec le systeme
temps reel de Kuka : vxWorks. La figure 4 resume son architecture theorique. Nous ne nous attarderons
pas a expliquer cette solution, elle fut rapidement ecartee a cause du manque de documentation et de
l’absence de programmes d’exemple. En effet, cette solution touche de tres pres le coeur du systeme du
robot et garde les informations afin de proteger leur technologie.
17
Rapport du stage Kuka
Fig. 4 – Solution ”vxWorks”
3.3.3 OPC
D’autre part, M. Salvat avait suggere la possibilite d’utiliser le standard OPC. OPC (OLE Process
Control) est une specification d’interface qui permet aux differentes machines d’un atelier de communiquer
entre elles. L’implementation de ces interfaces est faite avec la technologie DCOM. Il existe actuellement
deux produit :
– L’OPC , qui est encore en developpement.
– L’OPC ProConOs dont nous avons obtenu une version d’essai illimitee.
La figure 5 represente le fonctionnement de la solution “OPC ProConOs”. Nous constatons que cette
solution implique un programme de commande qui s’execute sur Kuka dans vxWorks. Nous communiquons
avec le robot via le ProConOs (equivalent du cross). Ce dernier recoit des ordres depuis un serveur OPC
qui lui-meme est sollicite par ses clients.
Grace a une proposition de la part d’Emmanuel Bergerot et de Jean-Louis Renoux, nous avons pu essayer
cette solution a l’ecole.
3.3.4 CrosscommExe
Enfin, MlleEckert avait obtenue un exemple d’utilisation d’un composant OLE permettant de communi-
quer avec le robot : le crosscomm. D’autre part le robot dispose en standard d’un systeme de diagnostic
accessible depuis http. Apres l’etude de son fonctionnement nous avons constate qu’il repose egalement
sur un composant OLE (le webRobot).
18
3 Etude du projet
Fig. 5 – Solution ”OPC”
Pour etudier ces possibilites, nous avons developpe un programme qui permet de controler le robot grace
au CrossCommExe. Par contre nous etions limite au fait que le programme devait s’executer sur le robot
car le composant CrossCommExe n’est pas visible sur le reseau. Nous avons obtenus une solution comme
celle de la figure 6.
Fig. 6 – Solution ”CrossCommExe”
3.3.5 En conclusion
Au cours de nos recherches nous avons ecrit quelques pages qui nous serviraient d’aide memoire, notam-
ment :
19
Rapport du stage Kuka
– Une description de la norme OPC : voir en annexe (partie 7.3 page 56).
– Une description du fonctionnement de l’OPC de ProConOS : voir en annexe (partie 7.4 page 66).
– Une description de la technologie COM/DCOM, et un exemple d’utilisation du crosscommexe : voir en
annexe (partie 7.2 page 47).
– Une documentation des fonctions que propose le crosscommexe : voir en annexe (partie 7.6 page 81).
Aussi nous avons realise un premier comparatif des differents moyens de communication dans le document
“communication.pdf” : voir en annexe (partie 7.1 page 40).
Enfin, lorsque notre choix ne se limitait plus qu’a deux solutions (“OPC” ou “crosscommexe”) nous avons
realise un dernier comparatif plus detaille dans le document “comparatif.pdf” : voir en annexe (partie 7.5
page 71).
Finalement nous avons choisi d’utiliser la solution“crosscommexe”en l’etendant afin de la rendre accessible
depuis le reseau.
3.4 Conception d’une solution
Comme nous venons de l’expliquer, la solution sur laquelle nous nous appuyons n’est pas complete. Il
faut l’adapter a notre contexte.
Mais avant de parler de l’extension, nous allons reprendre en detail la description de la base.
3.4.1 La base : le “crosscommexe”
Le “crosscommexe” est un composant OLE. Nous decrivons ce qu’est un composant OLE dans le docu-
ment com dcom.pdf (dont la reference est indique dans la partie 3.3.5 page 19). Pour resumer :
– Ce composant se presente sous forme d’un executable (CROSSCOMMEXE.EXE sur la figure 7).
– Cet executable est un objet auquel nous pouvons acceder avec des interfaces (par exemple CrossCom-
mand sur la figure 7).
– Chaque composant est differencie par un identifiant constant : c’est le CLaSsID (D97209F1-CD...
sur la figure 7). C’est a dire que de tous temps et en tous lieux (sur n’importe quelle machine) nous
pourrons trouver ce composant connaissant son identifiant.
La figure 7 resume ces notions. Dans notre cas, l’interface qui nous interesse est l’interface _CrossCommand.
Cette interface met a notre disposition des methodes qui permettent de :
– voir/modifier la valeur des variables,
20
3 Etude du projet
Fig. 7 – Description d’un objet OLE
– charger/decharger des modules,
– interrompre l’execution d’un programme (stop),
– demarrer, stopper, changer l’interpreteur submit,
– etc.
Le composant crosscommexe et ses interfaces ne sont pas documentes par et ne beneficient d’aucun
support. Nous avons donc du faire des essais, noter le comportement de chaque fonction de l’interface
_CrossCommand, pour enfin produire une documentation. Cette documentation decrit chaque fonction,
avec les parametres d’entree, les valeurs de retour etc. Bien sur, il reste des points a eclaircir, mais nous
disposons deja de beaucoup de fonctions et cela nous suffit pour sortir la premiere version de notre produit.
Vous trouverez cette documentation en annexe (partie 7.6 page 81).
Grace a ce composant nous avons donc un moyen de commander le robot, du moins en partie. Nous allons
maintenant expliquer pourquoi le controle n’est pas total.
3.4.2 La base : le programme de commande
Nous voulons par exemple controler la position du bras du robot. Ceci peut se faire en ajustant la valeur
des angles de chaque axe de rotation. La figure2 8 indique les six degres de liberte du robot de l’ecole (un
KR 6/2).
Chaque angle de rotation est represente par une variable : $AXIS_ACT.A1, $AXIS_ACT.A2, [...], $AXIS_ACT.A6.
Ces variables contiennent la valeur de l’angle (en degres) de chaque axe. Grace a l’interface _CrossCom-
2Schema extrait de la documentation de kuka : Programmation expert, Programmation du deplacement (partie 4, page
66).
21
Rapport du stage Kuka
Fig. 8 – Les six degres de liberte du robot.
mand, nous pouvons consulter la valeur de ces variables en invoquant la methode ShowVar(). Par contre
il est impossible de les modifier directement car elles sont en lecture seule. Pour ce faire, nous devons
appeler une des commandes du robot qui permet d’effectuer des deplacements. Le manuel de programma-
tion expert du robot decrit comment faire de tels deplacements dans la section “Programmation expert,
Programmation du deplacement” (partie 4) a la page 65.
Jusqu’a present le seul moyen d’appeler ces commandes est de le faire dans un programme, que l’on
charge dans le robot pour l’executer. Nous precisons “jusqu’a present” car l’interface _CrossCommand dis-
pose d’une methode qui s’appelle “cmd”, ce qui laisse presager que le crosscomm peut executer certaines
commandes, mais nous n’avons pas encore trouve le moyen de faire fonctionner cette methode.
Dans notre contexte, il faudra un seul programme de commande capable d’executer le maximum d’ordre
differents. Ce programme de commande tournera en boucle infinie sur le robot en attente d’ordres pro-
venant des utilisateurs.
Remarque : les solutions “OPC” (voir partie 3.3.3 page 18) et “liaison serie” (voir partie 3.3.1 page 16)
sont basees sur le meme principe.
3.4.3 La base : resume
En resume, nos premiers tests nous font aboutir a une solution qui nous permet de controler les depla-
cements du robot a partir d’un processus local, c’est a dire qui s’execute sur Kuka. L’architecture du
systeme ressemble alors au schema de la figure 9. Nous avons alors en activite :
Le processus d’ecoute (ou programme de commande) Il tourne sur le robot dans le systeme temps
reel (vxWorks) en attente d’un ordre. Ce processus est lance depuis l’interface utilisateur du robot
(le KukaBof). Son source est ecrit en KRL.
Le processus client C’est un processus qui envoie les ordres au programme de commande. Il tourne
22
3 Etude du projet
Fig. 9 – Architecture du systeme de base.
dans l’espace utilisateur (Windows r©95). Ce processus est lance sur le robot par le client.
Le composant crosscommexe.exe C’est un executable lance automatiquement lorsqu’on desire utili-
ser une de ses interfaces. C’est transparent pour l’utilisateur, cela sert seulement a faire communiquer
le processus d’ecoute et le processus client via le cross.
Le produit dont nous disposons peut alors etre etendu afin de disposer des fonctionnalites depuis le reseau.
3.4.4 L’extension
Dans la specification du besoin (voir partie 3.2 page 14), il est ecrit que nous devrons pouvoir utiliser le
robot pour accomplir des taches liees a de la visionique, de l’IA, etc. Les algorithmes developpes pour ces
programmes sont generalement complexes, demandent beaucoup de ressources en temps de calcul, et ont
besoin d’acceder aux peripheriques (visionique). Il fallait donc deporter l’api sur un poste distant a cause
du systeme temps reel qui est prioritaire au niveau des ressources.
Encore une fois, nous nous sommes inspires de l’existant : la technologie sur laquelle repose DCOM (qui
lui meme est utilise par OPC) communique sur le reseau grace aux RPC. Il en existe differentes sortes3.
Alors que DCOM utilise les DCE RPC, nous avons choisi les ONC RPC. Notre choix s’est porte sur eux
a cause de leur simplicite, de leur robustesse, et du fait que c’est une vieille technologie qui a fait ses
preuves.
Grace aux RPC nous pouvons exporter sur le reseau des fonctions. Ainsi un client distant peut utiliser des
3Vous trouverez un comparatif a http ://hissa.nist.gov/rbac/5277/titlerpc.html. Il est vieux mais suffisant
23
Rapport du stage Kuka
fonctions qui sont implementees sur un serveur comme si elles etaient locales. Ainsi nous pourrons appeler
les methodes de l’interface du composant crosscommexe depuis un client distant. En realite nous avons
choisi de ne pas exactement exporter ces methodes. Pour plus de details sur ce point voir la partie 3.4.5
page 24.
Finalement, il suffit de presenter au client une interface ergonomique (facile d’utilisation, avec des types
simples a manipuler) qui encapsule les couches sous jacentes, et le produit final est complet (voir figure 10).
L’API mise a disposition propose des fonctions de bas niveau du point de vue utilisateur (set/getVar
Fig. 10 – Architecture du systeme definitif.
etc.). Donc pour des applications specifiques a un domaine il est recommande de l’encapsuler. Pour
illustrer ceci, nous fournissons avec le produit final un programme d’exemple qui manipule des pions sur
un damier. Ainsi un ordre du type prend(A,2) fait executer un deplacement du bras au dessus de la case
A2 du damier, ouvre la pince, baisse le bras, ferme la pince, leve le bras avec des fonctions de bas niveau
de type set/getVar.
3.4.5 Les details
Nous n’allons pas trop detailler ici le programme de commande car il s’agit de technique pure et que
nous n’avons rien apporte de nouveau dans sa conception. Si vous voulez plus d’informations a ce sujet
24
3 Etude du projet
reportez vous aux manuels fournis avec l’API4.
Par contre la partie API merite quelques explications afin de bien retrouver ou interviennent chaque
technologie mise en jeux. Grace a la figure 11 nous allons vous decrire chaque “couche”. Nous avons les
Fig. 11 – Les differentes couches de l’implementation
fichiers suivants :
– Cote serveur :
crosscommexe.* Le fichier IDL est une specification d’interface. C’est a dire qu’il decrit les interfaces
et les methodes (leur identifiant, leur prototype...) du composant CrossCommExe. De ce fichier
nous generons (avec midl, un outils de la suite VC++) les deux sources crosscommexe.h et cross-
commexe_i.cpp. Grace a ces fichiers nous pourrons utiliser le composant CrossCommExe. Enfin
le fichier crosscommexe_w.cpp permet d’encapsuler le composant afin d’en faciliter l’utilisation
dans les couches de dessus.
kuka *.* Ce sont des fichiers qui sont egalement generes (par rpcgen) a partir d’une specification
d’interface. Cette fois la specification (fichier kuka.x) est celle des procedures distantes. Seul le
fichier kuka_proc.c est cree manuellement. C’est lui qui implemente les procedures qui seront
exportees sur le reseau grace aux RPC.
– Cote client :
kuka *.* Ce sont aussi des fichiers generes a partir de kuka.x, mais ils sont specifiques au cote client.
kuka api.* C’est l’interface du produit final.
4disponibles sur le site : http ://www.imerir.com/kuka/kukaApi/doc/
25
Rapport du stage Kuka
Ceci est decrit plus en detail dans le manuel du developpeur, disponible a :
http ://www.imerir.com/kuka/kukaApi/doc/kuka api man devl.pdf
26
4 Realisation
4 Realisation
Le produit que nous avons developpe est baptise “kuka api”. Cette partie vous le presente dans sa version
0.0.5.
4.1 Le produit
Le produit final se decompose en deux parties : un serveur(fonctionnant sous Windows r©95 uniquement)
et un client(fonctionnant sous Windows r© ou Linux). Tout est disponible sous forme de sources, de
binaires, et bien sur, fournis avec la documentation qui l’accompagne.
4.1.1 La documentation
Pour faciliter la maintenance, nous avons dote chaque repertoire important (racine du repertoire du
serveur et du client) de :
– un README qui donne des infos generales,
– un CHANGELOG qui dit ce qui a change depuis les versions anterieures,
– un TODO qui propose ce qu’il faudra faire pour corriger des bugs ou ameliorer le produit.
Aussi deux manuels decrivent le systeme a differents niveaux :
– Le manuel de l’utilisateur, qui contient
– les instructions pour bien installer le serveur et/ou le client,
– la description des fonctions,
– un exercice d’application.
Ce manuel est disponible a :
http ://www.imerir.com/kuka/kukaApi/doc/kuka api man util.pdf
En complement, un manuel de reference liste tous les types de variables, les fonctions (avec leurs para-
metres et leur retours), les macros, les constantes, etc. Il est disponible a :
http ://www.imerir.com/kuka/kukaApi/doc/kuka api man ref.pdf
– Le manuel du developpeur qui contient
– la description du fonctionnement interne de l’API,
– la marche a suivre pour maintenir et faire evoluer le code.
Ce manuel est disponible a :
27
Rapport du stage Kuka
http ://www.imerir.com/kuka/kukaApi/doc/kuka api man devl.pdf
Note : Ces manuels sont ecrits en LATEX mais ils ont ete compile en pdf. Les sources sont disponibles avec
les sources du client dans le repertoire “http ://www.imerir.com/kuka/kukaApi/doc”.
Enfin, le site internet a ete realise pour partager les sources, les binaires, les documents, et des informations
en general.
4.1.2 Le serveur
Le serveur se compose de trois petits programmes :
– Un executable qui lance le portmapper des RPC (pm ascii.exe 52 Ko). Ceci est un programme qui
permet de resoudre les requetes provenant des clients invoquant les procedures du serveur. C’est un
composant qu’il ne nous a pas ete necessaire de developper puisqu’il est fourni avec le SDK ONC RPC.
– Un executable qui repond aux requetes des clients invoquant les procedures du serveur (kuka serveur.exe
137 Ko). C’est la partie que nous avons implemente.
– Un programme de commande d’exemple (ecrit en KRL) qui est en attente d’ordre de deplacement
ou d’action sur le robot (kuka api.src 5 Ko). Celui-ci est concu pour offrir les fonctionnalites de base
(deplacements du bras, ouverture/fermeture de la pince, changement de base et changement de vitesse).
Le serveur n’est disponible que pour Windows r©95 car comme IMERIR n’envisage pas de mettre a jour
le systeme qui tourne sur Kuka, tout au long du cycle de vie du robot, et de notre programme, nous
n’aurons que Windows r©95 a utiliser.
4.1.3 Le client
Le client se compose de :
– un kit de developpement. C’est une librairie (statique) qui implemente les fonctions de l’API, et un
fichier d’en-tete contenant la declaration des fonctions de l’API.
– un programme de demonstration qui permet de voir comment implementer la librairie (voir pour cela
les sources et la documentation).
Bien sur le client est disponible sous forme de sources mais egalement sous forme binaire pour differents
systemes :
Linux La compilation a ete faite avec gcc 3.2.2. Les binaires fonctionnent sur Nestor (le serveur d’IME-
RIR)
28
4 Realisation
Windows r© La compilation a ete faite avec VC++6 sous 2000. Les binaires fonctionnent sur Windows r©2000.
4.1.4 Partie commune
La figure 11 page 25 evoque la presence d’un fichier “kuka.x” se trouvant entre le serveur et le client. Ce
fichier est une specification d’interface qui declare les fonctions qui vont etre exportees sur le reseau grace
au mecanisme des RPCs. Nos fonctions prennent en parametre une seule variable de type kukaVar_t. Ce
type est une structure (kukaVar_s) etudie pour etre “multiusage” : nous nous en servons pour recuperer
les valeurs des variables du programme de commande ou pour faire remonter des erreurs. Nous allons
expliquer chaque role dans les paragraphes suivants.
La structure kukaVar_s
Cette structure a ete creee pour pouvoir manipuler des variables du programme de commande (ecrit en
KRL) dans un programme client (ecrit en c). Elle se decompose comme suit :
Nom Le nom de la variable est une chaıne de caractere qui correspond au nom de la variable dans le
programme de commande.
Valeur La valeur de la variable qui est une structure avec :
Type Un discriminant permettant de differencier le type de la variable ( booleen, reel, entier, etc.).
Union de valeur La valeur de la variable dont le type depend du discriminant.
Traitement des erreurs
Nous avons besoin de recuperer les erreurs pour :
1. faciliter le debogage,
2. informer l’utilisateur de la cause de ses problemes,
3. laisser la possibilite de retablir une situation stable en fonction des types d’erreur retournes.
Afin de satisfaire ces conditions il fallait un rapport d’erreur complet avec
1. le niveau ou s’est produit l’erreur,
2. un message explicite qui decrit l’erreur,
3. un code lie a ce message.
Nous avons donc mis en place une variable qui contiendrait ces informations et qui serait mise a jour
des qu’une erreur survient. Nous allons maintenant, grace a la figure 12, decrire le systeme de gestion
29
Rapport du stage Kuka
Fig. 12 – Propagation des erreurs : exemple de la fonction “initialize(...)”.
d’erreur. Lorsque nous appelons la fonction initialize(...) par exemple, nous passons a travers toutes
les couches du systeme. Lorsque les fonctions se terminent, elles peuvent avoir :
reussi auquel cas aucun message d’erreur n’est genere.
echoue et dans ce cas un message d’erreur est genere. Nous avons alors comme moyen de localisation de
l’erreur, une constante qui est enregistree dans la variable d’erreur. Cette constante est
KUKA_E si l’erreur vient d’un probleme d’execution du programme de commande qui tourne sur
Kuka (voir partie 3.4.2 page 21 pour plus de details sur le programme de commande).
CROSS_E si l’erreur est provoquee par OLE. C’est a dire au niveau du composant crosscommexe.
RPC_E si l’erreur vient d’un probleme de communication entre le client et le serveur c’est a dire au
niveau des RPCs.
API_E si l’erreur est generee au niveau de l’API.
Grace a ce systeme nous avons un rapport d’erreurs qui permet de les localiser et de savoir pourquoi elles
sont apparues.
4.2 Les tests
Cette partie presente la forme des tests que nous avons fait subir a la “kuka api”.
30
4 Realisation
4.2.1 Tests unitaires
Comme cela est decrit dans la partie 3.4.4 page 23, le produit se decompose en plusieurs couches. Pour
chacune d’elle nous avons fait des tests unitaires.
Niveau du composant “crosscommexe” Lors de nos recherches nous avions developpe un programme
qui permet de tester les fonctions du cross. Lors des tests, ce programme nous a servi a tester les
methodes qui invoquent le crosscommexe.
Niveau de la communication par RPC De la meme maniere des programmes minimalistes servent
de banc d’essai. Ils nous servent a verifier que les structures de donnees passent bien dans les
parametres des fonctions, que ces dernieres renvoient bien le resultat escompte.
Niveau de l’interface utilisateur finale La, il suffit d’encapsuler les appels au fonctions distantes.
Cette partie sera testee lors de l’integration.
Ainsi, avant d’etre assemble chaque couche fonctionnait independamment.
4.2.2 Tests d’integration
Comme un composant, chaque couche est utilisable via une interface. Chaque interface ne devrait pas
avoir a etre modifiee. De cette maniere nous pourrons re-implementer ou corriger les bugs de chaque
couches sans toucher aux autres.
Dans la premiere version de la “kuka api”, nous avions peu de fonctions a tester a savoir :
– initialize() et uninitialize() qui permettent d’ouvrir et de fermer la session de travail avec Kuka,
– setVar() et getVar() qui permettent d’ajuster les valeurs des variables du robot,
– getError() qui permet de recuperer le rapport d’erreur. Cette derniere etait fiable avant la phase de
test.
Nous avons donc limite nos tests aux quatre premieres fonctions.
Les criteres de validation etaient simples :
– initialize() et uninitialize() sont :
validees si elles permettent de communiquer avec Kuka, ou si elles generent un rapport d’erreur,
rejetees si aucune liaison n’est etablie et aucun rapport d’erreur n’est genere.
– setVar() ou getVar() sont :
validees si elle modifie (respectivement lit) la variable passee en parametre, ou si elles generent un
rapport d’erreur,
rejetees si elles n’affectent pas la variable passee en parametre et aucun rapport d’erreur n’est genere.
31
Rapport du stage Kuka
Pour verifier si les variables sont convenablement lues ou ecrites, nous disposons d’un outil dans l’in-
terface utilisateur du robot (le kukaBOF) qui permet visualiser la valeur des variables.
Les conditions de test etaient : le robot Kuka relie a un client sous Linux via Tcp/Ip.
La configuration du robot etait la suivante :
– KR C V4.1.4 SP02
– IHM (kukaBOF) V3.3.59 B20
– Systeme de base KS V4.59
– Systeme VxWin (avec Windows r©95 version 4.0.950)
La configuration du client Linux etait la suivante :
– Systeme Slackware 9
– Compilateur gcc 3.2.2
Le code etant totalement portable au niveau du client, aucun test d’integration n’a ete fait sous Windows r©.
Par contre, comme nous allons le voir dans la section suivante, nous y effectuerons certains tests finaux.
4.3 Le produit, aujourd’hui
La “kuka api” en est actuellement a sa version 0.0.5. Elle repond entierement au besoin initial a savoir :
“offrir la possibilite de commander le robot Kuka via une interface en c depuis le reseau de l’ecole”.
Toutes les fonctions proposees ont ete testees, et fonctionnent a 100%.
Seulement deux d’entre elles sont mal documentees et ne figurent pas dans les exemples d’utilisation
(load/unloadModule(). Cela est du au fait que ces fonctions sont des exemples pour le developpeur qui
desire en re-implementer d’autres.
Le serveur et le client sont disponibles en telechargement sur le site internet sous forme de binaire ou de
sources. La documentation servira de support pour l’utilisateur et les eventuels developpeurs futurs.
Enfin des programmes de test ont ete realises, ainsi que des demonstrations. Avant de les decrire, nous
allons faire un bref descriptif des performances du produit.
4.3.1 Performances et limitation
Les tests que nous avons fait permettaient de valider le fonctionnement du produit. Et bien que aucun
test de performance ne fut fait, nous connaissons les limites de notre produit.
Vitesse Dans un premier temps l’objectif n’etait pas d’obtenir un produit performant en terme de vitesse
32
4 Realisation
de transfert des informations. Il etait plus important d’atteindre l’objectif principal : communiquer
avec Kuka a distance. Nous ne garantissons donc aucune performance a ce niveau.
Temps reel Bien entendu, le systeme n’implemente pas, et n’implementera jamais, le temps reel.
Ceci est du au fait que la transmission des informations passe par une couche qui fait appel a des
fonctions Windows r© (OLE) qui ne sera jamais temps reel.
Connections multiples Il est possible de connecter plusieurs clients au serveur. Aucun test n’a ete fait
pour evaluer la limite. Et aucune prediction du comportement du robot n’a ete faite dans cette
situation. Ceci est du au fait qu’il ne devrait y avoir qu’un seul client a la fois qui se connecte.
4.3.2 Le jeux de dame
Cette demonstration est tres simple puisqu’elle ne consiste qu’a deplacer des pions sur un plateau de
dame. L’interface utilisateur se presente en ligne de commande. Le programme nous demande successi-
vement ou il doit prendre un pion et ou il doit le poser. Les coordonnees sont rentrees au clavier sous la
forme de deux entiers (numero de case horizontal et vertical : 3 4 par exemple).
Le but de cette demonstration est de decrire a l’utilisateur comment implementer une fonction qui trans-
forme des coordonnees comprehensibles par un algorithme d’IA (index sur un plateau) en des coordonnees
comprehensibles par un robot (cartesiens). La marche a suivre est decrite dans le manuel de l’utilisateur
disponible sur le site du projet :
http ://www.imerir.com/kuka/kukaApi/doc/kuka api man util.pdf
4.3.3 Le jeux de morpion
Cette demonstration est plus avancee. Elle permet de jouer au morpion avec Kuka sans interface homme-
machine. L’interface est remplacee par le plateau de jeux.
Le plateau se presente sous la forme d’un fond blanc sur lequel les 9 cases (3x3) sont delimitees par des
lignes noires. Le jeux se deroule de la maniere suivante :
1. L’utilisateur (vous) joue un pion noir sur une des 9 cases du morpion.
2. L’utilisateur appuie ensuite sur un bouton pour dire a l’ordinateur que c’est a son tour.
3. L’ordinateur prend une image du jeux, l’analyse et calcule son coup (donc des algorithmes de
visionique et d’IA sont implementes).
33
Rapport du stage Kuka
4. L’ordinateur joue : il prend un pion dans sa reserve et il le pose sur le jeu (c’est ici que la “kuka api”
est utilisee).
5. L’ordinateur informe l’utilisateur que c’est son tour et le jeu recommence jusqu’a ce qu’il y ai trois
pions alignes.
Lorsque la partie est finie, le robot range les pions. Nous avons mis a votre disposition les sources de ce
programme sur internet :
http ://www.imerir.com/kuka/kukaApi/src/morpion.tar.gz
Une video de demonstration est egalement disponible sur le site :
http ://www.imerir.com/kuka/kukaApi/images/morpion.mpeg
4.4 Le produit, demain
Le produit a ete concu avec peu de contraintes :
– Nous ne mettrons pas a jour le systeme de Kuka : donc il n’y aura pas de Windows r©2000 ou XP au
niveau du serveur, on reste sous 95.
– Nous n’acheterons pas de deuxieme robot et de toute facon le PC de l’armoire de commande est
mono-processeur : donc il n’y aura pas de multi-tache.
– Le robot sera mono-tache (il n’ecoute qu’un ordre a la fois) : donc gerer une seule connexion suffit.
Mise a part le deuxieme point qui implique des limitations materielles nous pouvons envisager de faire
evoluer le produit pour l’adapter.
Imaginons que nous voulions que le robot joue simultanement sur deux plateaux de morpions (voir
partie 4.3.3 page 33) il faudrait que nous gerions les ordres provenant de deux clients. Ceci est faisable
avec l’implementation actuelle de l’API mais n’a pas ete teste. Une des evolutions serait donc de tester
cette possibilite.
Il semble aussi que le serveur compile bien sous 2000. Une autre evolution serait alors de tester son
execution sous ce systeme et sous XP.
Mais l’implementation actuelle est deja assez souple pour envisager un grand nombre d’applications dont
votre imagination sera la seule limite.
34
5 Gestion du projet
5 Gestion du projet
L’idee du projet est lancee par MlleEckert et Eric Salvat debut 2003. Un stage de 4 mois est donc propose
au sein d’I.M.E.R.I.R. pour etudier, concevoir, realiser et tester une solution. Le stage Kuka commence
le 1erJuin.
5.1 Methodologie et planning
Au commencement nous ne savions pas si une solution existait. Donc, durant une periode que nous
avions fixee a un mois, nous avions decide de faire des recherches sur l’existant, et sur ce qu’il serait
possible de faire. Une reunion hebdomadaire servait a faire le point sur l’avancement de l’etude. Pour
chaque nouvelle solution que nous avons rencontre nous avons ecrit une fiche synoptique. Ces fiches sont
disponibles sur le compte du projet (leur chemin d’acces est precise dans la partie 3.3.5 a la page 19).
Au terme de ces investigations, nous avions assez de choix pour pouvoir comparer les solutions qui se
presentaient a nous et elire la mieux adaptee (voir le fichier ‘communication.pdf” et “comparatif.pdf” en
annexe partie 7.1 et partie 7.5).
L’architecture globale de chaque solution est tres similaire, a fait ses preuves, et afin de ne pas refaire ce
qui a deja ete fait, nous avons decide de calquer notre solution sur l’existant. C’est pour cela que la phase
de conception est inexistante.
Puis nous avons procede a la phase de realisation qui nous a amene a produire la version 0.0.1 du
produit.
Enfin, des phases de debugage/tests se sont succedees pour chaque sortie des nouvelles versions.
Pour faciliter le suivi dans la progression du travail, un compte rendu personnel hebdomadaire resumait
ce qui avait ete fait et fixait ce qu’il restait a faire. Ces fiches sont disponibles au format sxw (traitement
de texte OpenOffice) dans le repertoire du projet :
nestor:///Projets/Stages/Kuka/documents/organisation/sources/
La facon dont le projet fut menee peut sembler hasardeuse. Ceci s’explique pour differentes raisons :
– Le materiel etait a notre entiere disposition et donc nous n’avions pas de contraintes materielles,
– l’equipe de travail se composait d’une seule personne donc pas de contraintes humaines,
– et enfin pas de contraintes de temps liee aux deux precedentes (la seule contrainte de temps etait
35
Rapport du stage Kuka
la duree du stage a savoir 4 mois).
La figure 13 presente le planning du projet pendant la duree du stage (1erjuin au 31 septembre 2003).
Nous considerons que les mois font 4 semaines (sauf celui de juin qui en compte 5), que les semaines font
Fig. 13 – Planning
5 jours, et que les jours font 8h00 environ. Il y eu une semaine de repos en aout. La convention de stage
se termine le 31 septembre 2003, mais n’empeche pas le projet de continuer.
Note : Dans un soucis de simplification, le planning est decoupe en semaines. Or certaines semaines
comportent 3 ou 4 taches simultanees. L’equipe de travail etant composee d’une seule personne (voir
partie 5.2), cela semble irrealiste. Ceci s’explique par le fait que les taches se sont reparties sur les jours
de la semaine en question.
5.2 Ressources
Pour mener a bien la mission, l’equipe est composee des deux tuteurs de stages et du stagiaire (moi-meme).
Nous beneficions des locaux de l’ecole ainsi que de son personnel.
5.2.1 Ressources materielles
Nous avions a notre disposition le robot Kuka qui etait indispensable a la realisation de ce stage. Et du
fait des vacances scolaires, nous avons pu l’utiliser a cent pour cent du temps qui nous etait imparti. Nous
avions aussi deux PCs : un sous Windows r© (2000) et un sous Linux (Slackware 9.0).
36
5 Gestion du projet
Financierement, il etait prevu qu’un investissement serait necessaire. La solution que nous avons finale-
ment choisie ne nous a rien coutee, si ce n’est que le temps passe a la developper. Ceci est du au fait que
l’ecole disposait deja des licences des logiciels qui ont permis de developper sous Windows r©, et que ceux
utilises pour Linux sont libres de droit.
5.2.2 Ressources humaines
Une grosse partie de l’etude preliminaire n’aurait pu etre menee sans l’assistance du personnel de Kuka.
En particulier :
– Didier SUTTY (Technicien) pour
– les problemes lies a la programmation du robot en KRL,
– les questions se rapportant a la liaison serie (voir partie 3.3.1 page 16).
– Emmanuel BERGEROT (Commercial sud-ouest France) pour
– ses conseils sur le choix de l’OPC,
– sa contribution a eclaircir les problemes lies a la liaison serie.
– Jean-Louis RENOUX (Ingenieur Developpeur) pour
– le developpement de la solution Opc ProConOs.
– Laurent HALTER (Ingenieur Developpeur) pour
– les questions se rapportant a la liaison serie (voir partie 3.3.1 page 16).
D’autre part, nous avons sollicite Michel JUANOLA (responsable technique a IMERIR) pour les pro-
blemes d’ordre technique (installation reseau, commande de materiel, etc.).
37
Rapport du stage Kuka
6 Conclusion
Le produit final ayant ete approuve par les tuteurs du stage, nous considerons que la premiere etape est
accomplie avec succes.
Mais ce produit doit encore faire ses preuves aupres des etudiants qui l’utiliseront lors des TPs. En effet,
cette mise en situation sera le test qui permettra de mettre en evidence :
– la facilite d’utilisation de l’interface,
– sa robustesse.
Enfin si la “kuka api” obtient l’approbation de ses utilisateurs, ces derniers trouveront certainement
interessant de reprendre le projet afin de lui ajouter des fonctionnalites supplementaires, et, pourquoi
pas, de l’adapter a leur contexte (industriel par exemple) afin d’etendre sa communaute d’utilisateurs.
Pour cela nous comptons sur votre imagination, vous, a qui nous remettons avec la nostalgie de ce projet
qui nous aura tant tenu a coeur :
la “kuka api”
38
7 Annexes
7 Annexes
Voici quelques documents qui pourront contribuer a une meilleure comprehension des notions abordees
dans ce rapport. La plus part d’entre eux etait destinee a un usage interne a l’equipe, ce qui explique le
manque de mise en forme.
Annexe 39
Rapport du stage Kuka
7.1 Annexe 1 : communication.pdf
Fichiers pdf :
http ://www.imerir.com/kuka/kukaApi/doc/technique/communication.pdf
nestor:///Projets/Stages/Kuka/documents/technique/communication.pdf
Fichiers sources :
nestor:///Projets/Stages/Kuka/documents/technique/sources/communication.sxw
40 Annexe
Note : ce documentestdépasséet bienqu'il fut utile dansle passé,il ne justifie pasnoschoix.Pour cela voir le documentcomparatif.pdfqui se situe dans le répertoiredes documentstechnique du projet Kuka).
Table des matières
Introduction...................................................................................................................................................................2Serveur Opc :................................................................................................................................................................3Serveur sur vxWorks....................................................................................................................................................4Dialogue par le port série:............................................................................................................................................5Communication via un bus..........................................................................................................................................6
1 / 6
Stage : KukaEtudiant : Paul ChaventPériode : du 2 au 6 juin, et du 10 au 13 juin 2003Thème : Recherche sur les différents moyens d'accéder aux commandes du robot Kuka.
7 Annexes
Annexe 41
Introduction
Ce document apporte des éléments de comparaisonentre les différents systèmesdecommunicationqui s'offraient à nous pour commanderKuka à distance,dansun languagestandard.Les recherchesont été menéessur internet. Malheureusementla « communautéKuka » estessentiellementcomposéedeprofessionnels.Donc il n'existaitpasdemailling-list où soumettrenos questions, et très peu d'exemples de code.Alors j'ai téléphonéchez Kuka Francepour leur demanderde me mettre en relation aveccertainespersonnesque Martine m'avait conseillé de joindre, et personnen'était joignabledirectementet impossibled'obtenirleur numérodeportable.J'aidoncpris contactaveceuxparmail : seul Didier Sutty m'a répondu.J'ai aussi trouvé un projet, menéen Allemagne,correspondantà ce que nous voulons faire(commandederobotdistanteparplusieursclients,avecun langagedeprogrammationstandard:le c).Enfin les cds de documentationde Kuka m'ont permisde me familiariser avecl'ensembledusystème robot/armoire de commande.Plustard,Jean-LouisRenouxet EmmanuelBergerotnousont apportéleur soutientet nousontproposé la solution opc de ProConOs.
En conclusion je retiendrai trois solutions : � utiliser un opcServeur.� utiliser vxWorks via tcp/ip.� utiliser le port série.
le tableau suivant récapitule les avantages et inconvénients de chacun.
solution portable économique documenté simple * personnalisable temps réel libre
opc - - 0 0 - -
port série + + + + + 0 +
vxWorks / ethernet + 0 - - + + 0*nombre de modules, environnement de programmation à disposition...
Mais au fil de mesrecherchesil s'estavéréquesuivre la pistedu projet déjàexistantseraitlasolution la plus facile à réaliser.Les pages qui suivent sont une description succincte de chaque solution.
2 / 6
Rapport du stage Kuka
42 Annexe
Serveur Opc :
Description :
Cette solution consiste à partager les variables d'environnement du KRC.Ce dernier est équipéd'une interface logicielle accessiblepar un réseautcp/ip (Microsoft).D'ailleurs l'accèsaux donnéespeutse faire de manièresécuriséeen utilisant un contrôleurdedomaine NT. Il faut alors spécifier un niveau (demo, user, expert, admin) pour chaqueutilisateur en modifiant certaines valeurs de la base de registre.Ensuitegrâceà un fichier de configuration(opcconfig.csv)on définit les variablesà partager,quel sera leur mode d'accès, leur niveau de sécurité, leur type, etc.Enfin grâceaux environnementsde développementMicrosoft, on peut réaliserune interfacepour interagir à distance avec les variables du KRC comme si elles étaient en local.
A noter qu'il existe deux opcs :-OPCKukapermetl'utilisation de40 variables. En fait , l'opcpeutavoirunevueetmodifier lesvariablesglobalesqu'utilise le KRL déclaréespar exempledansle $config.dat.Cesvariablesdoivent êtres déclarées aussi dans un fichier .csv qu'utilise OPC.-OPCstandardfonctionnantavecun soft intermédiaire"ProConOs-Multiprog"(voir les PLC)qui estdirectementun automateprogrammabledanslequelunepasserellesousla forme d'E/Sou grouped'E/S existe. La déclarationet l'appel au driver pour cette liaison se fait dansleIOSYS.ini.On utilise alorsOPCpour lesvariablesqui serontutiliséessuruneinterfaceVB parexemple. Ce soft n'est pas fournis par Kuka.
Avantages/Inconvénients :
� Avantages :� grande simplicité d'utilisation
� inconvénient :� les outils de développement, les clients/serveurs opc sont payants.� forte dépendance au système Windows (bien que des solutions Linux existent)� protocoledéjàenplaceet doncmoinsdepossibilitésdepersonnaliserles typesd'échanges
en fonction du besoin.
Documentation :� opc_server.pdf (sur le cd de doc de Kuka).� mail de Didier Sutty du 05/06/2003.
Résumé :
3 / 6
KRC
vxWorks
Windows
opcServeurtcp/ip shm
Windows
opcClient
Windows
opcClienttcp/ip
7 Annexes
Annexe 43
Serveur sur vxWorks
Description :
Cette solution consisterait à dialoguer avec le système vxWork directement via la liaison tcp/ip.Le servicequi fournirait la connectionn'existepasactuellement.Il faut donc programmerunserveurquel'on lancerasurVxWorks. Il faudraensuitecherchercommentaccéderauxdonnéeset aux ordres pour que le serveur les mettent à disposition.Enfin d'unpoint devuematériel: il sembleraitqu'il faille unesecondecarteréseau(voir le docvxWinRT page 5) que vxWorks pilotera.
Avantages/Inconvénients :
� Avantages :� personnalisation des services disponibles.� plus proche du système temps réel donc de meilleures performances à priori.� indépendant de Windows.
� Inconvénients :� système vxWorks =>
� apprentissage de la programmation temps réel� outils de développement (tornado par exemple) payants ou utilisation de cross compiler.� ligne de commande inaccessible depuis vxWin.
� mise en place d'un protocole de dialogue
Résumé :
4 / 6
KRC
vxWorksWindows
tcp/ipethernetdriver
moduleServeur
tcp/ipethernetdriver
moduleClient
modulede commandekuka
Linuxtcp/ipethernetdriver
moduleClient
tcp/ip
Rapport du stage Kuka
44 Annexe
Dialogue par le port série:
Description :
Cette solution nécessite une machine qui fasse office de serveur.Cettemachinerécupèrelesrequêtesdesclientsvia uneconnectionstcp/ip (utilisationdesrpc?),et lestransmetauKRC parsonport série.Le KRC étaitalorsentrain d'exécuterun programmeen KRL qui consistaità boucler indéfinimenten attendantune interruption.La réceptiondedonnéessur le port série déclencheune interruption et permetau programmed'exécuterlacommandeCREAD pour lire ces données.Suivant un protocoleque nous auronsétabli, lacommandeserainterprétéen commandeKRL, puis exécutée.Enfin on pourra renvoyerunfeedback grâce à la commande CWRITE.
Avantages/Inconvénients :
� Avantages :� celaa déjàétéfait récementpar uneuniversitéallemande(avecunegestioncomplexede
temps réel et de niveau d'utilisateur) et nous pouvons s'inspirer de cet exemple concret.� nous disposonsde la documentationdes deux seulsélémentsdont nous dépendons: le
protocole3964r (dialoguesur le port série) et le Krl (languagede programmationdurobot).
� nous pourrons développerdes clients dans de multiples langagessur de multiplesplateformes
� Inconvénients :� beaucoup de modules à programmer (client, serveur, et programme kuka)� deux protocoles sont à définir (client<->serveur et serveur <->krc)
Documentation :
� site du projet allemand http://pdv.cs.tu-berlin.de/forschung/KUKA_PJ-WS00/index.html� document CREAD/CWRITE� Didier Sutty a proposéd'envoyerun cd d'exemplede codeet de documentationà ce sujet
dans un mail du 10/06/2003.
Résumé :
5 / 6
KRC
vxWorks
Windows
krlcrossrs2323964rtcp/ip shm
Linux Windowsrs2323964r
tcp/ipethernet
Linuxtcp/ipethernet
Windowstcp/ipethernet
7 Annexes
Annexe 45
Communication via un bus
Description :
Cette solution consiste à envoyer les ordres à la carte multifonction (mfc) par un bus (can, ...).Nous configurons l'affectation des commandesphysiques(provenantdu bus) aux signauxd'entréesortiedu KRL grâceaumenuconfigurer->e/S->automatiqueexterne.Chaquefois qu'unsignal est reçu on passedansun branchementconditionnelau niveau du KRL (cell.src).Lesignal reçut correspond à un numéro de programme à appeler.C'estle mêmesystèmequecelui utilisé actuellementavecles boutonsdont on a « mappé » lesignal sur les variables $IN[1...20].
Avantages/Inconvénients :
Inconvénient :� pas de passage de paramètres possibles
Documentation :
� Système E/S� Automatique externe� DeviceNet (bus CAN)
6 / 6
Rapport du stage Kuka
46 Annexe
7 Annexes
7.2 Annexe 2 : comdcom.pdf
Fichiers pdf :
http ://www.imerir.com/kuka/kukaApi/doc/technique/comdcom.pdf
nestor:///Projets/Stages/Kuka/documents/technique/comdcom.pdf
Fichiers sources :
nestor:///Projets/Stages/Kuka/documents/technique/sources/comdcom.sxw
Annexe 47
L'utilisation d'un serveur OPC pour l'interface de Kuka requiert une bonne compréhension de la
technologie COM/DCOM de Microsoft. Dans ce but, certaines expériences ont été menées afin
de se familiariser avec le fonctionnement d'un client COM/DCOM.
Ce document explique les notions théoriques qui ont été nécessaire de maîtriser pour mener les
expériences ainsi qu'une description du protocole opératoire.
Table des matières
Introduction...................................................................................................................................................................2Les composants.............................................................................................................................................................2Les interfaces................................................................................................................................................................3Le modèle client /serveur.............................................................................................................................................4Le crossComm..............................................................................................................................................................5
Description...............................................................................................................................................................5Exemple d'utilisation...............................................................................................................................................5
Matériel...............................................................................................................................................................5Démarche............................................................................................................................................................6Observations........................................................................................................................................................7
Conclusion....................................................................................................................................................................8Glossaire........................................................................................................................................................................8References.....................................................................................................................................................................8
1 / 8
Stage : KukaÉtudiant : Paul ChaventPériode : du 23 au 27 juin 2003Thème : Expériences sur com/dcom.
Rapport du stage Kuka
48 Annexe
Introduction
Grâce aux objets OLE (Object Linking and Embending) il est possible d'incorporer des
documentde type Excel dansun documentWord. Cesdeux applicationscommuniquentdonc
selonun standardqui spécifieles interfacesminimum que doiventavoir cesobjetsOLE pour
êtreréutilisables.Cestandardc'estCOM. Pourpermettrela distributiondesobjetssur le réseau
il y eu la spécification DCOM.
Pour des raisons de simplicité nous pouvons confondre COM, DCOM, OLE, ActiveX®
(fichiers .ocx).
Les composants
Un composant DCOM est une classe qui implémente plusieurs interfaces :
� les interfaces imposées par la spécification DCOM.
� les interfaces spécifiques aux services du composant.
Le schema ci-dessus est un exemple d'un composant et de ses interfaces :
� IUnknow est l'interface de base des composants COM.
� IToto est une interface spécifique aux services que rendent les composants CToto.
Les composantsdisponiblessontenregistrésdansla basede registre.Ils sont identifiéspar un
IDentifiant Global Unique (CLSID pour CLaSsID).Cet identifiant se présentesousla forme
d'un "nombre". Il est possiblede parcourir l'ensembledes composantset de leurs interfaces
grâce à l'outil OleView de Microsoft (\\KUKA\D\MSTOOLS\BIN\OLEVIEW.EXE).
2 / 8
CTotoIUnknow
IToto
7 Annexes
Annexe 49
Les interfaces
Pour utiliser un composant,nousdevonsle faire à traversune/desinterface(s).Les interfaces
sont des groupes de méthodes.
Le schemaci-dessusillustre un composantdont une interfaceserait IToto dont les methodes
seraient methode1, methode2, etc.
Tousles composantsimplémententl'interfaceIUnknow. C'estgrâceà cetteinterfacequenous
pouvonsaccéderauxautresen invoquantla méthodeQueryInteface.Cetteméthoderetourneun
pointeur vers l'interface demandée si l'objet l'implémente, nul sinon.
Nouspouvonsalorsmanipulerl'instancedu composantparsoninterface.Parexemplesi pIToto
estun pointeursur l'interfaceIToto du composantCToto, nouspouvonsinvoquerla méthode
methode1 comme suit :
3 / 8
pIToto->methode1();
@ methode1
@ methode2
@ methode3
Methode1(){...}
Methode2(){...}
Methode3(){...}
Table des methodes(VirtualTable)
Implémentation des methodes
@Interface IToto
Rapport du stage Kuka
50 Annexe
Le modèle client /serveur.
Le client est la machinequi utilise l'objet à travers son interface, le serveurest celle qui
implémente le code de l'objet.
L'implémentationdu codede l'objet peutêtresousforme de dll (qui sera"linkée" à l'exécution
du client). Le serveur est dit in-process.
Quandl'implémentationdu codedel'objet estsousformed'exécutable,il estdit out-process.Le
processus serveur peut alors être local ou distant.
Le but du projet de cette annéeest de développerun client distant.Donc il faut obtenir un
serveurout-processdistant.Le crossCommest un serveurout-process,mais nousne sommes
pas encoreparvenuà y accéderà distance.Il sembleraitqu'il faille faire l'acquisition du
crossCommDistant.
4 / 8
7 Annexes
Annexe 51
Le crossComm
Description
Le crossest le lien entrele systèmetemps-réelet l'interfaceutilisateur(Windows). Il permet
d'accéderaux fonctionsqui permettentdevoir ou demodifier desvariables,etc.Nouspouvons
en voir les caractéristiques grâce à OLEView :
Dansnotre situationl'interfacequi nousintéresseest la "CrossCommand".Elle regroupedes
méthodes telles que : � Init� ConnectToCross� ShowVar� SetVar� ServerOff� ...
Exemple d'utilisation
Matériel
Il est nécessairede mener l'expériencesur le PC de l'armoire de commandepuisquenous
n'avons pas encore trouvés le moyen d'appeler les fonctions de l'interface à distance.
5 / 8
Composant
Interfaces
Implémentation locale out-process
CLSID(ProgID=CrossCommEXE.CrossCommand)
Rapport du stage Kuka
52 Annexe
Démarche
Nous allons commenter les sources de l'exemple
//nestor/Projets/Stages/Kuka/programmes/testCrossCommLocal/test_crosscomm
� Nousdevons,avanttout, inclure le fichier décrivantl'interfacedu crosscomm.Ce fichier est
généré depuis le fichier idl crosscommexe.idl grâce à la commande
midl /header crosscommexe.h crosscommexe.idl
Ce fichier idl est récupéré grâce à l'utilitaire oleViewer.
� Cette commandesert à initialiser OLE. Elle appelle la commandeCoInitialize qui, elle,
initialise COM.
� ceci sert à récupérerun pointeur(pIDispatch)vers l'interfacede type _CrossCommanddu
serveur CrossCommandEXE.
� ceci permetd'initialiser le crosscomm.L'interfaceIDispatchpasséeen paramètren'estpas
encoresure.Nousavonsessayédepasserenparametreuneinterfacedu Cross.OLEServer,du
CrossCommEXE.CrossCommandainsi qu'uneinterfacenulle : cela fonctionnedanstousles
cas.
6 / 8
#include "crosscommexe.h"
OleInitialize(0);
CoCreateInstance(CLSID_CrossCommand,NULL,CLSCTX_LOCAL_SERVER,IID__CrossCommand,(void**)&cross);
cross->Init(&pIDispatch);
7 Annexes
Annexe 53
� Cesméthodesnouspermettentde seconnecterau cross.Le Secondparamètredela méthode
ConnectToCrossest un flag qui permetd'indiquersi les échangessont asynchrone(-1)ou
synchrone (0). Cela signifie que ...
� Ceciestun exempledela façond'utiliserl'interface_CrossCommanddu crosscommandEXE.
Cette méthoderetournedanssResult la valeur de la variable, et dansShowVarResultle
résultat de l'appel de la méthode. Pour avoir un aperçu des variables disponibles voir le fichier
//Kuka/c/krc/roboter/krc/r1/system/$config.dat.
� Enfin, les méthodeset fonctionspermettantde fermer les connectionset libérer la mémoire
proprement.
Observations
Nousavonsen retourde la fonction ShowVardesvaleursde variablescorrespondantesà leur
état actuel (vérifié grâce au menu visualiser->variabes->unitaire du BOF).
Le déroulementdesactionsse fait sanserreursdepuisl'initialisation jusqu'àla libération des
ressources.
7 / 8
BSTR sConnectName=::SysAllocString(L"test");VARIANT __RPC_FAR returnValue;cross->ConnectToCross(sConnectName,0,&returnValue);
VARIANT_BOOL isConnected;cross->get_CrossIsConnected(&isConnected);
_bstr_t sVariableName(varName);BSTR sResult = ::SysAllocStringLen(NULL,120);long vTimeOut=3000; //msVARIANT_BOOL ShowVarResult;cross->ShowVar(sVariableName.copy(),&sResult,&vTimeOut,&ShowVarResult);
cross->ServerOff();cross->Release();OleUninitialize();
Rapport du stage Kuka
54 Annexe
Conclusion
Noussommesparvenuà utiliser les composantsCOMs fournis par kuka (le CrossCommEXE
notamment).Celanousa permisd'avoiraccèsà uneinterfacenouspermettantd'utiliser le robot
commenousle faisionsavecle BOF (et le KRL). La prochaineétapeestdemettreenplaceun
accèsà distance.Or celasembleimpossibleavecles composantsde sériede kuka,notamentà
causedesrestrictionsqu'imposeun anciensystèmecommeWindows95(qui nebénificieplusdu
support de Microsoft). Nous devrons donc développer un système de communication à travers le
réseau. Pour cela deux solutions s'offrent à nous :
� Dessolutionsdebasniveau(socket,ou les rpc) qui nousdonnerontuneportabilitéoptimale,
mais qui en contrepartieexigent beaucoupplus de travail (définition des protocolesde
communication etc.), et une maintenance plus difficile.
� Dessolutionsde hautniveau: nousdévelopponsun composantCOM commecelaa étéfait
pour le crosscommdistant. Ces solutions ont l'avantagede nous éviter de spécifier un
protocole de communication,mais rendent plus difficile l'interopérabilitéentre différent
systèmes(selonuneinformationtrouvéesur internet,Windows95sembleincapabledeservir
de serveur pour DCOM, l'experience l'a confirmé jusqu'à présent).
Glossaire
Automation, interfaces IDispatch, OCX, contrôle ActiveX® ou composant ActiveX® :
Ces termesfont référenceà une interface qui permet d'accéderà des méthodesdepuis un
langage de script tel VB (qui ne supportent pas la technologie objet).
IDL (Interface Definition Language) :
C'est une langage permettant de définir les interface des composants COM.
References
Faq DCOM
(http://casteyde.christian.free.fr/objet/DCOM/faq/online/t1.html)
Les specs' de com
(//nestor/Projets/Stages/Kuka/documentation/com_dcom/COM_Spec.pdf)
Les fichiers d'exemple d'un serveur/client opc
(http://www.gefanucautomation.com/opchub/opcsample.asp).
8 / 8
7 Annexes
Annexe 55
Rapport du stage Kuka
7.3 Annexe 3 : opc.pdf
Fichiers pdf :
http ://www.imerir.com/kuka/kukaApi/doc/technique/opc.pdf
nestor:///Projets/Stages/Kuka/documents/technique/opc.pdf
Fichiers sources :
nestor:///Projets/Stages/Kuka/documents/technique/sources/opc.sxw
56 Annexe
Pourla réalisationd'uneinterfaceau robot Kuka, OPCsembleêtre la solutionla plus adaptée.
En effet elle permettradedialogueravecle robotavecdesprogrammesécrit enc(parexemple)
et celavia le réseautcp/ip de l'école.Ce documentsert à décrireOPCafin de se familiariser
avec son fonctionnement de base.
Table des matières
Introduction...................................................................................................................................................................2OPC (Object Linking and Embedding - for Process Control)...................................................................................2les interfaces.................................................................................................................................................................3L implémentation..........................................................................................................................................................4La spécification OPC Data Acces................................................................................................................................5
L'objet Serveur.........................................................................................................................................................5L'objet groupe..........................................................................................................................................................5L'objet item..............................................................................................................................................................6
Conclusion....................................................................................................................................................................7De quoi avons-nous besoins pour mettre en oeuvre cette solution?.....................................................................7Alors comment faire?..............................................................................................................................................7
Glossaire........................................................................................................................................................................8Reférences.....................................................................................................................................................................9
Documentation.........................................................................................................................................................9Opc en général....................................................................................................................................................9Glossaire..............................................................................................................................................................9Exemples.............................................................................................................................................................9
Contacts :..................................................................................................................................................................9
Introduction
Pour faire communiquerdeuxapplicationsà traversun réseau,nousavonsà notredisposition
lesmiddleware.Les middlewaresontdesproduitsqui serventde joint entredeuxapplications.
1 / 9
Stage : KukaÉtudiant : Paul ChaventPériode : du 16 au 18 juin 2003Thème : Étude du système client/serveur OPC.
7 Annexes
Annexe 57
Les deuxgrandsstandardsqui s'offrentà noussontCORBA et DCOM. Cesmodèlesséparent
l'interfaced'un objet de sa mise en oeuvreen utilisant un Languagede Définition d'Interface
(IDL). L'IDL fournit une représentationstandardiséed'un objet, de sesméthodeset de ses
attributs,ce qui nouslaisseindépendantde la plate-formeou du langaged'implémentation.En
utilisant IDL, CORBA et DCOM rendentla programmationdistribuéesimple,permettantaux
développeurs d'utiliser n'importe quel objet éloigné comme si il était local pour l'utilisateur.
OPC (Object Linking and Embedding - for Process Control)
OPC est basé sur la technologie COM/DCOM* de Microsoft.
Les spécifications OPC décrivent les objets COM et leurs interfaces*.
Cesinterfacesregroupentdesméthodeset desévènementsutilisésdansle dialogueentreclients
et serveursOPC.Un client OPC peutseconnecterà n'importequel serveurimplémentantces
interfaces.
2 / 9
Rapport du stage Kuka
58 Annexe
les interfaces
Les interfaces sont décrites par :
� la spécification Commune à tous les serveurs "Common spec"
� la spécification "OPC Data Access (DA) 1.0 - 1.0a – 2.0" (détaillé dans la section IV.)
� la spécification "OPC Alarm & Event (AE) 1.0 1.0a"
� la spécification "OPC Standart Access to historical data (HDA) 1.0. 1.1"
� la spécification "OPC Batch 1.0"
Chaque interface peut être de deux types :
� les interfaces obligatoires (interfaces "custom"):
Un client communiqueavecun serveuren appelantau moins les fonctionsdes interfaces
obligatoires. Les développeurs de serveurs OPC doivent implémenter toutes les
fonctionnalités des interfaces obligatoires dans leur serveur.
� les interfaces optionnelles (interfaces "automation"):
les développeursde serveurOPC peuvent,s'ils le souhaitent,implémenterles interfaces
optionnelles.Quandune interfaceoptionnelleest implémentée,toutesles fonctionsqu'elle
contientdoiventêtre implémentées,mêmesi la fonction retournesimplementE_NOTIMPL.
Le client doit êtredéveloppédesorteànepasutiliser lesinterfacesoptionnellesqui n'existent
pas.
Cesinterfaces, dansla plupartdescas,sont"Wrappés"par un composantDLL. C'està dire
qu'une DLL assurela conversiondes appels Automations vers des appels Custom. la
FondationOPCfournit à sesmembreslessourcesdecetteDLL qui peutêtreutiliséepour le
support des interfaces Automations.
3 / 9
Opc interface:
opcCommonopcSecurity[opcDA][...]
OpcClient(c++ apps)
Interfacecustom
OpcClient(vb apps)
Interfaceautomation
warpper
7 Annexes
Annexe 59
L implémentation
Les serveurs OPC peuvent être implémentés sous deux formes :
� les serveurs OPC In-Process (DLL) :
cesserveurspartagentl'espaced'adressagedel'applicationhôte.Ils nepeuventdoncêtreque
des serveurs locaux. Ces serveurs sont les plus performants.
� Les serveurs OPC Out-Process (EXE) :
cesserveurspeuventêtre locaux ou distants.Les serveursOPC sontcréésgénéralementen
C++, bien qu'il soit, a priori, possible de créer un serveur dans n'importe quel langage.
COM fournis un accès transparent aux serveurs locaux ou distant à travers des objets proxy et stub.
Les serveurs ont un code qui décrit :
� les périphériques et les données auxquels ils accèdent
� le nom des données
� le fonctionnement de l'accès aux ressources (physiques) par le serveur.
4 / 9
Rapport du stage Kuka
60 Annexe
La spécification OPC Data Acces
Un serveur Opc gère différents objets :
� le serveur
� le groupe
� l'item
L'objet Serveur
Il contientdesgroupesOPC.Il permetdecréerun groupe,desupprimerun groupe,d'obtenirle
nom d'un groupe et d'énumérer les groupes.
L'objet groupe
Il contient et organise (de manière logique) les items (indirectement, les données)
Le groupe permet au serveur d'exposer sa base à plat ou de façon hiérarchique.
Il y a deux types de groupes:
� public pour partager les données à plusieurs client
� local pour un client local.
5 / 9
Serveur Groupe
itemsvaleurqualitétimestamp
données physiques@
groupe
Item 10
Item 1n
Groupe hierarchique
Item 00
Item 0n
groupe
Item 20
Item 2n
Groupe flat
Item 0
Item n
7 Annexes
Annexe 61
L'objet item
Il représentela connexionentreles sourcesde donnéesphysiqueset le serveur.Les items ne
sont pasaccessiblesaux client : il n'ont pasd'interfaceexterne.Les clients y accèdentpar le
Groupequi le contient.Chaqueitem estassociéà unevaleur,unequalitéet un timestamp.Les
itemsne sontpasla sourcede données,ce sont justedesconnectionsverselles(un pointeur).
Ces sources peuvent être des bases de données, des cartes ADD-IN, etc.
Les items sont identifiés par leur "nom". Cesnomssont accessiblesau traversde l'interface
"Browse" (voir "Common spec") de l'objet groupe.
/* information à confirmer
Si le serveur est un superviseur les items correspondent aux tags.
Si le serveur est un Automate les items correspondent aux registres (DB).
L'appellation attribuée aux items est alors propre à chaque type de serveur OPC.
*/
6 / 9
Rapport du stage Kuka
62 Annexe
Conclusion
De quoi avons-nous besoins pour mettre en oeuvre cette solution?
� un serveur opc :
� qui nous est vendu par Kuka
� que nousréalisons.Pour celanousauronsaussibesoind'unedescriptionde commentse
fait l'accès aux données de Kuka.
� un client opc que nous réalisons.
Alors comment faire?
Il existeactuellementun opcServeurconcutpar Kuka. Mais commeil ne sortiraqu'en2004il
faudraitenvisagerde construirenotrepropreserveur/clientopc.Ceci nécessiteraitde connaître
l'interfacedescommandesdu robot.Alors je penseque,à avoir cesinformations,il seraitplus
intéressantd'établir notre propre systèmeclient/serveursanstenir comptedes spécifications
d'interfaceopc puisquenous n'avonspasbesoinde pouvoir s'inter-connecterà n'importequel
système opc.
Sinonutiliser le serveuropc ProConOs(voir opc_ProConOs.pdfdansle répertoirde la doc du
projet Kuka).
7 / 9
7 Annexes
Annexe 63
Glossaire
Process Control (commandede processus)est le contrôle automatiqued'un processus,dans
lequel un système informatique est utilisé pour régler les opérations répétitives ou les processus.
COM (ComponentObjectModel) estunearchitecturelogicielle qui permetà desapplications
d'être construitesà partir de composantsbinaires.COM est l'architecturefondamentalequi
forme la basepour desservicesde plus hautniveaude logiciel, commeceuxfournis parOLE.
Les servicesOLE présententde multiplesaspectdesfonctionnalitégénéralementnécessaireau
système,y compris les documentscomposés,des commandescustomisées,de scripts inter-
application, du transfert de données, et d'autres interactions de logiciel.
DCOM (DistributedComponentObjectModel) estun protocolequi permetà descomposants
logiciel de communiquerdirectementau-dessusde la couche réseaud'une façon fiable,
sécurisée,et efficace.Précédemmentappelé"network OLE," DCOM estconçupour l'usageà
traversdestransportsmultiplesde réseau,y comprisl'Internet(HTTP). DCOM estbasésur les
spéc.du OpenSoftwareFoundation'sDCE-RPC et fonctionneavecdesappletsJavaainsi que
des composants d'ActiveX® grâce à leur utilisation du modèle composant d'objet (COM).
COM/DCOM est une spécification indépendante du matériel et du système d'exploitation.
LescontrôlesActiveX® comptentparmi lescomposantsutiliséspar la technologieCOM pour
fournir l'interoperabilitéavecles autrestypesde composantset servicesCOM. Les contrôles
ActiveX sont la troisième version des contrôlesOLE (ocx), fournissantdes améliorations
spécialementconçuespour faciliter la distribution des composantssur des réseauxet pour
fournir l'intégration de commandes dans des navigateurs du Web.
SCADA (SupervisorControl And Data Acquisition) est une catégoried'applicationpour le
"processcontrol", la récupérationdedonnéesentempsréel envuedecontrôlerl'équipementet
les conditions.Les systèmesSCADA incluent des composantslogiciels et le matériels.Le
matérielrécupèreet fournis les donnéesdansun ordinateurqui a le logiciel SCADA installé.
L'ordinateurtraite alors cesdonnéeset les présenteinstantanément.SCADA enregistreaussi
touslesévènementsdansun fichier delog surun disquedur ou lesenvoieversuneimprimante.
8 / 9
Rapport du stage Kuka
64 Annexe
SCADA avertit quand les conditions deviennent dangereuses en sonnant des alarmes.
HMI (Human-machineinterface ) est une interfaceentre l'utilisateur et le systèmematériel
(électro-acoustique,électro-optique,etc.) et une section logique traitant des opérations
fonctionnelles à état.
PLC (ProgrammableLogical Controller)estun dispositif contrôlant diversprocessusd'atelier
de production.
Reférences
Documentation
Opc en général
http://www.opcfoundation.org/Downloads/Overview/
http://www.4ce-industry.com/OPC_INFOS/pourquoi_opc.htm
http://www.opcconnect.com/
Glossaire
http://www.atis.org/tg2k/
http://www.osacbm.org/Documents/Training/TrainingMaterial/TrainingWebsite/glossary.html
(ole, class, class factory, object class, stub, proxy, in-process, (M)IDL, etc.)
Exemples
http://www.gefanucautomation.com/opchub/opcsample.asp (implémentation d'un serveur,
exemple de client, respectant les spec's 1 de Opc)
Contacts :
9 / 9
7 Annexes
Annexe 65
Rapport du stage Kuka
7.4 Annexe 4 : opcproconos.pdf
Fichiers pdf :
http ://www.imerir.com/kuka/kukaApi/doc/technique/opcproconos.pdf
nestor:///Projets/Stages/Kuka/documents/technique/opcproconos.pdf
Fichiers sources :
nestor:///Projets/Stages/Kuka/documents/technique/sources/opcproconos.sxw
66 Annexe
La solution OPC de Kuka est disponible mais instable. Il développent une nouvelle version qui
sera disponible pour 2004. Le commercial de Kuka (Emmanuel Bergerot) nous propose alors
une solution alterantive : ProConOs. Dans un premier temps, pour les tests , la solution ne nous
coute rien. A terme elle ne devrait pas revenir à plus de 100 Euros.
Table des matièresDescription....................................................................................................................................................................2Schéma récapitulatif.....................................................................................................................................................3Exemple.........................................................................................................................................................................3Contacts.........................................................................................................................................................................3Glossaire........................................................................................................................................................................4Références.....................................................................................................................................................................4
1 / 4
Stage : KukaEtudiant : Paul ChaventPériode : le 02 Juillet 2003Thème : nouvelle solution : opc serveur au dessus de ProConOs.
7 Annexes
Annexe 67
DescriptionLa solution se décompose en trois parties :
� Le serveur ProConOs(Programmable Controller Operating System)(KW Software) :c'estun systèmed'exploitationPLC tempsréel,multitache,conformeCEI 61131conçupourêtreinstallésurpresquen'importequelmatériel. Puisqu'ilestbienintégréavecdesfirmwareset desruntimesexistants,les fournisseurspeuventoffrir un systèmeconformeCEI tout enmaintenant leurs propres dispositifs et possibilités.Son prix est à négocier, il serait possible de l'obtenir gratuitement.
� Une"boite noire" développéeavecMultiprog. C'estunelogiciel extrêmementcherqui sertàdévelopperdesprojetspour ProConOS.Nousdevonsdonnerunedescriptiondu produit quenousvoulons(nombreet nom desvariables),et Kuka Francenousle développera.Ils nousproposentde nousdévelopperun produit le plus génériquepossibleafin qu'ils puissentleproposer à d'autres clients.Ils pourraientalorsnousle donneren échangede quoi, nousdevrons,par exemple,écrire ladocumentationdu produit. Cependantils ne saventpasle nombred'heuresqu'ils passeronsdessus et donc ils ne s'avancent pas trop sur ce point (la gratuité).
� Le serveur OPC.Son prix est de 88 euros.
Nous n'aurons alors plus qu'à développer le client OPC.
D'aprésles renseignementsactuellementdisponibleset les testsdéjàeffectués(il enmanqueun
certainnombreà faire d'où le "flou" qui plannesur cettesolution) ils seraitpossibled'avoir40
variables accessibles.
2 / 4
Rapport du stage Kuka
68 Annexe
Schéma récapitulatif
Communication à distance à l’aide de l’OPC Serveur de ProConOs
Exemple
Du PC distant vers le robot :
Dans le Client OPC Mettre SofPLCBool1=TRUE,
=> dans le robot la valeur de la variable $SoftPlcBool[1] passera à TRUE.
Du Robot vers le PC distant :
Dans le robot mettre $SoftPlcBool[2]=TRUE,
=> dans le client OPC la valeur de la variable SofPLCBool2 passera à TRUE.
Contacts
Emmanuel Bergerot
3 / 4
PC distant
Client OPC
Serveur OPC
Robot
Trajectoire robot
Tache de fond(submit)
Runtime ProConOS16 E/S + KrcEXVarLib
Routeur
Mutiprog :Outil de développement d’unfichier automate génériquepermettant le transfert d’ infosbidirectionnelles entrele robotet le Pc distant.
Projet bootable et interprété par la Runtime
Tcp/IP@ figée
7 Annexes
Annexe 69
Glossaire
SCADA (SupervisorControl And Data Acquisition) est une catégoried'applicationpour le
"processcontrol", la récupérationdedonnéesentempsréel envuedecontrôlerl'équipementet
les conditions.Les systèmesSCADA incluent des composantslogiciels et le matériels.Le
matérielrécupèreet fournis les donnéesdansun ordinateurqui a le logiciel SCADA installé.
L'ordinateurtraite alors cesdonnéeset les présenteinstantanément.SCADA enregistreaussi
touslesévènementsdansun fichier delog surun disquedur ou lesenvoieversuneimprimante.
SCADA avertit quand les conditions deviennent dangereuses en sonnant des alarmes.
HMI (Human-machineinterface ) est une interfaceentre l'utilisateur et le systèmematériel
(électro-acoustique,électro-optique,etc.) et une section logique traitant des opérations
fonctionnelles à état.
PLC (ProgrammableLogical Controller)estun dispositif contrôlant diversprocessusd'atelier
de production.
Références
Description du ProConOS OPC-Server de KW-Software :
http://www.opcfoundation.org/05_products/05_prod_details.asp?prodid=316
Site de KW-Software avec la description de leurs produits :
http://www.kw-software.com/products/Proconos/proconos%20index.htm
http://www.kw-software.com/products/PROFInet/profinet%20index.htm
http://www.kw-software.com/products/Multiprog/multiprog%20index.htm
4 / 4
Rapport du stage Kuka
70 Annexe
7 Annexes
7.5 Annexe 5 : comparatif.pdf
Fichiers pdf :
http ://www.imerir.com/kuka/kukaApi/doc/technique/comparatif.pdf
nestor:///Projets/Stages/Kuka/documents/technique/comparatif.pdf
Fichiers sources :
nestor:///Projets/Stages/Kuka/documents/technique/sources/comparatif.sxw
Annexe 71
Comparaison entre
kuka api et OPC serveur.
Paul Chavent
16 septembre 2003
1
Rapport du stage Kuka
72 Annexe
A.P.I. Kuka : Manuel de l’utilisateur
Table des matieres
1 Introduction 3
2 Descriptions 4
2.1 OPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 kuka api . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Comparatif 5
3.1 fonctionalite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Portabilite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 Acces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6 Securite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7 Facilite d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8 Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 Conclusion 9
2
7 Annexes
Annexe 73
1 Introduction
1 Introduction
L’interface que nous proposerons a l’utilisateur doit etre simple et permettre de controler le robot intui-
tivement.
La solution kuka api est complete et propose deja une interface repondant a ces criteres.
La solution OPC ne propose qu’un moyen de communiquer avec le robot, et impliquera donc le develop-
pement de l’interface.
Au final ces deux solutions ne se distinguerons que par le moyen de faire passer les informations du robot
vers l’utilisateur.
3
Rapport du stage Kuka
74 Annexe
A.P.I. Kuka : Manuel de l’utilisateur
2 Descriptions
2.1 OPC
La solution que nous propose Kuka est basee sur un serveur OPC qui nous permettra d’acceder aux
variables du robot. OPC (OLE for Process Communication) est un standard qui permet de partager des
informations de type {nomDeVariable, valeur, date, qualite}. OPC utilise CCOM qui lui-meme utilise
les DCE RPC pour transferrer les donnees entre le serveur et les clients (voir figure 1). Le serveur OPC
que Kuka nous a livre est un serveur “Automation” et ne dispose donc que d’interfaces “dispatch” plus
adaptes a une utilisdation sous VisualBasic.
2.2 kuka api
L’api utilise le crosscomm (composant OLE) de kuka pour communiquer avec le robot, et les ONC RPC
pour transferrer les donnees entre le serveur et les clients (voir figure 1).
Fig. 1 – Description
Vous pourrez aussi trouver un comparatif ONC/DCE RPC a
http ://hissa.nist.gov/rbac/5277/titlerpc.html
4
7 Annexes
Annexe 75
3 Comparatif
3 Comparatif
3.1 fonctionalite
Les fonctionalites sont classe par ordre decroissant d’importance.
Fonctionalite OPC kuka api Commentaire
Nombre de variables 40 infini Le nombre de variables de L’OPC serveur nous est
impose par son fournisseur.
set/getVar() 3 3 Le mecanisme de mise a jour de variable pour l’OPC
est complique :
1. on met la valeur dans nomDeMaVariable,
2. on met nomDeMaVariableWrite a un,
3. on verifie que nomDeMaVariableWriteOk soit
vrai pour etre sur que c’est reussi.
Ce n’est pas plus simple pour lire des variables.
Gestion des erreurs 3 3 ras
Les fonctionalites suivantes ne sont pas indispensable.
load/unLoadModule() 7 3 ras
Acquitement defaut 3 3 ras
Mise sous puissance 3 7 ras
3.2 Portabilite
La portabilite de la solution dependra de la portabilite du client. Les deux solutions existent pour diffe-
rentent plateformes dont Windows et Linux.
Cependant, la facilite d’utilisation varie :
OPC :
Windows : nous disposons du SDK OLE en standard dans les IDE (Borland, VC++, . . .).
Linux : nous devons telecharger des packetages (au format rpm) afin d’installer le sdk. De plus, il
faut faire tourner un demon NT qui permet de “simuler l’environement de Microsoft r©”. Enfin,
il faut demander une licence d’utilisation (gratuite pour une utilisation non commerciale) par
5
Rapport du stage Kuka
76 Annexe
A.P.I. Kuka : Manuel de l’utilisateur
mail.
Voir http ://www.softwareag.com/entirex/download/download entxDCOM.htm.
Aucune recompilation du code source n’est envisageable.
kuka api :
Windows Nous fournissons l’A.P.I sous forme de librairie a linker avec votre code pour que cela
fonctionne.
Linux Idem.
Il est possible de recompiler la librairie. Sous Linux, les distributions actuelles fournissent toutes
par defaut les outils et les libs necessaires. Sous Windows, il vous faudra juste telecharger le SDK
ONCRPC. Attention la compilation sous Windows n’est pas encore tres bien supportee.
Conclusion : les deux solutions sont portables. Mais nous orienterons notre choix comme suit :
– Utilisation a dominante Windows plutot privilegier OPC.
– Utilisation a dominante Linux plutot privilegier kuka api.
3.3 Maintenance
OPC :
Le code La maintenace des clients necessite des connaissances sur le fonctionement de COM/D-
COM pour la partie programmation. L’interface restera inchangee tant que Microsoft r©ne
decidera pas de la changer. Le serveur est une boite noire sur laquelle nous n’avons aucun
controle.
Installation L’operation de reinstallation sous linux est delicate (installation des rpms et configura-
tion du demon nt). Sous Windows aucun probleme a priori (ou plutot c’est comme d’habitude :
on clique sur des bouttons et on prie pour que cela fonctionne).
kuka api :
Le code Il faudra au moins connaitre les bases du fonctionement des rpc (extremenment soimplifie
par l’utilisation de rpcgen).
Voir par exemple :
http://www.cs.cf.ac.uk/Dave/C/node33.html#SECTION003300000000000000000
Installation Sur Slackware l’installation du cient se fait simplement par installpkg. Sur Debian
il devrait bientot y avoir aussi un systeme de packetage. Sinon, pour le serveur comme pour le
client l’installation consiste a decompresser une archive. Elle ne modifie en rien votre systeme
(base de registre ou autre) et est totalement reversible.
6
7 Annexes
Annexe 77
3 Comparatif
Conclusion : De mon point de vue, la maintenance est plus aisee avec la solution kuka api :
– Au niveau de l’installation le systeme est quasiment pas affecte par l’api.
– L’evolutivite du code n’est pas compromise par des changements de version du soft de Kuka ou de
Microsoft. Il n’y aura qu’un source a modifier (Voir le manuel du developpeur).
3.4 Architecture
OPC Le serveur tourne sur un poste Windows 2000 relie a Kuka par TCP/IP. Il est imperatif de garder
une adresse fixe pour Kuka puisque elle est inscrite en dur dans le “serveur OPC” (du moins c’est
comme cela pour l’instant, mais les fournisseurs vont le faire evoluer avec un fichier de configuration).
kuka api Le serveur tourne sur Kuka. Le systeme temps reel garde en priorite les ressources pour lui.
Donc le serveur n’a pas beaucoup de ressources pendant que le systeme temps reel a la main.
Conclusion : les ressources pour le serveur n’ayant pas besoin d’etre enorme, et le fichier de configuration
pour l’OPC serveur n’etant pas encore fait, je privilegie la solution kuka api.
3.5 Acces
Cette section compare le comportement de chaque produit lorsque l’on y connecte plusieurs clients et que
l’on envoie plusieurs ordres simultanement.
OPC Un maximum de 10 clients peuvent se connecter (limitation logicielle imposee par le fournisseur,
extensible mais payant). Sur le serveur les ordres recut depuis les client sont traite en parallele
(les DCE RPC sont multithreaded par defaut). Mais meme avec du vrai multithreading (serveur
multiprocesseur), cela n’a pas de sens dans notre contexte puisque nous n’avons qu’un seul robot a
commander. Cela serait utile avec plusieur robot.
kuka api Pour l’instant 1 client doit se connecter. Mais sur le serveur plusieur ordres pouraient arriver a
meme temps, il seront geres grace a une file d’attente (les ONC RPC implementent les files d’attente
par defaut). Et bien que le multithreading soit supporte par les ONCRPC, il ne servirait a rien
puisque le PC de commande de kuka est monoprocesseur.
Conclusion : De toute facons les acces concurents aux commandes de Kuka ne seront pas traite en parallele.
De plus, si la solution est multithread et que les ordres sont destines a un seul robot, il faudra mettre en
place un sytem de blockage afin de ne pas interferer deux ordres. Sur ce point les deux solutions se valent
donc. Le comportement de l’api kuka est decrit dans la documentation et nous pouvons determiner a
7
Rapport du stage Kuka
78 Annexe
A.P.I. Kuka : Manuel de l’utilisateur
l’avance les reactions du robot pour un code donne (si les conditions sont respectes, a savoir un seul
client).
3.6 Securite
OPC COM/DCOM (DCE RPC) gere le controle d’acces.
kuka api ONC RPC gere l’authentification (elle n’est cependant pas activee par defaut). Nous ne l’uti-
lisons pas pour l’api et aucun controle d’acces n’est fait.
Conclusion : Dans un soucis de simplicite il serait preferable de desactiver l’authentification. Nous ne
retiendrons donc aucune solution sur ce critere.
3.7 Facilite d’utilisation
OPC Le mecanisme qu’n client OPC doit mettre en oeuvre pour recuperer des variables est complexe
dans ce cas. Nous aurions donc interret a l’encapsuler dans une interface semblable a celle de l’API,
ce qui reviendrait a refaire le travail qui a ete fait pour l’API.
kuka api L’interface de l’API est simple d’utilisation..
3.8 Evolution
OPC Si nous envisagons une cellule avec plusieurs robot la solution devient interressante car le serveur
gere le multitache. Par contre, la solution ProConOs risque d’etre abandonnee au profit de l’opc
serveur developpe par Kuka qui devai sortir en 2004.
kuka api Si nous investissons dans du materiel industriel compatible OPC (un autre robot), nous ne
pourrons pas directement communiquer avec lui avec la kuka_api.
Par contre nous pourrons ajouter a notre interface les autres fonctions du crosscomm (loadmodu-
le/unloadmodule. . .).
Conclusion : La solution kuka api n’est pas adaptee au monde industriel dans lequel beaucoup d’outils
differents communiquent grace a un protocole commun. Donc pour une evolutivite dans l’espace nous
priviligerions la solution OPC. Pour une evolutivite dans le temps, les deux solutions sont equivalents
puisque ce ne sont que des interfaces, leur implementation evolurons avec les technologies.
8
7 Annexes
Annexe 79
4 Conclusion
4 Conclusion
La solution que propose la kuka_api est tres specifique a l’environement de travail d’Imerir (un seul robot
par exemple). Elle repose cependant sur une technologie simple (ONC RPC) qui a fait ses preuves et qui
ne risque pas de disparaitre ( cf COM/DCOM qui est en train d’etre mis a l’ecart en faveur de .NET).
La maintenace en sera d’autant plus simple que le type de programmation “unix” est plus clair que celui
de type “Microsoft”.
9
Rapport du stage Kuka
80 Annexe
7 Annexes
7.6 Annexe 6 : crosscommexe.pdf
Fichiers pdf :
http ://www.imerir.com/kuka/kukaApi/doc/technique/crosscommexe.pdf
nestor:///Projets/Stages/Kuka/documents/technique/crosscommexe.pdf
Fichiers sources :
nestor:///Projets/Stages/Kuka/documents/technique/sources/crosscommexe.tex
Annexe 81
Aide memoire crosscommexe.
Paul Chavent
26 aout 2003
1
Rapport du stage Kuka
82 Annexe
Aide memoire crosscommexe
Table des matieres
1 Intro 4
2 Utiliser le crosscommexe grace a OLE 5
3 Generalite 6
4 Initialisation 7
4.1 Init . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5 Connection 8
5.1 ConnectToCross . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 ServerOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3 get CrossIsConnected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6 Gestion des variables 9
6.1 ShowVar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2 SetVar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3 SetInfoOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.4 SetInfoOff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7 Gestion de modules 11
7.1 ControlLevelStop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2 RunControlLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3 RobotLevelStop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2
7 Annexes
Annexe 83
Table des matieres
7.4 SelectModul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.5 CancelModul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8 Gestion du systeme 13
8.1 ConfirmAll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.2 KrcOk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.3 IO Restart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9 Gestion des fichiers et dossiers 15
9.1 GetRobotDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2 DeleteRobotProgram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.3 UploadFromRobotToMem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.4 DownLoadMemToRobot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.5 UploadFromRobotToDisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.6 DownLoadDiskToRobot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10 Inclassable pour l’instant 18
10.1 get CrossError . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.2 GetLine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.3 CrossCmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3
Rapport du stage Kuka
84 Annexe
Aide memoire crosscommexe
1 Intro
Ce document regroupe le resultat des observations faites sur le comportement du composant crosscom-
mexe fournis par kuka. Certaine des affirmation ne sont pas sure, c’est pour cela que la plus part du texte
est pondere par un pourcentage. Un faible pourcentage signifie qu’il reste encore des points a eclaircir,
un fort pourcentage permet de se fier a l’information.
4
7 Annexes
Annexe 85
2 Utiliser le crosscommexe grace a OLE
2 Utiliser le crosscommexe grace a OLE
Microsoft r©fournis avec VisualC++ un SDK(Software Developpement Kit) qui permet d’utiliser des com-
posants com. La documentation est disponible sur la “MSDN Library”. Cependant voici un bref rappel
de comment utiliser un composant le plus simplement possible.
1 #include ‘ ‘ crosscommexe . h ’ ’
2 #include <comdef . h>
3
4 CrossCommand ∗ c r o s s ;
5
6 O l e I n i t i a l i z e ( 0 ) ;
7
8 CoCreateInstance (CLSID CrossCommand , \9 NULL, \
10 CLSCTX LOCAL SERVER, \11 IID CrossCommand , \12 ( void∗∗)& c r o s s ) ;
13
14 [ . . . ]
15 cross−>ShowVar
16 [ . . . ]
17
18 O l e U n i n i t i a l i z e ( 0 ) ;
1 permet d’inclure la description de l’interface crosscomm.
2 permet d’inclure des outils pour manipuler plus facilement les BSTR.
4 declare l’interface “cross” grace a laquelle nous effectuerons nos appels sur les methodes du cross.
6 initialise OLE.
8 cree une instance de l’objet et nous fournis une interface pour le manipuler. Dans notre cas l’objet
instancie a le le CLSID CLSID_CrossCommand et il est local (10) (c-a-d sous forme d’executable, ici
crosscommexe.exe). L’interface qui nous est retournee est identifie par IID__CrossCommand.
15 nous manipulons l’objet grace aux methode que nous propose l’interface CrossCommand. 18 nous
desinitialisons OLE.
5
Rapport du stage Kuka
86 Annexe
Aide memoire crosscommexe
3 Generalite
Certains parametres reviennent souvent. C’est le cas par exemple du timeout. Par defaut cette variable
peut prendre la valeur 3000 (ms). Pour les operations sur des repertoires on peut la fixer a 10000 (ms),
et pour l’up/downLoad la fixer a 70000.
Tous les retours de fonctions sont de type HRESULT. Il peuvent etre teste grace a la macro SUCCEEDED.
Par exemple :
1 IDispatch ∗ pIDispatch=NULL;
2 p r i n t f ( ‘ ‘ c ross−>I n i t (%p ) . . . ’ ’ ,&pIDispatch ) ;
3 i f ( SUCCEEDED( cross−>I n i t (&pIDispatch ) ) )
4 p r i n t f ( ‘ ‘ succeed\n ’ ’ ) ;
5 else
6 p r i n t f ( ‘ ‘ f a i l e d ’ ’ ) ;
6
7 Annexes
Annexe 87
4 Initialisation
4 Initialisation
4.1 Init
Permet d’initialiser le composant OLE. (100%)
Init( IDispatch **oParent)
oParent 0%
7
Rapport du stage Kuka
88 Annexe
Aide memoire crosscommexe
5 Connection
5.1 ConnectToCross
Permet de se connecter au cross. (100%)
ConnectToCross( BSTR sConnectName, short nC Mode, VARIANT *result)
sConnectName est le nom avec lequel on se connecte. 100%
nC Mode est le type de connection : asynchrone(-1) ou synchrone(0). 100%
result 0%
5.2 ServerOff
Permet de se deconnecter du cross. (100%)
ServerOff()
5.3 get CrossIsConnected
Permet de savoir si on est connecte. (100%)
get CrossIsConnected( VARIANT BOOL *bResult )
bResult Pointeur vers un booleen qui contient le resultat :
– true : on est connecte,
– false : on ne l’est pas.
100%
8
7 Annexes
Annexe 89
6 Gestion des variables
6 Gestion des variables
6.1 ShowVar
Permet d’obtenir la valeur d’une variable sous la forme d’une chaine de caractere qu’il faudra alors traiter
pour obtenir des donnees typees. (100%)
ShowVar( BSTR sVariableName, BSTR* sResult, long *vTimeOut, VARIANT BOOL *bResult)
sVariableName nom de la variable a consulter. 100%
sResult chaine de charactere contenant le resultat. 100%
vTimeOut timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : le resultat est bien ecrit dans sResult,
– false : le resultat n’a pas pu etre obtenu (variable inexistante ...).
100%
6.2 SetVar
Permet d’attribuer a une variable une valeur. La valeur est affectee sous forme de chaine de charactere
correctement formatee. (100%)
SetVar( BSTR sVariableName, BSTR sNewValue, long *vTimeOut, VARIANT BOOL *bResult)
sVariableName nom de la variable a modifier. 100%
sNewValue Chaine de charactere contenant la nouvelle valeur a affecter. 100%
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : la variable a bien ete ecrite,
– false : la variable reste inchangee (variable inexistante ...).
100%
6.3 SetInfoOn
? ?. (0%)
9
Rapport du stage Kuka
90 Annexe
Aide memoire crosscommexe
SetInfoOn( BSTR sVariableName, BSTR *sResult, long *vTimeOut, VARIANT BOOL *bResult)
sVariableName nom de la variable. 100%
sresult
? ?.
0%
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : echoue.
100%
Au maximum 4 setInfos a meme temps, et plus d’un setInfo par variable est ignore.
6.4 SetInfoOff
? ?. (0%)
SetInfoOn( BSTR sVariableName, long *vTimeOut, VARIANT BOOL *bResult)
sVariableName nom de la variable. 100%
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : echoue.
100%
10
7 Annexes
Annexe 91
7 Gestion de modules
7 Gestion de modules
7.1 ControlLevelStop
Permet d’arreter l’interpreteur submit (100%).
ControlLevelStop( long *vTimeOut, VARIANT BOOL *bResult)
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : le module submit est stoppe (mais toujours charge),
– false : le module submit tourne toujours.
100%
7.2 RunControlLevel
Permet de mettre en route un interpreteur submit (100%).
RunControlLevel( BSTR *sPrgName, *vTimeOut, VARIANT BOOL *bResult)
sPrgName Nom du module sub a charger : “sps.sub” par exe. 90%
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : le module sPrgName tourne comme tache submit,
– false : sinon.
100%
7.3 RobotLevelStop
Permet d’arreter le programme courant (equivalent au boutton “stop” du KCP). (100%)
RobotLevelStop( long *vTimeOut, VARIANT BOOL *bResult)
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : le process actif est stoppe (mais toujours charge),
– false : sinon.
100%
11
Rapport du stage Kuka
92 Annexe
Aide memoire crosscommexe
7.4 SelectModul
Permet de charger un module dans le robot.(100%)
SelectModul( BSTR strFile, BSTR strParam, VARIANT BOOL *bImplizitCancel,*vTimeOut,[. . .])
strFile Nom du module a charger : “toto.src” par exe. 100%
strParam Parametres. 0%
bImplizitCancel
? ?.
0%
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : le module strFile est charge dans le robot,
– false : sinon.
100%
7.5 CancelModul
Permet de decharger le module du robot.(100%)
CancelModul( *vTimeOut, VARIANT BOOL *bResult)
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : le module courant est decharge du robot,
– false : sinon.
100%
12
7 Annexes
Annexe 93
8 Gestion du systeme
8 Gestion du systeme
8.1 ConfirmAll
Permet d’acquitter tous les messages d’erreur (les warnings sont laisses). (100%)
ConfirmAll( long *vTimeOut, VARIANT BOOL *bResult)
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : sinon.
100%
8.2 KrcOk
Permet d’acquitter ? ?. (0%)
ConfirmAll( long *vTimeOut, VARIANT BOOL *bResult)
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : sinon.
100%
8.3 IO Restart
? ? ?. (0%)
13
Rapport du stage Kuka
94 Annexe
Aide memoire crosscommexe
IO Restart( IO TYPE nBus, long *vTimeOut, VARIANT BOOL *bResult)
nBus IO TYPE c’est une enumeration :
– IORestart
– IBusReset
– ICanReset
– BoschReset
– PerceptronReset
100%
vTimeOut Timeout (3000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : sinon.
100%
14
7 Annexes
Annexe 95
9 Gestion des fichiers et dossiers
9 Gestion des fichiers et dossiers
“Les donnees importantes pour la commande sont memorisees sur le disque dur dans le repertoire Steu
alors que les donnees importantes pour le robot se trouvent dans le repertoire R1. L interface utilisateur
KUKA affiche le systeme de commande comme / et le systeme de robot comme sous-repertoire du systeme
de commande avec le nom R1.” cf Doc Kuka : Programmation expert, Partie 3 (variables et convention),
page 62.
Fig. 1 – Niveau commande (/) et niveau robot (R1) Fig. 2 – Niveau PC
9.1 GetRobotDirectory
Permet de recuperer le repertoire dans lequel se trouve un fichier. (50%)
GetRobotDirectory(BSTR *sDir, BSTR *sMask, long *vTimeOut, VARIANT BOOL *bResult)
sDir Pointeur vers une chaine dans laquelle il y aura le resultat de la recherche. 50%
sMask Pointeur vers une chaine dans laquelle il y le fichier a chercher. 50%
vTimeOut Timeout (10000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : sinon.
100%
La recherche est effectuee dans R1 seulement. La chaine sDir contient tous les chemins complets de fichiers
separes par CHR(10).
15
Rapport du stage Kuka
96 Annexe
Aide memoire crosscommexe
9.2 DeleteRobotProgram
Permet de detruire un fichier. (0%)
DeleteRobotProgram(BSTR sPrgName, long *vTimeOut, VARIANT BOOL *bResult)
sPrgName Programme a detruire. 0%
vTimeOut Timeout (10000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : sinon.
100%
9.3 UploadFromRobotToMem
Permet de copier un fichier depuis l’espace robot vers l’espace ? ?. (0%)
UpLoadFromRobotToMem(BSTR sFileName, BSTR sFile, BSTR *sOptions, long *vTimeOut, VARIANT BOOL *bResult)
sFileName Fichier sources (“toto.src” par exemple). 0%
sFile 0%
vTimeOut Timeout (70000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : sinon.
100%
9.4 DownLoadMemToRobot
. (50%)
16
7 Annexes
Annexe 97
9 Gestion des fichiers et dossiers
DonwLoadMemToRobot(BSTR sFilename, BSTR sFile, long *vTimeOut, VARIANT BOOL *bResult)
sFilename Fichier sources (“toto.src” par exemple). 0%
sFile 0%
vTimeOut Timeout (70000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : sinon.
100%
Le fichier source doit se trouver dans l’arborescence de R1.
9.5 UploadFromRobotToDisk
Permet de copier un fichier depuis l’espace robot vers l’espace PC. (0%)
UpLoadFromRobotToDisk(BSTR sFileName, BSTR sPath, BSTR *sOptions, long *vTimeOut, VARIANT BOOL *bResult)
sFileName Fichier sources (“toto.src” par exemple). 0%
sPath Repertoire de destination (“c :’ par exemple). 0%
vTimeOut Timeout (70000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : sinon.
100%
9.6 DownLoadDiskToRobot
. (50%)
DonwLoadDiskToRobot(BSTR sFilename, long *vTimeOut, VARIANT BOOL *bResult)
sFilename Chaine de caracteres contenant le nom du fichier (“c :\toto.src” par exemple). 100%
vTimeOut Timeout (70000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : sinon.
100%
17
Rapport du stage Kuka
98 Annexe
Aide memoire crosscommexe
Le fichier source doit se trouver dans l’arborescence de R1.
cross->Init
10 Inclassable pour l’instant
10.1 get CrossError
Permet de recuperer le dernier code d’erreur. (100%)
Ce code d’erreur est un long qui contient le numero d’erreur. La description du code est recuperable en
interrogeant la variable “&code”.
get CrossError( long *lResult )
lResult Pointeur vers un long qui contient le resultat. 100%
10.2 GetLine
? ? ?. (0%)
GetLine(BSTR *sBuffer, BSTR *sResult)
sBuffer Chaine de caracteres qui sera remplie avec quelque chose. 0%
hline sResult 0%
10.3 CrossCmd
? ? ?. (0%)
18
7 Annexes
Annexe 99
10 Inclassable pour l’instant
CrossCmd(BSTR sCommand, BSTR sParam1, BSTR sParam2, VARIANT *sResult1, VARIANT *sResult2,[. . .])
sCommand 0%
sParam1 0%
sParam2 0%
sResult1 0%
sResult2 0%
vTimeOut Timeout (70000 ms). 100%
bResult Pointeur vers un booleen qui contient le resultat de l’appel au cross :
– true : reussit,
– false : sinon.
100%
19
Rapport du stage Kuka
100 Annexe
Projet Kuka
(juin-septembre 2003)
Paul Chavent
Kubrick
Ce stage a permis a l’ecole de disposer d’une interface de programmation
pour le robot Kuka. Cette interface est ecrite en c, et est accessible depuis
un reseau Tcp/Ip.