Rapport de stage de deuxi`eme année

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


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


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


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


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

http://www.imerir.com/kuka/kukaApi/doc/rapport.pdf


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


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


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


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


– 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


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


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


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

http://www.imerir.com/kuka/kukaApi/doc/kuka_api_man_devl.pdf

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

http://www.imerir.com/kuka/kukaApi/doc/kuka_api_man_util.pdf

http://www.imerir.com/kuka/kukaApi/doc/kuka_api_man_ref.pdf


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

http://www.imerir.com/kuka/kukaApi/doc/kuka_api_man_devl.pdf

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


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


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

http://www.imerir.com/kuka/kukaApi/doc/kuka_api_man_util.pdf


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

http://www.imerir.com/kuka/kukaApi/src/morpion.tar.gz

http://www.imerir.com/kuka/kukaApi/images/morpion.mpeg

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


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


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


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

http://www.imerir.com/kuka/kukaApi/doc/technique/communication.pdf

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


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 :� 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


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 :� 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].


Inconvénient :� pas de passage de paramètres possibles

Documentation :

� Système E/S� Automatique externe� DeviceNet (bus CAN)

6 / 6


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

http://www.imerir.com/kuka/kukaApi/doc/technique/comdcom.pdf

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.


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


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)


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


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


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

http://www.imerir.com/kuka/kukaApi/doc/technique/opc.pdf

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


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


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


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


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


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

http://www.imerir.com/kuka/kukaApi/doc/technique/opcproconos.pdf

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


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


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

http://www.imerir.com/kuka/kukaApi/doc/technique/comparatif.pdf

Comparaison entre

kuka api et OPC serveur.

Paul Chavent

16 septembre 2003

1


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


74 Annexe


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


76 Annexe


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


78 Annexe


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


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

http://www.imerir.com/kuka/kukaApi/doc/technique/crosscommexe.pdf

Aide memoire crosscommexe.

Paul Chavent

26 aout 2003

1


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


84 Annexe


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


86 Annexe


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


88 Annexe


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%


– true : la variable a bien ete ecrite,

– false : la variable reste inchangee (variable inexistante ...).

100%

6.3 SetInfoOn

? ?. (0%)

9


90 Annexe


SetInfoOn( BSTR sVariableName, BSTR *sResult, long *vTimeOut, VARIANT BOOL *bResult)

sVariableName nom de la variable. 100%

sresult

? ?.

0%



– 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%



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



– 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%



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



– true : le process actif est stoppe (mais toujours charge),

– false : sinon.

100%

11


92 Annexe


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%



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



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



– true : reussit,

– false : sinon.

100%

8.2 KrcOk

Permet d’acquitter ? ?. (0%)

ConfirmAll( long *vTimeOut, VARIANT BOOL *bResult)



– true : reussit,

– false : sinon.

100%

8.3 IO Restart

? ? ?. (0%)

13


94 Annexe


IO Restart( IO TYPE nBus, long *vTimeOut, VARIANT BOOL *bResult)

nBus IO TYPE c’est une enumeration :

– IORestart

– IBusReset

– ICanReset

– BoschReset

– PerceptronReset

100%



– true : reussit,

– false : sinon.

100%

14

7 Annexes

Annexe 95

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%



– 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


96 Annexe


9.2 DeleteRobotProgram

Permet de detruire un fichier. (0%)

DeleteRobotProgram(BSTR sPrgName, long *vTimeOut, VARIANT BOOL *bResult)

sPrgName Programme a detruire. 0%



– 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%



– true : reussit,

– false : sinon.

100%

9.4 DownLoadMemToRobot

. (50%)

16

7 Annexes

Annexe 97


DonwLoadMemToRobot(BSTR sFilename, BSTR sFile, long *vTimeOut, VARIANT BOOL *bResult)

sFilename Fichier sources (“toto.src” par exemple). 0%

sFile 0%



– 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%



– 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%



– true : reussit,

– false : sinon.

100%

17


98 Annexe


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%



– true : reussit,

– false : sinon.

100%

19


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.