Quand le Deep Learning permet l’apprentissage par renforcement des robots industriels – 2nde partie


Le premier billet de notre série était destiné à introduire notre sujet de l’apprentissage par renforcement des robots industriels, une réflexion menée en partenariat avec KUKA Robotics en France.

Nous y avons ainsi présenté pour ce cas d’usage concret, les demandes et attentes quant à une solution appropriée à cette problématique, les grands principes de l’approche que l’on pourrait mettre en œuvre.

Avec cette démarche ainsi engagée avec KUKA, nous avons souhaité mobiliser les compétences et les ressources nécessaires, afin de proposer une solution se mêlant intelligence artificielle et objets connectés pour envisager l’Industrie 4.0, à savoir comme la décrit Wikipédia, « une nouvelle façon d’organiser les moyens de production : l’objectif est la mise en place d’usines dites « intelligentes » (« smart factories ») capables d’une plus grande adaptabilité dans la production et d’une allocation plus efficace des ressources, ouvrant ainsi la voie à une nouvelle révolution industrielle. »

Cette solution s’articule autour des technologies du #DeepLearning et plus particulièrement de l’apprentissage par renforcement, souvent condenser en « Deep Reinforcement Learning » lesquelles suscitent, à l’heure actuelle, le plus de recherches et d’innovations dans les grandes entreprises du numériques.

Dans ce contexte, Microsoft investie énormément dans le domaine, en témoigne la récente mise à disposition, librement, du Projet Malmo, faisant suite au rachat du célèbre jeu Minecraft, ou encore, la montée en puissance du Framework CNTK (Computational Network ToolKit) utilisé dans les développements d’algorithmes de Deep Learning au sein de Microsoft et que nous avons déjà eu l’occasion d’aborder dans ce même blog.

La collaboration ici présentée entre KUKA et Microsoft propose la mise à disposition des ressources nécessaires à la réalisation d’une intelligence artificielle permettant aux robots industriels de KUKA de réaliser, le cas échéant, des tâches, sans la supervision d’un humain, ou à minima, d’en réduire la nécessité.

Nous allons développer dans cette suite de cette série de billets la mise en œuvre d’un système de tri sélectif des déchets, se basant sur une acquisition d’image de l’objet à trier.

Comme promis dans le billet précédent, nous détaillons ici les différents systèmes intervenants dans la réalisation des différentes actions, ainsi que les mises en œuvre que nous avons proposées.

Les composants et systèmes utilisés pour la mise en œuvre

Comme vous pouvez l’imaginer sans peine, ce cas d’usage et l’étude associée reposent sur l’utilisation d’un certain nombre de briques matérielles et logicielles hétérogènes.

Afin de vous donner une idée précise de l’architecture finale mise en place, nous allons détailler les différents composants utilisés pour la réalisation de la solution opérationnelle.

Le projet global se base sur un ensemble de quatre éléments, ayant chacun un rôle bien précis :

  • Le robot industriel. Il saisit les objets et les dépose dans le bon bac de recyclage.
  • Le dispositif d’acquisition. Il capture les images via une caméra
  • Le système d’évaluation du modèle de Deep Learning. Il renvoie pour une image donnée le bac qu’il pense être le bon
  • La passerelle ou « Gateway ». Elle assure la communication entre les différentes briques logicielles citées ci-dessus.

Au-delà de cette description succincte, détaillons à présent chacun de ces systèmes indépendamment des autres, puis, nous aborderons ensuite les différents modèles de déploiement envisageables pour aboutir à la solution déployée dans la pratique.

Un robot KUKA LBR iiwa

 

Afin de réaliser cette étude et de mettre ainsi en œuvre ce cas d’usage concret au travers de la collaboration engagée, nous remercions très sincèrement KUKA Robotics en France d’avoir mis à la disposition de Microsoft France un robot de type LBR iiwa 7kg comme évoqué précédemment.

Ce dernier est installé au sein du MTC (Microsoft Technology Center) Paris, dont la vocation est d’accueillir tout au long de l’année dans les meilleures conditions les différents clients et partenaires de Microsoft et de leur proposer un accompagnement personnalisé afin de les aider à imaginer et déployer les solutions qui répondront aux challenges de leur organisation, et de leur permettre dans ce contexte de tirer le meilleur des technologies de Microsoft et de ses partenaires comme KUKA.

D’un point de vue technique, le robot LBR iiwa de KUKA est basé sur un système d’exploitation VxWorks, lequel fournit la base pour l’environnement temps réel que nécessite un tel robot industriel.

Sur ce système d’exploitation est ajoutée une couche de présentation, utilisant Windows Embedded, permettant d’obtenir un environnement PC traditionnel tel que nous le connaissons.

Enfin, à l’instar de bon nombre de systèmes industriels, l’interface de programmation proposées est basée sur le langage Java. Cette différence marque une réelle envie de moderniser les interfaces de programmations utilisées dans l’industrie, en introduisant, par exemple, la notion de programmation orientée objet.

Le robot propose toutes les fonctionnalités classiques d’un système d’information, réseaux, parallélisations, communication interprocessus, etc. auxquelles s’ajoutent les différentes interfaces matérielles fournies par KUKA afin de manipuler les éléments du robot.

Dans le but d’augmenter les capacités de ce dernier, nous avons réfléchi à la mise en œuvre additionnelles des éléments suivants (et procédé bien sûr à leur implémentation concrète) :

  • Un serveur web, afin d’exposer une interface REST, permettant d’interroger le robot sur les différentes forces ressenties, sa position actuelle, son mode de fonctionnement, etc.
  • Un point de communication bidirectionnel, TCP/IP, lui permettant de communiquer avec la gateway afin d’échanger des informations en temps réel.

Le robot fonctionne sous la forme d’un producteur/consommateur, le producteur étant la Gateway – mais nous y reviendrons un peu plus tard dans ce billet -, le robot ne faisant que consommer les commandes qui lui sont envoyées.

Bien que ce patron de conception soit assez simple, il convient de noter que, dès lors que nous utilisons un robot, quel qu’il soit, des contraintes d’environnement sont à établir et à prendre en compte.
Partant de ce constat, il nous a fallu mettre en place un système d’états nous permettant de gérer le déclenchement, ou non, de certaines actions du robot.

Dans la pratique, ce système d’états n’en possède que deux : BUSY et FREE, lesquels indiquent respectivement, qu’une opération est en cours d’exécution au sein du robot, et que le robot est en attente d’une action à exécuter.

Dès qu’une opération est planifiée pour l’exécution, elle bascule le robot dans l’état « BUSY », interdisant ainsi toute opportunité pour d’autres actions d’être exécutées parallèlement. Lorsque la tâche se termine, elle bascule l’état du robot en « FREE », rendant éligible ce dernier à l’exécution de nouvelles tâches.

Le système d’acquisition d’images

Pour nos différents scénarios relatifs au cas d’usage envisagé (tri sélectif et de contrôle autonome du mouvement), il nous a fallu réfléchir à un moyen d’acquérir des images de l’environnement perçu par le robot. L’idée principale étant de fournir la solution la plus simple possible, nous avons choisi d’utiliser une simple caméra 2D.

Afin de limiter l’espace nécessaire pour ce système (PC + caméra), nous avons opté pour une carte Raspberry PI 3 Model B sur lequel nous avons connecté une RPI Cam 2, proposant un capteur de 8 mégapixel, largement suffisant pour nos scénarios.

La Raspberry embarque un système d’exploitation Raspian (Linux 4.4) sur lequel nous hébergeons une application Java Spring. Cette dernière expose un micro service REST nous permettant d’effectuer la prise d’image. Concernant l’interface avec le matériel (la caméra), nous utilisons la bibliothèque OpenCV dans sa version 3.1. Enfin, nous documentons l’API directement via Swagger/Swagger UI au sein du code.

Ce système nous permet donc d’avoir une certaine souplesse dans la manière dont sont acquises les images de l’environnement, en délégant cette tâche à différents fournisseurs.

Le système d’évaluation du modèle de Deep Learning

Comme vous l’aurez compris, nous sommes sur la base précédente en mesure d’acquérir une image, et de faire exécuter des actions au robot, encore faut-il déterminer la bonne action !

Le sous-système d’entrainement du modèle de Deep Learning

Pour se faire, il est nécessaire d’entrainer un modèle de Deep Learning de manière supervisée, et ce afin de déterminer le bac de recyclage dans lequel devait être déposé l’objet à recycler.

C’est l’objet de ce sous-système. Nous développerons plus en détails dans le prochain billet les différentes étapes et itérations que nous avons réalisées afin de réaliser l’apprentissage du modèle.

Le sous-système d’évaluation

Le modèle appris se doit d’être exposé pour évaluer des images fournies en paramètre dans une API Web. C’est l’objet de ce sous-système.

Le système de « Gateway »

Dernière pièce du puzzle, et non des moindres – il s’agit même de la clé de voute de toute la communication entre les différents sous-systèmes -, la Gateway fournit l’interfaçage global du robot.

Le système de Gateway permet aussi l’interconnexion entre les différents composants et systèmes. Ainsi, pour le scénario de tri sélectif, elle opère les tâches suivantes (dans l’ordre) :

  1. Faire l’acquisition de l’environnement du robot (Kuka.Eye).
  2. Faire évaluer l’image acquise à l’API hébergeant le modèle de Deep Learning (Kuka.Intelligence Network).
  3. S’assurer la validité des résultats renvoyés.
  4. Lancer l’exécution de la tâche sur le robot.

Le diagramme de séquence ci-dessous résume les différentes phases pour l’exécution d’une tâche de tri sélectif.

Figure 1 : Diagramme de séquence d’évaluation d’une tâche de tri sélectif

Dans notre implémentation, la Gateway repose sur un système d’exploitation Windows 10 IoT Core, et héberge pour les besoins précédents une application universelle développée en C#. Cette application a la charge d’orchestrer les différents acteurs précédents.

Les modèles de déploiement de ces composants et systèmes

Le découpage précédent en composants et systèmes offre la souplesse nécessaire pour autoriser de multiples modèles de déploiement. Nous illustrons ci-après quelques-unes des possibilités ainsi offertes en bénéficiant le cas échéant de la puissance du cloud.

Un environnement purement local pour l’entrainement du modèle de Deep Learning

Dans une première approche, il est courant de vouloir utiliser les ressources à disposition dans l’entreprise, afin de réaliser des « PoC » (Proof of Concept) avant d’aller plus en avant.

L’architecture présentée ici comme premier modèle de déploiement va dans ce sens avec la totalité des éléments sont utilisés localement au sein des ressources de l’entreprise.

Figure 2 : Schéma de l’architecture purement locale

Un environnement hybride pour l’entrainement du modèle de Deep Learning

Dans ce second modèle de déploiement, l’entrainement du modèle de Deep Learning est réalisé via l’environnement d’exécution Microsoft Azure afin de tirer profit de la souplesse et de disponibilité de machines virtuelles potentiellement plus puissantes que celles dont on peut disposer dans l’entreprise en général, comme par exemple avec une machine virtuelle D5_v2 sous Windows Server R2 2012.

(Comme indiqué ici, les instances de la série Dv2 sont basées sur la dernière génération de processeur Intel Xeon® E5-2673 v3 (Haswell) de 2,4 GHz et peuvent aller jusqu’à 3,2 GHz avec Intel Turbo Boost Technology 2.0. Les séries Dv2 sont idéales pour les applications nécessitant des processeurs plus rapides, de meilleures performances des disques locaux ou des mémoires plus volumineuses.

Par ailleurs, il convient de noter que l’entrainement de modèles de Deep Learning pour des projets concrets au sein de Microsoft repose sur l’utilisation d’un cluster de calcul sur GPU au travers d’Azure GPU Lab. Il est à noter, que les applications sur GPU dans Microsoft Azure seront bientôt proposées au grand public, comme en témoigne cette vidéo d’introduction ici.)

Le modèle de Deep Learning, une fois entrainé, est ensuite déchargé localement, où il peut être utilisé directement comme en témoigne le schéma ci-dessous :

Figure 3 : Schéma hybride pour l’apprentissage dans le Cloud et l’évaluation locale

Un environnement hybride pour l’entrainement et l’évaluation du modèle de Deep Learning

Ceci nous amène à cet autre modèle de déploiement où tous les éléments sont déchargés dans le Cloud Azure.

L’entrainement du modèle de Deep Learning se fait donc, comme dans la situation précédente, sur une machine virtuelle potentiellement très performante. Suite à quoi, le modèle de Deep Learning, une fois entrainé, est déchargé au sein d’une API Web dans l’environnement Azure, apportant ainsi toute la flexibilité au niveau de la gestion des ressources et de l’éventuelle mise à l’échelle nécessaire.

Figure 4 : Schéma pour l’apprentissage et l’évaluation dans le Cloud

Un environnement hybride complet avec télémétrie et tableaux de bords

Dans la continuité du précédent, ce modèle de déploiement hybride vise à bénéficier des capacités de certains des services proposés par Microsoft Azure. Ceci suppose d’apporter des fonctionnalités additionnelles à la Gateway.

Ainsi, l’une de ces fonctionnalités consiste à permettre la récupération des informations de télémétrie exposées par le robot. Ces informations sont transmises dans Microsoft Azure, au travers de l’environnement Azure IoT Hub, afin d’être traitées par la suite, notamment dans la solution de visualisation de données PowerBI.

Ainsi, chaque seconde, les informations de positions, forces, boutons d’arrêt d’urgence, mode de fonctionnement sont remontées vers Azure, et affichée au travers de PowerBI.

La principale raison pour laquelle nous avons souhaité décharger l’envoi des informations vers Azure provient de la version de la machine virtuelle Java exécutée sur le robot. En effet, ce dernier exécute à date une version 1.6 de la Java Virtual Machine (JVM), il n’est donc pas compatible avec la bibliothèque Azure IoT Hub pour Java, qui nécessite à minima, la version 1.8 de cette même JVM.

La seconde raison repose sur les ressources à disposition du robot. Ce dernier propose en effet, moins d’un giga de mémoire RAM, et un processeur offrant deux cœurs. Bien que cela soit suffisant dans la majorité des cas d’utilisations classiques, il nous semblait préférable de décharger au maximum les calculs et autres tâches bloquantes sur un système dédié.

Enfin, en plus d’assurer une communication locale entre les différents systèmes, la Gateway expose un point d’entrée externe par le biais d’Azure IoT Hub, via la fonctionnalité Cloud to Device Messages, permettant à des appareils distants de communiquer entre eux de manière ciblée.

Cette fonctionnalité intervient dans le cadre du contrôle à distance du robot, afin de pouvoir exécuter un certain nombre d’actions prédéfinies :

  • Effectuer un déplacement cartésien.
  • Effectuer un déplacement relatif à chacun des degrés de libertés du robot.
  • Effectuer une action de tri sélectif.

Ces scénarios interviennent notamment dans des cas de maintenances à distances, supervisés par un opérateur ne se trouvant pas sur le site d’opération du robot.

Ceci conduit au diagramme ci-dessous qui reprend les différents points énoncés plus hauts, et fournit une vue macroscopique de l’architecture globale du projet telle qu’elle a été déployée à date pour le cas d’usage.

Figure 5 : Architecture globale proposée et mise en œuvre dans le cadre de l’étude

Un environnement local pour l’évaluation du modèle de Deep Learning

Un dernier scénario d’intégration et modèle de déploiement est envisageable, permettant à l’ensemble de s’affranchir de toute connexion Internet ; ce qui, dans un environnement industriel réel est (encore) assez répandu.

Pour cela, la Gateway ainsi que le système d’évaluation sont unifiés. Le modèle de Deep Learning est directement embarqué au sein de la Gateway et aucun mécanisme de communication interprocessus (« IPC ») n’est présent.

Outre la simplification des échanges, ce modèle permet une interrogation au plus rapide du modèle de Deep Learning. De plus, elle permet de facilement mettre à jour ce dernier.

Malheureusement, cette implémentation possède aussi un désavantage certain, elle restreint la plateforme sur laquelle s’exécute la Gateway. En effet, le projet CNTK (Computational Network ToolKit) développé par Microsoft Research que nous utilisons dans ce contexte n’est, à l’heure actuelle, utilisable que sur des plateformes x64. Ainsi, en embarquant le moteur d’évaluation au sein de la Gateway, il est impératif de s’exécuter sur une plateforme elle aussi x64.

Figure 6 : Interface unifiée entre la Gateway et le modèle de Deep Learning

Quelques conclusions préliminaires

Comme vous pouvez le constater, l’architecture ainsi mise en œuvre est basée principalement sur un ensemble de micro-services interopérables et déplaçables à souhait selon divers modèles de déploiement que nous avons brossés ci-avant.

Cette architecture nous semblait la plus pertinente vis-à-vis des besoins respectifs de nos deux sociétés, KUKA et Microsoft, ainsi que dans une optique de « labs ».

Aussi, Les différents modèles de déploiement envisagés mettent en lumière la puissance et la flexibilité du Cloud et de l’environnement d’exécution Microsoft Azure en particulier, permettant de prendre en charge un nombre très large de cas d’utilisations et de coller, au mieux, aux différentes contraintes qui pourraient survenir pour la mise en œuvre en situation réelle d’une telle solution.

Enfin, ces derniers sont toutes basés sur des technologies et principes modernes, et propices à un environnement innovant.

Ce dernier point sera développé plus en détails dans les prochains billets de cette série. À suivre donc. Rendez-vous au prochain épisode ! 😉

Comments (0)

Skip to main content