Communication entre entités - Supervision distribuée d’un système de production flexible utilis

 xtrans ytrans ytrans  =   x_ur10 y_ur10 z_ur10  −   x_ur5 x_ur5 x_ur5   (A.1)

De la tableA.1, on peut ainsi obtenir ces valeurs :

transmat =   0.235 −0.830 −0.400   (A.2)

A.5 Communication entre entités

Pour l’envoi et la réception des données , nous avons utilisé les protocoles de communications de ROS (Topics et services principalement). Les données à envoyer sont entre autres le numèro de l’opération, ce en quoi elle consiste ( par exemple, déplacer le produit d’un point m1 vers un point m2) et le nu-méro de la ressource ( par exemple 0 pour l’ur10 et 1 pour l’ur5) qui a gagné l’opération. Ces données sont transmises par le superviseur. Une fois que les robots auront accomplis ces tâches, ils doivent remonter l’information au su-perviseur pour que ce dernier puisse envoyer la prochaine.

Sur ROS, le protocole de type Topic, qui permet l’envoi de données par un Publisher et la souscription à ce Topic par autant de Subscriber le désirant, réponds bien à nos critères d’envoi d’information par le superviseur aux ro-bots. En outre, le Topic sous ROS peut avoir une structure, c’est-à-dire qu’on la possibilité d’envoyer plusieurs types de messages en utilisant le même

A.5. Communication entre entités 139 type, en spécifiant le type de message (booléen, entier, réel, points carté-siens. . .) dans un fichier de définition, au préalable. Quant à l’envoi des infor-mations par les robots, nous avions besoin d’un type qui permettra d’envoyer les informations justes une fois et à la demande. Donc le Topic ne correspond pas à ce critère, car il publie continuellement et sans qu’on le lui demande. Par ailleurs le service, basé sur le principe de Request/Response permet de répondre à ce besoin. Donc le superviseur lance une requête pour connaître l’etat de l’opération actuelle, et dès qu’il reçoit une réponse disant qu’elle est finie, il passe à l’opération suivante.

A.5.1 ROS multi-Machine

ROS multi-machine est une fonctionnalité de ROS qui permet de faire communiquer plusieurs machines, robots ou éléments équipés de ROS. Etant donné que nous voulons tester une architecture de supervision distribuée, nous avons alors utilisé trois ordinateurs, connectés en ROS multi-machine, pour le contrôle de nos entités.

La communication multi-machine sur ROS consiste à définir un des ordina-teurs comme étant le Ros-master, et à le faire reconnaître aux autres ordi-nateurs en utilisant l’adresse IP du Ros-master. Les ordiordi-nateurs doivent évi-demment être connectés dans le même réseau.

Parmi les trois ordinateurs utilisés, le premier symbolise le superviseur et est aussi le master. Il comporte le programme d’algorithme d’allocation des tâches, les positions des différents stocks et machines, le topic operation_info, le service operation_processed, le tout dans un noeud Ros nommé supervisor_pub.py. Les deux autres ordinateurs symbolisent les robots qui en plus des topics et service incluent dans le superviseur, un service pour le contrôle du gripper et le noeud ur_driver et l’ensemble du meta-package universal robot lancés dans des namespace "/ur10" et "/ur5" respectivement pour le robot UR10 et UR5. Il est important de lancer les noeuds et topics dans des namespace différents pour éviter les des conflits de noms. Les robots et les ordinateurs sont connectés au même réseau via Ethernet. Ainsi les ordinateurs peuvent envoyer des commandes aux robots (déplacement vers un point, ouverture/-fermeture gripper) et les robots peuvent aussi envoyer des informations sur leur état actuel , d’où l’interaction entre eux(robot et ordinateur).

141

Annexe B

Modèle de l’approche de plans de

transport et de production

intégrés : IT2P

Cette annexe décrit l’approche IT2P développée par l’université

d’EXE-TER et le laboratoire Lineact du CESI de Rouen. La sectionB.1 de cette

an-nexe décrit le modèle mathètique associé, et la sectionB.2explique le codage du chromosome utilisé dans l’algorithme génétique.

B.1 Modèle mathématique de l’approche IT2P

L’approche IT2P a été développée pour la résolution simultanée des pro-blèmes d’ordonnancement des tâches de transport et production. Une flexi-bilité de routage est en plus intégrée.

B.1.1 Notations

Ensembles et indices

M Ensemble des indices des machines

J Ensemble des indices des AGVs

j Indice des Jobs, j ∈ {1, . . . , J}avec J = |J |.

m Indice des machines de production m∈ {_{1, . . . , M}}_{avec M}= |M|)

r Indice des robots, r∈ {1, . . . , R}avec R = |R|.

i Indice des tâches, i ∈ {1, . . . , I^j}∀j ∈ J avec I^j le nombre de tâches d’un Job j

Mj,i Sous-ensemble de machines capable de réaliser la tâche i du Job j

avecM^j,i ⊂ M

Paramètres :

p_j,i,m Temps d’exécution de la tâche i du Job j sur la machine m

d_m,m0 Temps de transport entre m et m⁰, m, m⁰∈ M

Variables de décision :

X_j,i,m Variable binaire ; égale à : 1 si la machine m est allouée à la tâche i du

Job j ; 0 sinon

Y_j,i,r Variable binaire ; égale à : 1 si l’AGV r est en charge de transporter le

142

intégrés : IT2P

H⁻_j,i,m Variable binaire ; égale à : 1 si l’AGV r est en charge de transporter le

produit associé au Job j à la machine allouée à la tâche i est en train d’attendre à la machine m ; 0 sinon ;

H^m_j,i,r⁰^,m Variable binaire ; égale à : 1 si l’AGV r est en charge de transporter le

produit associé au Job j à la machine allouée à la tâche i est au niveau de la machine m⁰; 0 sinon ;

S_j,i Variable entière ; Temps de début de la tâche i du Job j E_j,i Variable entière ; Temps de fin de la tâche i du Job j

S^t_j,i Variable entière ; Temps de début de la tâche de transport du Job j

vers la machine allouée à la tâche i

E^t_j,i Variable entière ; Temps de fin de la tâche de transport du Job j vers la machine allouée à la tâche i

B.1.2 Fonction objectif et contraintes

La fonction objectif vise à minimiser le Makespan, peut s’écrire selon l’équationB.1: Minimiser max j∈J C_j, (B.1) Contrainte par : C_j =E^t_j,Ij+1 =S^t_j,Ij+1+

∑

m∈Mj,I j

∑

r∈R d_m,0×Y_j,Ij+1,r×X_j,Ij,m∀j ∈ J (B.2) S^t_j,i₊₁ ≥S_j,i+

∑

m∈Mj,i p_j,i,m×X_j,i,m∀j ∈ J ∀i ∈1, . . . , I^j (B.3) S^t_j,i₊₁ ≥

∑

j⁰ I_j,i+1,j0⁺

∑

i⁰=1

∑

m∈Mj,i

∑

m0∈Mj0,i0 E^t_j0,i⁰+d_m,m0 ×W_j,i,j0,i⁰,m,m⁰,r∀j∈ J ∀i∈ 1, . . . , I^j (B.4) Avec : I_j,i,j⁺ 0 = i si j = j⁰; I^j+1 sinon ; etW_j,i,j0,i0,m,m0,r = X_j0,i0,m ×Y_j0,i0,r ×

H⁻_j,i₊_1,m0 ×Y_j,i,r

La contrainteB.2 est relative au temps de livraison d’un produit associé

à un Job j, ce qui correspond à la fin de sa dernière tâche de transport. Cette tâche consiste à la ramener au point de stockage des produits.

Les contraintesB.3 et B.4 assurent le fait qu’une tâche de transport ne peut commencer sans l’AGV et le produit ne soient disponibles.

Dans le document Supervision distribuée d’un système de production flexible utilisant des robots mobiles collaboratifs pour la tâche de transport (Page 157-161)