Table des matières
Le diagramme suivant vous montre une architecture typique de clients et de logiciels pour une application URBI. Vous avez des clients en C++, en Java et en Matlab tournant sur différentes machines (sous Linux, Windows et MacOS X), des UObjects distants, des clients sur place, des UObjects intégrés et des scripts tapés depuis telnet/URBILab. Il y a également un ensemble de scripts de contrôle lancés depuis le fichier URBI.INI. Cet exemple montre combien URBI peut être souple en permettant à tous ces systèmes de fonctionner en parallèle sur votre robot.
Vous disposez d'un serveur URBI sur votre robot et ...
Contrôle à distance d'un robot
Votre robot est équipé d'une connexion WiFi, tel Aibo, et vous exécutez un programme complexe d'intelligence artificielle sur un puissant ordinateur personnel pour le contrôler. Ce programme est en réalité un client URBI écrit en C++ qui utilise la liburbi-C++ ou la bibliothèque UObject pour envoyer des commandes URBI au robot quand cela est nécessaire, et pour recevoir des messages URBI du serveur de manière asynchrone en vue d'y réagir de façon appropriée. Vous pouvez remplacer C++ par Java, Matlab ou tout autre langage. Vous avez également quelques composants UObject exécutant d'intéressants algorithmes de vision.
Un robot entièrement autonome avec un client URBI (des UObjects) à bord
Cette fois-ci, vous exécutez le client URBI ou les UObjects sur le robot et non à distance. Là encore, tout ceci est écrit en C++ avec la liburbi-C++ ou avec l'architecture UObject. Au lieu d'une connexion TCP/IP WiFi entre le client et le serveur, vous avez une communication directe entre les processus sur l'hôte local ou un accès direct à la mémoire partagée avec le mode intégré d'UObject.
Un robot autonome contrôlé entièrement par des scripts URBI
Dans ce cas, cela signifie que vous avez trouvé toutes les fonctionnalités dont vous avez besoin dans URBI (pas de programmation externe en C++ ou Java de nécessaire). Vous rédigez directement vos boucles perception-action avec des scripts URBI tournant sur le serveur, utilisant des composants pré-existants ou téléchargés en mode intégré. Vous n'avez besoin que d'un telnet ou d'URBI Remote pour envoyer vos scripts URBI au serveur, et voilà. Vous pouvez également stocker directement le script dans le fichier
URBI.INIet votre robot le lancera alors au démarrage (nul besoin d'un client ou d'un ordinateur).Un peu des trois
Vous avez un robot contrôlé par plusieurs clients URBI en même temps, certains sur le robot, d'autres sur l'ordinateur, certains en C++, d'autres en Java, d'autres encore en Matlab. Par dessus tout cela, vous avez également plusieurs scripts URBI faisant tourner sur le serveur des boucles perception-action, utilisant de puissants UObjects écrits par vos soins mais aussi d'autres téléchargés sur Internet. Tout ceci est lancé depuis
URBI.INImais aussi dynamiquement chargé par certains clients, au besoin. C'est la situation la plus intéressante, exploitant au maximum la souplesse d'URBI.