L’un des objectifs de la robotique est de réussir à concevoir des robots qui puissent interagir de manière autonome avec leur environnement. Pour que cela soit possible, le robot doit non seulement pouvoir récupérer des données sur l’environnement dans lequel il évolue, mais il doit surtout les prendre en compte et réagir de manière adaptée. En effet, un robot qui marche doit pouvoir s’apercevoir qu’il est tombé, mais il doit surtout interrompre sa marche, se relever, puis reprendre sa marche. Il doit donc être capable de recevoir une certaine quantité d’information, de les traiter en parallèle, et de ne garder que les informations pertinentes en rapport avec l’action qu’il doit effectuer. Cela doit lui offrir les moyens d’effectuer l’action adéquate à un moment précis, et d’avoir une réactivité suffisante.

Le but de ce projet est de concevoir une architecture informatique adaptée aux contraintes reposant sur le robot, mais pouvant être utilisée pour d’autre applications nécessitant l’utilisation de plusieurs modules interdépendants devant s’exécuter en parallèle. Cette architecture sera constituée de modules légers, qui peuvent interagir simplement entre eux. Ainsi certains modules pourront influer le comportement des autres en les inhibant ou au contraire en les activant. Le résultat final devra être une libraire C++ intégrant les briques de base pour cette architecture. Cette librairie pourra également contenir des modules types dont nous pouvons supposer qu’ils peuvent servir dans de nombreux cas.

Ce projet s’appuie sur le projet précédent (Projet NAO – Détecter et chercher une balle). L’environnement de travail fixé est le suivant : développement en langage C++ sous Linux.

Déroulement du projet

La réalisation de ce projet a nécessité de passer par différentes phases :

• bibliographie,
• conception de l'application,
• développement et test du programme.

Architecture du programme

L’idée du projet est de trouver une architecture logicielle permettant de concevoir facilement une application avec des taches qui interagissent à l’aide d’un ensemble simple de règles. La difficulté est d’avoir une librairie à la fois facile d’utilisation et avec un haut degré de liberté afin de ne pas limiter par la suite le développement d’application avec cette librairie.

Nous avons ainsi défini que les applications qui utiliseront notre bibliothèque seront composés d’un tas de composant, gérés par un contrôleur (nommé Robot). Les composants seront identifiés par un nom auprès du contrôleur.

Les composants

En nous inspirant du projet réalisé précédemment « Détecter et suivre une balle », nous avons défini trois types de composants :

• les « Sensors » qui captent des données,
• les « Processors » qui traitent des données acquises en amont,
• les « Actuators » qui réalisent les actions.

Transfert des données

Nous avons choisi que chaque élément composant l’application sera un Thread indépendant, permettant de faciliter le transfert des données entre les différents modules. Cette décision est prise au risque d’avoir un grand nombre de Thread tournant en parallèle.

Afin de faciliter les échanges de données, nous avons retenu une solution où chaque composant mettant à disposition des données les mémorise en interne. Ces données peuvent alors être consultées par d’autres composants. C’est au composant qui a besoin de consulter les données qui doit mémoriser la référence du composant auprès duquel il se fournit en données.

Notion d’états

En réfléchissant sur les différents états possibles d’un composant, nous avons aboutis à un diagramme à quate états :

• Init : état d’initialisation du composant,
• Paused : état de non fonctionnement du composant,
• Running : état de fonctionnement standard du composant,
• Achieved : état de fonctionnement d’un composant avec une idée d’objectif réussi.

Transitions

Nous avons prolongé cette description du fonctionnement par une étude des transitions utiles pour passer entre les différents états.

Nous avons ainsi défini 6 transitions possibles. Certaines de ces transitions peuvent être utilisées uniquement en interne du composant alors que les autres seront utilisés lors de l’application des règles par le contrôleur.

Règles

Une fois établi le diagramme d’état et de transition, nous avons établi la sémantique des règles qui seront utilisées.

Nous avons décidé la sémantique des règles : Précondition => Action

Les « Préconditions » sont un ensemble de relations sur les états des composants séparés par des « ET » logiques. Les « Actions » sont un ensemble de changements d’états.

Gestion des règles

La gestion des règles est prise en charge par une entité dédiée centralisée. L’activation d’une règle ne pouvant intervenir que lors du changement d’état d’un composant. Le contrôleur est avertis de chaque changement d’état. Le contrôleur est un Thread à part entière.

Validation du projet

A la fin de ce projet, nous avons remis au professeur encadrant :

• le code commenté composant notre projet,
• un rapport d'une cinquantaine de page résumant la démarche que nous a guidé durant ce projet ainsi qu'une documentation complète du programme.

Pour valider ce projet, nous avons présenté notre travail dans le cadre d'une soutenance devant le professeur encadrant ce projet ainsi que l'ingénieur responsable de la smart-room de Supélec. Cette présentation a été suivie d'une démonstration.

Le programme conçu lors de ce projet a servi de base pour un autre projet proposé par le professeur encadrant.