Présentation du projet « Robot Pousseur »

Dans le cadre de notre formation d’ingénieur mécatronique par apprentissage, nous avons eu l’occasion de travailler sur un projet de robot pousseur. Ce projet académique s’inscrit dans le cadre du projet fil rouge qui rappelons le, consiste à améliorer un robot d’investigation de cellule aveugle (RICA III).

Mais qu’est-ce qu’un robot pousseur ?

Un robot pousseur n’est en fait qu’un simple robot de type sumo mais dont la fonctionnalité principale a été détournée. Un robot sumo est un petit robot motorisé comprenant une carte électronique programmable. Son but à l’origine, comme son nom l’indique est d’être en compétition contre un autre robot sumo et de l’éjecter hors d’un cercle à l’aide de son châssis.

Dans notre cas, l’objectif n’est pas d’éliminer un concurrent mais de déblayer un chemin avec ce même châssis.  

Lors d’une mission d’investigation en cellule aveugle, la configuration des différents robots serait la suivante : plusieurs robots pousseurs forment un essaim devant/autour du RICA (voir image ci-dessous). Dès lors que cette configuration est mise en place, l’objectif des robots pousseurs est de déblayer le chemin pour laisser le RICA progresser en cellule aveugle. L’ajout de ces robots pousseurs permettrait de limiter les différents risques qui compromettraient la mission principale : recueillir des informations (radiologique, typographique, etc…) de la cellule à investiguer.

Ci-dessous une représentation schématique de la configuration en question.

Les fonctionnements attendus peuvent être décrit suivant trois modèles, c’est-à-dire selon la position du robot au sein de l’essaim :

• Notre robot pousseur se trouve à la place du RP0 : le robot pousseur doit suivre directement les mouvements du RICA.

• Notre robot pousseur se trouve en RPGx : le robot pousseur doit suivre les mouvements du premier robot pousseur à sa droite.

Ex : RPG2 suit les mouvements du RPG1 qui lui-même suit les mouvements du RP0 suite à un mouvement du RICA.

• Notre robot pousseur se trouve en RPDx : le robot pousseur doit suivre les mouvements du premier robot pousseur à sa gauche.

Ex : RPD2 suit les mouvements du RPD1 qui lui-même suit les mouvements du RP0 suite à un mouvement du RICA.

Dans l’idéal, chaque robot pousseur doit pouvoir gérer ces trois modes de fonctionnement.

Vous l’aurez sûrement compris, contrairement au RICA qui lui est piloté, les robots pousseurs fonctionnent en parfaite autonomie. On pourrait dire ici que ces différents robots sont asservis aux mouvements du RICA, c’est-à-dire qu’ils sont dépendants de ce dernier.

Afin de pouvoir réaliser ce projet, nous avions à disposition un kit de robot Sumo. Celui-ci comprenait différents éléments dont une carte programmable Arduino nous permettant de programmer les différents modes de fonctionnement. Nous avions également différents capteurs avec des caractéristiques différentes. Ces éléments seront détaillés au cours du prochain article à savoir « Robot Pousseur : Partie 1 Hardware » et suivra par la suite un troisième article : « Robot pousseur : Partie 2 Software ».

Le Multiplexage/Démultiplexage du RICA

Qu’est-ce que le multiplexage ?

La fonction multiplexage est le fait d’envoyer sur une même ligne de transmission des informations provenant de plusieurs sources.

Dans cet exemple, le multiplexeur a 4 entrées logiques E0, E1, E2 et E3, et une sortie logique S. En fonction de la sélection, une des 4 entrées se retrouvera à la sortie du multiplexeur :

• Si la sélection est placée en position 0, la sortie prend l’état logique de l’entrée E0
• Si la sélection est placée en position 1, la sortie prend l’état logique de l’entrée E1
• Si la sélection est placée en position 2, la sortie prend l’état logique de l’entrée E2
• Si la sélection est placée en position 3, la sortie prend l’état logique de l’entrée E3

Qu’est-ce que le démultiplexage ?

La fonction démultiplexage est le fait d’envoyer sur plusieurs lignes de transmission des informations provenant d’une seule source.

Dans cet exemple, le démultiplexeur a 1 entrée logique E, et 4 sorties logiques S0, S1, S2 et S3. En fonction de la sélection, les informations présentes sur l’entrée du démultiplexeur se retrouvent sur l’une des sorties :

• Si la sélection est placée en position 0, l’état logique de l’entrée E se retrouve sur la sortie S0
• Si la sélection est placée en position 1, l’état logique de l’entrée E se retrouve sur la sortie S1
• Si la sélection est placée en position 2, l’état logique de l’entrée E se retrouve sur la sortie S2
• Si la sélection est placée en position 3, l’état logique de l’entrée E se retrouve sur la sortie S3

Quel rapport avec le RICA ?

Comme signalé dans les articles précédents, le robot RICA est un robot d’investigation. Afin de remplir pleinement sa mission, les données mesurées doivent être transférer le plus efficacement possible au poste de téléopération. Pour cela le CEA a mis au point un système de multiplexage/démultiplexage. Les paragraphes suivant vont vous expliquer la raison et l’utilité de ce choix techniques.

Lors de ces interventions le robot RICA est alimenté par un câble que l’on appelle « Ombilic ». Ce câble permet également d’envoyer les mesures et informations capturées par le robot et de recevoir les ordres liés au déplacement, à l’éclairage et au choix des caméras. Il n’y a donc qu’une seule voie d’accès pour les informations. Or pour faciliter le traitement des informations, ces dernières doivent être acheminées entre différents postes. En effet en fonction des mesures que l’on effectue, le traitement nécessitera une configuration spécifique des ordinateurs. De plus il est a noté que le RICA doit recevoir et envoyer des informations à la mallette de commande.

Un système de multiplexage/démultiplexage, avec plusieurs prises permettant de changer les entrées/sorties du système plus facilement, fut installé dans un coffret. Chaque système intervenant dans le traitement des informations y sera connecté et possédera une adresse permettant de l’identifier. Ainsi les pilotes peuvent pleinement se concentrer sur le robot et son environnement, évitant ainsi des erreurs de manipulation.

Le schéma ci-dessous représente un exemple de branchement sur le coffret de multiplexage/démultiplexage lors d’une intervention.

Pour la montée en gamme du RICA, le CEA souhaite garder le coffret de multiplexage/démultiplexage. Il faudra donc prendre en compte les caractéristiques de ce coffret lors de la conception du nouveau robot.

La caméra gamma

      1- Présentation de l'outil

La caméra gamma est un outil indispensable lors de l’investigation de zones potentiellement contaminées. Il permet de localiser et donc de réaliser une cartographie des sources radioactives.

L’objectif est donc de pouvoir à partir des images réelles et des mesures faites par la caméra gamma d’obtenir une image nous indiquant l’activité radioactive dans l’environnement où évolue notre robot (voir image ci-dessous).

Cependant pour pouvoir réaliser des mesures correctes, la caméra doit être orientée dans la direction de la zone radioactive pour capter au mieux les rayonnements. Ceci étant rendu possible par le système supportant la caméra sur le robot RICA.

La caméra gamma, peut être optionnellement être couplée à différents autres systèmes. Par exemple, un dosimètre permettant de vérifier et de recaler les résultats mesurés par la caméra ou encore de définir le temps de pose pour prendre la mesure. On peut aussi coupler un télémètre de connaître la distance séparant la source radioactive visée de la caméra gamma.

2- Description de la caméra gamma

La caméra gamma est composé de 5 principaux éléments présentés dans l’image ci-dessous. Un embout en tungstène bloquant la majorité des rayonnements gamma, sert à protéger ce dispositif. Il dispose d’une ouverture biconique à sténopé permettant de laisser passer une partie des rayonnements. Ensuite le rayonnement traverse un obturateur, ne laissant passer que les rayonnements radioactifs. La lumière est ainsi arrêtée par ce dispositif. Une fois l’obturateur traversé, les rayonnements sont captés par un scintillateur. Le rôle de cet élément est de convertir ce rayonnement en photons. Les photons sont, pour finir, captés par le détecteur permettant ainsi de fournir une image des rayonnements.

Comme expliqué précédemment, cette image est ensuite superposée à une image réelle, nous donnant ainsi de localiser les sources dans notre environnement.

Ce type de technologie est aussi utilisé dans l’imagerie médicale.

Application de l'IS pour le RICA IV

Comme vous avez pu le comprendre dans l'article précédent, l'ingénierie système est une démarche permettant de concevoir un système qui répond à tous les besoins du client. Pour le système du RICA IV, nous avons donc mis en place cette démarche. Depuis environs un an, nous travaillons sur la création de la nouvelle version du RICA III.

Cerner la demande du client

Avant de nous lancer dans la conception et la recherche de solution, nous devons identifier les besoins de notre client. Pour cela, de nombreuses réunions ont été mise en place entre l'école et le CEA afin de mieux comprendre le cahier des charges qui nous a été délivré. Nous avons ainsi pu identifier une vingtaine de besoins pour notre système RICA IV, comme par exemple:

• " Franchir un obstacle"
• "Résister aux radiation"
• "Acquérir des informations"
• "Interagir avec des robots pousseurs"

Une fois les besoins identifiés, il faut créer les exigences fonctionnelles ou non fonctionnelles qui en découlent. Pour cette partie, nous devons affiner les différents besoins et identifier tout ce qu'ils impliquent. Pour se donner un exemple simple, on peut déduire que les exigences qui proviennent du  besoin "résister au radiation" sont :

• "Résister aux radiations Gamma"
• "Résister aux radiations Beta"
• "Résister aux radiations Alpha"

Avec notre vingtaine de besoin, nous avons donc réussi à tirer environs une soixantaine d'exigences. Par la suite, elles permettront  de déterminer les fonctions que doit réaliser notre système et les composants nécessaires à sa réalisation.

Le contexte du  RICA IV

Afin de continuer dans notre étude, nous avons réalisé des recherches sur le contexte de notre système. Vous avez pu le comprendre dans les articles précédents que le contexte principal de notre RICA IV est le milieu nucléaire avec toutes les contraintes de sécurité et de radioactivité que cela implique. Cependant dans notre étude, nous devons prendre en compte le cycle de vie complet de notre système, soit aussi durant sa phase de conception, de fabrication et de sa fin de vie.

 En prenant en compte ces étapes, nous  obtenons de nouvelles exigences. Par exemple pour sa fin de vie, nous devons faire attention aux radiations en limitant au maximum les pièces qui pourraient être soumises à celle-ci. Toutes ces exigences supplémentaires devront être prise en compte durant notre recherche de solution.

Fonctionnement

Enfin  avant de se lancer dans la réalisation des architectures du système RICA IV, il faut identifier les différents scénarios possibles lors de son mode de fonctionnement. Il faut créer tous les scénarios possibles que ce soit en mode nominal ou en mode dégradé afin de faire fasse à toutes les éventualités et de pouvoir palier à certains problèmes dès la conception de notre système. Pour mieux comprendre, je vais vous décrire brièvement quelqu’un de ces scénarios identifiés dans le cadre de notre projet:

• Le franchissement d’une marche de 30 cm, pour ce scénario le pilote et le copilote mettent le RICA IV en mode automatique pour franchir la marche, un fois la marche franchi le RICA IV s'arrête et attend les ordres du pilote et du copilote
• La perte de vision au niveau de l’interface homme machine, le RICA IV doit revenir sans endommager la cellule, un bip sonore est mis en place en cas de détection d’un obstacle.
• Utilisation du bras robotisé, le RICA IV doit se stabiliser en fonction du déplacement du bras robotisé et en fonction du poids qu’il déplace.

Ces scénarios font partis des nombreux scénarios possibles que pourrait réaliser notre RICA IV. Ces scénarios devront être pris en compte lors de la réalisation de nos architectures qui sera la base de notre conception.

Présentation de l'Ingénierie Système :

Pour mener à bien des projets tels que la montée en gamme du robot RICA, il est nécessaire de voir le projet dans sa globalité et répondre au besoin exprimé par le client sans oubli. Les méthodes de conception, évolution et vérification de produits/systèmes simples ne sont plus particulièrement pertinentes lorsque le projet devient complexe en faisant par exemple intervenir plusieurs corps de métier ou encore plusieurs sous-traitants.

C’est dans le cadre de ce type de projets (complexes et novateurs) qu’une méthode a été mise en place à l’aube des années 90 appelée Ingénierie Système (IS). Les premiers à utiliser cette méthode, qui en sont par ailleurs les créateurs, ont été les entités américaines travaillant pour le compte de la recherche spatiale et de l’armement. Depuis l’IS s’est largement étendue tout autour du monde et notamment en France à travers la création de l’AFIS (Association Française d’Ingénierie Système) en 1998. (https://www.afis.fr/pages/accueil.aspx)

La démarche d’IS est souvent présentée au travers du cycle en V dans lequel on retrouve toutes étapes qu’il faut suivre. Ce cycle se décompose en 3 grandes parties.

Figure 1 Cycle en V

1. Définition du système :

La première étape et certainement la plus importante est la définition du système. Dans un premier temps sous la forme d’un cahier des charges classique. Puis au travers de plusieurs itérations avec le client fixer un document qui décrit le système (par la définition de sa mission, sa finalité, son objectif) dans son ensemble et par la liste exhaustive des besoins auxquels il doit répondre rapporter en exigences.

Il est également nécessaire de prendre en compte les interactions que le système est amené à avoir avec le milieu extérieur, ses différents modes de fonctionnement sans oublier de prendre en compte tous acteurs gravitant autour du projet.

Dans cette phase de définition, des architectures du système sont créées (fonctionnelles et organiques). L’architecture fonctionnelle regroupe l’ensemble des fonctions qui définissent le système, ces fonctions sont organisées par ordre d’utilisation dans des diagrammes de plusieurs niveaux. Chacune des fonctions est reliée à au moins une exigence fonctionnelle. L’architecture organique en opposition à l’architecture fonctionnelle regroupe tous les composants identifiés de notre système hiérarchisés et organisés en niveaux. Ils sont relié aux exigences non-fonctionnelle de notre système.

Figure 2 Exemple d'une architecture fonctionnelle

Des outils informatiques permettent de saisir et corréler l’ensemble des informations recueillies lors de la définition du système. Une fois tous les éléments créé, définis et reliés entre eux et après plusieurs itérations nous sommes en possession du modèle de notre système.

2. Validation & Vérification (V&V) :

Après avoir créé le modèle du système, il est logique de le confronter à un autre regard afin de s’assurer qu’il ne présente pas d’erreurs de formes et qu’il est complet. Tous composants, les fonctions, exigences présentes dans le modèle sont donc analysés.

Le vérificateur fourni, une fois son travail terminé, un document pointant du doigt des aspects qui paraissent ambiguës, des oublis ou encore des erreurs de forme. A cette étape seule la forme est vérifiée, la cohérence du modèle et son exactitude est étudiée par la suite.

Il est possible d’avoir des itérations entre cette phase et celle de définition de système pour parvenir à un modèle admis comme juste et cohérent par le vérificateur.


3. IVTV (Intégration, Vérification, Transition, Validation du système) :

Le modèle étant à cette étape vérifié et validé il faut maintenant passer aux phases de réalisation du premier jet du système qui va permettre de passer à l’étape de vérification. La vérification a pour but de prouver que le système correspond au modèle établi dans les étapes amont.

Après cette vérification, le système correspond à l’ensemble des attentes du client. Le système est donc prêt à être exploité dans son environnement opérationnel.

Pour finir, il ne reste plus qu’à valider l’ensemble du système dans son environnement et vérifier une fois de plus qu’il répond à l’ensemble des exigences exprimées par le client.


Pour conclure :

L’Ingénierie Système est donc, vous l’aurez compris, un outil aussi puissant que complexe permettant de faire émerger des systèmes toujours plus compliqués. Les étapes citées ci-dessus en sont le piller et toute démarche sur la création ou la modification d’un système complexe fera intervenir ces étapes à tour de rôle. Il ne faut néanmoins pas oublier l’élément principal qui permet à un système d’être abouti : les itérations. Elles sont omniprésentes dans chacune des étapes et d’une étape à une autre, et permettent de corriger la majorité des erreurs avant que le système ne soit mis en production ou utilisé de manière opérationnelle par le client.