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 ».

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.