Vers une architecture multi-robots

L’utilisation d’une flotte de robots plutôt qu’un robot unique apporte beaucoup dans de nom-breux contextes opérationnels, pour améliorer le temps d’exécution d’une mission et ses chances

de réussite. On peut donc se demander si il est possible de faire évoluerroarpour contrôler non

seulement un robot mais une flotte de robots. Notons d’abord que roar a plusieurs atouts de

base pour le contrôle multi-robots. Sa décomposition en agents-ressources permet de modéliser

facilement l’hétérogénéité des différents robots, chaque robot déployant uniquement les agents

correspondant à ses propres capacités. La décision se fait de manière distribuée, chaque agent

n’ayant qu’une vue partielle du système. La modélisation décentralisée de roar passe bien à

l’échelle multi-robots, d’autant plus qu’elle est basée sur des messages asynchrones.

Communication Ceci étant dit, il existe évidemment des difficultés pour passer d’un modèle

mono-robot à un modèle multi-robots. L’une de ces difficultés est la communication. Au sein

d’un robot, on peut faire l’hypothèse d’une communication sans problème de délai, perte de messages ou limites de bande passante : ce n’est évidemment pas le cas au sein d’un système multi-robots. Il est donc nécessaire d’introduire explicitement un agent gérant la communication au niveau de l’architecture (et pas simplement au niveau instanciation). Cet agent aura alors des

9.2. PERSPECTIVES 125 en réponse contraindre d’autres agents (en particulier la position du robot, afin de garantir que la communication reste possible).

Choix des agents impliqués Une des autres questions qui se pose est de savoir quels agents

choisir quand plusieurs agents sur différents robots correspondent aux spécifications d’une

re-cette. Différentes approches sont possibles ici. Le choix peut se faire unilatéralement, au niveau

de l’agent exécutant la recette : celui-ci décide arbitrairement, ou à partir d’une information haut

niveau présente sur les différents agents, quels agents sur quels robots il va utiliser et essayer.

En cas d’échec, il tentera une autre combinaison d’agents, et les contraintes automatiques sur les communications vont alors implicitement créer des coalitions. Cette extension serait dans l’esprit de la synthèse automatique de tâche de ASyMTRe (Tang and Parker, 2005). Comme il

s’agit de problèmes d’affectation (ou d’allocation), une autre approche possible est d’utiliser des

approches de négociations, comme par exemple CNP (“Contract Net Protocol”) (Smith, 1980), pour décider entre ces agents celui qui est le mieux adapté pour résoudre actuellement une

cer-taine contrainte, dans l’esprit de ASyMTRe-D (Tang, 2007). Bien que probablement plus efficace

sur des cas complexes, cette approche soulève deux types de problèmes, qui devront être finement analysés. D’un côté, la décision de choisir un agent plutôt qu’un autre dépend aussi généralement des autres activités courantes du robot, et donc d’une information “globale” sur le système. De l’autre, cela a un impact non négligeable sur la formalisation et pourrait rendre certains résultats

Annexes

Annexe A

Liste des publications

Publications en cours d’évaluation

Degroote, A. and Lacroix, S. (2012a). A control architecture for autonomous robots founded

on resource agents. Submitted to International Journal of Robotics Research.

Echeverria, G., Lemaignan, S., Degroote, A., Lacroix, S., Karg, M., Koch, P., Lesire-Cabaniols, C., and Stinckwich, S. (2012). User Driven Improvements to Robotics Simulation in MORSE. InSubmitted to Simulation, Modeling, and Programming for Autonomous Robots.

Publications dans des conférences internationales

Degroote, A. and Lacroix, S. (2011a). Roar : Resource oriented agent architecture for the

autonomy of robots. InInternational Conference on Robotics and Automation, Shangai (China).

Degroote, A. and Lacroix, S. (2011b). Roar : Resource oriented agent architecture for the

autonomy of robots. In 9th International Conference on Practical Applications of Agents and

Multi-Agent Systems (PAAMS), Salamanca (Spain).

Echeverria, G., Lassabe, N., Degroote, A., and Lemaignan, S. (2011a). Modular open

ro-bots simulation engine : Morse. In Robotics and Automation (ICRA), 2011 IEEE International

Conference on, pages 46 –51.

Boumghar, R., Roussillon, C., Degroote, A., Cox, P., Vandeportaele, V. D. B., Herrb, M.,

and Lacroix, S. (2011). Over the hill and far away : aerial/ground cooperation for long range

navigation. In International Workshop on Robotics for risky interventions and Environmental

Surveillance-Maintenance, Leuwen (Belgique).

Publications dans des conférences nationales

Degroote, A. and Lacroix, S. (2012b). Roar : une architecture orientée agents pour

l’autono-mie des robots. In 18ème congrès francophone sur la Reconnaissance des Formes et

gence Artificielle, Lyon (France).

Degroote, A. and Lacroix, S. (2012c). Une architecture pour l’autonomie des robots basée

sur des agents-ressources. In 6ème Conférence francophone sur les architectures logicielles,

Montpellier (France).

Degroote, A. and Lacroix, S. (2012a). A resource-agents robot control architecture : design

and formalization. In 7ème Conférence francophone sur les architectures logicielles, Nancy

(France).

Degroote, A. and Lacroix, S. (2010). Structuring processes into abilities : an

information-oriented architecture for autonomous robots. In5th National Conference on Control

Annexe B

MORSE

morse(“Modular OpenRobots Simulator Engine”) (Echeverria et al., 2011) est un simulateur

libre orienté robotique initié au LAAS, au développement duquel nous avons beaucoup participé,

et qui est maintenant co-développé par de nombreux universitaires1. Il est basé sur

l’environne-ment de modélisation libre Blender2et son mode jeu reposant sur le moteur physiquebullet3.

Cela permet de construire des simulations relativement réalistes dans des modèles d’environne-ments complexes (voir un exemple figure B.1). Blender, aussi bien la partie modélisation que la

partie jeu, est entièrement programmable via une interface Python4 : il est alors facile de créer

des comportements de haut niveau ou de développer de nouveaux capteurs à partir des données exportées par Blender.