Contribution des méthodes d’apprentissage à la distribution de tâches dans un cluster robotique

Architecture d’un réseau de neurones

   Un réseau de neurones est un ensemble d’interconnexions de neurones organisé, le plus souvent, en plusieurs couches comme sur la Figure 1.5. Nous pouvons distinguer trois types de couches :
1. La couche d’entrée recevant les données externes au réseau.
2. La couche de sortie produisant le résultat final.
3. Entre zéro et plusieurs couches cachées réparties entre la couche d’entrée et la couche de sortie et servant à capturer des relations complexes. Chaque couche supplémentaire permet d’extraire des caractéristiques de plus en plus abstraites.La force d’un réseau de neurones réside dans sa capacité à apprendre à partir d’exemples sans nécessité de connaissance préalable. L’apprentissage est l’adaptation du réseau à la réalisation d’une tâche (comme la détection d’objets) à partir d’exemples d’observations. Lors de l’apprentissage, les poids et les seuils du réseau sont ajustés afin d’améliorer la précision de la prediction (inférence). Ce processus s’effectue par minimisation des erreurs observées à l’aide d’une fonction de coût. Ce procédé appelé rétropropagation du gradient permet d’ajuster les poids de connexion afin de compenser les erreurs détectées lors de l’apprentissage. Concrètement, la rétropropagation du gradient calcule le gradient de la fonction de coût associée à un état donné par rapport aux poids [37]. Couramment, la mise à jour des poids est effectuée à l’aide de l’algorithme du gradient stochastique. L’ampleur des corrections apportées aux réseaux dépend du taux d’apprentissage (learning rate). L’apprentissage est considéré terminé lorsque les observations supplémentaires ne réduisent plus suffisamment le taux d’erreur observé.

Deep Q-Network

   La première utilisation conjointe d’un réseau de neurones avec l’algorithme de QLearning remonte aux travaux de Jin [23], mais elle ne concernait qu’un espace d’état réduit. Cette approche n’est devenue populaire qu’avec Minh et al. [33]. Profitant des récentes avancées observées dans l’utilisation d’un réseau de neurones convolutifs profonds, ils ont réussi à traiter un problème d’apprentissage par renforcement possédant un espace d’état à forte dimension (les pixels d’une image). Concrètement, le Deep Q-network a recours à un réseau de neurones de paramètre θ pour approximer la value function. Le Q-Network est entraîné en minimisant une séquence de fonctions objectif Li(θi) qui évolue à chaque itération i.

Formalisation du problème MRTA

   Cette diversité de contextes, situations et problématiques a poussé Gerkey et Mataric [6] à proposer une taxonomie du problème de MRTA afin de le formaliser. Cette dernière offre une classification rapide et indépendante du contexte selon les trois axes suivants :
1. Robot mono-tâche (ST) ou robot multi-tâche (MT) : les robots d’un système ST ne peuvent exécuter chacun qu’une tâche à la fois alors que ceux d’un système MT peuvent mener plusieurs tâches en parallèle.
2. Tâche mono-robot(SR) ou tâche multi-robot (MR) : dans un système SR, les tâches de type ST nécessitent seulement un robot pour être complétées alors que dans un système MR, certaines tâches nécessitent plusieurs robots.
3. Affectation instantanée (IA) ou affectation prolongée (TA) : les affectations IA sont effectuées sur la base d’informations ne permettant pas de planifier les futures allocations. Les allocations TA profitent de davantage d’informations comme la connaissance de l’ordre d’arrivée des tâches, leur nombre, etc. Cependant, la pertinence d’une solution d’allocation de tâches dépend aussi fortement de l’architecture du MRS.

Architecture du système multi-robot

Cette architecture se caractérise selon deux axes majeurs :
1. Centralisée ou décentralisée : Dans un système centralisé, un agent central est responsable de la gestion de l’ensemble des ressources du système. Cette centralisation de l’information permet à l’agent central d’obtenir une vision globale de la situation, et donc, de trouver une solution optimale au problème. Cependant cette centralisation implique que tous les robots du systèmes communiquent avec l’agent central entraînant un fort coût de communications et la création d’un point de défaillance unique. À l’opposé, dans un système décentralisé, chaque robot prend lui même ses décisions basées sur une compréhension locale de la situation.
2. Homogène ou hétérogène : Dans un système homogène, les robots possèdent des caractéristiques identiques et sont donc capables d’exécuter les mêmes tâches. Lorsqu’un système devient hétérogène, certains de ses robots possèdent des spécificités allant de la présence (ou de l’absence) d’un capteur au changement de paradigme du robot Dans ces travaux, nous nous intéressons aux architectures décentralisées (homogènes ou hétérogènes) pour lesquelles les approches basées sur le marché se révèlent efficaces.

Cloud robotique

   Suite au développement rapide des infrastructures cloud et du big data, l’intégration de ces technologies a permis aux systèmes MRS d’améliorer considérablement leurs performances et de gagner en complexité [17, 52]. Le recours au cloud affranchit les robots d’une partie des contraintes de l’univers embarqué en les transformant en capteurs/actionneurs mobiles. Le cloud robotique peut être défini de la façon suivante : un système robotique qui s’appuie sur des données ou du code obtenus depuis un réseau pour conduire ses tâches et dont toutes les données capteurs, tous les calculs ou toutes les mémoires ne sont pas intégrés directement dans le système. Le cloud robotique apporte les avantages suivants :
1. Calculs déportés : l’exécution des calculs sur des serveurs distants permet d’une part, d’alléger les robots de leurs tâches de calcul et, d’autre part, d’accélérer ces derniers en exploitant, entre autre, la parallélisation des calculs. Cela a notamment été employé pour des tâches de cartographie et localisation simultanées (SLAM) [36], de contrôle de formation [51] et d’analyse d’images [38]. Cependant, le recours au cloud computing entraîne une forte utilisation de la bande passante pour transférer les données nécessaires aux calculs.
2. Accès au Big Data : l’utilisation du cloud permet aux robots d’accéder à de larges bases de données qu’ils ne pourraient pas stocker localement compte tenu des limitations imposées par l’informatique embarquée. Son recours pour les tâches de saisie d’objet permet à la fois d’identifier l’objets à saisir [7], mais aussi d’améliorer la stabilité de la prise [18] comme illustré en Figure 2.12.
3. Apprentissage coopératif : l’utilisation du cloud offre la possibilité d’apprendre collectivement en partageant les expériences [2].

Distribution et parallélisation de tâches

   La distribution des tâches au sein d’un système multi-robots conditionne la coordination de ce dernier. Par conséquent, il s’agit d’une problématique cruciale qui reçut une forte attention et de nombreuses solutions furent proposées. Cependant, la pertinence d’une solution dépend fortement du contexte, et notamment, de l’architecture du système multirobots. Dans le cas d’un système décentralisé, les approches basées sur le marché se révèlent pertinentes. Elles consistent à faire évoluer les robots dans une économie fictive où les tâches et ressources nécessaires à leur exécution s’échangent. Chaque robot cherche alors à maximiser son profit conduisant à l’amélioration des performances du système. Couramment, le mécanisme d’échanges s’appuie sur un système d’enchères pour effectuer les attributions. De nombreux types d’enchères existent et ils répondent à des besoins particuliers. Si l’objectif recherché est la mise en concurrence simultanée des acheteurs et vendeurs, il est alors nécessaire de recourir à des enchères doubles qui s’apparentent à des offres boursières. Cependant, quelle que soit l’approche de résolution utilisée, les occurrences actuelles de MRTA ne traitent pas de problématiques relatives à la parallélisation (et la distribution) des tâches fortement calculatoires. Ces dernières sont abordées indépendamment du MRTA avec les concepts de cloud et de cluster robotique :
1. Cloud robotique : cette solution consiste à déporter les calculs, les données et parfois même la prise de décision à un système extérieur. Ce dernier possède des capacités nettement supérieures à celles de la MRS et libère les robots d’une grande partie de contraintes liées à l’univers embarqué. Cependant, cette solution nécessite l’accès à une bande passante stable et à haute capacité. De plus, elle entraîne la génération d’une latence dans les traitements. Par conséquent, bien qu’efficace, cette approche est inutilisable dans de nombreuses situations.
2. Cluster robotique : les limites du cloud robotique ont conduit au développement d’une approche de traitement locale au MRS. Elle consiste à mettre en commun les ressources non-utilisées du système afin d’accélérer les robots dans le besoin. Cette solution ne souffre pas des limitations du cloud robotique, mais elle n’est applicable qu’aux tâches fortement parallélisables et nécessitant peu d’échanges de données.

Le système multi-robots

   Afin de répondre aux exigences d’un déploiement dans un milieu critique tel qu’une zone de sinistre, le système multi-robots est décentralisé et isolé de tout appui extérieur (cloud robotique). En outre, bien que capable de communiquer entre eux, les drones du système évoluent indépendamment sans échanger d’informations concernant leur état. Par conséquent, les communications apparaissent uniquement lors de la distribution d’une tâche. Une nouvelle fois, nous nous intéressons aux tâches d’un point de vue calculatoire. Dès lors, la définition de nos drones s’avère proche de celle utilisée précédemment. Néanmoins, dans un contexte opérationnel réel, un système de drones exécute une mission sous une contrainte forte, l’énergie initiale dont il dispose. Cette dernière sera consommée en fonction des choix et des tâches réalisés par le système. Pour cette raison, nous considérons un modèle de consommation afin d’ajouter cette contrainte forte au problème posé.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Introduction
1 Contexte théorique 
1.1 Apprentissage par renforcement 
1.1.1 Principes
1.1.2 Processus de décision markovien fini
1.1.3 Programmation dynamique
1.1.4 Monte Carlo
1.2 Réseaux de neurones artificiels 
1.2.1 Neurone formel
1.2.2 Réseaux de neurones
2 État de l’art 
2.1 Apprentissage par renforcement
2.1.1 Temporal-difference
2.1.2 Deep Q-Learning
2.1.3 Espace d’actions à forte dimension
2.2 Distribution et parallélisation de tâches
2.2.1 Multi-Robot Task Allocation
2.2.2 Calcul haute performance et MRS
3 Allocation de tâches calculatoires au sein d’un cluster robotique 
3.1 Introduction
3.2 Modélisation du problème 
3.2.1 Définition de l’environnement
3.2.2 Solutions
3.3 Résultats
3.3.1 Conditions d’expérimentation
3.3.2 Performances globales
3.3.3 Qualité de la distribution
3.3.4 Évolutivité et déséquilibre
3.4 Conclusion 
3.5 Note importante
4 Administration dynamique d’un cluster robotique 
4.1 Introduction 
4.2 Présentation du problème
4.2.1 Les concepts principaux
4.2.2 Le concept de tâche
4.3 Modélisation du problème
4.3.1 Modélisation de l’environnement et des acteurs
4.3.2 Modélisation d’une tâche
4.3.3 Modélisation de la consommation d’énergie
4.4 Définition de nos solutions 
4.4.1 Première solution
4.4.2 Approche BDQ
4.4.3 Approches multi-agents
4.5 Conditions d’expérimentation
4.5.1 Présentation du simulateur
4.5.2 Paramétrages
4.6 Résultats
4.6.1 Exécution locale vs distribuée
4.6.2 Taux de succès
4.6.3 Utilisation des ressources du système
4.6.4 Systèmes de récompenses
4.7 Conclusion 
Conclusion et perspectives
Bibliography

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *